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
| 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?
c'est très simple. le permier embryon de l'implémentation de C++ (ou C plutôt de C with Classes) n'est pas pas une modification d'un compilateur C existant ou simula existant.
| Cela va dans le | sens de mes propos donc je ne comprends pas tes protestations | precedentes.
non, cela ne va pas dans le sens de tes propos. Et si tu arrêtais une seconde d'être de mauvaise foi ?
| > | 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...
C'est une bonne illustration de ta mauvaise foi, si besoin en était.
| > | - 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
Quel header?
Encore une fois, as-tu lu les spécifications ? C++ définie une classe template primaire ainsi que trois spécialisations pour float, double et long double -- qui correspondent aux trois types complexes de C.
Dans mon header, GCC-3.x, j'ai :
// 26.2.2 Primary template class complex template<typename _Tp> class complex { [...] private: _Tp _M_real, _M_imag; };
"__complex__ T" est le type de donnée complexe utilisé par les front-ends C, Fortran et C++ de GCC.
| template <class _FLT> | class complex | { | [...] | private: | _FLT re, im; | [...] | } | | et ce n'est pas garanti d'etre compatible avec:
mais as-tu essayé concrètement de savoir ou te contentes-tu de faire de la masturbation intellectuelle ? As-tu essayé le reinterpret_cast<> comme dit le DR ou te contentes-tu de pédaler en l'air ?
[...]
| > | - 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.
et quels sont ces experts dont tu parles ? Toi ?
| Plus serieusement, cela en fait une classe incomplete alors qu'il
laquelle, une classe complète ? Toutes les classes dont il est question sont complètes. Si elles avaient été incomplètes, on ne pourrait pas créé des objets de tels classes. Encore oublier de lire les spécifications ou toujours de mauvaise foi ?
| 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.
Je te conseillerais de consulter les archives de libstdc++ pour plus amples informations.
[...]
| > | - 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.
Ho ho, quand tu m'as envoyé le mail, tu me parlais de GCC.
| 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_
Là, je ne te suis plus.
| > | > 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.
Qui « on » ? La personne à amener typeof dans la discussion est toi. Tu ne contrôles rien sur typeof, tu ne peux pas en espérer que ce qui est dit dans la doc. Ensuite, typeof appliqué à une expression retourne un type. Or dans l'exemple ci-haut tu appliques "==" à deux types. Ce qui est une indication sur sur ta mauvaise foi dans cette discussion. Yaka. Bouh !
| Je me demande d'ailleurs s'il n'y pas un GNUisme recent qui | permet de faire ca.
qui permte quoi exactement ?
| > | 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.
"comment implémenter <tgmath.h> n'est pas ma préoccupation, mais j'en parle quand même".
Ce n'est pas ta préoccupation. Soit. Mais cela n'en fait pas quelque chose d'hors sujet sur ce groupe.
| 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.
qu'est-ce que tu en sais ? C'est la foi du charbonnier ou juste une croyance aveugle ?
http://gcc.gnu.org/ml/gcc/2003-08/msg01257.html
| 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.
Just do it.
-- Gaby
Laurent Deniau <Laurent.Deniau@cern.ch> writes:
| 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?
c'est très simple. le permier embryon de l'implémentation de C++ (ou C
plutôt de C with Classes) n'est pas pas une modification d'un
compilateur C existant ou simula existant.
| Cela va dans le
| sens de mes propos donc je ne comprends pas tes protestations
| precedentes.
non, cela ne va pas dans le sens de tes propos. Et si tu arrêtais une
seconde d'être de mauvaise foi ?
| > | 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...
C'est une bonne illustration de ta mauvaise foi, si besoin en était.
| > | - 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
Quel header?
Encore une fois, as-tu lu les spécifications ?
C++ définie une classe template primaire ainsi que trois
spécialisations pour float, double et long double -- qui correspondent
aux trois types complexes de C.
Dans mon header, GCC-3.x, j'ai :
// 26.2.2 Primary template class complex
template<typename _Tp>
class complex
{
[...]
private:
_Tp _M_real, _M_imag;
};
"__complex__ T" est le type de donnée complexe utilisé par les
front-ends C, Fortran et C++ de GCC.
| template <class _FLT>
| class complex
| {
| [...]
| private:
| _FLT re, im;
| [...]
| }
|
| et ce n'est pas garanti d'etre compatible avec:
mais as-tu essayé concrètement de savoir ou te contentes-tu de faire
de la masturbation intellectuelle ? As-tu essayé le reinterpret_cast<>
comme dit le DR ou te contentes-tu de pédaler en l'air ?
[...]
| > | - 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.
et quels sont ces experts dont tu parles ? Toi ?
| Plus serieusement, cela en fait une classe incomplete alors qu'il
laquelle, une classe complète ? Toutes les classes dont il est
question sont complètes. Si elles avaient été incomplètes, on ne
pourrait pas créé des objets de tels classes.
Encore oublier de lire les spécifications ou toujours de mauvaise foi ?
| 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.
Je te conseillerais de consulter les archives de libstdc++ pour plus
amples informations.
[...]
| > | - 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.
Ho ho, quand tu m'as envoyé le mail, tu me parlais de GCC.
| 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_
Là, je ne te suis plus.
| > | > 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.
Qui « on » ? La personne à amener typeof dans la discussion est toi.
Tu ne contrôles rien sur typeof, tu ne peux pas en espérer que ce qui
est dit dans la doc. Ensuite, typeof appliqué à une expression
retourne un type. Or dans l'exemple ci-haut tu appliques "==" à deux
types. Ce qui est une indication sur sur ta mauvaise foi dans cette
discussion. Yaka. Bouh !
| Je me demande d'ailleurs s'il n'y pas un GNUisme recent qui
| permet de faire ca.
qui permte quoi exactement ?
| > | 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.
"comment implémenter <tgmath.h> n'est pas ma préoccupation, mais
j'en parle quand même".
Ce n'est pas ta préoccupation. Soit. Mais cela n'en fait pas quelque
chose d'hors sujet sur ce groupe.
| 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.
qu'est-ce que tu en sais ? C'est la foi du charbonnier ou juste une
croyance aveugle ?
http://gcc.gnu.org/ml/gcc/2003-08/msg01257.html
| 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.
| 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?
c'est très simple. le permier embryon de l'implémentation de C++ (ou C plutôt de C with Classes) n'est pas pas une modification d'un compilateur C existant ou simula existant.
| Cela va dans le | sens de mes propos donc je ne comprends pas tes protestations | precedentes.
non, cela ne va pas dans le sens de tes propos. Et si tu arrêtais une seconde d'être de mauvaise foi ?
| > | 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...
C'est une bonne illustration de ta mauvaise foi, si besoin en était.
| > | - 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
Quel header?
Encore une fois, as-tu lu les spécifications ? C++ définie une classe template primaire ainsi que trois spécialisations pour float, double et long double -- qui correspondent aux trois types complexes de C.
Dans mon header, GCC-3.x, j'ai :
// 26.2.2 Primary template class complex template<typename _Tp> class complex { [...] private: _Tp _M_real, _M_imag; };
"__complex__ T" est le type de donnée complexe utilisé par les front-ends C, Fortran et C++ de GCC.
| template <class _FLT> | class complex | { | [...] | private: | _FLT re, im; | [...] | } | | et ce n'est pas garanti d'etre compatible avec:
mais as-tu essayé concrètement de savoir ou te contentes-tu de faire de la masturbation intellectuelle ? As-tu essayé le reinterpret_cast<> comme dit le DR ou te contentes-tu de pédaler en l'air ?
[...]
| > | - 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.
et quels sont ces experts dont tu parles ? Toi ?
| Plus serieusement, cela en fait une classe incomplete alors qu'il
laquelle, une classe complète ? Toutes les classes dont il est question sont complètes. Si elles avaient été incomplètes, on ne pourrait pas créé des objets de tels classes. Encore oublier de lire les spécifications ou toujours de mauvaise foi ?
| 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.
Je te conseillerais de consulter les archives de libstdc++ pour plus amples informations.
[...]
| > | - 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.
Ho ho, quand tu m'as envoyé le mail, tu me parlais de GCC.
| 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_
Là, je ne te suis plus.
| > | > 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.
Qui « on » ? La personne à amener typeof dans la discussion est toi. Tu ne contrôles rien sur typeof, tu ne peux pas en espérer que ce qui est dit dans la doc. Ensuite, typeof appliqué à une expression retourne un type. Or dans l'exemple ci-haut tu appliques "==" à deux types. Ce qui est une indication sur sur ta mauvaise foi dans cette discussion. Yaka. Bouh !
| Je me demande d'ailleurs s'il n'y pas un GNUisme recent qui | permet de faire ca.
qui permte quoi exactement ?
| > | 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.
"comment implémenter <tgmath.h> n'est pas ma préoccupation, mais j'en parle quand même".
Ce n'est pas ta préoccupation. Soit. Mais cela n'en fait pas quelque chose d'hors sujet sur ce groupe.
| 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.
qu'est-ce que tu en sais ? C'est la foi du charbonnier ou juste une croyance aveugle ?
http://gcc.gnu.org/ml/gcc/2003-08/msg01257.html
| 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.
