Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>На час она тому, кто регулярно пишет парсеры/интерпретаторы выражений, или знаком с готовыми библиотеками.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>... ЕМ>Я не использую ни defined (), ни #ifdef/#ifndef — это неслабый источник труднообнаруживаемых глюков. Только #if.
#ifdef xxxx это частный случай от #if defined(xxxx). Так что вы что-то путаете.
Re[5]: Утилита для удаления из текста C++ блоков #if с подходящими условиями
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здравствуйте, SaZ, Вы писали:
SaZ>>Это же основы ООП.
ЕМ>Ну давайте, расскажите мне, как с помощью знания "основ ООП" условно добавить в константную таблицу (массив структур) дополнительную структуру в зависимости от условия. И так, чтобы это не выглядело по-идиотски и монстроидально, и не требовало отдельного описания для понимания того, как и зачем это сделано.
Да хоть самописной кодогенерацией, если вы не можете осилить нормальную архитектуру. Пояснять бесплатно не буду, наймите за деньги нормального senior программиста.
SaZ>>И более чистый код. ЕМ>"Чистый код ради идеи чистого кода" — это тупое сектантство. Если код после преобразования к "чистому" виду теряет прозрачность и понятность — значит, с идеей "чистоты" что-то не так.
Грязный код просто потому что не умеете/не хотите чистый — это сектанство.
SaZ>>Если вам не нравится ООП подход, который тут отлично ложится ЕМ>Мне нравится ООП-подход, я его регулярно использую, но только там, куда он ложится естественно, а не путем натягивания.
Я пока этого не заметил. Судя по многим сообщениям у вас типичный "си с классами" вместо нормального си++.
SaZ>>городите простыни из неконтролируемых #ifdef/endif. ЕМ>Вы в состоянии представить себе что-то промежуточное между "полное отсутствие #if" и "простыни из #if"?
Давно отказался от таких практик в сторону нормальных билд систем и архитектур. Немного pimpl магии и всё работает как часы.
Re[10]: Утилита для удаления из текста C++ блоков #if с подхо
Здравствуйте, SaZ, Вы писали:
SaZ>Да хоть самописной кодогенерацией
Зачем мне самописная кодогенерация, если задача элементарно, адекватно и удобно решается через #if?
SaZ>если вы не можете осилить нормальную архитектуру.
Не путайте нормальное с сакральным.
SaZ>Грязный код просто потому что не умеете/не хотите чистый — это сектанство.
В тех местах, о которых идет речь, код вполне чистый. Если он не удовлетворяет каким-то высшим законам — это проблема проповедников тех законов.
SaZ>у вас типичный "си с классами" вместо нормального си++.
"Нормального C++" не существует. Существует несколько сект со сверхидеями "это нужно делать только вот так, а если не так — это не C++". Что характерно, правила для "вот так" меняются по мере изменения стандартов C++, так что то, что какое-то время назад было "типичным C++", со временем становится "совсем не C++". Мне совершенно по барабану, какие в этих сектах нынче правила, я тупо использую возможности языка, подходящие для моих, а не высших целей.
SaZ>Давно отказался от таких практик в сторону нормальных билд систем и архитектур.
Да и ради бога. Я добавляю дополнительные сущности, когда они облегчают мне жизнь, а не когда они становятся модными и прогрессивными.
Re[7]: Утилита для удаления из текста C++ блоков #if с подхо
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Что характерно, правила для "вот так" меняются по мере изменения стандартов C++, так что то, что какое-то время назад было "типичным C++", со временем становится "совсем не C++".
Что характерно, это происходит не просто так. Например, для C++ до C++98 (особенно до появления в C++ шаблонов) типично было делать так:
class B {
public:
A * make_A() { return new A(); }
...
};
...
A * a = b->make_A();
...
delete a;
Но вот появляется C++98 и типично становится делать так:
class B {
public:
std::auto_ptr<A> make_A() { return std::auto_ptr<A>(new A()); }
...
};
...
std::auto_ptr<A> a = b->make_A();
... // Стало легче, не нужно делать delete.
Потом приходит C++11/14 и типично становится делать так:
class B {
public:
auto make_A() { return std::make_unique<A>(); }
...
};
...
auto a = b->make_A();
...
Ну и как-то само собой получается, что то, что не находит применения в актуальном C++ (из-за потенциальных багов или неудобств), типичным C++ считать перестается. Эволюция и прогресс, ничего не поделать.
ЕМ>Мне совершенно по барабану, какие в этих сектах нынче правила, я тупо использую возможности языка, подходящие для моих, а не высших целей.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>"Мне совершенно по барабану, какие в этих сектах нынче правила, я тупо использую возможности языка, подходящие для моих, а не высших целей.
Ну и говнокодил бы себе потихоньку, а зачем же из себя эталон изображать? Зачем себя на большинство натягивать, зачем регулярно устраивать холивары и зачем козырять каким-то невероятным опытом, когда реальный опыт стремится к нулю?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>... SaZ>>Давно отказался от таких практик в сторону нормальных билд систем и архитектур. ЕМ>Да и ради бога. Я добавляю дополнительные сущности, когда они облегчают мне жизнь, а не когда они становятся модными и прогрессивными.
Нормальная архитектура всегда была в моде с момента появления первых высокоуровневых языков программирования. Но всегда были люди, которые "вжух-вжух и в продакшн" и потом удивлялись, почему же так сложно делать с проектом тривиальные вещи. Вы явно из них, потому что даже не пробуете.
В общем, вам предложили нормальное решение, вы продолжаете натягивать сову на глобус и упорно сопротивляться. Разбираться в причинах (много кода переделывать / вам лень / вам не хватает квалификации) мне не досуг, желаю успехов.
Re[8]: Утилита для удаления из текста C++ блоков #if с подхо
Здравствуйте, so5team, Вы писали:
S>для C++ до C++98 (особенно до появления в C++ шаблонов) типично было делать так
Шаблоны были фундаментальным нововведением в языке — как и ранее классы. Они слишком многое поменяли в практике программирования. Было бы странно, останься подходы прежними.
Но программа на C++ без шаблонов не становится "программой на C с классами" — она остается "программой на C++". Можно говорить о "программе на C++ 2.0", "программе на C++11" и т.п.
S>Но вот появляется C++98 и типично становится делать так: S>
Здесь принципиально лишь использование шаблона, без которого такая конструкция невозможна. А вот использование именно готового варианта из std — непринципиально. Программа на C, использующая собственные реализации strlen/strcpy и прочего, не перестает быть "программой на C", даже если не будет использовать вообще ни одной функции из libc.
S>Потом приходит C++11/14 и типично становится делать так: S>
S> auto make_A() { return std::make_unique<A>(); }
S>
Я предпочитаю использовать auto только в шаблонах, а вне их — только там, где ошибка в типе не влечет неявных глюков. Отсутствие auto, лямбда-функций или чего-то еще тоже не выводит программу из множества "программ на C++".
S>то, что не находит применения в актуальном C++ (из-за потенциальных багов или неудобств), типичным C++ считать перестается.
Это совершенно нормально, ничего не имею против. Но речь была не о "типичном C++", а о неком каноническом наборе, без которого программа рискует быть подвергнута остракизму.
S>И как называется ваша секта?
У нас нет секты. Секта предполагает набор жестких правил, нарушение которых преследуется лишь потому, что возникает опасность снижения авторитета руководителей и разрушения секты. Хватит и того, что я много лет избегал использования goto для выхода из блока, еще в ранней юности чрезмерно впечатлившись идеей структурного программирования, и применяя извращения вроде do { } while (false).
S>"Не учите меня C++"?
"Не учите меня (и других тоже) единственно правильному C++" Учите своих студентов, наемных работников и тех, кто от вас зависит.
Re[11]: Утилита для удаления из текста C++ блоков #if с подх
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здравствуйте, SaZ, Вы писали:
SaZ>>#ifdef xxxx это частный случай от #if defined(xxxx). Так что вы что-то путаете.
ЕМ>Я ничего не путаю — выше написано "Я не использую ни defined (), ни #ifdef/#ifndef".
Конкретики можно тогда, что у вас там под #if?
С вашей постановкой задачи — мол полноценный парсер мне не надо, переделывать код не хочу, вам не нужно хорошее решение. Вам нужен полноценный костыль, типа этого
Здравствуйте, Евгений Музыченко, Вы писали:
S>>то, что не находит применения в актуальном C++ (из-за потенциальных багов или неудобств), типичным C++ считать перестается.
ЕМ>Это совершенно нормально, ничего не имею против. Но речь была не о "типичном C++", а о неком каноническом наборе, без которого программа рискует быть подвергнута остракизму.
Ну вот мне буквально сегодня довелось увидеть в коде в реализации PImpl голый владеющий указатель. Именно так, без std::unique_ptr.
И, естественно, операторы/конструкторы копирования/перемещения не былы ни определены, ни объявлены как delete. Т.е. компилятор сгенерирует их по умолчанию.
Назвать такой код "нормальным C++" или "типичным С++" у меня не получится. А вот обозвать "Си с классами" -- запросто, и это еще будет очень мягко сказано.
Не зря говорят, что уставы и правила безопасности написаны кровью. Точно так же и "нормальный C++" определяется количеством отстреленных ног.
S>>И как называется ваша секта? S>>"Не учите меня C++"?
ЕМ>"Не учите меня (и других тоже) единственно правильному C++"
Значит угадал.
Re[8]: Утилита для удаления из текста C++ блоков #if с подходящими условиями
Здравствуйте, SaZ, Вы писали:
SaZ>Нормальная архитектура всегда была в моде
Проблема лишь в том, какую архитектуру называть "нормальной". Это больше вопрос школы, нежели архитектуры. Тот же C поначалу многие называли "недоязыком" и предрекали ему скорое забвение. И оно вполне могло наступить, сойдись звезды чуть иначе — все это можно регулярно наблюдать с любой модой. Взлетело бы нечто принципиально похожее, но другое, и далее развивалось бы сильно иначе.
SaZ>всегда были люди, которые "вжух-вжух и в продакшн" и потом удивлялись, почему же так сложно делать с проектом тривиальные вещи. Вы явно из них
Пусть Вам и дальше так кажется.
SaZ>потому что даже не пробуете.
Многое из предлагаемого я не пробую просто потому, что оно требует изменения подхода. В чем-то новом, возможно, и применю другие подходы, а переделывать то, что давно сложилось, лишь потому, что "нынче это считается модным" — нунах.
SaZ>вам предложили нормальное решение
В моем случае создавать классы там, где самым естественным образом используются #if — ненормальное решение. А там, где естественным образом могли бы использоваться классы, они давным-давно созданы.
Re[9]: Утилита для удаления из текста C++ блоков #if с подходящими условиями
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>...
SaZ>>всегда были люди, которые "вжух-вжух и в продакшн" и потом удивлялись, почему же так сложно делать с проектом тривиальные вещи. Вы явно из них ЕМ>Пусть Вам и дальше так кажется. ЕМ>В моем случае создавать классы там, где самым естественным образом используются #if — ненормальное решение. А там, где естественным образом могли бы использоваться классы, они давным-давно созданы.
Сами себе противоречите, в одном сообщении причём =)
Re[12]: Утилита для удаления из текста C++ блоков #if с подх
Здравствуйте, SaZ, Вы писали:
SaZ>Конкретики можно тогда, что у вас там под #if?
Так была ж конкретика — "Если какие-то стандартные макросы поступают в виде "определено / не определено", они переделываются в локальные со значениями 0/1". А локальные "логические" макросы, которые определяю я, имеют такие значения изначально. Под #if, соответственно, или одиночные макросы, или конструкции вида "xxx || yyy", "xxx && yyy", а иногда и более сложные.
SaZ>вам не нужно хорошее решение. Вам нужен полноценный костыль
Так для этой цели и нужен костыль, поскольку такая обработка требуется достаточно редко. Поэтому меня интересует, существует ли готовый костыль, более удобный, чем я уже использую. Делать что-то хоть заново, хоть дорабатывать существующее, имеет смысл лишь тогда, когда это способно сэкономить время в будущем.
Re[10]: Утилита для удаления из текста C++ блоков #if с подхо
Здравствуйте, so5team, Вы писали:
S>Ну вот мне буквально сегодня довелось увидеть в коде в реализации PImpl голый владеющий указатель. Именно так, без std::unique_ptr. S>И, естественно, операторы/конструкторы копирования/перемещения не былы ни определены, ни объявлены как delete. Т.е. компилятор сгенерирует их по умолчанию.
Да и ради бога. Если объекты этих классов никому не придет в голову ни копировать, ни перемещать, кроме полных идиотов, от которых не спасут определения/delete, то зачем? Чтоб было красиво и канонiчно?
S>Назвать такой код "нормальным C++" или "типичным С++" у меня не получится. А вот обозвать "Си с классами" -- запросто, и это еще будет очень мягко сказано.
Да и ради бога. Кто-то ведь и инструкцию к микроволновке, которая явно не запрещает сушить в ней домашних животных, обзовет плохой и неправильной.
Re[11]: Утилита для удаления из текста C++ блоков #if с подх
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Да и ради бога. Если объекты этих классов никому не придет в голову ни копировать, ни перемещать, кроме полных идиотов, от которых не спасут определения/delete, то зачем? Чтоб было красиво и канонiчно?
ЕМ>Да и ради бога. Кто-то ведь и инструкцию к микроволновке, которая явно не запрещает сушить в ней домашних животных, обзовет плохой и неправильной.
Демагогия, возведенная в степень пещерного невежества.
P.S. Его величество человечский фактор способен на такое, до чего ни один идиот не додумается. Для того, чтоб моймать нежелательное копирование достаточно просто не дожать символ '&' в типе формального параметра. И будешь ты такие ошибки ловить на проде долго и мучительно. А вот те, кто не понимают, что людям свойственно ошибаться, действительно идиоты.
Здравствуйте, Евгений Музыченко, Вы писали:
S>>Ну вот мне буквально сегодня довелось увидеть в коде в реализации PImpl голый владеющий указатель. Именно так, без std::unique_ptr. S>>И, естественно, операторы/конструкторы копирования/перемещения не былы ни определены, ни объявлены как delete. Т.е. компилятор сгенерирует их по умолчанию.
ЕМ>Да и ради бога. Если объекты этих классов никому не придет в голову ни копировать, ни перемещать, кроме полных идиотов, от которых не спасут определения/delete, то зачем? Чтоб было красиво и канонiчно?
Фокус в том, что спасут. В этом-то и весь фокус.
Re[12]: Утилита для удаления из текста C++ блоков #if с подх
Здравствуйте, rg45, Вы писали:
R>Демагогия, возведенная в степень пещерного невежества.
С броневичка не упадите.
R>достаточно просто не дожать символ '&' в типе формального параметра.
Обычно большинство функций дублируется объявлениями, так что это придется повторить дважды. А там, где только определение, такое достаточно хорошо видно глазами. Особенно тем, кто не лепит "&" ни к типу, ни к переменной, хотя это предписывает "канонiчный стиль".
Re[13]: Утилита для удаления из текста C++ блоков #if с подх
Здравствуйте, Евгений Музыченко, Вы писали:
R>>достаточно просто не дожать символ '&' в типе формального параметра.
ЕМ>Обычно большинство функций дублируется объявлениями, так что это придется повторить дважды. А там, где только определение, такое достаточно хорошо видно глазами.
Опыт показывает, что и не достаточно, и не видно, и не хорошо.
Re[13]: Утилита для удаления из текста C++ блоков #if с подх
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>С броневичка не упадите.
А-ха-ха! Ты, наверное, сам себе кажешься очень остроумным, судя по непрекращающимся попыткам пошутить.
ЕМ>Обычно большинство функций дублируется объявлениями, так что это придется повторить дважды. А там, где только определение, такое достаточно хорошо видно глазами. Особенно тем, кто не лепит "&" ни к типу, ни к переменной, хотя это предписывает "канонiчный стиль".
Рассуждения типичного говнокодера. Не дай Боже сделать что-то по-нормальному. Все на соплях и все через жопу, с перекладыванием ответственности на кого-то.
