Здравствуйте, ни у кого не возникало ощущения куцести плюсового препроцессора? У меня, например, периодически возникают случаи, когда его возможностей определенно хватает. Вот один из них. Стандартный случай, когда нужны методы с различными правам доступа ко внутренним переменным. Приходится писать кучу одинакового кода. Данный пример для двух переменных, и то разница уже видна, а что будет когда их число приблизится, например, к 10?

Этот случай не первый и не единственный, хотелось бы послушать общество. Заранее спасибо

в целом хватает
хотя препроцессор GAS (Gnu Assembler) по-лучше будет
я бы добавил
1. Перегрузку макрофункций

2. Циклы 

где __ITERATION__ - номер текущей итерации (0, 1, 2, ...)
3. Внутренние макродирективы


Это сообщение отредактировал(а) MAKCim - 17.5.2007, 19:30

Совершенству нет предела.
В целом - устраивает, для меня это далеко не самая важная часть программирования.
Добавить функциональность, о которой говорится в начале темы - можно, конечно... вот только, для начала, предложите для нее синтаксис.

ИМХО возможностей у препроцессора вполне достаточно, и даже они обычно не используются, потому что в С++ есть много способов сделать то же самое проще/лучше/удобнее. См. например шаблоны.
Насчет твоего примера, можно сделать например так:


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

Есть еще примеры?

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

Это же надо, 
MAKCim, Максим прочитал мои мысль, пока я ее писал...


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

Кстати, это пример плохого дизайна, а не слобости препроцессора;)

Daevaorn, ты тоже мыслечитатель?   



Первая мысль была именно такая.

Добавлено через 4 минуты и 37 секунд
Кстати, а почему нет варианта "В препроцессоре и так много лишнего, сократить до минимума". А то начинаешь юзать всякие темплейтные min/max/swap, а какой-то умник их уже через дефайны переопределил. И начинаешь чесать репу, лихорадочно соображая что сделал не так.

  
Daevaorn, 
прикольное число сообщений у тебя 1234   

ИМХО, основной недостаток препроцессора в том, что он не разбирается в том, что обрабатывает (ну разве что не трогает строки и не обрабатывает max в max1)
в этом смысле шаблоны более "встроены в язык", хотя и возможностей местами поменьше
так что, возможно, было бы неплохо, как-то сближать эти два инструмента...

Собственно шаблоны и есть аналогом препроцессора, просто шаблоны не являются препроцессором по определению )

о чем Вы?! вам мало "приятных" и незаметных вещей что дает вам препроцессор?)

кстати можете себя проверить.. код даст 50 (а вот на старых компиляторах может дать и не 50)...
смех смехом а я как-то часа 4 искал такую "ошибку" (не в своем коде).... уж никак не пологал что сделан будет макрос... вот чего в голву не пришло, того не пришло)
---------------------
все эти намудреные препроцессорные директивы выливаются в полную мешанину и панику при отладке (нее дай вам столкнуться с ошибкой неявной в большом макросе)...
------------------
inline - функции чем не устраивают?!

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

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

nickless, 
Предложенный вами вариант, конечно, упрощает, но тем не менее нужно для каждого члена класса писать вызов макроса.
Насчет шаблонов полностью согласен, но они не обеспечивают возможность перечисления членов структуры (или я не знаю как это сделать).
Еще один случай, когда это было бы удобно. Например, есть текстовый файл, из которого нужно считать структуру. В случае возможности перечисления можно было бы написать подобный код (данный пример призван показать полезность перечисления, поэтому, пожалуйста, не обращайте внимания на контроль ошибок и проч.):

Кстати вариант то правильный 

Если хочется поизвращаться - советую посмотреть ещё на boost::preprocessor. Я толком не смотрел, но если не ошибаюсь циклы там есть. Правда, наверно, с ограниченным количеством итераций (просто не представляю как сделать, юзаю лишь существующие возможности, по-другому).

А вообще шаблоны для кого придумывали? 

Наверное, вопрос был поставлен не совсем корректно. Правильней было бы спросить - устраивают ли Вас возможности метапрограммирования с С++? Тогда сюда автоматом войдут и шаблоны, и макро. Думаю функциональность шаблонов тоже есть куда расширять. Например в книге "шаблоны. Спавочник пользователя" говорится о возможности включения именованных аргументов шаблонов. Я бы еще добавил частичную специализацию по количеству шаблонных аргументов.

ты дашь гарантию, что они будут inline?   

пример надуманный (только, чтобы идентифицировать конструкцию)

я не писал компилятор (всмысле писал когда-то как курсовик), но то не о том)=> никаких гарантия я дать не могу, однако хоть стандарт и не оговаривает что inline будут inline, но компилятору я пологаю можно указать чтобы он делал принудилово... опять же как реализовано.
Да и в общем случаем "оно вам надо" ? Обычно большой оптимизации по скорости не будет (время вызова скажем __fastcall функции << времени  цикла (или иной, не подходящей под определение inline, как посчитает (если посчитает) умный компилятор) , т.о. этим временем можно пренебречь. Безусловно, существуют задачи, в которых размер стека жестко ограничен (кодинг железа, я пологаю),но с таким вещаями я не знаком и думаю там есть средства....
упс, когда писал свой пост пропустил это, но, как минимум я не один так считаю) и то гуд... это - мой вариант выбора.

вот именно, переносимость будет -> 0

макросы нужны не только для эмуляции inline

