Jean Lacoste a écrit :
> sheep a écrit :
> ...
>>>> (Perso, je n'ai jamais travaillé de manière intuitive avec le C++,
>>>> c'est trop plein
>>>> de choses cachées sui me gâchent le plaisir et la performance, style
>>>> constructeurs
>>>> là où on s'attends vraiment pas à en trouver , etc...)
>>> Etonnant. En c++, on a un appel de constucteur quand on construit un
>>> objet, et c'est automatique, comme la destruction. Là où on a 1 ligne
>>> en c++ pour déclarer et utiliser un objet, il en faut obligatoirement
>>> 5 (je ne parle même pas de la déclaration de la variable) en delphi.
>>> Le risque d'erreur est considérablement réduit.
>>
>> Vous croyez qu'un appel à un constructeur ne se fait que lors que vous
>> décidez de créer
>> un objet ?
>
> Non, il se fait lorsqu'un objet doit être créé, il se fait
> automatiquement, au moment exact où c'est nécessaire. Il ne se fait pas
> si ce n'est pas nécessaire. Et ça ne pose pas le moindre problème à
> quiconque sait comment fonctionne le c++.
>
>> Faites du pas à pas et vous serez surpris du nombre de constructeurs
>> faisant suite à la simple
>> utilisation de variables correspondants * a priori * a des types simples.
>> Quelques recherches sur l'optimisation en c++ sur le net, et vous
>> trouverez
>> un temps d'exemples !
>
> C'est étrange, avec plus de 10 ans de c++ plutôt intense, je ne vois pas
> précisemment ce que tu veux dire.
>
>> Que de code exécuté pour rien !
>
> Voilà une affirmation rigolotte ! Du code exécuté pour rien, qu'est ce
> que ça peut bien vouloir dire ?
>
>>>> Et puis, je reste toujours très méfiant vis à vis de ces bip de
>>>> buffer overflow
>>> Des buffers overflow, en c++ ? Tu parles d'un vieux programmeur c qui
>>> s'est mis sur le tard au c++ et qui programme comme un nourin ?
>>> Quelqu'un qui programme en c++, il a moins de chance de déborder un
>>> tableau qu'en delphi (tu en connais beaucoup qui activent l'option
>>> Vérification des limites avec delphi ?).
>>
>> En bebug, oui : moi. Je ne suis vraiement tranquille qu"apres des
>> tests unitaires
>> en couverture C2 (méthode cocomo). 60 % de mon temps.
>
> Dans ce cas, il est assez étrange que tu reproches au c++ des problèmes
> de buffer overflow !
>
>> Quant au c++, regardez comment est gérée une réservation de mémoire :
>> regardez
>> comment il y a surdemsionnement, comment il y a un magic crré en fin
>> de zone
>> et comme le code gégéné teste la présence de ce magic pour éviter
>> l'adressage au dela !
>
> Qu'est ce que c'est que ce charabia ?
>
> En c++, si on alloue de la mémoire "à la main", qu'on le manipule "à la
> main", alors c'est exactement comme avec Delphi, on est seul responsable
> des problèmes si on sort du bloc mémoire.
>
> De plus, les erreurs de buffers que tu cites sont des erreurs que font
> les vieux programmeurs c qui n'ont pas compris grand chose au c++.

à mon avis il en reste un bon paquet des ces programmeurs là

surtout qu'avec un tel argument, on pourrait dire que les programmes
Delphi sont d'une stabilité à toute épreuve...ou alors c'est que le
programmeur n'a rien compris à Delphi

>> C'est une usine à gaz, je ne vous dis pas !
>> ... Et ca fait toujours plus de code invisible exécuté !
>
> Du code invisible exécuté. Après le code exécuté pour rien, le code
> invisible.
>
> Ma foi, si j'ai du code invisible exécuté pour rien qui me permet
> d'avoir un langage extrèmement puissant, pouvant résoudre rapidement et
> de manière très efficace les problèmes que je dois implémenter, alors
> pourquoi pas.
>
> Jean