Discussion :

[Quatre_Couleurs]

j'adore ce genre d'affirmation

+1

"Java c'est trop bien et le C++ c'est mort" ça commence à faire mal à la tête...

et +1

[atm0sfe4r]

J'avoue m'être emballé sur le coup, mais difficile de ne pas le faire quand premièrement on entends (enfin on lit plutôt) des choses hallucinantes sur une partie de forum censée être orienté "professionnels", et deuxièmement quand on sait que le C++ est très utilisé dans le domaine de l'imagerie.

Des doutes M. souviron34 ?

[millie]

entreprise d'imagerie médicale -> C++ obligatoire (+ scripts Python mais ça c'est en option).

le C++ est très utilisé dans le domaine de l'imagerie.

Très utilisé ou obligatoire alors ?

La plupart des contributions sur le traitement d'images que l'on a sont en Java et en C, notamment grâce à des API comme ImageJ, JAI, openCV et d'autres.

On voit beaucoup de projet d'imagerie médicale en C++ dû à la présence de Itk, mais c'est loin d'être obligatoire

Et comme d'habitude, les algorithmes en traitement d'images sont nettement plus important que le langage. Un exemple bateau est le filtre médian. Des logiciels en C comme Gimp utilisent de vieux algorithmes absolument par performant alors qu'il y a d'autres logiciels dans des langages a priori moins rapide, qui utilise des algorithmes plus performants et récent et qui explose en terme de performance Gimp.

J'utilise en général Java pour faire du traitement d'images, et la plupart de mes filtres sont rapide (tous les filtres de base sont aussi rapide que sous photoshop et explosent littéralement gimp)

Par contre, les bibliothèques de traitement d'images à haute résolution (>50.000*50.000) sont pas extrêmement développé en Java.

[hcrepin]

Honnêtement, j'ai commencé ma carrière en installant des applications C++ et actuellement, je ne fais plus que du JAVA.

Le JAVA, c'est l'équivalent de Windows, portable, accessible mais souvent mal développé, plein de bugs et gourmand en resosurce en regard des fonctions.

C++, aride, dur à comprendre et à configurer, capricieux et rigide mais très puissant.

A choisir, je prendrais les développements classiques pour leur efficacité, normalement tout ceci est géré par des professionnels et toutes ces jolies consoles et ces brols qui partent dans tous les sens, ça devient vite ingérable et coûteux en matériel.

J'ai géré un SMSC en OpenVMS pendant 6 ans, il fallait, en JAVA, presque la même puissance pour traiter juste ses statistiques, en différé ce que lui faisait en parfait real time plus les gestions de sécurité, de transfert, de queuue, ...

[Furikawari]

Honnêtement, j'ai commencé ma carrière en installant des applications C++ et actuellement, je ne fais plus que du JAVA.

Le JAVA, c'est l'équivalent de Windows, portable, accessible mais souvent mal développé, plein de bugs et gourmand en resosurce en regard des fonctions.

C++, aride, dur à comprendre et à configurer, capricieux et rigide mais très puissant.

A choisir, je prendrais les développements classiques pour leur efficacité, normalement tout ceci est géré par des professionnels et toutes ces jolies consoles et ces brols qui partent dans tous les sens, ça devient vite ingérable et coûteux en matériel.

J'ai géré un SMSC en OpenVMS pendant 6 ans, il fallait, en JAVA, presque la même puissance pour traiter juste ses statistiques, en différé ce que lui faisait en parfait real time plus les gestions de sécurité, de transfert, de queuue, ...

Ca n'est pas aprce que tu as rencontré du mauvais code que le langage est mauvais. Attention aux amalgames...

[Uther]

Certes mais certains langages sont une invitation a faire du mauvais code.

Il n'y a pas beaucoup de fonctionnalité de C++ qui me manquent vraiment en java. Mais la plupart de ces fonctionnalités, sont un gros risque de code moche, dangereux ou prise de tête (goto ,héritage multiple, surcharge des opérateur, risque de débordement, ...)

[Alp]

Certes mais certains langages sont une invitation a faire du mauvais code.

