конструктор с переменным числом аргументов...

х.з. насчёт кодировки - наверное, вы правы. ну тогда уж не PCXSTR, а PCSTR. хотя, с другой стороны, работать с разными типами строк в методе format тоже не оч удобно.

 

А зачем в стандарт это вводить? Давайте не будем путать язык с компилятором этого языка.

И что? Назвался груздем -- полезай в кузов. Если это компилятор C++, то пускай тянет stdarg. Если же компилятор не предоставляет ни stdarg, ни возможности реализовать его функциональность, то пускай не называет себя гордым именем C++.
О переносимости здесь речи нет, равно как и о поддержке другими компиляторами. Каждый компилятор C или C++ имеет такого рода черезжопные расширения, добавленные для каких-то очень конкретных целей, и не претендующие на внесение в какой бы то ни было стандарт. Разработчики не гарантируют ничего, относительно этих расширений, даже того, что они будут существовать при смене версии компилятора с x.x.123 на x.x.124. И поэтому эти фичи крайне скупо документированы, специально для того, чтобы какой-нибудь "умник" не решил бы использовать их в своей программе, и не ныл бы потом, когда эти фичи будут выкинуты из очередной версии компилятора.
В данной ситуации разработчики gcc желая соответствовать стандарту _предоставляют_ файл stdarg.h вместе с компилятором. Если им самим не понравятся эти __builtin_*, если они придумают/сделают что-то другое в очередной версии компилятора, то они просто приложат к компилятору stdarg.h немного другого содержания. И разработчики каждой конкретной реализации libc, даже париться не будут на тему "как реализовать stdarg, чтобы он работал с gcc", они просто ничего делать не будут. gcc сам добавит в список директорий с include'ами что-нибудь типа /usr/lib64/gcc/x86_64-pc-linux-gnu/4.3.2/include/ или /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/include/. Черезжопный это способ или нет -- я не знаю, тебе виднее, вероятно в своём компиляторе ты сделал иначе, так?

 

r90
Раз этого нет в стандарте, то никто и не обязан это реализовывать. Вот когда будет чётко прописано поведение макроса va_start в случае ссылок, тогда и можно будет кидать тухлые помидоры в разработчиков компиляторов. Хотя я тоже не против нормального поведения, но раз нет, так нет.

 

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

 

Держи. Подарок. Я погуглил немного, и почитал стандарт.

ps. Трындец какое удовольствие разговаривать с такими "знатоками" стандартов. Они гнать туманную пургу типа "когда будет чётко прописано...", "нормальное поведение...", и проч. раздувая топик до невообразимых размеров. Нет, ну что сложно было просто сослаться на стандартное поведение va_start при ссылочном типе rightmost параметра, процитировав здесь стандарт? Там ведь, как обычно, всё чётко прописано. Можно было даже не цитировать, а сказать: "я читал, там написано, что это работоспособность данной конструкции в C++ стандартом объявлена как undefined." Я бы поверил в это. А в туман, который ты подпустил -- он скорее заставляет сомневаться.

 

Нет не думаю. Просто нефиг пользоватся недокументированными фичами. И нефиг сливать сорцы аппликухи, которые написаны человеком использующим недокументированные фичи чего бы то ни было.
"нефиг" -- это не означает, что нельзя. Можно, но надо отдавать себе полный отчёт о возможных последствиях.

 

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

 

r90
Я стандарта не читал, но во многих источниках написано, что такое поведение va_start нормально. То что ты нашёл стандарт это хорошо, но не понятно к чему тут праведное возмущение.

 

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

Что в этом хорошего? Я всё равно ничем кроме gcc не пользуюсь, и найденная в стандарте информация мне практически бесполезна. Более того, я и g++ использую крайне редко.

Я ведь написал откуда возмущение, и даже потом раскрыл вопрос довольно-таки подробно. Не?

 

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

Помог другим, молодец. Что я один должен впрягаться за других? ^)

 

Я смотрю тема, как и положено, плавно превращается в срач? )))

 

уже довольно давно

 

Сами же и засрали. Достаточно было сказать, что функции с переменным числом аргументов неприемлимы в С++ из-за типонебезопасности То что хочет автор топика называется string builder и обычно реализуется семейством свободных функций. Кстати std::basic_string в STLPort использует expression templates для конкатенации строк в компайл-тайм.

 

это уже ближе к теме. а если не юзать AutoPtr и прочие приколы ATL, если передавать дополнительные параметры через указатели, ведь не должно быть никаких проблем?

 

Это слишком категоричное утверждение. А StringBuilder концепция той же строки, но с оптимизацией для изменения.

 

Booster

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


J0E

Ты чо, батяня, какая конкатенация в компайл-тайм?


maksim_

 

J0E

специально качнул либу.
долго смотрел код. ничего подобного не увидел
_DEN_

а я поверил в чудеса

 

_DEN_

Предлагаешь как и J0E бесконечное кол-во функций?

RedLord

Аналогично. По Джосьютису(о фамилия) цель stlport, это безопасный stl с проверками. Так что он скорее менее эффективен чем стандартный, небезопасный.

 

Booster

Неограниченность elipsis-функций - совсем не понт. Если человек складывает в одном выращении стопитсот аргументов, то это уже какбэ намекает, что человек ошибся профессией. Посмотри на boost::bind - сделано несколько перегрузок функции, и все довольны и счастливы, поскольку все RAII-тельненько и типобезопасненько.

Главный недостаток эллипсов это то, что они рантаймовые (со всеми вытекающими проблемами). Однако эта рантаймовость никому не нужна - в действительности чуть менее чем 100% юзерам хватило бы и компайлтаймовых эллипсисов. В C++0x таковые есть (будут), и имя им - variadic templates.

 

_DEN_
Ведь проблема не в кол-ве параметров, сделать сто питьсот функций