Rust vs C++

@ReYalp · Регистрация: 27.12.2017

Студворк — интернет-сервис помощи студентам

Кто-то писал на Rust? Стоит ли начинать учить? Насколько Rust хуже/лучше С++?

@Fulcrum_013 · 07.07.2020, 20:30

Сообщение от COKPOWEHEU

Не угадали, в bash вообще нет библиотек, ни внешних, ни внутренних.

То что они не подключаются явно, говорит только о том что они подключены по дефаулту. Подключение к скриптам нативных библиотек прямым быть не может. Они подключаются через обертки в результате чего в языке становятся доступны типы и функции из оной библиотеки. Абсолютно вся функциональность которая не входит в ядро языка меняется только таким способом, особенно в скриптах. Если работа к примеру со строками будет внесена в ядро, как к примеру паскале когда то в 70-х напрямую компилил работу с ними в нативный код, а не вызовом нативных функций реализующих функциональность, то в плане производительности наступит вообще катастрофа. К созданию библиотек даже для себя скрипты не пригодны по определению.

Добавлено через 3 минуты

Сообщение от COKPOWEHEU

Мы ведь говорим о десктопном применении двух ОСей общего назначения,

Если не забыли мы говорим о продуктивности языков на которых они написаны. Т.е. для этого нужно взять код реализующий одинаковую функциональность и сравнить количество строк кода. Объем функциональности же АПИ винды ни в какое сравнение с функциональностью линухи не идет - у линухи дай бог чтобы 1% в этом плане набрался, не говоря уже про набор искоробочных софтин и драйверов.

Добавлено через 59 секунд

Сообщение от COKPOWEHEU

Так что там со скоростями роста ядер разных ОС?

У линухи с этим вопросом явно гигантские проблемы. Размер ядра давно превысил размер примерно анологичного по функциональности ядра + апи резко превосходящего апи линухи + горы мелких утилит.

Добавлено через 1 час 14 минут

Сообщение от COKPOWEHEU

с приблизительно равным общим функционалом

А вот насчет равности функциональности это уже абсолютныые сказки.

Добавлено через 15 минут

Сообщение от COKPOWEHEU

А вот если бы они еще и практикой подтверждались...

Да оно давно ей подтверждается. Ничего сложнее примитивных числодробилок на старых универсальных языках процедурного пркроения, и мусорных хеллоувердов на скриптовых языках давно не пишут ни на чем окромя дельфы и плюсов. При этом дельфа очень сильно сдает позиции. Ада держится только на куче еще юзаемого софта на ней, обеспечить совместимость которого с плюсами будет довольно сложно. Единственное где на ней еще ведутся новые разработки - Ариан-6, унаследовавший большую часть бортовых и все наземные системы от пердыдущих ракет. Новоделы даже в этой нише во всю на плюсах.
Вообще последним действительно специализированным языком был давно почивыший в бозе CLIPPER-87.
Все что после - это куцые обрубки универсальных языков, создаваемые исключительно с целью привлечения неквалифицированных разрабов к самым примитивным задачам и не более того.

Добавлено через 5 минут

Сообщение от COKPOWEHEU

ООП - одно из естественных ответвлений от процедурного стиля.

Еще раз - ООП это методолгия проектирования, основанная на моделировании сущностей предметной области, связей между ними и их взаимодействия, а не ключевое слово class. И в каком стиле это будет реализовано в принципе не важно -все средства для костыленья спроектированного по такой методологии кода имеет даже ассемблер, именно эта методология соответсвует особенностям человеческого мышления. Именно поэтому процедурщина которая выражалась формулой программы = структуры данных + алгоритмы их обработки обзавеласть языковыми средствами поддержки этого + в виде классов, а не по какой то другой причине.
И именно поэтому ФП с 50-летни опозданием во всю движется именно в сторону ООП.
По другому спроектировать что то сложнее примитивной числодробилки невозможно.

Добавлено через 2 часа 29 минут
COKPOWEHEU, При этом не надо путать ответвление и обобщение. Это таки две огромные разницы.

@Usaga · 08.07.2020, 07:54

Сообщение от Fulcrum_013

Ну там вообще то html и т.д. были поставлены в один ряд с языками программирования, а не о генерации речь шла.

Всё таки, речь шла о генерации. Плюсы тут никаких "плюсов" не имеют перед другими языками (не только скриптовыми).

@COKPOWEHEU · 08.07.2020, 09:05

Сообщение от Fulcrum_013

То что они не подключаются явно, говорит только о том что они подключены по дефаулту. Подключение к скриптам нативных библиотек прямым быть не может

Прежде чем о чем-то рассуждать, хорошо бы ознакомиться с предметом. Хотя бы на базовом уровне. Пока что уж слишком хорошо видно, что о Баше вы только слышали.

Сообщение от Fulcrum_013

Если не забыли мы говорим о продуктивности языков на которых они написаны.