Il n'y a pas beaucoup de fonctionnalité de C++ qui me manquent vraiment en java. Mais la plupart de ces fonctionnalités, sont un gros risque de code moche, dangereux ou prise de tête (goto ,héritage multiple, surcharge des opérateur, risque de débordement, ...)

Je trouve qu'il est facile de balancer des critiques "en l'air" comme tu le fais. Pourrais-tu argumenter ? Quelque chose qui ressemblerait à ce qui suit mais dans le sens opposé

1- goto n'a jamais été recommendé en C++, même pas lors de ses premiers pas, au début des années 80. Il est là par soucis de compatibilité avec le peu de développeur C qui s'en servent.

2- l'héritage multiple n'est pas une mauvaise chose. Mais c'est comme pour tout, pas uniquement dans l'informatique : si tu veux utiliser quelque chose, apprends à t'en servir.

3- La surcharge des opérateurs est une excellente chose, et c'est même encore plus poussé en OCaml ou Haskell où l'on peut définir des opérateurs entièrement nouveaux. Cela rend le code plus clair, plus agréable à lire et souvent plus concis. Suffit évidemment de documenter ton nouvel opérateur, mais tu as de toute manière le même genre de chose à faire lorsque tu écris une classe ou une fonction.

4- Par risque de débordement, tu sous-entends ... quoi ?

[Furikawari]

Je trouve qu'il est facile de balancer des critiques "en l'air" comme tu le fais. Pourrais-tu argumenter ? Quelque chose qui ressemblerait à ce qui suit mais dans le sens opposé

1- goto n'a jamais été recommendé en C++, même pas lors de ses premiers pas, au début des années 80. Il est là par soucis de compatibilité avec le peu de développeur C qui s'en servent.

2- l'héritage multiple n'est pas une mauvaise chose. Mais c'est comme pour tout, pas uniquement dans l'informatique : si tu veux utiliser quelque chose, apprends à t'en servir.

3- La surcharge des opérateurs est une excellente chose, et c'est même encore plus poussé en OCaml ou Haskell où l'on peut définir des opérateurs entièrement nouveaux. Cela rend le code plus clair, plus agréable à lire et souvent plus concis. Suffit évidemment de documenter ton nouvel opérateur, mais tu as de toute manière le même genre de chose à faire lorsque tu écris une classe ou une fonction.

4- Par risque de débordement, tu sous-entends ... quoi ?

A mon avis on tombe là au coeur du problème entrre pro C++ et pro java.

Grosso modo en java c'est "la fonctionnalité X est trop dangereuse parce qu'un mauvais programmeur pourrait faire de mauvaises choses avec, on la supprime".

En C++ c'est "j'ai vu que dans 0.0000001% des cas cette fonctionnalité peut servir, alors même si dans 99,99999% des cas les gens l'utiliseront mal, je la garde quand même".

[Uther]

Je trouve qu'il est facile de balancer des critiques "en l'air" comme tu le fais. Pourrais-tu argumenter ?

Je ne trouve pas qu'il s'agit de critiques en l'air, certains mécanismes C++ ont volontairement été exclus de Java non pas parce qu'ils étaient inutiles mais que le rapport risque/utilité ou complexité/utilité n'a pas été jugé bon.

1- goto n'a jamais été recommendé en C++, même pas lors de ses premiers pas, au début des années 80. Il est là par soucis de compatibilité avec le peu de développeur C qui s'en servent.

C'est vrai qu'il est peu utilisé. Pourtant, il peut-être bien pratique s'il est utilisé sans abus. Toujours est il qu'il est présent contrairement a beaucoup de langage modernes qui on fait le choix de s'en passer

2- l'héritage multiple n'est pas une mauvaise chose. Mais c'est comme pour tout, pas uniquement dans l'informatique : si tu veux utiliser quelque chose, apprends à t'en servir.

