Newbies en C++ !

Laurent Deniau

13/08/2004 à 16:55

drkm wrote:

Laurent Deniau writes:

drkm wrote:

Laurent Deniau writes:

me semble qu'a *l'exterieur de la definition d'une classe* on peut
utiliser partout un const int a la place d'un enum. La reciproque
n'est biensur pas vraie.

Si tu parles de la réciproque « enum à la place d'un int », alors
si. Une énumération est implicitement convertible en entier, non ?

enum { e=1 };
const int a=1;

const int *p = &a; // ok
const int *q = &e; // boum

Donc la ou a passe, e ne passe pas necessairement...

Mais c'est encore moins vrai dans l'autre sens, non ? Puisqu'il n'y
a pas de conversion implicite des entiers vers les énumération :

~> cat fclcxx.cc
enum E {
e = 0
} ;
int monI = e ;
E monE = 0 ;
~> g++ -o fclcxx.o -c fclcxx.cc -Wall -ansi -pedantic
fclcxx.cc:5: error: invalid conversion from 'int' to 'E'

C'est vrai. Donc un contre exemple que je cherchais pourrait etre

{
enum E { e=1 };
const int a=1;

E v = e; // ok
E v = a; // boum
}

Donc dans ce cas d'accord, ce qui est effectivement evident. Mais
vois-tu d'autres cas?

Pour ce qui est de l'utilisation d'un entier à la place d'une
énumération, cela me semble bizarre. Ne t'emmêles-tu pas simplement
les pinceaux avec leur utilisation commune en tant que « integral
constant-expression » ?

J'ai parler de comportement. Je n'ai pas dit qu'un const int etait un
enum. Je demandais pour infirmer ma conjecture un exemple qui montre
un cas d'utilisation en C++ ou un enum ne peut pas etre substitue par
un const int.

Cfr. l'exemple ci-dessus, en remplaçant le litéral '0' par une
variable de type « int const », ce qui revient à la même erreur.

Yep.

En C on a le cas trivial:

{ // Ok C++ pas C
const int size = 10;
int array[size];

// ...
}

Tu veux dire que ceci n'est pas du C ? J'aurais dit qu'à l'inverse
du C++, en C, size peut même n'être pas constant. Cfr. les VLAs.
Non ?

Arf, en C99 tout a fait d'accord. Je pense encore trop souvent en C89...

La particularite C++ est que const int peut etre utilise dans une
expression integrale constante, a condition que son initialisation
soit elle meme une expression integrale constante, ce n'est pas le cas
en C.

Il s'agit alors lui-même d'une « integral constant-expression ».
Cfr. 5.19 :

« An integral constant-expression can involve only literals,
enumerators, const variables or static data members of integral
or enumeration types initialized with constant expressions,
non-type template parameters of integral or enumeration types,
and sizeof expressions. »

Mais peut-être n'ai pas tout à fait compris ce que tu voulais dire ?

Si, c'est exactement ce que je voulais dire.

a+, ld.

drkm wrote:

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

drkm wrote:

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

me semble qu'a *l'exterieur de la definition d'une classe* on peut
utiliser partout un const int a la place d'un enum. La reciproque
n'est biensur pas vraie.

Si tu parles de la réciproque « enum à la place d'un int », alors
si. Une énumération est implicitement convertible en entier, non ?

enum { e=1 };
const int a=1;

const int *p = &a; // ok
const int *q = &e; // boum

Donc la ou a passe, e ne passe pas necessairement...

Mais c'est encore moins vrai dans l'autre sens, non ? Puisqu'il n'y
a pas de conversion implicite des entiers vers les énumération :

~> cat fclcxx.cc
enum E {
e = 0
} ;
int monI = e ;
E monE = 0 ;
~> g++ -o fclcxx.o -c fclcxx.cc -Wall -ansi -pedantic
fclcxx.cc:5: error: invalid conversion from 'int' to 'E'

C'est vrai. Donc un contre exemple que je cherchais pourrait etre

{
enum E { e=1 };
const int a=1;

E v = e; // ok
E v = a; // boum
}

Donc dans ce cas d'accord, ce qui est effectivement evident. Mais
vois-tu d'autres cas?