Да, но вы зачем-то решили уйти в сторону и сравнить объем кода ядра различных ОСей. Причем ваше сальто в лужу было настолько артистичным, что мне хочется продолжения!

Сообщение от Fulcrum_013

Объем функциональности же АПИ винды ни в какое сравнение с функциональностью линухи не идет

Да, winapi настолько убогая штука, что и сравнивать бы не стоило, но раз уж начали - добьем до конца.

Сообщение от Fulcrum_013

не говоря уже про набор искоробочных софтин и драйверов.

Я бы тоже об этом не говорил, иначе виндузятники совсем ущербными себя почувствуют, но опять же - раз начали...

Сообщение от Fulcrum_013

У линухи с этим вопросом явно гигантские проблемы. Размер ядра давно превысил размер примерно анологичного по функциональности ядра + апи резко превосходящего апи линухи + горы мелких утилит.

Графики я вам предоставил, видно что winapi растет минимум квадратично, линукс скорее логарифмично. Или в вашей вселенной чем больше кода тем лучше?
И как видно по вашей же ссылке, даже современное ядро намного компактнее древних виндовых, при том что до функционала линукса и современной винде еще расти и расти.

Сообщение от Fulcrum_013

Да оно давно ей подтверждается.

Если бы подтверждалось, мы бы видели всеобщее засилье С++, а не сотни языков, и постоянно возникают новые.

Сообщение от Fulcrum_013

Еще раз - ООП это методолгия проектирования

Хорошо, если вас так беспокоит ваше непонимание принципов ООП, поясню: предметная область разбивается на максимально обособленные сущности, обладающие внутренним состоянием и логикой, а также внешними интерфейсами. Такая сущность и называется объектом. Отдельные объекты могут выстраиваться в иерархию наследования, когда потомок обладает всеми свойствами предка, но в дополнение - какими-то своими. Соответственно, основной принцип ООП - объединение данных и методов работы с ними.
Процедурное программирование разделяет данные и процедуры, это скорее выделение повторяющихся блоков в более-менее монолитном алгоритме.
В функциональном данные как таковые отсутствуют, есть только функции, аналогичные математическим (хм. только сейчас задумался что Labview богомерзкий - функциональный язык. Да и bash тоже, хотя и от процедурщины там немало)
Хоть теперь разница понятна?

Сообщение от Fulcrum_013

COKPOWEHEU, При этом не надо путать ответвление и обобщение. Это таки две огромные разницы.

Поэтому ООП - ответвление процедурного, а не обобщение. А по реализации (по крайней мере, в Lua, Python, C++) ООП - частный случай процедурного подхода, передача объекта как неявного нулевого параметра в методы.

@korvin_ · 08.07.2020, 09:36

Сообщение от COKPOWEHEU

В функциональном данные как таковые отсутствуют

Щито?

@COKPOWEHEU · 08.07.2020, 10:57

korvin_, имеется в виду, что они существуют только между функциями, в неявном виде. Может быть линия данных, но вот выделенного хранилища данных в ФП быть не должно.

@Fulcrum_013 · 08.07.2020, 14:22

Сообщение от COKPOWEHEU

Хоть теперь разница понятна?

Вы хоть сами то поняли какой бред несете?

Сообщение от COKPOWEHEU

частный случай процедурного подхода, передача объекта как неявного нулевого параметра в методы

В чем отличие от явной передачи, которая во всем "процедурном" коде во всю? Вся процедурщина в которой более одной процедуры - это все то же ООП только без поддержки со стороны ядра языка. Obj.Proc() от Proc(&Obj) принципиально ничем не отличается. Точно так же Obj->Proc() от Obj->VPTR[ProcId](Obj). Так что точно так же в процедурщине разбивают на сущности и выполняемые над ними операции, иначе что то сложнее табулирования функции спроектировать анриал.

Сообщение от COKPOWEHEU

Процедурное программирование разделяет данные и процедуры, это скорее выделение повторяющихся блоков в более-менее монолитном алгоритме.

Еще раз формула процедурного программирования программы = алгоритмы + процедуры. Процедурщина отличается исключительно отсутсвием поддержки оного + со стороны синтаксисас и больше ничем.

Сообщение от COKPOWEHEU

В функциональном данные как таковые отсутствуют,

Любая программа занимается преобразованием строки во входном алфавите в строку в выходном. И как по вашему ФП может обходится без данных?

Сообщение от COKPOWEHEU

Может быть линия данных, но вот выделенного хранилища данных в ФП быть не должно.

Замыкания не? А монады? Вот в том то и дело - движется оно семимильными шагами в сторону ООП. По той же самой причине - спроектировать что то сложнее табулирования функции без разделения на сущности и их взаимодействия анриал.
Не верите? Ну спросите у любого адепта ФП а можно ли обойтись без стейтов и ООП? Ну единственное что он ответит - их можно эмулировать средствами ФП - т.е. обойтись нельзя. Но когда перешли к эмуляции оных то и жить оно будет по правилам статефулл ООП.

