Rust vs C++

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

0

Сообщение от Fulcrum_013 Ну и?

Ну и зачем вы тогда привели эту ссылку? Хотели показать что якобы объем линукса растет быстрее, чем винды - не вышло. Зато появился встречный вопрос: почему у линукса при меньшем объеме исходников функционал настолько больше?

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

Желаете предложить более простой и корректный способ сравнения функционала, требований и объема?

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

Да на эту-то тему он уже сам признал что слился: из линукса он теперь хочет брать для сравнения только ядро, в котором не то что окон, но и графики нет, а из винды "изкоробку".

Сообщение от Fulcrum_013 Это даст при движении мыши O(1) при типа курсор упал с неба Log(n).

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

Сообщение от Fulcrum_013 Хотя при аппаратной отрисовке может быть логичным и второй - цвет то RGB а выравнивают пикселы все равно на 32, так что место на 256 id есть априори.

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

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

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

0

Сообщение от COKPOWEHEU Ну и зачем вы тогда привели эту ссылку?

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

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

Сообщение от COKPOWEHEU Учитывая, что существуют планшеты, где курсор именно что "падает с неба", а после слоя абстракции уже невозможно определить откуда он взялся.

Параллельно с отрисовкой рабочего стола рисуем в стенсил/второй таргет маску id контролов. При нажатии/телодвижении путем лукапа по координате в этом втором таргете получаем id адресата за O(1). Всего то. Во всю используется лет 20 а то и больше там где геометрия не обязательно выровняна по x/y - т.е. графические редакторы, всякие маски объектов под капотом у браузера и т.д. и т.п. подобные дела. Вам бы действительно азам подучится. А то морозите глюпости на каждом шагу.

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

Сообщение от COKPOWEHEU И кстати, если уж утверждаете что обмен через pipe внезапно устарел (хотя с чего бы), то что бы использовали вы если бы занимались разработкой многопоточных программ?

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

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

Сообщение от COKPOWEHEU Вместо простого математического алгоритма предлагаете отрисовать вообще все окна по второму разу, придумать алгоритм назначения цветов, да еще и анализ. Бр-р-р.

Это тоже простой математический алгоритм. Вообще все алгоритмы исключительно математические. При этом вычислительная сложность для такого алгоритма значительно ниже. Это называется оптимизация по скорости за счет памяти. Вообще оптимизация алгоритмов бывает либо по памяти за счет скорости, либо по скорости за счет памяти. C учетом того что в рамках обработки этих дел на стороне оси можно иметь одну маску на весь десктоп и строить ее параллельно с отрисовкой изображения (по факту алгоритмически аналогично добавлению id в структуру пиксела), то это гораздо проще и производительней беготни по деревьям, особенно в случае когда контролы могут быть непрямоугольной формы/не выровняны по осям.

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

Сообщение от COKPOWEHEU И кстати, если уж утверждаете что обмен через pipe внезапно устарел (хотя с чего бы), то что бы использовали вы если бы занимались разработкой многопоточных программ?

А постановка задачи будет или как? А то телепат в отпуске.

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

Сообщение от COKPOWEHEU из линукса он теперь хочет брать для сравнения только ядро,

Берем те элементы по которым есть данные для сравнения. Найдете данные по ядру винды - ради бога сравним именно с ними - ядра как раз по функциональности примерно равны.

Добавлено через 12 минут
Но надеюсь понимаете что размер кода ядра у винды будет в единицах процентов от размера кода дистрибутива? При этом начиная с хрюшки где в дистрибутив добавили Net Framework этот процент начнет резко падать.

0

Сообщение от Fulcrum_013 Ну там явно все видно

Да уж видно. Что вы облажались, а теперь пытаетесь пустыми оскорблениями выкрутиться.

Сообщение от Fulcrum_013 Параллельно с отрисовкой рабочего стола рисуем в стенсил/второй таргет маску id контролов.

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

Сообщение от Fulcrum_013 Вам бы действительно азам подучится.

Если бы вы это сказали первый раз - было бы смешно, сейчас уже надоело.

