Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Développement Développement Langage C++ Suppression d'instances inutiles ?

Suppression d'instances inutiles ?

53 réponses
Avatar
Mickael Pointier
[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.

Vala, merci de m'éclairer là dessus.

Mike
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
2 3 4 5 6
Avatar
Gabriel Dos Reis
writes:

[...]

| Sérieusement, c'est bien pour des raisons histér^H^Horiques. C'est un
| style qui n'est pas bien vu aujourd'hui, et qui n'est pas très répandu.
| Mais c'était légal dans les premières versions de C, et jusqu'ici,

D&E, page 69:

Even Steve Johnson's PCC, which was the preeminent 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.

-- Gaby
Avatar
Gabriel Dos Reis
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. Voir le
passage cité dans ma réponse à Michel.

D&E, 2.8 Syntax problems.

Could I have "fixed" the most annoying deficiencies of the C syntax
and semantics at some point before C++ was made generally available?
Could I have done so without removing useful features (to C with
Classes' users in their environments -- as opposed to an ideal
world) or introducing incompatibilities that were unacceptable to C
programmers wanting to migrate to C with Classes? I think not. In
some cases, I tried, but I backed out my changes after receiving
complaints from outraged users.

[...]

The part of the C syntax I disliked most was the declaration
syntax. [...] The negative reaction to changes in this area from
users was very strong. They considered the "terseness" allowed by C
essential to the point of refusing to use a "fascist" language that
required them to write redundant type specifiers. [...] Similarly, I
considered the possibility of introducing a linear notation for
declarators. The C trick of having the declaration of name mimic
its use leads to declarations that are hard to read and write, and
maximizes the opportunity for humans and programs to confuse
declarations and expressions. [...] My eventual rationale for
leaving things as they were was that any new syntax would
(temporarily at lest) add complexity to a known mess. Also, even
though the old style is a boon to teachers of trivia and to people
who want to ridicule C, it is not a significant problem for C
programmers. In this case, I'm not sure if I did the right thing,
though. The agony to me and other C++ implementers, documenters, and
tool builders caused by the perversities of syntax has been
significant.

[...]

A subtle aspect of C compatibility discussions is that old-time C
programmers are comfortable with the old ways of doing things and
can therefore be quite intolerant of the incompatibilities needed to
support styles of programming that C wasn't designed for.
Conversely, non-C programmers usually underestimate the value that C
programmers attribute to the C syntax.

-- Gaby
Avatar
kanze
Pierre Maurette wrote in message
news:...
Gabriel Dos Reis typa:

writes:

[...]

| Je regrette que tu t'es senti un peu aggressé par mon posting, mais
| j'avoue que s'il y a une chose que je supporte mal, c'est l'idée
| qu'on peut débogguer un programme au coup d'« au hazard ». Si tu
| avais dit qu'il fallait ajouter un volatile, parce que blah, blah,
| blah, avec des raisons, et non simplement « au hazard », j'aurais
| répondu d'une façon bien moins agressive.

Est-ce à dire que tu reconnais que tu as répondu volontairement de
manière agressive, et non pas qu'il s'est « senti un peu agressé par
ton posting » ?


Me suis pas senti agressé en quoi que ce soit, même pas un peu. Je
commence à connaître un peu le style de chacun sur le groupe, et celui
de James me convient. En tous cas bien plus que celui de ... (faut pas
réver, quand même ;-))


Merci. Il faut dire qu'ici, on ne voit pas son interlocuteur ; on n'a
pas d'indication visuelle comment il prend des choses, et c'est donc
facile à offenser. Dans son livre sur les protocoles Internet, Stevens
avait une bonne règle de base : « Be conservative in what you send,
liberal in what you accept. » Je crois que c'est une bonne règle au
niveau humain aussi.

S'envoyer des noms d'oiseaux à cause d'un malheureux volatile perdu
dans un post serait dommage.


Tout à fait. Il y a quand même des choses plus importantes dans la vie.

