Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Langage C conversion int vers string

conversion int vers string

47 réponses
Avatar
sebosac
salut,

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 ?

merci
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2 3 4 5
Avatar
Gabriel Dos Reis
Emmanuel Delahaye writes:

| Gabriel Dos Reis wrote on 11/11/04 :
| > James Kanze writes:
| >
| >> Gabriel Dos Reis writes:
| >>
| >>>> "Charlie Gordon" writes: [...]
| >>
| >>>> | > En ce qui concerne le itoa() classique (issu de MS-DOS je
| >>>> | > pense), cet équivalent simple n'existe pas, ou plutôt on en
| >>>> | > revient à sprintf() et un calcul de la longueur de la chaîne en
| >>>> | > fonction des propriétés des types entiers; et quand tu en es là,
| >>>> | > utiliser sprintf ou autre chose devient anecdotique, sans parler
| >>>> | > de la lourdeur.
| >>
| >>>> | Je ne crois pas que cet argument tienne : le fait qu'il existait
| >>>> | déjà à l'époque une alternative correcte à gets(), en l'occurrence
| >>>> | fgets() est la raison qui aurait dû conduire à exclure gets() de
| >>>> | la norme ANSI.
| >>
| >>>> Je crois que tu fais l'erreur colossale de croire que la norme était
| >>>> écrite pour ne contenir que des choses « non bugguées ». Certains
| >>>> aiment à dire que la charte du comité ANSI était de codifier la
| >>>> partique existante, alors ... -- mais, en réalité c'est pas vrai, le
| >>>> comité a fait mal d'inventions, y compris l'infame void* -> T* et
| >>>> volatile.
| >> La réalité est un peu plus complexe que ça, et codifier la pratique
| >> existante faisait bien partie du cahier de charge. Mais c'est vrai que
| >> dans le langage même, ils ont introduit un certain nombre d'innovations
| >> dans le sens de plus de rigueur et de vérifications de côté du
| >> compilateur.
| >
| > Comme la conversion void* -> T* ?
| > Ou comme l'introduction de « volatile » avec la sémantique qu'un objet
| > déclaré avec un type volatile pourrait voir sa valeur modifiée de
| > manière inconnue au compilateur ou pourrait avoir d'autres
| > « side effects » inconnus ? C'est vachement plus de vérification
| > et de rigeur ça.
|
| Si j'ai bien compris, le but de 'volatile' n'est pas d'introduire de
| la rigueur, mais plutôt d'interdire quelques optimisations aggressives
| genre

Est-ce que tu as lu la spécification de « volatile » ?

[#6] An object that has volatile-qualified type may be
modified in ways unknown to the implementation or have other
unknown side effects. Therefore any expression referring to
^^^^^^^^^^^^^^^^^^^^
such an object shall be evaluated strictly according to the
rules of the abstract machine, as described in 5.1.2.3.
Furthermore, at every sequence point the value last stored
in the object shall agree with that prescribed by the
abstract machine, except as modified by the unknown factors
mentioned previously.114) What constitutes an access to an
object that has volatile-qualified type is implementation-
defined.

Puisqu'un objet volatile peut avoir des « unknown side effects », on
ne peut même pas savoir si le programme fait ce pourquoi il est conçu.

|
| {
| int x = 100;
|
| while (x)
| {
| x--;
| }
| }
|
| Ce code ne fait rien à part perdre du temps (pas de 'side-effect'),
| donc, je (compilateur) le vire...

La sémantique d'un programme C est décrite en terme de fonctionnement
observable. Est-ce que tu peux dire la différence si le compilateur
vire cette stupidité et le remplace par un sleep(47349304425) ? Ou si
le compilateur le garde mais active le turbo réacteur pour que ça
aille plus vite ?

| Je ne dis pas que c'est la meilleure façon de faire une tempo, mais

C'est just eune stupidité.

