Здравствуйте, Евгений Музыченко, Вы писали:
CC>>Если этот класс доступен для использования то рано или поздно кто нить найдёт применение.
ЕМ>Тут мы снова приходим к вопросу об упорядочении рисков. Если копирование/перемещение — самое опасное, что можно сделать с объектом класса, то класс, безусловно, необходимо от этого защитить. А если возможность неправильного использования невозможно исключить полностью, то первым делом нужно заботиться о наиболее опасных ее вариантах. Скорее всего, случайное копирование/перемещение среди них будет далеко не на первых местах, а технической возможности исключить наиболее опасные варианты может попросту не оказаться.
Да, б**дь! Пусть уж простят меня модераторы.
Выбор, начиная с C++11 (а это, б**дь, уже двенадцать(!!!) лет как) простой. Либо:
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здравствуйте, SaZ, Вы писали:
SaZ>>Это же основы ООП.
ЕМ>Ну давайте, расскажите мне, как с помощью знания "основ ООП" условно добавить в константную таблицу (массив структур) дополнительную структуру в зависимости от условия. И так, чтобы это не выглядело по-идиотски и монстроидально, и не требовало отдельного описания для понимания того, как и зачем это сделано.
Да хоть самописной кодогенерацией, если вы не можете осилить нормальную архитектуру. Пояснять бесплатно не буду, наймите за деньги нормального senior программиста.
SaZ>>И более чистый код. ЕМ>"Чистый код ради идеи чистого кода" — это тупое сектантство. Если код после преобразования к "чистому" виду теряет прозрачность и понятность — значит, с идеей "чистоты" что-то не так.
Грязный код просто потому что не умеете/не хотите чистый — это сектанство.
SaZ>>Если вам не нравится ООП подход, который тут отлично ложится ЕМ>Мне нравится ООП-подход, я его регулярно использую, но только там, куда он ложится естественно, а не путем натягивания.
Я пока этого не заметил. Судя по многим сообщениям у вас типичный "си с классами" вместо нормального си++.
SaZ>>городите простыни из неконтролируемых #ifdef/endif. ЕМ>Вы в состоянии представить себе что-то промежуточное между "полное отсутствие #if" и "простыни из #if"?
Давно отказался от таких практик в сторону нормальных билд систем и архитектур. Немного pimpl магии и всё работает как часы.
Re: Утилита для удаления из текста C++ блоков #if с подходящими условиями
. Тогда посоветовали cpp-partial, но он не подошел — понимает только #ifdef/#ifndef, а у меня все условия на #if, чтобы не нарываться на проблемы из-за ошибок в написании имен.
Если не пытаться сделать универсальный всемогутор, — то такая штука пишется на скриптовом языке за пару часов. Ну, за день.
Только надо с самого начала договориться об определённом стиле кода.
Условно говоря,
// ZAKAZCHIK - параметр, приезжающий из настроек проекта
// константы заказчиков - все с одним и тем же префиксом#define ZAKAZCHIK_XXX 1
#define ZAKAZCHIK_YYY 2
#define ZAKAZCHIK_PIDORAS 321 // это имя мы не должны показывать, естественно#if ZAKAZCHIK == ZAKAZCHIK_XXX // допускается только ==
...
#elif ZAKAZCHIK == ZAKAZCHIK_YYY || ZAKAZCHIK == ZAKAZCHIK_ZZZ // допускаются только дизъюнкции
...
#else// ZAKAZCHIK - комментарий обязателен (ну или давайте, играйте в разбор деревьев if/def/ndef-elif-else-endif)
...
#endif// ZAKAZCHIK
static_assert(ZAKAZCHIK != ZAKAZCHIK_PIDORAS); // нужно сделать подстановки констант при рендеринге проекта для заказчика
Забег по строкам файла
def cleanup(lines, prefix, values_dict, actual_value):
# prefix = 'ZAKAZCHIK'
# values_dict = {'ZAKAZCHIK_XXX':1, 'ZAKAZCHIK_YYY':2, 'ZAKAZCHIK_PIDORAS':321}
# actual_value = 'ZAKAZCHIK_PIDORAS'
ifs_stack = [] # стек if-ов и значение условий в них (пары: "уже встретили true" и "прямо сейчас true")
right_now = True # текущее состояние - "выводить строку или нет?"
define update_right_now():
nonlocal right_now, ifs_stack
right_now = all(now for _,now in ifs_stack)
for line in lines:
# обмажь регекспами потом, а пока приколотим количество пробелов гвоздямиif line.startswith(f'#define {prefix}'): # #define ZAKAZCHIK...continue# выкидываем такие дефайныif line.startswith(f'#if {prefix}'):
cond = eval_condition(line, prefix, values_dict, actual_value)
ifs_stack.append((cond,cond))
update_right_now()
continue
elif line.startswith(f'#elif {prefix}'):
assert ifs_stack
was, now = ifs_stack[-1]
cond = not was and eval_condition(line, prefix, values_dict, actual_value)
ifs_stack[-1] = was or cond, cond
update_right_now()
continue
elif line.startswith(f'#else // {prefix}'):
assert ifs_stack
was, now = ifs_stack[-1]
cond = not was
ifs_stack[-1] = was or cond, cond
update_right_now()
continue
elif line.startswith(f'#endif // {prefix}'):
assert ifs_stack
ifs_stack.pop()
update_right_now()
continue
if not right_now:
continue
if prefix not in line:
yield line
else:
yield substitute_appearances(line, prefix, values_dict, actual_value)
И т.д.
Понятное дело, выше — говнокод. Его можно вылизать и ускорить в разы, но это уже стоит денег.
Перекуём баги на фичи!
Re[4]: Утилита для удаления из текста C++ блоков #if с подходящими условиями
Здравствуйте, SaZ, Вы писали:
SaZ>Это же основы ООП.
Ну давайте, расскажите мне, как с помощью знания "основ ООП" условно добавить в константную таблицу (массив структур) дополнительную структуру в зависимости от условия. И так, чтобы это не выглядело по-идиотски и монстроидально, и не требовало отдельного описания для понимания того, как и зачем это сделано.
SaZ>И более чистый код.
"Чистый код ради идеи чистого кода" — это тупое сектантство. Если код после преобразования к "чистому" виду теряет прозрачность и понятность — значит, с идеей "чистоты" что-то не так.
SaZ>Если вам не нравится ООП подход, который тут отлично ложится
Мне нравится ООП-подход, я его регулярно использую, но только там, куда он ложится естественно, а не путем натягивания.
SaZ>городите простыни из неконтролируемых #ifdef/endif.
Вы в состоянии представить себе что-то промежуточное между "полное отсутствие #if" и "простыни из #if"?
Re[5]: Утилита для удаления из текста C++ блоков #if с подходящими условиями
Здравствуйте, Евгений Музыченко, Вы писали: M>>Сам пиши за такие деньги ЕМ>Мне лень. Это из разряда "неплохо бы...".
Когда мне хочется, я пишу, а не ною
Скрытый текст
umba-2c
Генерирует исходник на C для входного файла. Пердназначен для генерации кроссплатформенных "ресурсов"
для приложения.
Изначально была реализована для того, чтобы зашить в прошивку самодельного веб-сервера для микроконтроллера
статичные странички и картинки, отсюда опции добавления mime-type'а и last-modified, но потом идея понравилась,
и стала применяться и для обычных исполняемых файлов.
Умеет форматировать ресурс в виде строки (использует C-escape), в виде массива char'ов, hex/dec.
Ресурс двоичный/текстовый, для текстовых может делаться замена перевода строки и сжатие пробелов,
возможно наверно надо добавить коррекцию/конвертацию Tab'ов/в Tab'ы, нормализацию отступов (как в umba-tabtool).
Умеет кодировать данные в base64, умеет простецкое "шифрование" XOR'ом - длина XOR ключа 1/2/4 байта,
стартовый seed и increment. Предназначено, чтобы скрывать в EXE текстовые данные от простого просмотра.
umba-2rcfs
Сканирует заданные каталоги, генерирует единый файл для регистрации builtin ресурсов во встроенной в EXE файловой системе.
Пользователь должен определить макросы CUSTOM_UMBA_RCFS_REGISTER_RESOURSE/CUSTOM_UMBA_RCFS_REGISTER_RESOURSE_XORED.
Xor-шифрует как данные, так и имена файлов ресурсов, если указано.
Тип входного файла bin/text - определяется масками, если не подходит ни под одну - используется заданная по умолчанию.
Во многом повторяет umba-2c утилиту.
Идея в том, что необходимые ресурсы проще носить с собой в EXE, чем хранить где-то в файловой системе пользователя.
Если нужна пользовательская кастомизация, то тогда просто ищутся и подсасываются пользовательские файлы
во встроенную RCFS, при этом можно проверять корректность синтаксиса пользователских файлов - например - JSON-конфиги,
вне зависимости от их далее интерпретируемого содержимого.
Умеет в XOR-шифрование как для данных, так и для имен файлов ресурсов.
Имена файлов ресурсов указываются относительно скан-корня - если в разных скан-корнях будет файл с одинаковым подпутём/именем
- будет ошибка компиляции сгенерированного сишника.
umba-brief-scanner
Производит сканирование заданных каталогов на предмет поиска файлов по маске (include/exclude files)
В каждом файле производит поиск комментария специального вида:
/*(*|!) (\|@)file
(\|@)brief Brief desription of the file
*/
Производится поиск entry points типа main/DllMain/etc, --entry-name=... задает имя и тип возвращаемых значений
В результирующий отчет (txt|html) выводится список файлов с их описанием, файлы с entry points идут первыми.
Есть возможность группировки по пути.
Основные опции
--main - генерировать только entry points в отчёте.
--update[=FILE] - в выходном txt файле можно дописывать описания файлов, и если оно не появляется в сорцах
- берётся из предыдущей версии brief-файла
--split-group - группирует/делит на группы
umba-enum-gen
Генератор enum'ов. На входе - задаём имена абы как, хоть в параметре командной строки, хоть в .txt файле,
на выходе - отформатированно по всем правилам - PascalCase, camelCase etc.
Сериализация и десериализация значений, как и наборов значений, enum-флаги, для флагов - bitwise операторы.
Шаблоны для генерации - user/custom/base (builtins) варианты для lang/template версий.
Автоматически производится поиск файла с опциями 'umba-enum-gen-flags.txt', который обрабатывается
после встроенных файлов опций, но перед всеми непосредственно указанными опциями.
umba-make-headers
Простая утилита.
Генерирует include файлы согласно namelist.txt (который пишется руками), со ссылкой на C++/Qt документацию.
Сгенерированное надо подсовывать среде, которая умеет в это.
std::back_inserter лежит в <iterator>, но помнить это никто не делает.
Просто пишем в среде '#include "std/ba' - среда подсказывает, '#include "std/back_inserter'
В свою очередь, в файле 'std/back_inserter' лежит #include на <iterator>, и комментарий со ссылкой на cppreference
(или на кутишные доки).
Ссылка на доку в 95% случаев работает.
Готовченко тут:
https://github.com/al-martyn1/_std_headers
https://github.com/al-martyn1/_qt_headers
https://github.com/al-martyn1/_qt5_headers
https://github.com/al-martyn1/_qt6_headers
Примеры namelist.txt там же, для каждого случая.
umba-pretty-headers
Парсит заданные входные файлы, для каждого типа или свободной функции или дефайна создаёт include-файл в output каталоге.
Развитие утилиты umba-make-headers. Используется Clang-tooling. Текущая версия Win32/64 собрана на MSVC2019,
если студия нужной версии/Clang не установлены, то могут быть проблемы (проблемы могут быть, даже если всё в
порядке вроде бы - как решать - хз, но у меня работает, на предыдущей работе не работало, но я уволился)
Неплоха, чтобы посмотреть, что вообще в проекте с типами и иерархиями имен и пространств имён творится, и что есть что.
umba-sort-headers
Сортировка incude'ов. Ничего не трогает, в тч кодировку. Макс попортятся переводы строк, но и тут мы старались делать нежно.
Пробелы и пустые строки игнорируются. Все иное, в тч пустой комент - это брик для сортировки иклудов,
инклуды сортируются только в рамках блока без бриков. Всякие #ifdef'ы - тоже брики.
Можно задавать приоритет сортировки - "user" и <system>
Хорошая практика - в хидере сортировать всё, в файле реализации - первым идёт его хидер (чтобы проверить его самододостаточность),
затем - отсортированные внешние зависимости - чтобы проще ориентироваться.
umba-subst-macros
Задаём макросы в командной строке. Парсим файл, подставляем - профит. Макросы похожи на макросы проектов VisualStudio - $(MacroName).
Неизвестные макросы можно пропускать как есть, либо вырезать.
Ключик --raw позоляет делать замены без макросов - тупая текстовая подстановка. Из конкретного файла делаем шаблон в --raw режиме,
потом шаблон используем для генерации по шаблону при помощи макросов. Профит.
umba-tabtool
--check - только проверки с выводом отчета. Возвращает не нулевой код возврата, можно использовать при коммита в хуках, например.
Конвертит TAB'ы в пробелы и наоборот.
Нормализация TAB'ов - конвертит пробелы в TAB'ы, потом наоборот, потом опять наоборот, с учетом TAB-дельты.
Умеет исправлять некратное табам количество пробелов, так, 3 пробела дополняются до четырёх при -tab-delta=1, а 2 и меньше - обрезаются.
umba-tr
Поддержка легковесной системы перевода (локализации) сообщений в стиле Qt - marty_tr.
Собирает файлы из дерева каталогов/файлов в единый файл перевода в формате JSON. Иерархия трёх уровневая - LangTag/Category/MessageId,
где MessageId - собственно сам текст сообщения (на англиском). LangTag может быть как в формате локали en-US, так и в виде виндового
LangId - 0x0409/0x409/0409/409. Если категория в файле не задана (пустая), то подставляется путь конкретного файла относительно корня поиска.
Единый JSON-файл перевода затем следует добавить в ресурсы приложения при помощи umba-2c и использовать с использованием библиотеки
https://github.com/al-martyn1/marty_tr
Здравствуйте, Евгений Музыченко, Вы писали:
R>>достаточно просто не дожать символ '&' в типе формального параметра.
ЕМ>Обычно большинство функций дублируется объявлениями, так что это придется повторить дважды. А там, где только определение, такое достаточно хорошо видно глазами.
Опыт показывает, что и не достаточно, и не видно, и не хорошо.
Re[11]: Утилита для удаления из текста C++ блоков #if с подходящими условиями
. Тогда посоветовали cpp-partial, но он не подошел — понимает только #ifdef/#ifndef, а у меня все условия на #if, чтобы не нарываться на проблемы из-за ошибок в написании имен.
Тогда я обошелся вынесением заказчикозависимого кода в отдельные файлы, но это довольно неудобно — и код не сразу виден, и для многих мест достаточно лишь пары-тройки строк.
Может, с тех пор появилось что-то подходящее?
Re: Утилита для удаления из текста C++ блоков #if с подходящими условиями
А в чём проблема написать самому? Я может что-то не понимаю, но вроде задача на час от силы. Или там какие-то сверх-сложные условия в if, которые самописным парсером не разобрать?
Re[6]: Утилита для удаления из текста 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++ считать перестается. Эволюция и прогресс, ничего не поделать.
ЕМ>Мне совершенно по барабану, какие в этих сектах нынче правила, я тупо использую возможности языка, подходящие для моих, а не высших целей.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>"Мне совершенно по барабану, какие в этих сектах нынче правила, я тупо использую возможности языка, подходящие для моих, а не высших целей.
Ну и говнокодил бы себе потихоньку, а зачем же из себя эталон изображать? Зачем себя на большинство натягивать, зачем регулярно устраивать холивары и зачем козырять каким-то невероятным опытом, когда реальный опыт стремится к нулю?
Здравствуйте, Евгений Музыченко, Вы писали:
M>>уровень владения языком у тебя так себе
ЕМ>Так я никогда не претендовал на знание какого-либо языка в совершенстве.
Да я не про уровень типа "в совершенстве". В совершенстве даже Кодт не знает (хотя я в этом не уверен на 100% ). Просто ты реально частенько вылезаешь с очень сомнительными заявлениями, и с отсылками к своему многолетнему опыту. Тебе бы надо понимать, что опыт у тебя специфический, ты в одно лицо пилишь продукт. В командной же разработке внезапно начинает играть рояль совсем другой опыт, и, часто, совсем другие практики.
Здравствуйте, Евгений Музыченко, Вы писали:
AD>>Думаю, оно появилось сильно до. https://dotat.at/prog/unifdef/
ЕМ>Спасибо! Это больше всего похоже на то, что искал. Там вроде даже допилили поддержку символьных макросов (у меня код заказчика задается в таком виде). Может, даже сам туда чего добавлю.
За 15 лет страданий ты не смог нагуглить вариантов? Ты начинаешь напоминать Шмыгу
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, Marty, Вы писали:
M>>Так и я про это. Если считать со всеми форумами, этот махонький отъедается как не в себя S>Большой вопрос как он успевает все это потреблять. Да еще и работать. S>Есть подозрение, что не успевает ни того, ни другого Чем больше я смотрю на людей, тем больше я люблю со... Тьфу блин!
Чем больше я смотрю на Шмыджика, тем больше мне кажется что кто-то тренирует AI-робота какого-то...
Здравствуйте, Евгений Музыченко, Вы писали: ЕМ>Может, с тех пор появилось что-то подходящее?
Концепты и policy-based подход к реализации подобных вещей. Просто переделай это и всё будет нормально работать, хотя куда тебе, ты знатный ретроград.
Вот хорошее видео
Видео
.
Sic luceat lux!
Re[2]: Утилита для удаления из текста C++ блоков #if с подхо
Здравствуйте, vsb, Вы писали:
vsb>вроде задача на час от силы.
На час она тому, кто регулярно пишет парсеры/интерпретаторы выражений, или знаком с готовыми библиотеками. Я такого вообще ни разу не писал — если возьмусь делать наскоро, то получится жутко уродливый код, меня такой раздражает, придется дорабатывать и вылизывать, в итоге растянется на несколько дней.
vsb>Или там какие-то сверх-сложные условия в if, которые самописным парсером не разобрать?
Да не особо — только числовая/битовая арифметика, да логические связки.
. Тогда посоветовали cpp-partial, но он не подошел — понимает только #ifdef/#ifndef, а у меня все условия на #if, чтобы не нарываться на проблемы из-за ошибок в написании имен. ЕМ>Тогда я обошелся вынесением заказчикозависимого кода в отдельные файлы, но это довольно неудобно — и код не сразу виден, и для многих мест достаточно лишь пары-тройки строк. ЕМ>Может, с тех пор появилось что-то подходящее?
gcc -E?
-E Stop after the preprocessing stage; do not run the compiler
proper. The output is in the form of preprocessed source
code, which is sent to the standard output.
Как много веселых ребят, и все делают велосипед...
Re[3]: Утилита для удаления из текста C++ блоков #if с подхо
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>На час она тому, кто регулярно пишет парсеры/интерпретаторы выражений, или знаком с готовыми библиотеками. Я такого вообще ни разу не писал — если возьмусь делать наскоро, то получится жутко уродливый код, меня такой раздражает, придется дорабатывать и вылизывать, в итоге растянется на несколько дней.
Да ты 14 лет уже ищешь.
Если 30 лет опыта разработки на С++ недостаточно для решения такой сложной задачи, можно воспользоваться более приятными языками
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Ну это ж совсем не то.
То, если распарсить результат, посмотреть, какие блоки выкинулись/остались, и на основании этого пропатчить оригиналы.
Re[5]: Утилита для удаления из текста C++ блоков #if с подхо
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Осталось вспомнить, что есть такая штука, как макросы, и соотнесение блоков в том виде, в каком их выдаст препроцессор, будет задачей куда менее тривиальной, чем сделать интерпретатор выражений, допустимых для #if. Вы результат работы gcc -E вживую видели? Или, хотя бы, задумывались, как cc1, работающий после препроцессор, умудряется записать правильные номера строк в debug info, не выполняя "нетривиальное соотнесение блоков"?
По факту, задача элементарная, потому что препроцессор нашпигует свою выдачу #line-ами.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здравствуйте, SaZ, Вы писали:
SaZ>>Нормальная архитектура с заказчикозависимым кодом в отдельном классе.
ЕМ>Когда реализация предполагает отдельный класс — само собой. А во многих местах заказчикозависимый код состоит всего из нескольких строк, вставляемых по условию, и делающих дополнительные проверки или мелкие операции. Городить для таких добавок/уточнений отдельные классы — лишь загромождать реализацию.
Вы не правы. Как раз таки наоборот — вам требуется разная логика с одинаковым интерфейсом, в зависимости от каких-либо условий (заказчикозависимость). Имеет смысл её вынести в отдельные сущности. Это же основы ООП. И более чистый код.
Если вам не нравится ООП подход, который тут отлично ложится, то тогда удачи с другими парадигмами — городите простыни из неконтролируемых #ifdef/endif.
Re[4]: Утилита для удаления из текста C++ блоков #if с подходящими условиями
и от каких-либо условий (заказчикозависимость). Имеет смысл её вынести в отдельные сущности. Это же основы ООП. И более чистый код. SaZ>Если вам не нравится ООП подход, который тут отлично ложится, то тогда удачи с другими парадигмами — городите простыни из неконтролируемых #ifdef/endif.
Зачем #ifdef/endif? Можно вполне через шаблоны сделать. PS: ожидаем rg45... Попкорном могу поделиться, уважаемые коллеги
Ты так остроумно иронизируешь по поводу шаблонов, что может показаться, что ты собаку съел по этой теме.
А вот, как ты считаешь, есть вообще что-нибудь, что следовало бы делать через шаблоны? Не мог бы ты поподробнее рассказать о своем опыте (если таковой есть)?
Здравствуйте, vsb, Вы писали:
vsb>А в чём проблема написать самому? Я может что-то не понимаю, но вроде задача на час от силы. Или там какие-то сверх-сложные условия в if, которые самописным парсером не разобрать?
там не только if надо разбирать но и define, undefine, макросы, логические и арифметические операторы и выражения
Re[3]: Утилита для удаления из текста C++ блоков #if с подхо
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>На час она тому, кто регулярно пишет парсеры/интерпретаторы выражений, или знаком с готовыми библиотеками.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>... ЕМ>Я не использую ни defined (), ни #ifdef/#ifndef — это неслабый источник труднообнаруживаемых глюков. Только #if.
#ifdef xxxx это частный случай от #if defined(xxxx). Так что вы что-то путаете.
Re[6]: Утилита для удаления из текста C++ блоков #if с подходящими условиями
Здравствуйте, SaZ, Вы писали:
SaZ>Да хоть самописной кодогенерацией
Зачем мне самописная кодогенерация, если задача элементарно, адекватно и удобно решается через #if?
SaZ>если вы не можете осилить нормальную архитектуру.
Не путайте нормальное с сакральным.
SaZ>Грязный код просто потому что не умеете/не хотите чистый — это сектанство.
В тех местах, о которых идет речь, код вполне чистый. Если он не удовлетворяет каким-то высшим законам — это проблема проповедников тех законов.
SaZ>у вас типичный "си с классами" вместо нормального си++.
"Нормального C++" не существует. Существует несколько сект со сверхидеями "это нужно делать только вот так, а если не так — это не C++". Что характерно, правила для "вот так" меняются по мере изменения стандартов C++, так что то, что какое-то время назад было "типичным 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[10]: Утилита для удаления из текста C++ блоков #if с подхо
Здравствуйте, so5team, Вы писали:
S>Ну вот мне буквально сегодня довелось увидеть в коде в реализации PImpl голый владеющий указатель. Именно так, без std::unique_ptr. S>И, естественно, операторы/конструкторы копирования/перемещения не былы ни определены, ни объявлены как delete. Т.е. компилятор сгенерирует их по умолчанию.
Да и ради бога. Если объекты этих классов никому не придет в голову ни копировать, ни перемещать, кроме полных идиотов, от которых не спасут определения/delete, то зачем? Чтоб было красиво и канонiчно?
S>Назвать такой код "нормальным C++" или "типичным С++" у меня не получится. А вот обозвать "Си с классами" -- запросто, и это еще будет очень мягко сказано.
Да и ради бога. Кто-то ведь и инструкцию к микроволновке, которая явно не запрещает сушить в ней домашних животных, обзовет плохой и неправильной.
Re[11]: Утилита для удаления из текста C++ блоков #if с подх
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Да и ради бога. Если объекты этих классов никому не придет в голову ни копировать, ни перемещать, кроме полных идиотов, от которых не спасут определения/delete, то зачем? Чтоб было красиво и канонiчно?
ЕМ>Да и ради бога. Кто-то ведь и инструкцию к микроволновке, которая явно не запрещает сушить в ней домашних животных, обзовет плохой и неправильной.
Демагогия, возведенная в степень пещерного невежества.
P.S. Его величество человечский фактор способен на такое, до чего ни один идиот не додумается. Для того, чтоб моймать нежелательное копирование достаточно просто не дожать символ '&' в типе формального параметра. И будешь ты такие ошибки ловить на проде долго и мучительно. А вот те, кто не понимают, что людям свойственно ошибаться, действительно идиоты.
Здравствуйте, rg45, Вы писали:
R>Демагогия, возведенная в степень пещерного невежества.
С броневичка не упадите.
R>достаточно просто не дожать символ '&' в типе формального параметра.
Обычно большинство функций дублируется объявлениями, так что это придется повторить дважды. А там, где только определение, такое достаточно хорошо видно глазами. Особенно тем, кто не лепит "&" ни к типу, ни к переменной, хотя это предписывает "канонiчный стиль".
Re[13]: Утилита для удаления из текста C++ блоков #if с подх
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>С броневичка не упадите.
А-ха-ха! Ты, наверное, сам себе кажешься очень остроумным, судя по непрекращающимся попыткам пошутить.
ЕМ>Обычно большинство функций дублируется объявлениями, так что это придется повторить дважды. А там, где только определение, такое достаточно хорошо видно глазами. Особенно тем, кто не лепит "&" ни к типу, ни к переменной, хотя это предписывает "канонiчный стиль".
Рассуждения типичного говнокодера. Не дай Боже сделать что-то по-нормальному. Все на соплях и все через жопу, с перекладыванием ответственности на кого-то.
Здравствуйте, Евгений Музыченко, Вы писали:
R>>с перекладыванием ответственности на кого-то.
ЕМ>Смешно, да. У Вас и большинства Ваших единомышленников хотя бы физически есть, на кого переложить ответственность, а мне-то на кого спихивать?
Зашибись отмазка. Звучит примерно как "я живу один, поэтому могу срать прямо в комнате".
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Скорее как "могу не дезинфицировать унитаз после каждого использования, и не выравнивать стулья у стола по одной линии".
За "не выравнивать стулья" — могло бы сойти не очень строгое соблюдение стиля оформления кода, нерегулярность в расстановке скобок и отступов, нерегулярность в стиле имен и т.п. А то, о чем ты пишешь здесь
Здравствуйте, Marty, Вы писали:
M>За 15 лет страданий ты не смог нагуглить вариантов? Ты начинаешь напоминать Шмыгу
Не «Шмыга», а «Шмыджик». Он еще махонький...
Здравствуйте, CreatorCray, Вы писали:
CC>Ты что, их руками каждый раз набираешь???
Нет, конечно. Но иногда бывает, например, что фокус на IDE, курсор стоит в тексте, а я случайно задеваю какую-нибудь клавишу, отчего в текст вставляется соответствующий символ. Особенно неприятно, когда это происходит внутри строки — кроме как глазами, никак не обнаружить.
Re[5]: Утилита для удаления из текста C++ блоков #if с подходящими условиями
Здравствуйте, Carc, Вы писали:
M>>За 15 лет страданий ты не смог нагуглить вариантов? Ты начинаешь напоминать Шмыгу C>Не «Шмыга», а «Шмыджик». Он еще махонький...
Шмыга махонький? Да он на одном плюсовом форуме отъелся так, что толще Шрека уже
Здравствуйте, so5team, Вы писали:
M>>Так и я про это. Если считать со всеми форумами, этот махонький отъедается как не в себя
S>Большой вопрос как он успевает все это потреблять. Да еще и работать.
S>Есть подозрение, что не успевает ни того, ни другого
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здравствуйте, CreatorCray, Вы писали:
CC>>Ты что, их руками каждый раз набираешь???
ЕМ>Нет, конечно. Но иногда бывает, например, что фокус на IDE, курсор стоит в тексте, а я случайно задеваю какую-нибудь клавишу, отчего в текст вставляется соответствующий символ. Особенно неприятно, когда это происходит внутри строки — кроме как глазами, никак не обнаружить.
Приходит программист на работу с красными глазами, злой, не в настроении. У него же и спрашивают:
— Слышь, Вась, че ты такой невеселый?
— Да я тут всю ночь программу писал.
— И что не работает?
— Работает.
— Может с глюками какими?
— Нет, без.
— Так че ты злой такой?
— Да я, бл@#$, на клавише Backspace заснул.
Re[10]: Утилита для удаления из текста C++ блоков #if с подходящими условиями
. Тогда посоветовали cpp-partial, но он не подошел — понимает только #ifdef/#ifndef, а у меня все условия на #if, чтобы не нарываться на проблемы из-за ошибок в написании имен.
ЕМ>Тогда я обошелся вынесением заказчикозависимого кода в отдельные файлы, но это довольно неудобно — и код не сразу виден, и для многих мест достаточно лишь пары-тройки строк.
ЕМ>Может, с тех пор появилось что-то подходящее?
Мне в свое время понравился boost wave, посмотри его примеры, в особенности некий "The advanced_hooks sample", выглядит довольно близко к тому что тебе надо.
Re[2]: Утилита для удаления из текста C++ блоков #if с подходящими условиями
Здравствуйте, Quebecois, Вы писали:
Q>То, если распарсить результат, посмотреть, какие блоки выкинулись/остались, и на основании этого пропатчить оригиналы.
Осталось вспомнить, что есть такая штука, как макросы, и соотнесение блоков в том виде, в каком их выдаст препроцессор, будет задачей куда менее тривиальной, чем сделать интерпретатор выражений, допустимых для #if.
Re[6]: Утилита для удаления из текста C++ блоков #if с подхо
Здравствуйте, Quebecois, Вы писали:
Q>Вы результат работы gcc -E вживую видели?
Видел.
Q>По факту, задача элементарная
Она лишь просто выполнимой станет только после того, как препроцессор будет обеспечен правильной конфигурацией как путей include, так и значениями всех макросов, которые могут встретиться в выражениях. В общем случае все это доступно только внутри цикла сборки под соответствующую среду (VS, WDK и т.п. — ну не требовалось мне никогда именно *make), так что надо будет вытаскивать конфигурацию и поддерживать ее отдельно. Самое-то смешное, что по логике задачи всего этого не требуется.
Q>препроцессор нашпигует свою выдачу #line-ами.
Нашпигует, а толку? В #if может быть не только одинокий макрос вида "_BUILD_FOR_CUSTOMER_XXX", но и более сложное выражение. Как понять, по какой именно части условия препроцессор выкинул или оставил такой блок?
Re[7]: Утилита для удаления из текста C++ блоков #if с подхо
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Нашпигует, а толку? В #if может быть не только одинокий макрос вида "_BUILD_FOR_CUSTOMER_XXX", но и более сложное выражение. Как понять, по какой именно части условия препроцессор выкинул или оставил такой блок?
А в общем виде, без учета значения других макросов, задача не решается.
Например:
// #define Y 1 || 1#if defined(USER_C) && Y
int Foo=4; // Этот кусок кода оставлять, для пользователя A ?#endif
Тут нужно учесть, что значение Y могло "приехать" и из настроек скрипта сборки и его значение неизвестно...
Остается только переписать код, так чтобы defined(_BUILD_FOR_CUSTOMER_XXX) не встречались в сложных условиях, т.е. заменить на #ifdef/#ifndef соотвественно.
Тогда подход cpp-partial сработает.
Re[8]: Утилита для удаления из текста C++ блоков #if с подхо
Здравствуйте, Chorkov, Вы писали:
C>А в общем виде, без учета значения других макросов, задача не решается.
Через стандартный препроцессор — конечно, нет. В идеале надо бы просто упрощать сложные условия, исключая из них макросы с известными значениями.
C>Остается только переписать код, так чтобы defined(_BUILD_FOR_CUSTOMER_XXX) не встречались в сложных условиях, т.е. заменить на #ifdef/#ifndef соотвественно.
Я не использую ни defined (), ни #ifdef/#ifndef — это неслабый источник труднообнаруживаемых глюков. Только #if. Если какие-то стандартные макросы поступают в виде "определено / не определено", они переделываются в локальные со значениями 0/1.
Re: Утилита для удаления из текста C++ блоков #if с подходящими условиями
. Тогда посоветовали cpp-partial, но он не подошел — понимает только #ifdef/#ifndef, а у меня все условия на #if, чтобы не нарываться на проблемы из-за ошибок в написании имен.
ЕМ>Тогда я обошелся вынесением заказчикозависимого кода в отдельные файлы, но это довольно неудобно — и код не сразу виден, и для многих мест достаточно лишь пары-тройки строк.
ЕМ>Может, с тех пор появилось что-то подходящее?
Нормальная архитектура с заказчикозависимым кодом в отдельном классе. Можно через pimpl подсовывать нужные реализации, а решать уже включать ту или иную имплементацию — на усмотрение билд системы. Если нужно отдавать исходник не заказчику — отдаём только заглушку.
// main.hclass A;
class I
{
public:
I(A& a) : _a{a}()
void foo(int a); // not virtualprivate:
A& _a;
};
class A
{
friend class I;
public:
A() : _impl{*this}()
void foo(int a)
{
// Shared logic
_impl.foo(a); // Customer-specific or shared logic
std::cout << _last;
}
private:
I _impl;
std::string _last;
};
// common.cpp или заглушкаvoid I::foo(int a)
{
_a._last = "called from shared code";
}
// customer_specific.cppvoid I::foo(int a)
{
_a._last = "called from customer-specific code";
}
Re[2]: Утилита для удаления из текста C++ блоков #if с подходящими условиями
Здравствуйте, SaZ, Вы писали:
SaZ>Нормальная архитектура с заказчикозависимым кодом в отдельном классе.
Когда реализация предполагает отдельный класс — само собой. А во многих местах заказчикозависимый код состоит всего из нескольких строк, вставляемых по условию, и делающих дополнительные проверки или мелкие операции. Городить для таких добавок/уточнений отдельные классы — лишь загромождать реализацию.
Re: Утилита для удаления из текста C++ блоков #if с подходящими условиями
Здравствуйте, rg45, Вы писали:
R>Здравствуйте, Carc, Вы писали:
C>>PS: ожидаем rg45... Попкорном могу поделиться, уважаемые коллеги
R>А я не приду. Надоел он мне хуже горькой редьки.
Не-е-е-е, так не пойдет! Попкорн закуплен, билеты распроданы, на подветки подписаны... Ждём-съ (ц)
PS: а если шутки в сторону, то весьма интересно наблюдать за вашим спором. И не без практической выгоды (пару-тройку интересных и новых мыслей уже попадалось, из разряда "а с такой стороны задачу я не разглядывал" ).
Здравствуйте, CRT, Вы писали:
vsb>>А в чём проблема написать самому? Я может что-то не понимаю, но вроде задача на час от силы. Или там какие-то сверх-сложные условия в if, которые самописным парсером не разобрать?
CRT>там не только if надо разбирать но и define, undefine, макросы, логические и арифметические операторы и выражения
И директивы #include тоже, причем, с двумя видами скобок-кавычек. Какие-то макроопределения могут же находиться в других заголовочных файлах. Нужно будет правильно работать с относительными путями и правильно учесть приоритеты при обходе директорий. А перед тем, как грызть директивы препроцессора нужно еще правильно очистить весть текст от комментариев. Директивы препроцессора могут же быть и закомментированы, правда? Задачка не на часик, явно. Но за 14 лет можно было сделать. Причем, совсем не обязательно на плюсах. Лично я бы делал на шарпе — это реально быстрее получается, просто эмпирически.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>... SaZ>>Давно отказался от таких практик в сторону нормальных билд систем и архитектур. ЕМ>Да и ради бога. Я добавляю дополнительные сущности, когда они облегчают мне жизнь, а не когда они становятся модными и прогрессивными.
Нормальная архитектура всегда была в моде с момента появления первых высокоуровневых языков программирования. Но всегда были люди, которые "вжух-вжух и в продакшн" и потом удивлялись, почему же так сложно делать с проектом тривиальные вещи. Вы явно из них, потому что даже не пробуете.
В общем, вам предложили нормальное решение, вы продолжаете натягивать сову на глобус и упорно сопротивляться. Разбираться в причинах (много кода переделывать / вам лень / вам не хватает квалификации) мне не досуг, желаю успехов.
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[11]: Утилита для удаления из текста C++ блоков #if с подхо
Здравствуйте, Евгений Музыченко, Вы писали:
S>>Ну вот мне буквально сегодня довелось увидеть в коде в реализации PImpl голый владеющий указатель. Именно так, без std::unique_ptr. S>>И, естественно, операторы/конструкторы копирования/перемещения не былы ни определены, ни объявлены как delete. Т.е. компилятор сгенерирует их по умолчанию.
ЕМ>Да и ради бога. Если объекты этих классов никому не придет в голову ни копировать, ни перемещать, кроме полных идиотов, от которых не спасут определения/delete, то зачем? Чтоб было красиво и канонiчно?
Фокус в том, что спасут. В этом-то и весь фокус.
Re[14]: Утилита для удаления из текста C++ блоков #if с подх
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Если объекты этих классов никому не придет в голову ни копировать, ни перемещать
Если...
А потом через несколько месяцев просто забудут что его нельзя трогать и ой.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[10]: Утилита для удаления из текста C++ блоков #if с подхо
Чаще всего, конечно, в таких случаях ломаются зависимости, но не всегда. Например, константная таблица, в которую по различным условиям включаются разные элементы, и нет внятного условия времени компиляции, которому должен удовлетворять ее размер.
CC>Чота как то с прошлого века глюков в этой области у меня не случалось.
У меня не случалось жестких глюков, ломающих логику, а вот с теми же таблицами, в которых что-то ищется, а не индексируется напрямую — бывало.
Re[12]: Утилита для удаления из текста C++ блоков #if с подхо
Здравствуйте, CreatorCray, Вы писали:
CC>А потом через несколько месяцев просто забудут что его нельзя трогать и ой.
Если именно нельзя, то, само собой, надо принимать технические меры. А если тупо бессмысленно (например, кто в здравом уме станет копировать объект "приложение"?), то случайно с ним ничего не сделают.
Re[10]: Утилита для удаления из текста C++ блоков #if с подхо
Здравствуйте, CreatorCray, Вы писали:
ЕМ>>#ifdef/#ifndef — это неслабый источник труднообнаруживаемых глюков.
CC>Например? CC>Чота как то с прошлого века глюков в этой области у меня не случалось.
Здравствуйте, Marty, Вы писали:
M>тут неделю уже стоны
И Ваши вопли.
M>уже и готовую заготовку ему сделали...
Зачем, кстати? Я ж только задавал вопрос — есть или нет, какой-либо помощи по деланию не предполагалось вообще. Я иногда и сам что-то конкретное делаю в ответ на абстрактный вопрос, если вдруг стало интересно, а тут вот никакого интереса нет самому что-то делать, напрочь. Если найдется что-то готовое/подходящее — буду использовать, не найдется — обойдусь тем, что есть.
Re[11]: Утилита для удаления из текста C++ блоков #if с подхо
Здравствуйте, Евгений Музыченко, Вы писали:
M>>Ну, учитывая общий уровень ТС...
ЕМ>Учитывая то, что большинство оценивает общий уровень по достаточно косвенным признакам, он может несколько не совпадать с оценками...
Общий уровень я имел в виду в контексте названия форума. Ты возможно бог драйверов и тп, но уровень владения языком у тебя так себе
Здравствуйте, Marty, Вы писали:
M>уровень владения языком у тебя так себе
Так я никогда не претендовал на знание какого-либо языка в совершенстве. Я и в русском-то иногда пропускаю запятые или вставляю лишние, а уж в видах сложноподчиненных предложений и вовсе не разбираюсь. Очень, кстати, любопытно бывает посмотреть на то, как ревнители уличают писателей в недостаточном знании правил языка, музыкантов — нотной грамоты, и т.п.
Re[15]: Утилита для удаления из текста C++ блоков #if с подхо
Здравствуйте, Евгений Музыченко, Вы писали:
M>>В командной же разработке внезапно начинает играть рояль совсем другой опыт, и, часто, совсем другие практики.
ЕМ>А тем, кто работает в команде, надо бы понимать, что слушать надо не меня, а тех, кто разрабатывает и устанавливает правила для [их] команды.
Тут публичный форум, тебя читать могут даже дети до 18. И могут подумать, что ты что-то полезное сказал
Спасибо! Это больше всего похоже на то, что искал. Там вроде даже допилили поддержку символьных макросов (у меня код заказчика задается в таком виде). Может, даже сам туда чего добавлю.
Re[13]: Утилита для удаления из текста C++ блоков #if с подхо
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Если именно нельзя, то, само собой, надо принимать технические меры. А если тупо бессмысленно (например, кто в здравом уме станет копировать объект "приложение"?), то случайно с ним ничего не сделают.
Если этот класс доступен для использования то рано или поздно кто нить найдёт применение.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[11]: Утилита для удаления из текста C++ блоков #if с подхо
Здравствуйте, CreatorCray, Вы писали:
CC>Если этот класс доступен для использования то рано или поздно кто нить найдёт применение.
Тут мы снова приходим к вопросу об упорядочении рисков. Если копирование/перемещение — самое опасное, что можно сделать с объектом класса, то класс, безусловно, необходимо от этого защитить. А если возможность неправильного использования невозможно исключить полностью, то первым делом нужно заботиться о наиболее опасных ее вариантах. Скорее всего, случайное копирование/перемещение среди них будет далеко не на первых местах, а технической возможности исключить наиболее опасные варианты может попросту не оказаться.
Re[6]: Утилита для удаления из текста C++ блоков #if с подходящими условиями
Здравствуйте, Marty, Вы писали: C>>Не «Шмыга», а «Шмыджик». Он еще махонький... M>Шмыга махонький? Да он на одном плюсовом форуме отъелся так, что толще Шрека уже
Ну не скажи... Тут вот видно, что сплошные войнушки, абразавания, и политигонаше Шмыджиково всё!
Здравствуйте, Carc, Вы писали:
C>>>Не «Шмыга», а «Шмыджик». Он еще махонький... M>>Шмыга махонький? Да он на одном плюсовом форуме отъелся так, что толще Шрека уже C>Ну не скажи... Тут вот видно, что сплошные войнушки, абразавания, и политигонаше Шмыджиково всё!
Так и я про это. Если считать со всеми форумами, этот махонький отъедается как не в себя
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Тут мы снова приходим к вопросу об упорядочении рисков.
Голый владеющий указатель это как раз высокий риск. Он по определению должен быть обложен со всех сторон.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[13]: Утилита для удаления из текста C++ блоков #if с подх
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Так для этой цели и нужен костыль, поскольку такая обработка требуется достаточно редко. Поэтому меня интересует, существует ли готовый костыль, более удобный, чем я уже использую. Делать что-то хоть заново, хоть дорабатывать существующее, имеет смысл лишь тогда, когда это способно сэкономить время в будущем.
Не уверен, что есть такие готовые костыли. Будь первым, напиши и выложи скрипт в публичное пространство, осчастливь человеков.
Перекуём баги на фичи!
Re[14]: Утилита для удаления из текста C++ блоков #if с подх
Здравствуйте, пффф, Вы писали:
П>Здравствуйте, Carc, Вы писали: C>>Чем больше я смотрю на людей, тем больше я люблю со... Тьфу блин! П>Про Шария, что ли, вспомнил?
Кто такой Шарий?
Здравствуйте, Carc, Вы писали:
C>>>Чем больше я смотрю на людей, тем больше я люблю со... Тьфу блин! П>>Про Шария, что ли, вспомнил? C>Кто такой Шарий?
Да так, забей
Re[13]: Утилита для удаления из текста C++ блоков #if с подходящими условиями
Перекуём баги на фичи!
Вы результат работы gcc -E вживую видели? Или, хотя бы, задумывались, как cc1, работающий после препроцессор, умудряется записать правильные номера строк в debug info, не выполняя "нетривиальное соотнесение блоков"? 
).