Puisque ce volatile semble avoir fait des petits (des oeufs?), je me
permets une précision sur mes intentions (que je pensais claires): il
ne s'agissait absolument pas de placer un volatile dans le code pour
peut-être le faire fonctionner, mais tout simpement de faire un test.
Le problème (à ce moment-là, pas en fonction de ce que je sais
maintenant): mon truc n'est pas instancié, c'est pour ça que ça marche
pas. Je mets un volatile (et je connais bien mon C++7.1). Ça me prend
10", plus le temps de compilation, plus 10" pour l'enlever. Bonne ou
pas, c'est une méthode peu couteuse.


Jusqu'à là, j'avais compris. Mais en général :

- si je fais une expérience, j'aime avoir une idée de ce auquel je
m'attends -- changer pour changer, sans savoir ce qu'on attend,
n'apporte un général pas d'information nouvelle, et

- d'après mon expérience, si tu compiles sans l'optimisation (en mode
debug avec VC++), volatile est un no-op -- son seul effet est
d'inhiber certaines optimisations.

Surtout compte tenu de ce deuxième point, l'ajoute de volatile me
semblait vraiment un coup aléatoire.

En réparation au sens large, quand une panne est un peu sioux (= elle
n'est pas dans le manuel), il arrive très souvent qu'en raisonnant par
inférence, on arrive à prouver que A == !A, ou en d'autres termes
qu'il n'y pas de panne. Combien de fois, en expliquant le blème a un
tiers, ai-je terminé par "et pourtant, ça ne marche pas". (faut jamais
expliquer le problème tel qu'on le voit à un tiers, parce qu'on ne
fait que lui transmettre ses propres paradigmes, perdant l'opportunité
d'une approche fraiche, mais c'est autre chose).


Ça, c'est un autre thèse. Quand il y a une erreur logique dans un
programme, le fait de démander à quelqu'un d'autre nous exige
d'expliquer clairement exactement ce qu'on est en train de faire. Ce qui
souvent suffit pour qu'on voit l'erreur -- même avant que l'autre a dit
un mot.

Je l'ai déjà dit dans les groupes anglophone : la programmation est un
travail d'équipe. On ne peut pas écrire un programme correct tout seul.
Et dans le travail d'équipe, l'ensemble est supérieur à la somme des
parts. (À condition, évidemment, qu'il y a communication réele.)

--
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


Avatar
kanze
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é.

--
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

Avatar
Pierre Maurette
typa:

Pierre Maurette wrote
[...]

S'envoyer des noms d'oiseaux à cause d'un malheureux volatile perdu
dans un post serait dommage.


Tout à fait. Il y a quand même des choses plus importantes dans la vie.
Et c'était surtout un mauvais jeu de mots aviaire de ma part.


[...]
- d'après mon expérience, si tu compiles sans l'optimisation (en mode
debug avec VC++), volatile est un no-op -- son seul effet est
d'inhiber certaines optimisations.
C'est comme ça que je voyais les choses. Mais il en est de même pour

un éventuel problème de non-instanciation, on est donc fatalement en
release quand on se pose la question du code généré.
[Axiome : j'admet que la BONNE solution est de ne pas s'intéresser au
code généré. Admettons donc que c'est mon dada]
Je me demande si la présence d'un point d'arrêt peut modifier le code
généré, dans le cas d'un environnement intégré, bien entendu. Je pense
que non, j'en suis certain pour pour Delphi (qui matérialise dans le
source les lignes "breakpointables", qui génèrent du code objet. C'est
bien, Delphi ;-)).
A part le désassembleur et le debugger kernel (sans rajouter d'appel
système "rare" pour faciliter le repérage dans le code), il faut faire
une sortie .asm de la release.
A ce moment là, avec g++, pas de problème. Avec d'autres (qui
n'utilisent pas systématiquement l'assembleur pour créer le .obj) il
peut y avoir encore doute. Encore qu'une différence constiturait un
bug. Idem pour la sortie préprocesseur, qui peut être fabriquée "pour
l'occasion" (Borland affirme être "une passe").