| c'est parfois la seule possible dans les phases d'init d'une
| application embarquée (avant que le système ne soit lancé
| complètement) ...

Pouf, ici, celui qui écrit ça en embarqué est viré pour faute
professionelle grave.

| {
| int volatile x = 100;
|
| while (x)
| {
| x--;
| }
| }
|
| ne sera pas optimisé.

Non, on ne sait pas ce qu'il fait : il peut avoir des « unknowns side
effects », par exemple établir une commnication avec l'Alpha du
Centaure.

-- Gaby
Avatar
Emmanuel Delahaye
Gabriel Dos Reis wrote on 11/11/04 :
Je ne dis pas que c'est la meilleure façon de faire une tempo, mais


C'est juste une stupidité.


On a pas besoin de tes commentaires. Contente toi de parler de
technique.

c'est parfois la seule possible dans les phases d'init d'une
application embarquée (avant que le système ne soit lancé
complètement) ...


Pouf, ici, celui qui écrit ça en embarqué est viré pour faute
professionelle grave.


Au lieu de dire des bêtises gratuites, investit toi un peu plus[1]
{
int volatile x = 100;

while (x)
{
x--;
}
}

ne sera pas optimisé.


Non, on ne sait pas ce qu'il fait : il peut avoir des « unknowns side
effects », par exemple établir une commnication avec l'Alpha du
Centaure.


