Newbies en C++ !

drkm

15/08/2004 à 02:16

Luc Hermitte writes:

Je ne crois pas que
quiconque ait parlé d'ignorer ces choses. Juste qu'il faut les présenter
au moment _opportun_.

Bien sûr.

--drkm, en recherche d'un stage : http://www.fgeorges.org/ipl/stage.html

kanze

16/08/2004 à 10:49

drkm wrote in message
news:...

"Arnaud Debaene" writes:

drkm wrote:

"Arnaud Debaene" writes:

Et je ne parle pas des messages où l'on accuse pour ainsi dire un
prof d'imcompétence d'après ce que peux raconter un de ses élèves
ici, sans avoir la moindre idée de ce à quoi ressemble réellement
son cours (et bien sûr sans qu'il ait une chance de s'expliquer).

J'ai moi-même écrit plusieurs articles de ce genre. Sur mes profs à
moi. Un prof de C++ qui ne connaissais pas la notion de namespace, et
n'avait même jamais rencontré « std:: ». Ou un prof de C enseignant
l'égalité stricte entre pointeur et tableau C.

Attention. Il y a une différence de taille entre les deux cas. Un prof
de C++ qui ne connaît pas namespace n'est pas à jour, c'est tout. C'est
loins d'être idéal, mais s'il enseigne bien le C++ d'il y a dix ans,
c'est toujours un bon enseignement -- AMHA, il vaut mieux un bon
enseignement du C++ d'il y a dix ans qu'un mauvais enseignement du C++
actuel. Quelqu'un qui apprend le C++ avec un ancien compilateur, et qui
n'apprend pas les namespace, apprend quand même du C++.

Tandis qu'il n'y a jamais eu un instant où des pointeurs et des tableaux
étaient équivalent en C, et quelqu'un qui apprend le C sans en apprendre
la différence serait incapable d'écrire un programme en C.

C'est pareil en ce qui concerne les livres. Ni Coplien, ni Barton et
Nackman ne mentionne namespace ; Gamma, Helme, Johnson et Vlissides ne
les utilisent pas non plus dans leurs exemples. N'empêche que ce sont
des livres que je conseille fortement. Je dirais même qu'une
connaissance du dernier est souvent un critère d'embauche dans pas mal
de boîtes. Et pour un débuttant, le livre de Robert Martin me paraît
toujours très intéressant, même s'il se sert de ses propres classes pour
des tableaux (et des nuages plutôt que des rectangles dans la
conception). (Il est intéressant, à mon avis, parce que je ne connais
pas de livre plus récent qui prend la même approche -- que
l'apprentissage de la programmation en C++ est plus qu'une apprentissage
des structures syntactiques et la sémantique du langage, et que pour
savoir programmer, il faut aussi savoir un peu de conception.)

Il y a tout de même des critères objectifs permettant de juger de la
compétence d'un prof.

Il y a un critère objectif absolu : est-ce que ses élèves connaissent
bien la matière quand ils sortent du cours. Si c'est un cour sur les
dernières subtilités du C++, c'est une chose. Si c'est un cour sur
comment écrire des programmes qui marche en C++, c'est une autre.

À l'extrème, si c'est un cours pour former des programmeurs (non
ingenieurs en informatique) à VC++, pourquoi pas « void main » ?

Quand ce n'est pas le prof d'un cours que l'on a suivit, il faut
évidemment faire attention à ne pas trop vite généraliser.

Je suis d'accord pour dire que parfois, certains article tranchent
un peu vite sur ces questions. Mais je n'hadère pas à la thèse selon
laquelle on ne peut rien qualifier de négatif, et que si c'est le cas,
alors on est intégriste dans sa manière de voir l'enseignement d'une
matière.

Je n'adhère pas à la thèse qu'on ne peut rien qualifier de négatif non
plus. Le problème, je crains, c'est qu'il y a réelement des profs
mauvais. Et que statistiquement, on trouve la plupart de ceux qui ne se
tiennent pas à jours parmi les mauvais. Du coup, si le fait de ne pas
parler de std::vector ne rend pas forcement un prof mauvais,
statistiquement, la plupart des profs qui n'en parlent pas sont mauvais.

Mais ce n'est pas une raison de s'attaquer à un individu. On a peut-être
affaire à une des rares exceptions.

--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

drkm <usenet.fclcxx@fgeorges.org> wrote in message
news:<wk4qn8pjkg.fsf@fgeorges.org>...

"Arnaud Debaene" <adebaene@club-internet.fr> writes:

drkm wrote:

"Arnaud Debaene" <adebaene@club-internet.fr> writes:

Et je ne parle pas des messages où l'on accuse pour ainsi dire un
prof d'imcompétence d'après ce que peux raconter un de ses élèves
ici, sans avoir la moindre idée de ce à quoi ressemble réellement
son cours (et bien sûr sans qu'il ait une chance de s'expliquer).

