============= >> 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
simplissime (mais non vide).
[...]
Mon compilo C++ (borland C++ builder) passe tout sans pb (aucun
warning) la variable est bien construite puis détruite.
ça serait étrange que visual studio renferme un bug aussi gros. Un
peu plus de détails sur cette classe et DoSomething nous aiderait...
============= >> 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
simplissime (mais non vide).
[...]
Mon compilo C++ (borland C++ builder) passe tout sans pb (aucun
warning) la variable est bien construite puis détruite.
ça serait étrange que visual studio renferme un bug aussi gros. Un
peu plus de détails sur cette classe et DoSomething nous aiderait...
============= >> 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
simplissime (mais non vide).
[...]
Mon compilo C++ (borland C++ builder) passe tout sans pb (aucun
warning) la variable est bien construite puis détruite.
ça serait étrange que visual studio renferme un bug aussi gros. Un
peu plus de détails sur cette classe et DoSomething nous aiderait...
Pierre Maurette wrote in message
news:...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");
On programme à coups d'hazard, maintenant. Si le programme ne marche
pas, on modifie quelque chose de façon aléatoire, en espérant que par je
ne sais pas quelle miracle, il va se mettre à marcher.
Cool, Raoul.
J'espère ne jamais avoir à utiliser un programme que tu as écrit.
Dieu m'en préserve également, ce serait un grand honneur pour moi,
Pierre Maurette <maurette.pierre@free.fr> wrote in message
news:<gm0t70917it87q89qds50ns3m55jrph89m@4ax.com>...
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");
On programme à coups d'hazard, maintenant. Si le programme ne marche
pas, on modifie quelque chose de façon aléatoire, en espérant que par je
ne sais pas quelle miracle, il va se mettre à marcher.
Cool, Raoul.
J'espère ne jamais avoir à utiliser un programme que tu as écrit.
Dieu m'en préserve également, ce serait un grand honneur pour moi,
Pierre Maurette wrote in message
news:...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");
On programme à coups d'hazard, maintenant. Si le programme ne marche
pas, on modifie quelque chose de façon aléatoire, en espérant que par je
ne sais pas quelle miracle, il va se mettre à marcher.
Cool, Raoul.
J'espère ne jamais avoir à utiliser un programme que tu as écrit.
Dieu m'en préserve également, ce serait un grand honneur pour moi,
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?
Il faudrait bien en effet savoir exactement le contexte. Parce que je
ne peux pas croire que le compilateur ôte systèmatiquement de telles
variables. Comme j'ai écris par ailleurs, ça fait partie d'un idiome
consacré (RAII), décrit dans prèsque tous les textes C++.
S'il a un mechanisme de trace (fortement conseillé pour tout sauf les
programmes les plus petits), il n'a que l'activer. S'il n'en a pas, il
pourrait penser d'y en ajouter un. Et en attendant, des sorties vers
std::cerr permet d'avancer -- est-ce que le constructeur est réelement
appelé ? Sinon, est-ce qu'on passe par le code où la variable est
déclarée ; si oui, est-ce que l'essai de changer le répertoire a
réussi@? (A priori, s'il y a eu un échec lors de l'essai de changer le
répertoire, une erreur aurait dû être logguée. Sauf qu'il me semble
que Michael a dit une fois qu'il travaille sur des jeux. Un domain
que je ne connais pas, mais où les règles de programmation son bien
différentes que ce que je vois d'habitude. C'est donc peut-être
normal ou acceptable qu'il n'a pas loggué l'erreur -- qu'est-ce qu'on
ferait avec un log d'un programme de jeu ?)
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?
Il faudrait bien en effet savoir exactement le contexte. Parce que je
ne peux pas croire que le compilateur ôte systèmatiquement de telles
variables. Comme j'ai écris par ailleurs, ça fait partie d'un idiome
consacré (RAII), décrit dans prèsque tous les textes C++.
S'il a un mechanisme de trace (fortement conseillé pour tout sauf les
programmes les plus petits), il n'a que l'activer. S'il n'en a pas, il
pourrait penser d'y en ajouter un. Et en attendant, des sorties vers
std::cerr permet d'avancer -- est-ce que le constructeur est réelement
appelé ? Sinon, est-ce qu'on passe par le code où la variable est
déclarée ; si oui, est-ce que l'essai de changer le répertoire a
réussi@? (A priori, s'il y a eu un échec lors de l'essai de changer le
répertoire, une erreur aurait dû être logguée. Sauf qu'il me semble
que Michael a dit une fois qu'il travaille sur des jeux. Un domain
que je ne connais pas, mais où les règles de programmation son bien
différentes que ce que je vois d'habitude. C'est donc peut-être
normal ou acceptable qu'il n'a pas loggué l'erreur -- qu'est-ce qu'on
ferait avec un log d'un programme de jeu ?)
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?
Il faudrait bien en effet savoir exactement le contexte. Parce que je
ne peux pas croire que le compilateur ôte systèmatiquement de telles
variables. Comme j'ai écris par ailleurs, ça fait partie d'un idiome
consacré (RAII), décrit dans prèsque tous les textes C++.
S'il a un mechanisme de trace (fortement conseillé pour tout sauf les
programmes les plus petits), il n'a que l'activer. S'il n'en a pas, il
pourrait penser d'y en ajouter un. Et en attendant, des sorties vers
std::cerr permet d'avancer -- est-ce que le constructeur est réelement
appelé ? Sinon, est-ce qu'on passe par le code où la variable est
déclarée ; si oui, est-ce que l'essai de changer le répertoire a
réussi@? (A priori, s'il y a eu un échec lors de l'essai de changer le
répertoire, une erreur aurait dû être logguée. Sauf qu'il me semble
que Michael a dit une fois qu'il travaille sur des jeux. Un domain
que je ne connais pas, mais où les règles de programmation son bien
différentes que ce que je vois d'habitude. C'est donc peut-être
normal ou acceptable qu'il n'a pas loggué l'erreur -- qu'est-ce qu'on
ferait avec un log d'un programme de jeu ?)
"Mickael Pointier" a écrit dans le message de
news:c5lob5$stc$
Salut,
[snip le reste]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é.
Ca me parait tout a fait normal, à qui ou à quoi s'applique ta fonction
DoSomething ? Est-ce une fonction membre de tbDirectoryChanger, est-ce une
fonction statique ? Je ne le vois pas.
"Mickael Pointier" <mpointier@eden-games.moc> a écrit dans le message de
news:c5lob5$stc$1@aphrodite.grec.isp.9tel.net...
Salut,
[snip le reste]
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é.
Ca me parait tout a fait normal, à qui ou à quoi s'applique ta fonction
DoSomething ? Est-ce une fonction membre de tbDirectoryChanger, est-ce une
fonction statique ? Je ne le vois pas.
"Mickael Pointier" a écrit dans le message de
news:c5lob5$stc$
Salut,
[snip le reste]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é.
Ca me parait tout a fait normal, à qui ou à quoi s'applique ta fonction
DoSomething ? Est-ce une fonction membre de tbDirectoryChanger, est-ce une
fonction statique ? Je ne le vois pas.
Pierre Maurette wrote in message
[...]
il génère:
12 -> mémoire
mémoire -> registre
registre -> mémoire
mémoire -> registre
registre -> mémoire
Ce qui me semble tout à fait normal.
Mais pas à g++ 3.2 (mingw, sous Windows). Il se contente de:
Sur une machine moderne, je m'attendrais aussi à ce que le compilateur
ajoute des barrières d'écriture et de lecture, de façon à s'assurer que
les l'écritures soient bien visibles de l'exterieur, et que les lectures
va réelement chercher au delà de la cache, mais la plupart des
compilateurs ne le font pas.
D'après tes commentaires, j'ai l'impression que vous ne connaissez pas
Je vois que vous hésitez entre le tu et le vous. Je vous autorise l'un
la signification de volatile. Ce qui n'est pas grave en soi -- un
programmeur d'applications n'en a jamais besoin. Mais dans ce cas-là, il
ne faut pas s'en servir n'en plus. Ni en conseiller l'utilisation à
d'autres.
L'amabilité est une seconde nature chez vous.
Il faudrait bien en effet savoir exactement le contexte. Parce que je ne
peux pas croire que le compilateur ôte systèmatiquement de telles
variables. Comme j'ai écris par ailleurs, ça fait partie d'un idiome
consacré (RAII), décrit dans prèsque tous les textes C++.
Dont acte. Je ne pouvais croire le contraire.
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).
Et quoi encore ?
J'aime bien voir le code généré, c'est mon vice, avec les volatiles.
S'il a un mechanisme de trace (fortement conseillé pour tout sauf les
programmes les plus petits), il n'a que l'activer. S'il n'en a pas, il
pourrait penser d'y en ajouter un. Et en attendant, des sorties vers
std::cerr permet d'avancer -- est-ce que le constructeur est réelement
appelé ? Sinon, est-ce qu'on passe par le code où la variable est
déclarée ; si oui, est-ce que l'essai de changer le répertoire a
réussi@? (A priori, s'il y a eu un échec lors de l'essai de changer le
répertoire, une erreur aurait dû être logguée. Sauf qu'il me semble que
Michael a dit une fois qu'il travaille sur des jeux. Un domain que je ne
connais pas, mais où les règles de programmation son bien différentes
que ce que je vois d'habitude. C'est donc peut-être normal ou acceptable
qu'il n'a pas loggué l'erreur -- qu'est-ce qu'on ferait avec un log d'un
programme de jeu ?)
Générer un .asm, alors ?
Pierre Maurette <maurette.pierre@free.fr> wrote in message
[...]
il génère:
12 -> mémoire
mémoire -> registre
registre -> mémoire
mémoire -> registre
registre -> mémoire
Ce qui me semble tout à fait normal.
Mais pas à g++ 3.2 (mingw, sous Windows). Il se contente de:
Sur une machine moderne, je m'attendrais aussi à ce que le compilateur
ajoute des barrières d'écriture et de lecture, de façon à s'assurer que
les l'écritures soient bien visibles de l'exterieur, et que les lectures
va réelement chercher au delà de la cache, mais la plupart des
compilateurs ne le font pas.
D'après tes commentaires, j'ai l'impression que vous ne connaissez pas
Je vois que vous hésitez entre le tu et le vous. Je vous autorise l'un
la signification de volatile. Ce qui n'est pas grave en soi -- un
programmeur d'applications n'en a jamais besoin. Mais dans ce cas-là, il
ne faut pas s'en servir n'en plus. Ni en conseiller l'utilisation à
d'autres.
L'amabilité est une seconde nature chez vous.
Il faudrait bien en effet savoir exactement le contexte. Parce que je ne
peux pas croire que le compilateur ôte systèmatiquement de telles
variables. Comme j'ai écris par ailleurs, ça fait partie d'un idiome
consacré (RAII), décrit dans prèsque tous les textes C++.
Dont acte. Je ne pouvais croire le contraire.
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).
Et quoi encore ?
J'aime bien voir le code généré, c'est mon vice, avec les volatiles.
S'il a un mechanisme de trace (fortement conseillé pour tout sauf les
programmes les plus petits), il n'a que l'activer. S'il n'en a pas, il
pourrait penser d'y en ajouter un. Et en attendant, des sorties vers
std::cerr permet d'avancer -- est-ce que le constructeur est réelement
appelé ? Sinon, est-ce qu'on passe par le code où la variable est
déclarée ; si oui, est-ce que l'essai de changer le répertoire a
réussi@? (A priori, s'il y a eu un échec lors de l'essai de changer le
répertoire, une erreur aurait dû être logguée. Sauf qu'il me semble que
Michael a dit une fois qu'il travaille sur des jeux. Un domain que je ne
connais pas, mais où les règles de programmation son bien différentes
que ce que je vois d'habitude. C'est donc peut-être normal ou acceptable
qu'il n'a pas loggué l'erreur -- qu'est-ce qu'on ferait avec un log d'un
programme de jeu ?)
Générer un .asm, alors ?
Pierre Maurette wrote in message
[...]
il génère:
12 -> mémoire
mémoire -> registre
registre -> mémoire
mémoire -> registre
registre -> mémoire
Ce qui me semble tout à fait normal.
Mais pas à g++ 3.2 (mingw, sous Windows). Il se contente de:
Sur une machine moderne, je m'attendrais aussi à ce que le compilateur
ajoute des barrières d'écriture et de lecture, de façon à s'assurer que
les l'écritures soient bien visibles de l'exterieur, et que les lectures
va réelement chercher au delà de la cache, mais la plupart des
compilateurs ne le font pas.
D'après tes commentaires, j'ai l'impression que vous ne connaissez pas
Je vois que vous hésitez entre le tu et le vous. Je vous autorise l'un
la signification de volatile. Ce qui n'est pas grave en soi -- un
programmeur d'applications n'en a jamais besoin. Mais dans ce cas-là, il
ne faut pas s'en servir n'en plus. Ni en conseiller l'utilisation à
d'autres.
L'amabilité est une seconde nature chez vous.
Il faudrait bien en effet savoir exactement le contexte. Parce que je ne
peux pas croire que le compilateur ôte systèmatiquement de telles
variables. Comme j'ai écris par ailleurs, ça fait partie d'un idiome
consacré (RAII), décrit dans prèsque tous les textes C++.
Dont acte. Je ne pouvais croire le contraire.
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).
Et quoi encore ?
J'aime bien voir le code généré, c'est mon vice, avec les volatiles.
S'il a un mechanisme de trace (fortement conseillé pour tout sauf les
programmes les plus petits), il n'a que l'activer. S'il n'en a pas, il
pourrait penser d'y en ajouter un. Et en attendant, des sorties vers
std::cerr permet d'avancer -- est-ce que le constructeur est réelement
appelé ? Sinon, est-ce qu'on passe par le code où la variable est
déclarée ; si oui, est-ce que l'essai de changer le répertoire a
réussi@? (A priori, s'il y a eu un échec lors de l'essai de changer le
répertoire, une erreur aurait dû être logguée. Sauf qu'il me semble que
Michael a dit une fois qu'il travaille sur des jeux. Un domain que je ne
connais pas, mais où les règles de programmation son bien différentes
que ce que je vois d'habitude. C'est donc peut-être normal ou acceptable
qu'il n'a pas loggué l'erreur -- qu'est-ce qu'on ferait avec un log d'un
programme de jeu ?)
Générer un .asm, alors ?
============= >> 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
simplissime (mais non vide).
[...]
Mon compilo C++ (borland C++ builder) passe tout sans pb (aucun
warning) la variable est bien construite puis détruite.
ça serait étrange que visual studio renferme un bug aussi gros. Un
peu plus de détails sur cette classe et DoSomething nous aiderait...
============= >> 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
simplissime (mais non vide).
[...]
Mon compilo C++ (borland C++ builder) passe tout sans pb (aucun
warning) la variable est bien construite puis détruite.
ça serait étrange que visual studio renferme un bug aussi gros. Un
peu plus de détails sur cette classe et DoSomething nous aiderait...
============= >> 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
simplissime (mais non vide).
[...]
Mon compilo C++ (borland C++ builder) passe tout sans pb (aucun
warning) la variable est bien construite puis détruite.
ça serait étrange que visual studio renferme un bug aussi gros. Un
peu plus de détails sur cette classe et DoSomething nous aiderait...
En clair, si j'écrit ca:
tbDirectoryChanger tbDC;
l'objet est correctement créé et détruit, le chemin mémorisé et restauré.
Si j'écrit ca:
tbDirectoryChanger tbDC("Un chemin quelconque");
l'objet est correctement créé avec le chemin bien modifié puis l'ancien
restauré à la destruction.
Par contre si j'écrit ca:
tbDirectoryChanger tbDC();
j'ai le droit à un message:
warning C4930: 'tbDirectoryChanger tbDC(void)': prototyped function not
called (was a variable definition intended?)
En quoi cette écriture est-elle fausse ? Ca ne revient pas à dire
"utilise le constructeur non paramétré" ? Si quelqu'un pouvait
m'éclairer sur le problème, ca serait cool
En clair, si j'écrit ca:
tbDirectoryChanger tbDC;
l'objet est correctement créé et détruit, le chemin mémorisé et restauré.
Si j'écrit ca:
tbDirectoryChanger tbDC("Un chemin quelconque");
l'objet est correctement créé avec le chemin bien modifié puis l'ancien
restauré à la destruction.
Par contre si j'écrit ca:
tbDirectoryChanger tbDC();
j'ai le droit à un message:
warning C4930: 'tbDirectoryChanger tbDC(void)': prototyped function not
called (was a variable definition intended?)
En quoi cette écriture est-elle fausse ? Ca ne revient pas à dire
"utilise le constructeur non paramétré" ? Si quelqu'un pouvait
m'éclairer sur le problème, ca serait cool
En clair, si j'écrit ca:
tbDirectoryChanger tbDC;
l'objet est correctement créé et détruit, le chemin mémorisé et restauré.
Si j'écrit ca:
tbDirectoryChanger tbDC("Un chemin quelconque");
l'objet est correctement créé avec le chemin bien modifié puis l'ancien
restauré à la destruction.
Par contre si j'écrit ca:
tbDirectoryChanger tbDC();
j'ai le droit à un message:
warning C4930: 'tbDirectoryChanger tbDC(void)': prototyped function not
called (was a variable definition intended?)
En quoi cette écriture est-elle fausse ? Ca ne revient pas à dire
"utilise le constructeur non paramétré" ? Si quelqu'un pouvait
m'éclairer sur le problème, ca serait cool
warning C4930: 'tbDirectoryChanger tbDC(void)': prototyped function
not called (was a variable definition intended?)
En quoi cette écriture est-elle fausse ? Ca ne revient pas à dire
"utilise le constructeur non paramétré" ? Si quelqu'un pouvait
m'éclairer sur le problème, ca serait cool
La forme qui ne fonctionne pas est une declaration de fonction nommee
tbDC sans parametre et retournant un tbDirectoryChanger. Le warning
t'indique que tu declares cette fonction sans jamais l'appeler.
Il faut se souvenir de deux choses:
- quand qqch est interpretable comme declaration de fonction et
definition, c'est la declaration qui prime;
- on peut declarer des fonctions localement.
warning C4930: 'tbDirectoryChanger tbDC(void)': prototyped function
not called (was a variable definition intended?)
En quoi cette écriture est-elle fausse ? Ca ne revient pas à dire
"utilise le constructeur non paramétré" ? Si quelqu'un pouvait
m'éclairer sur le problème, ca serait cool
La forme qui ne fonctionne pas est une declaration de fonction nommee
tbDC sans parametre et retournant un tbDirectoryChanger. Le warning
t'indique que tu declares cette fonction sans jamais l'appeler.
Il faut se souvenir de deux choses:
- quand qqch est interpretable comme declaration de fonction et
definition, c'est la declaration qui prime;
- on peut declarer des fonctions localement.
warning C4930: 'tbDirectoryChanger tbDC(void)': prototyped function
not called (was a variable definition intended?)
En quoi cette écriture est-elle fausse ? Ca ne revient pas à dire
"utilise le constructeur non paramétré" ? Si quelqu'un pouvait
m'éclairer sur le problème, ca serait cool
La forme qui ne fonctionne pas est une declaration de fonction nommee
tbDC sans parametre et retournant un tbDirectoryChanger. Le warning
t'indique que tu declares cette fonction sans jamais l'appeler.
Il faut se souvenir de deux choses:
- quand qqch est interpretable comme declaration de fonction et
definition, c'est la declaration qui prime;
- on peut declarer des fonctions localement.
warning C4930: 'tbDirectoryChanger tbDC(void)': prototyped function
not called (was a variable definition intended?)
En quoi cette écriture est-elle fausse ? Ca ne revient pas à dire
"utilise le constructeur non paramétré" ? Si quelqu'un pouvait
m'éclairer sur le problème, ca serait cool
La forme qui ne fonctionne pas est une declaration de fonction nommee
tbDC sans parametre et retournant un tbDirectoryChanger. Le warning
t'indique que tu declares cette fonction sans jamais l'appeler.
Donc en fait c'est Visual 6 qui ne fait pas les choses correctement.
Il faut se souvenir de deux choses:
- quand qqch est interpretable comme declaration de fonction et
definition, c'est la declaration qui prime;
- on peut declarer des fonctions localement.
Hu ? Je ne savais pas ca.
Quel est l'intérêt de déclarer une fonction locale ???
warning C4930: 'tbDirectoryChanger tbDC(void)': prototyped function
not called (was a variable definition intended?)
En quoi cette écriture est-elle fausse ? Ca ne revient pas à dire
"utilise le constructeur non paramétré" ? Si quelqu'un pouvait
m'éclairer sur le problème, ca serait cool
La forme qui ne fonctionne pas est une declaration de fonction nommee
tbDC sans parametre et retournant un tbDirectoryChanger. Le warning
t'indique que tu declares cette fonction sans jamais l'appeler.
Donc en fait c'est Visual 6 qui ne fait pas les choses correctement.
Il faut se souvenir de deux choses:
- quand qqch est interpretable comme declaration de fonction et
definition, c'est la declaration qui prime;
- on peut declarer des fonctions localement.
Hu ? Je ne savais pas ca.
Quel est l'intérêt de déclarer une fonction locale ???
warning C4930: 'tbDirectoryChanger tbDC(void)': prototyped function
not called (was a variable definition intended?)
En quoi cette écriture est-elle fausse ? Ca ne revient pas à dire
"utilise le constructeur non paramétré" ? Si quelqu'un pouvait
m'éclairer sur le problème, ca serait cool
La forme qui ne fonctionne pas est une declaration de fonction nommee
tbDC sans parametre et retournant un tbDirectoryChanger. Le warning
t'indique que tu declares cette fonction sans jamais l'appeler.
Donc en fait c'est Visual 6 qui ne fait pas les choses correctement.
Il faut se souvenir de deux choses:
- quand qqch est interpretable comme declaration de fonction et
definition, c'est la declaration qui prime;
- on peut declarer des fonctions localement.
Hu ? Je ne savais pas ca.
Quel est l'intérêt de déclarer une fonction locale ???
Quel est l'intérêt de déclarer une fonction locale ?
Quel est l'intérêt de déclarer une fonction locale ?
Quel est l'intérêt de déclarer une fonction locale ?
