Bonjour,
Je me décide à poser cette question certainement peu originale. Mais
pourtant, j'ai cherché, et pas de réponse satisfaisante (en 2003).
J'ai chargé la FAQ de fclc en format PDF, bravo pour le document, mais pas
vraiment trouvé ma réponse.
Rien non plus dans le doc ISO/IEC 9899:1999, pourtant, vu que cette dernière
normalisation du C est postérieure à la dernière du C++, je pensais que le
sujet aurait été évoqué.
Dans Google, pas trouvé le mot-clé qui tue en français ("c ou c++" donne des
résultats, mais dans le sens C/C++). En anglais, "C vs C++" OR "C++ vs C"
donne bien 2500 résultats, mais la question posée est généralement, dans des
références souvent anciennes, "Pourquoi passer au C++ ?", voire "Pourquoi la
POO ?". Questions pertinentes que j'ai connues, mais à l'époque de
l'apparition réelle de C++ sur le marché. Mais aujourd'hui, je dirais :
POO -> C++ (ou autre chose).
POO pur et dur -> autre chose
Pas POO -> pourquoi C et non C++ ? (c'est ma question).
Je vais tenter de préciser. Je ne connais par la pratique de la
programmation que les plateformes "grand-public", actuellement PC (x86) sous
divers OS et Apple.
Quelles peuvent être les raisons, pour de nouveaux projets, de se
contraindre à programmer en C ? La question ne porte pas sur l'utilisation
ou non des objets, voire de la STL, puisque leur utilisation peut être
évitée ou différée (dans le cadre d'une démarche pédagogique, ou
d'auto-apprentissage).
J'ai écrit "se contraindre". Les compilateurs que je connais permettent tous
de choisir le langage, entre un (ou plusieurs) C++ et un (ou plusieurs) C.
En d'autres termes, sur les plateformes que je pratique, l'acquisition d'un
compilateur C met souvent à votre disposition un compilateur C++, que vous
le vouliez ou non.
Existe-t-il des plateformes pour lesquelles l'offre est plus restrictive, et
ne propose pour un prix donné qu'un compilateur C ?
Bien entendu, la simple maintenance d'un développement existant en C impose
de pratiquer ce langage, La culture interdit d'ailleurs de l'ignorer.
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++.
Certains parmi vous font-ils parfois du C, parfois du C++, et si oui, selon
quels critères et pour quelles raisons ? Simplement parce qu'il s'agit d'un
choix du client, peut-être ?
Plus vraisemblablement, il y a entre C et C++ (dégradé) une différence qui
m'aura échappé.
Voilà, je compte sur vous pour éclairer ma lanterne.
Cordialement,
Pierre
Une légende circule selon laquelle, en 1998, Bjarne Stroustroup a donné une interview pour le magazine Computer de IEEE, dans laquelle il a expliqué ses vraies motivations en créant C++. Ca décape tellement que la rédaction aurait décidé de ne pas publier le texte, "pour le bien de l'industrie". Il aurait ensuite transpiré confidentiellement...
J'ai lu ce texte (en Anglais), et effectivement ça envoie le pâté. Mais peut-être n'est-ce qu'un hoax ?
Quelqu'un aurait-il des précisions pour confirmer ou infirmer cette histoire ?
Cordialement,
PB
"Pierre Maurette" a écrit dans le message news: 3f4b07b6$0$6203$
Bonjour, Je me décide à poser cette question certainement peu originale. Mais pourtant, j'ai cherché, et pas de réponse satisfaisante (en 2003). J'ai chargé la FAQ de fclc en format PDF, bravo pour le document, mais pas vraiment trouvé ma réponse. Rien non plus dans le doc ISO/IEC 9899:1999, pourtant, vu que cette dernière
normalisation du C est postérieure à la dernière du C++, je pensais que le sujet aurait été évoqué. Dans Google, pas trouvé le mot-clé qui tue en français ("c ou c++" donne des
résultats, mais dans le sens C/C++). En anglais, "C vs C++" OR "C++ vs C" donne bien 2500 résultats, mais la question posée est généralement, dans des
références souvent anciennes, "Pourquoi passer au C++ ?", voire "Pourquoi la
POO ?". Questions pertinentes que j'ai connues, mais à l'époque de l'apparition réelle de C++ sur le marché. Mais aujourd'hui, je dirais : POO -> C++ (ou autre chose). POO pur et dur -> autre chose Pas POO -> pourquoi C et non C++ ? (c'est ma question). Je vais tenter de préciser. Je ne connais par la pratique de la programmation que les plateformes "grand-public", actuellement PC (x86) sous
divers OS et Apple. Quelles peuvent être les raisons, pour de nouveaux projets, de se contraindre à programmer en C ? La question ne porte pas sur l'utilisation ou non des objets, voire de la STL, puisque leur utilisation peut être évitée ou différée (dans le cadre d'une démarche pédagogique, ou d'auto-apprentissage). J'ai écrit "se contraindre". Les compilateurs que je connais permettent tous
de choisir le langage, entre un (ou plusieurs) C++ et un (ou plusieurs) C. En d'autres termes, sur les plateformes que je pratique, l'acquisition d'un
compilateur C met souvent à votre disposition un compilateur C++, que vous le vouliez ou non. Existe-t-il des plateformes pour lesquelles l'offre est plus restrictive, et
ne propose pour un prix donné qu'un compilateur C ? Bien entendu, la simple maintenance d'un développement existant en C impose
de pratiquer ce langage, La culture interdit d'ailleurs de l'ignorer. 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++. Certains parmi vous font-ils parfois du C, parfois du C++, et si oui, selon
quels critères et pour quelles raisons ? Simplement parce qu'il s'agit d'un
choix du client, peut-être ? Plus vraisemblablement, il y a entre C et C++ (dégradé) une différence qui m'aura échappé. Voilà, je compte sur vous pour éclairer ma lanterne. Cordialement, Pierre
Bonjour.
Une légende circule selon laquelle, en 1998, Bjarne Stroustroup a donné une
interview pour le magazine Computer de IEEE, dans laquelle il a expliqué ses
vraies motivations en créant C++. Ca décape tellement que la rédaction
aurait décidé de ne pas publier le texte, "pour le bien de l'industrie". Il
aurait ensuite transpiré confidentiellement...
J'ai lu ce texte (en Anglais), et effectivement ça envoie le pâté. Mais
peut-être n'est-ce qu'un hoax ?
Quelqu'un aurait-il des précisions pour confirmer ou infirmer cette histoire
?
Cordialement,
PB
"Pierre Maurette" <pierre.maurette@laposte.net> a écrit dans le message
news: 3f4b07b6$0$6203$626a54ce@news.free.fr...
Bonjour,
Je me décide à poser cette question certainement peu originale. Mais
pourtant, j'ai cherché, et pas de réponse satisfaisante (en 2003).
J'ai chargé la FAQ de fclc en format PDF, bravo pour le document, mais pas
vraiment trouvé ma réponse.
Rien non plus dans le doc ISO/IEC 9899:1999, pourtant, vu que cette
dernière
normalisation du C est postérieure à la dernière du C++, je pensais que le
sujet aurait été évoqué.
Dans Google, pas trouvé le mot-clé qui tue en français ("c ou c++" donne
des
résultats, mais dans le sens C/C++). En anglais, "C vs C++" OR "C++ vs C"
donne bien 2500 résultats, mais la question posée est généralement, dans
des
références souvent anciennes, "Pourquoi passer au C++ ?", voire "Pourquoi
la
POO ?". Questions pertinentes que j'ai connues, mais à l'époque de
l'apparition réelle de C++ sur le marché. Mais aujourd'hui, je dirais :
POO -> C++ (ou autre chose).
POO pur et dur -> autre chose
Pas POO -> pourquoi C et non C++ ? (c'est ma question).
Je vais tenter de préciser. Je ne connais par la pratique de la
programmation que les plateformes "grand-public", actuellement PC (x86)
sous
divers OS et Apple.
Quelles peuvent être les raisons, pour de nouveaux projets, de se
contraindre à programmer en C ? La question ne porte pas sur l'utilisation
ou non des objets, voire de la STL, puisque leur utilisation peut être
évitée ou différée (dans le cadre d'une démarche pédagogique, ou
d'auto-apprentissage).
J'ai écrit "se contraindre". Les compilateurs que je connais permettent
tous
de choisir le langage, entre un (ou plusieurs) C++ et un (ou plusieurs) C.
En d'autres termes, sur les plateformes que je pratique, l'acquisition
d'un
compilateur C met souvent à votre disposition un compilateur C++, que vous
le vouliez ou non.
Existe-t-il des plateformes pour lesquelles l'offre est plus restrictive,
et
ne propose pour un prix donné qu'un compilateur C ?
Bien entendu, la simple maintenance d'un développement existant en C
impose
de pratiquer ce langage, La culture interdit d'ailleurs de l'ignorer.
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++.
Certains parmi vous font-ils parfois du C, parfois du C++, et si oui,
selon
quels critères et pour quelles raisons ? Simplement parce qu'il s'agit
d'un
choix du client, peut-être ?
Plus vraisemblablement, il y a entre C et C++ (dégradé) une différence qui
m'aura échappé.
Voilà, je compte sur vous pour éclairer ma lanterne.
Cordialement,
Pierre
Une légende circule selon laquelle, en 1998, Bjarne Stroustroup a donné une interview pour le magazine Computer de IEEE, dans laquelle il a expliqué ses vraies motivations en créant C++. Ca décape tellement que la rédaction aurait décidé de ne pas publier le texte, "pour le bien de l'industrie". Il aurait ensuite transpiré confidentiellement...
J'ai lu ce texte (en Anglais), et effectivement ça envoie le pâté. Mais peut-être n'est-ce qu'un hoax ?
Quelqu'un aurait-il des précisions pour confirmer ou infirmer cette histoire ?
Cordialement,
PB
"Pierre Maurette" a écrit dans le message news: 3f4b07b6$0$6203$
Bonjour, Je me décide à poser cette question certainement peu originale. Mais pourtant, j'ai cherché, et pas de réponse satisfaisante (en 2003). J'ai chargé la FAQ de fclc en format PDF, bravo pour le document, mais pas vraiment trouvé ma réponse. Rien non plus dans le doc ISO/IEC 9899:1999, pourtant, vu que cette dernière
normalisation du C est postérieure à la dernière du C++, je pensais que le sujet aurait été évoqué. Dans Google, pas trouvé le mot-clé qui tue en français ("c ou c++" donne des
résultats, mais dans le sens C/C++). En anglais, "C vs C++" OR "C++ vs C" donne bien 2500 résultats, mais la question posée est généralement, dans des
références souvent anciennes, "Pourquoi passer au C++ ?", voire "Pourquoi la
POO ?". Questions pertinentes que j'ai connues, mais à l'époque de l'apparition réelle de C++ sur le marché. Mais aujourd'hui, je dirais : POO -> C++ (ou autre chose). POO pur et dur -> autre chose Pas POO -> pourquoi C et non C++ ? (c'est ma question). Je vais tenter de préciser. Je ne connais par la pratique de la programmation que les plateformes "grand-public", actuellement PC (x86) sous
divers OS et Apple. Quelles peuvent être les raisons, pour de nouveaux projets, de se contraindre à programmer en C ? La question ne porte pas sur l'utilisation ou non des objets, voire de la STL, puisque leur utilisation peut être évitée ou différée (dans le cadre d'une démarche pédagogique, ou d'auto-apprentissage). J'ai écrit "se contraindre". Les compilateurs que je connais permettent tous
de choisir le langage, entre un (ou plusieurs) C++ et un (ou plusieurs) C. En d'autres termes, sur les plateformes que je pratique, l'acquisition d'un
compilateur C met souvent à votre disposition un compilateur C++, que vous le vouliez ou non. Existe-t-il des plateformes pour lesquelles l'offre est plus restrictive, et
ne propose pour un prix donné qu'un compilateur C ? Bien entendu, la simple maintenance d'un développement existant en C impose
de pratiquer ce langage, La culture interdit d'ailleurs de l'ignorer. 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++. Certains parmi vous font-ils parfois du C, parfois du C++, et si oui, selon
quels critères et pour quelles raisons ? Simplement parce qu'il s'agit d'un
choix du client, peut-être ? Plus vraisemblablement, il y a entre C et C++ (dégradé) une différence qui m'aura échappé. Voilà, je compte sur vous pour éclairer ma lanterne. Cordialement, Pierre
Stephane Legras-Decussy
"Patrick Brunet" <Patrick.Brunet @ cned.fr> a écrit dans le message news: 3f4de96a$0$16562$
Quelqu'un aurait-il des précisions pour confirmer ou infirmer cette histoire
c'est un faux tres connu...et assez drole...(je trouve)...
"Patrick Brunet" <Patrick.Brunet @ cned.fr> a écrit dans le message news:
3f4de96a$0$16562$626a54ce@news.free.fr...
Quelqu'un aurait-il des précisions pour confirmer ou infirmer cette
histoire
c'est un faux tres connu...et assez drole...(je trouve)...
"Patrick Brunet" <Patrick.Brunet @ cned.fr> a écrit dans le message news: 3f4de96a$0$16562$
Quelqu'un aurait-il des précisions pour confirmer ou infirmer cette histoire
c'est un faux tres connu...et assez drole...(je trouve)...
Emmanuel Delahaye
In 'fr.comp.lang.c', "Pierre Maurette" wrote:
Quelles peuvent être les raisons, pour de nouveaux projets, de se contraindre à programmer en C ? La question ne porte pas sur
Certains projets sont suffisement simples pour ne pas exiger de POO. D'autre part, certaines plateformes légères n'ont tout simplement pas de compilateur autre que C (ou l'assembleur, bien sûr).
-- -ed- [remove YOURBRA before answering me] The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html <blank line> FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
In 'fr.comp.lang.c', "Pierre Maurette" <pierre.maurette@laposte.net>
wrote:
Quelles peuvent être les raisons, pour de nouveaux projets, de se
contraindre à programmer en C ? La question ne porte pas sur
Certains projets sont suffisement simples pour ne pas exiger de POO. D'autre
part, certaines plateformes légères n'ont tout simplement pas de compilateur
autre que C (ou l'assembleur, bien sûr).
--
-ed- emdelYOURBRA@noos.fr [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
<blank line>
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
Quelles peuvent être les raisons, pour de nouveaux projets, de se contraindre à programmer en C ? La question ne porte pas sur
Certains projets sont suffisement simples pour ne pas exiger de POO. D'autre part, certaines plateformes légères n'ont tout simplement pas de compilateur autre que C (ou l'assembleur, bien sûr).
-- -ed- [remove YOURBRA before answering me] The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html <blank line> FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
Emmanuel Delahaye
In 'fr.comp.lang.c', 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 de 1999 est sans doute nettement moins implémentée que la norme ISO C++98.
Laurent parlait de C90.
-- -ed- [remove YOURBRA before answering me] The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html <blank line> FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
In 'fr.comp.lang.c', Richard Delorme <abulmo@nospam.fr> 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
de 1999 est sans doute nettement moins implémentée que la norme ISO C++98.
Laurent parlait de C90.
--
-ed- emdelYOURBRA@noos.fr [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
<blank line>
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
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.
Laurent parlait de C90.
-- -ed- [remove YOURBRA before answering me] The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html <blank line> FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
Richard Delorme
In 'fr.comp.lang.c', 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 de 1999 est sans doute nettement moins implémentée que la norme ISO C++98.
Laurent parlait de C90.
C'est bien ce que je lui reprochais.
-- Richard
In 'fr.comp.lang.c', Richard Delorme <abulmo@nospam.fr> 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 de 1999 est sans doute nettement moins implémentée que la norme ISO
C++98.
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.
Laurent parlait de C90.
C'est bien ce que je lui reprochais.
-- Richard
Pierre Maurette
"Jean-Michel Bechet" a écrit dans le message de news: 3f4b25b7$0$1128$ ...
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) Il est clair que, vu du coté du concepteur de micro-controleurs, une
implémentation correcte d'un C est plus séduisante qu'une implémentation d'un C++ qui sera certainement incomplète. D'autant que (j'imagine), s'appliquant à une famille de circuits, ces compilateurs doivent en permanence être modifiés, soit vers une nouvelle version spécifique, soit vers une version plus complète quand aux paramétrages. Ceci n'empêche pas que l'Objet soit très présent dans d'autres domaines de l'informatique industrielle et de l'automatisme. Cordialement, Pierre
"Jean-Michel Bechet" <jmb@bea.be> a écrit dans le message de news:
3f4b25b7$0$1128$6c56d894@feed0.news.be.easynet.net...
...
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)
Il est clair que, vu du coté du concepteur de micro-controleurs, une
implémentation correcte d'un C est plus séduisante qu'une implémentation
d'un C++ qui sera certainement incomplète. D'autant que (j'imagine),
s'appliquant à une famille de circuits, ces compilateurs doivent en
permanence être modifiés, soit vers une nouvelle version spécifique, soit
vers une version plus complète quand aux paramétrages.
Ceci n'empêche pas que l'Objet soit très présent dans d'autres domaines de
l'informatique industrielle et de l'automatisme.
Cordialement,
Pierre
"Jean-Michel Bechet" a écrit dans le message de news: 3f4b25b7$0$1128$ ...
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) Il est clair que, vu du coté du concepteur de micro-controleurs, une
implémentation correcte d'un C est plus séduisante qu'une implémentation d'un C++ qui sera certainement incomplète. D'autant que (j'imagine), s'appliquant à une famille de circuits, ces compilateurs doivent en permanence être modifiés, soit vers une nouvelle version spécifique, soit vers une version plus complète quand aux paramétrages. Ceci n'empêche pas que l'Objet soit très présent dans d'autres domaines de l'informatique industrielle et de l'automatisme. Cordialement, Pierre
Pierre Maurette
"Laurent Deniau" a écrit dans le message de news:
...
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. 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. 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 ? 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++) 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 ? Voila, tout ça simplement pour savoir s'il est utile de passer un peu de temps à "bosser" le C pur. Cordialement, Pierre
"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.
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.
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 ?
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++)
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 ?
Voila, tout ça simplement pour savoir s'il est utile de passer un peu de
temps à "bosser" le C pur.
Cordialement,
Pierre
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. 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. 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 ? 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++) 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 ? Voila, tout ça simplement pour savoir s'il est utile de passer un peu de temps à "bosser" le C pur. Cordialement, Pierre
Patrick Brunet
Bonjour.
"Stephane Legras-Decussy" a écrit dans le message news: 3f4e01a5$0$6246$
"Patrick Brunet" <Patrick.Brunet @ cned.fr> a écrit dans le message news: 3f4de96a$0$16562$
Quelqu'un aurait-il des précisions pour confirmer ou infirmer cette histoire
c'est un faux tres connu...et assez drole...(je trouve)...
OUF !!!
Quoique...
Ce texte met les deux pieds dans le plat sur un certain nombre de réalités, concernant la mauvaise maîtrise des possibilités de C++, et la démarche de navigation à vue de certains développeux tarif éco (j'en sais quelque chose pour avoir passé des mois derrière à rafistoler leurs .erdes). Mais on peut faire du sabotage aussi en C pur...
Comme dirait Gabriel Dos Reis : "Mauvais programmeur ... changer de programmeur".
Cordialement,
PB
Bonjour.
"Stephane Legras-Decussy" <stephane.legrasdecussy@freesbee.fr> a écrit dans
le message news: 3f4e01a5$0$6246$626a54ce@news.free.fr...
"Patrick Brunet" <Patrick.Brunet @ cned.fr> a écrit dans le message news:
3f4de96a$0$16562$626a54ce@news.free.fr...
Quelqu'un aurait-il des précisions pour confirmer ou infirmer cette
histoire
c'est un faux tres connu...et assez drole...(je trouve)...
OUF !!!
Quoique...
Ce texte met les deux pieds dans le plat sur un certain nombre de réalités,
concernant la mauvaise maîtrise des possibilités de C++, et la démarche de
navigation à vue de certains développeux tarif éco (j'en sais quelque chose
pour avoir passé des mois derrière à rafistoler leurs .erdes).
Mais on peut faire du sabotage aussi en C pur...
Comme dirait Gabriel Dos Reis :
"Mauvais programmeur ... changer de programmeur".
"Stephane Legras-Decussy" a écrit dans le message news: 3f4e01a5$0$6246$
"Patrick Brunet" <Patrick.Brunet @ cned.fr> a écrit dans le message news: 3f4de96a$0$16562$
Quelqu'un aurait-il des précisions pour confirmer ou infirmer cette histoire
c'est un faux tres connu...et assez drole...(je trouve)...
OUF !!!
Quoique...
Ce texte met les deux pieds dans le plat sur un certain nombre de réalités, concernant la mauvaise maîtrise des possibilités de C++, et la démarche de navigation à vue de certains développeux tarif éco (j'en sais quelque chose pour avoir passé des mois derrière à rafistoler leurs .erdes). Mais on peut faire du sabotage aussi en C pur...
Comme dirait Gabriel Dos Reis : "Mauvais programmeur ... changer de programmeur".
Cordialement,
PB
AG
pour avoir passé des mois derrière à rafistoler leurs .erdes c'est quoi cette extension de fichier ?
pour avoir passé des mois derrière à rafistoler leurs .erdes
c'est quoi cette extension de fichier ?
