tyoup a écrit 308 commentaires

Impossible ! Par terre c'est sale, le garbage collector n'en finit de s'exécuter…

Parfaitement d'accord ! C'est une histoire à dormir debout !

Cependant, quand on code tout soi-même, on apprécie de tout faire dans le même langage et ne pas avoir un process de compilation trop compliqué.

Pfff. L'expérience montrera que beaucoup de développeurs aiment "se faire plaisir"…

Débranchons tous les windows, tous les linux et tous les autres bidules et voyons comment ce comporte le système d'exploitation n°1 :-)

Personne n'a rebondi sur node.js mais franchement pourquoi pas ? Et voire pourquoi pas avec Java/Netty?

Oublier la mémoire est une mauvaise idée

c'est une mauvaise idée… en C++…

depuis les annotations c'est devenu la foire aux bibliothèque faisant tout, sauf ce que le dev veut

ben parlons des bibliothèques C++ alors… ah j'oubliais, on ne sait jamais comment elles gèrent la mémoire donc on évite de les utiliser (c'est bien vendredi ?)

Et perso, entre une appli en java faite par un dev qui ne sait pas ce qu'il fait mais qui va quand même sortir cas la JVM s'est occupée de ramasser ses merdes miettes et une en C++ avec un codeur qui ne sait pas ce qu'il fait, du coup ça ne sortira pas. Je ne suis pas sur de ce qui est le mieux.

Ben c'est un peu comme comparer un moteur de voiture avec… ok ---->[] je sors

tiens moi j'aurais comparé avec java parce que Qt c'est assez lourd…

ou pas les bouseux comme moué ben qu'i dis' crayon d'papier

Ben.. par où commencer ? Des arguments j'en ai quelques uns, alors, petit, écoute moi bien car je suis effectivement très hautain MOI. Sorti de ton monde merveilleux où tu as codé ton petit hello world tu verras que l'écosystème java est très fragmenté et que cela pose rapidement des petits soucis. Tu te rendras compte qu'avoir une dépendance JNI peut être fatale en terme de portabilité. Tu verras peut-être des applications qui ont été conçues avec des dépendances sur des briques logicielles spécifiques à un serveur d'application JEE et qui ne pourront pas tourner sur un autre serveur JEE. Tu verras peut-être qu'une librairie devra peut-être être intégrée de diverses manières dans différents contextes. Tu verras peut-être des librairies qui ne sont pas compatibles avec ton classpath alors qu'ailleurs ça aurait été comme sur des roulettes. J'espère juste que tu aies tout plein de contre arguments :-).

Quand on compile du Java, ça fonctionne partout (enfin tant qu’on en change pas de version majeure de Java), c’est prévu pour être redistribuable.

Merde, encore quelqu'un qui y croit…

Peuf ! un vrai hacker n'a pas besoin de debugging surtout pour un truc aussi basique ;-)

Je voudrais voir s'il est possible de généraliser ce système à entités et de l'appliquer au développement de mon site internet en PHP. Quelqu'un aurait-il des pistes ou des conseils pour m'aider à débuter ?

… et les pâtes ???

Oh sympa, un système de contraception objet pour éviter de concevoir des enfants à tout va.

On n'y est toujours pas je crois.

Moi je dirais que ça serait plus que ça serait assimiler un server web au site internet qu'il sert.

Soyons précis c'est important. L'approximation et les abus de langage ne sauraient être tolérés.

souffler n'est pas jouer

amen

Il attend peut-être que linux soit utilisable. Le libre après tout c'est une affaire d'idéaliste.

De l'eau est mise dans la farine, le composé est pétri par un bras mécanique qui forme une pâte. La pâte est placée dans un four haute température. Voici comment l'on fabrique du pain.

J'adore leur humour :-)

Omega ?

Viadeo ? LinkedIn ? chooseyourboss ? lesjeudis ?

Et par le biais de connaissances ? Ton école peut-être ?

Dans ce cas, string_array reste un std::vector. Je ne veux pas exposer l'interface de std::vector, et l'utilisateur n'a pas à savoir comment est implémenté string_array. Bref, dans ton cas, il est possible de confondre des type, puisque string_array est publiquement un std::vectorstd::string.
Ceci implique que n'importe quel std::vectorstd::string peut être fournit en lieu et place de string_array. Donc le jour où tu décide de remplacer std::vectorstd::string par std::vectorstd::string, partout où le code utilisera std::vertorstd::string devront être mis à jour. Alors qu'en étant orthogonal dès le départ, on évite ses blagues.

bah si tu aimes être responsable des conneries des autres…

De plus, il n'est pas possible de restreindre l'usage des méthodes de std::vector.

C'est clair qu'en mettant tout privé on évite efficacement les bugs.

Personnellement, je ne connais que deux types de polymorphismes : statique, dynamique.

Eh bien on parle aussi parfois de polymorphisme de méthode pour désigner la surcharge par opposition au polymorphisme de type que tu connais. Visiblement c'est un terme qui ne semble pas très répandu, j'ai trouvé peu de références sur le net, en tout cas il était utilisé dans les cours que j'ai eus sur les langages objets.

Une composition, dans ce cas, pourrait introduire une indirection, et plus de code (donc statistiquement plus de bogues).

S'il faut avoir peur d'une simple délégation, où va le monde ? :-)

J'ai pas compris l'exemple que tu as donné, pourquoi ne pas faire ça ? Le template ne fait pas bien son job ?

typedef std::vector<std::string> string_array;

Pour le reste du commentaire, je n'ai pas envie d'être méchant, alors je n'y réponds pas…

Je pensais au "polymorphisme de méthode"…

Pour ce qui est de l'héritage autre que publique, je ne vois pas trop son intérêt par rapport à la composition…

Ce que je trouve pénible, c'est l'utilisation systématique du maximum de contraintes pour décrire un objet. Pour moi le fait de devoir introduire des contraintes dans une définition est un inconvénient.