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 ...
[...] 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.[...]
Voilà une vision franchement caricaturale de Java.
Le mécanisme de java pour cela, c'est les interfaces, les classes abstraites, les mécanisme de "factory". On peut ne pas apprécier la manière dont ça marche, trouver plein de raisons pour lesquelles cette manière de faire alourdit le code, mais ça existe.
La mode de java aujourd'hui vient bien du fait qu'en se basant là dessus (+ les mécanisme de réflexion) on a trouvé des méthode relativement efficace de gérer des projets un peu gros.
Des méthodes par lesquelles quand les développeurs sont mauvais, le résultat rame, consomme trop de mémoire, a une mauvaise scalabilité, au lieu de planter sauvagement, devenir instable quand on fait développer le même projet un peu gros par de mauvais programmeurs C++.
James Kanze wrote:
On Feb 16, 4:28 pm, MYSELF<mys...@here.com> wrote:
[...] 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.[...]
Voilà une vision franchement caricaturale de Java.
Le mécanisme de java pour cela, c'est les interfaces, les classes
abstraites, les mécanisme de "factory". On peut ne pas apprécier la
manière dont ça marche, trouver plein de raisons pour lesquelles cette
manière de faire alourdit le code, mais ça existe.
La mode de java aujourd'hui vient bien du fait qu'en se basant là dessus
(+ les mécanisme de réflexion) on a trouvé des méthode relativement
efficace de gérer des projets un peu gros.
Des méthodes par lesquelles quand les développeurs sont mauvais, le
résultat rame, consomme trop de mémoire, a une mauvaise scalabilité, au
lieu de planter sauvagement, devenir instable quand on fait développer
le même projet un peu gros par de mauvais programmeurs C++.
[...] 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.[...]
Voilà une vision franchement caricaturale de Java.
Le mécanisme de java pour cela, c'est les interfaces, les classes abstraites, les mécanisme de "factory". On peut ne pas apprécier la manière dont ça marche, trouver plein de raisons pour lesquelles cette manière de faire alourdit le code, mais ça existe.
La mode de java aujourd'hui vient bien du fait qu'en se basant là dessus (+ les mécanisme de réflexion) on a trouvé des méthode relativement efficace de gérer des projets un peu gros.
Des méthodes par lesquelles quand les développeurs sont mauvais, le résultat rame, consomme trop de mémoire, a une mauvaise scalabilité, au lieu de planter sauvagement, devenir instable quand on fait développer le même projet un peu gros par de mauvais programmeurs C++.
espie
In article <go6bmc$dn8$, Jean-Marc Desperrier wrote:
James Kanze wrote: Des méthodes par lesquelles quand les développeurs sont mauvais, le résultat rame, consomme trop de mémoire, a une mauvaise scalabilité, au lieu de planter sauvagement, devenir instable quand on fait développer le même projet un peu gros par de mauvais programmeurs C++.
ce qui constitue une excellente raison de preferer C++: on a des mesures nettement moins "fuzzy" de la qualite d'un logiciel....
In article <go6bmc$dn8$1@writer.imaginet.fr>,
Jean-Marc Desperrier <jmdesp@alussinan.org> wrote:
James Kanze wrote:
Des méthodes par lesquelles quand les développeurs sont mauvais, le
résultat rame, consomme trop de mémoire, a une mauvaise scalabilité, au
lieu de planter sauvagement, devenir instable quand on fait développer
le même projet un peu gros par de mauvais programmeurs C++.
ce qui constitue une excellente raison de preferer C++: on a des mesures
nettement moins "fuzzy" de la qualite d'un logiciel....
In article <go6bmc$dn8$, Jean-Marc Desperrier wrote:
James Kanze wrote: Des méthodes par lesquelles quand les développeurs sont mauvais, le résultat rame, consomme trop de mémoire, a une mauvaise scalabilité, au lieu de planter sauvagement, devenir instable quand on fait développer le même projet un peu gros par de mauvais programmeurs C++.
ce qui constitue une excellente raison de preferer C++: on a des mesures nettement moins "fuzzy" de la qualite d'un logiciel....
Jean-Marc Desperrier
Wykaaa wrote:
[...] C# n'est qu'une copie de Java (avec amélioration de certains de ses défauts les plus flagrants comme le fait que les types de base ne sont pas des classes).
Il y a sensiblement plus que cela de corrigé par rapport à Java.
Par exemple le mot clé « partial » est disponible pour résoudre justement le problème de séparation interface/implémentation (sans passer par les mécanismes de généricité) : http://msdn.microsoft.com/fr-fr/library/wbx7zzdd(VS.80).aspx http://msdn.microsoft.com/fr-fr/library/wa80x488(VS.80).aspx
En fait l'avantage de C# par rapport à java aujourd'hui est qu'il évolue plus vite pour corriger ses défauts.
Et on peut le faire tourner sur d'autres plate-forme, où il se positionne de plus en plus comme un outils de RAD assez sympa : http://www.0xdeadbeef.com/weblog/?p9
Bien évidement, le calcul de Microsoft est que ceux qui l'utilise sous Windows vont se trouver extrêmement facilement portés à utiliser des API qui elles ne sont pas disponibles sur les autres environnement.
Wykaaa wrote:
[...]
C# n'est qu'une copie de Java (avec amélioration de certains de ses
défauts les plus flagrants comme le fait que les types de base ne sont
pas des classes).
Il y a sensiblement plus que cela de corrigé par rapport à Java.
Par exemple le mot clé « partial » est disponible pour résoudre
justement le problème de séparation interface/implémentation (sans
passer par les mécanismes de généricité) :
http://msdn.microsoft.com/fr-fr/library/wbx7zzdd(VS.80).aspx
http://msdn.microsoft.com/fr-fr/library/wa80x488(VS.80).aspx
En fait l'avantage de C# par rapport à java aujourd'hui est qu'il évolue
plus vite pour corriger ses défauts.
Et on peut le faire tourner sur d'autres plate-forme, où il se
positionne de plus en plus comme un outils de RAD assez sympa :
http://www.0xdeadbeef.com/weblog/?p9
Bien évidement, le calcul de Microsoft est que ceux qui l'utilise sous
Windows vont se trouver extrêmement facilement portés à utiliser des API
qui elles ne sont pas disponibles sur les autres environnement.
[...] C# n'est qu'une copie de Java (avec amélioration de certains de ses défauts les plus flagrants comme le fait que les types de base ne sont pas des classes).
Il y a sensiblement plus que cela de corrigé par rapport à Java.
Par exemple le mot clé « partial » est disponible pour résoudre justement le problème de séparation interface/implémentation (sans passer par les mécanismes de généricité) : http://msdn.microsoft.com/fr-fr/library/wbx7zzdd(VS.80).aspx http://msdn.microsoft.com/fr-fr/library/wa80x488(VS.80).aspx
En fait l'avantage de C# par rapport à java aujourd'hui est qu'il évolue plus vite pour corriger ses défauts.
Et on peut le faire tourner sur d'autres plate-forme, où il se positionne de plus en plus comme un outils de RAD assez sympa : http://www.0xdeadbeef.com/weblog/?p9
Bien évidement, le calcul de Microsoft est que ceux qui l'utilise sous Windows vont se trouver extrêmement facilement portés à utiliser des API qui elles ne sont pas disponibles sur les autres environnement.
Wykaaa
Jean-Marc Desperrier a écrit :
Wykaaa wrote:
[...] C# n'est qu'une copie de Java (avec amélioration de certains de ses défauts les plus flagrants comme le fait que les types de base ne sont pas des classes).
Il y a sensiblement plus que cela de corrigé par rapport à Java.
Bien sûr. Je donnais juste un exemple qui montrait que C# avait tiré quelques enseignements des erreurs de conception de Java (mais pas tous...°
Par exemple le mot clé « partial » est disponible pour résoudre justement le problème de séparation interface/implémentation (sans passer par les mécanismes de généricité) : http://msdn.microsoft.com/fr-fr/library/wbx7zzdd(VS.80).aspx http://msdn.microsoft.com/fr-fr/library/wa80x488(VS.80).aspx
En fait l'avantage de C# par rapport à java aujourd'hui est qu'il évolue plus vite pour corriger ses défauts.
Et on peut le faire tourner sur d'autres plate-forme, où il se positionne de plus en plus comme un outils de RAD assez sympa : http://www.0xdeadbeef.com/weblog/?p9
Bien évidement, le calcul de Microsoft est que ceux qui l'utilise sous Windows vont se trouver extrêmement facilement portés à utiliser des API qui elles ne sont pas disponibles sur les autres environnement.
C'est l'éternel malheur avec Microsoft...
Jean-Marc Desperrier a écrit :
Wykaaa wrote:
[...]
C# n'est qu'une copie de Java (avec amélioration de certains de ses
défauts les plus flagrants comme le fait que les types de base ne sont
pas des classes).
Il y a sensiblement plus que cela de corrigé par rapport à Java.
Bien sûr. Je donnais juste un exemple qui montrait que C# avait tiré
quelques enseignements des erreurs de conception de Java (mais pas tous...°
Par exemple le mot clé « partial » est disponible pour résoudre
justement le problème de séparation interface/implémentation (sans
passer par les mécanismes de généricité) :
http://msdn.microsoft.com/fr-fr/library/wbx7zzdd(VS.80).aspx
http://msdn.microsoft.com/fr-fr/library/wa80x488(VS.80).aspx
En fait l'avantage de C# par rapport à java aujourd'hui est qu'il évolue
plus vite pour corriger ses défauts.
Et on peut le faire tourner sur d'autres plate-forme, où il se
positionne de plus en plus comme un outils de RAD assez sympa :
http://www.0xdeadbeef.com/weblog/?p9
Bien évidement, le calcul de Microsoft est que ceux qui l'utilise sous
Windows vont se trouver extrêmement facilement portés à utiliser des API
qui elles ne sont pas disponibles sur les autres environnement.
[...] C# n'est qu'une copie de Java (avec amélioration de certains de ses défauts les plus flagrants comme le fait que les types de base ne sont pas des classes).
Il y a sensiblement plus que cela de corrigé par rapport à Java.
Bien sûr. Je donnais juste un exemple qui montrait que C# avait tiré quelques enseignements des erreurs de conception de Java (mais pas tous...°
Par exemple le mot clé « partial » est disponible pour résoudre justement le problème de séparation interface/implémentation (sans passer par les mécanismes de généricité) : http://msdn.microsoft.com/fr-fr/library/wbx7zzdd(VS.80).aspx http://msdn.microsoft.com/fr-fr/library/wa80x488(VS.80).aspx
En fait l'avantage de C# par rapport à java aujourd'hui est qu'il évolue plus vite pour corriger ses défauts.
Et on peut le faire tourner sur d'autres plate-forme, où il se positionne de plus en plus comme un outils de RAD assez sympa : http://www.0xdeadbeef.com/weblog/?p9
Bien évidement, le calcul de Microsoft est que ceux qui l'utilise sous Windows vont se trouver extrêmement facilement portés à utiliser des API qui elles ne sont pas disponibles sur les autres environnement.