J'ai moi-même écrit plusieurs articles de ce genre. Sur mes profs à
moi. Un prof de C++ qui ne connaissais pas la notion de namespace, et
n'avait même jamais rencontré « std:: ». Ou un prof de C enseignant
l'égalité stricte entre pointeur et tableau C.

Attention. Il y a une différence de taille entre les deux cas. Un prof
de C++ qui ne connaît pas namespace n'est pas à jour, c'est tout. C'est
loins d'être idéal, mais s'il enseigne bien le C++ d'il y a dix ans,
c'est toujours un bon enseignement -- AMHA, il vaut mieux un bon
enseignement du C++ d'il y a dix ans qu'un mauvais enseignement du C++
actuel. Quelqu'un qui apprend le C++ avec un ancien compilateur, et qui
n'apprend pas les namespace, apprend quand même du C++.

Tandis qu'il n'y a jamais eu un instant où des pointeurs et des tableaux
étaient équivalent en C, et quelqu'un qui apprend le C sans en apprendre
la différence serait incapable d'écrire un programme en C.

C'est pareil en ce qui concerne les livres. Ni Coplien, ni Barton et
Nackman ne mentionne namespace ; Gamma, Helme, Johnson et Vlissides ne
les utilisent pas non plus dans leurs exemples. N'empêche que ce sont
des livres que je conseille fortement. Je dirais même qu'une
connaissance du dernier est souvent un critère d'embauche dans pas mal
de boîtes. Et pour un débuttant, le livre de Robert Martin me paraît
toujours très intéressant, même s'il se sert de ses propres classes pour
des tableaux (et des nuages plutôt que des rectangles dans la
conception). (Il est intéressant, à mon avis, parce que je ne connais
pas de livre plus récent qui prend la même approche -- que
l'apprentissage de la programmation en C++ est plus qu'une apprentissage
des structures syntactiques et la sémantique du langage, et que pour
savoir programmer, il faut aussi savoir un peu de conception.)

Il y a tout de même des critères objectifs permettant de juger de la
compétence d'un prof.

Il y a un critère objectif absolu : est-ce que ses élèves connaissent
bien la matière quand ils sortent du cours. Si c'est un cour sur les
dernières subtilités du C++, c'est une chose. Si c'est un cour sur
comment écrire des programmes qui marche en C++, c'est une autre.

À l'extrème, si c'est un cours pour former des programmeurs (non
ingenieurs en informatique) à VC++, pourquoi pas « void main » ?

Quand ce n'est pas le prof d'un cours que l'on a suivit, il faut
évidemment faire attention à ne pas trop vite généraliser.

Je suis d'accord pour dire que parfois, certains article tranchent
un peu vite sur ces questions. Mais je n'hadère pas à la thèse selon
laquelle on ne peut rien qualifier de négatif, et que si c'est le cas,
alors on est intégriste dans sa manière de voir l'enseignement d'une
matière.

Je n'adhère pas à la thèse qu'on ne peut rien qualifier de négatif non
plus. Le problème, je crains, c'est qu'il y a réelement des profs
mauvais. Et que statistiquement, on trouve la plupart de ceux qui ne se
tiennent pas à jours parmi les mauvais. Du coup, si le fait de ne pas
parler de std::vector ne rend pas forcement un prof mauvais,
statistiquement, la plupart des profs qui n'en parlent pas sont mauvais.

Mais ce n'est pas une raison de s'attaquer à un individu. On a peut-être
affaire à une des rares exceptions.

--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Vous avez filtré cet utilisateur ! Consultez son message

drkm wrote in message
news:...

"Arnaud Debaene" writes:

drkm wrote:

"Arnaud Debaene" writes:

Et je ne parle pas des messages où l'on accuse pour ainsi dire un
prof d'imcompétence d'après ce que peux raconter un de ses élèves
ici, sans avoir la moindre idée de ce à quoi ressemble réellement
son cours (et bien sûr sans qu'il ait une chance de s'expliquer).

J'ai moi-même écrit plusieurs articles de ce genre. Sur mes profs à
moi. Un prof de C++ qui ne connaissais pas la notion de namespace, et
n'avait même jamais rencontré « std:: ». Ou un prof de C enseignant
l'égalité stricte entre pointeur et tableau C.

Attention. Il y a une différence de taille entre les deux cas. Un prof
de C++ qui ne connaît pas namespace n'est pas à jour, c'est tout. C'est
loins d'être idéal, mais s'il enseigne bien le C++ d'il y a dix ans,
c'est toujours un bon enseignement -- AMHA, il vaut mieux un bon
enseignement du C++ d'il y a dix ans qu'un mauvais enseignement du C++
actuel. Quelqu'un qui apprend le C++ avec un ancien compilateur, et qui
n'apprend pas les namespace, apprend quand même du C++.

