Pourquoi du C pur ?

Existe-t-il des plateformes pour lesquelles l'offre est plus restrictive,
et

ne propose pour un prix donné qu'un compilateur C ?

Je programme des micro-controleurs (systèmes embarqués) et il n'y a bien
souvent que des compilateurs C de disponibles ;ce qui est logique, le C
étant le langage les plus adapté pour ce type d'application (contraintes de
taille - quelques 10aines de k de code - et contraintes de vitesse
d'exécution - avec un bon compilateur bien optimisé, on aurait pas fait
mieux en écrivant directement en assembleur)

Bien entendu, on ne programme pas que des ordinateurs, mais je connais un
peu l'informatique industrielle (ou automatisme) et justement il ne me
semble pas que ce domaine soit spécialement réfractaire au C++.

Pour des applications "bas niveau" style drivers, controle de processus,...
il est vrai que ça pourrait être faisable en c++ mais un niveau
d'abstraction élevé est inutile pour ce type d'applications et ne fait que
complexifier et alourdir l'application.


Tout cela n'est évidemment qu'une question de gouts, il y a des gens qui
programment des micros en C++ et d'autres des interfaces graphiques en C
mais je trouve que chaque type d'application a ses outils spécifiques avec
leurs avantages et leurs inconvénients.

Pierre Maurette wrote:

Bonjour,
Je me décide à poser cette question certainement peu originale.
(snip)

