J'ouvre un autre fil pour ne pas empiéter sur celui
ouvert par André (Barbaroux) mais mon message est
en rapport avec une des réponses qui lui a été faite :
Le 22/07/2014 21:58, Samuel DEVULDER a écrit :
> Par ailleurs je vois que tu utilises des tableaux de taille variable.
> C'est pas une super bonne idée. Le C est un vieux langage qui ne
> possède pas de sémantique très forte à la Pascal pour le type tableau.
> Le C prèfère de loin les tableaux de taille fixe.
C'est vraiment un souci en 2014 de faire du c99 ?
Question vraiment sans arrières pensées. Je n'y connais
rien sur là-dessus (d'où ma question), mais je me dis
seulement qu'en 2014 on devrait quand même pouvoir faire
du c99 sans trop de souci. Mais pourtant on lit souvent
ici où là qu'il vaut mieux éviter le c99, où en tout cas
éviter de déclarer des tableaux dont la taille est une
variable.
Ça serait possible, sans rentrer dans les détails techniques,
d'avoir quelques explications sur cette réticence par rapport
au c99 ? Notamment, les tableaux dynamiques sont-ils vraiment
à proscrire ?
De memoire, ce bout de la norme est controvesee, globalement pour les architectures plus ou moins embarquees, parce que pour le coup, l'espace memoire correspondant (la pile) est de taille reduite.
Note que meme pour du tableau de taille fixe, un gros tableau sur la pile peut poser souci.
(ca veut dire qu'on est plus ou moins oblige de supposer qu'un tableau dynamique peut etre gros, et ca impose des solutions de contournement tel qu'un allocateur specifique pour ce genre de choses).
Bref.
Dans le cas initial, un compilo decent saura qu'il ne s'agit pas vraiment d'un tableau de taille variable. Mais bon, les vieilles habitudes meurent lentement !
Perso, je trouve assez dommage que la fonctionnalite correspondante de C++ (le fait que const int te permette de fabriquer de vraies constantes) n'ait pas migre en C. Moins je vois le preprocesseur, mieux je me porte.
In article <53cf01ea$0$2151$426a74cc@news.free.fr>,
Francois Lafont <francois.lafont@nospam.invalid> wrote:
De memoire, ce bout de la norme est controvesee, globalement pour les
architectures plus ou moins embarquees, parce que pour le coup, l'espace
memoire correspondant (la pile) est de taille reduite.
Note que meme pour du tableau de taille fixe, un gros tableau sur la pile
peut poser souci.
(ca veut dire qu'on est plus ou moins oblige de supposer qu'un tableau
dynamique peut etre gros, et ca impose des solutions de contournement
tel qu'un allocateur specifique pour ce genre de choses).
Bref.
Dans le cas initial, un compilo decent saura qu'il ne s'agit pas vraiment
d'un tableau de taille variable. Mais bon, les vieilles habitudes meurent
lentement !
Perso, je trouve assez dommage que la fonctionnalite correspondante de C++
(le fait que const int te permette de fabriquer de vraies constantes) n'ait
pas migre en C. Moins je vois le preprocesseur, mieux je me porte.
De memoire, ce bout de la norme est controvesee, globalement pour les architectures plus ou moins embarquees, parce que pour le coup, l'espace memoire correspondant (la pile) est de taille reduite.
Note que meme pour du tableau de taille fixe, un gros tableau sur la pile peut poser souci.
(ca veut dire qu'on est plus ou moins oblige de supposer qu'un tableau dynamique peut etre gros, et ca impose des solutions de contournement tel qu'un allocateur specifique pour ce genre de choses).
Bref.
Dans le cas initial, un compilo decent saura qu'il ne s'agit pas vraiment d'un tableau de taille variable. Mais bon, les vieilles habitudes meurent lentement !
Perso, je trouve assez dommage que la fonctionnalite correspondante de C++ (le fait que const int te permette de fabriquer de vraies constantes) n'ait pas migre en C. Moins je vois le preprocesseur, mieux je me porte.
Antoine Leca
Le 23/07/2014 02:29, Francois Lafont écrivit :
C'est vraiment un souci en 2014 de faire du c99 ?
Il y a deux aspects à prendre en compte ÀMHA.
a) Certains des compilateurs, y compris les plus diffusés (comme Microsoft C pour ne pas le nommer) ne sont pas encore conformes.
b) Une des nouveautés de C99, en l'occurrence les tableaux à taille dynamique, était obligatoire pour la conformité à C99 mais est seulement optionnelle pour la conformité à la norme C11, qui remplace.
Antoine
Le 23/07/2014 02:29, Francois Lafont écrivit :
C'est vraiment un souci en 2014 de faire du c99 ?
Il y a deux aspects à prendre en compte ÀMHA.
a) Certains des compilateurs, y compris les plus diffusés (comme
Microsoft C pour ne pas le nommer) ne sont pas encore conformes.
b) Une des nouveautés de C99, en l'occurrence les tableaux à taille
dynamique, était obligatoire pour la conformité à C99 mais est seulement
optionnelle pour la conformité à la norme C11, qui remplace.
a) Certains des compilateurs, y compris les plus diffusés (comme Microsoft C pour ne pas le nommer) ne sont pas encore conformes.
b) Une des nouveautés de C99, en l'occurrence les tableaux à taille dynamique, était obligatoire pour la conformité à C99 mais est seulement optionnelle pour la conformité à la norme C11, qui remplace.
Antoine
Francois Lafont
Bonsoir,
Merci à tous les deux pour vos réponses.
C'est quand même surprenant cette lenteur et cette inertie qu'on peut constater dans le langage C, par exemple sur le fait qu'en 2014 certains compilateurs ne soient pas en mesure d'être 100% conforme C99.
-- François Lafont
Bonsoir,
Merci à tous les deux pour vos réponses.
C'est quand même surprenant cette lenteur et cette inertie
qu'on peut constater dans le langage C, par exemple sur le
fait qu'en 2014 certains compilateurs ne soient pas en mesure
d'être 100% conforme C99.
C'est quand même surprenant cette lenteur et cette inertie qu'on peut constater dans le langage C, par exemple sur le fait qu'en 2014 certains compilateurs ne soient pas en mesure d'être 100% conforme C99.
-- François Lafont
espie
In article <53d045a7$0$2132$, Francois Lafont wrote:
C'est quand même surprenant cette lenteur et cette inertie qu'on peut constater dans le langage C, par exemple sur le fait qu'en 2014 certains compilateurs ne soient pas en mesure d'être 100% conforme C99.
Non, ca n'a rien de surprenant. On parle d'un des langages les plus portables de la terre. Il y a des environnements un peu specifiques (l'embarque) sur lesquels ca n'est pas si simple de faire certaines choses. Et le fait que les tableaux de taille variable soit devenue une fonctionnalite optionnelle en C2011 le montre bien.
Il faut penser autre chose que PC de bureau.
Ah, et a cote, il y a microsoft, qui font un peu n'importe quoi a leur sauce, que ce soit pour C, ou pour certains autres langages...
In article <53d045a7$0$2132$426a34cc@news.free.fr>,
Francois Lafont <francois.lafont@nospam.invalid> wrote:
C'est quand même surprenant cette lenteur et cette inertie
qu'on peut constater dans le langage C, par exemple sur le
fait qu'en 2014 certains compilateurs ne soient pas en mesure
d'être 100% conforme C99.
Non, ca n'a rien de surprenant. On parle d'un des langages les plus
portables de la terre. Il y a des environnements un peu specifiques
(l'embarque) sur lesquels ca n'est pas si simple de faire certaines
choses. Et le fait que les tableaux de taille variable soit devenue
une fonctionnalite optionnelle en C2011 le montre bien.
Il faut penser autre chose que PC de bureau.
Ah, et a cote, il y a microsoft, qui font un peu n'importe quoi a leur
sauce, que ce soit pour C, ou pour certains autres langages...
C'est quand même surprenant cette lenteur et cette inertie qu'on peut constater dans le langage C, par exemple sur le fait qu'en 2014 certains compilateurs ne soient pas en mesure d'être 100% conforme C99.
Non, ca n'a rien de surprenant. On parle d'un des langages les plus portables de la terre. Il y a des environnements un peu specifiques (l'embarque) sur lesquels ca n'est pas si simple de faire certaines choses. Et le fait que les tableaux de taille variable soit devenue une fonctionnalite optionnelle en C2011 le montre bien.
Il faut penser autre chose que PC de bureau.
Ah, et a cote, il y a microsoft, qui font un peu n'importe quoi a leur sauce, que ce soit pour C, ou pour certains autres langages...
JKB
Le Thu, 24 Jul 2014 06:52:43 +0000 (UTC), Marc Espie écrivait :
In article <53d045a7$0$2132$, Francois Lafont wrote:
Bonsoir,
Merci à tous les deux pour vos réponses.
C'est quand même surprenant cette lenteur et cette inertie qu'on peut constater dans le langage C, par exemple sur le fait qu'en 2014 certains compilateurs ne soient pas en mesure d'être 100% conforme C99.
Non, ca n'a rien de surprenant. On parle d'un des langages les plus portables de la terre. Il y a des environnements un peu specifiques (l'embarque) sur lesquels ca n'est pas si simple de faire certaines choses. Et le fait que les tableaux de taille variable soit devenue une fonctionnalite optionnelle en C2011 le montre bien.
Il faut penser autre chose que PC de bureau.
Ah, et a cote, il y a microsoft, qui font un peu n'importe quoi a leur sauce, que ce soit pour C, ou pour certains autres langages...
Et il y a aussi les habitudes bien ancrées et certains compilos mal écrits qu'il faudrait reprendre from scratch pour un ou deux points des standards...
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr => http://loubardes.de-charybde-en-scylla.fr
Le Thu, 24 Jul 2014 06:52:43 +0000 (UTC),
Marc Espie <espie@lain.home> écrivait :
In article <53d045a7$0$2132$426a34cc@news.free.fr>,
Francois Lafont <francois.lafont@nospam.invalid> wrote:
Bonsoir,
Merci à tous les deux pour vos réponses.
C'est quand même surprenant cette lenteur et cette inertie
qu'on peut constater dans le langage C, par exemple sur le
fait qu'en 2014 certains compilateurs ne soient pas en mesure
d'être 100% conforme C99.
Non, ca n'a rien de surprenant. On parle d'un des langages les plus
portables de la terre. Il y a des environnements un peu specifiques
(l'embarque) sur lesquels ca n'est pas si simple de faire certaines
choses. Et le fait que les tableaux de taille variable soit devenue
une fonctionnalite optionnelle en C2011 le montre bien.
Il faut penser autre chose que PC de bureau.
Ah, et a cote, il y a microsoft, qui font un peu n'importe quoi a leur
sauce, que ce soit pour C, ou pour certains autres langages...
Et il y a aussi les habitudes bien ancrées et certains compilos mal
écrits qu'il faudrait reprendre from scratch pour un ou deux points
des standards...
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Le Thu, 24 Jul 2014 06:52:43 +0000 (UTC), Marc Espie écrivait :
In article <53d045a7$0$2132$, Francois Lafont wrote:
Bonsoir,
Merci à tous les deux pour vos réponses.
C'est quand même surprenant cette lenteur et cette inertie qu'on peut constater dans le langage C, par exemple sur le fait qu'en 2014 certains compilateurs ne soient pas en mesure d'être 100% conforme C99.
Non, ca n'a rien de surprenant. On parle d'un des langages les plus portables de la terre. Il y a des environnements un peu specifiques (l'embarque) sur lesquels ca n'est pas si simple de faire certaines choses. Et le fait que les tableaux de taille variable soit devenue une fonctionnalite optionnelle en C2011 le montre bien.
Il faut penser autre chose que PC de bureau.
Ah, et a cote, il y a microsoft, qui font un peu n'importe quoi a leur sauce, que ce soit pour C, ou pour certains autres langages...
Et il y a aussi les habitudes bien ancrées et certains compilos mal écrits qu'il faudrait reprendre from scratch pour un ou deux points des standards...
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr => http://loubardes.de-charybde-en-scylla.fr
Antoine Leca
Le 24/07/2014 01:30, Francois Lafont écrivit :
C'est quand même surprenant cette lenteur et cette inertie qu'on peut constater dans le langage C, par exemple sur le fait qu'en 2014 certains compilateurs ne soient pas en mesure d'être 100% conforme C99.
Lenteur : je ne sais pas si c'est réellement le cas, je n'en ai pas l'impression sur la base de la pratique des cycles de vie des produits. Je me souviens ainsi que vers 1995 (16 ans après la publication de la norme ANSI), certains projets se posaient (légitimement) la question d'opter ou pas pour C90 ; aujourd'hui la notion même de « C K&R » disparaît graduellement, mais ce n'était pas vrai il y a seulement quelques années. Évidemment, si on se base sur le cycle de vie des applications OpenSource/Bazar ou du « Web 2.0 » en général, tout le reste est extrêmement lent. Mais bon, il n'y a rien de particulier au langage C à ce niveau ; et je ne pense pas que l'on peut espérer que le monde des outils informatiques va passer au seul modèle de développement « 2.0 ». Sans compter que beaucoup d'utilisateurs « réels » (ceux qui payent) de compilateurs C ne sont probablement pas d'accord avec les principes comme l'absence de support dédié, la nécessité de changer souvent de versions pour intégrer les corrections des bogues anciens (avec pour corolaire l’introduction des nouveaux bogues), etc.
Inertie : thème beaucoup plus intéressant ÀMHA. Effectivement, il y a eu une certaine inertie avec C99 ; si l'on regarde C11, on voit bien que le comité a en eu parfaitement conscience ; et son analyse semble déboucher sur deux points: - les tableaux dynamiques n'ont pas eu le succès escompté ; - les « innovations du comité » n'ont pas leur place dans une révision pour une norme stable comme peut l'être le langage C. Il est très intéressant à ce niveau de comparer avec C++, où les innovations foisonnent, et où certaines sont retirées (après échec).
En fait, on pouvait anticiper cette inertie après l'énorme succès que fut C90; le peu de changement qualitatifs d'envergure offerts par C99 (surtout si on compare avec C++, Java etc.) combiné avec le grand nombre de (principalement petits) changements dans C99 -- 600 pages au lieu de 200-- n'a pas amélioré la situation ; et donc peut être qu'un certain nombre d'acteurs (programmeurs, implémenteurs etc.) ont considéré que C99 n'était pas une révision indispensable.
Antoine
Le 24/07/2014 01:30, Francois Lafont écrivit :
C'est quand même surprenant cette lenteur et cette inertie
qu'on peut constater dans le langage C, par exemple sur le
fait qu'en 2014 certains compilateurs ne soient pas en mesure
d'être 100% conforme C99.
Lenteur : je ne sais pas si c'est réellement le cas, je n'en ai pas
l'impression sur la base de la pratique des cycles de vie des produits.
Je me souviens ainsi que vers 1995 (16 ans après la publication de la
norme ANSI), certains projets se posaient (légitimement) la question
d'opter ou pas pour C90 ; aujourd'hui la notion même de « C K&R »
disparaît graduellement, mais ce n'était pas vrai il y a seulement
quelques années.
Évidemment, si on se base sur le cycle de vie des applications
OpenSource/Bazar ou du « Web 2.0 » en général, tout le reste est
extrêmement lent. Mais bon, il n'y a rien de particulier au langage C à
ce niveau ; et je ne pense pas que l'on peut espérer que le monde des
outils informatiques va passer au seul modèle de développement « 2.0 ».
Sans compter que beaucoup d'utilisateurs « réels » (ceux qui payent) de
compilateurs C ne sont probablement pas d'accord avec les principes
comme l'absence de support dédié, la nécessité de changer souvent de
versions pour intégrer les corrections des bogues anciens (avec pour
corolaire l’introduction des nouveaux bogues), etc.
Inertie : thème beaucoup plus intéressant ÀMHA. Effectivement, il y a eu
une certaine inertie avec C99 ; si l'on regarde C11, on voit bien que le
comité a en eu parfaitement conscience ; et son analyse semble déboucher
sur deux points:
- les tableaux dynamiques n'ont pas eu le succès escompté ;
- les « innovations du comité » n'ont pas leur place dans une révision
pour une norme stable comme peut l'être le langage C.
Il est très intéressant à ce niveau de comparer avec C++, où les
innovations foisonnent, et où certaines sont retirées (après échec).
En fait, on pouvait anticiper cette inertie après l'énorme succès que
fut C90; le peu de changement qualitatifs d'envergure offerts par C99
(surtout si on compare avec C++, Java etc.) combiné avec le grand nombre
de (principalement petits) changements dans C99 -- 600 pages au lieu de
200-- n'a pas amélioré la situation ; et donc peut être qu'un certain
nombre d'acteurs (programmeurs, implémenteurs etc.) ont considéré que
C99 n'était pas une révision indispensable.
C'est quand même surprenant cette lenteur et cette inertie qu'on peut constater dans le langage C, par exemple sur le fait qu'en 2014 certains compilateurs ne soient pas en mesure d'être 100% conforme C99.
Lenteur : je ne sais pas si c'est réellement le cas, je n'en ai pas l'impression sur la base de la pratique des cycles de vie des produits. Je me souviens ainsi que vers 1995 (16 ans après la publication de la norme ANSI), certains projets se posaient (légitimement) la question d'opter ou pas pour C90 ; aujourd'hui la notion même de « C K&R » disparaît graduellement, mais ce n'était pas vrai il y a seulement quelques années. Évidemment, si on se base sur le cycle de vie des applications OpenSource/Bazar ou du « Web 2.0 » en général, tout le reste est extrêmement lent. Mais bon, il n'y a rien de particulier au langage C à ce niveau ; et je ne pense pas que l'on peut espérer que le monde des outils informatiques va passer au seul modèle de développement « 2.0 ». Sans compter que beaucoup d'utilisateurs « réels » (ceux qui payent) de compilateurs C ne sont probablement pas d'accord avec les principes comme l'absence de support dédié, la nécessité de changer souvent de versions pour intégrer les corrections des bogues anciens (avec pour corolaire l’introduction des nouveaux bogues), etc.
Inertie : thème beaucoup plus intéressant ÀMHA. Effectivement, il y a eu une certaine inertie avec C99 ; si l'on regarde C11, on voit bien que le comité a en eu parfaitement conscience ; et son analyse semble déboucher sur deux points: - les tableaux dynamiques n'ont pas eu le succès escompté ; - les « innovations du comité » n'ont pas leur place dans une révision pour une norme stable comme peut l'être le langage C. Il est très intéressant à ce niveau de comparer avec C++, où les innovations foisonnent, et où certaines sont retirées (après échec).
En fait, on pouvait anticiper cette inertie après l'énorme succès que fut C90; le peu de changement qualitatifs d'envergure offerts par C99 (surtout si on compare avec C++, Java etc.) combiné avec le grand nombre de (principalement petits) changements dans C99 -- 600 pages au lieu de 200-- n'a pas amélioré la situation ; et donc peut être qu'un certain nombre d'acteurs (programmeurs, implémenteurs etc.) ont considéré que C99 n'était pas une révision indispensable.
Si je ne m'abuse, tout le monde ou presque a adopte relativement vite les trucs vraiment sympa, comme par exemple stdint.h...
A cote pour C++, il faut bien voir que le gap C++98 -> C++2011 est comparable avec le gap K&R -> ISO C...
Antoine Leca
Le 24/07/2014 15:20, Marc Espie écrivit :
Si je ne m'abuse, tout le monde ou presque a adopte relativement vite les trucs vraiment sympa, comme par exemple stdint.h...
Oui (encore que les finasseries avec C_INT8() sont... incommodes) D'ailleurs, cela m'a fait réécrire une partie de mon message précédent: dans un 1er temps je concluais par « la vraie question, c'est est-ce qu'il faut une révision de C90 ? » Et rien que pour <stdint.h>, je crois que la réponse est oui.
A cote pour C++, il faut bien voir que le gap C++98 -> C++2011 est comparable avec le gap K&R -> ISO C...
Avec la différence que derrière C90, il y a peu d'évolutions (genre VLA, complex ou thread) ; tandis que derrière C++11, il y a C++14, C++17 et probablement d'autres à suivre...
Antoine
Le 24/07/2014 15:20, Marc Espie écrivit :
Si je ne m'abuse, tout le monde ou presque a adopte relativement vite les
trucs vraiment sympa, comme par exemple stdint.h...
Oui (encore que les finasseries avec C_INT8() sont... incommodes)
D'ailleurs, cela m'a fait réécrire une partie de mon message précédent:
dans un 1er temps je concluais par « la vraie question, c'est est-ce
qu'il faut une révision de C90 ? »
Et rien que pour <stdint.h>, je crois que la réponse est oui.
A cote pour C++, il faut bien voir que le gap C++98 -> C++2011 est
comparable avec le gap K&R -> ISO C...
Avec la différence que derrière C90, il y a peu d'évolutions (genre VLA,
complex ou thread) ; tandis que derrière C++11, il y a C++14, C++17 et
probablement d'autres à suivre...
Si je ne m'abuse, tout le monde ou presque a adopte relativement vite les trucs vraiment sympa, comme par exemple stdint.h...
Oui (encore que les finasseries avec C_INT8() sont... incommodes) D'ailleurs, cela m'a fait réécrire une partie de mon message précédent: dans un 1er temps je concluais par « la vraie question, c'est est-ce qu'il faut une révision de C90 ? » Et rien que pour <stdint.h>, je crois que la réponse est oui.
A cote pour C++, il faut bien voir que le gap C++98 -> C++2011 est comparable avec le gap K&R -> ISO C...
Avec la différence que derrière C90, il y a peu d'évolutions (genre VLA, complex ou thread) ; tandis que derrière C++11, il y a C++14, C++17 et probablement d'autres à suivre...
Antoine
espie
In article <lqr2ed$351$, Antoine Leca wrote:
Le 24/07/2014 15:20, Marc Espie écrivit :
Si je ne m'abuse, tout le monde ou presque a adopte relativement vite les trucs vraiment sympa, comme par exemple stdint.h...
Oui (encore que les finasseries avec C_INT8() sont... incommodes)
C'est clair! Et il a fallu helas un peu trop de temps pour que printf et consorts s'adaptent (dans les faits) a size_t et wide ints...
D'ailleurs, cela m'a fait réécrire une partie de mon message précédent: dans un 1er temps je concluais par « la vraie question, c'est est-ce qu'il faut une révision de C90 ? » Et rien que pour <stdint.h>, je crois que la réponse est oui.
A cote pour C++, il faut bien voir que le gap C++98 -> C++2011 est comparable avec le gap K&R -> ISO C...
Avec la différence que derrière C90, il y a peu d'évolutions (genre VLA, complex ou thread) ; tandis que derrière C++11, il y a C++14, C++17 et probablement d'autres à suivre...
Ouais, il y a une volonte deliberee de se replacer en norme a evolution rapide sous formes de groupes de travail separee. Sur le papier, ca a l'air bandant, faut voir ce qui va suivre.
De toutes facons, make_unique() est incontournable en C++14, et les propositions concernant les evolutions des lambda et d'auto ont l'air extremement interessantes.
De mon point de vue, faut voir que c'est plus javascript ou java ou php qui sont en ligne de mire... et de ce cote, C++ a l'air plutot interessant. Meme s'il manque encore, par exemple, une facon standard de faire du graphique (c'est en cours, je crois)... mais pour se placer en concurrent viable, typiquement pour l'education, il faut des bibliotheques systeme simples...
Si la proposition de Gaby et autres concernant d'eventuels modules venait a passer, ca tordrait peut-etre enfin le cou du plus gros souci actuel de C++: les temps de compile et de link delirants. et la, on pourrait envisager de s'en servir a la place du C a plein d'endroits (je sais qu'on aura toujours des irreductibles, en particulier ici, qui diront que c'est perdu d'avance...)
In article <lqr2ed$351$1@shakotay.alphanet.ch>,
Antoine Leca <root@localhost.invalid> wrote:
Le 24/07/2014 15:20, Marc Espie écrivit :
Si je ne m'abuse, tout le monde ou presque a adopte relativement vite les
trucs vraiment sympa, comme par exemple stdint.h...
Oui (encore que les finasseries avec C_INT8() sont... incommodes)
C'est clair! Et il a fallu helas un peu trop de temps pour que printf
et consorts s'adaptent (dans les faits) a size_t et wide ints...
D'ailleurs, cela m'a fait réécrire une partie de mon message précédent:
dans un 1er temps je concluais par « la vraie question, c'est est-ce
qu'il faut une révision de C90 ? »
Et rien que pour <stdint.h>, je crois que la réponse est oui.
A cote pour C++, il faut bien voir que le gap C++98 -> C++2011 est
comparable avec le gap K&R -> ISO C...
Avec la différence que derrière C90, il y a peu d'évolutions (genre VLA,
complex ou thread) ; tandis que derrière C++11, il y a C++14, C++17 et
probablement d'autres à suivre...
Ouais, il y a une volonte deliberee de se replacer en norme a evolution
rapide sous formes de groupes de travail separee. Sur le papier, ca a
l'air bandant, faut voir ce qui va suivre.
De toutes facons, make_unique() est incontournable en C++14, et les
propositions concernant les evolutions des lambda et d'auto ont l'air
extremement interessantes.
De mon point de vue, faut voir que c'est plus javascript ou java ou php
qui sont en ligne de mire... et de ce cote, C++ a l'air plutot
interessant. Meme s'il manque encore, par exemple, une facon standard
de faire du graphique (c'est en cours, je crois)... mais pour se placer
en concurrent viable, typiquement pour l'education, il faut des bibliotheques
systeme simples...
Si la proposition de Gaby et autres concernant d'eventuels modules
venait a passer, ca tordrait peut-etre enfin le cou du plus gros
souci actuel de C++: les temps de compile et de link delirants.
et la, on pourrait envisager de s'en servir a la place du C a plein
d'endroits (je sais qu'on aura toujours des irreductibles, en
particulier ici, qui diront que c'est perdu d'avance...)
Si je ne m'abuse, tout le monde ou presque a adopte relativement vite les trucs vraiment sympa, comme par exemple stdint.h...
Oui (encore que les finasseries avec C_INT8() sont... incommodes)
C'est clair! Et il a fallu helas un peu trop de temps pour que printf et consorts s'adaptent (dans les faits) a size_t et wide ints...
D'ailleurs, cela m'a fait réécrire une partie de mon message précédent: dans un 1er temps je concluais par « la vraie question, c'est est-ce qu'il faut une révision de C90 ? » Et rien que pour <stdint.h>, je crois que la réponse est oui.
A cote pour C++, il faut bien voir que le gap C++98 -> C++2011 est comparable avec le gap K&R -> ISO C...
Avec la différence que derrière C90, il y a peu d'évolutions (genre VLA, complex ou thread) ; tandis que derrière C++11, il y a C++14, C++17 et probablement d'autres à suivre...
Ouais, il y a une volonte deliberee de se replacer en norme a evolution rapide sous formes de groupes de travail separee. Sur le papier, ca a l'air bandant, faut voir ce qui va suivre.
De toutes facons, make_unique() est incontournable en C++14, et les propositions concernant les evolutions des lambda et d'auto ont l'air extremement interessantes.
De mon point de vue, faut voir que c'est plus javascript ou java ou php qui sont en ligne de mire... et de ce cote, C++ a l'air plutot interessant. Meme s'il manque encore, par exemple, une facon standard de faire du graphique (c'est en cours, je crois)... mais pour se placer en concurrent viable, typiquement pour l'education, il faut des bibliotheques systeme simples...
Si la proposition de Gaby et autres concernant d'eventuels modules venait a passer, ca tordrait peut-etre enfin le cou du plus gros souci actuel de C++: les temps de compile et de link delirants. et la, on pourrait envisager de s'en servir a la place du C a plein d'endroits (je sais qu'on aura toujours des irreductibles, en particulier ici, qui diront que c'est perdu d'avance...)