Je n'ai jamais dis que c'était une mauvaise chose mais c'est potentiellement source d'erreur et rarement indispensable(personnellement, ça ne m'a jamais manqué)

3- La surcharge des opérateurs est une excellente chose, et c'est même encore plus poussé en OCaml ou Haskell où l'on peut définir des opérateurs entièrement nouveaux. Cela rend le code plus clair, plus agréable à lire et souvent plus concis. Suffit évidemment de documenter ton nouvel opérateur, mais tu as de toute manière le même genre de chose à faire lorsque tu écris une classe ou une fonction.

Ça peux potentiellement être plus clair c'est vrai. Sur certaines classe Java comme BigInteger, ça peut manquer.
Par contre , j'ai souvent vu des utilisations que je trouve abusives. Pas besoin d'aller chercher loin:

Code :

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

std::cout << "Hello World" << std::endl;

Ca ne choque pas grand monde, mais c'est quand même un bel exemple d'une utilisation que je trouve abusive de la surcharge des opérateurs.On utilise des opérateurs pour faire des actions qui n'ont pas grand chose à voir avec des opérations.

4- Par risque de débordement, tu sous-entends ... quoi ?

C'est vrai que je m'écarte un peu du sujet qui était la clarté du code. La il s'agit plutôt de risque de bug étant donné que les pointeurs/tableaux peuvent potentiellement accéder ailleurs qu'un emplacement mémoire réservé, sans obligatoirement générer d'erreur.

[Luc Hermitte]

[2- héritage multiple]
C'est vrai qu'il est peu utilisé. Pourtant, il peut-être bien pratique s'il est utilisé sans abus. Toujours est il qu'il est présent contrairement a beaucoup de langage modernes qui on fait le choix de s'en passer
Je n'ai jamais dis que c'était une mauvaise chose mais c'est potentiellement source d'erreur et rarement indispensable(personnellement, ça ne m'a jamais manqué)

[3- surcharge opérateurs]
Ça peux potentiellement être plus clair c'est vrai. Sur certaines classe Java comme BigInteger, ça peut manquer.
Par contre , j'ai souvent vu des utilisations que je trouve abusives. Pas besoin d'aller chercher loin:

Code :

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

std::cout << "Hello World" << std::endl;

Ca ne choque pas grand monde, mais c'est quand même un bel exemple d'une utilisation que je trouve abusive de la surcharge des opérateurs.On utilise des opérateurs pour faire des actions qui n'ont pas grand chose à voir avec des opérations.

[4- débordements]
C'est vrai que je m'écarte un peu du sujet qui était la clarté du code. La il s'agit plutôt de risque de bug étant donné que les pointeurs/tableaux peuvent potentiellement accéder ailleurs qu'un emplacement mémoire réservé, sans obligatoirement générer d'erreur.

2- N'aurait-il pas fallu plutôt commencer par interdire l'héritage vu le nombre de personnes qui n'ont pas compris le LSP et dériveront des ListeTriee de Liste? Tant que l'on ne comprend pas le LSP, c'est sûr que les chances de bien utiliser l'héritage multiple sont maigres. Très maigres.
Sinon, de l'héritage multiple, tu en fais avec les interfaces en Java, par contre ces petites roues te privent de la possibilité de faire de la programmation par contrat nativement...

3- Oui, et il faudrait aussi interdire aux développeurs d'appeler handle() une fonction qui exécute une requête...
Tu n'empêcheras jamais aux utilisateurs d'avoir des mauvaises idées en matière de nommage. Et pour tout ceux qui veulent développer des applications scientifiques, les priver de la surcharge des opérateurs est ridicule. Le problème de celle du C++ c'est que l'on est limité dans les opérateurs que l'on peut surcharger et que leurs priorités respectives ne peuvent pas être modifiées. Dans le cadre d'un appel d'offre du DoD (IIRC) Sun avait d'ailleurs proposé un langage où l'on pouvait étendre le langage avec n'importe quel symbole UTF-8 (plus avec une syntaxe textuelle à la LaTeX si me souvenirs sont bons).

4- C'est pour cela que l'on recommande fortement d'oublier les pointeurs et d'utiliser une implémentation checkée de la bibliothèque standard.
Mais ... balancer une exception sur un accès hors borne est une fausse bonne solution. Il faut savoir distinguer l'accès hors borne plausible (car index provenant d'une source externe) de l'erreur de programmation. Là on a besoin de pouvoir stopper l'exécution tout en restant dans le contexte de l'erreur , et les cores sont bien pour ça.
Par contre effectivement il ne faut pas utiliser les artefacts du C, mais ceux du C++. Et on en revient une fois de plus au problème de l'apprentissage du langage....

[Alp]

Je ne trouve pas qu'il s'agit de critiques en l'air, certains mécanismes C++ ont volontairement été exclus de Java non pas parce qu'ils étaient inutiles mais que le rapport risque/utilité ou complexité/utilité n'a pas été jugé bon.

Oui, c'est vrai. Ca rend le C++ plus complexe et donc plus dur à maîtriser, mais par conséquent plus pratique une fois maîtrisé.

Je n'ai jamais dis que c'était une mauvaise chose mais c'est potentiellement source d'erreur et rarement indispensable(personnellement, ça ne m'a jamais manqué)

D'un autre côté, c'est un peu ce que tu dois faire quand tu implémentes plusieurs interfaces.

Ça peux potentiellement êtrratie plus clair c'est vrai. Sur certaines classe Java comme BigInteger, ça peut manquer.
Par contre , j'ai souvent vu des utilisations que je trouve abusives. Pas besoin d'aller chercher loin:

Code :

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

std::cout << "Hello World" << std::endl;

Ca ne choque pas grand monde, mais c'est quand même un bel exemple d'une utilisation que je trouve abusive de la surcharge des opérateurs.On utilise des opérateurs pour faire des actions qui n'ont pas grand chose à voir avec des opérations.

En Haskell, il y a des opérateurs du genre :

Code :

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

(f $$$ g) x

qui retournent

Code :

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

(f x, g x)

Ca s'avère très pratique ce genre de choses. Il faut avoir une vue plus large. Si tu ne connais pas ces opérateurs, tant pis, si tu les connais tu en tires le bénéfice à 200%.
Quand aux opérateurs << et >> pour les flux, je suspecte énormément que ça a été influencé par le même genre d'opérateurs utilisés pour les flux de texte sous Unix, du genre echo "Developpez" >> developpez.txt. A chacun de voir s'il aime ou non, mais dire que saimal spabien [...] je trouve ça excessif

C'est vrai que je m'écarte un peu du sujet qui était la clarté du code. La il s'agit plutôt de risque de bug étant donné que les pointeurs/tableaux peuvent potentiellement accéder ailleurs qu'un emplacement mémoire réservé, sans obligatoirement générer d'erreur.

Euh, en Java, quand tu fais montableau[un_nombre_bien_plus_grand_que_la_taille], tu as une exception non ? On a des mécanismes similaires en C++. Pour les pointeurs, on s'en sert aussi peu que possible, et surtout on a les pointeurs intelligents depuis quelques années (cf les 150 autres fois où cela a été mentionné dans ce thread).

[millie]

Euh, en Java, quand tu fais montableau[un_nombre_bien_plus_grand_que_la_taille], tu as une exception non ? On a des mécanismes similaires en C++. Pour les pointeurs, on s'en sert aussi peu que possible, et surtout on a les pointeurs intelligents depuis quelques années (cf les 150 autres fois où cela a été mentionné dans ce thread).

Sauf qu'on accède jamais à une zone mémoire où a priori on aurait pas le droit d'accèder car c'est arrêté avant.

On peut pas faire ça par exemple :

Code :

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

1
2
*( (char*) 1234);

Code :

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

1
2
3
4
5
6
void fonction(int i) {
  char * p = (void*) &i;
  p--;
  std::cout<<(*p);
}

Ou plus simplement :

Code :

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

1
2
3
4
5
6
void fonction() {
   int * i = new int[12];
   delete i;
   std::cout<<*i;
}

[Alp]

Ah. Bah aujourd'hui on a rarement à écrire du tel code. Ou alors tu encapsules une bonne fois pour toute le bas niveau dans des classes/fonctions, en gérant les différents risques, et c'est réglé

De toute manière, on tourne en rond, le langage ne fait pas le programmeur

[ac_wingless]

De toute manière, on tourne en rond...

Naaaan... à peine!
juste 93 pages, mais on peut faire mieux!
Il suffit de mettre un lien en page de garde du site pour qu'on ait une nouvelle relance du genre "j'ai pas tout lu mais à mon avis, moi je pense que le C++ c'est bien pour faire du bas niveau, et le Java c'est achement bien pour euh... le reste, et pi d'abord ça dépend du programmeur et pi je pense que ça dépend du langage, que tous les langages ils zont des trucs bien que faut juste savoir bien les utiliser à mon avis, je pense."

Le but, c'est bien d'atteindre les 100 pages pour vérifier s'il y a un bug dans le forum, c'est ça? Alors moi j'aide, et voilà.

[adiGuba]

D'un autre côté, c'est un peu ce que tu dois faire quand tu implémentes plusieurs interfaces.

Non justement.
En implémentant plusieurs interfaces tu ne peux pas rentrer dans le problème d'héritage en triangle que tu peux obtenir avec l'héritage multiple.

A noter que ce problème aurait été bien plus important en Java du fait que les méthodes sont virtuelle par défaut...



Sinon pour le reste c'est plus une philosophie du langage. C++ se veut hyper-complet là où Java restreint les fonctionnalités.

Enfin personne n'a dit que ces fonctionnalités sont mauvaises en soit, mais uniquement qu'elles ont une utilité assez limité en comparaison des utilisations abusives et erroné qui en sont faite (je parle ici en moyenne et non pas en ce qui concerne un gourou du langage ).

a++

[Alp]

Non justement.
En implémentant plusieurs interfaces tu ne peux pas rentrer dans le problème d'héritage en triangle que tu peux obtenir avec l'héritage multiple.

Le problème de l'héritage en diamant, tu voulais dire ?

[adiGuba]

Le problème de l'héritage en diamant, tu voulais dire ?

Heu oui !

a++

[Alp]

Heu oui !

a++

On a l'héritage virtuel exprès pour ça en C++

[kisitomomotene]

Ah. Bah aujourd'hui on a rarement à écrire du tel code. Ou alors tu encapsules une bonne fois pour toute le bas niveau dans des classes/fonctions, en gérant les différents risques, et c'est réglé

De toute manière, on tourne en rond, le langage ne fait pas le programmeur

Oui mais, lorsqu'on doit maintenir un code écrit en C++ par une autre personne, on a plus de chance d'avoir un code difficile à comprendre qu'en Java.

[Uther]

Oui, c'est vrai. Ca rend le C++ plus complexe et donc plus dur à maîtriser, mais par conséquent plus pratique une fois maîtrisé.

Si je ne pensais qu'a moi, j'aurais tendance à être d'accord mais comme on travaille rarement seul, et que le niveau de chacun est très variable, il est souvent préférable de viser ce qui sera le plus simple et clair pour tout le monde, directement.

D'un autre côté, c'est un peu ce que tu dois faire quand tu implémentes plusieurs interfaces.

Oui mais le fait que les interface soient des classes abstraites pures élimine les cas complexes que peut provoquer l'héritage multiple.

Quand aux opérateurs << et >> pour les flux, je suspecte énormément que ça a été influencé par le même genre d'opérateurs utilisés pour les flux de texte sous Unix, du genre echo "Developpez" >> developpez.txt. A chacun de voir s'il aime ou non, mais dire que saimal spabien [...] je trouve ça excessif

Ce qui me gène surtout c'est que ça détourne une utilisation existante d'un opérateur pour faire autre chose. En toute logique, un opérateur se devrait de retourner un résultat sans interagir avec autre chose que ces opérandes et rester sans effet de bord (sauf pour les opérateurs d'affectation)
Je suis le premier a trouver ce genre de truc sympathique, mais il faut reconnaitre que ça peut vraiment induire en erreur.

Euh, en Java, quand tu fais montableau[un_nombre_bien_plus_grand_que_la_taille], tu as une exception non ? On a des mécanismes similaires en C++. Pour les pointeurs, on s'en sert aussi peu que possible, et surtout on a les pointeurs intelligents depuis quelques années (cf les 150 autres fois où cela a été mentionné dans ce thread).

Je suis pas un expert C++ loin de la, mais il me semble que comme en C, tant que l'on ne sort pas de l'espace mémoire de l'application il ne se passe rien non?

Quant au pointeurs intelligents, il ont beau exister. A ce que j'ai lu les pointeurs de la STL sont loin d'être suffisants pour gérer tous les problèmes et comme ce n'est pas intégré au langage, c'est loin d'être naturel à utiliser.
Enfin j'ai quand même l'impression que le pointeurs classiques sont toujours utilisés un peu partout.