Pour ce qui est de l'utilisation d'un entier à la place d'une
énumération, cela me semble bizarre. Ne t'emmêles-tu pas simplement
les pinceaux avec leur utilisation commune en tant que « integral
constant-expression » ?

J'ai parler de comportement. Je n'ai pas dit qu'un const int etait un
enum. Je demandais pour infirmer ma conjecture un exemple qui montre
un cas d'utilisation en C++ ou un enum ne peut pas etre substitue par
un const int.

Cfr. l'exemple ci-dessus, en remplaçant le litéral '0' par une
variable de type « int const », ce qui revient à la même erreur.

Yep.

En C on a le cas trivial:

{ // Ok C++ pas C
const int size = 10;
int array[size];

// ...
}

Tu veux dire que ceci n'est pas du C ? J'aurais dit qu'à l'inverse
du C++, en C, size peut même n'être pas constant. Cfr. les VLAs.
Non ?

Arf, en C99 tout a fait d'accord. Je pense encore trop souvent en C89...

La particularite C++ est que const int peut etre utilise dans une
expression integrale constante, a condition que son initialisation
soit elle meme une expression integrale constante, ce n'est pas le cas
en C.

Il s'agit alors lui-même d'une « integral constant-expression ».
Cfr. 5.19 :

« An integral constant-expression can involve only literals,
enumerators, const variables or static data members of integral
or enumeration types initialized with constant expressions,
non-type template parameters of integral or enumeration types,
and sizeof expressions. »

Mais peut-être n'ai pas tout à fait compris ce que tu voulais dire ?

Si, c'est exactement ce que je voulais dire.

a+, ld.

Vous avez filtré cet utilisateur ! Consultez son message

drkm wrote:

Laurent Deniau writes:

drkm wrote:

Laurent Deniau writes:

me semble qu'a *l'exterieur de la definition d'une classe* on peut
utiliser partout un const int a la place d'un enum. La reciproque
n'est biensur pas vraie.

Si tu parles de la réciproque « enum à la place d'un int », alors
si. Une énumération est implicitement convertible en entier, non ?

enum { e=1 };
const int a=1;

const int *p = &a; // ok
const int *q = &e; // boum

Donc la ou a passe, e ne passe pas necessairement...

Mais c'est encore moins vrai dans l'autre sens, non ? Puisqu'il n'y
a pas de conversion implicite des entiers vers les énumération :

~> cat fclcxx.cc
enum E {
e = 0
} ;
int monI = e ;
E monE = 0 ;
~> g++ -o fclcxx.o -c fclcxx.cc -Wall -ansi -pedantic
fclcxx.cc:5: error: invalid conversion from 'int' to 'E'

C'est vrai. Donc un contre exemple que je cherchais pourrait etre

{
enum E { e=1 };
const int a=1;

E v = e; // ok
E v = a; // boum
}

Donc dans ce cas d'accord, ce qui est effectivement evident. Mais
vois-tu d'autres cas?

Pour ce qui est de l'utilisation d'un entier à la place d'une
énumération, cela me semble bizarre. Ne t'emmêles-tu pas simplement
les pinceaux avec leur utilisation commune en tant que « integral
constant-expression » ?

J'ai parler de comportement. Je n'ai pas dit qu'un const int etait un
enum. Je demandais pour infirmer ma conjecture un exemple qui montre
un cas d'utilisation en C++ ou un enum ne peut pas etre substitue par
un const int.

Cfr. l'exemple ci-dessus, en remplaçant le litéral '0' par une
variable de type « int const », ce qui revient à la même erreur.

Yep.

En C on a le cas trivial:

{ // Ok C++ pas C
const int size = 10;
int array[size];

// ...
}

Tu veux dire que ceci n'est pas du C ? J'aurais dit qu'à l'inverse
du C++, en C, size peut même n'être pas constant. Cfr. les VLAs.
Non ?

Arf, en C99 tout a fait d'accord. Je pense encore trop souvent en C89...

La particularite C++ est que const int peut etre utilise dans une
expression integrale constante, a condition que son initialisation
soit elle meme une expression integrale constante, ce n'est pas le cas
en C.

Il s'agit alors lui-même d'une « integral constant-expression ».
Cfr. 5.19 :

« An integral constant-expression can involve only literals,
enumerators, const variables or static data members of integral
or enumeration types initialized with constant expressions,
non-type template parameters of integral or enumeration types,
and sizeof expressions. »

