L'enfer de la STL

Le
Alain Ketterlin
Salut,

J'utilise pas mal la STL, avec des combinaisons du genre :

map < pair<Truc*,Truc*> , set<Truc*> > m;

(pour la plus simple). Pour diverses raisons, j'essaie d'éviter les
typedef. Donc je me retrouve avec des boucles comme :

for ( map < pair<Truc*,Truc*> , set<Truc*> >::iterator it=m.begin() ;
it!=m.end() ; it++ )
{ }

D'où mes deux questions :

1) y a-t-il plus court ? (Hors for_each, qui ne m'intéresse pas parce
que mes corps de boucle sont éventuellement longs, et je n'ai pas
envie de les rejeter chacun dans une classe.)

2) Quelqu'un a-t-il des informations sur la standardisation
(éventuelle) et l'implémentation de "auto" dans g++ ? Je n'ai rien
trouvé de précis. Quand pourrais-je écrire
for ( auto it=m.begin() ; it!=m.end() ; it++ )


Question subsidiaire : en essayant d'écrire une macro pour remplacer
la tête de boucle ci-dessus, j'ai remarqué que le préprocesseur ne
connait rien aux templates. Si j'écris

#define FOREACH(T,c,v) for ( T :: iterator v=c.begin() )

alors il couine sur

FOREACH(pair<Truc1,Truc2>,m,it)

parce qu'il ne comprend pas que la première virgule est entre < et >.
Savez-vous si il est prévu que ça change ?

Merci d'avance. J'espère avoir raté quelque chose d'évident.

-- Alain.
Vos réponses Page 3 / 3
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Mickaël Wolff
Le #17777511
Olivier Miakinen a écrit :

Une documentation existante d'une fonction absente ?



Ah tiens, je la connaissait pas celle-là. Ça m'apprendra. Je pensais
plutôt à une documentation erronée ou périmée.

--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org
Alain Ketterlin
Le #17797881
Fabien LE LEZ
On Fri, 07 Nov 2008 12:45:56 +0100, Alain Ketterlin

map < pair<Truc*,Truc*> , set<Truc*> > data;






Mais je ne peux pas écrire c1 = c2 (avec deux instances de C) sans
risque.



Pourquoi ?
Si tu utilises des pointeurs nus, j'imagine qu'ils référencent des
objets (de classe Truc) qui existe par ailleurs ?



Stop. Ce n'est pas vrai dans le contexte de ces posts. Tu coupes trop
pour qu'on comprenne. Je rappelle ce que tu proposais :

| Si les constructeur et opérateur de copie du type
| map < pair<Truc*,Truc*> , set<Truc*> >
| te conviennent, alors ceux de
|
| class C
| { ...
| private:
| map < pair<Truc*,Truc*> , set<Truc*> > data;
| };
|
| devraient te convenir aussi.

Si tu fais cela, et que tu as deux objets, déclarés par :

C c1;
C c2;

et que tu écris :

c1 = c2;

tu auras des soucis si C ne définit pas d'operator=. Dans la ligne
précédente, l'opérator= de map indépendant de ce qui est dans la map). Tu sembles dire que si.

(Je disais simplement : si on définit une nouvelle classe, il faut la
munir de copy-ctor et d'operator=. C'était un inconvénient mineur,
mais ça n'en reste pas moins une obligation, même si le compilo ne
l'exige pas.)

-- Alain.
pjb
Le #17798281
Mickaël Wolff
Pascal J. Bourguignon a écrit :

D'où l'intérêt d'un langage comme Common Lisp qui permet de définir
facilement des nouvelles syntaxes.



Tu commences à me gonfler. Si LISP est un langage si parfait,
ignores le C++ et arrêter de nous les briser. Certainement que LISP a
des qualités, mais c'est pas avec ce genre d'interventions pénibles
que tu vas attirer du monde dans ta chapelle.

Fin de la parenthèse ? :D



Si tu n'as pas de problème qui demande des solutions innexistantes ou
pénibles en C++, alors sois heureux.


Mais on constate régulièrement des questions posées sur les groupes
C++ qui ne se poseraient pas ou qui aurait une solution trivial dans
un autre langage: pour ces personnes, le problème vient du langage C++.



Je ne vois pas ce qu'il y a de pénible à mentionner en passant qu'il y
a une solution triviale de l'autre côté du mirroir.

On n'est pas là pour ce masturber avec le C++ et ses idiosyncrasies,
mais pour résoudre des problèmes qui vont au delà du langage.

--
__Pascal Bourguignon__
Serge Paccalin
Le #17798271
Le lundi 10 novembre 2008 à 10:59:15, Pascal J. Bourguignon a écrit dans
fr.comp.lang.c++ :

On n'est pas là pour ce masturber avec le C++ et ses idiosyncrasies,



Ben si, c'est très exactement l'objet de ce forum...

--
___________
_/ _ _`_`_`_) Serge PACCALIN -- sp ad mailclub.net
_L_) Il faut donc que les hommes commencent
-'(__) par n'être pas fanatiques pour mériter
_/___(_) la tolérance. -- Voltaire, 1763
Serge Paccalin
Le #17798421
Le lundi 10 novembre 2008 à 10:59:15, Pascal J. Bourguignon a écrit dans
fr.comp.lang.c++ :

On n'est pas là pour ce masturber avec le C++ et ses idiosyncrasies,



Ben si, c'est très exactement l'objet de ce forum...

mais pour résoudre des problèmes qui vont au delà du langage.



Si tu cherches fr.comp.developpement, tu sais où le trouver.

--
___________
_/ _ _`_`_`_) Serge PACCALIN -- sp ad mailclub.net
_L_) Il faut donc que les hommes commencent
-'(__) par n'être pas fanatiques pour mériter
_/___(_) la tolérance. -- Voltaire, 1763
Fabien LE LEZ
Le #17802021
On Mon, 10 Nov 2008 10:38:11 +0100, Alain Ketterlin

| class C
| { ...
| private:
| map < pair<Truc*,Truc*> , set<Truc*> > data;
| };
|
| devraient te convenir aussi.



c1 = c2;

[...] Dans la ligne
précédente, l'opérator= de map


Bien sûr que si.
data est un membre de C, donc son opérateur = est bien appelé.

(Ce serait différent si data était un pointeur vers un map<>)
Olivier Miakinen
Le #17839391
Le 07/11/2008 20:54, Mickaël Wolff a écrit :

Une documentation existante d'une fonction absente ?



Ah tiens, je la connaissais pas celle-là. Ça m'apprendra.



;-)

Je pensais plutôt à une documentation erronée ou périmée.



Ah oui, aussi. Les plus belles perles sont souvent dans les traductions.
Publicité
Poster une réponse
Anonyme