Добавлено через 1 минуту

Сообщение от COKPOWEHEU

Да, winapi настолько убогая штука, что и сравнивать бы не стоило, но раз уж начали - добьем до конца.

Ну вы хоть доку то по апи откройте и сравните. У линухи оного апи вообще почти нет.

Добавлено через 2 минуты

Сообщение от COKPOWEHEU

Если бы подтверждалось, мы бы видели всеобщее засилье С++, а не сотни языков, и постоянно возникают новые.

А плюсов и так засилье во всей разработе которую ведут квалифицированные разрабы . А новые возникают по банальной причине - фейлят лечение проблемы недопонимание задачи, их выкидывают, потому что в результате и обрубки и без лечения недопонимания задачи никому нафиг не нужны, и пытаются создать новый который типа недопонимание задачи полечет. Но ведь это невозможно в принципе. НО эффективным менеджерам этого понять не дано.

@COKPOWEHEU · 08.07.2020, 15:10

Сообщение от Fulcrum_013

Хоть теперь разница понятна?

Вы хоть сами то поняли какой бред несете?

Значит непонятна. Жаль.

Сообщение от Fulcrum_013

Вся процедурщина в которой более одной процедуры - это все то же ООП

Угу. А уж если сказать, что в процедурных языках неявно передается "объект" глобального состояния, так и вовсе ООП станет!

Сообщение от Fulcrum_013

Еще раз формула процедурного программирования программы = алгоритмы + процедуры. Процедурщина отличается исключительно отсутсвием поддержки оного

Не, я уже привык что вы не читаете что сами пишете, но все же.
Алгоритмы и процедуры у вас это кардинально разные вещи. "Процедурщина отличается отсутствием поддержки оного", причем ничего подходящего под это "оное" в тексте нет.
Не нервничайте так сильно, все равно от вас не ждут что вы что-то умное скажете. Но хотя бы когда говорите чушь, старайтесь чтобы хоть понятно было, какую именно чушь говорите.

Сообщение от Fulcrum_013

Вот в том то и дело - движется оно семимильными шагами в сторону ООП. По той же самой причине - спроектировать что то сложнее табулирования функции без разделения на сущности и их взаимодействия анриал.

Для вас, то есть человека от программирования далекого - несомненно.

Сообщение от Fulcrum_013

Ну спросите у любого адепта ФП а можно ли обойтись без стейтов и ООП?

На том же Labview как-то обходятся. Сам "язык", конечно, ужасный, но идея довольно интересная.

Сообщение от Fulcrum_013

Ну вы хоть доку то по апи откройте и сравните

Я - не вы, из пальца что попало не высасываю.
Каждый раз, когда надо написать мало-мальски кроссплатформенную программу (этот термин обозначает, что она должна запускаться на нескольких операционных системах, в моем случае Linux + Windows), как раз приходится открывать документацию к winapi. И, естественно, плеваться от того насколько там все криво и неудобно.
Не верите? Тогда попробуйте решить простенькую задачу - открыть анонимный канал (pipe) между процессом и его потомком, чтобы обмен не блокировался при опустошении. То есть, скажем, потомок пытается из канала читать, а там пусто - он должен понять что там пусто и продолжать свою работу.

Сообщение от Fulcrum_013

А новые возникают по банальной причине - фейлят лечение проблемы недопонимание задачи, их выкидывают, потому что в результате и обрубки

Конечно, куда ж им без мудрого руководства Fulcrum_013'а, скоро совсем загнутся.
Но если вы надеетесь, что за потоком вашего сознания я забуду про вопросы - напрасно:

Сообщение от COKPOWEHEU

То что и называется kernel-ом - ядро ос. Т.е. та часть которая работает в нулевом кольце - а именно диспетчер памяти, планировщик задач, система виртуализауии устройств, загрузчик прикладных программ и драйверов.

Нет-нет-нет, вы ссылку приведите, чтобы можно было посчитать строки кода.

Сообщение от COKPOWEHEU

Так что там со скоростями роста ядер разных ОС?
Что со ссылкой на "правильное" по вашему мнению ядро?
Что с объемом дистрибутивов, функционалом и требованиями?
Что с требованиями к языкам, включающим различную квалификацию программистов (а то и не-программистов)?

Сообщение от COKPOWEHEU

Мы ведь говорим о десктопном применении двух ОСей общего назначения, с приблизительно равным общим функционалом.
Вы предложили сравнивать "изкоробочные" данные - я готов, озвучьте объем, функционал и требования актуальной винды сразу после установки.
Можно сравнить "сферический в вакууме" компьютер офисного планктона, которому нужны разве что Офис, браузер, смотрелки картинок да pdf-ок.
Можно и дальше усложнять задачи специфичным софтом, но это перерастет уже в сравнение софта, а не операционок.

@Fulcrum_013 · 08.07.2020, 16:19

Сообщение от COKPOWEHEU