Tandis qu'il n'y a jamais eu un instant où des pointeurs et des tableaux
étaient équivalent en C, et quelqu'un qui apprend le C sans en apprendre
la différence serait incapable d'écrire un programme en C.

C'est pareil en ce qui concerne les livres. Ni Coplien, ni Barton et
Nackman ne mentionne namespace ; Gamma, Helme, Johnson et Vlissides ne
les utilisent pas non plus dans leurs exemples. N'empêche que ce sont
des livres que je conseille fortement. Je dirais même qu'une
connaissance du dernier est souvent un critère d'embauche dans pas mal
de boîtes. Et pour un débuttant, le livre de Robert Martin me paraît
toujours très intéressant, même s'il se sert de ses propres classes pour
des tableaux (et des nuages plutôt que des rectangles dans la
conception). (Il est intéressant, à mon avis, parce que je ne connais
pas de livre plus récent qui prend la même approche -- que
l'apprentissage de la programmation en C++ est plus qu'une apprentissage
des structures syntactiques et la sémantique du langage, et que pour
savoir programmer, il faut aussi savoir un peu de conception.)

Il y a tout de même des critères objectifs permettant de juger de la
compétence d'un prof.

Il y a un critère objectif absolu : est-ce que ses élèves connaissent
bien la matière quand ils sortent du cours. Si c'est un cour sur les
dernières subtilités du C++, c'est une chose. Si c'est un cour sur
comment écrire des programmes qui marche en C++, c'est une autre.

À l'extrème, si c'est un cours pour former des programmeurs (non
ingenieurs en informatique) à VC++, pourquoi pas « void main » ?

Quand ce n'est pas le prof d'un cours que l'on a suivit, il faut
évidemment faire attention à ne pas trop vite généraliser.

Je suis d'accord pour dire que parfois, certains article tranchent
un peu vite sur ces questions. Mais je n'hadère pas à la thèse selon
laquelle on ne peut rien qualifier de négatif, et que si c'est le cas,
alors on est intégriste dans sa manière de voir l'enseignement d'une
matière.

Je n'adhère pas à la thèse qu'on ne peut rien qualifier de négatif non
plus. Le problème, je crains, c'est qu'il y a réelement des profs
mauvais. Et que statistiquement, on trouve la plupart de ceux qui ne se
tiennent pas à jours parmi les mauvais. Du coup, si le fait de ne pas
parler de std::vector ne rend pas forcement un prof mauvais,
statistiquement, la plupart des profs qui n'en parlent pas sont mauvais.

Mais ce n'est pas une raison de s'attaquer à un individu. On a peut-être
affaire à une des rares exceptions.

--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

kanze

16/08/2004 à 11:09

Gabriel Dos Reis wrote in message
news:...

writes:

| Laurent Deniau wrote in message
| news:<cffp9d$8sg$...
| > wrote:
| > [...]

| > Note que sur les remarques suivantes, je n'ai pas dit que C++
| > avait tort (la pluspart sont logiques voir indispensables) mais
| > que const a une semantique qui change en fonction de son
| > utilisation. Ca veut dire que le programmeur doit etre plus
| > attentif.

| Je n'ai jamais compris qu'il s'agissait de donner tort à un langage
| ou à un autre. Je contend toujours, en revanche, que le const en C
| et en C++ sont fondamentalement la même chose, à quelques détails
| près, et évidemment, seulement quand il s'agit des choses qu'on peut
| faire dans les deux langages -- c'est difficile de parler de la
| signification d'une fonction membre const ou d'une référence à const
| en C.

| D'après les discussions, je ne vois que les différences suivantes
| dans la partie commune des deux langages :

| 1. const int a = 1 ;

| En C, le nom a un linkage externe (et c'est donc une variable
| globale), en C++, le nom a un linkage interne (et c'est donc une
| variable locale au fichier).

| Et j'avoue que je ne comprends pas cette incohérence en C++.
| Qu'est-ce que le mot clé static a à voir avec le linkage ? Et
| c'est

C'est une excellent question, mais ce n'est pas la sémantique de const
qui dit que « static » a avoir quelque avec le linkage. Donc, pourquoi
poses-tu cette question ?

Il y a une faute de frappe. La question que je voulais poser, c'est
« qu'est-ce que le mot clé const a à voir avec le linkage ? ».

| un piège, parce qu'il amène des gens à écrire des choses comme :

| const int x = 5 ;
| template< T > T f( T a ) { return a + x ; }

