Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Да как сказать. Если в качестве площадки для выступления предоставляется только натянутая проволока, то я, пожалуй, мелкими шажками кое-как перейду, а пляшут на ней пускай более другие.

Опять ты пытаешься заболтать суть.

Вот не хотел я встревать в этот разговор, но всё-таки встрял зачем-то. Теперь трачу на тебя свой драгоценный выходной.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Представление я имею. Вдаваться в тонкости консистенции дерьма, оттенков его цвета и запаха — не имею желания.

Подожди, в таком случае, как понимать твоё "нет"? Вопрос же был: представляешь или нет. Ты сказал "нет", а теперь оказывается, что "нет" — это "да".

Короче. Не хочу больше тратить время на твою пустую болтовню.

Здравствуйте, rg45, Вы писали:

R>как понимать твоё "нет"? Вопрос же был: представляешь или нет.

Вопрос: "представляешь, в чём принципиальная разница этих двух реализаций?"

Ответ: "нет, в чем принципиальная разница — не представляю", "нет, не согласен считать эту разницу принципиальной".

Здравствуйте, so5team, Вы писали:

M>>Уверен, что можно красиво и не слишком сложно переделать без макросов

S>Я вот не уверен, надо бы код глянуть или хотя бы условие задачи узнать.

Ну, это я конечно чутка преувеличил. Конечно, надо смотреть


S>Но поймал себя на мысли о том, что не помню ни одного раза, когда бы г.Музыченко хоть какие-то примеры кода приводил.
S>Ни в одном сраче, в котором он высказывал свое недовольство современным C++ никакой конкретики с его стороны не вспоминается.

S>Так что, думаю, и здесь не дождемся.

Дык, у него весь код под NDA небось, вдруг что сопрут конкуренты

Здравствуйте, Евгений Музыченко, Вы писали:

M>>Уверен, что можно красиво и не слишком сложно переделать без макросов

ЕМ>Ну попробуйте, например, это:

ЕМ>

ЕМ>

ЕМ>Это таблица преобразования индекса в стандартный идентификатор (KSPROPERTY_AUDIO_LATENCY и т.п.). У меня подобных таблиц до черта.

Ну, это тот случай, когда сишный препроцессор как раз весьма хорош. Тут только вызывает подозрение макрос PlaceKsId — если он в сишнике объявлен — то ничего, если в хидере — то это плохо.

И, если судить по твоему описанию, то это предназначено для отображения одних констант (какого-то твоего индекса) в стандартную константу из SDK/DDK. А в коде видно, что ты им сопоставляешь строковые литералы.

В любом случае, тут простые текстовые подстановки на уровне текста/лексем. Не очень понятно, зачем бы тут нужен был бы какой-то макрос-язык, работающий на уровне AST. Но, кстати, ты всё равно можешь написать на своём макро-языке пример конструкции, которая бы делала тоже самое, что и эти макросы, но на твоём макро-языке.

Здравствуйте, rg45, Вы писали:

R>Бездарно и говнокодисто. Хотя бы потому, что все свои идентификаторы ты прописываешь вручную. Т.е. корректность твоей реализации полностью висит на человеческом факторе.

Ну, а куда деваться, если константы заданы до тебя, да ещё — в виде сишных макросов


ЕМ>>Ну попробуйте, например, это:

R>Удивишься, но пробовали и делали. Поищи, какое у меня количество тем, посвящённых компайл-тайм каунтерам.

Ну, было бы интересно посмотреть на твоё решение подобной проблемы. Может, ссылку конкретную дашь?

Здравствуйте, Евгений Музыченко, Вы писали:

R>>Что значт "если"? Ты представляешь, или нет?

ЕМ>Я вижу, что "чистую магию" из boost в C++11 переделали в "частичную" за счет ограниченной поддержки компилятором (variadic templates). Сама же магия никуда не делась, стала лишь менее навороченной.

	Любая достаточно развитая технология неотличима от магии