Сообщение от Fulcrum_013 Вы разницу между устарел и не предназначен для синхронизации вообще не видите чтоли?

Вы разницу между асинхронным каналом и синхронизацией не вообще не видите что ли?

Сообщение от Fulcrum_013 При этом область применения пайпа - исключительно передача неструктурированных raw-данных, что исключительная редкость. Большая часть обмена между приложениями - это таки RPC как ни крути.

О конвейере вы тоже не слышали, понятно. И о TCP, который по сути тот же канал, тоже.
Но от темы не уходите - сколько строк кода займет пересылка данных (ладно, можно не потоком, а пакетом) между двумя потоками?

Сообщение от Fulcrum_013 Это тоже простой математический алгоритм. Вообще все алгоритмы исключительно математические.

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

Сообщение от Fulcrum_013 А постановка задачи будет или как? А то телепат в отпуске.

см. выше - передать сколько-то данных с проверкой их существования. Или вам для абстрактной промежуточной задачи нужно сказку написать?

Сообщение от Fulcrum_013 Но надеюсь понимаете что размер кода ядра у винды будет в единицах процентов от размера кода дистрибутива? При этом начиная с хрюшки где в дистрибутив добавили Net Framework этот процент начнет резко падать.

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

0

Сообщение от COKPOWEHEU Параллельно это не работает - только последовательно.

Ага щаз. Stencil Buffer не? Его размер можно любым делать. Второй таргет не? Знали бы хоть что то глупостей бы не морозили.

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

Сообщение от COKPOWEHEU Не угадали.

Да то вы не угадали. Алгоритм - это вообще такая математическая фича которая родилась вместе с алгеброй. Еще раз - азы сначала освойте, будете знать а не гадать.

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

Сообщение от COKPOWEHEU Но для банальных окошек, особенно на ОС общего назначения

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

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

Сообщение от COKPOWEHEU это крайне неэффективный подход

Очень даже эффективный. Оверхед по памяти никак не более 2x.

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

Сообщение от COKPOWEHEU Лично у меня нет никакой информации о ядре винды

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

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

Сообщение от COKPOWEHEU между двумя потоками

Нисколько. Потоки живут в одном адресном пространстве если вы этого до сих пор не знаете.

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

Сообщение от COKPOWEHEU О конвейере вы тоже не слышали, понятно. И о TCP, который по сути тот же канал, тоже.

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

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

Сообщение от COKPOWEHEU И о TCP, который по сути тот же канал, тоже.

А о том что маршаллинг RPC может быть универсальным, а не костыльным на каждый частный случай, и не зависимым от канала вы слышали? А про то что канал - наиболее неэффективный способ обменна данными в пределах одного компа?

0

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

Верю!
Верю, что если на ВинАПИ с помощью передаваемых в CreateWindow() флагов создать окно с вертикальной/горизонтальной полосами прокрутки - то затем в оконную функцию при сообщениях WM_HSCROLL/WM_VSCROLL будет приходить хэндл именно полосы прокрутки (как текущего жмакаемого мышой элемента гуя), а не хэндл всего окна (окна топ-уровня).
А при сворачивании/разворачивании окна через кнопки в правом верхнем углу (т.е. при событиях WM_MINIMIZE/WM_MAXIMIZE) будут приходить хэндлы именно этих кнопок.
Так что не надо ля-ля про

Сообщение от Fulcrum_013 именно хендл конкретного элемента а не содержащего его окна топ уровня.

1

Сообщение от VTsaregorodtsev Верю, что если на ВинАПИ с помощью передаваемых в CreateWindow() флагов создать окно с вертикальной/горизонтальной полосами прокрутки - то затем в оконную функцию при сообщениях WM_HSCROLL/WM_VSCROLL будет приходить хэндл именно полосы прокрутки (как текущего жмакаемого мышой элемента гуя), а не хэндл всего окна (окна топ-уровня).

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

0

Сообщение от Fulcrum_013 Да то вы не угадали. Алгоритм - это вообще такая математическая фича которая родилась вместе с алгеброй