| qui a un comportement indéfini (même si c'est difficile à
| concevoir qu'une implémentation puisse faire autre chose que ce
| auquel on s'attend intuitivement).

Peux-tu m'expliquer pour quelles raisons (avec chapitres et versets à
l'appui) tu y vois du comportement indéfini ?

J'aurais du mettre plus de contexte. Je me plaçais dans le contexte
habituel, ou le const et la définition du template se trouvaient dans un
fichier d'en-tête, inclu dans plusieurs unités de traduction. Dans ce
contexte-là, il y a violation de la ODR. Formelle, parce que dans la
pratique, je n'imagine pas que ça pose des problèmes.

Mais en fait, je viens de vérifier dans la norme -- il y a encore un
hack pour le permettre.

--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Gabriel Dos Reis <gdr@integrable-solutions.net> wrote in message
news:<m3k6w3kqfs.fsf@uniton.integrable-solutions.net>...

kanze@gabi-soft.fr writes:

| Laurent Deniau <Laurent.Deniau@cern.ch> wrote in message
| news:<cffp9d$8sg$1@sunnews.cern.ch>...
| > kanze@gabi-soft.fr wrote:
| > [...]

| > Note que sur les remarques suivantes, je n'ai pas dit que C++
| > avait tort (la pluspart sont logiques voir indispensables) mais
| > que const a une semantique qui change en fonction de son
| > utilisation. Ca veut dire que le programmeur doit etre plus
| > attentif.

| Je n'ai jamais compris qu'il s'agissait de donner tort à un langage
| ou à un autre. Je contend toujours, en revanche, que le const en C
| et en C++ sont fondamentalement la même chose, à quelques détails
| près, et évidemment, seulement quand il s'agit des choses qu'on peut
| faire dans les deux langages -- c'est difficile de parler de la
| signification d'une fonction membre const ou d'une référence à const
| en C.

| D'après les discussions, je ne vois que les différences suivantes
| dans la partie commune des deux langages :

| 1. const int a = 1 ;

| En C, le nom a un linkage externe (et c'est donc une variable
| globale), en C++, le nom a un linkage interne (et c'est donc une
| variable locale au fichier).

| Et j'avoue que je ne comprends pas cette incohérence en C++.
| Qu'est-ce que le mot clé static a à voir avec le linkage ? Et
| c'est

C'est une excellent question, mais ce n'est pas la sémantique de const
qui dit que « static » a avoir quelque avec le linkage. Donc, pourquoi
poses-tu cette question ?

Il y a une faute de frappe. La question que je voulais poser, c'est
« qu'est-ce que le mot clé const a à voir avec le linkage ? ».

| un piège, parce qu'il amène des gens à écrire des choses comme :

| const int x = 5 ;
| template< T > T f( T a ) { return a + x ; }

| qui a un comportement indéfini (même si c'est difficile à
| concevoir qu'une implémentation puisse faire autre chose que ce
| auquel on s'attend intuitivement).

Peux-tu m'expliquer pour quelles raisons (avec chapitres et versets à
l'appui) tu y vois du comportement indéfini ?

J'aurais du mettre plus de contexte. Je me plaçais dans le contexte
habituel, ou le const et la définition du template se trouvaient dans un
fichier d'en-tête, inclu dans plusieurs unités de traduction. Dans ce
contexte-là, il y a violation de la ODR. Formelle, parce que dans la
pratique, je n'imagine pas que ça pose des problèmes.

Mais en fait, je viens de vérifier dans la norme -- il y a encore un
hack pour le permettre.

--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Vous avez filtré cet utilisateur ! Consultez son message

Gabriel Dos Reis wrote in message
news:...

writes:

| Laurent Deniau wrote in message
| news:<cffp9d$8sg$...
| > wrote:
| > [...]

| > Note que sur les remarques suivantes, je n'ai pas dit que C++
| > avait tort (la pluspart sont logiques voir indispensables) mais
| > que const a une semantique qui change en fonction de son
| > utilisation. Ca veut dire que le programmeur doit etre plus
| > attentif.

| Je n'ai jamais compris qu'il s'agissait de donner tort à un langage
| ou à un autre. Je contend toujours, en revanche, que le const en C
| et en C++ sont fondamentalement la même chose, à quelques détails
| près, et évidemment, seulement quand il s'agit des choses qu'on peut
| faire dans les deux langages -- c'est difficile de parler de la
| signification d'une fonction membre const ou d'une référence à const
| en C.

| D'après les discussions, je ne vois que les différences suivantes
| dans la partie commune des deux langages :

| 1. const int a = 1 ;

| En C, le nom a un linkage externe (et c'est donc une variable
| globale), en C++, le nom a un linkage interne (et c'est donc une
| variable locale au fichier).

| Et j'avoue que je ne comprends pas cette incohérence en C++.
| Qu'est-ce que le mot clé static a à voir avec le linkage ? Et
| c'est

C'est une excellent question, mais ce n'est pas la sémantique de const
qui dit que « static » a avoir quelque avec le linkage. Donc, pourquoi
poses-tu cette question ?

Il y a une faute de frappe. La question que je voulais poser, c'est
« qu'est-ce que le mot clé const a à voir avec le linkage ? ».

| un piège, parce qu'il amène des gens à écrire des choses comme :

| const int x = 5 ;
| template< T > T f( T a ) { return a + x ; }

| qui a un comportement indéfini (même si c'est difficile à
| concevoir qu'une implémentation puisse faire autre chose que ce
| auquel on s'attend intuitivement).

Peux-tu m'expliquer pour quelles raisons (avec chapitres et versets à
l'appui) tu y vois du comportement indéfini ?

J'aurais du mettre plus de contexte. Je me plaçais dans le contexte
habituel, ou le const et la définition du template se trouvaient dans un
fichier d'en-tête, inclu dans plusieurs unités de traduction. Dans ce
contexte-là, il y a violation de la ODR. Formelle, parce que dans la
pratique, je n'imagine pas que ça pose des problèmes.

Mais en fait, je viens de vérifier dans la norme -- il y a encore un
hack pour le permettre.

--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

kanze

16/08/2004 à 11:40

Gabriel Dos Reis wrote in message
news:...

writes:
| Laurent Deniau wrote in message
| news:<cfd6um$kqa$...
| > Jean-Marc Bourguet wrote:
| > > writes:

| > >>Laurent Deniau wrote in message
| > >>news:<cfai51$po6$...

| > >>>Fabien LE LEZ wrote:

| > >>>>On Tue, 10 Aug 2004 14:54:10 +0200, Fabien LE LEZ
| > >>>>:

| > >>>>>Est-ce que C gère correctement "const" ?

| > >>>>Note : il s'agit bien d'une question. J'ai vraiment de grosses
| > >>>>lacunes en C (ou, pour prendre le problème à l'envers, j'ai quelques
| > >>>>vagues connaissances en C ;-) ).

| > >>>Pour repondre, il faudrait d'abord definir ce que l'on attend
| > >>>de const dans le language et que signifie gerer "correctement"
| > >>>const. Hormis ces deux considerations, const en C est plus
| > >>>simple et plus logique (pas de cas particulier de sa
| > >>>semantique), mais ca ne repond en rien a la question :-).

| > >>Comme j'ai déjà dit, les deux langages sont prèsqu'identique
| > >>dans leur traitement de const, dans les parties communes. (En
| > >>fait, de tête, je crois qu'ils y sont rigueureusement
| > >>identiques. Et que c'était en tout cas l'intention du comité de
| > >>normalisation C++ et avant de Stroustrup qu'ils le soient.) En
| > >>revanche :

| > > De memoire, les regles pour const dans des pointeurs vers
| > > pointeurs sont moins strictes (mais aussi sures) en C++ qu'en C.

| En effet. En fait, la différence a été conçue comme une correction ;
| les règles C++ devaient correspondre plus à ce que les auteurs de la
| norme C ont voulu. Cependant, la « correction » n'a pas été réprise
| en C99.

« D&E, §3.8 Constants »

C'est intéressant, à plusieurs réprises. Mais quel rapport avec la
« correction » dont on parle ici. Le fait qu'en C++, tu peux écrire :

char* pc ;
char const* const* ppc = &pc ;

mais non en C ?

Pour la reste, une question importante : nous savons ce qui est venu
readonly, mais qu'est-ce qui s'est passé avec writeonly ?

[...]

Unfortunately, a vote isn't
executable, so nothing happened to our C compilers.

Une précédent pour export ? :-)

[...]

In the meantime, I had experimented further with const in C with
Classes and foound that const was a useful alternative to macros for
representing constants only if global consts were implicitly local
to their compilation unit. Only in that case could the compiler
easily deduce that their value really didn't change.

J'aurais aimé un peu plus ici. Je ne vois pas vraiement le problème, à
moins qu'on cherche simplement à réduire des possibilités des violations
de la ODR. Ou peut-être simplement qu'il fallait un hack, d'une façon ou
une autre, et que celui-là semblait aussi bien qu'un autre.
(Aujourd'hui, en 2004, et donnée qu'on a déjà un différent hack pour les
membres static const, je dirais que la solution logique est d'utiliser
le même hack dans les deux cas. Mais bon, c'est aujourd'hui.)

En fait, on a encore un mot clé qui fait double emploi -- d'après
l'histoire, et encore l'utilisation la plus générale, const signifie
qu'un objet peut être placé en ROM. Mais nous l'utilisons aussi pour des
constantes manifestes (les « constant integral expressions », selon la
norme). Or, en tant qu'objet, on ne doit la définir (et donner
l'initialisation) qu'une seule fois. Tandis qu'en tant que constante
manifeste, il faut bien que toutes les unités de compilation contienne
sa valeur.

D'un point de vue strictement théorique, j'imaginerai un nouveau storage
class pour des constantes manifestes, qui dit plus ou moins qu'elles ne
sont pas des objets, qu'on ne peut pas, par exemple, en prendre
l'adresse. Mais c'est une complication en plus, simplement pour
satisfaire à un idéalisme.

--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Gabriel Dos Reis <gdr@integrable-solutions.net> wrote in message
news:<m3smarkqtv.fsf@uniton.integrable-solutions.net>...

kanze@gabi-soft.fr writes:
| Laurent Deniau <Laurent.Deniau@cern.ch> wrote in message
| news:<cfd6um$kqa$1@sunnews.cern.ch>...
| > Jean-Marc Bourguet wrote:
| > > kanze@gabi-soft.fr writes:

| > >>Laurent Deniau <Laurent.Deniau@cern.ch> wrote in message
| > >>news:<cfai51$po6$2@sunnews.cern.ch>...

| > >>>Fabien LE LEZ wrote:

| > >>>>On Tue, 10 Aug 2004 14:54:10 +0200, Fabien LE LEZ
| > >>>><gramster@gramster.com>:

| > >>>>>Est-ce que C gère correctement "const" ?

| > >>>>Note : il s'agit bien d'une question. J'ai vraiment de grosses
| > >>>>lacunes en C (ou, pour prendre le problème à l'envers, j'ai quelques
| > >>>>vagues connaissances en C ;-) ).