Ты просто не осилил

Здравствуйте, Евгений Музыченко, Вы писали:

R>>как понимать твоё "нет"? Вопрос же был: представляешь или нет.

ЕМ>Вопрос: "представляешь, в чём принципиальная разница этих двух реализаций?"

ЕМ>Ответ: "нет, в чем принципиальная разница — не представляю", "нет, не согласен считать эту разницу принципиальной".

Как же ты может классифицировать разницу как принципиальную или не принципиальную, если ты не представляешь, в чем разница?

Здравствуйте, Marty, Вы писали:

M>Ну, было бы интересно посмотреть на твоё решение подобной проблемы. Может, ссылку конкретную дашь?

Внешних ссылок нету, но словесное описание дать могу. Эти подходы насчитывают уже почтенную историю и находятся в постоянном развитии.

Сначала была целая эпоха декларативных описаний. Результатом таких декларативных описаний были обычные классы (структуры) C++, сопровождаемые метаданными — возможности доступа к полям структур по индексам и получение строковых представлений имён. Зачастую в метаданные включались средства форматного контроля и версионирования. Поверх таких структур можно было делать унифицированные обработки типа ввода-вывода, сериализации и пр. Пример такого декларативноного описания вот:

   STRUCT_BEGIN(Expiration)
      PRIMARY_KEY((contractYear, contractMonth), (std::optional<int>, std::optional<int>))
      FIELD(contractYear,        std::optional<int>, Pattern("\\d{1,2}"))
      FIELD(contractMonth,       std::optional<int>, Pattern("\\d{1,2}"))
      FIELD(expirationDate,      boost::gregorian::date, Expanded)
      FIELD(daysToExpiry,        int)
      FIELD(xmMaturityBucketID,  std::optional<int>)
      FIELD(teaBucketID,         std::optional<TeaBucketID>, VERSION(80))
      FIELD(contractDate,        boost::gregorian::date, ExtendedISO DEFAULT(_.expirationDate) VERSION(111))
      SECTION("S", series, SeriesMap)
   STRUCT_END(Expiration)

Очевидным недостатком этого подхода является использование макросов, от которых хотелось бы избавиться вовсе.

Сейчас вся эта кухня движется в сторону "чистых" структур без макросов с использованием компайл-тайм рефлексии. Эти подходы частично перекликаются с теми, которые используются в boost::mpl.

Здравствуйте, Marty, Вы писали:

M>тот случай, когда сишный препроцессор как раз весьма хорош.

Сишный препроцессор никогда не бывает "весьма хорош" — просто потому, что предельной убог. Максимум, на что его хватает в этой примере — не быть чрезмерно плохим.

M>если он в сишнике объявлен

Разумеется. И сразу за таблицей стоит #undef.

M>предназначено для отображения одних констант (какого-то твоего индекса) в стандартную константу из SDK/DDK.

Не моего индекса, а стандартного, для которого идентификаторы и определены.

M>зачем бы тут нужен был бы какой-то макрос-язык, работающий на уровне AST.

В данном случае — чтобы непосредственно получить у компилятора все идентификаторы указанного enum вместе с их значениями, желательно — в порядке перечисления в исходном тексте.

M>можешь написать на своём макро-языке пример конструкции, которая бы делала тоже самое, что и эти макросы, но на твоём макро-языке.

Зачем? Опять в качестве примера?

Здравствуйте, Marty, Вы писали:

M>Любая достаточно развитая технология неотличима от магии

Не следует путать магию (суть которой совершенно непонятна необразованнму/непосвященному) с "магией" (суть которой заключается в чрезмерно навороченной манипуляции понятными в целом вещами).

Эквилибрист, танцующий на проволоке для демонстрации своих умений, может вызывать уважение. Пара, занимающаяся сексом в гамаке на лыжах потому, что другими способами в данной культуре этого делать не разрешается, вызывает лишь недоумение и сочувствие.

Здравствуйте, Marty, Вы писали:

M>Как же ты может классифицировать разницу как принципиальную или не принципиальную, если ты не представляешь, в чем разница?

Вы утомили оба. Не моя вина, что rg45 меняет смысл своего вопроса с течением времени, а Вы не утруждаете себя обратить на это внимание.

Здравствуйте, rg45, Вы писали:

R>Внешних ссылок нету, но словесное описание дать могу. Эти подходы насчитывают уже почтенную историю и находятся в постоянном развитии.

R>Сначала была целая эпоха декларативных описаний. Результатом таких декларативных описаний были обычные классы (структуры) C++, сопровождаемые метаданными — возможности доступа к полям структур по индексам и получение строковых представлений имён. Зачастую в метаданные включались средства форматного контроля и версионирования. Поверх таких структур можно было делать унифицированные обработки типа ввода-вывода, сериализации и пр. Пример такого декларативноного описания вот:

R>

R>   STRUCT_BEGIN(Expiration)
R>   //...
R>   STRUCT_END(Expiration)
R>

Ну, а) макросы, б) ты описываешь свои данные, а не чужие, заданные кем-то другим даже не в виде перечислений, а тупо макросами


R>Очевидным недостатком этого подхода является использование макросов, от которых хотелось бы избавиться вовсе.

Ну, лично я против умеренного использования макросов ничего не имею


R>Сейчас вся эта кухня движется в сторону "чистых" структур без макросов с использованием компайл-тайм рефлексии. Эти подходы частично перекликаются с теми, которые используются в boost::mpl.

Ну, я бы не стал так делать, очень не прозрачно всё выглядит.

Я предпочитаю запиливать внешние инструменты. Вот сейчас понадобилось метаданные к сишечке прикрутить — нашел такой CastXML, который пилят создатели CMake, это наследник GCC-XML (там, на самом деле, кроме названия, ничего особо не поменялось, по крайней мере, видимого с наружи — они похоже движ с GCC на Clang только перевели). Так вот, CastXML умеет извлекать из кода структуры, объединения, перечисления, тайпдефы, и складывать это в XML, из которого можно всё что угодно нагенерить

Здравствуйте, rg45, Вы писали:

R>Сейчас вся эта кухня движется в сторону "чистых" структур без макросов с использованием компайл-тайм рефлексии.

Вот я и говорю, что она так "движется" уже десятки лет, и каждое незначительное, дозированное улучшение подается, как радикальный прорыв, от которого еще совсем немного до полного счастья. Кто-то искреннее радуется и гордиться, а мне кринжово.

Здравствуйте, Marty, Вы писали:

M>CastXML умеет извлекать из кода структуры, объединения, перечисления, тайпдефы, и складывать это в XML

Ну, то есть, делает то же, что и все обычные компиляторы, но в силу врожденной жадности не отдают.

Здравствуйте, Евгений Музыченко, Вы писали:

R>>Сейчас вся эта кухня движется в сторону "чистых" структур без макросов с использованием компайл-тайм рефлексии.

ЕМ>Вот я и говорю, что она так "движется" уже десятки лет, и каждое незначительное, дозированное улучшение подается, как радикальный прорыв, от которого еще совсем немного до полного счастья. Кто-то искреннее радуется и гордиться, а мне кринжово.

Я говорю про движение своих личных подходов, а не о движении каких-то тектонических плит, которых ты ждешь, как у моря погоды и сам нифига не делаешь.

Здравствуйте, Евгений Музыченко, Вы писали:

M>>тот случай, когда сишный препроцессор как раз весьма хорош.

ЕМ>Сишный препроцессор никогда не бывает "весьма хорош" — просто потому, что предельной убог. Максимум, на что его хватает в этой примере — не быть чрезмерно плохим.

Да нормально с ним всё в пределах его компетенций. Ты какой-то догматик


M>>если он в сишнике объявлен

ЕМ>Разумеется. И сразу за таблицей стоит #undef.

