Plutôt que d'énumérer toutes les raisons pour lesquelles vous préfèrerez
CodeGear RAD Studio, nous allons garder une courte liste et n'en
mentionner que 10 :

- Liberté de choix et productivité maximales avec une solution « tout en
un ».

ça veux dire quelque chose en français ça ?

- Développement transparent des applications Vista en environnement RAD.

rien à faire

- Conception d’applications .NET attractives avec le support de .NET
Framework 2.0.

ils n'en sont pas à la version 3 ?

- Liberté de déploiement avec la base de données intégrée Blackfish™ SQL.

tient, encore un petit nouveau ?

- Développement d’applications Web avancées (Avec support AJAX).

mais encore ? AJAX c'est essentiellement du Javascript, quel rapport
avec Delphi ?

- Développement RAD C++ ultrarapide avec des performances incomparables
grâce aux dernières mises à jour et extensions de C++Builder 2007.

moi je fais du Delphi

- Rationalisation des connexions aux bases de données avec la nouvelle
architecture DBX 4, avec support de ADO.NET 2.0.

c'est la nouvelle plus neuve que dbExpress ? pas marre de changer à
chaque fois ?

- De multiples extensions et améliorations ouvrant de nouveaux horizons
à Delphi pour Win32.

ah ben oui, ça met tout de suite l'eau à la bouche

- De nombreuses évolutions et améliorations qui propulsent Delphi for
Win32 à un niveau supérieur.

et c'est rien de le dire !

- Nouvelle flexibilité avec MSBuild et options de construction
personnalisée pour simplifier la gestion des « builds ».

bon ben, si c'est ça les 10 meilleurs raisons de passer à CodeGear RAD
Studio, je préfère ne pas entendre les autres

C'est simple, leur cible ce sont les cadres qui achètent le produit pour
le service développement et qui vendent du nouveau aux clients.
Il faut les aguicher avec tout plein de bons mots partout et non pas
allécher les développeurs avec des arguments massue pour leur faciliter
le travail.

Franck a écrit :
> C'est simple, leur cible ce sont les cadres qui achètent le produit pour
> le service développement et qui vendent du nouveau aux clients.
> Il faut les aguicher avec tout plein de bons mots partout et non pas
> allécher les développeurs avec des arguments massue pour leur faciliter
> le travail.

Ce n'est pas CodeGear le souci. Ils font ce qu'ils peuvent. Le souci,
c'est la façon dont le marché évolue. Acheter de la licence, ce n'est
plus dans les moeurs... Non ?

ben ouais, ils ont copié la dernière pub d'IBM sur le vaporware... Tu coches les cases à chaque fois qu'apparaissent les termes
connectivité, productivité, Ajax, Web 3.0, et quand la grille est pleine tu cris BINGO devant le Guru en chef....

Paul TOTH a écrit :
> Plutôt que d'énumérer toutes les raisons pour lesquelles vous préfèrerez
> CodeGear RAD Studio, nous allons garder une courte liste et n'en
> mentionner que 10 :
>
> - Liberté de choix et productivité maximales avec une solution « tout en
> un ».
>
> ça veux dire quelque chose en français ça ?
>
> - Développement transparent des applications Vista en environnement RAD.
>
> rien à faire
>
> - Conception d’applications .NET attractives avec le support de .NET
> Framework 2.0.
>
> ils n'en sont pas à la version 3 ?
>
> - Liberté de déploiement avec la base de données intégrée Blackfish™ SQL.
>
> tient, encore un petit nouveau ?
>
> - Développement d’applications Web avancées (Avec support AJAX).
>
> mais encore ? AJAX c'est essentiellement du Javascript, quel rapport
> avec Delphi ?
>
> - Développement RAD C++ ultrarapide avec des performances incomparables
> grâce aux dernières mises à jour et extensions de C++Builder 2007.
>
> moi je fais du Delphi
>
> - Rationalisation des connexions aux bases de données avec la nouvelle
> architecture DBX 4, avec support de ADO.NET 2.0.
>
> c'est la nouvelle plus neuve que dbExpress ? pas marre de changer à
> chaque fois ?
>
> - De multiples extensions et améliorations ouvrant de nouveaux horizons
> à Delphi pour Win32.
>
> ah ben oui, ça met tout de suite l'eau à la bouche
>
> - De nombreuses évolutions et améliorations qui propulsent Delphi for
> Win32 à un niveau supérieur.
>
> et c'est rien de le dire !
>
> - Nouvelle flexibilité avec MSBuild et options de construction
> personnalisée pour simplifier la gestion des « builds ».
>
> bon ben, si c'est ça les 10 meilleurs raisons de passer à CodeGear RAD
> Studio, je préfère ne pas entendre les autres

