Статья претендует на максимально формальный, академический стиль. Так что позволю и я себе немного подушнить ;) в качестве обратной связи по ней. Всю статью, вероятно, разобрать в таком стиле не будет сил, но, надеюсь, по аналогии дальше автор сможет сам провести повторную вычитку. В случае заинтересованности в повышении её корректности ;) Однако, в любом случае, большое спасибо за статью, даже в существующем варианте! Полезно для изучения схемотехники.
В книгах со времен рассвета полупроводниковой импульсной силовой схемотехники отечественного (СССР) и зарубежного производства, авторы зачатую прибегают к рассказу принципов работы того или иного устройства основываясь лишь на базовых схемотехнических постулатах...
"основываясь лишь на базовых..." - "прибегают, основываясь" - начало деепричастного оборота, выделяется запятой.
Данная статья является попыткой автора систематически собрать воедино многие фрагменты знаний электроники и электротехники, с целью...
"Систематически" говорит о повторяемости действия, "собрать" - о завершённости. Путает, так как, если действие повторяемое, оно, скорее всего, ещё не завершено. Да, и зачем здесь запятая?
" В далее излагаемом материале" - лишний пробел в начале.
На схеме, помимо уже упомянутой другими комментаторами точки соединения R4-R5, не хватает точек у обмоток трансформатора, обозначающих их начала. Можно догадаться по логике, но это затрудняет разбор работы.
"При заряде конденсатора С1 в контуре: клемма источника переменного напряжения, резистор R1, диод VD1, ESR C" - что такое ESR? Термин не описан ни здесь, ни в конце. Лучше, как минимум, давать расшифровку терминов по мере ввода их в текст статьи.
"однако, в данном контуре в начальный момент ЭДС самоиндукции катушки Т1-2 по закону коммутации численно равно напряжению источника питания" - параллельно этой катушке стоит диод VD5 и конденсатор C3, последний - разряжен. Исходя из этого, напряжение на выводах катушки будет не больше напряжения падения на переходе диода. Током в этом контуре пренебрегать нельзя или нужно вводить какое-то ещё допущение.
"Но так как в первоначальный момент времени б-э переход транзистора представляет собой незаряженную ёмкость Cбэ, и его сопротивлением можно пренебречь." - союз "и" - лишний с учётом наличия вводной части "так как". Нужно убрать либо её, либо "и". Сейчас же выглядит как: "но так как ААА, и БББ".
"Это наводит в сердечнике трансформатора переменное магнитное поле, которое в свою очередь пронизывает вторичную, согласно включенную (относительно первичной Т1-1) логическую обмотку трансформатора Т1-2 и в ней" - перед "и" запятая - причастный оборот к слову "обмотку".
"Это наводит в сердечнике трансформатора переменное магнитное поле, которое в свою очередь пронизывает вторичную, согласно включенную (относительно первичной Т1-1) логическую обмотку трансформатора Т1-2 и в ней по закону Фарадея наводится ЭДС." - с учётом (6) сложно понять, как будет комбинироваться самоиндукция этой катушки и наведённая от T1-1 индукция. Конденсатор C3 итак бы заряжался по цепочке R2-C2-R3-VD5-R5, даже при отсутствии транзистора VT1, и в устоявшемся состоянии C2-C3 образовали бы ёмкостной делитель. Здесь же происходит сложный процесс, зависящий от количественных значений соответствующих элементов. "В сумме с постоянным током смещения R2, наводимый ток обмотки Т1-2 уводит режим работы транзистора в область насыщения." - про какой транзистор идёт речь? Мы говорим о транзисторе VT1? И к току R2-VT1(бэ)-R5 добавляется ток от C2-R3-T1_2? Хм, мне весьма сложно представить процесс комбинации токов этих двух путей без дополнительной информации о скорости процессов и относительных величинах элементов.
Дальнейший анализ, лично у меня в голове, обрастает чрезмерно большим количеством домыслов. Оценок реальных активно-реактивных параметров интересующих цепочек провести нельзя, так как номиналов элементов нет. Вынужден закончить чтение на этом месте.
Вот совершенно нет. "Динозавр gdb" - это, простите, про наиболее мощный и развивающийся отладчик, который разрабатывают и по сей день? Который имеет поддержку для кучи платформ? У которого куча gui-нашлёпок, если кому-то с консолью не совладать? Что до ОС, то для каждого пакета линукса (ок, говорим про Ubuntu/Debian для конкретности) есть пакет с отладочными символами и исходным кодом. Так что подцепиться отладчиком можно не просто так же просто, как показано в статье, да ещё и с исходным кодом! Вряд ли для windows будет исходный код. Конфиги в бОльшей части концентрируются в /etc, а реестр windows, в таком случае, тоже давно превратился в помойку, куда пихают всё все компоненты. Разбираться и там и там придётся. Взаимодействие компонент в windows не запутано? Оу-оу. Оно и запутано, и написано индусами внутри компании и не документировано. А компоненты в Линукс, так как пишутся зачастую, разными людьми/группами, имеют очень даже неплохую документацию по каждому такому компоненту отдельно. Документации по библиотечным функциям, говорите? Ну, вообще смешно. Мы о публичном API? Для большинства стандартных библиотек libc, glibc, gtk, qt - огромная масса док, не хуже MSDN. А что до внутренних функций типа той, что описана в статье, ну-ка покажите на неё документацию, и отдельно на компонент, который автор отлаживал? В Линуксе я не просто дебажил систему, как свой домашний проект, так ещё и пересобирал пару модулей из стандартной поставки дистрибутива, чтобы бажку пофиксить. И теперь они - часть системы.
Я много времени работал разработчиком под Windows до ухода к пингвинам. Windows до 7-ки включительно была вполне юзабельна, нетребовательна к ресурсам, стабильна, и не решала за меня, что мне лучше, чей это компьютер, и когда тут обновляться. Куда пошла компания мелких после этого, один шайтан ведает. Не хочется вообще теперь иметь дело с их поделиями вообще никогда.
Сказка ложь, да в ней намёк… :) Не важно, вымысел это, или нет. Ситуация очень жизненная. Это как какое-нибудь художественное произведение — важно, что хотел сказать автор, а не то, были ли у истории реальные прототипы.
Нет, не остановит. Это как поход к гадалке или взгляд в будущее через машину времени. Вроде тебе всё объяснили, всё понимаешь, а сделать с собой ничего не можешь :)
Интересное чтиво! Может буду немного резковат, это был похвальный и глупый поступок. Но все программисты делятся на тех, кто так сделал хотя-бы раз, и тех, кто так сделает обязательно (если не уйдёт в другую отрасль). Я тоже через это проходил. Да и сейчас приходится каждый день иметь дело с разным уровнем легосятины и очень аккуратно выбирать, что можно отрефакторить и где границы.
Очень интересный вопрос, который тут уже поднимали, и который я себе задаю всё чаще — а скольким людям захочется отрефакторить мой код. Ведь нет же идеального решения, а значит, как бы я не старался, будет другое мнение на то, как это должно тут выглядеть. Остаётся надеяться, что документирование идей над собственно кодом может помочь. Похоже на упреждающий разговор с будущим программистом: «хей, погоди ругать, я вот тут применил такой и такой концепт потому-то и потому-то».
Да, ну и держим в голове, что любой код завтра, в связи с дуновением другого политического ветерка, может быть выкинут. Даже идеальный.
Вообще, хорошая статья, чтобы показать её как-нибудь коллеге новичку, который норовит всё переписать на работе. Правда, он всё-равно попытается это несколько раз сделать…
Такая ситуация везде и всюду. И дело тут не в том, что «человек работает с неприятными вещами». А в том, что люди, собираясь в группы для создания какого-то продукта/услуги, образуют социальные системы, но почти никто не понимает, что такое «система» применительно к людям. Что такое «системный подход». Как обеспечивать стабильность системы. Вот и получается, что группа живёт «по наитию». Повезло, если руководитель группы «нутром чует», что работать с техническим долгом тоже надо, что и поддержка нужна более вменяемая, чем «ваш звонок очень важен для нас, перезагрузите PC».
Но вот отсутствие понимания системного подхода и приводит к тому, что живём от «с этим руководителем повезло, с тем — не повезло».
Вкратце. Факторы, обеспечивающие стабильность и устойчивость системы, нужно так же внимательно анализировать, как и факторы, обеспечивающие её рост. А у нас видят только последние (о, мега-бабло попёрло, сейчас купим жип и яхту!). Если наступил значительный рост (ба..., да мы уже офис в центре имеем в своём здании), то соответствующим образом нужно над стабильностью думать. Вводить нормы и метрики по багам, стабильности в CI, нефункциональным показателям ПО (не выросло ли потребление памяти, не стало ли медленнее). Но это от головы должно идти. В смысле, от владельцев бизнеса. Средний уровень управления пришёл в компанию только для максимизации своей прибыли (и тут нет ничего предосудительного).
Но всё это полная лажа. Если: а) владельцам бизнеса «итак норм», бабло течёт «в достаточной мере», а мнение леммингов — как надоедливый зуд комара (и топ-IT компании могут себе это позволить ещё на десятилетия с такой подушкой безопасности); б) владельцы всё это понимают, но в условиях внешней политической конъюктуры живут днём сегодняшним, потому что «завтра может и не быть», так что «утром деньги, вечером… может и стулья поставлять не придётся».
Спасибо за статью! Было интересно попробовать ручками это проделать. Садо-мазо, конечно, но для составления собственной картины полезно.
Кстати, один нюанс заинтересовал. Обычно я трепетно отношусь к предупреждениям компилятора, поэтому собираю с -Wall. Попробовал и тут, получив предупреждения incompatible types. Потому что в функции animal_tiger_class_init указатель на функцию parent_class->say_meow принимает функцию с другим аргументом. И потому что в тестовом main «animal_cat_say_meow(tiger)» тоже принимает указатель на cat, а мы передаём tiger. Это не ошибка в данном случае, но warnings раздражают. Есть ли способ в реальной ситуации писать такие моменты более корректно, чтобы не приходилось на весь проект -Wno-incompatible-pointer-types выставлять? (в animal_tiger_class_init я могу явное преобразование типа писать, но в «пользовательском коде», где «виртуальная» функция animal_cat_say_meow вызывается, как быть? В каждом месте преобразование (AnimalCat*)ptr писать?)
Попробовал тот же исходник, apr оставил, omp убрал. Результаты для C и C++ плавают на одном и том же уровне. Вы по одному эксперименту делали? Я по 5 раз запускаю. Опции одни и те же: -O3 -Wall -march=native.
11.79
11.81
12.28
11.88
11.87
mean: 11.92
C++
12.16
11.90
12.41
11.82
11.85
mean: 12.02
Имхо, подобные расхождения, это уже малоинформативно, тут куча разных факторов типа фазы луны роль играть начинают. Наверное, не стоило пытаться сравнивать одну и ту же программу, собранную gcc и g++.
Подскажите, пожалуйста, а какова вероятность «подвесить ядро», если в процедуре wait_for_transaction_finish аппаратура так и не выставит бит готовности, или, скажем, сделает это через пол-минуты? Я не очень разбираюсь в архитектуре ядра, мне интересно, в каком потоке работает этот код, и что может оказаться отложенным из-за такого ожидания? Просто чтение из аппаратуры обычно делается на основе прерываний, которые и сигнализируют в таких случаях, что данные готовы.
Я тут в качестве паранойи решил проверить, что если скомпилировать чистую C программу в C++ режиме. Взял ту же C версию, что использовал для статьи, вообще не переписывал, только расширение файла на cpp поменял, чтобы cmake считал, что у меня тут C++. В паре мест, конечно, пришлось синтаксически подправить, но без изменения структуры/логики вообще. Ожидал, что версия C и версия «C в C++ режиме» будут давать абсолютно одно и то же. Ну, погрешность измерения, понятно. Но результаты должны перекрываться с учётом погрешности. Был удивлён, когда обнаружил, что результаты не перекрываются. Да, просадка по производительности псевдо-C++ версии была всего в 2%. Но она была заметна. Удивлён.
Так что для себя сделал вывод, что, если какой-то кусок проекта хочу написать на C, то это будет чистый C, компилируемый C компилятором. Если уж выдавливать по максимуму.
(Компилятор, как и прежде — gcc-5.4.0 в Ubuntu 16.04)
На рабочих проектах у меня clang, как ни странно, тоже слегка проседает по отношению к gcc. Я имею ввиду именно генерируемый им код. Сам компилятор, при этом, компилирует быстрее. И сообщения об ошибках у него более точные. Поэтому мы его в continious integration гоняем.
Ну, здесь цифры вообще субъективны вконец. То есть, я просто из головы постараюсь вспомнить, сколько вечеров факультативно я потратил на это. Скажем так, Написание на C заняло три вечера. И я сделал много ошибок с работой с указателями и неправильного преобразования типов, которые, естественно, компилятором не отслеживались. То есть, я сидел в gdb и пытался понять, а что это вообще тут за байты. Скажем, вечер.
На C++ я переписал всё это за вечер, и программа сразу получилась корректной. Благодарить ли тут C++ или уже мою подкованность в только что реализованном алгоритме — не знаю. А вот на оптимизацию со всякими valgrind'ами ещё несколько вечеров ушло.
Кстати, одним пакером я проверял другой, потому что они, разумеется, должны выдавать абсолютно одинаковый результат на одном и том же входном файле. И по ходу оптимизации я пару раз ломал C++ имплементацию. И нашёл ещё таким же образом ошибку в C версии. Но тут уже это ни к одному ни к другому не приплюсуешь.
Подскажите, пожалуйста, какие действия можно выразить в программе на языке C, которых нельзя было бы выразить тем же способом на языке C++? (мелкие синтаксические различия типа переиспользования ключевого слова auto не в счёт).
priority_queue реализовано самостоятельно. И операции с битовыми массивами — тоже. Чтобы иметь возможность сравнивать как можно более близкие имплементации из C и C++. Более того, про vector выше уже выразили несколько резковатое мнение. С которым я, в прочем, согласен на 100%.
Статья претендует на максимально формальный, академический стиль. Так что позволю и я себе немного подушнить ;) в качестве обратной связи по ней. Всю статью, вероятно, разобрать в таком стиле не будет сил, но, надеюсь, по аналогии дальше автор сможет сам провести повторную вычитку. В случае заинтересованности в повышении её корректности ;) Однако, в любом случае, большое спасибо за статью, даже в существующем варианте! Полезно для изучения схемотехники.
В книгах со времен рассвета полупроводниковой импульсной силовой схемотехники отечественного (СССР) и зарубежного производства, авторы зачатую прибегают к рассказу принципов работы того или иного устройства основываясь лишь на базовых схемотехнических постулатах...
"основываясь лишь на базовых..." - "прибегают, основываясь" - начало деепричастного оборота, выделяется запятой.
Данная статья является попыткой автора систематически собрать воедино многие фрагменты знаний электроники и электротехники, с целью...
"Систематически" говорит о повторяемости действия, "собрать" - о завершённости. Путает, так как, если действие повторяемое, оно, скорее всего, ещё не завершено. Да, и зачем здесь запятая?
" В далее излагаемом материале" - лишний пробел в начале.
На схеме, помимо уже упомянутой другими комментаторами точки соединения R4-R5, не хватает точек у обмоток трансформатора, обозначающих их начала. Можно догадаться по логике, но это затрудняет разбор работы.
"При заряде конденсатора С1 в контуре: клемма источника переменного напряжения, резистор R1, диод VD1, ESR C" - что такое ESR? Термин не описан ни здесь, ни в конце. Лучше, как минимум, давать расшифровку терминов по мере ввода их в текст статьи.
"однако, в данном контуре в начальный момент ЭДС самоиндукции катушки Т1-2 по закону коммутации численно равно напряжению источника питания" - параллельно этой катушке стоит диод VD5 и конденсатор C3, последний - разряжен. Исходя из этого, напряжение на выводах катушки будет не больше напряжения падения на переходе диода. Током в этом контуре пренебрегать нельзя или нужно вводить какое-то ещё допущение.
"Но так как в первоначальный момент времени б-э переход транзистора представляет собой незаряженную ёмкость Cбэ, и его сопротивлением можно пренебречь." - союз "и" - лишний с учётом наличия вводной части "так как". Нужно убрать либо её, либо "и". Сейчас же выглядит как: "но так как ААА, и БББ".
"Это наводит в сердечнике трансформатора переменное магнитное поле, которое в свою очередь пронизывает вторичную, согласно включенную (относительно первичной Т1-1) логическую обмотку трансформатора Т1-2 и в ней" - перед "и" запятая - причастный оборот к слову "обмотку".
"Это наводит в сердечнике трансформатора переменное магнитное поле, которое в свою очередь пронизывает вторичную, согласно включенную (относительно первичной Т1-1) логическую обмотку трансформатора Т1-2 и в ней по закону Фарадея наводится ЭДС." - с учётом (6) сложно понять, как будет комбинироваться самоиндукция этой катушки и наведённая от T1-1 индукция. Конденсатор C3 итак бы заряжался по цепочке R2-C2-R3-VD5-R5, даже при отсутствии транзистора VT1, и в устоявшемся состоянии C2-C3 образовали бы ёмкостной делитель. Здесь же происходит сложный процесс, зависящий от количественных значений соответствующих элементов. "В сумме с постоянным током смещения R2, наводимый ток обмотки Т1-2 уводит режим работы транзистора в область насыщения." - про какой транзистор идёт речь? Мы говорим о транзисторе VT1? И к току R2-VT1(бэ)-R5 добавляется ток от C2-R3-T1_2? Хм, мне весьма сложно представить процесс комбинации токов этих двух путей без дополнительной информации о скорости процессов и относительных величинах элементов.
Дальнейший анализ, лично у меня в голове, обрастает чрезмерно большим количеством домыслов. Оценок реальных активно-реактивных параметров интересующих цепочек провести нельзя, так как номиналов элементов нет. Вынужден закончить чтение на этом месте.
Вот совершенно нет. "Динозавр gdb" - это, простите, про наиболее мощный и развивающийся отладчик, который разрабатывают и по сей день? Который имеет поддержку для кучи платформ? У которого куча gui-нашлёпок, если кому-то с консолью не совладать? Что до ОС, то для каждого пакета линукса (ок, говорим про Ubuntu/Debian для конкретности) есть пакет с отладочными символами и исходным кодом. Так что подцепиться отладчиком можно не просто так же просто, как показано в статье, да ещё и с исходным кодом! Вряд ли для windows будет исходный код. Конфиги в бОльшей части концентрируются в /etc, а реестр windows, в таком случае, тоже давно превратился в помойку, куда пихают всё все компоненты. Разбираться и там и там придётся. Взаимодействие компонент в windows не запутано? Оу-оу. Оно и запутано, и написано индусами внутри компании и не документировано. А компоненты в Линукс, так как пишутся зачастую, разными людьми/группами, имеют очень даже неплохую документацию по каждому такому компоненту отдельно. Документации по библиотечным функциям, говорите? Ну, вообще смешно. Мы о публичном API? Для большинства стандартных библиотек libc, glibc, gtk, qt - огромная масса док, не хуже MSDN. А что до внутренних функций типа той, что описана в статье, ну-ка покажите на неё документацию, и отдельно на компонент, который автор отлаживал? В Линуксе я не просто дебажил систему, как свой домашний проект, так ещё и пересобирал пару модулей из стандартной поставки дистрибутива, чтобы бажку пофиксить. И теперь они - часть системы.
Я много времени работал разработчиком под Windows до ухода к пингвинам. Windows до 7-ки включительно была вполне юзабельна, нетребовательна к ресурсам, стабильна, и не решала за меня, что мне лучше, чей это компьютер, и когда тут обновляться. Куда пошла компания мелких после этого, один шайтан ведает. Не хочется вообще теперь иметь дело с их поделиями вообще никогда.
Очень интересный вопрос, который тут уже поднимали, и который я себе задаю всё чаще — а скольким людям захочется отрефакторить мой код. Ведь нет же идеального решения, а значит, как бы я не старался, будет другое мнение на то, как это должно тут выглядеть. Остаётся надеяться, что документирование идей над собственно кодом может помочь. Похоже на упреждающий разговор с будущим программистом: «хей, погоди ругать, я вот тут применил такой и такой концепт потому-то и потому-то».
Да, ну и держим в голове, что любой код завтра, в связи с дуновением другого политического ветерка, может быть выкинут. Даже идеальный.
Вообще, хорошая статья, чтобы показать её как-нибудь коллеге новичку, который норовит всё переписать на работе. Правда, он всё-равно попытается это несколько раз сделать…
Но вот отсутствие понимания системного подхода и приводит к тому, что живём от «с этим руководителем повезло, с тем — не повезло».
Вкратце. Факторы, обеспечивающие стабильность и устойчивость системы, нужно так же внимательно анализировать, как и факторы, обеспечивающие её рост. А у нас видят только последние (о, мега-бабло попёрло, сейчас купим жип и яхту!). Если наступил значительный рост (ба..., да мы уже офис в центре имеем в своём здании), то соответствующим образом нужно над стабильностью думать. Вводить нормы и метрики по багам, стабильности в CI, нефункциональным показателям ПО (не выросло ли потребление памяти, не стало ли медленнее). Но это от головы должно идти. В смысле, от владельцев бизнеса. Средний уровень управления пришёл в компанию только для максимизации своей прибыли (и тут нет ничего предосудительного).
Но всё это полная лажа. Если: а) владельцам бизнеса «итак норм», бабло течёт «в достаточной мере», а мнение леммингов — как надоедливый зуд комара (и топ-IT компании могут себе это позволить ещё на десятилетия с такой подушкой безопасности); б) владельцы всё это понимают, но в условиях внешней политической конъюктуры живут днём сегодняшним, потому что «завтра может и не быть», так что «утром деньги, вечером… может и стулья поставлять не придётся».
Кстати, один нюанс заинтересовал. Обычно я трепетно отношусь к предупреждениям компилятора, поэтому собираю с -Wall. Попробовал и тут, получив предупреждения incompatible types. Потому что в функции animal_tiger_class_init указатель на функцию parent_class->say_meow принимает функцию с другим аргументом. И потому что в тестовом main «animal_cat_say_meow(tiger)» тоже принимает указатель на cat, а мы передаём tiger. Это не ошибка в данном случае, но warnings раздражают. Есть ли способ в реальной ситуации писать такие моменты более корректно, чтобы не приходилось на весь проект -Wno-incompatible-pointer-types выставлять? (в animal_tiger_class_init я могу явное преобразование типа писать, но в «пользовательском коде», где «виртуальная» функция animal_cat_say_meow вызывается, как быть? В каждом месте преобразование (AnimalCat*)ptr писать?)
11.79
11.81
12.28
11.88
11.87
mean: 11.92
C++
12.16
11.90
12.41
11.82
11.85
mean: 12.02
Имхо, подобные расхождения, это уже малоинформативно, тут куча разных факторов типа фазы луны роль играть начинают. Наверное, не стоило пытаться сравнивать одну и ту же программу, собранную gcc и g++.
Так что для себя сделал вывод, что, если какой-то кусок проекта хочу написать на C, то это будет чистый C, компилируемый C компилятором. Если уж выдавливать по максимуму.
(Компилятор, как и прежде — gcc-5.4.0 в Ubuntu 16.04)
На C++ я переписал всё это за вечер, и программа сразу получилась корректной. Благодарить ли тут C++ или уже мою подкованность в только что реализованном алгоритме — не знаю. А вот на оптимизацию со всякими valgrind'ами ещё несколько вечеров ушло.
Кстати, одним пакером я проверял другой, потому что они, разумеется, должны выдавать абсолютно одинаковый результат на одном и том же входном файле. И по ходу оптимизации я пару раз ломал C++ имплементацию. И нашёл ещё таким же образом ошибку в C версии. Но тут уже это ни к одному ни к другому не приплюсуешь.