Pas POO -> pourquoi C et non C++ ? (c'est ma question).

Honnêtement, et à titre tout à fait personnel, si ce n'est pas pour
utiliser les possibilités de programmation générique (templates) ou OO,
je ne vois guère l'intérêt d'utiliser C++ plutôt que C.

Bruno

Pierre Maurette wrote:

Pas POO -> pourquoi C et non C++ ? (c'est ma question).

D'abord parce que les compilateur C existent sur quasiment toutes les
plateformes contrairement au C++.

Ensuite les compilateur C++ implemente plus ou moins bien la norme
contrairement au C, plus "simple" et qui est relativement bien
implémenté par les concepteurs de compilateur.

Enfin les compilateurs C++ modifie le nom des fonctions (le name
mangling ou decoration) de facon a permettre la surchage (plusieurs
fonctions avec le meme nom mais des arguments différents). Or jusqu'a
une periode recente chaque compilateur avait sa propre facon de modifier
le nom. Il en resultait qu'une librairie crée par un compilateur ne
pouvait etre utilisée que par un programme compilé par le meme compilateur.

Ca fait au moins trois bonnes raisons, mais il y en a certainement d'autres.


A+

LD

Laurent DELEPINE wrote:

Pierre Maurette wrote:

Pas POO -> pourquoi C et non C++ ? (c'est ma question).

D'abord parce que les compilateur C existent sur quasiment toutes les
plateformes contrairement au C++.

Ensuite les compilateur C++ implemente plus ou moins bien la norme
contrairement au C, plus "simple" et qui est relativement bien
implémenté par les concepteurs de compilateur.

Enfin les compilateurs C++ modifie le nom des fonctions (le name
mangling ou decoration) de facon a permettre la surchage (plusieurs
fonctions avec le meme nom mais des arguments différents). Or jusqu'a
une periode recente chaque compilateur avait sa propre facon de modifier
le nom. Il en resultait qu'une librairie crée par un compilateur ne
pouvait etre utilisée que par un programme compilé par le meme compilateur.

Ca fait au moins trois bonnes raisons, mais il y en a certainement
d'autres.

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.

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 wrote:

POO -> C++ (ou autre chose).
POO pur et dur -> autre chose
Pas POO -> pourquoi C et non C++ ? (c'est ma question).

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

Il y a aussi plein d'autres raisons plus subjectives.

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 -- ]

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.
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. 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 l'on commence sans doute à arriver à une maturité
acceptable qui fait qu'un programme C++ compilant aujourd'hui compilera
encore l'année prochaine.

--
Richard

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


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

Mauvais principe, changer de principe.

Les gens devraient pas lire les en-têtes, mais les spécifications et
les documentations.

[...]

| o on controle (presque) tout,

ce n'est qu'une (fausse) impression. De fait, on contrôle *moins* en C
qu'en C++. Pense typage, portée et abstraction. Ce sont des notions
premières de la programmation, mais il n'y a pratiquement rien en C
pour les supporter efficacement.

[...]

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

Si l'on doit prendre le « niveau basique » des questions comme
critère, alors la conclusion seraint plutôt qu'on ne fait rien
d'intéressant en C, ou que les gens qui l'utilise sont encore en
petites culottes et ne sont pas encore arrivés à maturité.
Mais, ce n'est pas le cas. De fait, le « niveau basique » des questions
ne donne pas une idée de la complexité requise pour résoudre un
problème en utilisant le C. Je dirais plutôt que cela en dit plus long
sur le niveau des gens qui fréquentent le groupe ou qui y posent des
questions. En comparaison, je te demanderais de regarder le niveau des
questions sur comp.std.c ou comp.lang.c.moderated par exemple.

J'utilise le C quotidiennement pour implémenter des compilateurs ; mes
collègues et moi sommes à arriver au consensus que le C rend le
développement plus long et plus difficile, justement par manque de
support d'abstractions et de typages. Il nous a fallu écrire un
système de types et contrôler les expressions pendant l'exécution du
programme (et cela prend un temps non négligeable, allant de 50% à
200% de temps de l'éxecution normale). Le nombre de bugs fixés qui
auraient pu être évités par un typage décent est incalculable.

J'utilise le C++ qoutidiennement aussi pour implémenter des
bibliothèques de complexité trois à cinq fois plus grande que les
compilateurs C en question, et en toute franchise, je rencontre très
peu de problèmes par rapport au projet mentionné ci-dessus.

-- Gaby

Richard Delorme wrote:

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

C'est un groupe sur le C :-)

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 supportee est bien moindre
que pour C++98. Cela ne veut pas dire que C++98 ne sera pas supportee avant C99.
Mais disons que pour que C99 soit supportee, cela demande une volonte de la part
du fabiquant du compilateur et rien d'autre, en particulier l'ABI ne change pas
(a ma connaissance). Pour que C++98 soit supportee *completement*, cela demande
une collaboration avec d'autres fabriquants de compilateur, voir d'OS, ou alors
il le livre avec ses binutils et son lot d'incompatibilites.

La compatibilité binaire entre compilateurs s'améliorent et les vendeurs
s'arrangent pour développer des ABI communes. Sous linux x86, par exemple,

Est ce que tous garantissent d'etre capable de traiter mutuellement les
exceptions des autres? L'heritage virtuel? RTTI? Comportement lors d'un
bad_alloc? Et jusqu'a quand? Quand de nouvelles techniques permettront de faire
mieux, par exemple pour diminuer l'overhead d'un try ou optimiser le layout
binaire d'objet complexe, qu'adviendra-t-il de ses bonnes resolutions?

Plus il y a de points ou une collaboration est necessaire, plus il y a de
possibilite de conflit et d'incompatibilite. Meme si rien n'est garanti ni en C
ni en C++, par nature ce dernier a d'avantage de points pretant a litige.

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.

M'est avis qu'une nouvelle version de la norme sortira avant que C++98 soit
complement supportee. Ca serait meme peut-etre souhaitable.

Pour finir, oui je suis de mauvaise foi :-)

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 -- ]

Gabriel Dos Reis wrote:

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


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

Mauvais principe, changer de principe.

Principe venant de Kernighan et il ne parlait pas d'un language en particulier :-)

Les gens devraient pas lire les en-têtes, mais les spécifications et
les documentations.

Qui sont presque toujours obsolete ou inconsistante? C'est pas toi qui disait
"the source is the documentation?"

Ceci dit l'un n'empeche pas l'autre. Une fois export supporte, il faut esperer
un allegement des entetes et un retour a des entetes claires et explicite.

[...]

| o on controle (presque) tout,

ce n'est qu'une (fausse) impression. De fait, on contrôle *moins* en C
qu'en C++. Pense typage, portée et abstraction. Ce sont des notions

Je parlais de l'ABI, stable, connue, peu-evoluee (comme le C) et sans surprise a
part qque trucs exotiques genre les signaux ou setjmp.

premières de la programmation, mais il n'y a pratiquement rien en C
pour les supporter efficacement.

C'est vrai et je regrette que C99 n'ai pas fait un pas dans ce sens.

Mais un peu de programmation defensive au runtime avec du dynamic typing peu
aider beaucoup. L'overhead n'est pas insupportable. Mais ca demande des tests
plus complique.

[...]

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

Si l'on doit prendre le « niveau basique » des questions comme
critère, alors la conclusion seraint plutôt qu'on ne fait rien
d'intéressant en C, ou que les gens qui l'utilise sont encore en
petites culottes et ne sont pas encore arrivés à maturité.
Mais, ce n'est pas le cas. De fait, le « niveau basique » des questions
ne donne pas une idée de la complexité requise pour résoudre un
problème en utilisant le C. Je dirais plutôt que cela en dit plus long
sur le niveau des gens qui fréquentent le groupe ou qui y posent des
questions. En comparaison, je te demanderais de regarder le niveau des
questions sur comp.std.c ou comp.lang.c.moderated par exemple.

Entierement d'accord. Mais plus de la moitie des questions postees sur ces
newsgroup pourraient l'etre sur leur pendant C++ sans etre HS. De fait, les
questions sur le C++ mais ayant une nature C ne seront pas posees sur un NG C++
alors qu'elle pourrait l'etre pour avoir une reponse plus complete. Par exemple
une question comme "When do pointers match" aura une reponse compliquee en C et
encore plus compliquee en C++.

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 -- ]

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

| Richard Delorme wrote:
| >
| >>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
|
| C'est un groupe sur le C :-)

et alors ?

| > 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 supportee est bien
| moindre que pour C++98.

qu'est-ce que tu en sais ?

| Cela ne veut pas dire que C++98 ne sera pas supportee avant C99.

je prédis que C++98 serait bien mieux supporté avant C99.

| Mais disons que pour que C99 soit supportee, cela
| demande une volonte de la part du fabiquant du compilateur et rien
| d'autre, en particulier l'ABI ne change pas (a ma connaissance).

la norme C (et aussi C++) ne spécifie pas une ABI. Ce sont deux choses
complètement orthogonales. L'ABI sur Itanium a bien changé par rapport
à x86, en ce qui concerne le C90.

[...]

| > La compatibilité binaire entre compilateurs s'améliorent et les vendeurs
| > s'arrangent pour développer des ABI communes. Sous linux x86, par exemple,
|
| Est ce que tous garantissent d'etre capable de traiter mutuellement
| les exceptions des autres? L'heritage virtuel? RTTI? Comportement lors
| d'un bad_alloc? Et jusqu'a quand? Quand de nouvelles techniques
| permettront de faire mieux, par exemple pour diminuer l'overhead d'un
| try ou optimiser le layout binaire d'objet complexe, qu'adviendra-t-il
| de ses bonnes resolutions?

et si tu faisais ton devoir de maison ?

[...]

| > 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.
|
| M'est avis qu'une nouvelle version de la norme sortira avant que C++98
| soit complement supportee.

en l'occurence, il existe une implémentation complète de C++98 avant
que C++2003 ne sorte.

-- Gaby