преобразование числа в строку

[Olej]

мне вот интересно, а что, если применять функции языка С в коде С++ это извращение? вроде как С является частью С++.

1. С никогда не являлся "частью" С++ - это 2 отличающихся языка одной группы, на С могут быть написаны такие конструкции, которые синтаксически не пройдут контроль С++, их немного, но есть, см. Б.Страуструпа.

2. Linux (само ядро) + все проекты (утилиты) GNU + большинство используемых в Linux сторонних проектов - выписаны на классическом C (с синтаксическими расширениями GCC, правда)...

3. так что все разговоры о кошерности С++ или некошерности С - это всё исходит исключительно из уст пыанэров, толком не написавшим и 10 строк собственного практического кода ... кроме списанных курсовых

4. а абсолютно весь API и почти все конструкции C можете правомерно использовать в С++ коде ... как о том см. у того же Б.Страуструпа ... только умники, они же "не читатели, а писатели". Так же (использованием API стандартной библиотеки С, всех syscall системных вызовов) сделана и стандартная библиотека С++ от её разработчиков.

5. таким образом и С и С++ каждый хорош для тех целей и задач, где именно он уместен, а программный проект хорош тот, как писалось от Bell Labs. - "который работает", независимо от того, на чём и как он выписан.

P.S. а преобразовывать числа в строку в Linux уместнее всего sprintf("...%d...", ...) как это делается в сотнях (если не в тысячах) мест в коде ядра того же Linux.

[Yurror]

Однако задача стояла на С++
и sprintf не безопасна особенно в кривых руках о чем можно даже на русском прочитать во всё той же википедии
тем более что вызов функции у тебя не правильно написан: буфер забыл первым ппараметром
а потом вау че это оно у меня падает

[Olej]

тем более что вызов функции у тебя не правильно написан: буфер забыл первым ппараметром
а потом вау че это оно у меня падает

Ну, я же писал не настолько для пыанэров, которые даже не знают чем по прототипу sprintf() отличается от printf()... 

[alecsartania]

О-о а если еще вспомнят из руководства классику
if (!sscanf(argvc[1],"%d",&dos_sleep)){
                printf("Необходим аргумент\n");
                return;
}

То и ваще круто.

[Olej]

Однако задача стояла на С++

В том то и фокус, что любое действие нужно делать минимально достаточными средствами, а весь POSIX API в Linux (который почему-то по простоте душевной называют стандартной библиотекой С - нет в природе такого стандарта!) доступен и в С++ как базис.

А то ещё и boost приплели, как "стандартное средство преобразования числа в строку" ... не стыдно?
Можно с таким же успехом вспомнить и другую такую же обёртку к библиотекам: Apache Portable Runtime (APR) - http://www.ibm.com/developerworks/ru/library/os-apache_8/ - которая и сделана в точности для тех же целей что и boost: сгладить переносимость языковых механизмов между разными ОС ... и не более того.

Очень можно и тип string использовать (здесь кто-то показывал), и даже написать пользовательский оператор преобразования типа int->string ... но только реализация всех этих удобств будет всё равно записана через sprintf().

и sprintf не безопасна особенно в кривых руках о чем можно даже на русском прочитать во всё той же википедии

В википедии, особенно русской - можно вообще много о чём начитаться...
Как говорил профессор Преображенский: "Не читайте википедию перед едой".
Пользователь решил продолжить мысль 20 Февраля 2012, 13:58:12:

... но только реализация всех этих удобств будет всё равно записана через sprintf().

В этом смысле очень любопытно собрать 2 сравнительных программы С & C++, по принципу "меньше не бывает":
prog_c.c :

Код: [Выделить]

#include <stdio.h>

int main( int argc, char *argv[] ) {
   printf( "Hello, world!\n" );
   return 0;
};
prog_cc.cc :

Код: [Выделить]

#include <iostream>
using std::cout;
using std::endl;

int main( int argc, char *argv[] ) {
   cout << "Hello, world!" << endl;
   return 0;
};
+ глянуть какие они библиотеки будут подтягивать:

Код: [Выделить]

[olej@notebook prog_sys_call]$ ldd ./prog_c
        linux-gate.so.1 =>  (0x001de000)
        libc.so.6 => /lib/libc.so.6 (0x007ff000)
        /lib/ld-linux.so.2 (0x007dc000)
