Discussion :

[Firwen]

J'ai choisi C++.
- Pourquoi ce choix ?
C++ est de mon point de vue incontournable, la meilleur alternative possible lorsque l'on cherche un langage permettant à la fois performances accrues, gestion manuelle de la mémoire et orienté objet.
- Les plus/avantages
-> Orienté Objet
-> Compilé donc globalement plus performant que Java ou C#
-> Gestion de la mémoire manuelle
-> Grand nombre de bibliothèques de grande qualités: Qt, WxWidget, OpenGL....
-> Portabilité totale quand utilisé avec une bibliothèque adéquate
- Les moins/inconvénients
-> langage "Bâtard" (Imp., POO., POA ) donc complexe et déstabilisant pour un néophyte.
-> Bibliothèque standard globalement trop pauvre.
-> Nécessite une bonne connaissance de la mécanique des pointeurs
-> Creation de bibliotheque complexe.
- Quels projets réalisez-vous avec et pourquoi
Applications orientées Desktop multi-plateformes principalement à l'aide de la bibliotheque Qt
- Vers quels autres langages pensez-vous évoluer dans le futur
Java ou python pour les projets de petite taille, les langages dépendant d'une plateforme comme C# ne m'interessent pas.
- Comment vous êtes-vous formé, ou avez-vous été formé sur ce langage :
Autoformation.
- Est-ce une utilisation amateur ou professionnelle
Au départ c'était une utilisation amateur mais maintenant c'est aussi professionnelle
- Avez vous fait votre choix pour raison professionnelle, par plaisir, par choix personnel :
par choix personnel.
- Quels outils vous utilisez (Editeur, EDI, etc.)
Eclipse, QtCreator, ou Editeur classique & maketools.
- Autres langages utilisés, pourquoi ? dans quel cadre ? et comparaisons ?
-> PHP : Développement Web.
-> Python : Creation de petites applications rapidement.
- Sur quels systèmes ou plateformes vous travaillez (Windows, DotNET, Linux, etc.)
Windows & Linux.
- Conclusion
C++ est pour moi un langage qui conservera sa place de langage de prédilection dans les projets massifs car il a toutes les qualités nécessaires ( compilé, hautes-performances, POO, Nombreuses Libs, pas de Garbage Collector, fiabilité accrue,portabilité ) contrairement aux langages de Haut Niveau récents ( java, C#, Python, Ruby, VB )

[alex_pi]

C++ est pour moi un langage qui conservera sa place de langage de prédilection dans les projets massifs car il a toutes les qualités nécessaires ( [...] pas de Garbage Collector, fiabilité accrue [...]

Euh.... ça te chagrine pas ces deux trucs dans une même liste ?

[Alain Defrance]

- Les plus/avantages
-> Compilé donc globalement plus performant que Java ou C#
-> Gestion de la mémoire manuelle

Oui le C++ est plus rapide que le Java (je connais pas assès C#). Mais pour la plupart des projets les différences ne se sentent pas. Quant aux projets ou ça se sent, le Java n'est probablement pas le bon choix technique.
La gestion de la mémoire manuelle est pour moi un autre point négatif, pourquoi faire simple quand on peut faire compliqué ?

- Les moins/inconvénients
-> Nécessite une bonne connaissance de la mécanique des pointeur

Si je ne m'abuse, en C++ moderne, les pointeurs tendent à disparaitre non ? Notament avec les nouvelles choses qui arrivent bientôt -> smartpointeurs -> proche d'un garbage collector.

- Conclusion
C++ est pour moi un langage qui conservera sa place de langage de prédilection dans les projets massifs car il a toutes les qualités nécessaires ( compilé, hautes-performances, POO, Nombreuses Libs, pas de Garbage Collector, fiabilité accrue,portabilité ) contrairement aux langages de Haut Niveau récents ( java, C#, Python, Ruby, VB )

En terme de fiabilité, avoir un garbage collector est une bonne chose. Ceci nous évite plus facilement d'avoir des fuites mémoires (même si on peut toujours en avoir ).
Sur le point de vue portabilité, Java est plutot largement mieux placé que C++ (la portabilité est native et ne nécéssite pas de recompilation ...).
En terme de déploiement et rapidité de développement, la Plateforme JavaEE est très éfficace, surtout sur de gros projets ...

Désolé pour ce petit commentaire. Je ne cherche pas a dénigrer C++ (qui est pour moi un excelent langage). Mais certains arguments, bien que compréhensibles, ne me semblaient pas justifiés.

[dingoth]

En terme de fiabilité, avoir un garbage collector est une bonne chose. Ceci nous évite plus facilement d'avoir des fuites mémoires (même si on peut toujours en avoir ).

Je n'approuve pas du tout l'argument : la présence d'un garbage collector tend à faire oublier au développeur le besoin de "cleaner" ses objets lorsqu'il en a fini avec eux. L'exemple le plus simple : l'oubli quasi systématique d'appeler clear() sur une collection Java lorsqu'elle n'a plus besoin d'être. Je le sais, j'oublie assez souvent moi-même.

[nicorama]

Une fois ta fonction terminée, ton objet list est mis à disposition du GC, et appeler clear() ne va pas forcemment accélérer les choses, ce qui n'est d'ailleurs pas une necessité.

A moins d'avoir des grosses collections en attributs de classes static dans ton code (et c'est un autre problème ), ton argument ne tient pas, à mon avis.

[dingoth]

Ah bon ?

[jabbounet]

En dehors du boulot : bof
Dans le boulot: Perl / C++ / lisp
historiquement: en gros parmi tous ceux que j'ai pratiqué depuis que je bosse. ada/perl/lisp

[jabbounet]

Personnellement je pense que c'est surtout les humains qui sont derrière la conception/développement/test qui font la différence pour la fiabilité d'un soft et ceux quelque soit les choix technologiques effectué.

un mec qui (ne) code (pas) avec les pied saura tout aussi bien le faire en C++ ou en java ou dans n'importe quel langage....

Oui le C++ est plus rapide que le Java (je connais pas assès C#). Mais pour la plupart des projets les différences ne se sentent pas. Quant aux projets ou ça se sent, le Java n'est probablement pas le bon choix technique.
La gestion de la mémoire manuelle est pour moi un autre point négatif, pourquoi faire simple quand on peut faire compliqué ?

Parce que même avec un gestion "automatique" de la mémoire je vois encore trop de développeur java ne pas maitriser leurs références (pour ne pas dire pointeur) aux dits objets et avoir des leaks mémoire et particulièrement sur des projet très complexe.....

Parfois je pense que réapprendre des bases tel que producteur/consommateur aide pas mal a résoudre ce genre de soucis

Exemple:
Dans ce programme qui produit la donnée et pourquoi ,
qui va la modifier en apportant sa petite graine. et finalement qui va avoir la charge de s'en servir et finalement s'en débarrasser.

Si je ne m'abuse, en C++ moderne, les pointeurs tendent à disparaitre non ? Notament avec les nouvelles choses qui arrivent bientôt -> smartpointeurs -> proche d'un garbage collector.


En terme de fiabilité, avoir un garbage collector est une bonne chose. Ceci nous évite plus facilement d'avoir des fuites mémoires (même si on peut toujours en avoir ).

Effectivement parce qu'il y' a un garbage collector dans le java et que c'est "géré automatiquement",

On oublie trop souvent d'expliquer ce qu'est une mémoire quand on forme un nouveau développeur (le plus souvent sur java maintenant) et on lui cache certains aspect système indispensable pour penser a un développement "stable" tel que des problématique de gestion de mémoire en lui disant ça tu n'as pas a t'en occuper c'est le garbage collector qui le fait.

la faute ne reviens pas forcement au langage qui en lui même apporte pas mal de chose, mais encore une fois aux humains qui sont derrière.....

Sur le point de vue portabilité, Java est plutot largement mieux placé que C++ (la portabilité est native et ne nécéssite pas de recompilation ...).
En terme de déploiement et rapidité de développement, la Plateforme JavaEE est très éfficace, surtout sur de gros projets ...

C'est effectivement plus portable que d'autres langage a condition d'avoir la même jvm (les comportement sont parfois légèrement différent entre la jvm de sun, bea/oracle (jrockit), celle de hp-ux dont j'ai oublié le nom) installé partout dans ton déploiement et de ne pas faire appel a certaines fonction qui sont spécifique a un os

Ceci dit la portabilité dépend la encore des gens qui ont fait la conception/développement s'ils y ont pensé dès le départ ou non.
j'ai déjà croisé des soft compilé qui était tout aussi portables, il suffisait juste de générer le binaire pour les plateformes cibles.

[Alain Defrance]

Je n'approuve pas du tout l'argument : la présence d'un garbage collector tend à faire oublier au développeur le besoin de "cleaner" ses objets lorsqu'il en a fini avec eux. L'exemple le plus simple : l'oubli quasi systématique d'appeler clear() sur une collection Java lorsqu'elle n'a plus besoin d'être. Je le sais, j'oublie assez souvent moi-même.

Une instance est élligible par le garbage collector lorsque l'instance n'est plus référencée, et donc inaccéssible (ce qui exclu les ilôts de référence). Avoir des objets référencés par une collection font d'eux des instances non nettoyables. Mais lorsque nous perdons la référence indirecte de ces instance (celle de la liste), alors la liste et les éléments deviennent éligibles. Clear ne fait que faire en sorte que la liste ne référence plus rien, mais en perdant la référence vers la liste, le garbage collector est tout à fait capable de s'en charger.

Personnellement je pense que c'est surtout les humains qui sont derrière la conception/développement/test qui font la différence pour la fiabilité d'un soft et ceux quelque soit les choix technologiques effectué.

un mec qui (ne) code (pas) avec les pied saura tout aussi bien le faire en C++ ou en java ou dans n'importe quel langage....

Outre le fait que beaucoup de différences sont présentes entre les technologies, je suis entièrement d'accord.

Parce que même avec un gestion "automatique" de la mémoire je vois encore trop de développeur java ne pas maitriser leurs références (pour ne pas dire pointeur) aux dits objets et avoir des leaks mémoire et particulièrement sur des projet très complexe.....

C'est vrai dans tous les domaines. Soit on ne fait qu'utiliser une technologie sans la connaitre et on s'expose à des erreurs énormes. Soit on apprend le fonctionnement interne et on évite les abérations. Mais le langage Java ici est hors d'accusation, on ne peut pas taper sur une techno sous prétèxte qu'elle est suffisement simple pour permettre aux développeur maladroit de mal l'utiliser.

Effectivement parce qu'il y' a un garbage collector dans le java et que c'est "géré automatiquement",

On oublie trop souvent d'expliquer ce qu'est une mémoire quand on forme un nouveau développeur (le plus souvent sur java maintenant) et on lui cache certains aspect système indispensable pour penser a un développement "stable" tel que des problématique de gestion de mémoire en lui disant ça tu n'as pas a t'en occuper c'est le garbage collector qui le fait.

Ici aussi le langage est hors d'accusation, c'est très agréable de pouvoir s'appuiller sur du solide pour peu de savoir le faire et être conscient de ce que ceci nous évite de faire.

C'est effectivement plus portable que d'autres langage a condition d'avoir la même jvm (les comportement sont parfois légèrement différent entre la jvm de sun, bea/oracle (jrockit), celle de hp-ux dont j'ai oublié le nom) installé partout dans ton déploiement et de ne pas faire appel a certaines fonction qui sont spécifique a un os

Le plus simple reste d'utiliser la JVM de sun ...
De quelles fonctions parles-tu concernant la spécificité à l'OS ?

il suffisait juste de générer le binaire pour les plateformes cibles.

C'est de cette génération que je parle quand je dis que Java est nativement portable, mais ce n'est pas une critique, c'est juste une des particularité de la techno.

[jabbounet]

C'est vrai dans tous les domaines. Soit on ne fait qu'utiliser une technologie sans la connaitre et on s'expose à des erreurs énormes. Soit on apprend le fonctionnement interne et on évite les abérations. Mais le langage Java ici est hors d'accusation, on ne peut pas taper sur une techno sous prétèxte qu'elle est suffisement simple pour permettre aux développeur maladroit de mal l'utiliser.


Ici aussi le langage est hors d'accusation, c'est très agréable de pouvoir s'appuiller sur du solide pour peu de savoir le faire et être conscient de ce que ceci nous évite de faire.

j'accuse rarement un langage, mais j'ai souvent tendance a etre mécontent de l'utilisation qui en est faite.

Ce serait comme accuser un tournevis de ne pas pouvoir enfoncer des clou ou un marteau de mal planter des vis...

Le plus simple reste d'utiliser la JVM de sun ...
De quelles fonctions parles-tu concernant la spécificité à l'OS ?

étant donné que je travail chez un éditeur de logiciel qui se retouve parfois intégré dans des environnement complexes, on ne peux faire que des recommandations parfois très forte quand à la façon dont ils sont utilisés mais après le client est roi et est libre de choisir ses technos.

En fait ce n'était pas des fonctions systèmes, mais plus des fonctions jvm spécifique que j'avais vu en relisant un code c'etait dans com.io.sun.misc ou quelque chose comme ça (java n'est pas trop mon langage ).

[jabbounet]

Outre le fait que beaucoup de différences sont présentes entre les technologies, je suis entièrement d'accord.

pas tant que ça c'est juste une façon de faire qui est différente, un garbage collector peu être implémenté en C++,

En simplifié le principe est le suivant:
Créer un classe 'object' avec un compteur, surcharger ou refefinir avec des macros quelques opérations (new , =, ...) pour incrémenter / décrémenter le compteur qui compte en fait le nombre d'objet qui y font référence.

Cet 'object' s'efface/ ou indique a un thread dédié qu'il peu être effacé.
quand le compteur redescend a 0.

Ensuite on impose dans les normes de codage que tout le monde doit hériter de 'object' et d'utiliser les quelques macros qui vont bien si besoin et le tour est joué .


Après dans la réalité c'est un peu plus complexe et ça ne se fait pas en trois lignes, mais il y'a (eu) des implémentations de GC qui ont existé en C++, Simplement ça casse un peu les perf et les développeurs C/C++ n'aiment pas ne pas savoir ce qu'il se passe dans la mémoire.

Pour le bac a sable tu place tes objet dans une mémoire partager et tu t'assure que tu n'en sortira jamais....

après je ne suis pas convaincu que cela vaille la peine de réécrire ce qu'un langage fait déjà mais cela est possible.



Note pour plus tard, répondre en un seul post ci possible sinon on va croire que je flood

[nicorama]

Ah bon ?

Ben oui, suffit de ne pas faire n'importe quoi, à commencer par mettre des grosses collections en static, premier exemple donné.

Il y a deux autres exemples qui sont également cités, et que je ne retrouve pas dans mes patterns de programmation. Et ce n'est pas faire un clear() qui absout de ce genre de pratiques.

[dingoth]

...

Mon argument tient. Ce n'est pas parce que tu fais attention à bien utiliser tes instances que tout le monde le fait. Les méthodes et instances statiques font partie des plus gros problèmes menant aux ML, tout comme les collections. Les deux ensembles sont de plus grosses sources de memory leaks, mais chacun individuellement reste source de ML.

Quand tu verras un programme développé par une poignée d'Indiens qui nécessite deux mois de nettoyage car il bouffe des perfs incroyables pour la simplicité toute relative que ce programme représente et qu'il n'y a pas une seule méthode statique excepté le main(String...), tu comprendras le besoin de clear()er toutes tes collections une fois le boulot terminé.

[Ubiquité]

Je voudrai pas troller, mais en vous lisant j'ai pas l'impression que le ramasse miette de la JVM simplifit grand chose.

[Tarul]

Après dans la réalité c'est un peu plus complexe et ça ne se fait pas en trois lignes, mais il y'a (eu) des implémentations de GC qui ont existé en C++, Simplement ça casse un peu les perf et les développeurs C/C++ n'aiment pas ne pas savoir ce qu'il se passe dans la mémoire.
:

Tu doit être fatigué, je pense que tu voulais peut être dire que les développeurs c/c++ aiment savoir ce qu'il se passe dans la mémoire et non l'inverse.

[Jedai]

Tu doit être fatigué, je pense que tu voulais peut être dire que les développeurs c/c++ aiment savoir ce qu'il se passe dans la mémoire et non l'inverse.

Lis ce passage plus attentivement, jabbounet a utilisé une double négation, donc il a bien dit que les développeurs C/C++ aiment savoir ce qu'il se passe en mémoire, ils n'aiment pas ne pas savoir ce qu'il se passe en mémoire.

--
Jedaï

[jabbounet]

...

Mon argument tient. Ce n'est pas parce que tu fais attention à bien utiliser tes instances que tout le monde le fait. Les méthodes et instances statiques font partie des plus gros problèmes menant aux ML, tout comme les collections. Les deux ensembles sont de plus grosses sources de memory leaks, mais chacun individuellement reste source de ML.

Quand tu verras un programme développé par une poignée d'Indiens qui nécessite deux mois de nettoyage car il bouffe des perfs incroyables pour la simplicité toute relative que ce programme représente et qu'il n'y a pas une seule méthode statique excepté le main(String...), tu comprendras le besoin de clear()er toutes tes collections une fois le boulot terminé.

C'est ce que je suis en train de voir depuis quelques mois , je ne connais pas trop java (je serait plutôt tout un tas de langage mais pas java :lol) et pourtant leur code me fait peur

[nicorama]

C'est pas la JVM qui est responsable des conditions de travail des Indiens

[jabbounet]

Je voudrai pas troller, mais en vous lisant j'ai pas l'impression que le ramasse miette de la JVM simplifit grand chose.

Disons que cela a simplifié des choses quand les personnes avait vu d'autres langages avant et qu'il avaient été plus sensibilisé à la gestion mémoire, maintenant elles l'apprenne avec l'expérience.

Le problème est dans les explication faite sur un langage/outils ou on oublie souvent d'expliquer comment marche les internes, et ce qu'il faut faire pour ne pas tout aller à rebrousse poil.

j'ai trop souvent vu des développeur java me dire java c'est bien je n'ai pas a m'occuper de la mémoire y'a le garbage collector ( "c'est magique" ). en fait c'est une erreur il n'y a pas de magie, même en java il faut penser à regarder ce que tu fais avec ta mémoire (mais c'est un peu moins important).

Le garbage collector ne fait pas tout il faut aussi penser a ne plus référencer les objets que tu n'utilise plus et pour cela il faut être conscient de ce que tu alloue.

Je ne fais aucun reproche à la techno, Java a effectivement permis de rendre la programmation plus facile d'accès en limitant certaines difficultés (sur la gestion mémoire notamment).

Simplement dès l'instant ou tu commence à faire du dev avancé dans un cadre professionnel il faut pousser un peu au delà des concepts de bases du langage et comprendre ce que tu fait, et c'est là ou les personnes qui n'ont appris que java et qui débute on des progrès a faire (et y'en a qui en font ).