| > >>>Pour repondre, il faudrait d'abord definir ce que l'on attend
| > >>>de const dans le language et que signifie gerer "correctement"
| > >>>const. Hormis ces deux considerations, const en C est plus
| > >>>simple et plus logique (pas de cas particulier de sa
| > >>>semantique), mais ca ne repond en rien a la question :-).

| > >>Comme j'ai déjà dit, les deux langages sont prèsqu'identique
| > >>dans leur traitement de const, dans les parties communes. (En
| > >>fait, de tête, je crois qu'ils y sont rigueureusement
| > >>identiques. Et que c'était en tout cas l'intention du comité de
| > >>normalisation C++ et avant de Stroustrup qu'ils le soient.) En
| > >>revanche :

| > > De memoire, les regles pour const dans des pointeurs vers
| > > pointeurs sont moins strictes (mais aussi sures) en C++ qu'en C.

| En effet. En fait, la différence a été conçue comme une correction ;
| les règles C++ devaient correspondre plus à ce que les auteurs de la
| norme C ont voulu. Cependant, la « correction » n'a pas été réprise
| en C99.

« D&E, §3.8 Constants »

C'est intéressant, à plusieurs réprises. Mais quel rapport avec la
« correction » dont on parle ici. Le fait qu'en C++, tu peux écrire :

char* pc ;
char const* const* ppc = &pc ;

mais non en C ?

Pour la reste, une question importante : nous savons ce qui est venu
readonly, mais qu'est-ce qui s'est passé avec writeonly ?

[...]

Unfortunately, a vote isn't
executable, so nothing happened to our C compilers.

Une précédent pour export ? :-)