Ну, всё равно, я придерживаюсь правила, что макросы носят имена только заглавными буквами, и их полное имя отражает пространство имён, т.е. что-то типа MARTY_ENUM_SERIALIZE_KSPROPERTY_SERIALIZE_ITEM_PLACE_ID


M>>предназначено для отображения одних констант (какого-то твоего индекса) в стандартную константу из SDK/DDK.

ЕМ>Не моего индекса, а стандартного, для которого идентификаторы и определены.

П окоду — я понял, но твоё описание не соответствовало коду


M>>зачем бы тут нужен был бы какой-то макрос-язык, работающий на уровне AST.

ЕМ>В данном случае — чтобы непосредственно получить у компилятора все идентификаторы указанного enum вместе с их значениями, желательно — в порядке перечисления в исходном тексте.

Это если они в SDK в виде enum

Можешь попробовать сделать внешний генератор на базе CastXML


M>>можешь написать на своём макро-языке пример конструкции, которая бы делала тоже самое, что и эти макросы, но на твоём макро-языке.

ЕМ>Зачем? Опять в качестве примера?

Да

Здравствуйте, Marty, Вы писали:

M>Ну, а) макросы, б) ты описываешь свои данные, а не чужие, заданные кем-то другим даже не в виде перечислений, а тупо макросами

Я специально привёл одну из наиболее древних реализаций, которая закладывалась ещё на базе C++03, когда не было даже макросов с переменным числом параметров. Тем не менее, эта реализация позволяла реализовывать унифицированные процедуры, которые работали сразу для всех типов. Например, я был избавлен от необходимости писать процедуры сериализации для каждой структуры в отдельности (коих овер-дохрена).

M>Ну, лично я против умеренного использования макросов ничего не имею

Так я тоже ничего не имею против макросов там, где без них реально не обойтись. Я против превращения макросов в основной элемент разработки под девизом "шаблоны — это те же макросы".

Здравствуйте, Евгений Музыченко, Вы писали:

M>>CastXML умеет извлекать из кода структуры, объединения, перечисления, тайпдефы, и складывать это в XML

ЕМ>Ну, то есть, делает то же, что и все обычные компиляторы, но в силу врожденной жадности не отдают.

Не жадности, нет. Токмо от скудоумия. Если бы ты сделалпридумал красивый (в архитектурном плане) и элегантно дополняющий плюсики язык "макросов", то вполне возможно, что его кто-нибудь бы и запилил, на том же Clang'e, и пропоузал бы закинул в комитет. Но только ты даже примеров не хочешь выдать, а значит, что индустрия C++ так и будет мучаться с шаблонами

Здравствуйте, rg45, Вы писали:

M>>Ну, а) макросы, б) ты описываешь свои данные, а не чужие, заданные кем-то другим даже не в виде перечислений, а тупо макросами

R>Я специально привёл одну из наиболее древних реализаций, которая закладывалась ещё на базе C++03, когда не было даже макросов с переменным числом параметров. Тем не менее, эта реализация позволяла реализовывать унифицированные процедуры, которые работали сразу для всех типов. Например, я был избавлен от необходимости писать процедуры сериализации для каждой структуры в отдельности (коих овер-дохрена).

Ну, я в своё время наткнулся на статью местную — C++: метаданные своими руками. Чтение/запись простых Xml-файлов из программы на классическом С++

Автор(ы): Андрей Мартынов
Дата: 30.11.2003
В статье рассмотрен декларативный подход к решению задачи чтения/записи XML-файлов из программ на классическом C++. Метод основан на построении специальной структуры статических данных — метаданных типов.

Мне подход понравился, я его под себя подпилил и долго использовал. Но там структуры данных не замусориваются конструкциями, аналогичными твоим, с другой стороны, есть минус — надо самому отдельно описывать раскладку для сериализации. Но зато можно иметь несколько разных раскладок. Процедуры же ручками писать не надо, там всё автоматом работает на базе описательных раскладок (layout)