Personnellement quand j'ai appris a réellement a comprendre ce que je faisais c'était à l'école pendant mes cours sur les OS et la programmation système (en C) ou on t'expliquais bien l'archi d'une machine (soft/hard), ce qu'était un process, une mémoire partagée , un sémpahore, un pipe, une fifo, .... , et ce que cela representais physiquement.

Avant c'etait disjoint d'un coté tu avais la programmation ou c'était plus de l'algorithmie en fait (basic sur amstrad et atari, puis pascal au lycée)

Et électronique/automatisme ou la tu te préoccupais que du matériel, (comment faire marcher ton microcontrolleur avec une eprom a coté, comment marche une liaison HDLC, ...)

La programmation système m'a en fait permis de trouver le liant entre les deux. quand je déclare une variable dans un langage ou que j'alloue un objet je devines les mécanismes qu'il peux y avoir derrière physiquement (même si parfois ils sont très très loin) et je sais que si je joue un peu trop au con j'en payerai forcement le prix

[yan]

...
Simplement dès l'instant ou tu commence à faire du dev avancé dans un cadre professionnel il faut pousser un peu au delà des concepts de bases du langage et comprendre ce que tu fait, et c'est là ou les personnes qui n'ont appris que java et qui débute on des progrès a faire (et y'en a qui en font )....

Ca me fait pensez à un article que j'avais lue sur l'influence de java dans les ecoles sur le niveau
http://www.developpez.net/forums/d59...ecoles-niveau/