[olej@notebook prog_sys_call]$ ldd ./prog_cc
        linux-gate.so.1 =>  (0x0048f000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x03927000)
        libm.so.6 => /lib/libm.so.6 (0x0098f000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x0054c000)
        libc.so.6 => /lib/libc.so.6 (0x007ff000)
        /lib/ld-linux.so.2 (0x007dc000)
- не странно во втором случае (С++) libc.so.6 ?

А потом убедиться, что на выполнении вызовы (многие) библиотеки С++ - это всего лишь то, что ретранслируется тут же в вызовы библиотеки POSIX API:

Код: [Выделить]

[olej@notebook prog_sys_call]$ strace ./prog_c
...
write(1, "Hello, world!\n", 14Hello, world!
)         = 14
...
[olej@notebook prog_sys_call]$ strace ./prog_cc
...
write(1, "Hello, world!\n", 14Hello, world!
)         = 14
...

А все "изысканные" формы записи С++ зачастую - это только то, как красивше это выразить на бумаге.

[Yurror]

=)

Olej, прямо таки адская необходимость обойтись минимумом.
можно и на ассемблере написать. вся фишка в том что там никто по рукам не настучит
sprintf настучит чуть больше чем ассемблер
lexical_cast таких пистонов вставит криворуким идиотам что еще долго будут плеваться от С++
не гоняйся за простотой. она шибко кажущаяся =) можно наделать много ляпов. прямо как ты. описка, понимаю, но функция с переменным числом аргументов и прекрасно все прожуёт с выключенными варнингами даже не ругнётся а потом просидишь ты 2 минуты и лишняя пересборка и дурачки которые у тебя скопипастят 2 дня просидят и будут долго вопить что у них что-то падает.

boost далеко не стандартное средство. я и написал что оно не в стандарте. но изучать и пользоваться стоит. когда изучают С++ наверное предполагается что с Си знакомы и не интересно делать sprintf тем более топикстартер хотел сделать так static_cast<char>(int) бугага. но типа по стилю lexical_cast для него был бы меньшим порясением чем знакомство с sprintf тем более что функционал необходимый добавляется одним sudo apt-get install boost-dev

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

то что реализация будет через спринтф ой не факт =) STL бывает сильно разный

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

...который почему-то по простоте душевной называют стандартной библиотекой С - нет в природе такого стандарта!) доступен и в С++ как базис...

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
Глава 7. страница 198.
Иногда лучше жевать, чем говорить.

Ну а с POSIX'ом ты лажанулся =) открой стандарты и почитай. POSIX и стандартная библиотека Си это хоть и пересекающиеся но разные множества. Завязывай придираться
Пользователь решил продолжить мысль 20 Февраля 2012, 14:09:28:Чем красивее на бумаге, тем меньше шансов наделать ляпов.
Поэтому я за питон как первый язык программирования. Он приучает делать красивые отступы, там это часть синтаксиса, блоки по другому не оформить.
А то иногда такую кашу в Си накуралесят и удивляются почему не работает. А подойдешь, проблюёшься, тыкнешь хоткей для форматирования кода и сразу видно касяк.

[Olej]

...который почему-то по простоте душевной называют стандартной библиотекой С - нет в природе такого стандарта!) доступен и в С++ как базис...

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
Глава 7. страница 198.
Иногда лучше жевать, чем говорить.

Ну а с POSIX'ом ты лажанулся =) открой стандарты и почитай. POSIX и стандартная библиотека Си это хоть и пересекающиеся но разные множества.

Вот и я о том же, что в Linux вы работаете с библиотекой системных вызовов POSIX. И это очень важное отличие.
К какой такой "стандартной библиотеке С" вы отнесёте вызовы (основополагающие для UNIX!): fork(), signal(), ... ?

Или в Linux вы найдёте <threads.h> из того draft-стандарта, что вы показали?
В Linux вы найдёте семество типов-вызовов pthread_* - что есть часть дополнения реального времени POSIX 1003.b. А threads из "какого-то якобы стандарта библиотеки С" ... ну, нет такого, и никогда не было ... и вряд ли уже будет.

И это не "придираешься". Это очень важные отличия!
Текстуально POSIX и состав API Linux можем смотреть здесь:
http://pubs.opengroup.org/onlinepubs/9699919799/
Это стандарт по состоянию на 2008г., более позднего нет.

Пользователь решил продолжить мысль 20 Февраля 2012, 14:31:30:

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

