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.
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<...> n'est pas appelé (et c'est 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.
Fabien LE LEZ <gramster@gramster.com> writes:
On Fri, 07 Nov 2008 12:45:56 +0100, Alain Ketterlin
<alain@dpt-info.u-strasbg.fr>:
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<...> n'est pas appelé (et c'est
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.)
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<...> n'est pas appelé (et c'est 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
Mickaël Wolff writes:
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__
Mickaël Wolff <mickael.wolff@laposte.net> writes:
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.
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 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
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
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 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
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
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
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<...> n'est pas appelé
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<>)
On Mon, 10 Nov 2008 10:38:11 +0100, Alain Ketterlin
<alain@dpt-info.u-strasbg.fr>:
| 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<...> n'est pas appelé
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<>)
