Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Зачем там перегрузки? Каково их возможное применение? Рекурсия там была бы обязательно, но контролируемая более явно и точно, нежели в шаблонах. "Вариадики" в таких конструкциях не нужны — это костыль исключительно для функционального стиля.
Говоря о перегрузках, я имел в виду ветвление в зависимости от типов передаваемых параметров. Например, я хочу, чтобы для все целых генерировался один код, для дробных — другой. Это не совсем перегрузка, но близко. В чем бы ваши макросы принципиально отличались от шаблонов? Процедурным подходом? Вы уверены, что он проще и выразительней? И, главное, вы уверены, что он также расширяем? Вот написал я чудо-макрос, который для плавающих делает одно, а для целых — другое. А уже в коде ниже потребовалось добавить исключение, что для булевых нужно делать третье. Как бы я это сделал? "Расширил" бы макрос? "Заместил" бы макрос? Или специализировал? И где тогда процедурный подход?
ЕМ>Представьте, что в сишную main вместо argc/argv передавались бы "вариадики".
Вы точно понимаете, что такое вариадики?
ЕМ>Я ж вроде описал — более естественным и понятным способом развертывания, обработки параметров, управления порождением кода. Тем же, чем любой процедурный язык отличается от любого функционального. Математические задачи, моделирование и подобное на ФЯ решаются удобно и изящно, но как доходит до реализации обычного последовательного алгоритма, так сразу начинаются пляски.
Лучше бы с примерами. А то получается "за всё хорошее", но без конкретики.
ЕМ>У Вас слишком много ошибок в словах "примитивность" и "убожество".
В своих проектных рамках, макросы просты и мощны. Если за них вылазить, имитируя метапрограммирование, начинается hell.
ЕМ>Повторю: речь не о том, чтобы сейчас заменить шаблоны "продвинутыми макросами" — это очевидно невозможно без создания новой версии языка. Речь о том, что сперва был реализован примитивный и неудобный препроцессор, затем он заботливо сохранялся два десятка лет, а затем, "для избавления от macro hell", были созданы шаблоны, которые создали hell почище прежнего.
Нет, hell в шаблонах начинается тогда, когда вы вылазите в них за проектные рамки. Это касается любой технологии, любой части языка. Если делать на шаблонах то, ради чего их вводили, а не всякие boost::mpl, то все чики-пуки. И без шаблонов можно создать hell на goto, на switch, UB hell, hell при написании истинно-кросплатформенного кода, функциональный лямбда-hell и т.п.
Re[18]: Чем современные шаблоны лучше макросов? :)
Здравствуйте, Евгений Музыченко, Вы писали:
NB>>как это будут выглядеть на твоих макросах?
ЕМ>В этом примере is_signed вернет false, и assert обломается. А чего хотелось-то?
на уровне main (и на уровне lib2 по желанию) иметь возможность сделать так, чтобы возвращало true, очевидно
шаблоны такое сделать позволяют, а макросы?
Re[19]: Чем современные шаблоны лучше макросов? :)
Здравствуйте, night beast, Вы писали:
NB>на уровне main (и на уровне lib2 по желанию) иметь возможность сделать так, чтобы возвращало true, очевидно
Я ж привел самый простейший пример для иллюстрации. В нормальной реализации, коли уж есть стандартное условие "-1 < 0", как раз is_signed и is_unsigned стоило бы сделать через него. Но еще правильнее следовало делать такое через атрибуты типов, задаваемые непосредственно в определении класса и/или выводимые из набора определенных операций.
Re[20]: Чем современные шаблоны лучше макросов? :)
Здравствуйте, Евгений Музыченко, Вы писали:
NB>>на уровне main (и на уровне lib2 по желанию) иметь возможность сделать так, чтобы возвращало true, очевидно
ЕМ>Я ж привел самый простейший пример для иллюстрации. В нормальной реализации, коли уж есть стандартное условие "-1 < 0", как раз is_signed и is_unsigned стоило бы сделать через него. Но еще правильнее следовало делать такое через атрибуты типов, задаваемые непосредственно в определении класса и/или выводимые из набора определенных операций.
а я привел пример, когда это не работает.
lib2 ничего не знает про lib1 и необходимые для него атрибуты типов.
а специализация позволяет эти атрибуты задать не влезая в определения существующих типов.
подобного эффекта ты бы мог добиться, добавив для своих макросов перегрузку. но тогда у тебя получились бы те же шаблоны, вид сбоку.
Здравствуйте, Евгений Музыченко, Вы писали:
BFE>>Запретить неявное преобразование типа. ЕМ>Для этого не нужен макропроцессор. Нужны языковые средства задания допустимых правил преобразования.
Что ж, вот вам и ответ на вопрос темы: шаблоны позволяют сделать то, что макропроцессору не по силам.
Здравствуйте, Went, Вы писали:
W>В чем бы ваши макросы принципиально отличались от шаблонов? Процедурным подходом? Вы уверены, что он проще и выразительней?
Для операций, которые проще описываются последовательностью действий, а не подобием или рекурсией — безусловно. А подобие/рекурсия там тоже реализуются достаточно просто.
W>вы уверены, что он также расширяем? Вот написал я чудо-макрос, который для плавающих делает одно, а для целых — другое. А уже в коде ниже потребовалось добавить исключение, что для булевых нужно делать третье. Как бы я это сделал? "Расширил" бы макрос? "Заместил" бы макрос? Или специализировал?
Можно было бы предусмотреть любые удобные варианты. Такое впечатление, что Вы рассматриваете любые макросы, как предельно тупые конструкции, которые должны раскрываться сразу же, как только обнаружен соответствующий идентификатор. Но ничто не вынуждает рассматривать их именно так. По сути, шаблоны — тоже вид макросов, но обрабатываемых более сложным образом. Основная проблема, на мой взгляд, состоит в том, что шаблоны, с их функционально-регулярной парадигмой, неочевидностью и чрезмерной сложностью, противопоставлены традиционным макросам, которые убоги и примитивны. Они находятся на крайних участках шкалы возможностей, а между ними — пусто.
ЕМ>>Представьте, что в сишную main вместо argc/argv передавались бы "вариадики".
W>Вы точно понимаете, что такое вариадики?
Точно понимаю. Именно поэтому и предлагаю представить себе реализацию командно-строковой утилиты со сколько-нибудь сложным форматом параметров, в которую вместо argc/argv передаются "пакеты параметров", раскрываемые регулярным образом. А потом представьте, что кто-то таки осилил написать такую утилиту, и теперь Вам требуется ее доработать, добавив еще пару-тройку возможных параметров, формат которыых не получается уложить в выбранную систему.
W>В своих проектных рамках, макросы просты и мощны. Если за них вылазить, имитируя метапрограммирование, начинается hell.
Что значит "имитируя"? Любые макросы по определению предназначены для метапрограммирования.
W>hell в шаблонах начинается тогда, когда вы вылазите в них за проектные рамки.
При выбранном пути развития языка его было невозможно избежать. Как только появились самые первые неочевидные, "заумные" конструкции на шаблонах, лидерам разработки языка нужно было бегом дорабатывать ядро, чтобы эти конструкции могли быть реализованы по-человечески. Но они сами вдохновились этой идеей, и благословили применение шаблонов для всего, на что они технически способны (а способны они, как мы помним, вообще на все). С этого момента hell стал неизбежным.
W>И без шаблонов можно создать hell на goto
Так его успешно и создавали до тех пор, пока Дейкстра сотоварищи не показали, что любая программа с goto может быть преобразована в структурированную, и выглядеть при этом или лучше, или не хуже. До этого сторонники goto успешно защищались, приводя все более навороченные схемы, и утверждая "а вот этого вы на своем Алголе не сделаете".
Пока в ядре языка не будет средств, позволяющих удобно и эффективно делать то, что сейчас принято делать на хитровыгнутых шаблонах — hell будет только умножаться.
Здравствуйте, Евгений Музыченко, Вы писали:
W>>Вы точно понимаете, что такое вариадики? ЕМ>Точно понимаю. Именно поэтому и предлагаю представить себе реализацию командно-строковой утилиты со сколько-нибудь сложным форматом параметров, в которую вместо argc/argv передаются "пакеты параметров", раскрываемые регулярным образом. А потом представьте, что кто-то таки осилил написать такую утилиту, и теперь Вам требуется ее доработать, добавив еще пару-тройку возможных параметров, формат которыых не получается уложить в выбранную систему.
Не понимаю. Набор входящих параметров — это абсолютно динамические данные очень свободной формы. Вариадики — наборы типов, строго определенных в момент компиляции. Как в момент компиляции можно предугадать, какие данные передадутся в main? Как вывести их тип?
ЕМ>Что значит "имитируя"? Любые макросы по определению предназначены для метапрограммирования.
Использование С-макросов для кодогенерации — это hell и выход за проектные рамки. Макросы здорового человека используются только для управления процессом компиляции.
По поводу прочего — вы говорите о "хороших макросах" как о чем-то, обладающим всей мощью шаблонов, но без их недостатков. Я бы хотел понять, в чем ожидается их принципиальная разница с шаблонами?
Re[21]: Чем современные шаблоны лучше макросов? :)
Здравствуйте, night beast, Вы писали:
NB>а я привел пример, когда это не работает.
Так для любой возможности можно привести пример, когда она не работает, или бесполезна, или неудобна.
NB>а специализация позволяет эти атрибуты задать не влезая в определения существующих типов.
Для навешивания атрибутов на существующие типы тоже давно требуются языковые средства. Они крайне просты в реализации, но их не торопятся добавлять, поскольку того же можно достичь шаблонной магией. Через задницу, боль и геморрой, но технически можно. Именно поэтому тянуть будут до последнего.
NB>подобного эффекта ты бы мог добиться, добавив для своих макросов перегрузку. но тогда у тебя получились бы те же шаблоны, вид сбоку.
Так ведь шаблоны, по сути, и есть параметризованные макросы. И шаблоны, и тот вид "макросов", о котором я говорю, обрабатываются в контексте программы, а не тупых лексем. Понятное дело, что и там, и там возможна перегрузка и подобные приемы.
Здравствуйте, Went, Вы писали:
W>Набор входящих параметров — это абсолютно динамические данные очень свободной формы. Вариадики — наборы типов, строго определенных в момент компиляции. Как в момент компиляции можно предугадать, какие данные передадутся в main? Как вывести их тип?
Никакие типы выводить не нужно. Я предложил сравнить процесс обработки (во время компиляции) шаблона, в который передается переменное количество параметров, с процессом обработки (во время выполнения) кода main, в который параметры передавались бы таким же регулярным способом, что и параметры в шаблон. Реализация утилит, получающих наборы однотипных параметров разной длины, была бы несложной, зато реализация утилит с мало-мальски сложной командной строкой усложнилась бы неимоверно, а то и вовсе стала невозможной без написания отдельной процедуры для каждого набора. Именно это мы и имеем в существующем подходе к variadic.
W>Использование С-макросов для кодогенерации — это hell и выход за проектные рамки. Макросы здорового человека используются только для управления процессом компиляции.
Откуда Вы это взяли? Будь макросы предназначены исключительно для задания параметров-констант, их бы изначально ограничили до чисел, строк и идентификаторов.
W>вы говорите о "хороших макросах" как о чем-то, обладающим всей мощью шаблонов, но без их недостатков. Я бы хотел понять, в чем ожидается их принципиальная разница с шаблонами?
Да ради бога, можно вообще забыть слово "макрос", и говорить исключительно о шаблонах. Если сделать возможным использование в коде шаблона условных и циклических конструкций, позволяющих анализировать как вид переданных параметров, так и их роль в программе — получится то же самое. Собственно, адекватные макропроцессоры делают именно это.
Re[22]: Чем современные шаблоны лучше макросов? :)
Здравствуйте, Евгений Музыченко, Вы писали:
NB>>подобного эффекта ты бы мог добиться, добавив для своих макросов перегрузку. но тогда у тебя получились бы те же шаблоны, вид сбоку.
ЕМ>Так ведь шаблоны, по сути, и есть параметризованные макросы. И шаблоны, и тот вид "макросов", о котором я говорю, обрабатываются в контексте программы, а не тупых лексем. Понятное дело, что и там, и там возможна перегрузка и подобные приемы.
мне вот, например, глядя на твое определения макроса, совсем непонятно, как туда перегрузку добавить.
покажешь?
Re[23]: Чем современные шаблоны лучше макросов? :)
Здравствуйте, night beast, Вы писали:
NB>вроде это ты макросы продаешь
Я "продаю" не макросы, а идею. А главная проблема понимания — в том, что в сознании большинства программистов на C/C++ к термину "макрос" гвоздями прибито тупое, чисто лексическое преобразование, и при попытке представить себе любое другое, восприятие столь же прочно цепляется за "шаблон".
я вообще слабо понимаю подобную тональность в темах языкостроения. в С++ практиках редко бывает что-то особенно выделенное, особенно "vs", как правило для практической архитектурной задачи выбираются комбинированные решения. что на макро положили, что не шаблоны. Отличие макро от templates сугубо в том, что макро не попадают в АСТ, туда попадает С++, а препроцессор к языку (его ситаксису) не относится. Потому еслои ж и ратовать за макро, то я бы предложил внедрять их именно в АСТ, и вообще расширять до грамматик_о_ориентированного подхода, когда можно парсить
#define PARSE_TOKENS(txt) get_tok : token txt | txt token | token
etc' а то текущие костыли вида на базе __VA_ARGS__ мягко говоря напрягают
ЕМ>Считается, что функциональный стиль использования шаблонов — это благо, но многие ли способны быстро разобраться в иерархии и взаимодействии шаблонов в какой-нибудь Boost?
бывает, что ничего другого просто не остается, и приходится разбираться.
ЕМ>Вот будь вместо шаблонов приличный макропроцессор, в котором можно и параметры вызова разобрать, и циклические конструкции использовать, и за счет объединения с компилятором использовать в условиях типы, классы и их свойства — какие у шаблонов остались бы преимущества?
для этого надо внедрять препроцессор в АСТ, в противном случае он костылизуется до безобразия как баш, и судить о стандартизации (как и сейчас ведь те же итерации внутри макро по параметрам происходят в gcc MSVC и тд по разному) А если тащить их в АСТ, то это уже dsl
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здравствуйте, дев.с.оффером, Вы писали:
ДСО>>если и ратовать за макро, то я бы предложил внедрять их именно в АСТ
ЕМ>Если прочитать исходное сообщение
внимательно, то даже без чтения моих последующих разъяснений обнаружится, что именно это и предлагалось.
ЕМ>Определенно, понятия "макрос" и "макропроцессор" у подавляющего большинства накрепко прибиты гвоздями к убогому сишному препроцессору.
Вы простите, но я увидел войну. вы на стороне макросов против шаблонов. Чем, честно говоря, можно так заказать — запугиваете. Мне шаблоны оч нравятся .. в философском ткскть контексте.
а именно "что угодно во что угодно" — абстракция без которой мне не видится сейчас AI language
struct any { template <typename T> opreator T(); };
разве можно пугать отбором этого ...
а вот с раширением макро до грамматик я сршенно согласен. более того я немного ранее писал здесь .. http://rsdn.org/forum/cpp/8162357.1
после моей извращенной часто практики, где хватаются за все, получается в препроцессоре — делаешь в препроцессоре, получается в шаблонах — вперед. Я вот одного не понимаю, че все пристали к этому бедному препроцессору, хорошая вещь, там столько хороших и ценных практик, что... а — давайте засунем его в АСТ, прям вот не только в llvm. А что ??
Здравствуйте, T4r4sB, Вы писали:
TB>Закопайте этот сраный С++ поглубже нафиг, вот что я скажу.
да давайте уже закопаем это IT все вместе целиком. Вы думаете с вами цацкаться будут в ИИ ? А оно скоро вот к вам притопает прямо вот сядет рядом в виде статического анализа, и читай те эссе ..
практика показывает, что видеть ты научишься достаточно быстро. И там, где народ будет паром из мозгов брызгать, ты даже эти шаблоны ни разу не задебажишь. от поверь ...
мне коллеги говорили нетривиальный код на то, где я писал без вчитывания в эти эссе ведь понятно, что это железное )) от тебя хочет. не понимаю че вы все орете )) этож интересно ..
