[Je viens de réinstaller mon PC suite à un changement d'OS, pourriez vous me
signaler le moindre problème dans ce message, que ca soit au niveau de
l'encodage ou que sais-je encore ? Merci d'avance.]
Je viens de passer de Visual 6 à VS.net 2003, et en convertissant mes
quelques projets C++, j'ai constaté un certain nombre de différences au
niveau du comportement de ces deux compilateurs. VS.net est visiblement bien
plus rigoureux et clair dans les erreurs qu'il signale, par contre il m'a
fait un truc que je n'ai pas trop aimé.
Ce que j'aimerai savoir si c'est lui qui a raison (la norme dit qu'il faut
le faire) et que donc je me reposait sur un comportement indéfini, ou bien
si ce que je faisait était pas mauvais en soit et que c'est donc VS.net qui
abuse.
Le point en question, c'est que dans ma librairie de déboggage, j'ai un
certain nombre de petites classes utilitaires qui n'ont de code que dans le
constructeur et dans le destructeur.
Certaines me servent à trouver des fuites de mémoire, d'autre à me sauver la
pile des appels dans un log, etc... tout ca ne sert qu'en debug, en release
le code en question est supprimé.
Vu que c'était pratique, j'ai débordé de l'usage purement debug, et j'ai
commencé à m'en servir, comme par exemple avec ma microclasse de
manipulation de répertoires:
==============
class tbDirectoryChanger
{
public:
tbDirectoryChanger(); //!< Simply store the current path
tbDirectoryChanger(const string &new_path); //!< Store the current path,
and set the new one
~tbDirectoryChanger(); //!< Restore the path stored during
construction
private:
void store_current_path(); //!< Utility function, store the current
path
string m_memo_path; //!< Contains the stored path
};
==============
C'est pas forcément très beau, mais ca me permet dans un outil de build de
ressources qui gère beaucoup de chemins d'accès de faire des trucs dans le
genre:
...
{
tbDirectoryChanger tbDC("mon nouveau chemin de travail temporaire");
DoSomething(bla sur le nouveau chemin);
}
...
ce qui fait qu'à la sortie du scope, le directory est automatiquement
restauré.
Avec VC6 ca marchait bien, VC7 lui considère que la variable "tbDC" n'est
pas utilisée, et donc il vire l'instanciation de ma variable, ce qui fait
que mon répertoire n'est pas changé, et mon "DoSomething" il fait n'importe
quoi vu que le répertoire n'est pas validé.
Donc il a le droit de faire ca ???
La variable n'est pas utilisée, soit, mais le constructeur et le destructeur
ne sont pas triviaux.
| Gabriel Dos Reis wrote in message | news:... | > writes: | | > | Gabriel Dos Reis wrote in message | > | news:... | > | > writes: | | > | > [...] | | > | > | Mais le langage le permettait, et du moment que le langage le | > | > | permettait, il faut bien supposer que quelqu'un s'en est servi. | > | > | Je ne sais pas si Stroustrup a réflechi sur la question quand il | > | > | créait le | | > | > Sûr qu'il y a réfléchi et cela a été l'une de ses agonies. | | > | Je sais qu'il a dû agoniser beaucoup. Faire propre ET rester | > | compatible avec C n'est pas toujours évident. | | > | > Voir le passage cité dans ma réponse à Michel. | | > | Je savais qu'il n'aimait pas le syntaxe de déclaration en général. | > | Je crois que c'est lui qui a caractèrisé ce syntaxe comme « an | > | experiment which failed ». Ma seule doute, c'était s'il avait fait | > | une reflexion approfondie sur le cas précis de : | | > | MyClass var() ; | | > | ou s'il tombait simplement dans la généralisation qu'on est obligé à | > | vivre avec le syntaxe C, bien ou mal, pour des raisons de | > | compatibilité. | | > Le passage que j'avais cité dans la réponse de Michel répondait à ce | > point précis. Comme il l'a indiqué, il y a réfléchi et a même noté que | > malgré la spécification de l'époque, le compilateur PCC faisait | > n'importe quoi -- c'est écrit dans la texte. | | Le passage que tu as cité parlait des généralités en ce qui concerne la | philosophie qui a servi, et contentait un anecdote sur l'implémentation | de CFront qui n'avait rien à voir avec le cas en question. C'est assez | intéressant, mais c'était à peu près ce que je savais déjà. Reste la | question si Stroustrup avait considéré ce cas particulièrement, ou s'il | a simplement retombé comme ça suite à des considérations générales.
Je présume que ton écran n'a pas affiché ceci :
[...] Even Steve Johnson's PCC, which was the prominent C compiler at the time, cheated at details that were to prove troublesome to C++ parser writers. For example, PCC didn't handle redundant parentheses correctly so that int(x); wasn't accepted as a declaration of x. [...]
[ Et si tu veux savoir comment il s'en est aperçu, c'est *pendant* qu'il essayait de trouver une solution à ce problème. ]
Et avant de répondre à ce message, prends le temps de lire la section 2.8. Cela serait bénéfique à chacun d'entre nous.
-- Gaby
kanze@gabi-soft.fr writes:
| Gabriel Dos Reis <gdr@integrable-solutions.net> wrote in message
| news:<m37jw796ps.fsf@uniton.integrable-solutions.net>...
| > kanze@gabi-soft.fr writes:
|
| > | Gabriel Dos Reis <gdr@integrable-solutions.net> wrote in message
| > | news:<m38ygp1o7l.fsf@uniton.integrable-solutions.net>...
| > | > kanze@gabi-soft.fr writes:
|
| > | > [...]
|
| > | > | Mais le langage le permettait, et du moment que le langage le
| > | > | permettait, il faut bien supposer que quelqu'un s'en est servi.
| > | > | Je ne sais pas si Stroustrup a réflechi sur la question quand il
| > | > | créait le
|
| > | > Sûr qu'il y a réfléchi et cela a été l'une de ses agonies.
|
| > | Je sais qu'il a dû agoniser beaucoup. Faire propre ET rester
| > | compatible avec C n'est pas toujours évident.
|
| > | > Voir le passage cité dans ma réponse à Michel.
|
| > | Je savais qu'il n'aimait pas le syntaxe de déclaration en général.
| > | Je crois que c'est lui qui a caractèrisé ce syntaxe comme « an
| > | experiment which failed ». Ma seule doute, c'était s'il avait fait
| > | une reflexion approfondie sur le cas précis de :
|
| > | MyClass var() ;
|
| > | ou s'il tombait simplement dans la généralisation qu'on est obligé à
| > | vivre avec le syntaxe C, bien ou mal, pour des raisons de
| > | compatibilité.
|
| > Le passage que j'avais cité dans la réponse de Michel répondait à ce
| > point précis. Comme il l'a indiqué, il y a réfléchi et a même noté que
| > malgré la spécification de l'époque, le compilateur PCC faisait
| > n'importe quoi -- c'est écrit dans la texte.
|
| Le passage que tu as cité parlait des généralités en ce qui concerne la
| philosophie qui a servi, et contentait un anecdote sur l'implémentation
| de CFront qui n'avait rien à voir avec le cas en question. C'est assez
| intéressant, mais c'était à peu près ce que je savais déjà. Reste la
| question si Stroustrup avait considéré ce cas particulièrement, ou s'il
| a simplement retombé comme ça suite à des considérations générales.
Je présume que ton écran n'a pas affiché ceci :
[...] Even Steve Johnson's PCC, which was the prominent C compiler
at the time, cheated at details that were to prove troublesome to
C++ parser writers. For example, PCC didn't handle redundant
parentheses correctly so that int(x); wasn't accepted as a
declaration of x. [...]
[ Et si tu veux savoir comment il s'en est aperçu, c'est *pendant* qu'il
essayait de trouver une solution à ce problème. ]
Et avant de répondre à ce message, prends le temps de lire la section
2.8. Cela serait bénéfique à chacun d'entre nous.
| Gabriel Dos Reis wrote in message | news:... | > writes: | | > | Gabriel Dos Reis wrote in message | > | news:... | > | > writes: | | > | > [...] | | > | > | Mais le langage le permettait, et du moment que le langage le | > | > | permettait, il faut bien supposer que quelqu'un s'en est servi. | > | > | Je ne sais pas si Stroustrup a réflechi sur la question quand il | > | > | créait le | | > | > Sûr qu'il y a réfléchi et cela a été l'une de ses agonies. | | > | Je sais qu'il a dû agoniser beaucoup. Faire propre ET rester | > | compatible avec C n'est pas toujours évident. | | > | > Voir le passage cité dans ma réponse à Michel. | | > | Je savais qu'il n'aimait pas le syntaxe de déclaration en général. | > | Je crois que c'est lui qui a caractèrisé ce syntaxe comme « an | > | experiment which failed ». Ma seule doute, c'était s'il avait fait | > | une reflexion approfondie sur le cas précis de : | | > | MyClass var() ; | | > | ou s'il tombait simplement dans la généralisation qu'on est obligé à | > | vivre avec le syntaxe C, bien ou mal, pour des raisons de | > | compatibilité. | | > Le passage que j'avais cité dans la réponse de Michel répondait à ce | > point précis. Comme il l'a indiqué, il y a réfléchi et a même noté que | > malgré la spécification de l'époque, le compilateur PCC faisait | > n'importe quoi -- c'est écrit dans la texte. | | Le passage que tu as cité parlait des généralités en ce qui concerne la | philosophie qui a servi, et contentait un anecdote sur l'implémentation | de CFront qui n'avait rien à voir avec le cas en question. C'est assez | intéressant, mais c'était à peu près ce que je savais déjà. Reste la | question si Stroustrup avait considéré ce cas particulièrement, ou s'il | a simplement retombé comme ça suite à des considérations générales.
Je présume que ton écran n'a pas affiché ceci :
[...] Even Steve Johnson's PCC, which was the prominent C compiler at the time, cheated at details that were to prove troublesome to C++ parser writers. For example, PCC didn't handle redundant parentheses correctly so that int(x); wasn't accepted as a declaration of x. [...]
[ Et si tu veux savoir comment il s'en est aperçu, c'est *pendant* qu'il essayait de trouver une solution à ce problème. ]
Et avant de répondre à ce message, prends le temps de lire la section 2.8. Cela serait bénéfique à chacun d'entre nous.
-- Gaby
kanze
Gabriel Dos Reis wrote in message news:...
[...]
Je présume que ton écran n'a pas affiché ceci :
[...] Even Steve Johnson's PCC, which was the prominent C compiler at the time, cheated at details that were to prove troublesome to C++ parser writers. For example, PCC didn't handle redundant parentheses correctly so that int(x); wasn't accepted as a declaration of x. [...]
Quel rapport avec :
MaClasse t() ;
?
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Gabriel Dos Reis <gdr@integrable-solutions.net> wrote in message
news:<m3fzatrw09.fsf@uniton.integrable-solutions.net>...
[...]
Je présume que ton écran n'a pas affiché ceci :
[...] Even Steve Johnson's PCC, which was the prominent C compiler
at the time, cheated at details that were to prove troublesome to
C++ parser writers. For example, PCC didn't handle redundant
parentheses correctly so that int(x); wasn't accepted as a
declaration of x. [...]
Quel rapport avec :
MaClasse t() ;
?
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
[...] Even Steve Johnson's PCC, which was the prominent C compiler at the time, cheated at details that were to prove troublesome to C++ parser writers. For example, PCC didn't handle redundant parentheses correctly so that int(x); wasn't accepted as a declaration of x. [...]
Quel rapport avec :
MaClasse t() ;
?
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Gabriel Dos Reis
writes:
| Gabriel Dos Reis wrote in message | news:... | | [...] | | > Je présume que ton écran n'a pas affiché ceci : | | > [...] Even Steve Johnson's PCC, which was the prominent C compiler | > at the time, cheated at details that were to prove troublesome to | > C++ parser writers. For example, PCC didn't handle redundant | > parentheses correctly so that int(x); wasn't accepted as a | > declaration of x. [...] | | Quel rapport avec : | | MaClasse t() ; | | ?
La continuité syntaxique -- c'était peut-être trop subtile pour apparaître comme évident.
Remettons ta citation en perspective :
Mais le langage le permettait, et du moment que le langage le permettait, il faut bien supposer que quelqu'un s'en est servi. Je ne sais pas si Stroustrup a réflechi sur la question quand il créait le langage, mais même en y réflechissant, il aurait très bien pu tombé sur l'argument de Fabien -- ce serait en effet drôle que « T f() ; » ait une signification à la portée de fichier, et une autre dans une fonction. Et même si moi, j'écris pas « T f() ; » à la portée de namespace non plus (j'écris l'« extern » explicitement), c'est un usage très répandu, qu'il n'aurait pas pû cassé.
Il était à la recherche d'une solution pour éliminer les parenthèses redondantes et s'il avait réussi comme il le souhaitait, les parenthèses ne seraient nécessaires que pour déclarer les fonctions, i.e. préserver la signification de « T f() » quelque soit la portée, et en avoir une signification proche de « T f(U) » c'est-à-dire une fonction. L'argument qu'il utilise, c'est celui de l'uniformité de la syntaxe (dont celui de Fabien est un corollaire trivial): f(U) et f() ne devraient pas appartenir à des catégories syntactiques différentes. Tout le blah blah habituel dans les newsgroups provient en grande partie de cette différence là.
-- Gaby
kanze@gabi-soft.fr writes:
| Gabriel Dos Reis <gdr@integrable-solutions.net> wrote in message
| news:<m3fzatrw09.fsf@uniton.integrable-solutions.net>...
|
| [...]
|
| > Je présume que ton écran n'a pas affiché ceci :
|
| > [...] Even Steve Johnson's PCC, which was the prominent C compiler
| > at the time, cheated at details that were to prove troublesome to
| > C++ parser writers. For example, PCC didn't handle redundant
| > parentheses correctly so that int(x); wasn't accepted as a
| > declaration of x. [...]
|
| Quel rapport avec :
|
| MaClasse t() ;
|
| ?
La continuité syntaxique -- c'était peut-être trop subtile pour
apparaître comme évident.
Remettons ta citation en perspective :
Mais le langage le permettait, et du moment que le langage le
permettait, il faut bien supposer que quelqu'un s'en est servi. Je ne
sais pas si Stroustrup a réflechi sur la question quand il créait le
langage, mais même en y réflechissant, il aurait très bien pu tombé sur
l'argument de Fabien -- ce serait en effet drôle que « T f() ; » ait une
signification à la portée de fichier, et une autre dans une fonction. Et
même si moi, j'écris pas « T f() ; » à la portée de namespace non plus
(j'écris l'« extern » explicitement), c'est un usage très répandu, qu'il
n'aurait pas pû cassé.
Il était à la recherche d'une solution pour éliminer les parenthèses
redondantes et s'il avait réussi comme il le souhaitait, les
parenthèses ne seraient nécessaires que pour déclarer les fonctions,
i.e. préserver la signification de « T f() » quelque soit la portée,
et en avoir une signification proche de « T f(U) » c'est-à-dire une
fonction. L'argument qu'il utilise, c'est celui de l'uniformité de la
syntaxe (dont celui de Fabien est un corollaire trivial): f(U) et f()
ne devraient pas appartenir à des catégories syntactiques
différentes. Tout le blah blah habituel dans les newsgroups provient
en grande partie de cette différence là.
| Gabriel Dos Reis wrote in message | news:... | | [...] | | > Je présume que ton écran n'a pas affiché ceci : | | > [...] Even Steve Johnson's PCC, which was the prominent C compiler | > at the time, cheated at details that were to prove troublesome to | > C++ parser writers. For example, PCC didn't handle redundant | > parentheses correctly so that int(x); wasn't accepted as a | > declaration of x. [...] | | Quel rapport avec : | | MaClasse t() ; | | ?
La continuité syntaxique -- c'était peut-être trop subtile pour apparaître comme évident.
Remettons ta citation en perspective :
Mais le langage le permettait, et du moment que le langage le permettait, il faut bien supposer que quelqu'un s'en est servi. Je ne sais pas si Stroustrup a réflechi sur la question quand il créait le langage, mais même en y réflechissant, il aurait très bien pu tombé sur l'argument de Fabien -- ce serait en effet drôle que « T f() ; » ait une signification à la portée de fichier, et une autre dans une fonction. Et même si moi, j'écris pas « T f() ; » à la portée de namespace non plus (j'écris l'« extern » explicitement), c'est un usage très répandu, qu'il n'aurait pas pû cassé.
Il était à la recherche d'une solution pour éliminer les parenthèses redondantes et s'il avait réussi comme il le souhaitait, les parenthèses ne seraient nécessaires que pour déclarer les fonctions, i.e. préserver la signification de « T f() » quelque soit la portée, et en avoir une signification proche de « T f(U) » c'est-à-dire une fonction. L'argument qu'il utilise, c'est celui de l'uniformité de la syntaxe (dont celui de Fabien est un corollaire trivial): f(U) et f() ne devraient pas appartenir à des catégories syntactiques différentes. Tout le blah blah habituel dans les newsgroups provient en grande partie de cette différence là.