Пошли натягивания совы на глобус. Уже алгоритм как логику работы программы приводят к математическому алгоритму. Нет, если очень постараться, то натянуть можно, вот только смысла в этом никакого.

Сообщение от Fulcrum_013 Окошки могут быть повернуты, могут иметь любой шейп в том чиcле не выпуклый. Вы вообще комп давно видели? А то живете реалиями псевдографияечких интерфейсов 80-х.

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

Сообщение от Fulcrum_013 Знаний что такое ядро по всей видимости тоже нет и близко.

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

Сообщение от Fulcrum_013 А осбенно с учетом того что у винды в дистрибутив напихано куча всего что ни к ядру ни к апи ни к утилитам управления ни малейшего отношения не имеет - веб сервер, SQL сервер и еще куча всего.

Да хватит уже изворачиваться! Объем дистрибутива, решающего простейшие пользовательские задачи сколько весит и на каком железе будет нормально работать?

Сообщение от Fulcrum_013 Нисколько. Потоки живут в одном адресном пространстве если вы этого до сих пор не знаете.

А, то есть вы внутри одного адресного пространства будете дергать какие-то данные из разных потоков без асинхронного обмена и без средств синхронизации?
Хотя нет, вы - не будете. Ни асинхронно, ни как-либо еще, это ведь за клавиатуру сесть надо, писать страшные буковки.

Сообщение от Fulcrum_013 Вопрос не в канале а в логике которую пытаетесь реализовать. С огромной вероятностью пайп для нее не подходит.

Опять пошли взятые с потолка проценты - лишь бы не отвечать по существу.

Сообщение от Fulcrum_013 А про то что канал - наиболее неэффективный способ обменна данными в пределах одного компа?

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

Сообщение от VTsaregorodtsev Верю, что если на ВинАПИ с помощью передаваемых в CreateWindow() флагов создать окно с вертикальной/горизонтальной полосами прокрутки - то затем в оконную функцию при сообщениях WM_HSCROLL/WM_VSCROLL будет приходить хэндл именно полосы прокрутки (как текущего жмакаемого мышой элемента гуя), а не хэндл всего окна (окна топ-уровня).

Ну, на самом деле оно именно так и работает. Не уверен на счет winapi, но в современных графических средах - так. И если контролы принадлежат оконной системе, разумеется. Если вы их нарисовали поверх окна, не уведомляя оболочку, естественно, она о них не узнает.

Сообщение от VTsaregorodtsev А при сворачивании/разворачивании окна через кнопки в правом верхнем углу (т.е. при событиях WM_MINIMIZE/WM_MAXIMIZE) будут приходить хэндлы именно этих кнопок.

Вот тут не уверен, по-разному делают. В некоторых окном (в том числе заголовком и кнопками) управляет само окно, в других - графическая система.

0

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

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

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

Сообщение от COKPOWEHEU Да хватит уже изворачиваться

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

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

Сообщение от COKPOWEHEU без средств синхронизации

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

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

Сообщение от COKPOWEHEU Опять пошли взятые с потолка проценты - лишь бы не отвечать по существу.

Ну вот вы и не хотите по существу отвечать какую логику обмена между процессами нужно организовать. Да и вообще не факт что там нужны дочерние процессы.

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

Сообщение от COKPOWEHEU почему оно не вытеснило предшественника

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

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

Сообщение от COKPOWEHEU , то есть вы внутри одного адресного пространства будете дергать какие-то данные из разных потоков без асинхронного обмена и без средств синхронизации?

А вы пайп что ли как средство синхронизации использовать пытаетесь? Где вы такую прущую траву берете?

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

Сообщение от COKPOWEHEU писать страшные буковки

Еще и латниницей. Вам наверно там ужасть как страшно.

0

Сообщение от Fulcrum_013 Вопрос в том что должна обеспечить ось и как это проще/быстрее и т.д. сделать. Именно так.

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

Сообщение от Fulcrum_013 Важно то что линуха на стороне получателя заставляет костылить еще один поиск, при этом абсолютно не нужный.

Доказательства будут или как обычно "я так нафантазировал, значит так и есть"?