ИМХО, есть несколько принципиальных случаев/моментов, когда макросы незаменимы в принципе. То есть аналогию с помощью чисто языковых конструкций построить не удастся.
Есть еще группа случаев, когда удастся, но слишком дорогой ценой (размер или производительность пострадают).
В остальных случаях можно использовать [шаблонные ][inline ]функции.

а смысл данного опроса?  допустим мне не нравится то то, то то. Кто то согласится, кто то нет. Но это не изменит ничего. Какой-то бесполезный топик. извиняюсь за оффтоп

Вот, если так - поддержу. Только не макросы.

MAKCim, вот в реальной жизни все твои примеры с циклами и перегрузкой для макросов когда-нибудь хотелось использовать (я, конечно, про плюсы)? Сомневаюсь, если честно.


Не спорю.


Вот именно. Можешь представить практические примеры (точнее - похожие на практические), где такое можно было бы красиво использовать?

Единственное, что кстати не помешает в препроцессоре - области видимости макросов (банальные блоки). Но это вроде и так обещали...


Ну, я бы не сказал, что бесполезный. Может ничего и не изменит (99,99999 %), но поговорить интересно 

хотелось пару раз


хотя пример тоже какой-то нереальный получился   

Это сообщение отредактировал(а) MAKCim - 19.5.2007, 15:47

  По-моему, совсем нереальный. Препроцессор для асма - это совсем другой вопрос, ибо там шаблонов нет  Ввиду полнейшей непортируемости вышенаписанного кода - тяжело говорить про расширение стандартного препроцессор для этого...

Любитель, 
в С тоже нет шаблонов   
а так подумаю на досуге над примером... реальным   
кстати, если ты с make знаком, мне там очень нравятся функции типа
$(foreach)
...
можно было бы писать такое

  

 А мне кажестся, что на уровне синтаксиса это было бы удобнее $)

В G++  схожая техника используется для  эмуляции Variadic Templates(google).  



А вот самое интересное:


По топику --- для генерации сложных хедеров использую питон.


Это сообщение отредактировал(а) Mayk - 19.5.2007, 17:34

Ужас! Я на 100% уверен, найдется "профессионал", который сделает определение DIR в одном месте, а подобное использование в другом. Вот обрадуются же те, кто отлаживать возьмется (модифицировать)...  

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

Что будем перечислять для public, protected, private мемберов наследуемого класса в С++? Я бы понял, если бы это делал компилятор (конструкция языка), но препроцессор... Или препроцессор должен знать правила доступа для разных типов наследования? Или для С должен быть другой препроцессор?

Насчет foreach. В С/С++ нет контейнеров как интегральных типов данных _языка_. Они реализованы на уровне библиотек (boost, stl  и т.д.), и библиотеки поддерживают foreach (или for_each). Я не понимаю, почему это должно поддерживаться на уровне компилятора (для языка) или препроцессора. Вариант с {...in list} - это тоже частный случай контейнера, он должен каким-то образом создаться. Для каких типов данных? Это должен решать программист или препроцессор?

Сравните с Perl, где тип контейнеров - часть языка.

Hurricane, 
про что ты говоришь, и что я написал   

Да кто спорит? Компилятор, он, родимый. Главное - функциональная возможность, а не чем и через что она будет реализована.
Пускай будет конструкция языка. Просто по сути это будет "языковой препроцессор".


А насчет for_each про контейнеры речь и не шла. См. пост MAKCimа выше.

Ты гарантируешь, что не найдется умник, который будет использовать это не для включения файлов, а для работы с  данными или чего-нибудь еще? Не верю.

Hurricane, 
Для перечисления методов с различным доступом можно использовать ключевые слова (for each protected, public ..) - здесь проблем не вижу. Другой вопрос - на кого можно было бы возложить данную задачу (препроцессор или шаблоны) и стоит ли ее вообще решать. Судя по обсуждению - большинство довольствуется существующими возможностями метапрограммирования, а значит никаких нововведений в данном ключе не предвидится. Может быть это правильно, и позволит избежать появления винегрета типа c#, но, с другой стороны, если расширить функциональность (без потери в производительности, совместимости и удобстве) то наверняка появится и спрос на подобные возможности.

Ключевые слова pivate, protected и т.д. не спасут - препроцессор все равно должен будет иметь представление о видимостях членов и методов классов - они объявляются все скопом в соответствующих секциях, а не каждый индивидуйно (как в С#, например). Кроме того, если класс наследуется и какой-либо из членов или методов не перегружен (используется из родительского класса) - надо ли их включать? Можно, конечно, нагородить ключевых слов для всех возможных ситуаций, но я не думаю, что это будет хорошо.

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

Ну консерватор я, консерватор!   

Это сообщение отредактировал(а) Hurricane - 21.5.2007, 18:40

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

я ничего не гарантирую
более того, следуя твоей логике, вообще следует много от чего отказаться, потому как "найдется умник..."   

Погоди, я попробую угадать... Т.е. на самом деле - умники не находятся, сложность конструкций никак не связана с их безопасностью, и вообще, это все выдумки Hurrican'а, так?   

шаблоны С++ сложны? 
безопасны?

1. Мы говорим о шаблонах вообще (как о конструкции языка) или о конкретных реализациях в виде boost, stl и т.п.?
2. Возможно, что это только мне так невезло, но я видел намного больше проблем, созданных препроцессором (неумелым его использованием), чем шаблонами. Во всяком случае шаблоны - часть языка, и в большинстве случаев компилятор тут же дает по рукам при попытке неправильного их использования. С препроцессором это не так.

В названии темы стоят плюсы   


Угу.


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