Pourquoi du C pur ?

Pierre Maurette wrote:

"Laurent Deniau" <Laurent.Deniau@cern.ch> a écrit dans le message de news:
3F4C53B1.4090404@cern.ch...
....

J'ai utilise' le C++ de 1989 (zortech 1.0 :-) a 1999. Je continue de temps

en

temps pour ne pas perdre contact car sur le plan des concepts, c'est un

language

tres interessant. J'ai egalement regarde Objective-C, Eiffel et Java (et
beaucoup d'autres pour la culture) mais pour l'instant aucun ne m'a seduit

plus

que le C et le C++.

Mais le C++ est deux (voir trois) ordres de magnitude plus complexe que le

C. Il

est tres facile de faire n'importe quoi en C++ et de ne plus s'y

retrouver. Et

c'est encore plus difficile de le faire comprendre a ses collaborateurs

(surtout

s'ils manquent d'experience) lorsque vous mixez plusieurs facettes du C++
(heritage multiple, heritage virtuel, methodes virtuelles, membres static,
template, traits, template expressions, exceptions).

Depuis je suis revenu au C que j'utilise presque comme Java (mais je gere

la

memoire :-). Il est en effet tout a faire possible de faire de la POO
(technique) en C (language) et j'y ai meme trouve des avantages. C'est
effectivement legerement plus lourd de creer une hierarchie d'objets en C
(quoique avec de bonnes macros)... Mais:

o cela incite a reflechir a la qualite de l'interface a deux fois, ce qui

de

mon point de vu est le point le plus important dans toute

programmation.

Mon principe est qu'en lisant une fois une interface (un header) on

devrait

pouvoir en utiliser les services et les objets sans trop se poser de

question.

Et le cas echeant, lever les questions persistantes en lisant

l'implementation

(selon moi ca doit rester <1% des cas).

Or en C++ (ou autre language OO) on voit rapidement le nombre de

classes

croitre exponentiellement ce qui devient inutilisable, incomprehensible

ou

impossible a maintenir (pour parodier une phase connue, "trop objet tue
l'objet"). Et l'utilisation intensive des templates n'aide pas a la
comprehension (qui serait capable d'utiliser la STL en lisant les

headers une

ou deux fois? Et encore il lui faudra bien quelques semaines vu la

taille du

code).

o les problemes sont explicites (par exemple levees d'exceptions dans les
constructeurs, ordre de construction/destruction des objets et de leurs
membres). Un source C++ est souvent beaucoup plus complique' a

comprendre

qu'un source C car de nombreuses choses (pas necessairement accessible)
sont implicites.

o on controle (presque) tout, ce qui fait que le C est souvent considere

comme

un super assembleur. Y compris le modele objet quand on fait de la POO,

avec

la possibilite de l'etendre a souhait (par exemple l'introspection, les
objects factory, etc...).

o on controle aussi d'avantage le layout binaire ce qui permet plus

facilement

de s'interfacer avec d'autres bibliotheques sans (trop de) surprise.

Certains

points du C++ ne sont pas encore resolu et demande parfois un

"collaboration"

avec l'OS (exemple: gestion de l'export des templates).

o le temps de developement est (pour moi mais je l'ai observe ailleurs)

deux

fois plus rapide en C qu'en C++, en partie parce que j'utilise le

meilleur des

deux mondes :-) POO sans les contraintes fortes qui vont avec (C++ en
particulier).

o il est plus simple de resoudre des problemes "non-standard" en C qu'en

C++. Il

suffit de voir le niveau plutot basique des questions sur fclc par

rapport aux

questions sur fclc++. Cela montre clairement que le C++ est plus

difficile a

maitriser et qu'on devient plus rapidement "autonome" en C. Cela compte
beaucoup quand l'equipe de development change souvent.

o pour finir, je n'ai besoin que d'un livre pour programmer en C (et

encore, on

trouve beaucoup dans les man), alors que j'ai besoin de 2 a 5 livres +

une

norme pour programmer en C++. Je parle de programmer proprement, pas

des bouts

de code ou des petits programmes de-ci-de-la....

