Quel est l'avantage d'utiliser ces fichiers par rapport à d'autres
langages qui ne les utilisent pas ?
Quel est l'avantage d'utiliser ces fichiers par rapport à d'autres
langages qui ne les utilisent pas ?
Quel est l'avantage d'utiliser ces fichiers par rapport à d'autres
langages qui ne les utilisent pas ?
Je me posais une question existencielle, à savoir "à quoi servent
exactement les fichiers .h en C++ ?"
Je sais bien que ce sont les headers et qu'on doit y inscrire les
prototypes des fonctions et méthodes des classes créées, mais je me
pose cette question parce qu'en C-Sharp par exemple, les classes sont
entièrement décrites dans les fichiers .cs, et il n'y a pas de
fichiers .h (à ce que je sache).
Il y a aussi d'autres langages tels que Java où on se passe fort bien
de fichiers .h.
D'où ma question : "A quoi servent exactement les fichiers .h en C++ ?"
Quel est l'avantage d'utiliser ces fichiers par rapport à d'autres
langages qui ne les utilisent pas ? Parce que j'imagine que si on les
a créés, c'est bien pour une raison ...
Je me posais une question existencielle, à savoir "à quoi servent
exactement les fichiers .h en C++ ?"
Je sais bien que ce sont les headers et qu'on doit y inscrire les
prototypes des fonctions et méthodes des classes créées, mais je me
pose cette question parce qu'en C-Sharp par exemple, les classes sont
entièrement décrites dans les fichiers .cs, et il n'y a pas de
fichiers .h (à ce que je sache).
Il y a aussi d'autres langages tels que Java où on se passe fort bien
de fichiers .h.
D'où ma question : "A quoi servent exactement les fichiers .h en C++ ?"
Quel est l'avantage d'utiliser ces fichiers par rapport à d'autres
langages qui ne les utilisent pas ? Parce que j'imagine que si on les
a créés, c'est bien pour une raison ...
Je me posais une question existencielle, à savoir "à quoi servent
exactement les fichiers .h en C++ ?"
Je sais bien que ce sont les headers et qu'on doit y inscrire les
prototypes des fonctions et méthodes des classes créées, mais je me
pose cette question parce qu'en C-Sharp par exemple, les classes sont
entièrement décrites dans les fichiers .cs, et il n'y a pas de
fichiers .h (à ce que je sache).
Il y a aussi d'autres langages tels que Java où on se passe fort bien
de fichiers .h.
D'où ma question : "A quoi servent exactement les fichiers .h en C++ ?"
Quel est l'avantage d'utiliser ces fichiers par rapport à d'autres
langages qui ne les utilisent pas ? Parce que j'imagine que si on les
a créés, c'est bien pour une raison ...
Je me posais une question existencielle, à savoir "à quoi
servent exactement les fichiers .h en C++ ?"
Je sais bien que ce sont les headers et qu'on doit y inscrire
les prototypes des fonctions et méthodes des classes créées,
mais je me pose cette question parce qu'en C-Sharp par
exemple, les classes sont entièrement décrites dans les
fichiers .cs, et il n'y a pas de fichiers .h (à ce que je
sache). Il y a aussi d'autres langages tels que Java où on se
passe fort bien de fichiers .h.
D'où ma question : "A quoi servent exactement les fichiers .h
en C++ ?"
Quel est l'avantage d'utiliser ces fichiers par rapport à
d'autres langages qui ne les utilisent pas ? Parce que
j'imagine que si on les a créés, c'est bien pour une raison
...
Je me posais une question existencielle, à savoir "à quoi
servent exactement les fichiers .h en C++ ?"
Je sais bien que ce sont les headers et qu'on doit y inscrire
les prototypes des fonctions et méthodes des classes créées,
mais je me pose cette question parce qu'en C-Sharp par
exemple, les classes sont entièrement décrites dans les
fichiers .cs, et il n'y a pas de fichiers .h (à ce que je
sache). Il y a aussi d'autres langages tels que Java où on se
passe fort bien de fichiers .h.
D'où ma question : "A quoi servent exactement les fichiers .h
en C++ ?"
Quel est l'avantage d'utiliser ces fichiers par rapport à
d'autres langages qui ne les utilisent pas ? Parce que
j'imagine que si on les a créés, c'est bien pour une raison
...
Je me posais une question existencielle, à savoir "à quoi
servent exactement les fichiers .h en C++ ?"
Je sais bien que ce sont les headers et qu'on doit y inscrire
les prototypes des fonctions et méthodes des classes créées,
mais je me pose cette question parce qu'en C-Sharp par
exemple, les classes sont entièrement décrites dans les
fichiers .cs, et il n'y a pas de fichiers .h (à ce que je
sache). Il y a aussi d'autres langages tels que Java où on se
passe fort bien de fichiers .h.
D'où ma question : "A quoi servent exactement les fichiers .h
en C++ ?"
Quel est l'avantage d'utiliser ces fichiers par rapport à
d'autres langages qui ne les utilisent pas ? Parce que
j'imagine que si on les a créés, c'est bien pour une raison
...
On Feb 16, 4:28 pm, MYSELF wrote:Je me posais une question existencielle, à savoir "à quoi
servent exactement les fichiers .h en C++ ?"
Dans la pratique, ils servent à implémenter ou émuler des
modules dans d'autres langages.Je sais bien que ce sont les headers et qu'on doit y inscrire
les prototypes des fonctions et méthodes des classes créées,
mais je me pose cette question parce qu'en C-Sharp par
exemple, les classes sont entièrement décrites dans les
fichiers .cs, et il n'y a pas de fichiers .h (à ce que je
sache). Il y a aussi d'autres langages tels que Java où on se
passe fort bien de fichiers .h.
En effet, c'est un défaut majeur de ces langages, qui en rend
l'utilisation problèmmatique dans un projet un peu gros.
En fait, le défaut, ce n'est pas l'absence des fichiers
d'en-tête ; c'est l'absence d'un moyen de séparer
l'implémentation de la spécification en général. Tout compte
fait, l'inclusion textuelle est peut-être le pire moyen de
résoudre le problème (et crée pas mal de problèmes par
ailleurs), mais c'est toujours mieux que pas de solution du
tout. (Pour un exemple d'une bonne solution, voir Modula-2, ou,
je crois, Ada, mais je ne le connais pas bien.)D'où ma question : "A quoi servent exactement les fichiers .h
en C++ ?"Quel est l'avantage d'utiliser ces fichiers par rapport à
d'autres langages qui ne les utilisent pas ? Parce que
j'imagine que si on les a créés, c'est bien pour une raison
...
L'historique diffère de la réalité actuelle. Aujourd'hui, on les
utilise surtout pour similuer la partie spécification d'une
module. Dès que le projet dépasse une certaine taille, il
devient important de maintenir la spécification dans un fichier
à part, séparé des fichiers qui l'implément. Certains langages,
comme Smalltalk, contourne le problème en se passant d'une
spécification complétement -- les vérifications (de type, par
exemple) ne se font qu'à l'exécution. Dans Java, et d'après ce
que je crois comprendre, C#, la spécification est dérivée de
l'implémentation par le compilateur. Ce qui est l'inverse de
ce qu'on veut -- il faut la spécification avant de commencer
l'implémentation (et d'autres doivent pouvoir programmer avec la
spécification, avant qu'elle soit implémentée).
On Feb 16, 4:28 pm, MYSELF <mys...@here.com> wrote:
Je me posais une question existencielle, à savoir "à quoi
servent exactement les fichiers .h en C++ ?"
Dans la pratique, ils servent à implémenter ou émuler des
modules dans d'autres langages.
Je sais bien que ce sont les headers et qu'on doit y inscrire
les prototypes des fonctions et méthodes des classes créées,
mais je me pose cette question parce qu'en C-Sharp par
exemple, les classes sont entièrement décrites dans les
fichiers .cs, et il n'y a pas de fichiers .h (à ce que je
sache). Il y a aussi d'autres langages tels que Java où on se
passe fort bien de fichiers .h.
En effet, c'est un défaut majeur de ces langages, qui en rend
l'utilisation problèmmatique dans un projet un peu gros.
En fait, le défaut, ce n'est pas l'absence des fichiers
d'en-tête ; c'est l'absence d'un moyen de séparer
l'implémentation de la spécification en général. Tout compte
fait, l'inclusion textuelle est peut-être le pire moyen de
résoudre le problème (et crée pas mal de problèmes par
ailleurs), mais c'est toujours mieux que pas de solution du
tout. (Pour un exemple d'une bonne solution, voir Modula-2, ou,
je crois, Ada, mais je ne le connais pas bien.)
D'où ma question : "A quoi servent exactement les fichiers .h
en C++ ?"
Quel est l'avantage d'utiliser ces fichiers par rapport à
d'autres langages qui ne les utilisent pas ? Parce que
j'imagine que si on les a créés, c'est bien pour une raison
...
L'historique diffère de la réalité actuelle. Aujourd'hui, on les
utilise surtout pour similuer la partie spécification d'une
module. Dès que le projet dépasse une certaine taille, il
devient important de maintenir la spécification dans un fichier
à part, séparé des fichiers qui l'implément. Certains langages,
comme Smalltalk, contourne le problème en se passant d'une
spécification complétement -- les vérifications (de type, par
exemple) ne se font qu'à l'exécution. Dans Java, et d'après ce
que je crois comprendre, C#, la spécification est dérivée de
l'implémentation par le compilateur. Ce qui est l'inverse de
ce qu'on veut -- il faut la spécification avant de commencer
l'implémentation (et d'autres doivent pouvoir programmer avec la
spécification, avant qu'elle soit implémentée).
On Feb 16, 4:28 pm, MYSELF wrote:Je me posais une question existencielle, à savoir "à quoi
servent exactement les fichiers .h en C++ ?"
Dans la pratique, ils servent à implémenter ou émuler des
modules dans d'autres langages.Je sais bien que ce sont les headers et qu'on doit y inscrire
les prototypes des fonctions et méthodes des classes créées,
mais je me pose cette question parce qu'en C-Sharp par
exemple, les classes sont entièrement décrites dans les
fichiers .cs, et il n'y a pas de fichiers .h (à ce que je
sache). Il y a aussi d'autres langages tels que Java où on se
passe fort bien de fichiers .h.
En effet, c'est un défaut majeur de ces langages, qui en rend
l'utilisation problèmmatique dans un projet un peu gros.
En fait, le défaut, ce n'est pas l'absence des fichiers
d'en-tête ; c'est l'absence d'un moyen de séparer
l'implémentation de la spécification en général. Tout compte
fait, l'inclusion textuelle est peut-être le pire moyen de
résoudre le problème (et crée pas mal de problèmes par
ailleurs), mais c'est toujours mieux que pas de solution du
tout. (Pour un exemple d'une bonne solution, voir Modula-2, ou,
je crois, Ada, mais je ne le connais pas bien.)D'où ma question : "A quoi servent exactement les fichiers .h
en C++ ?"Quel est l'avantage d'utiliser ces fichiers par rapport à
d'autres langages qui ne les utilisent pas ? Parce que
j'imagine que si on les a créés, c'est bien pour une raison
...
L'historique diffère de la réalité actuelle. Aujourd'hui, on les
utilise surtout pour similuer la partie spécification d'une
module. Dès que le projet dépasse une certaine taille, il
devient important de maintenir la spécification dans un fichier
à part, séparé des fichiers qui l'implément. Certains langages,
comme Smalltalk, contourne le problème en se passant d'une
spécification complétement -- les vérifications (de type, par
exemple) ne se font qu'à l'exécution. Dans Java, et d'après ce
que je crois comprendre, C#, la spécification est dérivée de
l'implémentation par le compilateur. Ce qui est l'inverse de
ce qu'on veut -- il faut la spécification avant de commencer
l'implémentation (et d'autres doivent pouvoir programmer avec la
spécification, avant qu'elle soit implémentée).
L'historique diffère de la réalité actuelle. Aujourd'hui, on les
utilise surtout pour similuer la partie spécification d'une
module. Dès que le projet dépasse une certaine taille, il
devient important de maintenir la spécification dans un fichier
à part, séparé des fichiers qui l'implément. Certains langages,
comme Smalltalk, contourne le problème en se passant d'une
spécification complétement -- les vérifications (de type, par
exemple) ne se font qu'à l'exécution. Dans Java, et d'après ce
que je crois comprendre, C#, la spécification est dérivée de
l'implémentation par le compilateur. Ce qui est l'inverse de
ce qu'on veut -- il faut la spécification avant de commencer
l'implémentation (et d'autres doivent pouvoir programmer avec la
spécification, avant qu'elle soit implémentée).
Merci à tous pour vos réponses.
Je suis juste surpris de voir qu'un langage comme le C#, qui était
censé être "mieux pensé" que le C++ puisque créé plus tard et se
basant -en partie- sur le C++, n'a pas prévu de moyen de gérer cette
spécification à part ...
L'historique diffère de la réalité actuelle. Aujourd'hui, on les
utilise surtout pour similuer la partie spécification d'une
module. Dès que le projet dépasse une certaine taille, il
devient important de maintenir la spécification dans un fichier
à part, séparé des fichiers qui l'implément. Certains langages,
comme Smalltalk, contourne le problème en se passant d'une
spécification complétement -- les vérifications (de type, par
exemple) ne se font qu'à l'exécution. Dans Java, et d'après ce
que je crois comprendre, C#, la spécification est dérivée de
l'implémentation par le compilateur. Ce qui est l'inverse de
ce qu'on veut -- il faut la spécification avant de commencer
l'implémentation (et d'autres doivent pouvoir programmer avec la
spécification, avant qu'elle soit implémentée).
Merci à tous pour vos réponses.
Je suis juste surpris de voir qu'un langage comme le C#, qui était
censé être "mieux pensé" que le C++ puisque créé plus tard et se
basant -en partie- sur le C++, n'a pas prévu de moyen de gérer cette
spécification à part ...
L'historique diffère de la réalité actuelle. Aujourd'hui, on les
utilise surtout pour similuer la partie spécification d'une
module. Dès que le projet dépasse une certaine taille, il
devient important de maintenir la spécification dans un fichier
à part, séparé des fichiers qui l'implément. Certains langages,
comme Smalltalk, contourne le problème en se passant d'une
spécification complétement -- les vérifications (de type, par
exemple) ne se font qu'à l'exécution. Dans Java, et d'après ce
que je crois comprendre, C#, la spécification est dérivée de
l'implémentation par le compilateur. Ce qui est l'inverse de
ce qu'on veut -- il faut la spécification avant de commencer
l'implémentation (et d'autres doivent pouvoir programmer avec la
spécification, avant qu'elle soit implémentée).
Merci à tous pour vos réponses.
Je suis juste surpris de voir qu'un langage comme le C#, qui était
censé être "mieux pensé" que le C++ puisque créé plus tard et se
basant -en partie- sur le C++, n'a pas prévu de moyen de gérer cette
spécification à part ...
Merci à tous pour vos réponses.
Je suis juste surpris de voir qu'un langage comme le C#, qui était
censé être "mieux pensé" que le C++ puisque créé plus tard et se basant
-en partie- sur le C++, n'a pas prévu de moyen de gérer cette
spécification à part ...
Merci à tous pour vos réponses.
Je suis juste surpris de voir qu'un langage comme le C#, qui était
censé être "mieux pensé" que le C++ puisque créé plus tard et se basant
-en partie- sur le C++, n'a pas prévu de moyen de gérer cette
spécification à part ...
Merci à tous pour vos réponses.
Je suis juste surpris de voir qu'un langage comme le C#, qui était
censé être "mieux pensé" que le C++ puisque créé plus tard et se basant
-en partie- sur le C++, n'a pas prévu de moyen de gérer cette
spécification à part ...
In article <gndv0n$4k8$, No_Name wrote:Merci à tous pour vos réponses.
Je suis juste surpris de voir qu'un langage comme le C#, qui était
censé être "mieux pensé" que le C++ puisque créé plus tard et se basant
-en partie- sur le C++, n'a pas prévu de moyen de gérer cette
spécification à part ...
Il ne faut pas croire toute la propagande du departement commercial de
Microsoft.
Si on regarde C#, du point de vue de Microsoft, son principal avantage
c'est de permettre de garder les gens encore un moment sur la plateforme
Windows. Il se presente comme un equivalent de Java, avec une interface
"plus propre" avec le systeme, et plus efficace (le fait que les
implementations Java pondues par microsoft soient subtilement inefficaces
n'est bien sur qu'une coincidence sans rapport). Le danger est bien reel:
si les gens commencent a ecrire du code qui tourne sur toutes les plateformes,
ils risqueraient de se rendre compte qu'ils peuvent vivre loin de Windows,
et qu'ils peuvent utiliser des bases de donnees autres qu'Access.
A cote de ca, il y a un reel effort des equipes "securite" de microsoft pour
faire avancer les choses... y compris en C++. C'est pas pour rien qu'ils
ont embauche Herb Sutter.
Mais F#, l'equivalent fonctionnel de C# au-dessus de la meme machine
virtuelle, avait l'air sensiblement plus interessant...
In article <gndv0n$4k8$1@aioe.org>, No_Name <no_mail@no_mail.com> wrote:
Merci à tous pour vos réponses.
Je suis juste surpris de voir qu'un langage comme le C#, qui était
censé être "mieux pensé" que le C++ puisque créé plus tard et se basant
-en partie- sur le C++, n'a pas prévu de moyen de gérer cette
spécification à part ...
Il ne faut pas croire toute la propagande du departement commercial de
Microsoft.
Si on regarde C#, du point de vue de Microsoft, son principal avantage
c'est de permettre de garder les gens encore un moment sur la plateforme
Windows. Il se presente comme un equivalent de Java, avec une interface
"plus propre" avec le systeme, et plus efficace (le fait que les
implementations Java pondues par microsoft soient subtilement inefficaces
n'est bien sur qu'une coincidence sans rapport). Le danger est bien reel:
si les gens commencent a ecrire du code qui tourne sur toutes les plateformes,
ils risqueraient de se rendre compte qu'ils peuvent vivre loin de Windows,
et qu'ils peuvent utiliser des bases de donnees autres qu'Access.
A cote de ca, il y a un reel effort des equipes "securite" de microsoft pour
faire avancer les choses... y compris en C++. C'est pas pour rien qu'ils
ont embauche Herb Sutter.
Mais F#, l'equivalent fonctionnel de C# au-dessus de la meme machine
virtuelle, avait l'air sensiblement plus interessant...
In article <gndv0n$4k8$, No_Name wrote:Merci à tous pour vos réponses.
Je suis juste surpris de voir qu'un langage comme le C#, qui était
censé être "mieux pensé" que le C++ puisque créé plus tard et se basant
-en partie- sur le C++, n'a pas prévu de moyen de gérer cette
spécification à part ...
Il ne faut pas croire toute la propagande du departement commercial de
Microsoft.
Si on regarde C#, du point de vue de Microsoft, son principal avantage
c'est de permettre de garder les gens encore un moment sur la plateforme
Windows. Il se presente comme un equivalent de Java, avec une interface
"plus propre" avec le systeme, et plus efficace (le fait que les
implementations Java pondues par microsoft soient subtilement inefficaces
n'est bien sur qu'une coincidence sans rapport). Le danger est bien reel:
si les gens commencent a ecrire du code qui tourne sur toutes les plateformes,
ils risqueraient de se rendre compte qu'ils peuvent vivre loin de Windows,
et qu'ils peuvent utiliser des bases de donnees autres qu'Access.
A cote de ca, il y a un reel effort des equipes "securite" de microsoft pour
faire avancer les choses... y compris en C++. C'est pas pour rien qu'ils
ont embauche Herb Sutter.
Mais F#, l'equivalent fonctionnel de C# au-dessus de la meme machine
virtuelle, avait l'air sensiblement plus interessant...
A cote de ca, il y a un reel effort des equipes "securite" de microsoft pour
faire avancer les choses... y compris en C++. C'est pas pour rien qu'ils
ont embauche Herb Sutter.
A cote de ca, il y a un reel effort des equipes "securite" de microsoft pour
faire avancer les choses... y compris en C++. C'est pas pour rien qu'ils
ont embauche Herb Sutter.
A cote de ca, il y a un reel effort des equipes "securite" de microsoft pour
faire avancer les choses... y compris en C++. C'est pas pour rien qu'ils
ont embauche Herb Sutter.
No_Name writes:
>> L'historique diffère de la réalité actuelle. Aujourd'hui,
>> on les utilise surtout pour similuer la partie
>> spécification d'une module. Dès que le projet dépasse une
>> certaine taille, il devient important de maintenir la
>> spécification dans un fichier à part, séparé des fichiers
>> qui l'implément. Certains langages, comme Smalltalk,
>> contourne le problème en se passant d'une spécification
>> complétement -- les vérifications (de type, par exemple) ne
>> se font qu'à l'exécution. Dans Java, et d'après ce que je
>> crois comprendre, C#, la spécification est dérivée de
>> l'implémentation par le compilateur. Ce qui est l'inverse
>> de ce qu'on veut -- il faut la spécification avant de
>> commencer l'implémentation (et d'autres doivent pouvoir
>> programmer avec la spécification, avant qu'elle soit
>> implémentée).
> Merci à tous pour vos réponses.
> Je suis juste surpris de voir qu'un langage comme le C#, qui
> était censé être "mieux pensé" que le C++ puisque créé plus
> tard et se basant -en partie- sur le C++, n'a pas prévu de
> moyen de gérer cette spécification à part ...
Il est vrai qu'avec une approche de haut-en-bas, on veut
écrire l'interface avant d'écrire l'implémentation (et même
dans le cas de modules compliqués, on peut écrire une
implémentation bidon permettant de tester les modules clients
avant d'avoir fini l'implémentation définitive).
Mais ceci n'empêche pas à priori de définir l'interface dans
le même source que l'implémentation, et d'utiliser des outils
pour en extraire la synthèse, tant que le source peut se
"compiler" sans l'implémentation.
C'est à dire que ça ne me choquerait pas de voir un source
contenant:
void Module1_initialize(const char* initparameter)
/*
Documentation de la fonction...
*/
{
NOT_IMPLEMENTED_YET();
}
int Module1_function42(float x,int y){
/*
Documentation de la fonction...
*/
NOT_IMPLEMENTED_YET();
return(0);
}
et de générer automatiquement le fichier entête et la
documentation à partir de ce source. C'est ce qui est fait en
Java.
C'est en fait exactement comme celà que je procédais quand je
programmais encore en C (et dans ma programmation C++
actuelle, les fichiers entêtes sont en fait entièrement
générés par Objecteering). Dans certains projets, même les
fichiers d'exemple de configuration et la documentation
utilisateur étaient générés à partir du source.
Le gros avantage étant de concentrer en un seul endroit toutes
les informations sur une fonction.
Sans celà, quand on modifie l'interface d'une fonction il faut
toucher à trois fichiers (entête, source, documentation), ce
qui n'est jamais fait dans l'urgence et on se retrouve avec
des incohérences et des documentations pas à jour.
No_Name <no_mail@no_mail.com> writes:
>> L'historique diffère de la réalité actuelle. Aujourd'hui,
>> on les utilise surtout pour similuer la partie
>> spécification d'une module. Dès que le projet dépasse une
>> certaine taille, il devient important de maintenir la
>> spécification dans un fichier à part, séparé des fichiers
>> qui l'implément. Certains langages, comme Smalltalk,
>> contourne le problème en se passant d'une spécification
>> complétement -- les vérifications (de type, par exemple) ne
>> se font qu'à l'exécution. Dans Java, et d'après ce que je
>> crois comprendre, C#, la spécification est dérivée de
>> l'implémentation par le compilateur. Ce qui est l'inverse
>> de ce qu'on veut -- il faut la spécification avant de
>> commencer l'implémentation (et d'autres doivent pouvoir
>> programmer avec la spécification, avant qu'elle soit
>> implémentée).
> Merci à tous pour vos réponses.
> Je suis juste surpris de voir qu'un langage comme le C#, qui
> était censé être "mieux pensé" que le C++ puisque créé plus
> tard et se basant -en partie- sur le C++, n'a pas prévu de
> moyen de gérer cette spécification à part ...
Il est vrai qu'avec une approche de haut-en-bas, on veut
écrire l'interface avant d'écrire l'implémentation (et même
dans le cas de modules compliqués, on peut écrire une
implémentation bidon permettant de tester les modules clients
avant d'avoir fini l'implémentation définitive).
Mais ceci n'empêche pas à priori de définir l'interface dans
le même source que l'implémentation, et d'utiliser des outils
pour en extraire la synthèse, tant que le source peut se
"compiler" sans l'implémentation.
C'est à dire que ça ne me choquerait pas de voir un source
contenant:
void Module1_initialize(const char* initparameter)
/*
Documentation de la fonction...
*/
{
NOT_IMPLEMENTED_YET();
}
int Module1_function42(float x,int y){
/*
Documentation de la fonction...
*/
NOT_IMPLEMENTED_YET();
return(0);
}
et de générer automatiquement le fichier entête et la
documentation à partir de ce source. C'est ce qui est fait en
Java.
C'est en fait exactement comme celà que je procédais quand je
programmais encore en C (et dans ma programmation C++
actuelle, les fichiers entêtes sont en fait entièrement
générés par Objecteering). Dans certains projets, même les
fichiers d'exemple de configuration et la documentation
utilisateur étaient générés à partir du source.
Le gros avantage étant de concentrer en un seul endroit toutes
les informations sur une fonction.
Sans celà, quand on modifie l'interface d'une fonction il faut
toucher à trois fichiers (entête, source, documentation), ce
qui n'est jamais fait dans l'urgence et on se retrouve avec
des incohérences et des documentations pas à jour.
No_Name writes:
>> L'historique diffère de la réalité actuelle. Aujourd'hui,
>> on les utilise surtout pour similuer la partie
>> spécification d'une module. Dès que le projet dépasse une
>> certaine taille, il devient important de maintenir la
>> spécification dans un fichier à part, séparé des fichiers
>> qui l'implément. Certains langages, comme Smalltalk,
>> contourne le problème en se passant d'une spécification
>> complétement -- les vérifications (de type, par exemple) ne
>> se font qu'à l'exécution. Dans Java, et d'après ce que je
>> crois comprendre, C#, la spécification est dérivée de
>> l'implémentation par le compilateur. Ce qui est l'inverse
>> de ce qu'on veut -- il faut la spécification avant de
>> commencer l'implémentation (et d'autres doivent pouvoir
>> programmer avec la spécification, avant qu'elle soit
>> implémentée).
> Merci à tous pour vos réponses.
> Je suis juste surpris de voir qu'un langage comme le C#, qui
> était censé être "mieux pensé" que le C++ puisque créé plus
> tard et se basant -en partie- sur le C++, n'a pas prévu de
> moyen de gérer cette spécification à part ...
Il est vrai qu'avec une approche de haut-en-bas, on veut
écrire l'interface avant d'écrire l'implémentation (et même
dans le cas de modules compliqués, on peut écrire une
implémentation bidon permettant de tester les modules clients
avant d'avoir fini l'implémentation définitive).
Mais ceci n'empêche pas à priori de définir l'interface dans
le même source que l'implémentation, et d'utiliser des outils
pour en extraire la synthèse, tant que le source peut se
"compiler" sans l'implémentation.
C'est à dire que ça ne me choquerait pas de voir un source
contenant:
void Module1_initialize(const char* initparameter)
/*
Documentation de la fonction...
*/
{
NOT_IMPLEMENTED_YET();
}
int Module1_function42(float x,int y){
/*
Documentation de la fonction...
*/
NOT_IMPLEMENTED_YET();
return(0);
}
et de générer automatiquement le fichier entête et la
documentation à partir de ce source. C'est ce qui est fait en
Java.
C'est en fait exactement comme celà que je procédais quand je
programmais encore en C (et dans ma programmation C++
actuelle, les fichiers entêtes sont en fait entièrement
générés par Objecteering). Dans certains projets, même les
fichiers d'exemple de configuration et la documentation
utilisateur étaient générés à partir du source.
Le gros avantage étant de concentrer en un seul endroit toutes
les informations sur une fonction.
Sans celà, quand on modifie l'interface d'une fonction il faut
toucher à trois fichiers (entête, source, documentation), ce
qui n'est jamais fait dans l'urgence et on se retrouve avec
des incohérences et des documentations pas à jour.
On Feb 17, 11:10 am, (Pascal J. Bourguignon)
wrote:
C'est en fait exactement comme celà que je procédais quand je
programmais encore en C (et dans ma programmation C++
actuelle, les fichiers entêtes sont en fait entièrement
générés par Objecteering). Dans certains projets, même les
fichiers d'exemple de configuration et la documentation
utilisateur étaient générés à partir du source.
C'est plutôt faire des choses à l'inverse. Et ça ne marche que
sur des petits projets -- dans les grosses applications où j'ai
travaillé, ce n'était pas la même personne qui était responsable
des spécifications et des implémentations.
Une solution, évidemment (que ce soit du Java ou du C++), c'est
de définir les spécifications dans un langage de conception
(UML) ou de spécification de l'interface (Corba), et puis
générer les fichiers automatiquement.Le gros avantage étant de concentrer en un seul endroit toutes
les informations sur une fonction.
Ce qui est précisement ce qu'on veut éviter.Sans celà, quand on modifie l'interface d'une fonction il faut
toucher à trois fichiers (entête, source, documentation), ce
qui n'est jamais fait dans l'urgence et on se retrouve avec
des incohérences et des documentations pas à jour.
Quand on modifie l'interface d'une classe, il faut en général
toucher à des centaines de fichiers -- tous les clients. C'est
la raison principale pour les garder séparées ; pour ne pas les
modifier inopinement.
On Feb 17, 11:10 am, p...@informatimago.com (Pascal J. Bourguignon)
wrote:
C'est en fait exactement comme celà que je procédais quand je
programmais encore en C (et dans ma programmation C++
actuelle, les fichiers entêtes sont en fait entièrement
générés par Objecteering). Dans certains projets, même les
fichiers d'exemple de configuration et la documentation
utilisateur étaient générés à partir du source.
C'est plutôt faire des choses à l'inverse. Et ça ne marche que
sur des petits projets -- dans les grosses applications où j'ai
travaillé, ce n'était pas la même personne qui était responsable
des spécifications et des implémentations.
Une solution, évidemment (que ce soit du Java ou du C++), c'est
de définir les spécifications dans un langage de conception
(UML) ou de spécification de l'interface (Corba), et puis
générer les fichiers automatiquement.
Le gros avantage étant de concentrer en un seul endroit toutes
les informations sur une fonction.
Ce qui est précisement ce qu'on veut éviter.
Sans celà, quand on modifie l'interface d'une fonction il faut
toucher à trois fichiers (entête, source, documentation), ce
qui n'est jamais fait dans l'urgence et on se retrouve avec
des incohérences et des documentations pas à jour.
Quand on modifie l'interface d'une classe, il faut en général
toucher à des centaines de fichiers -- tous les clients. C'est
la raison principale pour les garder séparées ; pour ne pas les
modifier inopinement.
On Feb 17, 11:10 am, (Pascal J. Bourguignon)
wrote:
C'est en fait exactement comme celà que je procédais quand je
programmais encore en C (et dans ma programmation C++
actuelle, les fichiers entêtes sont en fait entièrement
générés par Objecteering). Dans certains projets, même les
fichiers d'exemple de configuration et la documentation
utilisateur étaient générés à partir du source.
C'est plutôt faire des choses à l'inverse. Et ça ne marche que
sur des petits projets -- dans les grosses applications où j'ai
travaillé, ce n'était pas la même personne qui était responsable
des spécifications et des implémentations.
Une solution, évidemment (que ce soit du Java ou du C++), c'est
de définir les spécifications dans un langage de conception
(UML) ou de spécification de l'interface (Corba), et puis
générer les fichiers automatiquement.Le gros avantage étant de concentrer en un seul endroit toutes
les informations sur une fonction.
Ce qui est précisement ce qu'on veut éviter.Sans celà, quand on modifie l'interface d'une fonction il faut
toucher à trois fichiers (entête, source, documentation), ce
qui n'est jamais fait dans l'urgence et on se retrouve avec
des incohérences et des documentations pas à jour.
Quand on modifie l'interface d'une classe, il faut en général
toucher à des centaines de fichiers -- tous les clients. C'est
la raison principale pour les garder séparées ; pour ne pas les
modifier inopinement.