Здравствуйте, Marty, Вы писали:
M>файберы — это не настоящая многопоточность, насколько я помню. И проблем многопоточных там не должно быть
Если переключать только так, как принято для них — по явному запросу, в строго определенные моменты, то не должно. Но в те времена таких механизмов или не было вообще, или были совсем примитивные, поэтому переключали как явно в ранних виндах (yield), так и неявно — по асинхронному событию. Я и под досом как-то делал эмуляцию многопоточки для программы на C, через переключение контекстов по таймерным прерываниям. Такие костыли тогда многие делали для себя.
Re: Можно ли сделать универсальный шаблон для разных комбинаций whar_t и char?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>У меня есть функции, реализации которых нужны для разных комбинаций Unicode и ANSI (Unicode/Unicode, ANSI/ANSI, Unicode/ANSI). Строки ANSI используются только в качестве источников (байт дополняется нулевым старшим). Реализации отличаются только используемыми типами. Напрашивается идея оформить их одним шаблоном, но получается затык с "перекрестными" версиями — обычное присваивание из char в wchar_t расширяет знак, а мне нужно расширять нулем.
Это при сборке где char = signed char.
Однако тип char не специфирован со знаком он или нет, посему он может быть и unsigned char.
Например: gcc -funsigned-char myprogram.c
В связи с этим правильным вариантом будет сначала приведением к unsigned char, а только потом к wchar_t для избежания расширения знака.
Здравствуйте, Евгений Музыченко, Вы писали:
M>>файберы — это не настоящая многопоточность, насколько я помню. И проблем многопоточных там не должно быть
ЕМ>Если переключать только так, как принято для них — по явному запросу, в строго определенные моменты, то не должно. Но в те времена таких механизмов или не было вообще, или были совсем примитивные, поэтому переключали как явно в ранних виндах (yield), так и неявно — по асинхронному событию.
Хм. Если в совсем ранних виндах — то там многозадачность только кооперативная была, никто там ничего не переключал, и никаких yield'ов не было. Ну, или я не помню. В более взрослых виндах была нормальная вытесняющая многопоточность, и никаких yield'ов там тоже не было.
ЕМ>Я и под досом как-то делал эмуляцию многопоточки для программы на C, через переключение контекстов по таймерным прерываниям. Такие костыли тогда многие делали для себя.
А это в принципе вполне себе вытесняющая многопоточность. Такой и на контроллерах балуются — FreeRTOS, например, на STMке использовали. Только зело неудобно это, однопоточку на автоматах гораздо проще отлаживать, а когда совсем невтерпеж было — использовали stackless корутины на шаблонах. Те же автоматы, но больше похожи на многопоточность
Здравствуйте, Marty, Вы писали:
M>Если в совсем ранних виндах — то там многозадачность только кооперативная была
Она была в версиях 1.x, 2.x и 3.x.
M>никто там ничего не переключал, и никаких yield'ов не было.
И чем же там переключали, если не Yield'ом?
M>В более взрослых виндах была нормальная вытесняющая многопоточность
Она появилась в 4.0 (Win95).
M>никаких yield'ов там тоже не было.
Были, просто ничего не делали. В SDK и посейчас есть определение Yield.
M>Только зело неудобно это, однопоточку на автоматах гораздо проще отлаживать
Смотря какую. С ростом количества состояний и условий перехода между ними сложность отладки растет очень быстро. Автомат хорош там, где вероятности переходов между состояниями сравнимы между собой. А если в алгоритме есть явная последовательность, которая в автоматной реализации теряется, может быть очень неудобно разбираться, откуда и почему оно пошло не так.
M>использовали stackless корутины
Которые еще в 60-х назывались "сопрограммами".
Re[31]: Можно ли сделать универсальный шаблон для разных комб
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ> Я и под досом как-то делал эмуляцию многопоточки для программы на C, через переключение контекстов по таймерным прерываниям. Такие костыли тогда многие делали для себя.
Здравствуйте, rudzuk, Вы писали:
r> M> Если что, файберы в винду завезли довольно недавно, как бы не в W2K, если не в XP
r> В Windows 98 для линейки 9x или NT 3.5 SP3 для NT.
В Windows 98 для линейки 9x или NT 3.51 SP3 для NT.
Здравствуйте, Евгений Музыченко, Вы писали:
M>>Если в совсем ранних виндах — то там многозадачность только кооперативная была
ЕМ>Она была в версиях 1.x, 2.x и 3.x.
Не совсем понял что ты сказал сейчас. Уточни плс. Кто — она?
M>>никто там ничего не переключал, и никаких yield'ов не было.
ЕМ>И чем же там переключали, если не Yield'ом?
Да никак и не переключали. Просто возвращаешь управление из оконной процедуры, и всё.
ЕМ>Были, просто ничего не делали. В SDK и посейчас есть определение Yield.
Хм, хз, у Рихтера ничего про них не видел
M>>Только зело неудобно это, однопоточку на автоматах гораздо проще отлаживать
ЕМ>Смотря какую. С ростом количества состояний и условий перехода между ними сложность отладки растет очень быстро. Автомат хорош там, где вероятности переходов между состояниями сравнимы между собой. А если в алгоритме есть явная последовательность, которая в автоматной реализации теряется, может быть очень неудобно разбираться, откуда и почему оно пошло не так.
Да нормально. Отдельно делаются подавтоматы, и всё. Например, можно читать в одном потоке из UART'а сколько требуется, разбирать пришедшее, и что-то с этим делать, сообщать основному потоку, например. В основном потоке делать бизнес логику. А можно в одном потоке читать читать сколько прочитается, кидать в автомат разбора протокола, и, не блокируясь на этом, ковылять дальше и обрабатывать бизнес логику в том же потоке. Бизнес логику тоже на подавтоматы можно разбить обычно. И эти части готовыми фрагментами таскать из проекта в проект.
M>>использовали stackless корутины
ЕМ>Которые еще в 60-х назывались "сопрограммами".
Здравствуйте, Евгений Музыченко, Вы писали:
S>>Речь же не о литературе, а о программах. И, поскольку вы сравнивали с FoxPro и Clipper, то речь уже о x86 и MS-DOS (или клоны MS-DOS).
ЕМ>Так я и не говорил, что это хоть как-то относилось к СССР.
Вы говорили о том, что видели сами:
Я хорошо помню, какими уродливыми и тормозными они были еще на стыке 80-х и 90-х. Если какой-то софт был толстым и/или тормозным, и при этом не был написан на каком-нибудь FoxPro или Clipper, он чаще всего был написан на плюсах.
А поскольку вы в конце 80-х были в СССР, то видеть уродство и тормознутость С++ вы могли на том, что в это время было в СССР (не важно, написанное здесь или не здесь). Но на стыке 80-х и 90-х в СССР софта на C++ было микроскопически мало.
Подозреваю, что стыком 80-х и 90-х вы считаете период где-то с 1993-го. Но отнести 1993-й к "стыку 80-х и 90-х" сложновато.
S>>я к тому, что именно на рубеже 80-х и 90-х софта на C++, с которым вы могли бы столкнуться, было совсем совсем мало.
ЕМ>Верно, мало. Первым делом вспоминается Turbo Vision, который был прямо напоказ набит демонстрациями ООП.
У меня почему-то осталось воспоминание о том, что Turbo Vision был написан на Object Pascal, а к C++ там был сделан интерфейс за счет того, что формат объектников у Turbo Pascal и Turbo/Borland C++ от Borland-а был одинаковый. По крайней мере Turbo Vision конца 1980-х.
На C++ был написан OWL от Borland-а. Но это уже под Windows библиотека.
На C++, помнится, в начале 1990-х довелось видеть библиотеку Zinc Interface. Причем вроде как даже какую-то не первую версию, вроде бы Zinc 3.0, т.е. разрабатывать ее начали еще раньше.
S>>Именно многопоточность (а не многопроцессность) вроде бы в середине 1980-х только-только начиналась.
ЕМ>Я так написал потому, что нынче большинство знает только за многопоточность. А по сути, какая разница?
Большая. Особенно в конце 1980-х. Многопоточность -- это же параллельность внутри одного адресного пространства. Соответственно, влезть в данные соседнего потока можно просто и незаметно для самого себя. Тогда как в многопроцессности тогдашенего времени обмен данными велся через IPC механизмы (типа пайпов). Вроде как даже shared memory в Unix-ы добавили толи в конце 1980-х, толи в начале 1990-х.
Re[28]: Можно ли сделать универсальный шаблон для разных комб
Здравствуйте, so5team, Вы писали:
S>У меня почему-то осталось воспоминание о том, что Turbo Vision был написан на Object Pascal, а к C++ там был сделан интерфейс за счет того, что формат объектников у Turbo Pascal и Turbo/Borland C++ от Borland-а был одинаковый. По крайней мере Turbo Vision конца 1980-х.
Всё так. При этом борландовские среды Turbo Pascal и Turbo/Borland C++ были на нем написаны. И они вполне себе летали. Но, наверное, это слишком простые программы
ЕМ>>Я так написал потому, что нынче большинство знает только за многопоточность. А по сути, какая разница?
S>Большая. Особенно в конце 1980-х. Многопоточность -- это же параллельность внутри одного адресного пространства. Соответственно, влезть в данные соседнего потока можно просто и незаметно для самого себя. Тогда как в многопроцессности тогдашенего времени обмен данными велся через IPC механизмы (типа пайпов). Вроде как даже shared memory в Unix-ы добавили толи в конце 1980-х, толи в начале 1990-х.
Здравствуйте, Marty, Вы писали:
ЕМ>>Она была в версиях 1.x, 2.x и 3.x.
M>Не совсем понял что ты сказал сейчас. Уточни плс. Кто — она?
Кооперативная многозадачность.
M>Да никак и не переключали. Просто возвращаешь управление из оконной процедуры, и всё.
Ну, если вся функциональность софта состояла исключительно в быстрой обработке оконных сообщений, то да — Yield вызывал сам оконный менеджер. Но некоторые программы попутно делали еще и какую-то полезную работу, которая не всегда занимала доли секунды.
M>у Рихтера ничего про них не видел
Скорее всего, Вам просто не приходилось тогда писать под виндами код, работа которого занимала сколько-нибудь заметное время.
M>>>Только зело неудобно это, однопоточку на автоматах гораздо проще отлаживать
ЕМ>>Смотря какую. С ростом количества состояний и условий перехода между ними сложность отладки растет очень быстро. Автомат хорош там, где вероятности переходов между состояниями сравнимы между собой. А если в алгоритме есть явная последовательность, которая в автоматной реализации теряется, может быть очень неудобно разбираться, откуда и почему оно пошло не так.
M>Отдельно делаются подавтоматы, и всё. Например, можно читать в одном потоке из UART'а сколько требуется, разбирать пришедшее, и что-то с этим делать, сообщать основному потоку, например
Хм, что Вы называете "потоками" в контексте автоматной реализации — ветку обработки состояния? Тогда такая техника работает ровно до тех пор, пока в одной ветке не накопится достаточно кода, чтобы нарушить привязку к реальному времени. Придется добавлять промежуточные состояния, добавлять переменные для хранения контекста. В какой-то момент это становится настолько развесистым, что проще сделать простенький переключатель контекста (хотя бы и кооперативный), и дальше уже писать обработку в естественной последовательности действий. Особенно если это пишется не на ассемблере, на регистрах и глобальных переменных, а хотя бы на C, с локальными переменными на стеке.
Re[35]: Можно ли сделать универсальный шаблон для разных комб
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>>>Она была в версиях 1.x, 2.x и 3.x.
M>>Не совсем понял что ты сказал сейчас. Уточни плс. Кто — она?
ЕМ>Кооперативная многозадачность.
Ну да. А я что-то другое сказал?
M>>Да никак и не переключали. Просто возвращаешь управление из оконной процедуры, и всё.
ЕМ>Ну, если вся функциональность софта состояла исключительно в быстрой обработке оконных сообщений, то да — Yield вызывал сам оконный менеджер. Но некоторые программы попутно делали еще и какую-то полезную работу, которая не всегда занимала доли секунды.
Ну хз, может быть. Не доводилось использовать. Да и до сих пор почти всегда обхожусь однопоточностью
M>>у Рихтера ничего про них не видел
ЕМ>Скорее всего, Вам просто не приходилось тогда писать под виндами код, работа которого занимала сколько-нибудь заметное время.
Я про книжку Рихтера, когда он ещё про плюсы писал. Там про многопоток было, чуть ли не полкниги, а вот Yield'а я там не заметил
M>>Отдельно делаются подавтоматы, и всё. Например, можно читать в одном потоке из UART'а сколько требуется, разбирать пришедшее, и что-то с этим делать, сообщать основному потоку, например
ЕМ>Хм, что Вы называете "потоками" в контексте автоматной реализации — ветку обработки состояния? Тогда такая техника работает ровно до тех пор, пока в одной ветке не накопится достаточно кода, чтобы нарушить привязку к реальному времени. Придется добавлять промежуточные состояния, добавлять переменные для хранения контекста. В какой-то момент это становится настолько развесистым, что проще сделать простенький переключатель контекста (хотя бы и кооперативный), и дальше уже писать обработку в естественной последовательности действий. Особенно если это пишется не на ассемблере, на регистрах и глобальных переменных, а хотя бы на C, с локальными переменными на стеке.
Нет, я именно про threads. В FreeRTOS они есть, её и её многопоточность мы использовали, но отказались, стали все на автоматах делать. Ничего развесистым не становится. И риалтайм вполне жесткий. К слову, он редко нужен, этот жесткий риалтайм. Тех микросекунд, за которые прокручивается цикл в единственном потоке — хватало на все. Тут больше проблемы с внешними датчиками SPI/I2C. Во многих STMках есть аппаратные интерфейсы, и они вроде бы делают всю работу, но они подглючивают, и везде по разному. Для каждого камня надо эррату читать. И при переносе кода на другой камешек (почти такой же, только флеша, например, побольше) — легко могло оказаться, что что I2C отвалился. В итоге плюнули, и стали программно с датчиками общаться. В одном потоке. В блокирующем режиме. И 100/400 Кгц частоты I2C вполне хватало для всего. Один только случай могу вспомнить — когда чел делал управление асинхронным вроде мотором, и ему нужно было вот прямо сейчас получать значения тока, да так риалтаймово, что его не устраивали АЦП в обычном режиме, и приходилось делать инжектированный канал — что-то вроде запроса к АЦП отбросить всю текущую работу и побырому оцифрофровать значение определенного канала. И то — там в одном потоке умудрялись без проблем опрашивать CAN/UART'ы на предмет управляющих команд и отправлять ответы
Здравствуйте, so5team, Вы писали:
S>Но на стыке 80-х и 90-х в СССР софта на C++ было микроскопически мало.
Повторю: в тех организациях СССР, что предметно занимались вычислительной техникой и программированием, был любой зарубежный софт, который мог представлять интерес. Никаких ограничений по распространению обычного софта тогда не было, поэтому оттуда его раздавали всем желающим.
S>Подозреваю, что стыком 80-х и 90-х вы считаете период где-то с 1993-го.
Баловаться программированием на C++ наши юниксоиды начали в конце 80-х, я в этом не участвовал. В 90-м, как только вышел TC++ 1.0, народ уже начал писать всерьез. К моменту появления BC++ 3 (91-й) это уже цвело пышным цветом. Но я тогда ограничивался ANSI C.
S>У меня почему-то осталось воспоминание о том, что Turbo Vision был написан на Object Pascal, а к C++ там был сделан интерфейс
Я уже не помню, чего из Pascal и C++ там было больше. Но эффективность обоих тогда была очень близка, особых преимуществ по объему и/или быстродействию не было ни у того, ни у другого. В "процедурном" применении оба были достаточно эффективны, а в варианте "ООП без границ" оба давали одинаково тормозной код, как и сейчас.
S>На C++, помнится, в начале 1990-х довелось видеть библиотеку Zinc Interface.
Наши вроде тоже что-то на ней делали.
S>Вроде как даже shared memory в Unix-ы добавили толи в конце 1980-х, толи в начале 1990-х.
В RSX-11M общая память была с начала 80-х, и там мы много писали под ядро, где почти любой код мог быть в любой момент прерван, и драйвер одновременно мог обслуживать множество запросов от разных процессов. На БЭСМ-6 нас к ядру не пускали, но там как раз мы делали многопоточность вручную в рамках одного процесса.
Re[29]: Можно ли сделать универсальный шаблон для разных комб
Здравствуйте, Marty, Вы писали:
M>борландовские среды Turbo Pascal и Turbo/Borland C++ были на нем написаны. И они вполне себе летали.
Ну, у кого-то и VS 2019 "летает", хотя на мой взгляд она безбожно тормозит. А так-то даже в Norton Commander, написанном (по крайней мере, поначалу) на чистом C, на 286/16 ощущались задержки по сравнению с Volkov Commander, написанном на ассемблере, но это уже явно не от языка, а от неоптимальности реализации.
Re[36]: Можно ли сделать универсальный шаблон для разных комб
Здравствуйте, Marty, Вы писали:
ЕМ>>Кооперативная многозадачность.
M>Ну да. А я что-то другое сказал?
Вы сказали, что она была "в совсем ранних виндах". "Совсем ранние" — это версии 1.x-2.x (1985-1988), а версии 3.x (1990-1993) уже применялись достаточно массово.
M>Я про книжку Рихтера, когда он ещё про плюсы писал. Там про многопоток было, чуть ли не полкниги, а вот Yield'а я там не заметил
Если книга была про Win 4.x (95/98/ME), то там и не было нужды в Yield.
M>К слову, он редко нужен, этот жесткий риалтайм. Тех микросекунд, за которые прокручивается цикл в единственном потоке — хватало на все.
Так это и есть жесткий реалтайм, когда железо/софт гарантируют обработку события за один или несколько циклов. На голом железе с этим как раз проще, чем под навороченной многозадачной ОС.
Re[37]: Можно ли сделать универсальный шаблон для разных комб
ЕМ>Вы сказали, что она была "в совсем ранних виндах". "Совсем ранние" — это версии 1.x-2.x (1985-1988), а версии 3.x (1990-1993) уже применялись достаточно массово.
3.X — тоже вполне ранние
M>>Я про книжку Рихтера, когда он ещё про плюсы писал. Там про многопоток было, чуть ли не полкниги, а вот Yield'а я там не заметил
ЕМ>Если книга была про Win 4.x (95/98/ME), то там и не было нужды в Yield.
Нужды может и не было, но вообще можно было бы упомянуть хотя бы, что ещё есть в винде
M>>К слову, он редко нужен, этот жесткий риалтайм. Тех микросекунд, за которые прокручивается цикл в единственном потоке — хватало на все.
ЕМ>Так это и есть жесткий реалтайм, когда железо/софт гарантируют обработку события за один или несколько циклов. На голом железе с этим как раз проще, чем под навороченной многозадачной ОС.
Здравствуйте, Marty, Вы писали:
M>3.X — тоже вполне ранние
Если отсчитывать от Win11, то и XP можно считать "ранней" — уже больше двадцати лет, как-никак.
ЕМ>>Если книга была про Win 4.x (95/98/ME), то там и не было нужды в Yield.
M>Нужды может и не было, но вообще можно было бы упомянуть хотя бы, что ещё есть в винде
Так в Win32 Yield оставлено исключительно ради совместимости по исходникам — в виде пустого макроса, даже в библиотеках его нет.
Re[39]: Можно ли сделать универсальный шаблон для разных комб
Здравствуйте, Евгений Музыченко, Вы писали:
M>>3.X — тоже вполне ранние
ЕМ>Если отсчитывать от Win11, то и XP можно считать "ранней" — уже больше двадцати лет, как-никак.
ЕМ>>>Если книга была про Win 4.x (95/98/ME), то там и не было нужды в Yield.
M>>Нужды может и не было, но вообще можно было бы упомянуть хотя бы, что ещё есть в винде
ЕМ>Так в Win32 Yield оставлено исключительно ради совместимости по исходникам — в виде пустого макроса, даже в библиотеках его нет.
И охота тебе ещё всё это перетирать? Даже мне это уже надоело. А ты же во хранции, манифик, всё такое
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Повторю: в тех организациях СССР, что предметно занимались вычислительной техникой и программированием, был любой зарубежный софт, который мог представлять интерес. Никаких ограничений по распространению обычного софта тогда не было, поэтому оттуда его раздавали всем желающим.
Т.е. вы лично видели и пробовали все, что попадало в СССР?
Речь-то не о том, что в СССР было доступно многое, а о том, что лично вы видели и пробовали (вы же оценку на основании увиденного вами выдали). Хотя, если весь этот софт проходил через ваши руки... Но как-то верится с трудом.
S>>Подозреваю, что стыком 80-х и 90-х вы считаете период где-то с 1993-го.
ЕМ>Баловаться программированием на C++ наши юниксоиды начали в конце 80-х.
Вот именно, баловаться. А на чем, кстати, баловались? На СМ ЭВМ?
ЕМ>В 90-м, как только вышел TC++ 1.0, народ уже начал писать всерьез. К моменту появления BC++ 3 (91-й) это уже цвело пышным цветом.
Вот как раз после 1991-го о C++ и начали узнавать. И в 1992-1993-ом уже в журналах (типа "Мир ПК" и тому подобных) можно было встретить и упоминания о C++, и сравнения C++ с другими языками. И года с 1993-го уже C++ применялся массово. По крайней мере никто не переспрашивал о том, что такое C++ когда разговор заходил.
ЕМ>На БЭСМ-6 нас к ядру не пускали, но там как раз мы делали многопоточность вручную в рамках одного процесса.