Je vous remercie, ainsi que l'ensemble des contributeurs, pour votre longue
réponse.
Effectivement, le niveau de complexité de C++ (quand utilisé comme du C++)
induit une certaine imprévisibilité, due chez moi très certainement à un
manque de pratique intensive. Je mettrais en parallèle votre préférence à
programmer OO en C avec celle, sur un automate, de dessiner un Graphcet à la
main et de programmer ce Graphcet sur l'automate en langage plus fruste
(ladder par exemple), même si une possibilité de programmer directement le
Graphcet existe.
Ceci me permet de préciser ma question. Puisque comme prévisible, il a été
plus répondu à [POO ou pas POO ?], alors que c'était plus [si pas POO, C
obligatoire ou C++ aussi bien ?].
C++ peut être vu comme un C légèrement corrigé, augmenté des concepts
fondamentalement différents que tout le monde connaît. Citons les classe
pour l'exemple, mais il y en a d'autres. Ces concepts ne me sont pas
indispensables, ni même réellement utiles dans l'exemple qui suit.
Pour fixer les idees, je suis sous un Windows quelconque, et je dispose d'un
compilateur (C++ 5.5 par exemple), qui me permet de compiler en C ou en C++.
Donc, la question économique ne se pose pas. Pour l'exemple, je n'ai pas une
pratique en C pur qui justifie d'ignorer C++. Toujours pour fixer les idées,
et peut-être à tort, bien maîtriser C à terme ne m'intéresse pas
particulièrement, alors qu'une bonne pratique de C++ me motive.

Etant donne le niveau de bidonnage (;-) de ton cahier des charges, et
tes motivations, je ne vois aucune raison de ne pas programmer
totalement en C++, quel que soit le paradigme adopte.

Maintenant, c'est mon opinion, et je la partage :-)
--
Bertrand Mollinier Toublet
"In regard to Ducatis vs. women, it has been said: 'One is a sexy thing
that you've just got to ride, even if it breaks down a lot, costs a lot
of money, and will probably try to kill you'. However, nowadays I can't
seem to remember which one is which." -- Peer Landa

Bertrand Mollinier Toublet wrote:

Etant donne le niveau de bidonnage (;-) de ton cahier des charges, et
tes motivations, je ne vois aucune raison de ne pas programmer
totalement en C++, quel que soit le paradigme adopte.

Maintenant, c'est mon opinion, et je la partage :-)

Roh la la, c'est la honte ce matin (oui, il est 8h15 chez moi). J'ecris
des bourdes grosses comme moi, je ne snippe pas correctement les posts
auxquels je reponds. Toutes mes excuses.

--
Bertrand Mollinier Toublet
"In regard to Ducatis vs. women, it has been said: 'One is a sexy thing
that you've just got to ride, even if it breaks down a lot, costs a lot
of money, and will probably try to kill you'. However, nowadays I can't
seem to remember which one is which." -- Peer Landa

Loïc Joly <loic.actarus.joly@wanadoo.fr> writes:

| Laurent Deniau wrote:
|
| > Et il me semble que numeric_limits n'a pas non plus ete simple a
| > mettre au point...
|
|
| Je n'ai jamais implémenté de compilo, mais numeric_limits me semble
| hyper simple à implémenter.

Ah oui, tu me montres comment ?

| C'est juste une classe template comme les
| autres, avec de la spécialisation, et une fois que je connais les
| types de base traités par le compilo, je pense pouvoir l'écrire
| directement.

Je vois. Yaka. Non, désolé cela ne marche pas. Been there, done that.

| Pour moi, son délai d'apparition dans gcc n'est du qu'au fait que
| c'est une tâche "ingrate" par rapport à implémenter la spécialisation
| partielle, ou les template template, et que donc ça a mis du temps à
| motiver quelq'un pour le faire.

Détrompe-toi, ce n'est pas une tâche ingrate pour un compilateur comme
GCC.