Сообщение от Fulcrum_013 НУ вот вы и пытаетесь изворачиваться

То есть ответа в очередной раз нет, только попытки перевести стрелки. Это так не работает.

Сообщение от Fulcrum_013 А вы пайп что ли как средство синхронизации использовать пытаетесь?

Это не я, это некий Fulcrum_013 пытается этим заниматься. То он HTML в языки программирования записывал, то скрипты из них выносил, теперь вот каналы (асинхронные средства передачи данных) зачем-то средствами синхронизации называет. И, что самое обидное, веществами не делится!

Сообщение от Fulcrum_013 лишь бы не отвечать по существу. Ну вот вы и не хотите по существу

И снова вместо ответа попытки демагогии. Задача и пример решения приведены были.

Сообщение от Fulcrum_013 Или вы с линукса свалились

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

Сообщение от Fulcrum_013 Еще и латниницей.

Так вот почему вы их не пишете! Я-то думал, вы просто не предрасположены к алгоритмическому мышлению, а оказывается, буковки отпугивают.
---
Очередная попытка вернуть Fulcrum_013 к реальному миру:
Сравнение языков программирования:
- почему божественные плюсики не вытеснили все остальные языки из всех ниш, если она их во всем превосходит?
- каков объем кода, реализующего асинхронный обмен данными между двумя потоками? Поскольку сложность реализации такого базового функционала, как каналы, вы уже и сами подозреваете, сжалюсь и оставлю выбор типа данных и способа обмена за вами.
- почему парадигма ООП не вытеснила все остальные, если она так хороша? Почему до сих пор существуют процедурные, функциональные языки? Естественно, элементы ООП в них могут встречаться, все же это реальные языки, а не декоративные.
Сравнение операционных систем:
- признаете ли вы, что рост винды гораздо больше похож на экспоненту, чем линукса? Исключительно по вашим же данным.
- Каков объем и системные требования дистрибутива винды, решающего самый базовый класс задач - ползанье по интернету, работу в офисной программе, просмотр картинок, видео и pdf? Естественно, там в ядре куча лишнего мусора - ну так озвучьте, какие задачи он помогает решать.

0

Сообщение от COKPOWEHEU Поэтому обычно и делается через XXYY с соответствующей логарифмической сложностью.

Давно так никто не делает. Но опять же в данном ключе это не важно. Это только один тип события из тысяч, и это забота оси которую оно все равно выполни. Вопрос о том что происходит на стороне получателя.

Сообщение от COKPOWEHEU Доказательства будут или как обычно "я так нафантазировал, значит так и есть"?

Вы лекарство от скрлероза принять забыли? Напомню суть вопроса - у виндового дескриптора окна есть багажник под указатель на пользовательские данные, у x11 нет от слова совсем - т.е. поиск стейта по хендлу.

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

Сообщение от COKPOWEHEU То он HTML в языки программирования записывал,

Это вы их записали в языки программирования.

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

Сообщение от COKPOWEHEU теперь вот каналы (асинхронные средства передачи данных) зачем-то средствами синхронизации называет

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

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

Сообщение от COKPOWEHEU Отчего же свалился, это основная рабочая система.

Ну потому что отстали от жизни лет на 30.

Сообщение от COKPOWEHEU почему божественные плюсики не вытеснили все остальные языки из всех ниш, если она их во всем превосходит?

В профессиональной разработке плюсы давно занимают доминирующее положение.

Сообщение от COKPOWEHEU каков объем кода, реализующего асинхронный обмен данными между двумя потоками?

Никакой. Потоки живут в одном адресном пространстве. Еще раз - прочитайте в конце концов в чем разница между потоками и процессами.

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

Сообщение от COKPOWEHEU почему парадигма ООП не вытеснила все остальные, если она так хороша?

ООП - это не парадигма а методология проектирования. И вытеснила она все еще в 60-х. Разница с остальными "парадигмами" только в том поддерживается ли ООП языком на котором производится реализация, или эту реализацию приходится костылить.

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

Сообщение от COKPOWEHEU ризнаете ли вы, что рост винды гораздо больше похож на экспоненту, чем линукса? Исключительно по вашим же данным.