Угу. А уж если сказать, что в процедурных языках неявно передается "объект" глобального состояния, так и вовсе ООП станет!

Речь сейчас не о глобальных состояниях которые в языках с поддержкой ООП точно так же доступны как и в чисто процедурных.
Речь о том что нечто в духе

C
1
2
3
4
5
6
7
struct Foo {
   int Bar;
   int Baz;
};
int Foo_GetTotal(const *Foo){
      return Foo->Bar + Foo->Baz;
}

Это уже не процедурщина. Это ООП, с костыльной реализацией процедурными средствами. И никакой другой процедурщины не существует в принципе.

Добавлено через 5 минут

Сообщение от COKPOWEHEU

То есть, скажем, потомок пытается из канала читать, а там пусто - он должен понять что там пусто и продолжать свою работу.

Оверлаппед чтение не никак?

Добавлено через 7 минут

Сообщение от COKPOWEHEU

На том же Labview как-то обходятся.

В том то и дело что никак. Это всего лишь средство сборки иерархии объектов из предварительно реализованной библиотеки классов и не более того.

Добавлено через 9 минут

Сообщение от COKPOWEHEU

Я - не вы, из пальца что попало не высасываю.

А откуда?
Где к примеру в апи линухи аналог библиотеки контролов? или хотя бы где в их недоокнах багажник под пользовательский указатель?

Добавлено через 8 минут
Кроме файлового ввода-вывода сокетов и средст винхронизации у линухи вообще ничего нет. Потоки появились и какая то пародия на динамические либы- во какое достижение. а COM/DCOM где? Или так и будете всю жизнь заниматься изобретением мульйона частных случаев маршаллинга RPC через пайп?

Добавлено через 17 минут

Сообщение от COKPOWEHEU

Для вас, то есть человека от программирования далекого - несомненно

Эт для вас, человека абсолютно не знакомого даже с самыми азами специальности, неочевидно,что методология проектирования и способ реализации в коде - это далеко не одно и то же. Одним и тем же оно становится только тогда когда язык реализации оперирует теми же абстракциями что и методология проектирования.

Добавлено через 4 минуты

Сообщение от COKPOWEHEU

Сам "язык", конечно, ужасный, но идея довольно интересная.

Точно та же что к примеру в GPSS. Вообще языки построенные по принципу "данные проходят через блоки которые выполняют их обработку" - это ранние попытки построить системы по принципу событийного управления. Полноценный же переход к событийному управлению дал только полный и осознанный переход именно к ООП.
К примеру финальная сборка в той же дельфе (та часть которая называется формошлепством) делается точно так же. Отличия только в том что дельфа имеет еще и полноценные средства расширения библиотеки компонентов из которых производится финальная сборка. Поэтому и является универсальным языком в отличии от всяких GPSS и LabView, которые не более чем специализированные вспомогательные узконишевые средства. Но как бы сама концепция специализированных языков давно почила в бозе - фактически последними гвоздями в ее доску стало появление С и виртовского паскаля.

@COKPOWEHEU · 08.07.2020, 16:33

Сообщение от Fulcrum_013

И никакой другой процедурщины не существует в принципе.

Ах вон оно как далеко зашло! То есть существует идеальный язык - С++, существует идеальный стиль программирования - ООП. А все остальные только неумело косплеят, потому что дураки.

Сообщение от Fulcrum_013

Оверлаппед чтение не никак?

Вы код-то продемонстрируйте. Заодно хотя бы поверхностно ознакомитесь со своей священной коровой.

Например, в Линуксе можно сделать так

C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
#include <stdio.h>
#define __USE_GNU
#include <fcntl.h>
#include <unistd.h>
 
int main(){
  int fd[2];
  pipe2(fd, O_NONBLOCK);
  
  char buf[100] = "abcd";
  int res;
  //проверяем обычный обмен
  write(fd[1], "12345", 6);
  res = read(fd[0], buf, 6);
  printf("%i: [%s]\n", res, buf);
  //выводит в консоль
  //6: [12345]
  
  //проверяем когда буфер пуст:
  res = read(fd[0], buf, 6);
  printf("%i: [%s]\n", res, buf);
  //выводит в консоль
  //-1: [12345]
  
  close(fd[0]);
  close(fd[1]);
}

Найти человеческого решения через winapi мне не удалось, пришлось городить костыль.

Сообщение от Fulcrum_013

На том же Labview как-то обходятся.

В том то и дело что никак. Это всего лишь средство сборки иерархии объектов из предварительно реализованной библиотеки классов и не более того.

А, ну то есть опять "я этого не видел, но раз не С++, то недо-язык, не пригодный ни для чего".

Сообщение от Fulcrum_013

Где к примеру в апи линухи аналог библиотеки контролов?