Mais peut-être n'ai pas tout à fait compris ce que tu voulais dire ?

Si, c'est exactement ce que je voulais dire.

a+, ld.

Fabien LE LEZ

13/08/2004 à 17:11

On Fri, 13 Aug 2004 11:57:29 +0200, Martinez Jerome
:

C'est pourtant un très gros reproche fait au C++ : sa SL

Sans doute, mais tu parlais de STL, précédemment.

--
;-)

Gabriel Dos Reis

13/08/2004 à 17:20

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 »

In operating systems, it is common to have access to some piece of
memory controlled directly or indirectly by tow bits: one that
indicates whether a user can write to it and one that indicate
whether a user can read it. This idea seemed to me directly
applicable to C++, and I considered allowing every type to be
specified readonly or writeonly. An internal memo dated January
1981 [Stroustrup, 1981b] describes the idea:

"Until now it has not been possible in C to specify that a data
item should be /read only/, that is, that its value must remain
unchanged. Neither has there been any way of restricting the use
of the arguments passed to a function. Dennis Ritchie pointed
out that if readonly was a type operator, both facilities couold
be obtained easily, for example:

readonly char table[1024]; /* the chars in "table"
cannot be updated */
int f(readonly int * p)
{
/* "f" cannot update the date denoted by "p" */
/* ... */
}

The readonly operator is used to prevent update of some
location. It specifies that out of the usually legal ways of
accessing the location, only the ones that do not change the
value stored there are legal."

The memo goes on to point out that

"The readonly operator can be used on pointers, too. *readonly
is interpreted as "readonly pointer to," for example:

readonly int * p; /* pointer to read only int */
int* readonly pp; /* read only pointer to int */
readonly int * readonly ppp; /* read only pointer
to read only int */

Here it is legal to assign a new value to p, but not to *p. It
is legal to assign to *pp, but not pp, and it is illegal to
assign to ppp, or *ppp."

Finaly, the memo introduces writeonly:

"There is a type operator writeonly, which is used like
readonly, but prevents reading rather than writing. [...]

The proposal focued on specifying interfaces rather than providing
symbolic constants for C. Clearly, a readonly value is symbolic
constant, but the scope of the proposal is far greater. Initially,
I proposed pointers to readonly but not readonly pointers. A brief
discussion with Dennis Ritchie evolved the idea into the
readonly/writeonly mechanism that I implemented and proposed to an
internal Bell Labs C standards group cgaired by Larry Rosler.
There, I had my first experience with standards work. I came away
from a metting with an agreement (that is, a vote) that readonly
would be introduced into C -- yes C, not C with Classes or C++ --
provided it was renamed const. Unfortunately, a vote isn't
executable, so nothing happened to our C compilers. Latter, the
ANSI C committee (X3J11) was formed and the const proposal
resurfaced and become part of ANSI/ISO C.

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. Knowing that
allows us to use simple consts in constant expression and to avoid
allocating space for such constants. C did not adopt this rule.
[...] This makes consts far less useful in C than in C++ and leaves
C dependent on the preprocessor while C++ programmers can use
properly typed and scoped consts.

Pour la version integrale, voir le bouquin.

-- Gaby

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 »

In operating systems, it is common to have access to some piece of
memory controlled directly or indirectly by tow bits: one that
indicates whether a user can write to it and one that indicate
whether a user can read it. This idea seemed to me directly
applicable to C++, and I considered allowing every type to be
specified readonly or writeonly. An internal memo dated January
1981 [Stroustrup, 1981b] describes the idea:

"Until now it has not been possible in C to specify that a data
item should be /read only/, that is, that its value must remain
unchanged. Neither has there been any way of restricting the use
of the arguments passed to a function. Dennis Ritchie pointed
out that if readonly was a type operator, both facilities couold
be obtained easily, for example:

readonly char table[1024]; /* the chars in "table"
cannot be updated */
int f(readonly int * p)
{
/* "f" cannot update the date denoted by "p" */
/* ... */
}

The readonly operator is used to prevent update of some
location. It specifies that out of the usually legal ways of
accessing the location, only the ones that do not change the
value stored there are legal."

The memo goes on to point out that

"The readonly operator can be used on pointers, too. *readonly
is interpreted as "readonly pointer to," for example:

readonly int * p; /* pointer to read only int */
int* readonly pp; /* read only pointer to int */
readonly int * readonly ppp; /* read only pointer
to read only int */

Here it is legal to assign a new value to p, but not to *p. It
is legal to assign to *pp, but not pp, and it is illegal to
assign to ppp, or *ppp."

Finaly, the memo introduces writeonly:

"There is a type operator writeonly, which is used like
readonly, but prevents reading rather than writing. [...]

The proposal focued on specifying interfaces rather than providing
symbolic constants for C. Clearly, a readonly value is symbolic
constant, but the scope of the proposal is far greater. Initially,
I proposed pointers to readonly but not readonly pointers. A brief
discussion with Dennis Ritchie evolved the idea into the
readonly/writeonly mechanism that I implemented and proposed to an
internal Bell Labs C standards group cgaired by Larry Rosler.
There, I had my first experience with standards work. I came away
from a metting with an agreement (that is, a vote) that readonly
would be introduced into C -- yes C, not C with Classes or C++ --
provided it was renamed const. Unfortunately, a vote isn't
executable, so nothing happened to our C compilers. Latter, the
ANSI C committee (X3J11) was formed and the const proposal
resurfaced and become part of ANSI/ISO C.

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. Knowing that
allows us to use simple consts in constant expression and to avoid
allocating space for such constants. C did not adopt this rule.
[...] This makes consts far less useful in C than in C++ and leaves
C dependent on the preprocessor while C++ programmers can use
properly typed and scoped consts.

Pour la version integrale, voir le bouquin.

-- Gaby

Vous avez filtré cet utilisateur ! Consultez son message

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 »

In operating systems, it is common to have access to some piece of
memory controlled directly or indirectly by tow bits: one that
indicates whether a user can write to it and one that indicate
whether a user can read it. This idea seemed to me directly
applicable to C++, and I considered allowing every type to be
specified readonly or writeonly. An internal memo dated January
1981 [Stroustrup, 1981b] describes the idea:

"Until now it has not been possible in C to specify that a data
item should be /read only/, that is, that its value must remain
unchanged. Neither has there been any way of restricting the use
of the arguments passed to a function. Dennis Ritchie pointed
out that if readonly was a type operator, both facilities couold
be obtained easily, for example:

readonly char table[1024]; /* the chars in "table"
cannot be updated */
int f(readonly int * p)
{
/* "f" cannot update the date denoted by "p" */
/* ... */
}

The readonly operator is used to prevent update of some
location. It specifies that out of the usually legal ways of
accessing the location, only the ones that do not change the
value stored there are legal."

The memo goes on to point out that

"The readonly operator can be used on pointers, too. *readonly
is interpreted as "readonly pointer to," for example:

readonly int * p; /* pointer to read only int */
int* readonly pp; /* read only pointer to int */
readonly int * readonly ppp; /* read only pointer
to read only int */

Here it is legal to assign a new value to p, but not to *p. It
is legal to assign to *pp, but not pp, and it is illegal to
assign to ppp, or *ppp."

Finaly, the memo introduces writeonly:

"There is a type operator writeonly, which is used like
readonly, but prevents reading rather than writing. [...]

The proposal focued on specifying interfaces rather than providing
symbolic constants for C. Clearly, a readonly value is symbolic
constant, but the scope of the proposal is far greater. Initially,
I proposed pointers to readonly but not readonly pointers. A brief
discussion with Dennis Ritchie evolved the idea into the
readonly/writeonly mechanism that I implemented and proposed to an
internal Bell Labs C standards group cgaired by Larry Rosler.
There, I had my first experience with standards work. I came away
from a metting with an agreement (that is, a vote) that readonly
would be introduced into C -- yes C, not C with Classes or C++ --
provided it was renamed const. Unfortunately, a vote isn't
executable, so nothing happened to our C compilers. Latter, the
ANSI C committee (X3J11) was formed and the const proposal
resurfaced and become part of ANSI/ISO C.

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. Knowing that
allows us to use simple consts in constant expression and to avoid
allocating space for such constants. C did not adopt this rule.
[...] This makes consts far less useful in C than in C++ and leaves
C dependent on the preprocessor while C++ programmers can use
properly typed and scoped consts.