Ваши сведения о том, что "апач там что-то похоронил", по-моему сильно преувеличены:
http://ru.wikipedia.org/wiki/Apache_Software_Foundation
- это огромное семейство проектов, да ещё и со своей собственной лицензией, а ещё им Open Ofice недавно перепал, если мне память не изменяет...

Но если серьёзно, то ARP - не менее применяемая чем boost обёртка межплатформенная, и очень широко применяемая в самых крупных из свеже-развиваемых проектов, например, практически во всём, что касается телефонных станций (PBX, SoftSwitch), такие проекты как Asterisk, FreeSWITCH - построены на ARP.

Так что и его вполне можно иметь в виду как ещё одну прослойку API для своего использования.
 

[Yurror]

fork() часть POSIX
signal() описывается как в стандартах POSIX так и Cи
открываем man и читаем раздел CONFORMING TO

Я же русским языком написал два разных пересекающихся множества
опять же sprintf тобою любимый определён только в стандарте Си но ни как не POSIX

POSIX это стандарт на API операционных систем
библиотека Си - это библиотека Си как описано
glibc всего лишь одна из реализаций стандартной библиотеки. причём весьма расширенная реализация, и, да, она включает в себя все системные вызовы. просто как удобные обёртки, которые абстрагируют пользователя от способов сделать этот сисколл на конкретной платформе.

с потоками, каюсь, зря дал ссылку на свежий черновик, но уж что нагуглилось за минуту.
pthread это обычная такая кроссплатформенная либа которая работает и на винде и на солярке и на линуксе и на маках. у каждой ОС своя реализация POSIX 1003.b с ньюансами которые скрываются libpthread
то что эписано в драфте стандарта это концепт, который потом будет реализован (или уже где-то реализован) и вполне вероятно что для реализации возьмут pthread

Какая каша у тебя в голове, боже мой. За сим завершаю данный оффтоп.
Пользователь решил продолжить мысль 20 Февраля 2012, 15:10:23:ага. с апачем не верно выразился и не на тот продукт подумал
апач забросил всего-лишь свою реализацию STL stdcxx http://stdcxx.apache.org/status/2011-02.txt
как остальное не знаю
APR поковыряю на досуге, спасибо за наводку.

[Olej]

опять же sprintf тобою любимый определён только в стандарте Си но ни как не POSIX

Ну, здрасьте вам :
http://pubs.opengroup.org/onlinepubs/9699919799/functions/sprintf.html

The Open Group Base Specifications Issue 7
IEEE Std 1003.1-2008
Copyright © 2001-2008 The IEEE and The Open Group
NAME
dprintf, fprintf, printf, snprintf, sprintf - print formatted output
SYNOPSIS
#include <stdio.h>
[CX]  int dprintf(int fildes, const char *restrict format, ...);
int fprintf(FILE *restrict stream, const char *restrict format, ...);
int printf(const char *restrict format, ...);
int snprintf(char *restrict s, size_t n,
       const char *restrict format, ...);
int sprintf(char *restrict s, const char *restrict format, ...);
...

- POSIX даёт полный перечень API с языка системного программирования в системах, которые "portable", т.е. UNIX-like ... и системных вызовов, и библиотечных (таких как strlen()) ... ну и язык системного программирования для таких систем, естественно - только C.

P.S. вот здесь совсем смешно будет:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/sqrt.html

А все остальные языки и средства - используют уже этот API как нижний транзитный уровень для своих вызовов.

Поэтому, в простейших случаях (с которого всё началось), вполне уместно, наверное, использовать тот базовый API, который предоставляется той ОС, для которой это пишется. Для Linux это - POSIX. А для Windows будет что-то совсем другое ... Win32 API, наверное, кому нравится .

P.P.S. Поэтому тема исходная, скорее, сформулирована неправильно: "Тема: преобразование числа в строку"... а должно бы быть что-то типа: "в каких формах", или "как лучше" записать преобразование из числа в строку.

Пользователь решил продолжить мысль 20 Февраля 2012, 16:44:13:

За сим завершаю данный оффтоп.

Это не есть оффтопик, иначе я бы время на буквы не терял!
Это очень частая история, когда для простейших задач начинают обсуждать "верхотурные" решения, промежуточные надстройки (boost, APR и пр.), когда этого делать не стоит.
 

[Дядюшка Ау]

Какая каша у тебя в голове, боже мой.

О, броски какашками! Подписался.