Вы спрашиваете где в ядре операционной системы библиотеки графических компонентов? А, простите, какие вещества надо принимать чтобы такой вопрос вообще возник?
А, я понял! Вам надо провести ликбез что такое ядро операционной системы и чем оно отличается от оболочки. Если вкратце, ядро управляет распределением и единообразным доступом к ресурсам - памяти, процессорному времени, оборудованию. Это слой абстракции, отделяющий конкретное аппаратное обеспечение от пользовательских программ. Но пользователь с ядром не взаимодействует, для этого есть оболочки. И конкретный способ обмена информацией с пользователем зависит именно от оболочки. Это может быть консоль (в том числе подсоединяемая по последовательному порту), графическая система или, скажем, голосовое управление или нейроинтерфейс (пока что я про такое не слышал, но почему бы и нет).
А графические контролы, очевидно, имеют смысл только в рамках какой-либо графической системы, то есть оболочки. И даже там они не являются обязательными: вполне представима графическая система, в которой каждое окно самостоятельно рисует весь свой интерфейс, а оболочке выдает только готовую картинку (вроде бы wayland примерно так работает).

Сообщение от Fulcrum_013

где в их недоокнах багажник под пользовательский указатель?

Что такое "багажник под пользовательский указатель"?
Ну и традиционно не забываем напомнить вопросы:

Сообщение от COKPOWEHEU

То что и называется kernel-ом - ядро ос. Т.е. та часть которая работает в нулевом кольце - а именно диспетчер памяти, планировщик задач, система виртуализауии устройств, загрузчик прикладных программ и драйверов.

Нет-нет-нет, вы ссылку приведите, чтобы можно было посчитать строки кода.

Сообщение от COKPOWEHEU

Так что там со скоростями роста ядер разных ОС?
Что со ссылкой на "правильное" по вашему мнению ядро?
Что с объемом дистрибутивов, функционалом и требованиями?
Что с требованиями к языкам, включающим различную квалификацию программистов (а то и не-программистов)?

Сообщение от COKPOWEHEU

Мы ведь говорим о десктопном применении двух ОСей общего назначения, с приблизительно равным общим функционалом.
Вы предложили сравнивать "изкоробочные" данные - я готов, озвучьте объем, функционал и требования актуальной винды сразу после установки.
Можно сравнить "сферический в вакууме" компьютер офисного планктона, которому нужны разве что Офис, браузер, смотрелки картинок да pdf-ок.
Можно и дальше усложнять задачи специфичным софтом, но это перерастет уже в сравнение софта, а не операционок.

@Fulcrum_013 · 08.07.2020, 16:40

Сообщение от COKPOWEHEU

Найти человеческого решения через winapi мне не удалось, пришлось городить костыль.

Решение через пайп человеческими не бывают в принципе.

Сообщение от COKPOWEHEU

Что такое "багажник под пользовательский указатель"?

Банально место в дескрипторе окна, в которое можно положить указатель на свой стейт, чтобы при получении сообщения от окна не перерывать таблицу соответствия хендлов стейтам.

Добавлено через 2 минуты

Сообщение от COKPOWEHEU

Ну и традиционно не забываем напомнить вопросы:

Еще раз - ни о какой даже примерной одинаковости функциональности осей речи идти не может. Это и есть ответ на все вопросы. Винда в плане апи поставляется не то что с батарейками, а с термоядерным реактором. У линухи они отсутсвуют напрочь.

Добавлено через 1 минуту

Сообщение от COKPOWEHEU

Найти человеческого решения через winapi мне не удалось, пришлось городить костыль.

Человеческого решения данных вопросов через пайп не может быть в принципе. Он не предназначен для решения вопросов синхронизации процессов.

@COKPOWEHEU · 08.07.2020, 16:41

Сообщение от Fulcrum_013

ранние попытки построить системы по принципу событийного управления.

Вот как раз событийного управления там нет, и ничего. И развитое - весьма развитое - GUI есть, и создание новых компонентов. Фрагменты ООП, конечно, присутствуют, но именно что фрагменты.

Сообщение от COKPOWEHEU

[Ядро ОС] Это слой абстракции

Ах да, забыл уточнить: этот слой абстракции почему-то напрочь процедурный.

@Fulcrum_013 · 08.07.2020, 16:44

Сообщение от COKPOWEHEU

Вы спрашиваете где в ядре операционной системы библиотеки графических компонентов? А, простите, какие вещества надо принимать чтобы такой вопрос вообще возник?

Еще раз - в пытаетсь сравнит ядро линукс со всей виндой и говорите что это одно и тоже. Нет это априори далеко не одно и то же.
При этом только ядро линухи в котором ничего этого действительно быть не должно, давно по размерам кода превзошло всю как минимум Win2k - т.е. и примерно аналогичное ядро и все эти апи, и еще кучу всего чего в линухе вообще нет от слова совсем.
О чем и речь - продуктивность С крайне низка по сравнению с плюсами, именно потому что реализация на С требует на порядки больше кода чем на плюсах. Разницы же в проектировании того что реализовывать нет в принципе. Не забывайте что постановка задачи от языка реализации не зависит от слова совсем, и для такой штуки как ядро офисной ОС постановка плюс/минус одинакова.