| Ca existait par exemple sur visual C++ 5.0 (c'est à dire avant 1997),
| est ça marchait déjà.

Combien de plateformes supporte Visual C++ 5.0 ?

-- Gaby

Richard Delorme <abulmo@nospam.fr> wrote in message
news:<3f4c8523$0$1789$7a628cd7@news.club-internet.fr>...

Sans oublier le mauvais support de la norme (et encore pour un
moment), la gestion des exceptions, le layout binaire des objets, la
portabilite de la STL, la stabilite des compilateurs... Autant
d'incompatibilites entre compilateurs, voir version d'un meme
compilateur. Il va falloir encore quelques annees avant d'atteindre
la stabilite du C89, meme si beaucoup d'efforts sont fait de ce
cote.

Je crois que tu es un peu de mauvaise fois. La norme actuelle du C qui
date de 1999 est sans doute nettement moins implémentée que la norme
ISO C++98.

Ce n'est pas dit. Mais ce n'est pas la question. Le fait est qu'il
existe en ensemble de C, à peu près équivalent à C90, qui est tout à
fait portable. Surtout, la norme C99 n'a pas cassé des programmes écrits
en C90, ni même ceux écrit en C K&R. Pour de diverses raisons, on ne
peut pas en dire autant pour le C++ ; écrire du code portable exige
d'avantage d'attention.

Évidemment, si la comparison est avec le C, la question se pose d'une
façon un peu différente. Un gros problème de portabilité en C++, par
exemple, c'est la recherche des noms dans les templates. Mais c'est un
problème qui a une solution triviale -- ne pas se servir des templates.
Si c'est un problème réel, c'est que beaucoup d'entre nous considère
cette solution pire que le problème. Mais quand on compare à C... Même
sans templates, le C++, c'est nettement plus que le C.

Les vendeurs de compilateurs C/C++ ont fait d'énorme efforts ces
derniers temps pour s'approcher de la norme ISO C++98, beaucoup plus
que pour le support de la norme ISO C99.

Il en faut beaucoup plus d'effort:-). Plus important, peut-être, c'est
qu'on n'a pas toujours la liberté de pouvoir utiliser la dernière
version.

Le dernier compilateur C++ de Microsoft supporte quasiment toute la
norme C++, et rien de la norme C99. La compatibilité binaire entre
compilateurs s'améliorent et les vendeurs s'arrangent pour développer
des ABI communes. Sous linux x86, par exemple, gnu-g++ > 3.2,
intel-icc 7.x, borland c++ builder 6.0 sont binairement compatibles.

Et sous Solaris, g++ et Sun CC sont toujours différents. Et que dans
certaines applications, nous ne pouvons pas nous servir de g++,
simplement parce qu'on n'a pas de licenses g++ pour des bibliothèques
dont on a besoin.

C'est un peu pour cette raison, d'ailleurs, que beaucoup de produits
présentent encore une interface C aux utilisateurs, et non C++. (Voir à
cet égard l'article de Hyslop et Sutter dans le CUJ de septembre.)

Et l'on commence sans doute à arriver à une maturité acceptable qui
fait qu'un programme C++ compilant aujourd'hui compilera encore
l'année prochaine.

Le problème, c'est qu'un programme C++ conforme ne se compile pas
aujourd'hui. On peut écrire du C++ portable, mais seulement en rénonçant
à beaucoup de chose.

En revanche, comme j'ai dit ci-dessus, ce n'est pas un argument par
rapport à C. Même aujourd'hui, le plus grand apport de C++, par rapport
à C, ce sont les contrôles d'accès et les fonctions membre. Et ça, on
peut s'en servir portablement, partout, et sans la moindre hésitation.
Ça, c'est le pain ; la reste -- et il y en a encore beaucoup qui marche
de façon portable, c'est du beurre.

--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

Gabriel Dos Reis wrote:

Desole pour le delai, mais je suis un peu charge ses derniers temps.

Laurent Deniau <Laurent.Deniau@cern.ch> writes:

| Gabriel Dos Reis wrote:
| > | > | > de 1999 est sans doute nettement moins implémentée que la norme
| > | > ISO C++98.
| > | > | | Certes, mais l'effort a fournir pour que C99 soit supporte est
| > | > bien
| > | > | moindre que pour C++98.
| > | >
| > | > qu'est-ce que tu en sais ?
| > | | Pretendre le contraire serait pour l'occasion de la vraie
| > mauvaise
| > | foi.
| > Pas du tout. As-tu implémenté l'une ou les deux spécifications ?
|
| Non. Toi non plus.

J'ai travaillé (et travaille toujours) sur l'implémentation des deux
-- cela fait partie de mon gagne pain.

| En dehors d'etre provocatrice, cette question est
| inutile et je ne te suivrais pas dans ce jeux la. Peu de gens (s'il en
| existe) ont implemente eux-meme l'une ou l'autre de ses specifications
| (ou une version anterieure) dans leur totalite.

Cette question n'est ni provocatrice ni inutile. Elle vise å savoir
quelle expérience tu as de l'implémentation de l'une des deux. Ton
inexpérience en l'implémentation de l'une des deux spécifications, ne
fait pas de la question posée quelque chose d'inutile ou provocateur.

Je n'ai travaille sur aucune des deux specifications (C++98 et C99). J'ai
travaille sur une sous-partie de C89 il y a 11 ans. J'ai ecrit divers parseurs
et interpreteurs, essentiellement des LALR(1) avec contexte. Rien du niveau de
ses deux specifications et heureusement pour moi. Je n'ai jamais ecrit
d'optimiseur. Je suis donc loin d'etre un expert en compilateur.

| > | Sans ironie, qu'est ce qui serait une avancee majeure dans C99 et
| > | qui demanderait tant de travail par rapport a C89 (ou C95) selon toi?
| > | Mis a part _Bool, long long, _Complex et les varlen array (en general
| > | deja tous supportes en 1999 avec une semantique proche) et la
| > | foultitude de types, macros et autres fonctions a ajoutees dans la
| > | libc et qui demande surtout du temps et de la main d'oeuvre? Par
| > | contre il y avait enormement a faire entre le C++ existant au moment
| > | de la sortie de C++98 et le C++ qu'elle specifie.
| > À part l'arrogance des assertions,
|
| Il n'y a ni arrogance, ni assertion. Toutes les phrases ont un ? et

Tu n'es pas sans ignorance qu'une phrase qui se termine pas un point
d'interrogation peut impliquer arrogance, assertion ; n'est-il pas ?

J'avais ajoute "sans ironie" me doutant que tu reagirais comme cela...

| c'est ton avis que je voulais puisque tu es implique dans le
| development de GCC.

et je te l'ai donné.

Non. La question etait qu'est ce qui dans C99 par rapport a C89 A1 en fait une
norme plus difficile a supporter que C98++ a partir de C89 A1?

« très proche » dépend de ta définition de « proche ».

Idem pour "C++98 serait bien mieux supporté avant C99". Depend de la definition
de "mieux".

[...]

Relis la spécification des VLA (sans préjugé aucun sur ce que tu
connias d'alloca) et tu te rendras compte alloca est aussi proche des
VLA que uranus est proche du soleil.

| - les VMT posent effectivement des problemes et demandent de modifier
| le systeme de typage en profondeur, mais techniquement ce n'est pas un
| probleme inconnu et encore jamais resolu.

La plupart des compilateurs à vocation industrielle ne sont pas des
gadgets universitaires jetables après première utilisation. Ce sont
des logiciels évolutifs où chaque version est le fruit d'itérations
sur la version précédente. Le compilateur évolue mais garde un fond
plus ou moins immuable, basé sur une certaine compréhension de la
machine abstraite C et son système de types. Les VMT viennent
bouleverser cela, et en profoondeur. Concrètement, cela veut dire que
pour la plupart des compilateurs, il faut revoir la machinerie qui
fait la vérification sémantique, la conception du système de type et
interaction avec les extensions (tout le monde est contre et tout le
monde en veut). Ce sont des problèmes pratiques que l'univeristaire
dans son labo ne considère pas -- probablement parce qu'il vit dans un
monde parallèle. Mais le fabriquant de compilateur ne peut pas les
ignorer. Il doit les résoudre, assez rapidement. La question n'est pas
qu'il n'existe pas un papier académique qui prétend traiter le sujet
dans un cadre de travail ultra simplifié, c'est que l'universitaire
n'a qu'une vision très parcellaire du langage, des fonctionnalités et
des contraintes pratiques. Des choses qu'on ne traite en général pas
dans les papiers académiques. Ce qui laisse souvent dire que le
problèment est techniquement résoluble et donc qu'il n'y a pas de
problème. C'est-à-dire une ignorance de la réalité.

Bien. Mais C++98 aussi a necessite un changement du systeme de type par rapport
a C89 avec en plus un changement sur la gestion de la duree de vie des
temporaires. C'est pas plus complique que les VMT?

[...]

| > ne sembles le croire. La nouvelle sémantique des opérations flottantes
| > est au moins de deux ordres de magnitude difficiles à supporter qu'un
| > pendant en C++ avec une volution bibliothèque. C'est encore plus
|
| Si tu fais allusion a la classe complex,

Non. Je fais allusion au fait que le langage aurait dû fournir des
fonctionnalités assez générales pour faciliter des solutions
bibliothèques efficaces, au lieu de mettre en dur des fonctionnalités
qui au fond ne profite qu'à une fraction de la communauté.

| elle sera consideree comme une heresie par certains experts

qu'est-ce qui en ferait une hérésie selon ces « certains experts » ?

une liste rapide qui me vient a l'esprit:
- les arguments sont passes par reference mais rien n'est dit sur l'aliasing.
Est-ce que:
complex<float> z(2.0,3.0);
z *= z; z = z * z;
est autorise et est gere correctement par tous les compilos?
- rien ne dit si complex<double> est equivalent a double[2] ce qui empeche la
compatibilite avec la pluspart des librairies de calcul. Par exemple on doit
reecrire la multiplication de deux polynomes complexes in situ au lieu
d'utiliser fftw.
- il manque les fonctions reciproques et hyperboliques reciproques.
- elle ne gere pas les promotions usuelles telles que decritent dans C99.
- il n'y a aucune recommandation sur la stabilite de z / z ou abs(z).

| Et il me semble que numeric_limits n'a pas non plus ete simple a
| mettre au point...

Explique-toi.

Je ne fais que repeter ce que tu m'as dit il y a 4 ou 5 ans quand je demandais
pourquoi gcc ne fournissait pas de numeric_limits dont j'avais cruellement besoin.

| Mais je ne t'apprends rien, je sais que tu es un expert sur ces deux sujets.

En fait, je suis curieux d'en savoir un peu plus sur ces allusions vagues.

|
| > difficile qu'il faut modifier profondément l'architecture de nombre
| > de compilateurs majeurs existants. Comment implémentes-tu les
| > type-generic macros?
|
| une magie tu meme genre que typeof?

Non. Une fois que tu as le typeof, qu'est-ce que tu en fais ?

#define sqrt(a)
(typeof(a) == typeof(long double complex) ? csqrtl(a) :
(typeof(a) == typeof(double complex) ? csqrt(a) :
...

Je pense qu'on commence a etre franchement HS.

a+, ld.

--
[ Laurent Deniau -- Scientific Computing & Data Analysis ]
[ CERN -- European Center for Nuclear Research ]
[ Laurent.Deniau@cern.ch - http://cern.ch/Laurent.Deniau ]
[ -- One becomes old when dreams become regrets -- ]

"Pierre Maurette" <pierre.maurette@laposte.net> wrote in message
news:<3f4eec4e$0$244$626a54ce@news.free.fr>...

"Laurent Deniau" <Laurent.Deniau@cern.ch> a écrit dans le message de
news: 3F4C53B1.4090404@cern.ch...
...

J'ai utilise' le C++ de 1989 (zortech 1.0 :-) a 1999. Je continue de
temps en temps pour ne pas perdre contact car sur le plan des
concepts, c'est un language tres interessant. J'ai egalement regarde
Objective-C, Eiffel et Java (et beaucoup d'autres pour la culture)
mais pour l'instant aucun ne m'a seduit plus que le C et le C++.

Mais le C++ est deux (voir trois) ordres de magnitude plus complexe
que le C. Il est tres facile de faire n'importe quoi en C++ et de ne
plus s'y retrouver. Et c'est encore plus difficile de le faire
comprendre a ses collaborateurs (surtout s'ils manquent
d'experience) lorsque vous mixez plusieurs facettes du C++ (heritage
multiple, heritage virtuel, methodes virtuelles, membres static,
template, traits, template expressions, exceptions).

Pour répendre selon Robert Martin, la complexité aujourd'hui est déjà
présente dans ce que le programme doit faire. Si elle n'est pas dans le
langage (qu'on doit maîtrise une fois pour toute), elle le serait dans
l'implémentation de l'application (qu'on doit maîtriser pour chaque
application).

À toi de choisir. Pour des applications vraiment simple, le C est très
bien. Mais même là, il n'y a rien qui impose l'utilisation de tout le
langage (C ou C++) dans chaque application -- dans mon cas, je m'en sers
pas des types virgule flottant, par exemple. Et à mon avis, les
contrôles d'accès, à eux seuls, justifie l'utilisation de C++ plutôt que
C.

[...]

Ceci me permet de préciser ma question. Puisque comme prévisible, il a
été plus répondu à [POO ou pas POO ?], alors que c'était plus [si pas
POO, C obligatoire ou C++ aussi bien ?].

Peut-être parce que ce n'est pas clair ce que représente le POO pour
toi. Moi, il ne me viendrait pas à l'ésprit d'écrire du C++ sans les
classes et sans les modes d'accès. En revanche, je peux très bien
concevoir des applications assez simples pour qu'on n'a besoin de rien
d'autre du langage (bien que... pourquoi écrire ta propre classe de
string ou de vector, quand il y en a une tout fait qui marche?).

C++ peut être vu comme un C légèrement corrigé, augmenté des concepts
fondamentalement différents que tout le monde connaît. Citons les
classe pour l'exemple, mais il y en a d'autres. Ces concepts ne me
sont pas indispensables, ni même réellement utiles dans l'exemple qui
suit.

Pour fixer les idees, je suis sous un Windows quelconque, et je
dispose d'un compilateur (C++ 5.5 par exemple), qui me permet de
compiler en C ou en C++. Donc, la question économique ne se pose pas.
Pour l'exemple, je n'ai pas une pratique en C pur qui justifie
d'ignorer C++. Toujours pour fixer les idées, et peut-être à tort,
bien maîtriser C à terme ne m'intéresse pas particulièrement, alors
qu'une bonne pratique de C++ me motive.

Ma question est de savoir si les défauts que vous évoquez pour C++
existent dans un C++ réduit au "cahier des charges" de C.

Je dois écrire une petite appli, par exemple une édition de facture.
Pas de base de donnée qui pourrait orienter mon choix, quelques
fichiers textes joueront ce rôle. L'appli est en mode console, je
souhaiterais pouvoir la recompiler pour Linux avec le minimum de
travail supplémentaire. Please, pas de réponse sur ce cahier des
charges, il est totalement bidon. Bien entendu, ce travail est
parfaitement faisable en C pur.

C'est *faisable* même en assembleur.

Dans les startégies suivantes, à quel moment me trompé-je ?
1- Ecriture du bouzin en C.
2- Ecriture du bouzin en C++ "comme en C", c'est à dire pratiquement
le même code. Aux facilités syntaxiques près, puisque je suis sensé ne
pas avoir d'habitudes héritées du C. Par exemple, utilisation du type
bool, commentaires //, etc.

3- Comme le pécédent, mais en utilisant quelques concepts (hors POO)
propres à C++ qui me facilitent semble-t-il la vie, disons les
exceptions pour fixer les idées. Pointeurs -> références ? ?alloc/free
-> new/delete ?

Je ne sais pas si tu comprends ça dans la POO, mais je ne me passerais
pas des classes. Avec des constructeurs, un destructeur, des données
privées et des fonctions membres. Je le faisais déjà plus ou moins en C,
mais c'est tellement plus facile en C++. Et des idiomes comme RAII n'ont
pas besoin des exceptions pour être utile, ou pour rendre le code plus
simple et plus compréhensible.

Comme j'ai dit ci-dessus, la complexité (gerer les ressources) y est,
quelque soit le langage. La seule question, c'est si tu préfères qu'elle
y soit explicitement, et que tu le maîtrises de nouveau dans chaque
application, ou si tu préfères qu'elle soit dans le langage, et que tu
ne le maîtrises qu'une fois. À toi de choisir.

4- Comme en 2 (ou 3), mais en utilisant iostream à la place de stdio.h
pour les E/S standard. (A partir de là, il ne s'agit plus de faire du
C avec un compilateur C++, mais bien du C++)

Toujours iostream à la place de stdio -- je vais vouloir sortir les
types que j'ai écrit, et en entrée, le concepte des streambuf filtrant
rend la gestion des commentaires beaucoup plus simple. On peut le faire
très bien avec scanf, mais la spécification du formattage est loin
d'être simple, et ce n'est pas si évident comment on detecte et qu'on
traite le cas où une ligne d'entrée est plus longue que le buffer prévu.

5- J'ai une petite classe destinée à afficher en français une valeur
monétaire. Ellle utilise la classe std::string (en fait, elle
utilisait initialement AnsiString de la VCL Borland). Est-ce embêtant
de conserver une seule classe dans une appli résolument non POO ? Et
d'en extraire la fonction utile, mais en conservant std::string ?

En général (mais ce n'est pas universel), quand on parle de la POO, on
parle du polymorphisme dynamique, et non le simple cas d'avoir des
classes. Du moment que j'ai à traiter du texte, par exemple, je ne me
passerais aucunement de std::string (ou une autre classe de chaîne, dans
le cas du code ancien). Ne pas avoir à s'occuper constamment de la
gestion de la mémoire, c'est un tel simplification qu'il serait idiote
de s'en passer.

--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

Laurent Deniau <Laurent.Deniau@cern.ch> writes:

[...]

| > | > | Sans ironie, qu'est ce qui serait une avancee majeure dans C99 et
| > | > | qui demanderait tant de travail par rapport a C89 (ou C95) selon toi?
| > | > | Mis a part _Bool, long long, _Complex et les varlen array (en general
| > | > | deja tous supportes en 1999 avec une semantique proche) et la
| > | > | foultitude de types, macros et autres fonctions a ajoutees dans la
| > | > | libc et qui demande surtout du temps et de la main d'oeuvre? Par
| > | > | contre il y avait enormement a faire entre le C++ existant au moment
| > | > | de la sortie de C++98 et le C++ qu'elle specifie.
| > | > À part l'arrogance des assertions,
| > | | Il n'y a ni arrogance, ni assertion. Toutes les phrases ont un ?
| > et
| > Tu n'es pas sans ignorance qu'une phrase qui se termine pas un point
| > d'interrogation peut impliquer arrogance, assertion ; n'est-il pas ?
|
| J'avais ajoute "sans ironie" me doutant que tu reagirais comme cela...

tu as mal douté.

| > | c'est ton avis que je voulais puisque tu es implique dans le
| > | development de GCC.
| > et je te l'ai donné.
|
| Non.

C'est marrant. Tu me demandes mon avis, je te le donne et tu réponds
que je ne te l'ai pas donné.

| La question etait qu'est ce qui dans C99 par rapport a C89 A1 en
| fait une norme plus difficile a supporter que C98++ a partir de C89 A1?
|
| > « très proche » dépend de ta définition de « proche ».
|
| Idem pour "C++98 serait bien mieux supporté avant C99". Depend de la
| definition de "mieux".

je vois. Et qu'elle est ta définition de « mieux » ?

[...]

| Bien. Mais C++98 aussi a necessite un changement du systeme de type
| par rapport a C89

C++ ne dérive pas de C89. Cela fait beaucoup de différence plus que tu
ne peux l'imaginer.

| avec en plus un changement sur la gestion de la
| duree de vie des temporaires. C'est pas plus complique que les VMT?

Non. La seule chose compliquée, c'est les sutilisateurs ;-)

| [...]
| > | > ne sembles le croire. La nouvelle sémantique des opérations flottantes
| > | > est au moins de deux ordres de magnitude difficiles à supporter qu'un
| > | > pendant en C++ avec une volution bibliothèque. C'est encore plus
| > | | Si tu fais allusion a la classe complex,
| > Non. Je fais allusion au fait que le langage aurait dû fournir des
| > fonctionnalités assez générales pour faciliter des solutions
| > bibliothèques efficaces, au lieu de mettre en dur des fonctionnalités
| > qui au fond ne profite qu'à une fraction de la communauté. | elle
| > sera consideree comme une heresie par certains experts
| > qu'est-ce qui en ferait une hérésie selon ces « certains experts » ?
|
| une liste rapide qui me vient a l'esprit:
| - les arguments sont passes par reference mais rien n'est dit sur l'aliasing.

Parce que qu'il n'y a rien à dire. As-tu lu la spécification ?

| Est-ce que:
| complex<float> z(2.0,3.0);
| z *= z; z = z * z;
| est autorise

La réponse est dans la spécification.

| et est gere correctement par tous les compilos?

si tu trouves un compilateur qui ne le gère pas correctement suivant
la spécification de la norme, tu as trouvé un bug dans le compilo.
Moi, je n'en ai pas toruvé.

| - rien ne dit si complex<double> est equivalent a double[2]

On n'a pas besoin qu'il soit équivalent. Il suffit qu'il soit compatible.
Je ne connais pas une seule implémentation de C++ où ce n'est pas le cas.
Jette un coup d'oeil à

http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#387

| - il manque les fonctions reciproques et hyperboliques reciproques.

et cela en fait une hérésie ?

| - elle ne gere pas les promotions usuelles telles que decritent dans C99.

je n'en vois pas la nécessité et je ne considère pas que c'est une hérésie.

| - il n'y a aucune recommandation sur la stabilite de z / z ou abs(z).
|
| > | Et il me semble que numeric_limits n'a pas non plus ete simple a
| > | mettre au point... Explique-toi.
|
| Je ne fais que repeter ce que tu m'as dit il y a 4 ou 5 ans quand je
| demandais pourquoi gcc ne fournissait pas de numeric_limits dont
| j'avais cruellement besoin.

sauf que tu as oublié le contexte. Fournir numeric_limits<> sur une
architecture donnée n'est pas difficile (quelqu'un l'a fait remarqué
dans ce thread). Fournir numeric_limits<> dans GCC pour tous les
plateformes qu'il supporte est une autre histoire.

| > | Mais je ne t'apprends rien, je sais que tu es un expert sur ces deux sujets.
| > En fait, je suis curieux d'en savoir un peu plus sur ces allusions
| > vagues.
| > | | > difficile qu'il faut modifier profondément l'architecture de
| > nombre
| > | > de compilateurs majeurs existants. Comment implémentes-tu les
| > | > type-generic macros?
| > | | une magie tu meme genre que typeof?
| > Non. Une fois que tu as le typeof, qu'est-ce que tu en fais ?
|
| #define sqrt(a)
| (typeof(a) == typeof(long double complex) ? csqrtl(a) :
| (typeof(a) == typeof(double complex) ? csqrt(a) :

l'as-tu essayé ? ou c'est juste une autre illustration de yaka ?

| Je pense qu'on commence a etre franchement HS.

NON. Savoir comment implémenté <tgmath.h> n'est pas HS sur groupe.

-- Gaby

kanze@gabi-soft.fr writes:

| > Et l'on commence sans doute à arriver à une maturité acceptable qui
| > fait qu'un programme C++ compilant aujourd'hui compilera encore
| > l'année prochaine.
|
| Le problème, c'est qu'un programme C++ conforme ne se compile pas
| aujourd'hui.

Cela dépend de quel compilateur tu utilises. Et la même chose est
vraie pour C. So ?

-- Gaby

kanze@gabi-soft.fr writes:

[...]

| En général (mais ce n'est pas universel), quand on parle de la POO, on
| parle du polymorphisme dynamique, et non le simple cas d'avoir des
| classes. Du moment que j'ai à traiter du texte, par exemple, je ne me
| passerais aucunement de std::string (ou une autre classe de chaîne, dans
| le cas du code ancien). Ne pas avoir à s'occuper constamment de la
| gestion de la mémoire, c'est un tel simplification qu'il serait idiote
| de s'en passer.

Il y a un an, je formais des programmeurs professionnels C à C++.
Au premier cours, je voulais avoir une idée de comment ils s'attaquent
à ce genre de problème. Je leur avais demandé un programme (en C) qui
lit une suite de chaînes de caractères depuis l'entrée standard, la
trie et sort le résultat sur la sortie standard. Ils oont tous, presque
sans exception, écrit un programme qui m'a donné l'impression de faire
de la gestion de mémoire au lieu de répondre à la question posée.

-- Gaby

Gabriel Dos Reis wrote:

| Bien. Mais C++98 aussi a necessite un changement du systeme de type
| par rapport a C89

C++ ne dérive pas de C89. Cela fait beaucoup de différence plus que tu
ne peux l'imaginer.

Admettons. Disons Traditionnal C + Simula. Et apres? Cela va dans le sens de mes
propos donc je ne comprends pas tes protestations precedentes.

| avec en plus un changement sur la gestion de la
| duree de vie des temporaires. C'est pas plus complique que les VMT?

Non. La seule chose compliquée, c'est les sutilisateurs ;-)

| [...]
| une liste rapide qui me vient a l'esprit:
| - les arguments sont passes par reference mais rien n'est dit sur l'aliasing.

Parce que qu'il n'y a rien à dire. As-tu lu la spécification ?

| Est-ce que:
| complex<float> z(2.0,3.0);
| z *= z; z = z * z;
| est autorise

La réponse est dans la spécification.

Autant pour moi. Je n'avais pas regarde attentivement les "Returns:". Le fait
est qu'on commence par faire une copie de lhs...

| - rien ne dit si complex<double> est equivalent a double[2]

On n'a pas besoin qu'il soit équivalent. Il suffit qu'il soit compatible.
Je ne connais pas une seule implémentation de C++ où ce n'est pas le cas.

Mais ca n'est pas garanti. Dans le header de gcc je trouve

template <class _FLT>
class complex
{
[...]
private:
_FLT re, im;
[...]
}

et ce n'est pas garanti d'etre compatible avec:

template <class _FLT>
class complex
{
[...]
private:
_FLT val[2];
[...]
}

Jette un coup d'oeil à

http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#387

Je l'avais deja lu et j'etais totalement d'accord.

| - il manque les fonctions reciproques et hyperboliques reciproques.

et cela en fait une hérésie ?

Les "experts" sont des extremistes. Tout ce qui n'est pas correct et precis est
une heresie. CQFD.

Plus serieusement, cela en fait une classe incomplete alors qu'il aurait ete
facile de la rendre complete sur ce point, meme si cela demande de preciser les
branches retournees. C'est vrai aussi que l'on peut les ecrires soi-meme vu que
ce ne sont pas des fonctions membres. Ce que j'avais d'ailleurs fait et je
t'avais envoye une copie par email a la suite de la lecture de ton lien.

| - elle ne gere pas les promotions usuelles telles que decritent dans C99.

je n'en vois pas la nécessité et je ne considère pas que c'est une hérésie.

Sans etre une heresie, Blitz++ et la SL++ consideraient cela comme utile pour
simplifier les algos.

| - il n'y a aucune recommandation sur la stabilite de z / z ou abs(z).
|
| > | Et il me semble que numeric_limits n'a pas non plus ete simple a
| > | mettre au point... Explique-toi.
|
| Je ne fais que repeter ce que tu m'as dit il y a 4 ou 5 ans quand je
| demandais pourquoi gcc ne fournissait pas de numeric_limits dont
| j'avais cruellement besoin.

sauf que tu as oublié le contexte. Fournir numeric_limits<> sur une
architecture donnée n'est pas difficile (quelqu'un l'a fait remarqué
dans ce thread). Fournir numeric_limits<> dans GCC pour tous les
plateformes qu'il supporte est une autre histoire.

Je n'ai pas parle du cadre restreint d'une seule architecture mais de C++98 vs
C99. Et je pense que gerer tout ce qui touche de loin ou de pret aux NaN n'est
pas simple (tu sais les ... dans l'exemple :-) meme si on prerequiert iec559 ou
ieee754. D'ailleurs (du moins dans le draft) je n'ai rien sur les fonctions
entre les has_ et les is_

| > Non. Une fois que tu as le typeof, qu'est-ce que tu en fais ?
|
| #define sqrt(a)
| (typeof(a) == typeof(long double complex) ? csqrtl(a) :
| (typeof(a) == typeof(double complex) ? csqrt(a) :

l'as-tu essayé ? ou c'est juste une autre illustration de yaka ?

typeof n'est pas standard, donc on est en droit d'en attendre ce que l'on veut.
Je me demande d'ailleurs s'il n'y pas un GNUisme recent qui permet de faire ca.

| Je pense qu'on commence a etre franchement HS.

NON. Savoir comment implémenté <tgmath.h> n'est pas HS sur groupe.

Ce n'est pas du tout ma preoccupation. Ma question de depart n'a pas eu de
reponse et reste d'actualite. Tu as donnes des arguments en faveurs et des
assertions en opposition. La nouvelle specification des flottants ne contre
balance pas ne serait-ce que la gestion des templates. Je ne suis donc toujours
pas convaincu que C99 est plus difficile a implemente que C++98 par rapport a
l'existant au moment de la sortie de leur norme respective.

a+, ld.

--
[ Laurent Deniau -- Scientific Computing & Data Analysis ]
[ CERN -- European Center for Nuclear Research ]
[ Laurent.Deniau@cern.ch - http://cern.ch/Laurent.Deniau ]
[ -- One becomes old when dreams become regrets -- ]