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
Michel Michaud
Dans news:,
"Mickael Pointier" wrote in message
news:<c5oil5$b6v$...
- on peut declarer des fonctions localement.


Hu ? Je ne savais pas ca.
Quel est l'intérêt de déclarer une fonction locale ???


Ne pas casser du C ancien qui s'en sert:-).


On s'en servait en C pour faire des déclarations très locales,
parce qu'il y a une possibilité que ce soit plus sûr qu'une
déclaration globale (c'était peut-être une réalité plus menacante
encore avant les prototypes de ANSI C)...

J'imagine qu'on peut penser que ça ressemble à la possibilité de
mettre un using localement ou globalement : c'est plus sûr
localement, mais plus simple globalement !

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



Avatar
kanze
Fabien LE LEZ wrote in message
news:...
On 19 Apr 2004 01:21:25 -0700, wrote:

Si on a un programme qui ne marche pas, on commence par comprendre


Justement, faire des modifications "au hasard" aide (parfois) à
comprendre.


J'aimerais bien voir comment.

Si on ne connaît pas quelque chose dans le langage, on pourrait, à la
rigueur, faire des essais pour comprendre. Mais ce n'est pas ce que
j'appelle au hasard ; ce doit être des expériences contrôlées, que fait
le programme avec X, et qu'est-ce qu'il fait sans. Et le but dans ces
cas-là, c'est bien de comprendre X, ce n'est pas de faire tourner un
programme existant avec l'espoir que peut-être, au hasard, X résoudra le
problème.

Bien sûr, il ne s'agit pas de laisser ces tests dans le programme
final, mais juste voir comment le bug réagit à des petites
modifications.


Je crois qu'on parle de deux choses différentes. Faire des petites
modifications contrôlées dans l'environement (programme, données ou
autres) où se produit l'erreur pour voir comment il réagit, ce n'est pas
du « au hasard ». On cible bien, on sait (en général) à peu près ce
auquel on s'attend, et on sait ce que signifiera tel ou tel résultat.

Ça, c'est effectivement le premier démarche de la récherche de l'erreur,
bien que la plupart du temps, il se limite à faire varier les données,
sans modifier le code.

--
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
"Mickael Pointier" wrote in message
news:<c60bmh$2mk$...
Donc en fait c'est Visual 6 qui ne fait pas les choses correctement.


Au contraire.

tbDirectoryChanger tbDC() ;

déclare une fonction extern, et VC l'a traité comme une declaration
d'une fonction externe. En plus, il en a donné un avertissement, ce
qui est bien.


Nope.
C'est VC7 qui a fait ce diagnostic.
VC6 ne signale rien, et m'a bien instancié ma variable.
[Ce qui est étrange vu que loic à eu le même comportement avec VC6...]


Chez moi aussi. Est-ce que tu es sûr de tes mésures ? Essaie le
programme suivant, par exemple :

#include <ostream>
#include <iostream>

struct DC
{
DC() { std::cout << "ctorn" ; }
~DC() { std::cout << "dtorn" ; }
} ;

void
g()
{
std::cout << "in gn" ;
}

void
f1()
{
DC x ;
g() ;
}

void
f2()
{
DC x() ;
g() ;
}

int
main()
{
std::cout << "f1n" ;
f1() ;
std::cout << "f2n" ;
f2() ;
return 0 ;
}

Chez moi, il affiche :
f1
ctor
in g
dtor
f2
in g
que ce soit avec VC++ 6.0, g++ 3.2.2 ou Sun CC 5.1.

--
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
"Michel Michaud" wrote in message
news:<oFXgc.35163$...
Dans news:,
"Mickael Pointier" wrote in message
news:<c5oil5$b6v$...
- on peut declarer des fonctions localement.


Hu ? Je ne savais pas ca.
Quel est l'intérêt de déclarer une fonction locale ???


Ne pas casser du C ancien qui s'en sert:-).


On s'en servait en C pour faire des déclarations très locales, parce
qu'il y a une possibilité que ce soit plus sûr qu'une déclaration
globale (c'était peut-être une réalité plus menacante encore avant les
prototypes de ANSI C)...


Je ne m'en suis jamais servi en C. Déjà en C, nous étions beaucoup à le
considérait mieux de mettre les déclarations externes dans un en-tête,
et inclure l'en-tête, plutôt que de les répéter chaque fois qu'on en
avait besoin, dans la fonction.

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

Ce n'est pas beau, mais ce n'est pas la seule laiderie qu'on doit à C,
et en fin de compte, c'est un détail assez mineur. La plupart du temps,
si on oublie, et qu'on écrit « T x() », on a une erreur de compilation
lorsqu'on se sert d'x ; ce n'est donc pas bien grave. Si Mickael est
allé plus loin, c'est qu'exceptionnellement, il avait une classe RAII
avec un constructeur ne prenait pas de paramètres. Ça existe, mais je
doute que c'est la majorité des classes.

J'imagine qu'on peut penser que ça ressemble à la possibilité de
mettre un using localement ou globalement : c'est plus sûr localement,
mais plus simple globalement !


Ce n'est pas tout à fait pareil. Le using, ça dit quelque chose sur
l'endroit où tu le mets ; que tu vas te servir de tel ou tel symbole
dans cette portée-là. Tandis que la déclaration de la fonction, ça
décrit la fonction : ses paramètres et son type de rétour. Alors, tu ne
veux pas en avoir plus de copies que nécessaire à maintenir.

Ce n'était jamais une bonne technique. Mais ça ne veut pas dire qu'il
n'a pas servi.