@COKPOWEHEU · 08.07.2020, 16:50

Сообщение от Fulcrum_013

Решение через пайп человеческими не бывают в принципе.

Тем не менее, приведено вполне человеческое решение. Как там ваш вариант с Overlapped поживает?

Сообщение от Fulcrum_013

[пайп]Он не предназначен для решения вопросов синхронизации процессов.

Ну разумеется, средство асинхронного обмена не предназначено для синхронизации. Вот так новость!

Сообщение от Fulcrum_013

Банально место в дескрипторе окна, в которое можно положить указатель на свой стейт, чтобы при получении сообщения от окна не перерывать таблицу соответствия хендлов стейтам.

Если речь про коллбэки, то, скажем, в gtk можно передать вообще что угодно. В моем проекте передается объект Lua (последним аргументом):

C
1
g_signal_connect(G_OBJECT(btn->obj), "clicked", G_CALLBACK(BtnOnClick), btn);

Сообщение от Fulcrum_013

Еще раз - ни о какой даже примерной одинаковости функциональности осей речи идти не может. Это и есть ответ на все вопросы.

Еще раз: не хотите сравнивать ядро - ладно, можем сравнить дистрибутив с примерно равным функционалом: Офис, браузер, смотрелки картинок и pdf'ок. Хотя бы на это ваша винда способна?

Сообщение от Fulcrum_013

Винда в плане апи поставляется не то что с батарейками, а с термоядерным реактором.

Так вот оно в чем дело! Майкрософты вкорячили туда термоядерный реактор, который так ни у кого и не получилось запустить, так что оно и не работает, и весит многие тонны, да еще и ломается постоянно.
У вас как обычно - хотели выпендриться, а в результате очередное хореографическое сальто в лужу.

@Fulcrum_013 · 08.07.2020, 16:52

Сообщение от COKPOWEHEU

Вот как раз событийного управления там нет, и ничего.

Вы вообще понимаете что такое событийное управление хотя бы приблизительно? Поступление данных на вход блока - это как раз и есть событие. Передача обработанного буфера следующему блоку - тоже событие. Так что идите учите азы, не порите чушь.

@COKPOWEHEU · 08.07.2020, 16:53

Сообщение от Fulcrum_013

реализация на С требует на порядки больше кода чем на плюсах

У вас сегодня обострение капитанства? Реализация на более низкоуровневом языке требует больше кода, чем на более высокоуровневом. Вот так новость номер два!

Добавлено через 1 минуту

Сообщение от Fulcrum_013

Вы вообще понимаете что такое событийное управление хотя бы приблизительно? Поступление данных на вход блока - это как раз и есть событие. Передача обработанного буфера следующему блоку - тоже событие.

Изучите уже матчасть, хватит позориться. Предыдущие два плюха - с объемом ядерного кода и с термоядерным реактором были красивые, а этот как-то слабоват.

@Fulcrum_013 · 08.07.2020, 16:56

Сообщение от COKPOWEHEU

У вас сегодня обострение капитанства? Реализация на более низкоуровневом языке требует больше кода, чем на более высокоуровневом. Вот так новость номер два!

У вас уже С стал более высокоуровневым чем C++? Вы опять забыли лекарство принять?

Добавлено через 2 минуты

Сообщение от COKPOWEHEU

Изучите уже матчасть, хватит позориться

Вот действительно идите и учите. Для начала хотя бы вкратце ознакомьтесь с моделью акторов на которой построено и ООП и языки на подобие GPSS. Событийное управление - это одна из оптимизаций ее реализации.

@COKPOWEHEU · 08.07.2020, 17:32

Сообщение от Fulcrum_013

У вас уже С стал более высокоуровневым чем C++? Вы опять забыли лекарство принять?

И снова вы пытаетесь меня по себе судить, и снова мимо.
Могу повторить крупными буквами для тех, у кого со зрением проблемы:
Реализация на более низкоуровневом языке требует больше кода, чем на более высокоуровневом. Если проблемы не со зрением, а с восприятием письменного текста, поясню: Си более низкоуровневый, чем С++, поэтому объем кода на Си больше, чем на С++.

Сообщение от Fulcrum_013

Еще раз - в пытаетсь сравнит ядро линукс со всей виндой и говорите что это одно и тоже.

Вам напомнить кто привел ту ссылку на википедию? Мало того, по ней же можно сделать вывод о темпах роста.
На случай очередного выверта про "встроенные драйвера" тоже можем провести эксперимент.
--

Еще раз: не хотите сравнивать ядро - ладно, можем сравнить дистрибутив с примерно равным функционалом: Офис, браузер, смотрелки картинок и pdf'ок. Хотя бы на это ваша винда способна?

Оверлаппед чтение не никак?

Вы код-то продемонстрируйте. Заодно хотя бы поверхностно ознакомитесь со своей священной коровой.

