Discussion :

[gl]

Par contre pour ça je ne suis pas d'accord, mais pas du tout. Car déjà si tu n'as à ta disposition que le code source .java tu peux le transformer en .h avec un petit "collapse all" de ton IDE. Et "normalement" (dans un monde où tout le monde a pris le temps de documenter son code) tu as la petite Javadoc associée qui va bien

C'est un petit peu plus compliquer que ça.

Avec collapse all, tu vas voir tout ce qu'il y a dans ton implémentation. Alors que dans le .h tu ne peux exposer qu'une partie de ce contenu, ce qui permet d'organiser les header en fonction du public cible et notamment d'avoir des .h ne comportant que l'interface publique.

[Invité]

Hello world je vous lis pendant la pause café. J'ai sans doute mis suffisamment le souk dans vos têtes bien faites. Je suis vraisemblablement plus attaché à l'aspect business... Certains projets complètement pourris dont plus personne ne veut peuvent être des opportunités fantastiques, on arrive sur un code patché de partout , plein de rustines douteuses, de bugs irrattrapables que les users contournent quotidiennement.
C'est pourquoi je n'ai aucune sévérité sur ce qu'est devenu le couple C/C++. Ca me rappelle les fois ou des équipes de hautes volée ont fait "ce qu'elle pouvaient".
Ca mérite des critiques mais ça fait réfléchir sur les langages plus récents et la reditribution des cartes qu'ils ont permis aux éditeurs. Eux par contre, ont continué avec C(++) ce qui leur a permis de ne pas être concurrencés par les autres. Dans ces cas là : plus c'est pourri, plus c'est intéressant

[S(ô.Ô)B]

Mais ce n'est ni plus ni moins que le même problème que celui du choix des noms (de méthodes, variables).

Si tu tombes sur une méthode equal() tu t'attends à ce qu'elle fasse un test d'égalité. Si finalement elle fait tout à fait autre chose, tu vas être surpris et estimer (à juste titre à mon avis) que celui qui l'a faite est un imbécile.
C'est pareil pour la surcharge d'un opérateur, si l'opérateur surchargé n'a pas une sémantique logique et s'éloigne du fonctionnement des opérateurs de base c'est que le choix de cet opérateur n'était clairement pas bon, mais cela ne remet pas, à mon sens, en cause la surcharge des opérateurs.

Et à titre personnel, je trouve bien plus logique d'utiliser les opérateurs de comparaison pour faire une comparaison, l'opérateur d'affectation pour faire une affectation, etc. que d'appeler une fonction quelconque.

Oui je suis d'accord mais personnellement je fais (à tort ?) une confiance aveugle aux opérateurs de base, et donc si jamais il y a un problème dans mon code dont je ne trouve pas la cause je ne suis pas sûr que je soupçonnerai le == surchargé que j'utilise. Alors qu'avec equal() tu vois bien que c'est une méthode et j'en viendrai plus facilement à soupçonner le code de cette méthode.

Après c'est sûr que si les opérateurs surchargés ne comportent jamais de bug, là je te suis totalement d'accord avec toi, malheureusement...

[pseudocode]

Et à titre personnel, je trouve bien plus logique d'utiliser les opérateurs de comparaison pour faire une comparaison, l'opérateur d'affectation pour faire une affectation, etc. que d'appeler une fonction quelconque.

Je ne remet pas en cause la possibilité de pouvoir définir un nouvel opérateur sur une classe. Ce qui me dérange c'est de pouvoir redéfinir un opérateur de base du langage, qui à donc une signification connue par tous.

Tout comme redéfinir les mots clés "for", "if", "return" ou les symboles "*", "->" ou "&" me semble certes très puissant, mais aussi très sujet à risque.

[atttchoum]

Et pour vous, quel est le défaut le plus gênant du C++ ?

d'abord une bibliothèque standard vraiment trop réduite mais surtout une documentation tout simplement misérable pour une librairie qui sera utilisé par tout les développeur c++ a un moment ou à un autre.

sinon l'ajout de librairies extérieurs est parfois vraiment complexe.

[Davidbrcz]

Je ne remet pas en cause la possibilité de pouvoir définir un nouvel opérateur sur une classe. Ce qui me dérange c'est de pouvoir redéfinir un opérateur de base du langage, qui à donc une signification connue par tous.

Tout comme redéfinir les mots clés "for", "if", "return" ou les symboles "*", "->" ou "&" me semble certes très puissant, mais aussi très sujet à risque.

Oula !
Il est impossible de redefinir les operateurs sur les types primitifs ou den creer de nouveau. Si tu creer un operateur == pour une classe A, tu ne vas pas magiquement en avoir un pour une classe B.