[...]

In the meantime, I had experimented further with const in C with
Classes and foound that const was a useful alternative to macros for
representing constants only if global consts were implicitly local
to their compilation unit. Only in that case could the compiler
easily deduce that their value really didn't change.

J'aurais aimé un peu plus ici. Je ne vois pas vraiement le problème, à
moins qu'on cherche simplement à réduire des possibilités des violations
de la ODR. Ou peut-être simplement qu'il fallait un hack, d'une façon ou
une autre, et que celui-là semblait aussi bien qu'un autre.
(Aujourd'hui, en 2004, et donnée qu'on a déjà un différent hack pour les
membres static const, je dirais que la solution logique est d'utiliser
le même hack dans les deux cas. Mais bon, c'est aujourd'hui.)

En fait, on a encore un mot clé qui fait double emploi -- d'après
l'histoire, et encore l'utilisation la plus générale, const signifie
qu'un objet peut être placé en ROM. Mais nous l'utilisons aussi pour des
constantes manifestes (les « constant integral expressions », selon la
norme). Or, en tant qu'objet, on ne doit la définir (et donner
l'initialisation) qu'une seule fois. Tandis qu'en tant que constante
manifeste, il faut bien que toutes les unités de compilation contienne
sa valeur.

D'un point de vue strictement théorique, j'imaginerai un nouveau storage
class pour des constantes manifestes, qui dit plus ou moins qu'elles ne
sont pas des objets, qu'on ne peut pas, par exemple, en prendre
l'adresse. Mais c'est une complication en plus, simplement pour
satisfaire à un idéalisme.

--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Vous avez filtré cet utilisateur ! Consultez son message

Gabriel Dos Reis wrote in message
news:...