@Fulcrum_013 · 08.07.2020, 18:23

Сообщение от COKPOWEHEU

Вам напомнить кто привел ту ссылку на википедию?

Ну и? Есть два способа сравнить продуктивность - первый меряем строки кода на одну и ту же функциональность. Но надеюсь очевидно что в данном случае он не доступен - по винде есть информация только по всей оси по линухе только по ядру. Значит остается только второй - смотрим где есть примерно одинаковое количество строк и сравниваем функциональность.
При этом априори функциональность ядра всегда на порядки меньше функциональности целой оси на подобном ядре.
Имеем - ядро линухи переросло размер оси ,которая по функциональности первосходит всю линуху на голову, не говоря уже о только ядре.
Вы же как всегда несете ахинею про какое то сравнение мягкого с холодным.

Добавлено через 1 минуту
COKPOWEHEU, Вы сравнение дробей в начальной школе проходили? Ну вот пойдите и повторите. А то так и не поймете как сравнить дроби строк кода/функциональность

Добавлено через 6 минут
COKPOWEHEU, Или вы просто настолько безграмотны что не можете понять разницу между ядром ос и дистрибутивом ос?

@VTsaregorodtsev · 08.07.2020, 19:15

Сообщение от COKPOWEHEU

Если речь про коллбэки

Нет, Фулькрум скорее всего имел в виду вызовы Set/GetWindowLong() с флагом GWL_USERDATA.
И/или Set/GetWindowWord(), если предварительно при регистрации класса окна (WNDCLASS+RegisterClass()) задавать классу ненулевое (а дефолтно оно там нулевое) значение поля структуры, отвечающего за размер пользовательского буфера у каждого экземпляра окна этого класса.

Сообщение от Fulcrum_013

Банально место в дескрипторе окна, в которое можно положить указатель на свой стейт, чтобы при получении сообщения от окна не перерывать таблицу соответствия хендлов стейтам.

Я думаю

, что в Винде окон (в т.ч. в виде диалоговых элементов - кнопок и т.д.) суммарно гораздо больше, чем связанных с окнами "объектов" в отдельной проге.
Т.е. самомУ по отдельно и специально созданной таблице соответствия хэндлов окон стейтам=объектам пробежаться будет быстрее, чем отдавать эту операцию Винде.
Ибо хоть я и не мерял скорость работы указанных выше ВинАПИшных функций - но не наблюдаю в их логике указание на то, что они имеют ограничение области работы в виде перебора окон только некоторой проги (из потока которой они вызваны).
Так что тут ВинАПИ просто может давать облегчение работы программиста за счёт возможных тормозов. Особенно если в оконную функцию пойдёт достаточно активный поток событий, а доставать ссылку/индекс объекта прогер решит однократно (т.е. непосредственно перед свитчом выбора обрабатываемых сообщений) - т.е. будет доставать ссылку и для всех тех ненужных сообщений, обработка которых затем отправится в DefWindowProc().

@Fulcrum_013 · 08.07.2020, 20:28

Сообщение от VTsaregorodtsev

Я думаю , что в Винде окон (в т.ч. в виде диалоговых элементов - кнопок и т.д.) суммарно гораздо больше, чем связанных с окнами "объектов" в отдельной проге.

Эт очень зря думаете. В любом фреймверке каждому окну/пункуту меню и т.д. элементу гуя соответсвует объект фреймверка. При этом хендл в получаемом событии - именно хендл конкретного элемента а не содержащего его окна топ уровня. Немного по другому только у пунктов менюшек, но они как бы по определению не разу не окна.

Добавлено через 6 минут

Сообщение от VTsaregorodtsev

Нет, Фулькрум скорее всего имел в виду вызовы Set/GetWindowLong() с флагом GWL_USERDATA.

Именно об использовании багажника для диспетчеризации событий вот в таком духе

C++
1
2
3
4
5
6
7
8
9
10
11
static LRESULT CALLBACK WndProc(HWND Handle, UINT Mes, WPARAM wParam, LPARAM lParam) {
            WindowHandle hWnd{ Handle };
            if (Mes == WM_CREATE) {
                TWindow* Window = (TWindow*)((CREATESTRUCT*)lParam)->lpCreateParams;
                hWnd.UserData(Window);
                Window->HandleCreated(Handle);
                return DefWindowProc(Handle, Mes, wParam, lParam);
            }
            TWindow* Window = (TWindow*)hWnd.UserData();
            return Window ? Window->WndProc(Mes, wParam, lParam) : DefWindowProc(Handle, Mes, wParam, lParam);
        }

Добавлено через 6 минут

Сообщение от VTsaregorodtsev

но не наблюдаю в их логике указание на то, что они имеют ограничение области работы в виде перебора окон только некоторой проги