Pour la version integrale, voir le bouquin.

-- Gaby

Gabriel Dos Reis

13/08/2004 à 17:28

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 ?

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

-- Gaby

Gabriel Dos Reis

13/08/2004 à 17:29

Laurent Deniau writes:

[...]

| Je n'ai pas encore repondu a James parce que son post est long et que
| je n'ai pas le temps maintenant...

Ah, là James t'usera à la longueur... de ses messages ;-)

-- Gaby

Gabriel Dos Reis

13/08/2004 à 17:32

Gabriel Dos Reis

13/08/2004 à 17:35

"Arnaud Debaene" writes:

[...]

| Quand à je ne sais plus qui (pas toi il me semble) qui a parlé de brûler
| toutes ces "merdes", je rappellerais que d'habitude, ce sont les nazis ou
| les hayatollas qui organisent des autodaffés.

Si je me trompe, l'incinération est pratique courante aussi en France.
Et ce n'est pas spécialement un pays de nazis ou d'ayatollas.

-- Gaby

Gabriel Dos Reis

13/08/2004 à 17:37

"Arnaud Debaene" writes:

[...]

| <snip>
| >> Quand à je ne sais plus qui (pas toi il me semble) qui a parlé de
| >> brûler toutes ces "merdes",
| >
| > Sans doute parles-tu de :
| <snip>
| Je ne parlais pas d'*un* message, il y en a eu plusieurs sur le même thème
| (j'ai la flemme de chercher dans les archives,

Bah, c'est dommage parce que je n'ai pas trouvé ces messages et
j'espérais bien que tu allais appuyer ta remarque sur des faits..

-- Gaby

Gabriel Dos Reis

13/08/2004 à 17:45

"Alain Naigeon" writes:

| "Fabien LE LEZ" a écrit dans le message news:
|
| > On Tue, 10 Aug 2004 22:01:48 +0200, "Alain Naigeon"
| > :
| >
| > >C'est là où, sans intention méchante, je dis que le but de
| > > l'enseignement n'est pas forcément la production immédiate.
| >
| > Arrête-moi si je me trompe, mais j'ai l'impression que tu considères
| > que la base du C++, l'information fondatrice en quelque sorte, c'est
| > l'agencement de la mémoire -- le fait qu'une chaîne de caractères
| > puisse être constituée d'octets contigus.
| >
| > Quant à moi, je pense que l'information fondatrice du C++, c'est qu'un
| > objet ayant une sémantique de valeur fonctionne comme int.
| > Une fois cette "simple" phrase bien comprise, l'élève n'est plus
| > débutant, et il peut aller de l'avant.
|
| Je crois que cette histoire de C++ ressemble à celle de Faust.
| Est-ce moi qui ai parlé de "meilleur C" ? Est-ce moi qui ai décidé
| que C++ devait, autant que possible, rester compatible avec
| C pour les tournures existantes, et en adoptait la syntaxe pour
| celles-ci - ou du moins continuait de l'accepter ? Est-ce moi

Ou veux-tu en venir exactement, je veux dire eb relation avec
l'esneignement de C++ à un débutant ?

-- Gaby

Gabriel Dos Reis

13/08/2004 à 17:47

Jean-Marc Bourguet writes:

| "Alain Naigeon" writes:
|
| > "Jean-Marc Bourguet" a écrit dans le message news:
| >
| >
| > > J'ai pas commencé les maths par Bourbaki non plus. J'ai
| > > jamais lu Bourbaki ni même eu un cours à ce niveau de
| > > construction à partir des bases.
| >
| > Oui mais les tableaux de char ne sont pas implémentés
| > avec std:string, il me semble bien que c'est juste l'inverse ;-)
|
| C'est bien ce que j'ai ecrit: je me suis servi des reels avant de
| savoir comment Bourbaki les definissait (en fait je n'en ai qu'une
| vague idee). De meme je prefererais enseigner d'abord les std::string
| et les std::vector avant les tableaux.
|
|
| Si ta seule raison de commencer par les tableaux, c'est que c'est la
| base de l'implementation, pourquoi ne pas commencer encore plus bas,
| avec l'assembleur?

Tu voulais dire le binaire, je suppose :-)

-- Gaby

Newbies en C++ !

10 réponses

Veuillez sélectionner un problème