writes:
| Laurent Deniau wrote in message
| news:<cfd6um$kqa$...
| > Jean-Marc Bourguet wrote:
| > > writes:

| > >>Laurent Deniau wrote in message
| > >>news:<cfai51$po6$...

| > >>>Fabien LE LEZ wrote:

| > >>>>On Tue, 10 Aug 2004 14:54:10 +0200, Fabien LE LEZ
| > >>>>:

| > >>>>>Est-ce que C gère correctement "const" ?

| > >>>>Note : il s'agit bien d'une question. J'ai vraiment de grosses
| > >>>>lacunes en C (ou, pour prendre le problème à l'envers, j'ai quelques
| > >>>>vagues connaissances en C ;-) ).

| > >>>Pour repondre, il faudrait d'abord definir ce que l'on attend
| > >>>de const dans le language et que signifie gerer "correctement"
| > >>>const. Hormis ces deux considerations, const en C est plus
| > >>>simple et plus logique (pas de cas particulier de sa
| > >>>semantique), mais ca ne repond en rien a la question :-).

| > >>Comme j'ai déjà dit, les deux langages sont prèsqu'identique
| > >>dans leur traitement de const, dans les parties communes. (En
| > >>fait, de tête, je crois qu'ils y sont rigueureusement
| > >>identiques. Et que c'était en tout cas l'intention du comité de
| > >>normalisation C++ et avant de Stroustrup qu'ils le soient.) En
| > >>revanche :

| > > De memoire, les regles pour const dans des pointeurs vers
| > > pointeurs sont moins strictes (mais aussi sures) en C++ qu'en C.

| En effet. En fait, la différence a été conçue comme une correction ;
| les règles C++ devaient correspondre plus à ce que les auteurs de la
| norme C ont voulu. Cependant, la « correction » n'a pas été réprise
| en C99.

« D&E, §3.8 Constants »

C'est intéressant, à plusieurs réprises. Mais quel rapport avec la
« correction » dont on parle ici. Le fait qu'en C++, tu peux écrire :

char* pc ;
char const* const* ppc = &pc ;

mais non en C ?

Pour la reste, une question importante : nous savons ce qui est venu
readonly, mais qu'est-ce qui s'est passé avec writeonly ?

[...]

Unfortunately, a vote isn't
executable, so nothing happened to our C compilers.

Une précédent pour export ? :-)

[...]

In the meantime, I had experimented further with const in C with
Classes and foound that const was a useful alternative to macros for
representing constants only if global consts were implicitly local
to their compilation unit. Only in that case could the compiler
easily deduce that their value really didn't change.

J'aurais aimé un peu plus ici. Je ne vois pas vraiement le problème, à
moins qu'on cherche simplement à réduire des possibilités des violations
de la ODR. Ou peut-être simplement qu'il fallait un hack, d'une façon ou
une autre, et que celui-là semblait aussi bien qu'un autre.
(Aujourd'hui, en 2004, et donnée qu'on a déjà un différent hack pour les
membres static const, je dirais que la solution logique est d'utiliser
le même hack dans les deux cas. Mais bon, c'est aujourd'hui.)

En fait, on a encore un mot clé qui fait double emploi -- d'après
l'histoire, et encore l'utilisation la plus générale, const signifie
qu'un objet peut être placé en ROM. Mais nous l'utilisons aussi pour des
constantes manifestes (les « constant integral expressions », selon la
norme). Or, en tant qu'objet, on ne doit la définir (et donner
l'initialisation) qu'une seule fois. Tandis qu'en tant que constante
manifeste, il faut bien que toutes les unités de compilation contienne
sa valeur.

D'un point de vue strictement théorique, j'imaginerai un nouveau storage
class pour des constantes manifestes, qui dit plus ou moins qu'elles ne
sont pas des objets, qu'on ne peut pas, par exemple, en prendre
l'adresse. Mais c'est une complication en plus, simplement pour
satisfaire à un idéalisme.

--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Gabriel Dos Reis

16/08/2004 à 11:43

writes:

[...]