Surtout compte tenu de ce deuxième point, l'ajoute de volatile me
semblait vraiment un coup aléatoire.

En réparation au sens large, quand une panne est un peu sioux (= elle
n'est pas dans le manuel), il arrive très souvent qu'en raisonnant par
inférence, on arrive à prouver que A == !A, ou en d'autres termes
qu'il n'y pas de panne. Combien de fois, en expliquant le blème a un
tiers, ai-je terminé par "et pourtant, ça ne marche pas". (faut jamais
expliquer le problème tel qu'on le voit à un tiers, parce qu'on ne
fait que lui transmettre ses propres paradigmes, perdant l'opportunité
d'une approche fraiche, mais c'est autre chose).


Ça, c'est un autre thèse. Quand il y a une erreur logique dans un
programme, le fait de démander à quelqu'un d'autre nous exige
d'expliquer clairement exactement ce qu'on est en train de faire. Ce qui
souvent suffit pour qu'on voit l'erreur -- même avant que l'autre a dit
un mot.
Classique. Je ne me souviens pas d'avoir posté ici ou sur fclc à cause

d'un truc qui ne compilait pas ou qui plantait (orgueuil?). En
revanche, deux ou trois fois, j'ai trouvé ma solution en rédigeant le
post et expliquant le problème, en anticipant les questions. Ou en
réduisant le code incriminé à sa plus simple expression compilable et
posant le problème (ça, c'est radical, comme méthode).
Sinon, par rapport aux pannes en général, j'ai remarqué (j'ignore si
ça s'étudie) que l'humain ,n'était pas libre de son raisonnement. Si
A=>B, B=>C, etc., on peut reprendre le raisonnement de zéro, on fera
généralement la même boucle. Quand on a conscience de ce phénomène, on
a des chances d'arriver à s'en affranchir. Ça peut être une origine de
l'expression "la nuit porte conseil".
Quel que soit le problème (panne, mots croisés, lettre de rupture,
programme, rédaction), il est rare qu'on ne fasse pas une série de pas
en avant à la reprise après repos. Et c'est encore mieux si on a
marché ou fait du vélo ou de la voiture en parlant seul, sans crayon
ni ordinateur.
Bel HS, mais le sujet me passionne.
Pierre


Avatar
Michel Michaud
Dans news:,
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() ;


D'un autre côté (je sais que ça n'a pas vraiment rapport), c'est lui
qui a choisi de permettre :

class C;

C* p1= new C;

et
C* p2= new C();

Il y a des éléments syntaxiques de C et même de C++ dont la
sémantique n'est pas directement évidentes...

--
Michel Michaud
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/

Avatar
kanze
Pierre Maurette wrote in message
news:...
typa:

Pierre Maurette wrote
[...]

- d'après mon expérience, si tu compiles sans l'optimisation (en mode
debug avec VC++), volatile est un no-op -- son seul effet est
d'inhiber certaines optimisations.


C'est comme ça que je voyais les choses. Mais il en est de même pour
un éventuel problème de non-instanciation, on est donc fatalement en
release quand on se pose la question du code généré.


Il avait un programme qui ne marchait pas. Il n'avait pas dit que ça
marchait en mode debug, et que ça ne marche plus en mode release. Il est
donc forcement en mode debug.

--
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


Avatar
Gabriel Dos Reis
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.

-- Gaby
Avatar
Mickael Pointier
- d'après mon expérience, si tu compiles sans l'optimisation (en
mode debug avec VC++), volatile est un no-op -- son seul effet
est d'inhiber certaines optimisations.


C'est comme ça que je voyais les choses. Mais il en est de même pour
un éventuel problème de non-instanciation, on est donc fatalement en
release quand on se pose la question du code généré.


Il avait un programme qui ne marchait pas. Il n'avait pas dit que ça
marchait en mode debug, et que ça ne marche plus en mode release. Il
est donc forcement en mode debug.


J'était effectivement en mode debug.

Mike



Avatar
kanze
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.

--
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

2 3 4 5 6