Par ailleurs, sur == vs equal, a partir du moment ou tu ne manipule pas un type primitif, tu sais que == est une fonction (il ny a aucune ambiguite possible)

une documentation tout simplement misérable pour une librairie qui sera utilisé par tout les développeur c++ a un moment ou à un autre.

Tu fais quoi de roguewave , SGI, MSDN (partie STL) ?

[koala01]

Je ne remet pas en cause la possibilité de pouvoir définir un nouvel opérateur sur une classe. Ce qui me dérange c'est de pouvoir redéfinir un opérateur de base du langage, qui à donc une signification connue par tous.

Tout comme redéfinir les mots clés "for", "if", "return" ou les symboles "*", "->" ou "&" me semble certes très puissant, mais aussi très sujet à risque.

Attention, quand même...

Il est vrai que les opérateurs ont tous leur sémantique propre, et peuvent être regroupés par "catégorie"

• +,-,*,/,+=,-=,*=,/=, ++, -- opérateurs mathématiques
• <,>,<=,>=,== opérateur de comparaison
• &,*,-> opérateurs d'accès

Ces opérateurs ne peuvent, de toute manière, être appelés que s'ils sont valablement définis pour un type particulier.

C'est au développeur qui décide de les définir de veiller à ce qu'ils gardent leur sémantique propre

l'étoile (prise dans sa sémantique d'opérateur d'accès) et la flèche ne seront, par exemple, utilisés que dans le cadre d'une classe encapsulant une valeur à laquelle on souhaite accéder

La seule exception que je connaisse au principe de garder une sémantique identique est celle de boost::serialize qui utilise l'opérateur & dans une sémantique qui n'est pas habituelle.

Mais l'approche de cette bibliothèque est sensée et clairement documentée, ce qui fait que, bien que l'esperluette ne soit pas utilisée avec sa sémantique habituelle, cela ne me pose pas de problème philosophique majeur

[alexis b]

a partir du moment ou tu ne manipule pas un type primitif, tu sais que == est une fonction

C'est ce qui s'appelle, la surcharge des opérateurs ! Je l'utilise et c'est très pratique .

[jblecanard]

C'est ce qui s'appelle, la surcharge des opérateurs ! Je l'utilise et c'est très pratique .

Toi tu n'as pas lu tous les posts

[Invité]