| > | un piège, parce qu'il amène des gens à écrire des choses comme :
|
| > | const int x = 5 ;
| > | template< T > T f( T a ) { return a + x ; }
|
| > | qui a un comportement indéfini (même si c'est difficile à
| > | concevoir qu'une implémentation puisse faire autre chose que ce
| > | auquel on s'attend intuitivement).
|
| > Peux-tu m'expliquer pour quelles raisons (avec chapitres et versets à
| > l'appui) tu y vois du comportement indéfini ?
|
| J'aurais du mettre plus de contexte. Je me plaçais dans le contexte
| habituel, ou le const et la définition du template se trouvaient dans un
| fichier d'en-tête, inclu dans plusieurs unités de traduction. Dans ce
| contexte-là, il y a violation de la ODR.

Je ne vois toujours pas pourquoi. Je repose donc ma question initiale.

| Formelle, parce que dans la
| pratique, je n'imagine pas que ça pose des problèmes.
|
| Mais en fait, je viens de vérifier dans la norme -- il y a encore un
| hack pour le permettre.

Tant que tu n'as pas répondu à ma question, il est difficile de voir
de quoi tu parles et ce qui est un hack.
Et de plus, si c'est explicitement permis, alors il n'y a plus de
violation.

-- Gaby

Loïc Joly

16/08/2004 à 12:56

Sayajin wrote:

Bon ben chaque fois que j'ai parlé de "Accelerated C++" personne a bronché
je suis parti sur celui-là !

C'est souvent celui que je conseille, mais si tu peux faire un feed back
quand tu auras fini, c'est toujours intéressant, puisqu'il n'est pas
aisé de juger de la compréhensibilité des explications de ce qu'on
connait déjà.

--
Loïc

Sayajin

16/08/2004 à 14:29

"Loïc Joly" a écrit dans le message de
news:cfq3lc$ttm$

Sayajin wrote:

Bon ben chaque fois que j'ai parlé de "Accelerated C++" personne a
bronché

je suis parti sur celui-là !

C'est souvent celui que je conseille, mais si tu peux faire un feed back
quand tu auras fini, c'est toujours intéressant, puisqu'il n'est pas
aisé de juger de la compréhensibilité des explications de ce qu'on
connait déjà.

--
Loïc

J'y manquerais pas ;-)

Michel Michaud

16/08/2004 à 14:51

Dans news:cfi7cq$qqj$,

"Michel Michaud" a écrit dans le message de
news:YCUSc.26481$
Dans news:cfgi81$aef$,
Eh bien moi je m'attaque au C++ avec un bon petit bouquin de
poche "La langage C++" de Olivier Dupin, bien vu dans d'autre
forum.
[...]

Il décrit le C++ d'avant norme (la norme existe depuis 1998).
Donc pour toi, il est complètement dépassé et te forcera à
apprendre des choses inutiles et incorrectes aujourd'hui.
[...]

Tu viens de me mettre un poignard dans le dos, pourtant y'a eu
une nouvelle edition en 2003. Bon je vais me mettre directe au

Je n'ai pas regardé la date, j'ai bien l'impression que le
livre que j'ai vu était très récent. Vérifie par toi-même si le
tien parle de std::string, std::vector, etc.

Stroustroup . . . Donc pour toi c'est quoi le bouquin nec plsu
ultra pour commencer le C++ j'ai déjà programmer et fait de la
POO.

Déjà programmé et fait de la POO ? Alors Stroustrup, Lippman et
Lajoie, Koenig, etc., t'offrent des livres intéressants...
http:://www.accu.org est ton ami, particulièrement
http://minilien.com/?vRbvwi7za1

--
Michel Michaud
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/

Michel Michaud

16/08/2004 à 14:58

Dans news:cfj3nq$6ac$,

"Michel Michaud" a écrit dans le message de
news:YCUSc.26481$
Dans news:cfgi81$aef$,
Eh bien moi je m'attaque au C++ avec un bon petit bouquin de
poche "La langage C++" de Olivier Dupin, bien vu dans d'autre
forum.
[...]

Il décrit le C++ d'avant norme (la norme existe depuis 1998).
Donc pour toi, il est complètement dépassé et te forcera à
apprendre des choses inutiles et incorrectes aujourd'hui.
[...]

Y'a quand même beaucoup de monde qui en sont satisfait et
d'autres qui le cite en référence.

Satisfait dans quel sens ? Il est peut-être très bon pour
enseigner ce qu'il enseigne et ça pourrait satisfaire certaines
personnes. Ça dépend donc de ce que tu veux apprendre. Mais
on ne peut pas dire qu'il explique ISO C++, ça c'est sûr et
c'est probablement ce que tu veux apprendre.

Supposons un excellent livre sur C++, mais dont le titre serait
« Apprendre VB en 40 heures », est-ce que ceux qui veulent
apprendre VB vont dire que c'est un bon livre ? Peut-être !
S'ils ne savent pas ce qu'est VB !

--
Michel Michaud
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/

Michel Michaud

16/08/2004 à 15:00

Dans news:cfi8u6$h2j$,

En bouquins français, je conseillerais "Programmation C++ par
la pratique" (deuxième édition), de Oualline chez O'Reilly, et

Voir www.accu.org...

"L'essentiel du C++" de Lippman et Lajoie chez Vuibert. Le
deuxième est vraiment très bien, mais coute vraiment très cher.

Bon livre, pourrait être meilleur... Mais je n'ai pas lu la
version française !

--
Michel Michaud
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/

Newbies en C++ !

10 réponses

Veuillez sélectionner un problème