Еще раз - поймите разницу меду дистрибутивом оси, у которой и рост объемов функциональности экспоненциальный, и ядром оси для которого рост функциональности отсутствует от слова совсем. У винды растет дистрибутив. У линухи ядро давно привысило размер дистрибутива целой оси.

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

Сообщение от COKPOWEHEU - Каков объем и системные требования дистрибутива винды, решающего самый базовый класс задач - ползанье по интернету, работу в офисной программе, просмотр картинок, видео и pdf?

по минимуму
Intel 80386DX 4MB RAM 50 MB диск. рекомендованные для этого дистрибутива 80486 8мб. Вы ей богу как не знаете что винда и 95-я существует.

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

Сообщение от COKPOWEHEU Так вот почему вы их не пишете!

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

0

Сообщение от Fulcrum_013 Напомню суть вопроса - у виндового дескриптора окна есть багажник под указатель на пользовательские данные, у x11 нет от слова совсем - т.е. поиск стейта по хендлу.

Я даже не буду проверять ваши слова. Данный вопрос меня не интересует абсолютно. Хотя бы потому что результирующих возможностей линуксовой графической системы винде не достичь еще очень долго. Хотя порты иксов под винду вроде бы есть, так что не все так безнадежно. Во-вторых, потому что вы можете хоть до пробуждения Ктулху оптимизировать какой-то участок кода, но если он не является узким местом, ваши усилия будут бесполезны. А лаже логарифмический линейный поиск среди пары сотен окон узким местом не является точно.

Сообщение от Fulcrum_013 Вы же не хотите сказать какую именно логику вы хотите реализовать. Банально - куда процесс пошел дальше если в пайпе ничего нет, и что должен делать если что то есть.

Я же сказал - на ваш выбор, лишь бы до посинения не ждал пока данные появятся. В моем примере просто говорит что "данных нет" в stdout. Если хотите, добавьте анимацию (крутящиеся символы / | - \), мол "жду данных".
Да ладно код, достаточно если дадите качественную оценку сложности данной задачи на winapi - сколько строк на это должно уйти.

Сообщение от Fulcrum_013 В профессиональной разработке плюсы <... и прочий бред поскипан>

Уменьшим количество отвлекающих факторов, а то демагоги вроде вас упорно стараются отвечать на все что угодно кроме прямых вопросов.

Сообщение от COKPOWEHEU Сравнение языков программирования: - почему божественные плюсики не вытеснили все остальные языки из всех ниш, если она их во всем превосходит? - каков объем кода, реализующего асинхронный обмен данными между двумя потоками? Поскольку сложность реализации такого базового функционала, как каналы, вы уже и сами подозреваете, сжалюсь и оставлю выбор типа данных и способа обмена за вами. - почему парадигма ООП не вытеснила все остальные, если она так хороша? Почему до сих пор существуют процедурные, функциональные языки? Естественно, элементы ООП в них могут встречаться, все же это реальные языки, а не декоративные. Сравнение операционных систем: - признаете ли вы, что рост винды гораздо больше похож на экспоненту, чем линукса? Исключительно по вашим же данным. - Каков объем и системные требования дистрибутива винды, решающего самый базовый класс задач - ползанье по интернету, работу в офисной программе, просмотр картинок, видео и pdf? Естественно, там в ядре куча лишнего мусора - ну так озвучьте, какие задачи он помогает решать.

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

Сообщение от Fulcrum_013 Никакой. Потоки живут в одном адресном пространстве

Ну то есть раз память общая, то никакая синхронизация не нужна, можно напрямую читать-писать в память соседа. Я вас правильно понял?

Сообщение от Fulcrum_013 по минимуму Intel 80386DX 4MB RAM 50 MB диск. рекомендованные для этого дистрибутива 80486 8мб.

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

0

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

Вы же просили минимальную для перечисленных задач.

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

Сообщение от COKPOWEHEU Я же сказал - на ваш выбор, лишь бы до посинения не ждал пока данные появятся