У них абсолютно другая логика работы. И поиск адресата у них априори O(1). Т.е. к примеру для определения на каком именно окне находится курсор не надо пробегать все дерево. Достаточно разделить топ-окно на зоны и ловить переход через их границы. Это даст при движении мыши O(1) при типа курсор упал с неба Log(n). Если же пойти дальше и сделать маску с ID то там O(1) в любом наборе. Какой из этих способов у винды под капотом точно не известно, но по всей видимости первый - и мышь с неба падает (т.е. преставляется принудительно в заданные координаты) редко и по памяти оверхед вообще незначительный. Хотя при аппаратной отрисовке может быть логичным и второй - цвет то RGB а выравнивают пикселы все равно на 32, так что место на 256 id есть априори.
По событиям же не связанным с мышиной возней нахождение адресата O(1) априори.

Добавлено через 32 минуты

Сообщение от VTsaregorodtsev

Так что тут ВинАПИ просто может давать облегчение работы программиста за счёт возможных тормозов.

И опять вы ошибаетесь. Что в винде что в линухе в качестве адресата приходит хендл окна, а не хендл его топ-парента.
Т.е. как результат наличие багажника у винды позволяет диспетчеризировать событие на стороне получателя за O(1),
в линухе же потребуется Log( n ) поверх того, что потратила ось на своей стороне на определение адресата. С учетом того что все кроме мыши на стороне оси O(1) по определению, а O(1) (или хотя бы O(1) в подавляющем большинстве случаев) на стороне оси достижимы и для беготни грызуна - то отсутсвия багажника в линуксе как дает существенное пенальти по производительность диспетчеризации, так и резко снижает продуктивность программист при создании подсистемы диспетчеризации на принимающей события стороне, особенно если городить все эти подписки/отписки в мап на голом С.

Добавлено через 22 минуты
Вывод: разрабам линукса не мешало бы хотя бы базовые курсы подготовки программистов пройти, а не фапать де Майкрософт всех купил потому и такой процент распространенности у винды.

Новые блоги и статьи Все статьи Все блоги /
Nekobox - outbounds[0].transport: unknown transport type: raw damix 01.10.2026 Фикс ошибки Правым кликом по серверу -> отладочная информация -> edit Заменить "net": "raw", на "net": "tcp", Нажать кнопку reload.	Программный домашний кинотеатр russiannick 27.09.2026 Сподобился на программный домашний кинотеатр. В качестве ЯВУ по традиции выбрал js. В помощники взял Яндекс-Алису. Было создано три зала на разные интересы. исторические и ретро сериал Хичкок. . .	Беседа с ИИ о программистах, недопускающих к созданию и правке кода генеративные ИИ и причины этого zorxor 21.09.2026 Раньше я радовался или получал некоторые эмоции, пусть небольшие, но всё же, от самого процесса написания кода, рекомпиляции и запуска, видя постепенное развитие программы и прочее. А теперь лень. . .	Мобильное приложение ColorStep pavlinmavlin 17.09.2026 Реализовал приложение Красный, Зеленый, Синий в Unity3d + c#. Название изменил на ColorStep. Приложение прошло модерацию и теперь доступно для скачивания. Делал его сам, шаг за шагом — и вот,. . .
Запрет дублирования строк в табличной части Maks 13.09.2026 Реализация из решения ниже выполнена на нетиповом справочнике "Нормы ТО" с табличной часть "Виды ТО", разработанного в КА2, со следующими реквизитами: - ВидТО (СправочникСсылка. ВидыТО); - ВидГСМ. . .	Скрипты Tampermonkey для CyberForum, ChatGPT, Claude и пр. Jin X 06.09.2026 Скрипты Tampermonkey для CyberForum, ChatGPT, Claude и пр. Работая с форумом и нейросетями в браузере часто хочется что-то подкорректировать или добавить какого-то функционала. Ниже прикреплён. . .	Программа опроса у.з. расходомера SLS-720F Argus19 02.09.2026 Программа опроса у. з. расходомера SLS-720F Программа опрашивает один раз в минуту три ультразвуковых расходомера SLS-720F через интерфейс RS-485 по протоколу Modbus RTU. Опрашиваются регистры. . .	Hyper-V: Компьютер должен поддерживать доверенный платформенный модуль 2.0. Maks 31.08.2026 При установке Windows 11 на виртуальную машину Hyper-V 2-го поколения вылезла такая ошибка: Решение: в параметрах виртуальной машины, в разделе "Безопасность" (Security) активировать флаг. . .

@ReYalp 63 / 46 / 11 Регистрация: 27.12.2017 Сообщений: 1,484

	Rust vs C++ 26.06.2020, 16:10. Показов 49544. Ответов 660 Метки нет (Все метки) Кто-то писал на Rust? Стоит ли начинать учить? Насколько Rust хуже/лучше С++? 0

@COKPOWEHEU 4150 / 2728 / 433 Регистрация: 09.09.2017 Сообщений: 12,087
	08.07.2020, 10:57
	korvin_, имеется в виду, что они существуют только между функциями, в неявном виде. Может быть линия данных, но вот выделенного хранилища данных в ФП быть не должно. 0