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 минуты
Вывод: разрабам линукса не мешало бы хотя бы базовые курсы подготовки программистов пройти, а не фапать де Майкрософт всех купил потому и такой процент распространенности у винды.

Новые блоги и статьи Все статьи Все блоги /
Мобильное приложение 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) активировать флаг. . .	Архитектура биовида Стива в Майнкрафте: Зачем бонобо кубический каннибализм anaschu 30.08.2026 Кубический Вагинокапитализм в Minecraft: Математический инвариант ОДУ и рок Стивов-бонобо Главная задача разработанной «Модели Всего» — наглядно продемонстрировать наличие системной «судьбы». . .	Оттачиваю умение писать js программы. russiannick 30.08.2026 Проектом выходного дня стало написание Книги шифров Виженера. Итогом стала версия 200, синий туман. Синий туман назван так, потому что замораживает текст под собой. Нажатие синих кнопок управляют. . .	мат медиц модель 30. презентация проекта anaschu 27.08.2026 хоп хоп хоп хидахоп, а я кладую))

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

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

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