Ne crachons pas dans la soupe, qui n'a pas plus ou moins utilisé ce genre
d'arguement (un peu con c'est vrai) pour la sienne (soupe)...

"Paul TOTH" <tothpaul@free.fr> a écrit dans le message de
news:fobu3m$esg$1@sd-6836.dedibox.fr...
> Plutôt que d'énumérer toutes les raisons pour lesquelles vous préfèrerez
> CodeGear RAD Studio, nous allons garder une courte liste et n'en
> mentionner que 10 :
>
> - Liberté de choix et productivité maximales avec une solution « tout en
> un ».
>
> ça veux dire quelque chose en français ça ?
>
> - Développement transparent des applications Vista en environnement RAD.
>
> rien à faire
>
> - Conception d’applications .NET attractives avec le support de .NET
> Framework 2.0.
>
> ils n'en sont pas à la version 3 ?
>
> - Liberté de déploiement avec la base de données intégrée Blackfish™ SQL.
>
> tient, encore un petit nouveau ?
>
> - Développement d’applications Web avancées (Avec support AJAX).
>
> mais encore ? AJAX c'est essentiellement du Javascript, quel rapport avec
> Delphi ?
>
> - Développement RAD C++ ultrarapide avec des performances incomparables
> grâce aux dernières mises à jour et extensions de C++Builder 2007.
>
> moi je fais du Delphi
>
> - Rationalisation des connexions aux bases de données avec la nouvelle
> architecture DBX 4, avec support de ADO.NET 2.0.
>
> c'est la nouvelle plus neuve que dbExpress ? pas marre de changer à chaque
> fois ?
>
> - De multiples extensions et améliorations ouvrant de nouveaux horizons à
> Delphi pour Win32.
>
> ah ben oui, ça met tout de suite l'eau à la bouche
>
> - De nombreuses évolutions et améliorations qui propulsent Delphi for
> Win32 à un niveau supérieur.
>
> et c'est rien de le dire !
>
> - Nouvelle flexibilité avec MSBuild et options de construction
> personnalisée pour simplifier la gestion des « builds ».
>
> bon ben, si c'est ça les 10 meilleurs raisons de passer à CodeGear RAD
> Studio, je préfère ne pas entendre les autres

> bon ben, si c'est ça les 10 meilleurs raisons de passer à CodeGear RAD
> Studio, je préfère ne pas entendre les autres