Ну дык определитесь чего вы хотите. Там только апи межпроцессного обмена 6 штук, это не говоря про варианты того что можно при их помощи делать. От банальной пересылки RAW буфера через WM_COPYDATA до распределенного DCOM.

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

Сообщение от COKPOWEHEU В моем примере просто говорит что "данных нет" в stdout.

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

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

Сообщение от COKPOWEHEU каков объем кода, реализующего асинхронный обмен данными между двумя потоками?

Учите матчасть - никакой. Для начала уясните чем потоки отличаются от процессов. А то и будете так всю жизнь ненужные форки проессов плодить. И точно так же по всем вашим остальным вопросам - осильте азы специальности, все вопросы сразу же отпадут.
А до дискусий на эту тему вы явно не доросли - вы не в состоянии понять о чем вообще идет речь.

0

Сообщение от Fulcrum_013 Вы же просили минимальную для перечисленных задач.

И продолжаю просить: win95 эту задачу не решает. Как минимум, потому что легально ее не достать. Потом, современные форматы она не потянет.

Сообщение от Fulcrum_013 Ну дык определитесь чего вы хотите. Там только апи межпроцессного обмена 6 штук, это не говоря про варианты того что можно при их помощи делать. От банальной пересылки RAW буфера через WM_COPYDATA до распределенного DCOM.

"я знаю карате, кунг-фу и еще двадцать страшных слов!"
Хоть один вариант кода приведите.

Сообщение от Fulcrum_013 Учите матчасть - никакой.

В переводе с языка Fulcrum_013 на человеческий: "ответов я не знаю, поэтому лучше попытаюсь оскорбить оппонента - вдруг ему станет противно и он уйдет". Нет, не уйдет:

Сообщение от COKPOWEHEU Сравнение языков программирования: - почему божественные плюсики не вытеснили все остальные языки из всех ниш, если она их во всем превосходит? - каков объем кода, реализующего асинхронный обмен данными между двумя потоками? Поскольку сложность реализации такого базового функционала, как каналы, вы уже и сами подозреваете, сжалюсь и оставлю выбор типа данных и способа обмена за вами. - почему парадигма ООП не вытеснила все остальные, если она так хороша? Почему до сих пор существуют процедурные, функциональные языки? Естественно, элементы ООП в них могут встречаться, все же это реальные языки, а не декоративные. Сравнение операционных систем: - признаете ли вы, что рост винды гораздо больше похож на экспоненту, чем линукса? Исключительно по вашим же данным. - Каков объем и системные требования дистрибутива винды, решающего самый базовый класс задач - ползанье по интернету, работу в офисной программе, просмотр картинок, видео и pdf? Естественно, там в ядре куча лишнего мусора - ну так озвучьте, какие задачи он помогает решать.

0

COKPOWEHEU,

Сообщение от COKPOWEHEU каков объем кода, реализующего асинхронный обмен данными между двумя потоками?

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

Сообщение от COKPOWEHEU почему парадигма ООП не вытеснила все остальные, если она так хороша?

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

Сообщение от COKPOWEHEU Почему до сих пор существуют процедурные, функциональные языки?

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

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

Сообщение от COKPOWEHEU признаете ли вы, что рост винды гораздо больше похож на экспоненту, чем линукса?

Доростите до уровня второго класса и изучите тему сравнение дробей. Тогда поговорим. Сейчас же вы пытаетесь сравнить мягкое с холодным. Если пытаться сравнивать так как вы то к объему кода линухи по минимуму надо добавить объем кода хрома, оракла Java рантайма и VM, Апача, пыха, Вулкана, десктоп менеджера и т.д. и т.п - т.е. аналоги всего того что не входит в ядро но входит в дистрибутив виндов.
По доступным данным можно сравнить только функционал на строки кода. В тоже количество строк кода у которых в линухе влезло только ядро у Майкрософта влезла целая ось вместе со всем апи и кучей прикладного софта аки браузером веб-сервером sql-сервером, десктопом и т.д.
Т.е. вы банально не понимаете разницу между ядром и дистрибутивом и не умеете сравнивать дроби. О чем может идти речь?

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

