subj
>subjsprintf/snprintf
>subj
//...
#include <sstream>
//...
int n= 1234567;std::ostringstream stringout;
stringout << "n =" << n;std::string msg= stringout.str();
std::cout << msg << std::endl;
Можно самому написать такую - алгоритм совсем не сложен. А еще легче преобразовать в шестнадцатиричное число.
>Можно самому написать такую - алгоритм совсем не сложен.
"No problem should ever have to be solved twice":
http://www.catb.org/~esr/faqs/hacker-howto.html#believe2>А еще легче преобразовать в шестнадцатиричное число.
stringout << hex << n;
>>subj
>//...
>#include <sstream>
>//...
>int n= 1234567;
>
>std::ostringstream stringout;
>stringout << "n =" << n;
>
>std::string msg= stringout.str();
>std::cout << msg << std::endl;это все уже есть готовое в виде boost::lexical_cast (http://boost.org/libs/conversion/lexical_cast.htm)
>>>subj
>>//...
>>#include <sstream>
>>//...
>>int n= 1234567;
>>
>>std::ostringstream stringout;
>>stringout << "n =" << n;
>>
>>std::string msg= stringout.str();
>>std::cout << msg << std::endl;
>
>это все уже есть готовое в виде boost::lexical_cast
>(http://boost.org/libs/conversion/lexical_cast.htm)
Ну, тогда уж и boost::spirit и всё остальное...
Интересно, а почему не реализовали itoa?
>Интересно, а почему не реализовали itoa?
itoa() изовретение Borland (на сколько я знаю).
Тогда, в момент изобретения itoa() уже существовала sprintf(), а в такой
ситуации разработчики стандарта не пойдут ни за что на его расширение.
Кстати, даже snprintf() до сих пор (на сколько мне известно) не включена
в ISO C.
>>Интересно, а почему не реализовали itoa?
>itoa() изовретение Borland (на сколько я знаю).
>Тогда, в момент изобретения itoa() уже существовала sprintf(), а в такой
>ситуации разработчики стандарта не пойдут ни за что на его расширение.
>Кстати, даже snprintf() до сих пор (на сколько мне известно) не включена
>
>в ISO C.http://www.opengroup.org/onlinepubs/009695399/functions/snpr...
// wbr
>>Интересно, а почему не реализовали itoa?
>itoa() изовретение Borland (на сколько я знаю).
>Тогда, в момент изобретения itoa() уже существовала sprintf(), а в такой
>ситуации разработчики стандарта не пойдут ни за что на его расширение.
>Кстати, даже snprintf() до сих пор (на сколько мне известно) не включена
>
>в ISO C.
Дурь какая-то (это я про itoa) - такая простая и полезная функция, и вот тебе здрасти - нестандартная и нереализованная. Если говорить о семействе sprintf: по моему в выборе между функцией, которая не проверяет размер буфера и той, что проверяет должен быть однозначный выбор в пользу второй. Даже если это и не везде поддерживается.
>>>Интересно, а почему не реализовали itoa?
>>itoa() изовретение Borland (на сколько я знаю).
>>Тогда, в момент изобретения itoa() уже существовала sprintf(), а в такой
>>ситуации разработчики стандарта не пойдут ни за что на его расширение.
>Дурь какая-то (это я про itoa) - такая простая и полезная функция,
>и вот тебе здрасти - нестандартная и нереализованная. Если говорить о
>семействе sprintf: по моему в выборе между функцией, которая не проверяет
>размер буфера и той, что проверяет должен быть однозначный выбор в
>пользу второй. Даже если это и не везде поддерживается.
Ну, если, например, говорить об этой реализации:
http://www.cplusplus.com/ref/cstdlib/itoa.html
то сами посудите: максимальный размер буфера для itoa() зависит от
платформы. То бишь, программа, написанная в конце 80-х с прицелом на то,
что 64 разрядные архитектуры появятся не скоро, и сейчас скомпилируется
успешно, но...
Вообще говоря, любой стандарт сам по себе -- это нонсенс: то, что
стандартизовано, уже не является оптимальным решением.
>Вообще говоря, любой стандарт сам по себе -- это нонсенс: то, что
>
>стандартизовано, уже не является оптимальным решением.это почему?
// wbr
>>Вообще говоря, любой стандарт сам по себе -- это нонсенс: то, что
>>
>>стандартизовано, уже не является оптимальным решением.
>
>это почему?
>
>// wbr
Стандарт призван удовлетворить всех.
Если он этого не делает, то он умирает. Не сушествует оптимального
решения, которое осталось бы оптимальным для всех. Исключения ничтожны.
Фактически, стандарт -- это решение, которое более-менее кое-как ещё
удовлетворяет хотя бы большинство. О кокой-то оптимальности, особенно
в конкретном классе задач говорить не приходится.
Если посмотреть статистику успешных коммерческих решений, впереди окажутся
те, которые намеренно игнорируют стандарты. А стандарты в свою очередь
вынуждены учитывать эти успехи, становясь всё безобразнее.
Выходит, "стандартное" не значит "лучшее", а скорее -- наоборот.
>Стандарт призван удовлетворить всех.
>Если он этого не делает, то он умирает. Не сушествует оптимального
>решения, которое осталось бы оптимальным для всех. Исключения ничтожны.
>Фактически, стандарт -- это решение, которое более-менее кое-как ещё
>удовлетворяет хотя бы большинство. О кокой-то оптимальности, особенно
>в конкретном классе задач говорить не приходится.
>Если посмотреть статистику успешных коммерческих решений, впереди окажутся
>те, которые намеренно игнорируют стандарты. А стандарты в свою очередь
>вынуждены учитывать эти успехи, становясь всё безобразнее.
>Выходит, "стандартное" не значит "лучшее", а скорее -- наоборот.а можно живой пример?
// wbr
>>Стандарт призван удовлетворить всех.
>>Если он этого не делает, то он умирает. Не сушествует оптимального
>>решения, которое осталось бы оптимальным для всех. Исключения ничтожны.
>>Фактически, стандарт -- это решение, которое более-менее кое-как ещё
>>удовлетворяет хотя бы большинство. О кокой-то оптимальности, особенно
>>в конкретном классе задач говорить не приходится.
>>Если посмотреть статистику успешных коммерческих решений, впереди окажутся
>>те, которые намеренно игнорируют стандарты. А стандарты в свою очередь
>>вынуждены учитывать эти успехи, становясь всё безобразнее.
>>Выходит, "стандартное" не значит "лучшее", а скорее -- наоборот.
>
>а можно живой пример?
А можно контрпример? :)Если серьёзно, игнорирование стандартов -- одна из политик Microsoft
(да и любой крупной коммерческой фирмы тоже). Даже Qt использует moc,
когда вполне могла бы обойтись стандартными средствами.
По части уродливых стандартов впереди планеты всей, конечно же POSIX,
содержащий кроме обычных противоречий даже и смешные ошибки, вроде
getopt(). Так что примеров море не мерено.
Если Вы думаете, что я рекомендую игнорировать стандарты, то... обижусь,
наверное, даже...
Важно понимать, что стандарты разрабатыват люди, и языки разрабатывают
люди, а не боги; а человек слаб и не разумен -- таковы и творения рук его
(Боб Льюис).
Обычно очень не хочется искать оптимальное решение, хочется
иметь стандартное. А нужно делать обратное: постоянно совершенствовать стандарты и языки, бороться с ненасытными корпорациями (в том числе и,
соотвестсвующим трёпом в печати), и учиться, и вообще -- делать то, что
делать лень).
>А можно контрпример? :)нет, нельзя.
ps: не я же выдвигал оригинальное и весьма своеобразное утверждение? если вы что-то утверждаете - будьте добры при необходимости это отстоять.
>Если серьёзно, игнорирование стандартов -- одна из политик Microsoft
ну и что? я так понимаю, вы на основании этого делаете вывод, что стандарты - зло?
>(да и любой крупной коммерческой фирмы тоже).
> Даже Qt использует moc,
>когда вполне могла бы обойтись стандартными средствами.по поводу moc - нет, не могли. по крайней мере, в рамках той модели, которую они построили. внимательнее читайте документы от TrollTech, там это достаточно хорошо описано зачем им надстройки над C++. в противном случае, это был бы уже совсем не Qt а что-то другое.
по поводу следования Qt стандартам - опять же неправда. как раз этот продукт стандартам старается следовать, за что в том числе и ценим.
>По части уродливых стандартов впереди планеты всей, конечно же POSIX,
>содержащий кроме обычных противоречий даже и смешные ошибки, вроде
>getopt(). Так что примеров море не мерено.ммм.. а какие собственно проблемы с getopt()? и можно еще один-два примера из моря дегтя POSIX?
>Если Вы думаете, что я рекомендую игнорировать стандарты, то... обижусь,
>наверное, даже...я пока что не совсем понял, что же именно вы рекомендуете.
>Важно понимать, что стандарты разрабатыват люди, и языки разрабатывают
>люди, а не боги; а человек слаб и не разумен -- таковы
>и творения рук его
>(Боб Льюис).согласен, люди. ну и что?
>Обычно очень не хочется искать оптимальное решение, хочется
>иметь стандартное.пардон, из ваших аргументов я пока что не увидел явного противоречия между стандартным и оптимальным решением. тем более, что понятие оптимальное - это ой какое широкое понятие.
> А нужно делат..
[вода поскипана]
// wbr
>>А можно контрпример? :)
>
>нет, нельзя.
>
>ps: не я же выдвигал оригинальное и весьма своеобразное утверждение? если вы
>что-то утверждаете - будьте добры при необходимости это отстоять.
Беспроблем.
Но несогласие с таким хрестоматийным утверждением, как то,
что стандарты -- это совсем не оптимальные решения, мне кажется ещё более
оригинальным, и потому контрпример уместен.>>Если серьёзно, игнорирование стандартов -- одна из политик Microsoft
>
>ну и что? я так понимаю, вы на основании этого делаете вывод,
>что стандарты - зло?
Стандарты -- не зло, а добро. Но мой вывод я делаю и на основании этого
примера тоже, а что?>> Даже Qt использует moc,
>>когда вполне могла бы обойтись стандартными средствами.
>
>по поводу moc - нет, не могли. по крайней мере, в рамках
>той модели, которую они построили. внимательнее читайте документы от TrollTech, там
>это достаточно хорошо описано зачем им надстройки над C++. в противном
>случае, это был бы уже совсем не Qt а что-то другое.
И это другое -- более стандартное решение. Это не был бы Qt, потому что
Qt -- не вполне стандартное решение, но она очень хорошее решение, и
спасибо ему, что оно есть, хотя и его авторы пытаются придумать сказки о
том, как без moc нельзя обойтись, но всем и так понятно, причём тут был
moc (в 1991 году).>по поводу следования Qt стандартам - опять же неправда. как раз этот
>продукт стандартам старается следовать, за что в том числе и ценим.
Троли лучше других это понимают. Поэтому я и говорю: "_даже_ Qt".>>По части уродливых стандартов впереди планеты всей, конечно же POSIX,
>>содержащий кроме обычных противоречий даже и смешные ошибки, вроде
>>getopt(). Так что примеров море не мерено.
>
>ммм.. а какие собственно проблемы с getopt()? и можно еще один-два примера
>из моря дегтя POSIX?
man getopt>>Если Вы думаете, что я рекомендую игнорировать стандарты, то... обижусь,
>>наверное, даже...
>
>я пока что не совсем понял, что же именно вы рекомендуете.
Не создавать себе кумиров в виде самых любимых языков/библиотек/стандартов/технологий.>>Важно понимать, что стандарты разрабатыват люди, и языки разрабатывают
>>люди, а не боги; а человек слаб и не разумен -- таковы
>>и творения рук его
>>(Боб Льюис).
>
>согласен, люди. ну и что?
Люди не смогут создать даже просто хороший стандарт, куда уж им до
оптимального стандарта, на который бы можно было смотреть иначе, чем
просто на ещё одну бумажку.>>Обычно очень не хочется искать оптимальное решение, хочется
>>иметь стандартное.
>
>пардон, из ваших аргументов я пока что не увидел явного противоречия между
>стандартным и оптимальным решением. тем более, что понятие оптимальное - это
>ой какое широкое понятие.
Да. Мы отклнились.
Началось всё с недоумения dimus о том, почему itoa() не стандартизована.
Причина в том, что она не может быть стандартизована. И ответ на вопрос
"Почему?" в том, что такое стандарт, а не в том, насколько хороша itoa().
>>по поводу moc - нет, не могли. по крайней мере, в рамках
>>той модели, которую они построили. внимательнее читайте документы от TrollTech, там
>>это достаточно хорошо описано зачем им надстройки над C++. в противном
>>случае, это был бы уже совсем не Qt а что-то другое.
>И это другое -- более стандартное решение.например, gtk-- ? знаем, плавали. все очень стандартно и практически по шаблону. но абсолютно неюзабельно без поллитры :)
> Это не был бы Qt,
>потому что
>Qt -- не вполне стандартное решение, но она очень хорошее решение, и
>
>спасибо ему, что оно есть, хотя и его авторы пытаются придумать сказки
>о
>том, как без moc нельзя обойтись, но всем и так понятно, причём
>тут был
>moc (в 1991 году).причем? :)
>>по поводу следования Qt стандартам - опять же неправда. как раз этот
>>продукт стандартам старается следовать, за что в том числе и ценим.
>Троли лучше других это понимают. Поэтому я и говорю: "_даже_ Qt".ну тогда уж стоит добавить "даже Microsoft". или, по вашему, они совершенно не следуют никаким стандартам? :)
>>>По части уродливых стандартов впереди планеты всей, конечно же POSIX,
>>>содержащий кроме обычных противоречий даже и смешные ошибки, вроде
>>>getopt(). Так что примеров море не мерено.
>>ммм.. а какие собственно проблемы с getopt()? и можно еще один-два примера
>>из моря дегтя POSIX?
>man getoptпардон, man - это man, а POSIX - это POSIX. в первом может быть написано практически все, что душе угодно в различной вариации, в зависимости от системы и расположения звезд на небе. во втором смотрим тут:
http://www.opengroup.org/onlinepubs/009695399/functions/geto...
в чем там противоречие?
>>я пока что не совсем понял, что же именно вы рекомендуете.
>Не создавать себе кумиров в виде самых любимых языков/библиотек/стандартов/технологий.ну а причем тут следование или нет стандартам? ежу понятно, что у каждого стандарта есть область применения. что бывает при попытках использовать инструмент не по назначению многие знают, с этим никто не спорит.
>>согласен, люди. ну и что?
>Люди не смогут создать даже просто хороший стандарт, куда уж им до
>оптимального стандарта, на который бы можно было смотреть иначе, чем
>просто на ещё одну бумажку.и это утверждение я не понял. возьмем тот-же POSIX 1001.x. стандарт? да. хороший? ну судя по всему - как посмотреть. с моей точки зрения в своей области - более чем. ему не следуют и это просто бумажка? ой, не верю. причем делалось обычными людьми как мы с вами.
>Да. Мы отклнились.
>Началось всё с недоумения dimus о том, почему itoa() не стандартизована.
>Причина в том, что она не может быть стандартизована. И ответ на
>вопрос
>"Почему?" в том, что такое стандарт, а не в том, насколько хороша
>itoa().у любого стандарта есть цель. в том числе и у ANSI C и POSIX. и ооочень широкая аудиенция, которую нужно покрыть. и если itoa используется лишь маааленьким подмножеством народу, то заставлять всех остальных реализовать ее просто неразумно. отсекается все, что только можно с точки зрения разума и практики. и так в таком скромном подмножестве интерфейсов уже туева хуча.
мне вот на BSD вызов getprogname() нравится. простенько и со вкусом. хотя ни в ANSI C ни в POSIX не входит. ну и что собственно? от этого ни та ни другая сторона не пострадали.
// wbr
>>И это другое -- более стандартное решение.
>
>например, gtk-- ? знаем, плавали. все очень стандартно и практически по шаблону.
>но абсолютно неюзабельно без поллитры :)
Полностью согласен. Qt пока абы не самое лучшее решение в своём классе, и
спасибо ей за это.>> Это не был бы Qt,
>>потому что
>>Qt -- не вполне стандартное решение, но она очень хорошее решение, и
>>
>>спасибо ему, что оно есть, хотя и его авторы пытаются придумать сказки
>>о
>>том, как без moc нельзя обойтись, но всем и так понятно, причём
>>тут был
>>moc (в 1991 году).
>
>причем? :)
Это вопрос, или несогласие с утверждением о том, что (в сослагательном
наклонении) Троли без moc смогли бы обойтись и в 92-м?
Но они этого не сделали (и не могли сделать; это уже к ответу на вопрос);
получилось презамечательно -- ну и ладно.
А теперь к вопросу "Причём?".
Я делал два утверждения: a) стандартное решение почти никогда не бывает
оптимальным; b) коммерческая организация (любая) не стремится следовать
стандартам, а наоборот -- всячески стремится их проигнорировать.
Утверждение b -- ответ на "Причём?" (Qt -- коммерческий продукт).>>>по поводу следования Qt стандартам - опять же неправда. как раз этот
>>>продукт стандартам старается следовать, за что в том числе и ценим.
>>Троли лучше других это понимают. Поэтому я и говорю: "_даже_ Qt".
>
>ну тогда уж стоит добавить "даже Microsoft". или, по вашему, они совершенно
>не следуют никаким стандартам? :)
Моё мнение: Microsoft, если бы была в состоянии, не следовала бы вообще
никаким стандартам. Более того -- это неследование стандартам её
основная политика по отношению к любым стандартам и договорённостям.
Примеры нужны?>>>>По части уродливых стандартов впереди планеты всей, конечно же POSIX,
>>>>содержащий кроме обычных противоречий даже и смешные ошибки, вроде
>>>>getopt(). Так что примеров море не мерено.
>>>ммм.. а какие собственно проблемы с getopt()? и можно еще один-два примера
>>>из моря дегтя POSIX?
>>man getopt
>
>пардон, man - это man, а POSIX - это POSIX. в первом
>может быть написано практически все, что душе угодно в различной вариации,
>в зависимости от системы и расположения звезд на небе. во втором
>смотрим тут:
>
>http://www.opengroup.org/onlinepubs/009695399/functions/geto...
>
>в чем там противоречие?
Я вот о чём:
The POSIX.2 specification of getopt() has a technical
error described in POSIX.2 Interpretation 150. The GNU
implementation (and probably all other implementations)
implements the correct behaviour rather than that speci-
fied.
Не смешно? Документ, содержащий подобное стоит принимать всерьёз?
Но это я смеюсь, конечно. POSIX ругать неприлично даже: он есть
героическая попытка систематизировать 30-ти летний опыт, и попытка
успешная. Но это всего лишь стандарт и ему характерно всё, что характерно
любому стандарту: то, что стандартизовано не есть самое лучшее. Очень
вредно думать иначе, я сильно возражаю против этого.>>>я пока что не совсем понял, что же именно вы рекомендуете.
>>Не создавать себе кумиров в виде самых любимых языков/библиотек/стандартов/технологий.
>
>ну а причем тут следование или нет стандартам? ежу понятно, что у
>каждого стандарта есть область применения. что бывает при попытках использовать инструмент
>не по назначению многие знают, с этим никто не спорит.
Дело не в области применения. Я имею в виду, конечно, именно область
применения стандарта. Решение о выборе стандартного или нестандартного
решения принимать нужно взвешенно, отводя стандарту подобающее место,
которое вовсе не на троне находится. Это я мимел в виду.>>>согласен, люди. ну и что?
>>Люди не смогут создать даже просто хороший стандарт, куда уж им до
>>оптимального стандарта, на который бы можно было смотреть иначе, чем
>>просто на ещё одну бумажку.
>
>и это утверждение я не понял. возьмем тот-же POSIX 1001.x. стандарт? да.
>хороший? ну судя по всему - как посмотреть. с моей точки
>зрения в своей области - более чем. ему не следуют и
>это просто бумажка? ой, не верю. причем делалось обычными людьми как
>мы с вами.
На это я, вроде бы, ответил выше.>>Да. Мы отклнились.
>>Началось всё с недоумения dimus о том, почему itoa() не стандартизована.
>>Причина в том, что она не может быть стандартизована. И ответ на
>>вопрос
>>"Почему?" в том, что такое стандарт, а не в том, насколько хороша
>>itoa().
>
>у любого стандарта есть цель. в том числе и у ANSI C
>и POSIX. и ооочень широкая аудиенция, которую нужно покрыть. и если
>itoa используется лишь маааленьким подмножеством народу, то заставлять всех остальных реализовать
>ее просто неразумно. отсекается все, что только можно с точки зрения
>разума и практики. и так в таком скромном подмножестве интерфейсов уже
>туева хуча.
Это верно, но не точно. Как я понимаю, Вам кажется, что стандарт (любой,
не только в программировании) -- это собрание лучшего опыта, а это как раз
наоборот. Стандарт -- это набор решений, худших из всех вообще допустимых.>мне вот на BSD вызов getprogname() нравится. простенько и со вкусом. хотя
>ни в ANSI C ни в POSIX не входит. ну и
>что собственно? от этого ни та ни другая сторона не пострадали.
Переносимость страдает, но это очень сложная тема -- не стоит об этом.
>Интересно, а почему не реализовали itoa?
из-за размера int (равен машинному слову, зависит от архитектуры),
а вот long имеет более фиксированный размер (дважды short) ;-)
и для него в glibc есть ltoa/atol
>>Интересно, а почему не реализовали itoa?
>из-за размера int (равен машинному слову, зависит от архитектуры),
>а вот long имеет более фиксированный размер (дважды short) ;-)
>и для него в glibc есть ltoa/atol
взял слова по поводу ltoa обратно ;-) исторически склалось, что везде c сабой таскал макрос его заменяющий ;-) (на базе snprintf) и уже начал его воспринимать как само собой разумеющееся