Le serveur de chez Sun qui permet de télécharger Solaris 10 Express
Developer Edition (Solaris, Environnement Graphic, Netbeans, Java,
Hyperviseur Xen, Serveur d'applications...)

Free hein, bien entendu.

Eh bien il est down depuis deux jours. Sachant quels moyens Sun est
capable de mettre en matière de serveurs, j'ose penser qu'ils subissent
la rançon de leur succès...

http://developers.sun.com/sxde/

--
Pierre Y.

Pierre Y. a écrit :
>> bon ben, si c'est ça les 10 meilleurs raisons de passer à CodeGear RAD
>> Studio, je préfère ne pas entendre les autres
>
> Le serveur de chez Sun qui permet de télécharger Solaris 10 Express
> Developer Edition (Solaris, Environnement Graphic, Netbeans, Java,
> Hyperviseur Xen, Serveur d'applications...)
>
> Free hein, bien entendu.
>
> Eh bien il est down depuis deux jours. Sachant quels moyens Sun est
> capable de mettre en matière de serveurs, j'ose penser qu'ils subissent
> la rançon de leur succès...
>
> http://developers.sun.com/sxde/
>

un peu comme le site http://www.turboexplorer.com/ lors de son
ouverture, ils avaient même proposé des lien ed2k

mais il va bien mieux depuis

Paul TOTH a exposé le 06/02/2008 :
> Pierre Y. a écrit :
>>> bon ben, si c'est ça les 10 meilleurs raisons de passer à CodeGear RAD
>>> Studio, je préfère ne pas entendre les autres
>>
>> Le serveur de chez Sun qui permet de télécharger Solaris 10 Express
>> Developer Edition (Solaris, Environnement Graphic, Netbeans, Java,
>> Hyperviseur Xen, Serveur d'applications...)
>>
>> Free hein, bien entendu.
>>
>> Eh bien il est down depuis deux jours. Sachant quels moyens Sun est capable
>> de mettre en matière de serveurs, j'ose penser qu'ils subissent la rançon
>> de leur succès...
>>
>> http://developers.sun.com/sxde/
>>
>
> un peu comme le site http://www.turboexplorer.com/ lors de son ouverture, ils
> avaient même proposé des lien ed2k
>
> mais il va bien mieux depuis

Tu es sûr qu'on est en train de comparer des choses comparables ?

--
Pierre Y.

Paul,

Tu m'as l'air bien fort pour critiquer, mais que proposes-tu de constructif?

- Florent

"Achetez Visual Studio"

/_Flo_ a pensé très fort/ :
> Paul,

> Tu m'as l'air bien fort pour critiquer, mais que proposes-tu de constructif?

> - Florent

--
Faust
"Une âme en peine peut en cacher une autre"

> Tu m'as l'air bien fort pour critiquer, mais que proposes-tu de
> constructif?

* Développez vos applications sous Linux
* Travaillez de façon intuitive avec des objets C++
* Créez des objets sur la pile
* Développez pour windows CE

....

Franck a écrit :
>> Tu m'as l'air bien fort pour critiquer, mais que proposes-tu de
>> constructif?
>
> * Développez vos applications sous Linux
> * Travaillez de façon intuitive avec des objets C++
> * Créez des objets sur la pile
> * Développez pour windows CE
>
> ...

j'achète !

Bonjour,

Un autre point que je trouve regrettable, c'est le manque total de
transparence pour les prix.

Aucun tarif, aucun taux de réduction, rien en dehors du fait que Delphi
PHP est donné avec, ce qui me fait une belle jambe.

Encore un coup dans l'eau,
Dommage...

Pascal

Cher Paul,
et si vous achetiez simplement la dernière version de Delphi, tout
simplement ?

(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...)
Et puis, je reste toujours très méfiant vis à vis de ces bip de buffer
overflow


--
Phil

"Paul TOTH" <tothpaul@free.fr> a écrit dans le message de news:
focf81$lv2$1@sd-6836.dedibox.fr...
> Franck a écrit :
>>> Tu m'as l'air bien fort pour critiquer, mais que proposes-tu de
>>> constructif?
>>
>> * Développez vos applications sous Linux
>> * Travaillez de façon intuitive avec des objets C++
>> * Créez des objets sur la pile
>> * Développez pour windows CE
>>
>> ...
>
> j'achète !

sheep a écrit :
> Cher Paul,
> et si vous achetiez simplement la dernière version de Delphi, tout
> simplement ?

et pourquoi je ferais ça ?

> (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...)
> Et puis, je reste toujours très méfiant vis à vis de ces bip de buffer
> overflow
>
>
> --
> Phil
>
> "Paul TOTH" <tothpaul@free.fr> a écrit dans le message de news:
> focf81$lv2$1@sd-6836.dedibox.fr...
>> Franck a écrit :
>>>> Tu m'as l'air bien fort pour critiquer, mais que proposes-tu de
>>>> constructif?
>>> * Développez vos applications sous Linux
>>> * Travaillez de façon intuitive avec des objets C++
>>> * Créez des objets sur la pile
>>> * Développez pour windows CE
>>>
>>> ...
>> j'achète !
>
>

sheep a écrit :
> Cher Paul,
> et si vous achetiez simplement la dernière version de Delphi, tout
> simplement ?
>
> (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.

> 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 ?).

Jean

"Jean Lacoste" <lacoste@alussinan.org> a écrit dans le message de news:
foeevq$4h1$1@sd-6836.dedibox.fr...
> sheep a écrit :
>> Cher Paul,
>> et si vous achetiez simplement la dernière version de Delphi, tout
>> simplement ?
>>
>> (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 ?
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 ! Que de code exécuté pour rien !


>> 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.
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 !
C'est une usine à gaz, je ne vous dis pas !
.... Et ca fait toujours plus de code invisible exécuté !

> Jean

Cordialement,
--
Phil

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++.

> 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

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

Paul TOTH a écrit :
> à 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
>

Mouais, à l'époque où je développais en Delphi 7 (j'ai arrêté delphi il
y a un peu plus d'un an), il y en avait encore une bonne floppée qui
continuait à pondre du code delphi 4. On peut imaginer comment rigole le
développeur delphi 7 qui arrive derrière son code ...

Je peux aussi ajouter que malheureusement beaucoup de développeurs qui
se proclament développeurs expérimentés en delphi ne comprennent
effectivement rien à delphi ...

Franck

Franck a écrit :
> Mouais, à l'époque où je développais en Delphi 7 (j'ai arrêté delphi il
> y a un peu plus d'un an), il y en avait encore une bonne floppée qui
> continuait à pondre du code delphi 4. On peut imaginer comment rigole le
> développeur delphi 7 qui arrive derrière son code ...

Fichtre ! Y'a des trucs qui ont dû m'échapper alors...

Paul TOTH a écrit :
> Jean Lacoste a écrit :
>> 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à
Sans parler des nouveaux programmeurs qui ne savent même pas comment
marche un processeur et à quoi ressemble un programme une fois compilé.

Ou de ceux qui se contentent d'assembler des bouts de lib épars (plus ou
moin bien adaptés à leur besoin) en ajoutant de la glue à plein seaux
pour faire tenir les morceaux entre eux.

Bref, on finit par surcharger les machines par des routines
"automatiques" qu'un bon programmeur avec un peu de bon sens aurait
supprimé.

Tout fout le camp, je vous dit !
De mon temps, patati, patat patati patata, etc ...

:-)

Paul TOTH a écrit :
....
>> 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à

Effectivement, il en reste.
Le c++ a toujours trainé comme un boulet la compatibilité avec c !

> surtout qu'avec un tel argument, on pourrait dire que les programmes
> Delphi sont d'une stabilité à toute épreuve...

Et pourquoi donc ?

> ou alors c'est que le
> programmeur n'a rien compris à Delphi

Il y en a plein.

Jean

Ca part en quenelle, là.
Vaut mieux arrêter , cela devient stérile.

--
Phil

"Jean Lacoste" <lacoste@alussinan.org> a écrit dans le message de news:
fohcr1$ktv$1@sd-6836.dedibox.fr...
> Paul TOTH a écrit :
> ...
>>> 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à
>
> Effectivement, il en reste.
> Le c++ a toujours trainé comme un boulet la compatibilité avec c !
>
>> surtout qu'avec un tel argument, on pourrait dire que les programmes
>> Delphi sont d'une stabilité à toute épreuve...
>
> Et pourquoi donc ?
>
>> ou alors c'est que le programmeur n'a rien compris à Delphi
>
> Il y en a plein.
>
> Jean

sheep a écrit :
> Ca part en quenelle, là.
Voire en cassoulet.

> Vaut mieux arrêter , cela devient stérile.
Pour le conserver en bocaux, c'est plus prudent.