C++ est un langage que je trouve très bien fait et qui respecte à la lettre ses principes de bases (on ne paye pas pour ce qu'on utilise pas).

Les problèmes :
- pas de système de module, inclusion textuelle pas toujours pertinente

- très dur à parser

- productivité mauvaise (ça se discute évidemment)

J'aime bien ce message (cliquer la flèche pour lire la citation)car il suggère beaucoup de situations sans les lister toutes...
Pour le parser, on arrive en C++ à la même situation que dans un code php/html/javascript car l'évolution de ces deux technos a été historiquement voisine : impossible de réécrire les standards initiaux sans mettre la moitié du monde en panne !

le parallèle s'arrète là car les effets de précédence décrits sont liés à la compilation alors que les interpréteurs du monde web autorisent une infinité d'encapsulations. D'autre part il est assez incongru de faire un générateur de code compilé dépendant du contexte, à moins d'embarquer un compilateur dans l'application. Je suis particulièrement confronté à ce cas. Je dois embarquer un compilateur, hormis les problèmes de droit (qui ne me laissent pas de choix sur le langage ), c'est une aventure technique très particulière. Heureusement, je suis devenu (tardivement)fan des expressions régulières!!

[hiura]

hum... Meme si Java a des défauts, faut quand meme pas en rajouter. Critiquer autant la librairie standard de Java, c'est un peu "too much", sachant que l'une des premières choses qu'on fait généralement quand on débute un projet d'envergure en C++ c'est de se choisir une bonne librairie additionnelle.

Ce n'est pas «too much», pas avec ma petite histoire d'amour avec JAVA.

Bon c'est vrai que je suis un peu excessif des fois, raisons personnelles, blablabla, on s'en fiche! Mais quand je vois la difficulté que j'ai eu à m'adapter à JAVA et son API pour un petit projet (j'abrège parce que c'est franchement pas passionnant, mais pour les curieux voici plus d'info) alors qu'avec le C++ j'aurais rencontrer moins de difficultés. (Certains diront que c'est une question d'expérience. Je leur répondrai que ce n'est pas tout à fait vrai, pour chaque langage de programmation il y a une façon de penser propre et celle du C++ est plus adaptée à ma personne contrairement à celle de JAVA.)

Pour être franc j'ai encore été gentil avec JAVA dans ces deux posts, si tu savais ce que j'en pensais réellement tu me brûlerais peut-être sur la place public! (Mais ça commence à être hors topic, j'avoue.)

Par contre pour ça je ne suis pas d'accord, mais pas du tout. Car déjà si tu n'as à ta disposition que le code source .java tu peux le transformer en .h avec un petit "collapse all" de ton IDE. Et "normalement" (dans un monde où tout le monde a pris le temps de documenter son code) tu as la petite Javadoc associée qui va bien

C'est sûr que NetBeans, entre autre, est bien conçu, mais que peut-il faire si tu as le code sur une feuille de papier ? Tu me diras que ça arrive pas bien souvent mais quand ça arrive t'es vraiment content d'avoir tes deux fichiers .h(pp)/.c(pp)! (Exemple : à ton examen)

Note que l'argument de la documentation n'est pas très valide puisque en C++ (et de manière générale tout le temps) aussi tu dois documenter mais ce n'est en aucun cas une obligation du langage. Enfin bref.

[hiura]

Hum, et je peux rajouter quand même un point noir au C++ :
Pas de import (au sens Objective-C du terme et non Java qui n'a pas la même utilité).

(En Obj-C, il s'utilise comme include sauf que les anti-inclusion multiple ne sont plus nécessaire.)

[koala01]

Note que l'argument de la documentation n'est pas très valide puisque en C++ (et de manière générale tout le temps) aussi tu dois documenter mais ce n'est en aucun cas une obligation du langage. Enfin bref.

D'autant plus que, dés qu'il y a moyen de mettre des commentaires, il existe sans doute des outils capables d'en extraire tout ou partie pour créer une documentation

Pensez, par exemple, à doxygen

[pseudocode]

Oula !
Il est impossible de redefinir les operateurs sur les types primitifs ou den creer de nouveau. Si tu creer un operateur == pour une classe A, tu ne vas pas magiquement en avoir un pour une classe B.

Même si B hérite de A ?

a partir du moment ou tu ne manipule pas un type primitif, tu sais que == est une fonction (il ny a aucune ambiguite possible)

Tu veux dire que le compilateur génère une erreur si je n'ai pas explicitement overridé l'opérateur ?

C'est au développeur qui décide de les définir de veiller à ce qu'ils gardent leur sémantique propre

C'est justement ma critique personnelle depuis le début. Je préfèrerai que la sémantique des opérateurs présents "de base" soit inaltérable par le programmeur.

Mais bon, a force on va finir par croire que je suis un anti-cplusplussien, alors que j'aime plutôt bien ce langage. Je le trouve juste trop "permissif" a mon gout pour l'utiliser dans un contexte industriel, sans prendre une liste (que je juste trop excessive) de précautions.

Pour être franc j'ai encore été gentil avec JAVA dans ces deux posts, si tu savais ce que j'en pensais réellement tu me brûlerais peut-être sur la place public!

J'ai aussi des critiques a formuler sur Java, mais ce n'est pas le lieu.

[S(ô.Ô)B]

C'est sûr que NetBeans, entre autre, est bien conçu, mais que peut-il faire si tu as le code sur une feuille de papier ? Tu me diras que ça arrive pas bien souvent mais quand ça arrive t'es vraiment content d'avoir tes deux fichiers .h(pp)/.c(pp)! (Exemple : à ton examen)

Note que l'argument de la documentation n'est pas très valide puisque en C++ (et de manière générale tout le temps) aussi tu dois documenter mais ce n'est en aucun cas une obligation du langage. Enfin bref.

En fait pour la doc je voulais dire qu'en Java avec tous les IDE dignes de ce nom on peut regarder la doc d'une méthode ou autre sans pour autant ouvrir la classe correspondante, ce qui n'est par exemple pas possible (à ma connaissance) avec Code::Blocks (que je suis obligé d'utiliser) en C++.

Et sinon il faut brûler les exams papiers en informatique ! (enfin ceux où il faut juste pondre du code)

[Pill_S]

C'est sûr que NetBeans, entre autre, est bien conçu, mais que peut-il faire si tu as le code sur une feuille de papier ? Tu me diras que ça arrive pas bien souvent mais quand ça arrive t'es vraiment content d'avoir tes deux fichiers .h(pp)/.c(pp)! (Exemple : à ton examen)

Note que l'argument de la documentation n'est pas très valide puisque en C++ (et de manière générale tout le temps) aussi tu dois documenter mais ce n'est en aucun cas une obligation du langage. Enfin bref.

C'est quand même formidable de voir le nombre de post qui se plaignent que les interfaces et les implémentations ne sont pas séparées dans des fichiers distincts en java... Notez quand même:

1) on n'a besoin de l'interface que pour des raisons de "documentation" (au sens large), c'est à dire pour comprendre comment utiliser telle ou telle objet... En java il y a la javadoc, très répandue et très pratique, et bien plus claire qu'un fichier .h, sinon il y a les vues "outline" dans les éditeur, qui permettent de filtrer les méthodes statiques et / ou non publiques...
2) il y a sinon la notion d'interface (mot réservé) qui représente quasiment l'équivalent d'un fichier .h, et qui sont également trèèès utilisées.
3) sinon pour c et c++, je ne ferai pas de commentaires, ces 2 technos étant assez obscures pour moi et pas très "human friendly"

