je cherche a convertir un int en string:
il y aurais t'il une autre solution ?
je cherche a convertir un int en string:
il y aurais t'il une autre solution ?
je cherche a convertir un int en string:
il y aurais t'il une autre solution ?
je cherche a convertir un int en string:
<stdlib.h>
char string[255];
itoa(1664,&string,10);
mais le compilateur me dit qu'il ne peut linker car le symbole _itoa n'existe
pas.
il y aurais t'il une autre solution ?
je cherche a convertir un int en string:
<stdlib.h>
char string[255];
itoa(1664,&string,10);
mais le compilateur me dit qu'il ne peut linker car le symbole _itoa n'existe
pas.
il y aurais t'il une autre solution ?
je cherche a convertir un int en string:
<stdlib.h>
char string[255];
itoa(1664,&string,10);
mais le compilateur me dit qu'il ne peut linker car le symbole _itoa n'existe
pas.
il y aurais t'il une autre solution ?
sebosac wrote on 30/10/04 :je cherche a convertir un int en string:
<stdlib.h>
char string[255];
itoa(1664,&string,10);
Pas standard. (Quand au '&string', je préfère ne pas en parler...)mais le compilateur me dit qu'il ne peut linker car le symbole _itoa
n'existe
pas.
C'est ce qui arrive quand on utilise des fonctions non standard dont on
a pas le source...
sebosac wrote on 30/10/04 :
je cherche a convertir un int en string:
<stdlib.h>
char string[255];
itoa(1664,&string,10);
Pas standard. (Quand au '&string', je préfère ne pas en parler...)
mais le compilateur me dit qu'il ne peut linker car le symbole _itoa
n'existe
pas.
C'est ce qui arrive quand on utilise des fonctions non standard dont on
a pas le source...
sebosac wrote on 30/10/04 :je cherche a convertir un int en string:
<stdlib.h>
char string[255];
itoa(1664,&string,10);
Pas standard. (Quand au '&string', je préfère ne pas en parler...)mais le compilateur me dit qu'il ne peut linker car le symbole _itoa
n'existe
pas.
C'est ce qui arrive quand on utilise des fonctions non standard dont on
a pas le source...
C'est bien débile de la part du comité de normalisation de ne pas avoir
standardisé itoa et ultoa alors que strtol et tous ses dérivés sont passés !
Ce manque de cohérence a pour conséquence qu'on est capable de convertir en
entier des chaines de caractères les représentant dans toutes les bases de 2 à
36, mais que dans l'autre sens on est limité à 8, 10 et 16 avec une syntaxe
(snprintf) qui n'a rien a voir et qui n'est pas sans pièges. Sans compter
l'inefficacité et la lourdeur de la méthode.
C'est bien débile de la part du comité de normalisation de ne pas avoir
standardisé itoa et ultoa alors que strtol et tous ses dérivés sont passés !
Ce manque de cohérence a pour conséquence qu'on est capable de convertir en
entier des chaines de caractères les représentant dans toutes les bases de 2 à
36, mais que dans l'autre sens on est limité à 8, 10 et 16 avec une syntaxe
(snprintf) qui n'a rien a voir et qui n'est pas sans pièges. Sans compter
l'inefficacité et la lourdeur de la méthode.
C'est bien débile de la part du comité de normalisation de ne pas avoir
standardisé itoa et ultoa alors que strtol et tous ses dérivés sont passés !
Ce manque de cohérence a pour conséquence qu'on est capable de convertir en
entier des chaines de caractères les représentant dans toutes les bases de 2 à
36, mais que dans l'autre sens on est limité à 8, 10 et 16 avec une syntaxe
(snprintf) qui n'a rien a voir et qui n'est pas sans pièges. Sans compter
l'inefficacité et la lourdeur de la méthode.
C'est bien débile de la part du comité de normalisation de ne pas avoir
standardisé itoa et ultoa alors que strtol et tous ses dérivés sont passés !
Ce manque de cohérence a pour conséquence qu'on est capable de convertir en
entier des chaines de caractères les représentant dans toutes les bases de 2
à
36, mais que dans l'autre sens on est limité à 8, 10 et 16 avec une syntaxe
(snprintf) qui n'a rien a voir et qui n'est pas sans pièges. Sans compter
l'inefficacité et la lourdeur de la méthode.
en quoi snprintf() est lourd et inefficace ?
il ne nécessite pas d'allocation mémoire, contrairement à itoa() et ses
congénères. Ce que je trouve plus efficace.
Et je ne vois pas en quoi itoa() peut-être plus efficace vu que les
opérations utilisées seront les mêmes que snprintf() à part l'allocation
mémoire initiale de itoa().
Il vaut mieux également essayer de ne pas avoir beaucoup de fonctions
qui ont une utilité identique ou bien qui recouvre l'usage de l'autre
sur un ensemble plus réduit.
C'est bien débile de la part du comité de normalisation de ne pas avoir
standardisé itoa et ultoa alors que strtol et tous ses dérivés sont passés !
Ce manque de cohérence a pour conséquence qu'on est capable de convertir en
entier des chaines de caractères les représentant dans toutes les bases de 2
à
36, mais que dans l'autre sens on est limité à 8, 10 et 16 avec une syntaxe
(snprintf) qui n'a rien a voir et qui n'est pas sans pièges. Sans compter
l'inefficacité et la lourdeur de la méthode.
en quoi snprintf() est lourd et inefficace ?
il ne nécessite pas d'allocation mémoire, contrairement à itoa() et ses
congénères. Ce que je trouve plus efficace.
Et je ne vois pas en quoi itoa() peut-être plus efficace vu que les
opérations utilisées seront les mêmes que snprintf() à part l'allocation
mémoire initiale de itoa().
Il vaut mieux également essayer de ne pas avoir beaucoup de fonctions
qui ont une utilité identique ou bien qui recouvre l'usage de l'autre
sur un ensemble plus réduit.
C'est bien débile de la part du comité de normalisation de ne pas avoir
standardisé itoa et ultoa alors que strtol et tous ses dérivés sont passés !
Ce manque de cohérence a pour conséquence qu'on est capable de convertir en
entier des chaines de caractères les représentant dans toutes les bases de 2
à
36, mais que dans l'autre sens on est limité à 8, 10 et 16 avec une syntaxe
(snprintf) qui n'a rien a voir et qui n'est pas sans pièges. Sans compter
l'inefficacité et la lourdeur de la méthode.
en quoi snprintf() est lourd et inefficace ?
il ne nécessite pas d'allocation mémoire, contrairement à itoa() et ses
congénères. Ce que je trouve plus efficace.
Et je ne vois pas en quoi itoa() peut-être plus efficace vu que les
opérations utilisées seront les mêmes que snprintf() à part l'allocation
mémoire initiale de itoa().
Il vaut mieux également essayer de ne pas avoir beaucoup de fonctions
qui ont une utilité identique ou bien qui recouvre l'usage de l'autre
sur un ensemble plus réduit.
DINH Viêt Hoà wrote in message
news:C'est bien débile de la part du comité de normalisation de ne pas
avoir standardisé itoa et ultoa alors que strtol et tous ses
dérivés sont passés ! Ce manque de cohérence
a pour conséquence qu'on est capable de convertir en entier des
chaines de caractères les représentant dans toutes les bases de
2 à 36, mais que dans l'autre sens on est limité à 8, 10 et 16
avec une syntaxe
(snprintf) qui n'a rien a voir et qui n'est pas sans pièges.
Sans compter l'inefficacité et la lourdeur de la méthode.
en quoi snprintf() est lourd et inefficace ?
Parce que passer une chaine de format à une fonction générique pour
faire une conversion simple me semble plus lourd et forcément moins
efficace.
Par exemple putc(c,fp) me semble plus efficace que fprintf(fp, "%c", c);
Ce qui est regrettable dans itoa, c'est que la taille du tableau
résultat n'est pas spécifiée dans l'appel, avec les problèmes de
débordement de tableaux que cela peut poser si le programmeur est peu
méfiant ou que la taille des types entiers change au delà de ses
attentes.
Et je ne vois pas en quoi itoa() peut-être plus efficace vu que les
opérations utilisées seront les mêmes que snprintf() à part
l'allocation mémoire initiale de itoa().
parce que snprintf finira par appeler la fonction que je me propose
d'appeler directement.
Il vaut mieux également essayer de ne pas avoir beaucoup de fonctions
qui ont une utilité identique ou bien qui recouvre l'usage de l'autre
sur un ensemble plus réduit.
C'est faux, d'abord le langage est truffé de méthodes différentes
pour faire chaque chose,
ensuite ce ne sont pas des fonctions avec
une utilité identique, mais d'une fonction simple pour un usage et
d'une fonction riche qui utilisée d'une certaine facon permet
d'obtenir un résultat (presque) identique.
Dans un programme qui fait beaucoup de conversions int->str, ou qui a
besoin de les faire très vite, on regrettera de n'avoir que
snprintf() pour ce faire.
DINH Viêt Hoà wrote in message
news:etPan.4184bf95.27373417.60d8@utopia...
C'est bien débile de la part du comité de normalisation de ne pas
avoir standardisé itoa et ultoa alors que strtol et tous ses
dérivés sont passés ! Ce manque de cohérence
a pour conséquence qu'on est capable de convertir en entier des
chaines de caractères les représentant dans toutes les bases de
2 à 36, mais que dans l'autre sens on est limité à 8, 10 et 16
avec une syntaxe
(snprintf) qui n'a rien a voir et qui n'est pas sans pièges.
Sans compter l'inefficacité et la lourdeur de la méthode.
en quoi snprintf() est lourd et inefficace ?
Parce que passer une chaine de format à une fonction générique pour
faire une conversion simple me semble plus lourd et forcément moins
efficace.
Par exemple putc(c,fp) me semble plus efficace que fprintf(fp, "%c", c);
Ce qui est regrettable dans itoa, c'est que la taille du tableau
résultat n'est pas spécifiée dans l'appel, avec les problèmes de
débordement de tableaux que cela peut poser si le programmeur est peu
méfiant ou que la taille des types entiers change au delà de ses
attentes.
Et je ne vois pas en quoi itoa() peut-être plus efficace vu que les
opérations utilisées seront les mêmes que snprintf() à part
l'allocation mémoire initiale de itoa().
parce que snprintf finira par appeler la fonction que je me propose
d'appeler directement.
Il vaut mieux également essayer de ne pas avoir beaucoup de fonctions
qui ont une utilité identique ou bien qui recouvre l'usage de l'autre
sur un ensemble plus réduit.
C'est faux, d'abord le langage est truffé de méthodes différentes
pour faire chaque chose,
ensuite ce ne sont pas des fonctions avec
une utilité identique, mais d'une fonction simple pour un usage et
d'une fonction riche qui utilisée d'une certaine facon permet
d'obtenir un résultat (presque) identique.
Dans un programme qui fait beaucoup de conversions int->str, ou qui a
besoin de les faire très vite, on regrettera de n'avoir que
snprintf() pour ce faire.
DINH Viêt Hoà wrote in message
news:C'est bien débile de la part du comité de normalisation de ne pas
avoir standardisé itoa et ultoa alors que strtol et tous ses
dérivés sont passés ! Ce manque de cohérence
a pour conséquence qu'on est capable de convertir en entier des
chaines de caractères les représentant dans toutes les bases de
2 à 36, mais que dans l'autre sens on est limité à 8, 10 et 16
avec une syntaxe
(snprintf) qui n'a rien a voir et qui n'est pas sans pièges.
Sans compter l'inefficacité et la lourdeur de la méthode.
en quoi snprintf() est lourd et inefficace ?
Parce que passer une chaine de format à une fonction générique pour
faire une conversion simple me semble plus lourd et forcément moins
efficace.
Par exemple putc(c,fp) me semble plus efficace que fprintf(fp, "%c", c);
Ce qui est regrettable dans itoa, c'est que la taille du tableau
résultat n'est pas spécifiée dans l'appel, avec les problèmes de
débordement de tableaux que cela peut poser si le programmeur est peu
méfiant ou que la taille des types entiers change au delà de ses
attentes.
Et je ne vois pas en quoi itoa() peut-être plus efficace vu que les
opérations utilisées seront les mêmes que snprintf() à part
l'allocation mémoire initiale de itoa().
parce que snprintf finira par appeler la fonction que je me propose
d'appeler directement.
Il vaut mieux également essayer de ne pas avoir beaucoup de fonctions
qui ont une utilité identique ou bien qui recouvre l'usage de l'autre
sur un ensemble plus réduit.
C'est faux, d'abord le langage est truffé de méthodes différentes
pour faire chaque chose,
ensuite ce ne sont pas des fonctions avec
une utilité identique, mais d'une fonction simple pour un usage et
d'une fonction riche qui utilisée d'une certaine facon permet
d'obtenir un résultat (presque) identique.
Dans un programme qui fait beaucoup de conversions int->str, ou qui a
besoin de les faire très vite, on regrettera de n'avoir que
snprintf() pour ce faire.
"Antoine Leca" writes:Sans blague, tu ne crois pas que l'histoire de « toutes les bases »
c'est du sucre qui a été mis là parce que cela ne coutait rien, mais
qui ne sert à personne dans la réalité ?
On voit que tu ne parses pas du PostScript ;-)
"Antoine Leca" <root@localhost.gov> writes:
Sans blague, tu ne crois pas que l'histoire de « toutes les bases »
c'est du sucre qui a été mis là parce que cela ne coutait rien, mais
qui ne sert à personne dans la réalité ?
On voit que tu ne parses pas du PostScript ;-)
"Antoine Leca" writes:Sans blague, tu ne crois pas que l'histoire de « toutes les bases »
c'est du sucre qui a été mis là parce que cela ne coutait rien, mais
qui ne sert à personne dans la réalité ?
On voit que tu ne parses pas du PostScript ;-)
"Antoine Leca" writes:
| >>> a pour conséquence qu'on est capable de convertir en entier des
| >>> chaines de caractères les représentant dans toutes les bases de
| >>> 2 à 36, mais que dans l'autre sens on est limité à 8, 10 et 16
|
| Sans blague, tu ne crois pas que l'histoire de « toutes les bases » c'est du
| sucre qui a été mis là parce que cela ne coutait rien, mais qui ne sert à
| personne dans la réalité ?
On voit que tu ne parses pas du PostScript ;-)
"Antoine Leca" <root@localhost.gov> writes:
| >>> a pour conséquence qu'on est capable de convertir en entier des
| >>> chaines de caractères les représentant dans toutes les bases de
| >>> 2 à 36, mais que dans l'autre sens on est limité à 8, 10 et 16
|
| Sans blague, tu ne crois pas que l'histoire de « toutes les bases » c'est du
| sucre qui a été mis là parce que cela ne coutait rien, mais qui ne sert à
| personne dans la réalité ?
On voit que tu ne parses pas du PostScript ;-)
"Antoine Leca" writes:
| >>> a pour conséquence qu'on est capable de convertir en entier des
| >>> chaines de caractères les représentant dans toutes les bases de
| >>> 2 à 36, mais que dans l'autre sens on est limité à 8, 10 et 16
|
| Sans blague, tu ne crois pas que l'histoire de « toutes les bases » c'est du
| sucre qui a été mis là parce que cela ne coutait rien, mais qui ne sert à
| personne dans la réalité ?
On voit que tu ne parses pas du PostScript ;-)
A ce propos, je me souviens avoir optimisé en 1991 à Cambridge le
driver Postscript de Lotus 1-2-3.
plus de 90% du temps passé était concentré dans une seule routine qui
convertissait en chaines de caractères en base 10 des nombres entiers
pour la plupart constants.
Convertir les nombres en chaines est une opération courante, c'est
dommage que les outils pour le faire soient si tordus.
A ce propos, je me souviens avoir optimisé en 1991 à Cambridge le
driver Postscript de Lotus 1-2-3.
plus de 90% du temps passé était concentré dans une seule routine qui
convertissait en chaines de caractères en base 10 des nombres entiers
pour la plupart constants.
Convertir les nombres en chaines est une opération courante, c'est
dommage que les outils pour le faire soient si tordus.
A ce propos, je me souviens avoir optimisé en 1991 à Cambridge le
driver Postscript de Lotus 1-2-3.
plus de 90% du temps passé était concentré dans une seule routine qui
convertissait en chaines de caractères en base 10 des nombres entiers
pour la plupart constants.
Convertir les nombres en chaines est une opération courante, c'est
dommage que les outils pour le faire soient si tordus.