Функция-шаблон С++ в статической библиотеке?

Взаимоисключающие параграфы такие взаимоисключающие...

Отнюдь. Реальные макры всегда работают на уровне AST. Поэтому и код, который генерят реальные макры позволяет расширять синтаксис языка. Потому то макры в це - жалкое подобие. Ими не расширить синтаксис. Ими можно только накостылить тупую замену текста. А уж шаблонами цепепе даже такого не сделать, потому что с их помощью уже сам компилятор генерит типы и функции - т.е. шаблоны в крестах - это частный случай макр в Си.

Его даже сдампить можно, в некоторых реализациях. См. выше.

Толку то от этого? Ещё раз, смысл работы макр на уровне AST в том, что ими можно расширить синтаксис языка, а не в том, что вот где-то там на самом деле генерится AST, которое даже можно сдампить в некоторых реализациях.

т.е. шаблоны в крестах - это частный случай макр в Си.

Я не понял, ты решил для разнообразия меня поддержать?

Толку то от этого?

Ну, строго говоря, толку от C++ вообще никакого, но мы не об этом.

Я не понял, ты решил для разнообразия меня поддержать?

Ты читал «Дизайн и эволюция Си++»? Видел первые попытки сделать контейнеры? Там во все поля использовались обычные макросы. Это уже потом на основе этих наработок Страуструп изобрёл частный случай макр под названием «шаблоны». И даже не частный случай макр си, а замену им. Он решил, что этого хватит, ибо привносит типобезопасность.

Ещё раз: ты решил меня поддержать?

Ещё раз: ты решил меня поддержать?

Я не знаю о чём ты :-) Я всего лишь высказываю то, что знаю. Я знаю, что макры и шаблоны - суть принципиально разные по замыслу технологии. Макросы принимают на вход код и раскрываются в другой произвольный код на целевом языке. Шаблоны принимают на вход типы и константы и инстанцируются в классы и функции. Смешивать эти понятия глупо. Поэтому Страуструп специально отошёл от терминологии макросов и ввёл само понятие «шаблон».

Результат работы макроса - это код на целевом языке
частный случай макр под названием «шаблоны»

Но шаблоны не генерируют кода на целевом языке(и текста там тоже никакого)

частный случай макр под названием «шаблоны»

макры и шаблоны - суть принципиально разные по замыслу технологии.

Аспирин у кого-нибудь есть?

частный случай макр под названием «шаблоны»

Тебе взаимоисключающие параграфы в голове не жмут? Ты вроде в этом треде утверждал обратное?

if(0), и компилятор выбросит код

С каких пор это гарантируется?

C++17: http://en.cppreference.com/w/cpp/language/if

А неофициально, то любой уважающий себя компилятор делает constant propagation (но, думаю, я зря упоминаю)

Но шаблоны не генерируют кода на целевом языке(и текста там тоже никакого)

Это мы все знаем. Частный случай тут в том, что текстом шаблона может выступать только текст определения класса или функции. Текст макроса может быть абсолютно любым.

Но шаблоны не генерируют кода на целевом языке(и текста там тоже никакого)

Ты вроде пару страниц пытался доказать, что генерят, нет?

Тебе взаимоисключающие параграфы в голове не жмут? Ты вроде в этом треде утверждал обратное?

Конкретно тебе я утверждал и утверждаю, что шаблоны - это никакие не «макросы с гигиеной».

if(0), и компилятор выбросит код

С каких пор это гарантируется?

C++17

То есть до сих пор не гарантируется.

любой уважающий себя компилятор делает constant propagation

Начиная с некоторого уровня оптимизации.

Я топил за некоторую схожесть макросов и шаблонов. А вот это

Результат работы макроса - это код на целевом языке

в ответ прилетело, и я с этим не согласен. Выше более ясно изложили

И получается тот самый частный случай. А вот когда ты вот такое говоришь:

макры и шаблоны - суть принципиально разные по замыслу технологии

становиться непонятно

Конкретно тебе я утверждал и утверждаю

А, то есть сквозная взаимная непротиворечивость суждений не обязательна?

То есть до сих пор не гарантируется.

Если дотошно, if (0) — то нет. Но ведь можно гарантировать используя if constexpr (0).