- Explique en quoi le comportment est indéfini.(Je pense plutôt qu'il
dépend de l'implémentation)
- Propose une meilleure solution dans le cadre décrit.

------------
[1] à moins que tu ne soit là que pour faire le guignol. Je te rappelle
que l'un des buts des newsgroup est de partager la connaissance, pas de
faire des attaques personnelles...

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"C is a sharp tool"


Avatar
James Kanze
Gabriel Dos Reis writes:

|> James Kanze writes:

|> | Gabriel Dos Reis writes:

|> | |> "Charlie Gordon" writes:

|> | |> [...]

|> | |> | > En ce qui concerne le itoa() classique (issu de MS-DOS je
|> | |> | > pense), cet équivalent simple n'existe pas, ou plutôt on
|> | |> | > en revient à sprintf() et un calcul de la longueur de la
|> | |> | > chaîne en fonction des propriétés des types entiers; et
|> | |> | > quand tu en es là, utiliser sprintf ou autre chose devient
|> | |> | > anecdotique, sans parler de la lourdeur.

|> | |> | Je ne crois pas que cet argument tienne : le fait qu'il
|> | |> | existait déjà à l'époque une alternative correcte à gets(),
|> | |> | en l'occurrence fgets() est la raison qui aurait dû conduire
|> | |> | à exclure gets() de la norme ANSI.

|> | |> Je crois que tu fais l'erreur colossale de croire que la norme
|> | |> était écrite pour ne contenir que des choses « non bugguées ».
|> | |> Certains aiment à dire que la charte du comité ANSI était de
|> | |> codifier la partique existante, alors ... -- mais, en réalité
|> | |> c'est pas vrai, le comité a fait mal d'inventions, y compris
|> | |> l'infame void* -> T* et volatile.

|> | La réalité est un peu plus complexe que ça, et codifier la
|> | pratique existante faisait bien partie du cahier de charge. Mais
|> | c'est vrai que dans le langage même, ils ont introduit un certain
|> | nombre d'innovations dans le sens de plus de rigueur et de
|> | vérifications de côté du compilateur.

|> Comme la conversion void* -> T* ?

Limiter la conversion aux cas où il y a un void* d'un côté, c'est
toujours mieux de ce qu'il y avait avant, ou T1* -> T2* marchait, pour
tous T1 et T2.

|> Ou comme l'introduction de « volatile » avec la sémantique qu'un
|> objet déclaré avec un type volatile pourrait voir sa valeur modifiée
|> de manière inconnue au compilateur ou pourrait avoir d'autres « side
|> effects » inconnus ? C'est vachement plus de vérification et de
|> rigeur ça.

Je ne sais pas. Je n'ai pas vu d'autres alternatifs. Dans la pratique,
volatile m'a été assez utile dans les cas qui correspondaient à son
utilisation voulue.

|> | Les prototypes de fonctions, par exemple. Ou ne permettre

|> Tu veux parler de « l'abomination » « f(void) » ?

Le problème, toujours, c'est d'implémenter un cahier de charges où il y
a des exigeances contradictoire. Idéalement, on aurait exigé des
prototypes, comme en C++. Seulement, il y avait pas mal de code
existant, qui lui utilisait des declarations K&R. Et le cahier de charge
spécifiait bien qu'il ne fallait pas le casser. Du coup, il fallait
absolument que f() signifie une declaration K&R.

En fait, « l'abomination », c'était bien le langage du départ. Le comité
en a fait ce qu'il pouvait, mais comme on dit en anglais : « you can't
make a silk purse out of a sow's ear. »

|> | les conversions de pointeur que dans le cas où un des pointeur
|> | était void* (parce que la *pratique* existante à l'époque,
|> | quoiqu'on dise certaines références, était de convertir
|> | implicitement entre tout type

|> certaines références étant K+R-1.

Je sais. Mais entre Kernighan et Richie voulait pour leur langage, et ce
qu'il est (et était même alors) devenu, il y a parfois une différence.

--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Avatar
Gabriel Dos Reis
Emmanuel Delahaye writes:

| Gabriel Dos Reis wrote on 11/11/04 :
| >> Je ne dis pas que c'est la meilleure façon de faire une tempo, mais
| >
| > C'est juste une stupidité.
|
| On a pas besoin de tes commentaires. Contente toi de parler de
| technique.

Avec toi, parler technique ne suffit pas puisque tu ne les vois pas
(hint : tu as viré la sémantique que « volatile »).

| >> c'est parfois la seule possible dans les phases d'init d'une
| >> application embarquée (avant que le système ne soit lancé
| >> complètement) ...
| >
| > Pouf, ici, celui qui écrit ça en embarqué est viré pour faute
| > professionelle grave.
|
| Au lieu de dire des bêtises gratuites, investit toi un peu plus[1]

Y a-t-il un bénéfice à tiré d'un âne comme toi ?

| >> {
| >> int volatile x = 100;
| >> while (x)
| >> {
| >> x--;
| >> }
| >> }
| >> ne sera pas optimisé.
| >
| > Non, on ne sait pas ce qu'il fait : il peut avoir des « unknowns side
| > effects », par exemple établir une commnication avec l'Alpha du
| > Centaure.
|
| - Explique en quoi le comportment est indéfini.(Je pense plutôt qu'il
| dépend de l'implémentation)

Est-c que j'ai dit que le comportement est indéfini ? T'as besoin de
cours d'alphabétisation ?

| - Propose une meilleure solution dans le cadre décrit.

Ne pas l'écrire.

| ------------
| [1] à moins que tu ne soit là que pour faire le guignol. Je te
| rappelle que l'un des buts des newsgroup est de partager la
| connaissance, pas de faire des attaques personnelles...

Tu devrais relire ceci avant de poster un message la prochaine fois.

-- Gaby
Avatar
Gabriel Dos Reis
James Kanze writes:


[...]

| En fait, « l'abomination », c'était bien le langage du départ. Le comité

« abomination » est le qualificatif utilisé par Dennis Ritchie pour
caractériser « f(void) ».

| en a fait ce qu'il pouvait,

Oui, il avait inventé pire, je n'en doute pas. Noalias. No comment.

-- Gaby
Avatar
drkm
Emmanuel Delahaye writes:

Gabriel Dos Reis wrote on 11/11/04 :

Je ne dis pas que c'est la meilleure façon de faire une tempo, mais


C'est juste une stupidité.


On a pas besoin de tes commentaires. Contente toi de parler de
technique.


Ce n'est pas le cas ?

Au lieu de dire des bêtises gratuites, investit toi un peu plus[1]


Ahem.

Non, on ne sait pas ce qu'il fait : il peut avoir des « unknowns side
effects », par exemple établir une commnication avec l'Alpha du
Centaure.



C'est peut-être une piste de recherche intéressante :-).

- Explique en quoi le comportment est indéfini.(Je pense plutôt qu'il
dépend de l'implémentation)


Ben la réponse est dans la phrase à laquelle tu réponds, non ?

--drkm



Avatar
cedric
Gabriel Dos Reis wrote:
Non, on ne sait pas ce qu'il fait : il peut avoir des « unknowns side
effects », par exemple établir une commnication avec l'Alpha du
Centaure.


Le compilateur ne sait pas ce qu'il fait, craint qu'il entre en
communication avec alpha du centaure, et donc, ne sachant pas comment
optimiser cette communication potentielle, s'en tiens à ce que le
programmeur, qui lui sait ce qui se passe, à écrit dans son source.

Faut arreter la coke.

Avatar
Charlie Gordon
En fait, « l'abomination », c'était bien le langage du départ. Le comité
en a fait ce qu'il pouvait, mais comme on dit en anglais : « you can't
make a silk purse out of a sow's ear. »


En français, dommage que la différence entre soie et soies soit en soi assez
subtile ;-)

Chqrlie.

Avatar
drkm
James Kanze writes:

Gabriel Dos Reis writes:

|> Ou comme l'introduction de « volatile » avec la sémantique qu'un
|> objet déclaré avec un type volatile pourrait voir sa valeur modifiée
|> de manière inconnue au compilateur ou pourrait avoir d'autres « side
|> effects » inconnus ? C'est vachement plus de vérification et de
|> rigeur ça.

Je ne sais pas. Je n'ai pas vu d'autres alternatifs. Dans la pratique,
volatile m'a été assez utile dans les cas qui correspondaient à son
utilisation voulue.


Il y a eu dans le DDJ (en deux parties, juillet et août 2004, je
pense) un article de Meyers et Alexandrescu sur C++ et le
Double-Checked Locking Pattern. Je ne l'ai pas sous la main, mais il
parlait notamment de volatile et de son inutilisabilité. Je ne me
souviens pas des détails, mais il ne m'a pas semblé que ces problèmes
étaient spécifiques au C++.

Il me semble que la conclusion était qu'il n'était d'aucune utilité
dans ce cas. Voire en général. Je rappelle que je ne me souviens pas
des détails, mais je peux retrouver l'article, si nécessaire.

Je n'ai jamais très bien cerné les garanties que donne la norme à
propos de volatile, et donc de ses utilisations possibles. Qu'en
est-il réellement ?

--drkm

Avatar
drkm
cedric writes:

Gabriel Dos Reis wrote:

Non, on ne sait pas ce qu'il fait : il peut avoir des « unknowns side
effects », par exemple établir une commnication avec l'Alpha du
Centaure.


Le compilateur ne sait pas ce qu'il fait, craint qu'il entre en
communication avec alpha du centaure, et donc, ne sachant pas comment
optimiser cette communication potentielle, s'en tiens à ce que le
programmeur, qui lui sait ce qui se passe, à écrit dans son source.


Je ne pense pas que Gaby dise que le compilo ne s'en tient pas à ce
que le programmeur a écrit dans son source.

D'après le passage qu'il a cité :

[#6] An object that has volatile-qualified type may be
modified in ways unknown to the implementation or have other
unknown side effects.
^^^^^^^^^^^^^^^^^^^^

ça me semble cohérent (mais pas nécessairement simple) d'entrer en
contact avec l'office du tourisme d'Alpha du Centaure.

Faut arreter la coke.


Bof.

--drkm


1 2 3 4 5