Когда я пишу, скажем, недодрайвер для контроллера USB, я временами добавляю комментарии в стиле "что": но они, естественно, описывают не самоочевидные действия, а назначение этих действий применительно к конкретной железяке. Скажем, я пишу, что вот здесь я обрабатываю прерывание по поступлению пакета SETUP, здесь -- по завершению передачи данных и т.д. Хотя, казалось бы, причина прерывания понятна из флага в регистре состояния, который при этом анализируется, и такой комментарий не нужен, я давно уже убедился, что, возвращаясь к собственному коду спустя, скажем, полгода, я уже не помню назначение тех или иных битов регистров контроллера, и мне куда проще понять, что делается, глянув на краткий комментарий, чем открывать даташит в поисках описания нужных битов или же анализировать дальнейший код, чтоб уже из него догадаться, а что здесь происходит. Кроме того, такие комментарии позволяют структурировать код в рамках одной функции (обработчика прерываний, например), визуально отсекая одну часть от другой.
Ну и, конечно, я пишу комментарии в случае отнюдь не очевидных или "лишних" действий -- например, связанных с обходом аппаратных ошибок.
Добавлю, что, с моей точки зрения, классы стоит использовать лишь в том случае, когда предполагается (хотя бы в будущем) использовать наследование и полиморфизм; если заведомо ясно, что ни того, ни другого не требуется и не потребуется, то и смысла в классе нет (инкапсуляцию можно обеспечить другими методами).
Ну, работать руками с деревом и металлом тоже уметь надо: реальный мир намного шире, чем электроника и программирование :) Так что на трудах -- табуретки со скворечниками. А вот вместо бредовой информатики заниматься чем-то таким куда полезней, как по мне.
Консольным терминалом ранних моделей Системы 360 был не телетайп, а пишущая машинка, но уже вскоре появились первые дисплеи. В СССР с ЕС ЭВМ была та же история, разве что дисплеи у нас подзадержались. В частности, лично я в конце 1980-х -- начале 1990-х работал на ЕС-1035, у которой, хотя и были дисплеи (ЕС-7927), но консолью по-прежнему была пишущая машинка. Кстати, это было весьма удобно: в отличие от дисплея, всегда можно посмотреть, что творилось в системе, без дополнительных телодвижений (распечатки файла журнала). Что ж до телетайпов... Да, они были, но относились к тому, что у нас назвали "устройствами телеобработки данных" -- подключались к машине через телефонные/телеграфные линии и модемы, грубо говоря. Плюс, как народ уже говорил, IBM рассматривала свои машины как средства для пакетной, а не диалоговой обработки данных, а им терминалы, кроме консоли, не нужны, так что наличие/отсутствие телетайпов на появление и развитие ранних моделей никакого влияния не оказывало.
Здесь размазывания уже нет. Правда, некоторое разбухание исходника (объявление переменных finN, тела лямбд с if'ами и обрамляющие сие дело скобки), но в разумных пределах и вполне читабельное. А можете упростить? Интересно посмотреть, что получится.
Из недостатков -- выделение дополнительной памяти. Да, знаю, не динамической, а в стеке -- но, тем не менее. Когда у тебя всего ОЗУ, скажем, 6 Кбайт на всё про всё, это может быть критичным (а может и не быть -- от задачи зависит). Плюс, некоторое снижением производительности, но это даже на слабых МК крайне редко проблемой бывает (а где бывает, лично я бы просто перешёл на ассемблер -- на нём я всяко напишу и более быстрый, и более компактный код, чем самый наилучший компилятор).
Вынуждены -- отправляйте. Но, замечу, что код без goto, но с классами, не менее хрупок и столь же базируется на скрупулёзности и внимательности программиста -- может, для Вас это будет открытием, но надёжность кода всегда базируется именно на них.
Динамическое выделение/освбождение памяти -- это одна из возможных проблем, а не единственная проблема. Использование "левых" классов "размазывает" программу и сильно усложняет её восприятие -- и ради чего? Только чтоб goto не было? Это уже фанатизм, и приводит он к прямо противоположным результатам (ухудшению читабельности и лёгкости сопровождения кода вместо улучшения).
Требует использования классов, динамического выделения-освобождения памяти и всё такое. Когда ООП само по себе уместно -- скажем, нужно наследование с полиморфизмом, которые реализовывать средствами чистого Си глупо, если есть Си++, -- это нормально, но в простом низкоуровневом коде... Это чисто его раздувание без какой-либо нужды, да и читабельность снижает: разрывает фактически единую функцию между конструктором и деструктором, а последний заставляет ещё и анализировать условия завершения, чтобы определить, что именно откатывать, а что -- нет. Ну или делать кучу вспомогательных классов с той же целью. В общем, громоздко, нечитаемо и неэффективно. Ну а конструкции типа try-finally в языке нет.
Именно. Но для микроконтроллеров без всяких осей -- и без обработки исключений, там они не очень-то уместны (и совсем неуместны, если ресурсы сильно ограничены).
MSVS как IDE пока откровенно хреново с модулями работает, это да. Вот собственно компилятор мелкомягкий уже переваривает их более-менее нормально.
Сами же модули, как они введены стандартом, лично мне не понравились: переусложнено, запутано, чревато ошибками... Как по мне, лучше было бы вводить модули в стиле Ады.
Я регулярно использую goto в случае, когда функция должна проверить кучу параметров на правильность и при ошибке возвращать некий код ошибки, но при этом после каждой удачной проверки выполняются какие-то действия, какие нужно откатить в случае обнаружения ошибки в дальнейшем. Т.е. получается конструкция примерно такого вида:
int Ret_Code;
if (проверка1)
{
return Error1;
}
действие1;
if (проверка2)
{
Ret_Code = Error2;
goto Err1;
}
действие2;
if (проверка3)
{
Ret_Code = Error3;
goto Err2;
}
....
return Success;
ErrN:
откатN;
...
Err2:
откат2;
Err1:
откат1;
return Ret_Code;
Как по мне, читабельность такого варианта больше, чем без goto, поскольку сами goto используются единообразным способом, без всякого там спагетти-кода.
Да мне тоже хотелось бы :) Но дело в том, что подробной информации по ряду машин нет. Даже по отечественным полная ясность не всегда присутствует. Скажем, ЕС-1066 какой "версии" Системы 370 соответствовала? Я лично понятия не имею -- а соответственно, не могу сказать, какие расширения архитектуры там были реализованы. На Вике вообще регулярно чушь пишут. Например, ЕС-1015 относят к тому же ряду, что ЕС-1010/11/12 -- но последние никакого отношения к Системе 360 не имеют, а 1015, согласно венгерскому каталогу для какой-то советской выставки 1979 года, полностью совместима со старшими моделями -- т.е. является полноценной Системой 370 (в частности, имеет виртуальную память). Ну или ЕС-1130: Вика говорит, что год начала производства -- 1994, но я на ней уже в 1993 работал, причём отнюдь не в Минске, где их делали. В общем, плохо с информацией...
Для представления отрицательных целых чисел используется не обратный, а дополнительный код не от неча делать, а из-за того, что этим резко упрощается аппаратура. Что же до переполнения, то нет никаких непреодолимых технических проблем его обнаруживать, и то, что в Си/Си++ это не принято, не означает, что это невозможно.
Если доживу. Правда, о 1045 особо писать нечего: чем сложней машина, тем тоньше книжка по ней :) Наиболее подробно описана как раз ЕС-1020, 1022 уже хуже.
А я вот предпочитаю прижимать к имени переменной/поля -- чтоб легче было видеть, что это ссылка/указатель на что-то, что слева (а слева тоже может быть указатель или ссылка, или вообще что-то многоэтажное). Отчасти, возможно, из-за того, что я слепой.
Но вообще, синтаксис Си отвратителен, а синтаксис объявлений -- отвратителен вдвойне.
Это-то понятно, но специалист обычно следит за развитием своего языка, а соответственно, C++11 новым для него не является -- даже если по работе он вообще пишет на чистом L&R C. Не было б в заголовке слова "новая" -- не было бы вопросов. Лучше было б, наверное, "современная" вместо "новая". Ну или что-то в этом роде -- в общем, чтоб не создавало иллюзий, будто речь пойдёт о C++23 или, на худой конец, С++20.
В самом начале цикла я писал об этом: всего несколько самых ранних микросхем 155-й серии, до К155ИП3 было далеко, как до Луны (она была освоена для производства ЕС-1033, что произошло лишь через несколько лет).
Когда я пишу, скажем, недодрайвер для контроллера USB, я временами добавляю комментарии в стиле "что": но они, естественно, описывают не самоочевидные действия, а назначение этих действий применительно к конкретной железяке. Скажем, я пишу, что вот здесь я обрабатываю прерывание по поступлению пакета SETUP, здесь -- по завершению передачи данных и т.д. Хотя, казалось бы, причина прерывания понятна из флага в регистре состояния, который при этом анализируется, и такой комментарий не нужен, я давно уже убедился, что, возвращаясь к собственному коду спустя, скажем, полгода, я уже не помню назначение тех или иных битов регистров контроллера, и мне куда проще понять, что делается, глянув на краткий комментарий, чем открывать даташит в поисках описания нужных битов или же анализировать дальнейший код, чтоб уже из него догадаться, а что здесь происходит. Кроме того, такие комментарии позволяют структурировать код в рамках одной функции (обработчика прерываний, например), визуально отсекая одну часть от другой.
Ну и, конечно, я пишу комментарии в случае отнюдь не очевидных или "лишних" действий -- например, связанных с обходом аппаратных ошибок.
Добавлю, что, с моей точки зрения, классы стоит использовать лишь в том случае, когда предполагается (хотя бы в будущем) использовать наследование и полиморфизм; если заведомо ясно, что ни того, ни другого не требуется и не потребуется, то и смысла в классе нет (инкапсуляцию можно обеспечить другими методами).
Ну, работать руками с деревом и металлом тоже уметь надо: реальный мир намного шире, чем электроника и программирование :) Так что на трудах -- табуретки со скворечниками. А вот вместо бредовой информатики заниматься чем-то таким куда полезней, как по мне.
Консольным терминалом ранних моделей Системы 360 был не телетайп, а пишущая машинка, но уже вскоре появились первые дисплеи. В СССР с ЕС ЭВМ была та же история, разве что дисплеи у нас подзадержались. В частности, лично я в конце 1980-х -- начале 1990-х работал на ЕС-1035, у которой, хотя и были дисплеи (ЕС-7927), но консолью по-прежнему была пишущая машинка. Кстати, это было весьма удобно: в отличие от дисплея, всегда можно посмотреть, что творилось в системе, без дополнительных телодвижений (распечатки файла журнала). Что ж до телетайпов... Да, они были, но относились к тому, что у нас назвали "устройствами телеобработки данных" -- подключались к машине через телефонные/телеграфные линии и модемы, грубо говоря. Плюс, как народ уже говорил, IBM рассматривала свои машины как средства для пакетной, а не диалоговой обработки данных, а им терминалы, кроме консоли, не нужны, так что наличие/отсутствие телетайпов на появление и развитие ранних моделей никакого влияния не оказывало.
Да можно и C++20, ежели компилятор собрать самому или найти уже готовый современный. Там же обычный GCC.
Здесь размазывания уже нет. Правда, некоторое разбухание исходника (объявление переменных finN, тела лямбд с if'ами и обрамляющие сие дело скобки), но в разумных пределах и вполне читабельное. А можете упростить? Интересно посмотреть, что получится.
Из недостатков -- выделение дополнительной памяти. Да, знаю, не динамической, а в стеке -- но, тем не менее. Когда у тебя всего ОЗУ, скажем, 6 Кбайт на всё про всё, это может быть критичным (а может и не быть -- от задачи зависит). Плюс, некоторое снижением производительности, но это даже на слабых МК крайне редко проблемой бывает (а где бывает, лично я бы просто перешёл на ассемблер -- на нём я всяко напишу и более быстрый, и более компактный код, чем самый наилучший компилятор).
Вынуждены -- отправляйте. Но, замечу, что код без goto, но с классами, не менее хрупок и столь же базируется на скрупулёзности и внимательности программиста -- может, для Вас это будет открытием, но надёжность кода всегда базируется именно на них.
Динамическое выделение/освбождение памяти -- это одна из возможных проблем, а не единственная проблема. Использование "левых" классов "размазывает" программу и сильно усложняет её восприятие -- и ради чего? Только чтоб goto не было? Это уже фанатизм, и приводит он к прямо противоположным результатам (ухудшению читабельности и лёгкости сопровождения кода вместо улучшения).
Требует использования классов, динамического выделения-освобождения памяти и всё такое. Когда ООП само по себе уместно -- скажем, нужно наследование с полиморфизмом, которые реализовывать средствами чистого Си глупо, если есть Си++, -- это нормально, но в простом низкоуровневом коде... Это чисто его раздувание без какой-либо нужды, да и читабельность снижает: разрывает фактически единую функцию между конструктором и деструктором, а последний заставляет ещё и анализировать условия завершения, чтобы определить, что именно откатывать, а что -- нет. Ну или делать кучу вспомогательных классов с той же целью. В общем, громоздко, нечитаемо и неэффективно. Ну а конструкции типа try-finally в языке нет.
Именно. Но для микроконтроллеров без всяких осей -- и без обработки исключений, там они не очень-то уместны (и совсем неуместны, если ресурсы сильно ограничены).
MSVS как IDE пока откровенно хреново с модулями работает, это да. Вот собственно компилятор мелкомягкий уже переваривает их более-менее нормально.
Сами же модули, как они введены стандартом, лично мне не понравились: переусложнено, запутано, чревато ошибками... Как по мне, лучше было бы вводить модули в стиле Ады.
Я регулярно использую goto в случае, когда функция должна проверить кучу параметров на правильность и при ошибке возвращать некий код ошибки, но при этом после каждой удачной проверки выполняются какие-то действия, какие нужно откатить в случае обнаружения ошибки в дальнейшем. Т.е. получается конструкция примерно такого вида:
Как по мне, читабельность такого варианта больше, чем без goto, поскольку сами goto используются единообразным способом, без всякого там спагетти-кода.
Да мне тоже хотелось бы :) Но дело в том, что подробной информации по ряду машин нет. Даже по отечественным полная ясность не всегда присутствует. Скажем, ЕС-1066 какой "версии" Системы 370 соответствовала? Я лично понятия не имею -- а соответственно, не могу сказать, какие расширения архитектуры там были реализованы. На Вике вообще регулярно чушь пишут. Например, ЕС-1015 относят к тому же ряду, что ЕС-1010/11/12 -- но последние никакого отношения к Системе 360 не имеют, а 1015, согласно венгерскому каталогу для какой-то советской выставки 1979 года, полностью совместима со старшими моделями -- т.е. является полноценной Системой 370 (в частности, имеет виртуальную память). Ну или ЕС-1130: Вика говорит, что год начала производства -- 1994, но я на ней уже в 1993 работал, причём отнюдь не в Минске, где их делали. В общем, плохо с информацией...
На мэйнфрейме z/Architecture, чтоль? Обработка десятичных чисел переменной длины -- фишка ещё с Системы 360...
Для представления отрицательных целых чисел используется не обратный, а дополнительный код не от неча делать, а из-за того, что этим резко упрощается аппаратура. Что же до переполнения, то нет никаких непреодолимых технических проблем его обнаруживать, и то, что в Си/Си++ это не принято, не означает, что это невозможно.
Если доживу. Правда, о 1045 особо писать нечего: чем сложней машина, тем тоньше книжка по ней :) Наиболее подробно описана как раз ЕС-1020, 1022 уже хуже.
Спасибо. У меня они все в бумажном виде есть, но кому-то может быть интересно почитать.
Пы.Сы. А ТЭЗ от какой-то периферии, похоже: сами машины, где использовались ТЭЗы такого (1-го) типа в середине 1980-х уже не выпускались.
А я вот предпочитаю прижимать к имени переменной/поля -- чтоб легче было видеть, что это ссылка/указатель на что-то, что слева (а слева тоже может быть указатель или ссылка, или вообще что-то многоэтажное). Отчасти, возможно, из-за того, что я слепой.
Но вообще, синтаксис Си отвратителен, а синтаксис объявлений -- отвратителен вдвойне.
Это-то понятно, но специалист обычно следит за развитием своего языка, а соответственно, C++11 новым для него не является -- даже если по работе он вообще пишет на чистом L&R C. Не было б в заголовке слова "новая" -- не было бы вопросов. Лучше было б, наверное, "современная" вместо "новая". Ну или что-то в этом роде -- в общем, чтоб не создавало иллюзий, будто речь пойдёт о C++23 или, на худой конец, С++20.
В самом начале цикла я писал об этом: всего несколько самых ранних микросхем 155-й серии, до К155ИП3 было далеко, как до Луны (она была освоена для производства ЕС-1033, что произошло лишь через несколько лет).