становиться непонятно

У Страуструпа не было замысла сделать в Си++ расширяемый синтаксис. Поэтому он ограничился фреймворков для генерации типов и функций. Назвал эту технологию шаблонами и успокоился.

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

А, то есть сквозная взаимная непротиворечивость суждений не обязательна?

Не понимаю о чём ты.

То есть до сих пор не гарантируется.

Если дотошно, if (0) — то нет

Естественно, if (0).

У Страуструпа не было замысла сделать в Си++ расширяемый синтаксис.

Кстати, коммитет работает над концептами. https://youtu.be/4AfRAVcThyA

С этим я не спорю, я имел ввиду следующие твои фразы:

частный случай макр под названием «шаблоны»

макры и шаблоны - суть принципиально разные по замыслу технологии

Одно с другим не вяжется же

Заявлял ли ты, что шаблоны являются частным случаем макросов Си?

макры и шаблоны - суть принципиально разные по замыслу технологии

Очевидно :-) Самый замысел шаблонов - избавиться от макросов Си :-) Предоставить типобезопасную альтернативу. Это всё пошло от необходимости в контейнерах.

А замысел макросов - универсальное средство генерации кода на целевом языке.

Одно с другим не вяжется же

Ну ты постарайся :-)

Кстати, у меня не получилось заставить GCC не убирать код за if (0). Ты пробовал?

Ну ты постарайся :-)

Вот теперь уже мне слив засчитайте

Заявлял ли ты, что шаблоны являются частным случаем макросов Си?

Так и есть. Они самим своим появлением обязаны макрам Си.

А, наверное, ты считаешь, что в шаблонах нет гигиены?

Я говорил о гарантиях.

любой уважающий себя компилятор делает constant propagation

Начиная с некоторого уровня оптимизации.

Кстати, в рамках интереса проверил c -O0*:

• GCC: https://godbolt.org/g/uovi43
• Clang: https://godbolt.org/g/AMdF7S

* впрочем -O0 — тоже «некоторый уровень оптимизации».

Там если -fno-dce и -fno-tree-dce указать, всё равно «оптимизирует». Похоже, это поведение в GCC никак не выключить.

GCC

Как меня умиляют персонажи, у которых «GCC» - это «GCC последней версии на AMD64».

С чего ты взял последнюю версию и amd64?

Это было очевидно.

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

А догадайся.

Как меня умиляют персонажи, у которых «GCC» - это «GCC последней версии на AMD64».

Меня тоже, но в сабже — AMD64 не релевантно*, а GCC 4.1.2 и Clang 3.0 ведут себя ровно так же.

* Если попросишь вежливо, проверю и на ARM :)

Действовал вот по этому шаблону

Это ты сам решай

Да?

Нет. Сделай еще одну попытку. Не догадаешься - подскажу.

Тогда по вот такому:

Считай это чем хочешь

там же по своей ссылке ставите icc 13.0.1 и код на -O0 под ифом не выбрасывает

* Если попросишь вежливо, проверю и на ARM :)

А на PowerPC? На Microblaze? А другие версии компиляторов? А не-GCC?

ну так ты попытаешься еще раз, или так и будешь вспоминать свои обиды?

ага, я тоже поржал:

        mov       eax, 0                                        #2.3
        test      eax, eax                                      #2.3
        je        ..B1.3        # Prob 100%  

        ; ...

..B1.3:                         # Preds ..B1.1
        mov       eax, 13                                       #5.14
        leave                                                   #5.14
        ret                                                     #5.14

Вестимо icc не входит в категорию «уважающий себя компилятор» под моими критериями :)

msvc pre2018 тоже не выбрасывает итд

То есть ты взял это с потолка )

Значит, не попытаешься. Ну, дело твое.

А на PowerPC? На Microblaze? А другие версии компиляторов?

Проверяй хоть все, что есть на godbolt.org ;) Что-то мне подсказывает, что такая оптимизация происходит перед этапом платформозависимой кодогенерации.

А не-GCC?

/me считает компиляторы кроме gcc и clang (и их производные) не кошерными (в частности icc).

А на PowerPC? На Microblaze? А другие версии компиляторов?

Проверяй

okay.jpg