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
Fabien LE LEZ
On Fri, 5 Aug 2005 11:30:53 +0200, "Clément" :
char * buf = new char [n];
Déjà, mauvais réflexe ici. Si tu as besoin d'un char* pour une raison quelconque (ça arrive souvent quand on travaille avec des bibliothèques prévues pour le C), il est généralement plus facile d'utiliser std::vector<> :
Déjà, mauvais réflexe ici.
Si tu as besoin d'un char* pour une raison quelconque (ça arrive
souvent quand on travaille avec des bibliothèques prévues pour le C),
il est généralement plus facile d'utiliser std::vector<> :
Déjà, mauvais réflexe ici. Si tu as besoin d'un char* pour une raison quelconque (ça arrive souvent quand on travaille avec des bibliothèques prévues pour le C), il est généralement plus facile d'utiliser std::vector<> :
Déjà, mauvais réflexe ici. Si tu as besoin d'un char* pour une raison quelconque (ça arrive souvent quand on travaille avec des bibliothèques prévues pour le C), il est généralement plus facile d'utiliser std::vector<> :
OK merci du conseil... Je ne savais pas qu'on était sûr que les éléments d'un vector se suivaient en mémoire...
Déjà, mauvais réflexe ici.
Si tu as besoin d'un char* pour une raison quelconque (ça arrive
souvent quand on travaille avec des bibliothèques prévues pour le C),
il est généralement plus facile d'utiliser std::vector<> :
Déjà, mauvais réflexe ici. Si tu as besoin d'un char* pour une raison quelconque (ça arrive souvent quand on travaille avec des bibliothèques prévues pour le C), il est généralement plus facile d'utiliser std::vector<> :
OK merci du conseil... Je ne savais pas qu'on était sûr que les éléments d'un vector se suivaient en mémoire...
Fabien LE LEZ
On Fri, 5 Aug 2005 12:02:17 +0200, "Clément" :
Je ne savais pas qu'on était sûr que les éléments d'un vector se suivaient en mémoire...
Pendant longtemps, c'était vrai en pratique, parce qu'on ne connaissait aucun autre moyen sérieux d'implémenter la norme. Depuis peu, c'est explicite dans la norme C++.
On Fri, 5 Aug 2005 12:02:17 +0200, "Clément"
<clement@xxx.xxx.invalid>:
Je ne savais pas qu'on était sûr que les éléments
d'un vector se suivaient en mémoire...
Pendant longtemps, c'était vrai en pratique, parce qu'on ne
connaissait aucun autre moyen sérieux d'implémenter la norme.
Depuis peu, c'est explicite dans la norme C++.
Je ne savais pas qu'on était sûr que les éléments d'un vector se suivaient en mémoire...
Pendant longtemps, c'était vrai en pratique, parce qu'on ne connaissait aucun autre moyen sérieux d'implémenter la norme. Depuis peu, c'est explicite dans la norme C++.
Clément
"Fabien LE LEZ" a écrit dans le message de news:
On Fri, 5 Aug 2005 12:02:17 +0200, "Clément" :
Je ne savais pas qu'on était sûr que les éléments d'un vector se suivaient en mémoire...
Pendant longtemps, c'était vrai en pratique, parce qu'on ne connaissait aucun autre moyen sérieux d'implémenter la norme. Depuis peu, c'est explicite dans la norme C++.
OK, mais est-ce vraiment respecté dans la plupart des compilos (genre VC++
2003) ? Et puis, si je comprends bien, on n'a presque plus à utiliser "new", à part pour le polymorphisme (ce qui est déjà bcp, tu me diras)...
Et sinon, pour ma question, y'a pas d'autre moyen que de passer par un vector ? Les "char" ne sont pas sensés se succéder en mémoire, pour une "string" ? Parce que si c'est le cas, je passe &str[0]...
"Fabien LE LEZ" <gramster@gramster.com> a écrit dans le message de news:
3ji6f1l94evrbuaqibsga983lhpv2qlsjh@4ax.com...
On Fri, 5 Aug 2005 12:02:17 +0200, "Clément"
<clement@xxx.xxx.invalid>:
Je ne savais pas qu'on était sûr que les éléments
d'un vector se suivaient en mémoire...
Pendant longtemps, c'était vrai en pratique, parce qu'on ne
connaissait aucun autre moyen sérieux d'implémenter la norme.
Depuis peu, c'est explicite dans la norme C++.
OK, mais est-ce vraiment respecté dans la plupart des compilos (genre VC++
2003) ?
Et puis, si je comprends bien, on n'a presque plus à utiliser "new", à part
pour le polymorphisme (ce qui est déjà bcp, tu me diras)...
Et sinon, pour ma question, y'a pas d'autre moyen que de passer par un
vector ? Les "char" ne sont pas sensés se succéder en mémoire, pour une
"string" ? Parce que si c'est le cas, je passe &str[0]...
Je ne savais pas qu'on était sûr que les éléments d'un vector se suivaient en mémoire...
Pendant longtemps, c'était vrai en pratique, parce qu'on ne connaissait aucun autre moyen sérieux d'implémenter la norme. Depuis peu, c'est explicite dans la norme C++.
OK, mais est-ce vraiment respecté dans la plupart des compilos (genre VC++
2003) ? Et puis, si je comprends bien, on n'a presque plus à utiliser "new", à part pour le polymorphisme (ce qui est déjà bcp, tu me diras)...
Et sinon, pour ma question, y'a pas d'autre moyen que de passer par un vector ? Les "char" ne sont pas sensés se succéder en mémoire, pour une "string" ? Parce que si c'est le cas, je passe &str[0]...
Michel Michaud
Dans le message 42f35e31$0$15053$,
"Fabien LE LEZ" a écrit dans le message de news:
On Fri, 5 Aug 2005 12:02:17 +0200, "Clément" :
Je ne savais pas qu'on était sûr que les éléments d'un vector se suivaient en mémoire...
Pendant longtemps, c'était vrai en pratique, parce qu'on ne connaissait aucun autre moyen sérieux d'implémenter la norme. Depuis peu, c'est explicite dans la norme C++.
OK, mais est-ce vraiment respecté dans la plupart des compilos
(genre VC++ 2003) ?
C'était respecté partout quand on l'a rendu officielle. En fait, il semble que c'était évidemment ce qu'on pensait et que c'est pourquoi on avait oublié de l'écrire explicitement dans la norme.
Et puis, si je comprends bien, on n'a presque plus à utiliser "new", à part pour le polymorphisme (ce qui est déjà bcp, tu me diras)...
Presque. On a besoin de new si l'on veut contrôler la durée de vie des objets explicitement (c'est rare, mais ça arrive).
Et sinon, pour ma question, y'a pas d'autre moyen que de passer par un vector ? Les "char" ne sont pas sensés se succéder en mémoire, pour une "string" ? Parce que si c'est le cas, je passe &str[0]...
Non, là, c'est exprès que ce n'est pas obligatoire.
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans le message 42f35e31$0$15053$626a14ce@news.free.fr,
"Fabien LE LEZ" <gramster@gramster.com> a écrit dans le message de
news: 3ji6f1l94evrbuaqibsga983lhpv2qlsjh@4ax.com...
On Fri, 5 Aug 2005 12:02:17 +0200, "Clément"
<clement@xxx.xxx.invalid>:
Je ne savais pas qu'on était sûr que les éléments
d'un vector se suivaient en mémoire...
Pendant longtemps, c'était vrai en pratique, parce qu'on ne
connaissait aucun autre moyen sérieux d'implémenter la norme.
Depuis peu, c'est explicite dans la norme C++.
OK, mais est-ce vraiment respecté dans la plupart des compilos
(genre VC++ 2003) ?
C'était respecté partout quand on l'a rendu officielle. En fait,
il semble que c'était évidemment ce qu'on pensait et que c'est
pourquoi on avait oublié de l'écrire explicitement dans la norme.
Et puis, si je comprends bien, on n'a presque plus à utiliser
"new", à part pour le polymorphisme (ce qui est déjà bcp, tu me
diras)...
Presque. On a besoin de new si l'on veut contrôler la durée de vie
des objets explicitement (c'est rare, mais ça arrive).
Et sinon, pour ma question, y'a pas d'autre moyen que de passer par
un vector ? Les "char" ne sont pas sensés se succéder en mémoire,
pour une "string" ? Parce que si c'est le cas, je passe &str[0]...
Non, là, c'est exprès que ce n'est pas obligatoire.
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Je ne savais pas qu'on était sûr que les éléments d'un vector se suivaient en mémoire...
Pendant longtemps, c'était vrai en pratique, parce qu'on ne connaissait aucun autre moyen sérieux d'implémenter la norme. Depuis peu, c'est explicite dans la norme C++.
OK, mais est-ce vraiment respecté dans la plupart des compilos
(genre VC++ 2003) ?
C'était respecté partout quand on l'a rendu officielle. En fait, il semble que c'était évidemment ce qu'on pensait et que c'est pourquoi on avait oublié de l'écrire explicitement dans la norme.
Et puis, si je comprends bien, on n'a presque plus à utiliser "new", à part pour le polymorphisme (ce qui est déjà bcp, tu me diras)...
Presque. On a besoin de new si l'on veut contrôler la durée de vie des objets explicitement (c'est rare, mais ça arrive).
Et sinon, pour ma question, y'a pas d'autre moyen que de passer par un vector ? Les "char" ne sont pas sensés se succéder en mémoire, pour une "string" ? Parce que si c'est le cas, je passe &str[0]...
Non, là, c'est exprès que ce n'est pas obligatoire.
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Falk Tannhäuser
Clément wrote:
Je voudrais lire n (connu) caractères depuis un istream et mettre tout ça dans une string. J'ai bien pensé à faire un truc comme ca :
En supposant que "ifs" est un std::istream et "str" un std::string : ifs >> std::setw(n) >> str;
Cela lira tout au plus n caractères, mais la lecture s'arrête à la fin du fichier ou à une espace (cf. § 21.3.7.9/1). Si tu n'as pas d'espaces dans les chaînes à lire, cela devrait faire ce que tu veux. Sinon je ne vois rien de mieux que ce qui a déjà été proposé.
Falk
Clément wrote:
Je voudrais lire n (connu) caractères depuis un istream et mettre tout ça
dans une string. J'ai bien pensé à faire un truc comme ca :
En supposant que "ifs" est un std::istream et "str" un std::string :
ifs >> std::setw(n) >> str;
Cela lira tout au plus n caractères, mais la lecture s'arrête à la fin
du fichier ou à une espace (cf. § 21.3.7.9/1). Si tu n'as pas d'espaces
dans les chaînes à lire, cela devrait faire ce que tu veux. Sinon je ne
vois rien de mieux que ce qui a déjà été proposé.
Je voudrais lire n (connu) caractères depuis un istream et mettre tout ça dans une string. J'ai bien pensé à faire un truc comme ca :
En supposant que "ifs" est un std::istream et "str" un std::string : ifs >> std::setw(n) >> str;
Cela lira tout au plus n caractères, mais la lecture s'arrête à la fin du fichier ou à une espace (cf. § 21.3.7.9/1). Si tu n'as pas d'espaces dans les chaînes à lire, cela devrait faire ce que tu veux. Sinon je ne vois rien de mieux que ce qui a déjà été proposé.