Mais par pitié, arrêtez de vous plaindre de l'absence des fichiers .h... pour moi c'est une abberration

[koala01]

Même si B hérite de A ?

Si B hérite de A, on peut, décemment, estimer que la comparaison se fera de manière identique, quitte à ce qu'il y ait redéfinition d'une des fonctions qui intervient dans le processus.

Autrement, c'est plutôt du coté d'un problème de conception qu'il faudra se tourner

Tu veux dire que le compilateur génère une erreur si je n'ai pas explicitement overridé l'opérateur ?

Exactement:

Code C++ :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
#include <iostream>
class MaClass
{
   /* n'importe quoi */
};
int main()
{
    MaClass c1;
    MaClass c2;
    if(c1==c2)
    {
        std::cout<<"c1 et c2 sont identiques"<<std::endl;
    }
}

provoque l'erreur

Code SHELL :

Sélectionner tout - Visualiser dans une fenêtre à part

main.cpp|10|error: no match for 'operator==' in 'c1 == c2'|

C'est justement ma critique personnelle depuis le début. Je préfèrerai que la sémantique des opérateurs présents "de base" soit inaltérable par le programmeur.

Il en va de même pour les fonctions...

Si je nomme une fonction membre "equal" ou "less", l'utilisateur peut, décemment, s'attendre à ce qu'elles effectuent une comparaison entre deux objets.

Si elles ont un autre effet, j'en reste le seul responsable, et c'est que j'ai mal choisi le nom de ma fonction

Si je décide, pour une raison qui m'est propre, de modifier la sémantique d'un opérateur, il m'appartient de choisir effectivement de le faire (à ma charge de motiver et de documenter ma décision) ou non

Je ne vois pas pourquoi on appliquerait aux opérateurs des règles différentes de celles que l'on applique aux fonctions

Mais bon, a force on va finir par croire que je suis un anti-cplusplussien, alors que j'aime plutôt bien ce langage. Je le trouve juste trop "permissif" a mon gout pour l'utiliser dans un contexte industriel, sans prendre une liste (que je juste trop excessive) de précautions.

Ce que tu appelle permissivité, j'aurais tendance à l'appeler libre arbitre.

Tu remarqueras que c'est encore une question de point de vue

[atttchoum]

Tu fais quoi de roguewave , SGI, MSDN (partie STL) ?

je trouve SGI et MSDN très brouillon (enfin j'avoue que j'ai jamais été foutu de comprendre comment MSDN était rangée).
Quand à roguewave, je ne connaissais pas et je découvre en se moment même.

[koala01]

En fait pour la doc je voulais dire qu'en Java avec tous les IDE dignes de ce nom on peut regarder la doc d'une méthode ou autre sans pour autant ouvrir la classe correspondante, ce qui n'est par exemple pas possible (à ma connaissance) avec Code::Blocks (que je suis obligé d'utiliser) en C++.

Encore une fois, tu confonds les possibilités du langage avec celles des outils que tu utilises.

D'autres outils, comme Visual Studio ou Borland (après tout, il m'est déjà suffisamment arrivé de les dénigrer pour d'autres raisons pour pouvoir les encenser un peu ) intègrent un système d'aide des plus efficaces, et ce, depuis de nombreuses versions

On pourrait discuter de la politique suivie par les dev de code::block sur le sujet, mais ce n'est pas le lieu

[jblecanard]

2) il y a sinon la notion d'interface (mot réservé) qui représente quasiment l'équivalent d'un fichier .h.

Absolument pas. En java, un seul objet peut adhérer à plusieurs interfaces (c'est l'intérêt d'ailleurs). Pour faire ça en C++, c'est l'héritage multiple et toutes les difficultés qui viennent avec (on a d'autres techniques heureusement). L'interface au sens java et le header en C++ n'ont vraiment rien à voir.

Un petit rappel :
- Il y a doxygen qui fait aussi bien que javadoc pour c++, et c'est gratuit.
- Je préfère largement maintenir de la doc dans un .h et avoir mon implémentation ailleurs que devoir m'occuper en permanence d'un mélange des deux.
- Rien n'empêche de tout implémenter dans ses headers, la séparation est une bonne pratique et en rien une obligation. Ne pas le faire relève de l'hérésie mais c'est possible.