--
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
adebaene
"Mickael Pointier" wrote in message news:<c60bmh$2mk$...
Donc en fait c'est Visual 6 qui ne fait pas les choses correctement.


Au contraire.

tbDirectoryChanger tbDC() ;

déclare une fonction extern, et VC l'a traité comme une declaration
d'une fonction externe. En plus, il en a donné un avertissement, ce
qui est bien.


Nope.
C'est VC7 qui a fait ce diagnostic.
VC6 ne signale rien, et m'a bien instancié ma variable.
[Ce qui est étrange vu que loic à eu le même comportement avec VC6...]
Une différence de Service Pack peut-être?


Arnaud



Avatar
Michel Michaud
Dans news:,
"Michel Michaud" wrote in message
news:<oFXgc.35163$...
Dans news:,
"Mickael Pointier" wrote in message
news:<c5oil5$b6v$...
Quel est l'intérêt de déclarer une fonction locale ???


Ne pas casser du C ancien qui s'en sert:-).
[...]



Je ne m'en suis jamais servi en C. Déjà en C, nous étions beaucoup
à le considérait mieux de mettre les déclarations externes dans un
en-tête, et inclure l'en-tête, plutôt que de les répéter chaque
fois qu'on en avait besoin, dans la fonction.


Bien sûr. Je crois que c'était normal même en C pré-ANSI.


Mais le langage le permettait, et du moment que le langage le
permettait, il faut bien supposer que quelqu'un s'en est servi.


Oui, mais je ne me rappelle plus vraiment pourquoi il me semble
l'avoir déjà fait ou vu (il y a près de vingt ans !). Dans le livre
sur C écrit par un de mes collègues en 1986, je trouve bien la
description de cette possibilité, comme si ce n'était pas une
chose anormale ou extraordinaire, mais il n'y a pas d'explication
particulière sur le pourquoi de le faire. J'ai l'impression que
si l'idée de faire un fichier d'en-tête n'était pas retenue, alors
faire la déclaration la plus locale possible devait sembler
naturelle.

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




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

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

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


Je reconnais avoir essayer « faire un effet » exprès. L'intention
n'était pas de l'offenser personnellement. Il est loin d'être le seul à
poster des idioties en prétendant qu'il sache de quoi il parle ; il a eu
le malheur à être la goûte qui a débordé le sceau (or que certains
d'autres ont été bien pire), et en plus, d'avoir dit le mot magique
(«@au hasard » -- je n'accepte pas l'idée que la programmation est une
activité basée sur l'aléatoire). Et je me rendais bien compte en postant
qu'il pourrait s'y offenser.

Ceci dit, j'espère que tu es d'accord avec moi en ce qui concerne
l'essentiel, c-à-d que la programmation, ce n'est pas un jeu de dés, et
que « volatile » n'avait rien à faire avec le problème en question.
J'aurais pû m'exprimer d'une façon plus diplomatique, mais il y a des
jours où j'ai marre de la diplomatie.

--
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
"Michel Michaud" wrote in message
news:<J8bhc.41790$...

Dans news:,


[en ce qui concerne la déclaration locale des fonctions...]
Mais le langage le permettait, et du moment que le langage le
permettait, il faut bien supposer que quelqu'un s'en est servi.


Oui, mais je ne me rappelle plus vraiment pourquoi il me semble
l'avoir déjà fait ou vu (il y a près de vingt ans !).


Oh, je l'ai bien vu, moi aussi. Ça ne m'étonnerait même pas qu'il y a
vingt ans (ou plus), il y avait certains pour dire que c'était comme ça
qu'il fallait faire.

J'ai aussi vu des gens qui commençaient chaque ligne en colonne 1,
indépendamment de l'imbrication. Ça aussi, il y a plus de vingt ans. On
progresse. À petits pas, mais on progresse.

Dans le livre sur C écrit par un de mes collègues en 1986, je trouve
bien la description de cette possibilité, comme si ce n'était pas une
chose anormale ou extraordinaire, mais il n'y a pas d'explication
particulière sur le pourquoi de le faire.


Elle est décrit dans le K&R 1, je crois.

Elle fait partie du langage. D'un certain côté, elle est même cohérente
avec la reste du langage. En fait, personnellement, je le trouve normal
de *pouvoir* déclarer des fonctions externes dans une fonction. Pour des
raisons d'orthogonalité, évidemment, et non parce que je crois qu'on
doit s'en servir. Seulement, la syntaxe de déclaration de C est tel que
pratiquement tout ce qu'on permet fini par créer des ambiguïtés ; si
j'avais une syntaxe à la Pascal :

var DirectoryContext x ;
function DirectoryContext f ;

on n'en parlerait pas.

Si c'était le premier avril, je proposerais une solution à la Fortran :
si le nom commence par f, g ou h, c'est une fonction ; sinon, c'est une
variable.:-). Après tout, certains y ont déjà commencé : si le nom
commence par un C, c'est un type de classe:-).

J'ai l'impression que si l'idée de faire un fichier d'en-tête n'était
pas retenue, alors faire la déclaration la plus locale possible devait
sembler naturelle.


Tout à fait. Mais j'avoue ne pas avoir servi du C avant l'époque où il y
avait déjà le préprocesseur. Je suis ancien, mais je suis venu assez
tardivement à C (en 1982, je crois).

--
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
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 ;-))
S'envoyer des noms d'oiseaux à cause d'un malheureux volatile perdu
dans un post serait dommage.
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.
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).
Pour le rapport entre le volatile sus-évoqué et la réparation, je fais
confiance à votre sagacité.

Pierre

2 3 4 5 6