Сообщение от COKPOWEHEU Естественно, там в ядре куча лишнего мусора - ну так озвучьте, какие задачи он помогает решать.

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

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

Сообщение от COKPOWEHEU Потом, современные форматы она не потянет.

А это уже вопросы прикладного софта а не оси.

Добавлено через 2 минуты
COKPOWEHEU, Т.е. еще раз - вам на все вопросы исчерпывающе ответили. Вы же не в состоянии понять ответы в силу вашей безграмотности. Вывод - освойте хотя бы азы специальности и вам все сразу станет ясно.

Добавлено через 20 минут
COKPOWEHEU, Т.е. все ваши проблемы от безграмотности и бессистемной разработки. А значит ни апи ни возможности языка в плане создания абстракций помочь не способны - продуктивности а тем более решения задач сложнее уровня хеллоувердов у вас все равно не будет. И так у 90% неквалифицированных разрабов в индустрии. Но и решают эти 90% в результате около 1% задач.

0

Сообщение от Fulcrum_013 Еще раз ответ - никакой. Потоки живут в одном адресном пространстве. Поэтому никакой обмен им не нужен.

Понятно. Как решать задачу Fulcrum_013 не знает, для чего она может понадобиться - тоже. Он считает, что любой обмен просто обязательно должен идти через общую память.
Что ему мешало это написать прямым текстом неизвестно.

Сообщение от Fulcrum_013 [про все остальные ЯП] Потому что в них зафейлили добавить поддержку ООП. Все чем занимаются на этих языках - это ручное костыленье реализации ООП.

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

Сообщение от Fulcrum_013 Если пытаться сравнивать так как вы то к объему кода линухи по минимуму надо добавить объем кода хрома, оракла Java рантайма и VM, Апача, пыха, Вулкана, десктоп менеджера и т.д. и т.п - т.е. аналоги всего того что не входит в ядро но входит в дистрибутив виндов.

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

Сообщение от Fulcrum_013 В тоже количество строк кода у которых в линухе влезло только ядро у Майкрософта влезла целая ось

Очевидно, вы так спешили высказаться, что оговорились. Весь дистрибутив линукса может занимать меньше места, чем одно только ядро винды. Так будет правильно. "Может" - потому что дистрибутив штука крайне гибкая и его объем зависит от установленного софта.
Или это была не ошибка, и вы можете доказать, что ядро актуальной винды весит меньше 5 мегабайт?

Сообщение от Fulcrum_013 И этот список не зависим от самой операционной системы от слова совсем - ядро это тот минимум который обеспечивает виртуализацию устройств, планировку задач и механизмы синхронизации.

По вашему определению получается, что функционал любого ядра совершенно одинаков. Тогда откуда разница объема?

Сообщение от Fulcrum_013 Потом, современные форматы она не потянет. А это уже вопросы прикладного софта а не оси.

А соответствующий прикладной софт на нее установить невозможно. Значит пославленной задаче она не соответствует.
Но это ладно. Из того, как старательно вы пытаетесь увернуться от прямого сравнения, уже все понятно.

Сообщение от Fulcrum_013 COKPOWEHEU, Т.е. еще раз - вам на все вопросы исчерпывающе ответили.

Пара несвязных фраз - не ответ. Если конкретнее:

Сравнение языков программирования: - почему божественные плюсики не вытеснили все остальные языки из всех ниш, если она их во всем превосходит? <<< ответа не было >>> - каков объем кода, реализующего асинхронный обмен данными между двумя потоками? Поскольку сложность реализации такого базового функционала, как каналы, вы уже и сами подозреваете, сжалюсь и оставлю выбор типа данных и способа обмена за вами. <<< вместо ответа было утверждение что это не нужно никому и никогда. Это не ответ. >>> - почему парадигма ООП не вытеснила все остальные, если она так хороша? Почему до сих пор существуют процедурные, функциональные языки? Естественно, элементы ООП в них могут встречаться, все же это реальные языки, а не декоративные. <<< вместо ответа был бред что все языки стремятся к ООП. В реальности видим в лучшем случае элементы ООП, так что ответ не засчитан >>> Сравнение операционных систем: - признаете ли вы, что рост винды гораздо больше похож на экспоненту, чем линукса? Исключительно по вашим же данным. <<< вместо ответа попытки оскорбления и неумение пользоваться своими же данными. Признания не было >>> - Каков объем и системные требования дистрибутива винды, решающего самый базовый класс задач - ползанье по интернету, работу в офисной программе, просмотр картинок, видео и pdf? Естественно, там в ядре куча лишнего мусора - ну так озвучьте, какие задачи он помогает решать. <<< вместо ответа была приведены win95, которая условиям не удовлетворяет >>>

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

