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 ???
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 ???
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 ???
============= > 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
============= > 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
============= > 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
[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.
J'avais remarqué que VC++7 avait l'optimisation virile et joyeuse.
[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.
J'avais remarqué que VC++7 avait l'optimisation virile et joyeuse.
[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.
J'avais remarqué que VC++7 avait l'optimisation virile et joyeuse.
"Mickael Pointier" typa:[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.
J'avais remarqué que VC++7 avait l'optimisation virile et joyeuse.
Normal ou pas normal, je n'en sais pas assez en C++ et sur le
DoSomething pour me prononcer.
A tout hasard, essayez:
volatile tbDirectoryChanger tbDC("repert");
"Mickael Pointier" <mpointier@eden-games.moc> typa:
[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.
J'avais remarqué que VC++7 avait l'optimisation virile et joyeuse.
Normal ou pas normal, je n'en sais pas assez en C++ et sur le
DoSomething pour me prononcer.
A tout hasard, essayez:
volatile tbDirectoryChanger tbDC("repert");
"Mickael Pointier" typa:[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.
J'avais remarqué que VC++7 avait l'optimisation virile et joyeuse.
Normal ou pas normal, je n'en sais pas assez en C++ et sur le
DoSomething pour me prononcer.
A tout hasard, essayez:
volatile tbDirectoryChanger tbDC("repert");
Pierre Maurette wrote:
[...]
J'avais remarqué que VC++7 avait l'optimisation virile et joyeuse.
Normal ou pas normal, je n'en sais pas assez en C++ et sur le
DoSomething pour me prononcer.
A tout hasard, essayez:
volatile tbDirectoryChanger tbDC("repert");
Cela ne devrait rien changer.
Non, parce que ce n'est pas nécessaire, le problème est ailleurs.
Le constructeur non trivial et inconnu dans l'unite de compilation a le
droit d'avoir des effets de bords. Le compilateur doit donc construire
tbDC imperativement. La duree de vie de tbDC va jusqu'a la fin du bloc
courant donc au-dela de DoSomething. Je pencherais pour un bug mais ca
me parait enorme comme bug (difficile de croire qu'il n'ait pas ete
detecte par les ecrivains du compilateur). Peut-etre faudrait-il voir le
code du constructeur et de DoSomething pour en avoir le coeur net?
Pierre Maurette wrote:
[...]
J'avais remarqué que VC++7 avait l'optimisation virile et joyeuse.
Normal ou pas normal, je n'en sais pas assez en C++ et sur le
DoSomething pour me prononcer.
A tout hasard, essayez:
volatile tbDirectoryChanger tbDC("repert");
Cela ne devrait rien changer.
Non, parce que ce n'est pas nécessaire, le problème est ailleurs.
Le constructeur non trivial et inconnu dans l'unite de compilation a le
droit d'avoir des effets de bords. Le compilateur doit donc construire
tbDC imperativement. La duree de vie de tbDC va jusqu'a la fin du bloc
courant donc au-dela de DoSomething. Je pencherais pour un bug mais ca
me parait enorme comme bug (difficile de croire qu'il n'ait pas ete
detecte par les ecrivains du compilateur). Peut-etre faudrait-il voir le
code du constructeur et de DoSomething pour en avoir le coeur net?
Pierre Maurette wrote:
[...]
J'avais remarqué que VC++7 avait l'optimisation virile et joyeuse.
Normal ou pas normal, je n'en sais pas assez en C++ et sur le
DoSomething pour me prononcer.
A tout hasard, essayez:
volatile tbDirectoryChanger tbDC("repert");
Cela ne devrait rien changer.
Non, parce que ce n'est pas nécessaire, le problème est ailleurs.
Le constructeur non trivial et inconnu dans l'unite de compilation a le
droit d'avoir des effets de bords. Le compilateur doit donc construire
tbDC imperativement. La duree de vie de tbDC va jusqu'a la fin du bloc
courant donc au-dela de DoSomething. Je pencherais pour un bug mais ca
me parait enorme comme bug (difficile de croire qu'il n'ait pas ete
detecte par les ecrivains du compilateur). Peut-etre faudrait-il voir le
code du constructeur et de DoSomething pour en avoir le coeur net?
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.
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.
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.
j'ai un
certain nombre de petites classes utilitaires qui n'ont de code que dans le
constructeur et dans le destructeur.
j'ai un
certain nombre de petites classes utilitaires qui n'ont de code que dans le
constructeur et dans le destructeur.
j'ai un
certain nombre de petites classes utilitaires qui n'ont de code que dans le
constructeur et dans le destructeur.
============= > 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
};
=============
on a pas le code des méthodes. Je fais donc un essai avec un corps
{
tbDirectoryChanger tbDC("mon nouveau chemin de travail temporaire");
DoSomething(bla sur le nouveau chemin);
}
============= > 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
};
=============
on a pas le code des méthodes. Je fais donc un essai avec un corps
{
tbDirectoryChanger tbDC("mon nouveau chemin de travail temporaire");
DoSomething(bla sur le nouveau chemin);
}
============= > 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
};
=============
on a pas le code des méthodes. Je fais donc un essai avec un corps
{
tbDirectoryChanger tbDC("mon nouveau chemin de travail temporaire");
DoSomething(bla sur le nouveau chemin);
}
J'avais remarqué que VC++7 avait l'optimisation virile et joyeuse.
Normal ou pas normal, je n'en sais pas assez en C++ et sur le
DoSomething pour me prononcer.
A tout hasard, essayez:
volatile tbDirectoryChanger tbDC("repert");
J'avais remarqué que VC++7 avait l'optimisation virile et joyeuse.
Normal ou pas normal, je n'en sais pas assez en C++ et sur le
DoSomething pour me prononcer.
A tout hasard, essayez:
volatile tbDirectoryChanger tbDC("repert");
J'avais remarqué que VC++7 avait l'optimisation virile et joyeuse.
Normal ou pas normal, je n'en sais pas assez en C++ et sur le
DoSomething pour me prononcer.
A tout hasard, essayez:
volatile tbDirectoryChanger tbDC("repert");
Laurent Deniau typa:Pierre Maurette wrote:
[...]J'avais remarqué que VC++7 avait l'optimisation virile et joyeuse.
Normal ou pas normal, je n'en sais pas assez en C++ et sur le
DoSomething pour me prononcer.
A tout hasard, essayez:
volatile tbDirectoryChanger tbDC("repert");
Cela ne devrait rien changer.
Non, parce que ce n'est pas nécessaire, le problème est ailleurs.
C'est marrant, le volatile. Vous faites :
volatile int c = 12;
c=c;
c=c;
// rien d'autre pour c
il génère:
12 -> mémoire
mémoire -> registre
registre -> mémoire
mémoire -> registre
registre -> mémoire
Le constructeur non trivial et inconnu dans l'unite de compilation a
le droit d'avoir des effets de bords. Le compilateur doit donc
construire tbDC imperativement. La duree de vie de tbDC va jusqu'a la
fin du bloc courant donc au-dela de DoSomething. Je pencherais pour
un bug mais ca me parait enorme comme bug (difficile de croire qu'il
n'ait pas ete detecte par les ecrivains du compilateur). Peut-etre
faudrait-il voir le code du constructeur et de DoSomething pour en
avoir le coeur net?
J'ai vérifié rapidement sans écrire les constructeurs ni destructeurs.
Le lieur me jette, mais c'est pas grave. Le constructeur est bien
appelé au moment de l'instanciation, et le destructeur à la fin de la
fonction. Avec VC++ 7.1 full, en release optimisée. Doit y avoir du
bug ailleurs.
Pour Mickael, vérifier en ajoutant l'option /FAs à la compilation, et
en regardant le fichier .asm (rechercher sur les mots du source, c'est
à la fin d'un gros fichier).
Laurent Deniau <Laurent.Deniau@cern.ch> typa:
Pierre Maurette wrote:
[...]
J'avais remarqué que VC++7 avait l'optimisation virile et joyeuse.
Normal ou pas normal, je n'en sais pas assez en C++ et sur le
DoSomething pour me prononcer.
A tout hasard, essayez:
volatile tbDirectoryChanger tbDC("repert");
Cela ne devrait rien changer.
Non, parce que ce n'est pas nécessaire, le problème est ailleurs.
C'est marrant, le volatile. Vous faites :
volatile int c = 12;
c=c;
c=c;
// rien d'autre pour c
il génère:
12 -> mémoire
mémoire -> registre
registre -> mémoire
mémoire -> registre
registre -> mémoire
Le constructeur non trivial et inconnu dans l'unite de compilation a
le droit d'avoir des effets de bords. Le compilateur doit donc
construire tbDC imperativement. La duree de vie de tbDC va jusqu'a la
fin du bloc courant donc au-dela de DoSomething. Je pencherais pour
un bug mais ca me parait enorme comme bug (difficile de croire qu'il
n'ait pas ete detecte par les ecrivains du compilateur). Peut-etre
faudrait-il voir le code du constructeur et de DoSomething pour en
avoir le coeur net?
J'ai vérifié rapidement sans écrire les constructeurs ni destructeurs.
Le lieur me jette, mais c'est pas grave. Le constructeur est bien
appelé au moment de l'instanciation, et le destructeur à la fin de la
fonction. Avec VC++ 7.1 full, en release optimisée. Doit y avoir du
bug ailleurs.
Pour Mickael, vérifier en ajoutant l'option /FAs à la compilation, et
en regardant le fichier .asm (rechercher sur les mots du source, c'est
à la fin d'un gros fichier).
Laurent Deniau typa:Pierre Maurette wrote:
[...]J'avais remarqué que VC++7 avait l'optimisation virile et joyeuse.
Normal ou pas normal, je n'en sais pas assez en C++ et sur le
DoSomething pour me prononcer.
A tout hasard, essayez:
volatile tbDirectoryChanger tbDC("repert");
Cela ne devrait rien changer.
Non, parce que ce n'est pas nécessaire, le problème est ailleurs.
C'est marrant, le volatile. Vous faites :
volatile int c = 12;
c=c;
c=c;
// rien d'autre pour c
il génère:
12 -> mémoire
mémoire -> registre
registre -> mémoire
mémoire -> registre
registre -> mémoire
Le constructeur non trivial et inconnu dans l'unite de compilation a
le droit d'avoir des effets de bords. Le compilateur doit donc
construire tbDC imperativement. La duree de vie de tbDC va jusqu'a la
fin du bloc courant donc au-dela de DoSomething. Je pencherais pour
un bug mais ca me parait enorme comme bug (difficile de croire qu'il
n'ait pas ete detecte par les ecrivains du compilateur). Peut-etre
faudrait-il voir le code du constructeur et de DoSomething pour en
avoir le coeur net?
J'ai vérifié rapidement sans écrire les constructeurs ni destructeurs.
Le lieur me jette, mais c'est pas grave. Le constructeur est bien
appelé au moment de l'instanciation, et le destructeur à la fin de la
fonction. Avec VC++ 7.1 full, en release optimisée. Doit y avoir du
bug ailleurs.
Pour Mickael, vérifier en ajoutant l'option /FAs à la compilation, et
en regardant le fichier .asm (rechercher sur les mots du source, c'est
à la fin d'un gros fichier).