0

Сообщение от COKPOWEHEU По вашему определению получается, что функционал любого ядра совершенно одинаков. Тогда откуда разница объема?

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

Сообщение от COKPOWEHEU Он считает, что любой обмен просто обязательно должен идти через общую память.

Вы просите не про любой обмен а про обмен между потоками. Его делать как то по другому вообще бессмысленно. А то что вы не понимаете разницу между потоками и процессами - ну это проблемы вашей личной безграмотности.

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

Сообщение от COKPOWEHEU Именно это я и предлагаю, но вы почему-то упорно уходите от ответа.

Только вот тогда это не будет сравнение эффективности С++ и С абсолютно никак. Огромное количество из этих прог написано на плюсах или "С с классами" а не на С. Касательно же винды - то начиная с хрюшки в дистряке огромное количество манаджед кода. Это большая часть как самого Net Framework и абсолютно все вспомогательные днсктопные утилиты. Посему так сравнить не получится.
А вот посмотреть что у майкрософта поместилось в тот же размер кода что у линухи в код только ядра - от это более менее реальное сравнение продуктивности С хотя бы с "С с классами" на которых писали в конце 90-х - начале 0-х.

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

Сообщение от COKPOWEHEU А соответствующий прикладной софт на нее установить невозможно.

Никто не запрещает его разработать/портировать.

Добавлено через 6 минут
Еще раз - это проблемы уже не оси а прикладного софта.

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

Сообщение от COKPOWEHEU Весь дистрибутив линукса может занимать меньше места, чем одно только ядро винды.

Да что вы? Размер дистряка к примеру ubuntu 20 - 2.5ГБ. Размер 10-ки - 4,8ГБ. Вполне сравнимо. Только вот апи и список предустановленного прикладного софта у винды куда побольше - его сравнивать надо с ведром + вся гуглоапи + то чего в ведре в принципе нету.
При этом а какое вообще отношение размер дистряка имеет к размеру сырца?
Процентов 95 а то и больше занимает вообще даже не бинарник кода, а картинки и прочие свистопирделки. Или вы вообще не понимаете как исходник преобразуется в бинарку и что софтинам окромя кода еще и данные нужны?

0

To All: Предлагаю сделать ставку кто победит, пусть это будет 100 рублей, проигравший сделает перевод на Яндекс.Деньги.
Выбираем бойца - мой выбор Fulcrum_013, кто готов выбрать COKPOWEHEU ?

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

2

Сообщение от COKPOWEHEU Или это была не ошибка, и вы можете доказать, что ядро актуальной винды весит меньше 5 мегабайт?

При чем вообще размер бинарника к количеству строк сырца то? при этом сколько бы не было ядро линухи в виде бинарника, ядро винды все равно будет меньше. У винды архитектура гибридного (модульного) макроядра, у линухи монолитный анахронизм.
kernel.appcore.dll 59kb
kernel32.dll 722kb
KernelBase.dll 2701kb
Итого 3547kb

0

Kastaneda, это не честно. У Fulcrum_013 высокая выносливость и бонус к невосприимчивости к аргументам. Оппонент может просто задолбаться.

1

Сообщение от Usaga У Fulcrum_013 высокая выносливость и бонус к невосприимчивости к аргументам.

Блин, да, нужно как-то уровнять шансы.
Fulcrum_013, можешь принять зелье, понижающее выносливость и лишающее всех бонусов на 100 часов? Очень надо

0