Newbies en C++ !

Jean-Marc Bourguet

13/08/2004 à 08:59

"PRORIOL Fabien" writes:

La question est : Pour apprendre quelque chose, vaut-il mieu un prof
caller qui ne sait pas expliquer, ou un prof qui explique tres bien
le peu qu'il connait???

Le probleme avec Oualline, c'est qu'apparemment il ne comprend pas ce
qu'il enseigne. "He reacts to criticism by correcting what he thinks
are the errors but without understanding the issues." Donc la
question est qui fait le plus de degats: un prof calle mauvais
pedagogue ou un exellent pedagogue qui enseigne des erreurs?

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Martinez Jerome

13/08/2004 à 09:43

PRORIOL Fabien wrote:

il n'y a pas de void main() ni meme de printf dans les premiere page;
uniquement des cout cin; des std::string (par contre des tableau mais pas de
vector<> des le debut).

Et il fait comment le lecteur pour mettre en pratique ce qu'il apprend
sur std::cout par exemple?
J'ai du mal a voir comment il peut compiler sans main()... (int main()
d'ailleur non?)

kanze

13/08/2004 à 10:54

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
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).

2. On peut implicitement convertir char** en char const* const* en C++,
non en C.

3. En C++, une variable const de type entier, initialisée par une
expression constante entière, peut servir dans des expressions
constantes entières. Non en C.

Mais l'essentiel de const, c'est qu'il fait partie du typage. Je ne peux
pas, donc, passer un char const* à une fonction qui prend un char*.
Quand j'écris :

void f( int const* p ) ;

je promets de ne pas modifier l'int à travers *p dans la fonction. Et si
j'écris :

void g( int* p ) ;

je ne peux pas lui passer un int const*, ni l'adresse d'un int déclaré
const.

[...]

Et qu'est-ce que le const sur une référence fait en C ? C'est clair
que quand on applique const sur des choses qui n'existent pas en C,
le C++ est libre, sans soulever des problèmes de compatibilité.

- const sur une reference temporaire modifie sa duree de vie.

Voir ci-dessus.

Exact. Mais la duree de vie est differente avec et sans const, le tout
en C++. cf ma premiere remarque en debut de post.

D'où est-ce que tu as trouvé ça ? Le const n'a aucun effet sur la durée
de vie de quoique ce soit. Jamais.

Initialiser une référence avec un temporaire modifie la durée de vie du
temporaire. En C++, évidemment -- en C, il n'y a pas de références, et
la question ne se pose donc pas.

- const int se comporte comme un enum a l'exterieur d'une classe
(mais pas dedans).

Comment ? Const int ne se comporte jamais comme un enum.

En revanche, c'est vrai qu'un objet déclaré const peut faire partie
d'une expression constante, sous certaines conditions, alors que ce
n'est pas le cas en C.

C'est ce que j'ai dit.

Non, ce n'est pas ce que tu as dis. Un int (const ou non) a un type int,
et un enum a un type enum. En C++, à l'encontre de C, les constantes
d'enum n'ont pas de type int -- là, c'est une différence, mais c'est une
différence qui n'a rien à voir avec const.

Quelles sont les conditions dont tu parles? Il 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.

Je crois que tu confonds. En général (et partout), un type enum
convertit implicitement en type entier -- on peut donc utiliser un enum
comme un int. L'inverse n'est pas vrai, au moins en C++, et quelque
chose comme :
enum E e = 5 ;
est illégal en C++ (main non en C, si mes souvenirs sont bon). Mais là
aussi, je ne vois aucun rapport avec const.

Ce qu'on a en C++, mais non en C, c'est qu'une variable const de type
entier peut faire partie d'une expression entière constante. Sous
certaines conditions -- il faut que sa définition, avec
l'initialisation, soit visible, et que l'initialisation elle-même soit
une expression entière constante.

La reciproque n'est biensur pas vraie.

- const est ignore par l'overloading pour les arguments autres que
this s'il est au niveau le plus externe de la specification du type
mais il l'est pour les autres niveaux.

Et comment fonctionne la résolution de surcharge avec const en C.

Comme le const avec les références, la différence, ce n'est pas le
const. La différence, c'est que ce auquel on l'applique n'existe
carrément pas en C.

certe. Encore une fois, je ne compare pas C++ avec C, mais const vs no
const en C++.

Mais ce caractèristique n'est qu'une manifestation de l'aspect de base
de const (dans les deux langages) -- le const fait partie du système de
typage. Si j'écris en C :

void f( int * ) ;

je ne peux pas appeler la fonction avec un const int*. Ni en C++ ni en
C. Et des fonctions :
void f1( int* ) ;
void f2( const int* ) ;
ont des signatures différentes dans les deux langages.

En C, si ces deux fonctions avaient le même nom, ça serait une erreur.
En C++, c'est permis, et on dit qu'elles sont surchargées. À partir du
moment qu'on permet le surcharge des fonctions, il faut bien définir
comment le compilateur choisit laquelle à appeler. Le surcharge joue sur
le type des paramètres. Const fait partie du type, et à partir de ce
moment, il serait une anomalie s'il ne jouait pas dans la résolution du
surcharge.

Le C aussi a ses problemes (cf l'interminable post recent sur c.s.c a
propos de void** et ses variantes const, le titre du post etait une
question du style "broken type system?" ou qque chose comme ca).

J'y jetterai un coup d'oeil si je trouve le temps.

- j'en oublie surement...

J'ai oublie notament les static const int initialisable dans la classe
(seul cas particulier de ce type avec les enum). BS dit aussi que
c'est un "misfeature".

Si BS le dit...

En effet, c'est une incohérence. C'est aussi bien pratique, parfois. Je
ne sais pas si c'est un « misfeature », mais c'est certainement un hack.

Ce qu'il nous faut, en fait, c'est la possibilité de définir une
constante entière qui n'est pas un objet. Actuellement, la seule
possibilité (en C++), c'est avec #define. Souvent, dans la passée, on
trichait, et on se servait d'un enum, mais le type n'est pas correct, au
moins en C++. Ce qui a un effet notoire dans la résolution du surcharge
et surtout (parce que la probabilité qu'on ait une fonction surchargée
pour cet enum qui n'en est pas un, logiquement, est assez faible) dans
le cas des templates -- si j'écris « f( someEnum ) » et f est une
fonction templatée, c'est un autre f que si j'écris « f( 1 ) ».

et tout ca en plus de la semantique du C ou const signifie
simplement read-only et c'est tout.

Et dans C et dans C++, le const fait partie du système de typage. Tu
ne peux pas passer un char const* à un char*. C'est l'essentiel.
Pour la reste, on tombe dans des détails sécondaires, ou des choses
qui n'existent qu'en C++.

L'abondance de details peut nuire a l'apprentissage d'un language qui
necessitera des developpeurs plus chevronnes/attentifs pour ecrire du
code correct.

Certes. Mais c'est une caractèristique de C++, qui n'a rien à faire avec
const:-).

Je ne sais pas si un developpeur C++ gagne plus qu'un developpeur C ou
Java ;-)

Ça dépend. Actuellement, je ne crois pas que les développeurs Java
gagnent autant que ça. Et les développeurs C peut-être encore moins.
Mais ce n'est pas que la plupart des développeurs C++ soient surpayés
non plus. En fait, à quelques rares exceptions (dont je fais partie), ce
qu'on gagne dépend plus des connaissances du domaine d'application --
ceux qui écrivent des programmes de marché gagnent beaucoup plus que
ceux qui écrivent des programmes numériques de récherche:-).

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

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
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).

2. On peut implicitement convertir char** en char const* const* en C++,
non en C.

3. En C++, une variable const de type entier, initialisée par une
expression constante entière, peut servir dans des expressions
constantes entières. Non en C.

Mais l'essentiel de const, c'est qu'il fait partie du typage. Je ne peux
pas, donc, passer un char const* à une fonction qui prend un char*.
Quand j'écris :

void f( int const* p ) ;

je promets de ne pas modifier l'int à travers *p dans la fonction. Et si
j'écris :

void g( int* p ) ;

je ne peux pas lui passer un int const*, ni l'adresse d'un int déclaré
const.

[...]

Et qu'est-ce que le const sur une référence fait en C ? C'est clair
que quand on applique const sur des choses qui n'existent pas en C,
le C++ est libre, sans soulever des problèmes de compatibilité.

- const sur une reference temporaire modifie sa duree de vie.

Voir ci-dessus.

Exact. Mais la duree de vie est differente avec et sans const, le tout
en C++. cf ma premiere remarque en debut de post.

D'où est-ce que tu as trouvé ça ? Le const n'a aucun effet sur la durée
de vie de quoique ce soit. Jamais.

Initialiser une référence avec un temporaire modifie la durée de vie du
temporaire. En C++, évidemment -- en C, il n'y a pas de références, et
la question ne se pose donc pas.

- const int se comporte comme un enum a l'exterieur d'une classe
(mais pas dedans).

Comment ? Const int ne se comporte jamais comme un enum.

En revanche, c'est vrai qu'un objet déclaré const peut faire partie
d'une expression constante, sous certaines conditions, alors que ce
n'est pas le cas en C.

C'est ce que j'ai dit.

Non, ce n'est pas ce que tu as dis. Un int (const ou non) a un type int,
et un enum a un type enum. En C++, à l'encontre de C, les constantes
d'enum n'ont pas de type int -- là, c'est une différence, mais c'est une
différence qui n'a rien à voir avec const.

Quelles sont les conditions dont tu parles? Il 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.

Je crois que tu confonds. En général (et partout), un type enum
convertit implicitement en type entier -- on peut donc utiliser un enum
comme un int. L'inverse n'est pas vrai, au moins en C++, et quelque
chose comme :
enum E e = 5 ;
est illégal en C++ (main non en C, si mes souvenirs sont bon). Mais là
aussi, je ne vois aucun rapport avec const.

Ce qu'on a en C++, mais non en C, c'est qu'une variable const de type
entier peut faire partie d'une expression entière constante. Sous
certaines conditions -- il faut que sa définition, avec
l'initialisation, soit visible, et que l'initialisation elle-même soit
une expression entière constante.

La reciproque n'est biensur pas vraie.

- const est ignore par l'overloading pour les arguments autres que
this s'il est au niveau le plus externe de la specification du type
mais il l'est pour les autres niveaux.

Et comment fonctionne la résolution de surcharge avec const en C.

Comme le const avec les références, la différence, ce n'est pas le
const. La différence, c'est que ce auquel on l'applique n'existe
carrément pas en C.

certe. Encore une fois, je ne compare pas C++ avec C, mais const vs no
const en C++.

Mais ce caractèristique n'est qu'une manifestation de l'aspect de base
de const (dans les deux langages) -- le const fait partie du système de
typage. Si j'écris en C :

void f( int * ) ;

je ne peux pas appeler la fonction avec un const int*. Ni en C++ ni en
C. Et des fonctions :
void f1( int* ) ;
void f2( const int* ) ;
ont des signatures différentes dans les deux langages.

En C, si ces deux fonctions avaient le même nom, ça serait une erreur.
En C++, c'est permis, et on dit qu'elles sont surchargées. À partir du
moment qu'on permet le surcharge des fonctions, il faut bien définir
comment le compilateur choisit laquelle à appeler. Le surcharge joue sur
le type des paramètres. Const fait partie du type, et à partir de ce
moment, il serait une anomalie s'il ne jouait pas dans la résolution du
surcharge.

Le C aussi a ses problemes (cf l'interminable post recent sur c.s.c a
propos de void** et ses variantes const, le titre du post etait une
question du style "broken type system?" ou qque chose comme ca).

J'y jetterai un coup d'oeil si je trouve le temps.

- j'en oublie surement...

J'ai oublie notament les static const int initialisable dans la classe
(seul cas particulier de ce type avec les enum). BS dit aussi que
c'est un "misfeature".

Si BS le dit...

En effet, c'est une incohérence. C'est aussi bien pratique, parfois. Je
ne sais pas si c'est un « misfeature », mais c'est certainement un hack.

Ce qu'il nous faut, en fait, c'est la possibilité de définir une
constante entière qui n'est pas un objet. Actuellement, la seule
possibilité (en C++), c'est avec #define. Souvent, dans la passée, on
trichait, et on se servait d'un enum, mais le type n'est pas correct, au
moins en C++. Ce qui a un effet notoire dans la résolution du surcharge
et surtout (parce que la probabilité qu'on ait une fonction surchargée
pour cet enum qui n'en est pas un, logiquement, est assez faible) dans
le cas des templates -- si j'écris « f( someEnum ) » et f est une
fonction templatée, c'est un autre f que si j'écris « f( 1 ) ».

et tout ca en plus de la semantique du C ou const signifie
simplement read-only et c'est tout.

Et dans C et dans C++, le const fait partie du système de typage. Tu
ne peux pas passer un char const* à un char*. C'est l'essentiel.
Pour la reste, on tombe dans des détails sécondaires, ou des choses
qui n'existent qu'en C++.

L'abondance de details peut nuire a l'apprentissage d'un language qui
necessitera des developpeurs plus chevronnes/attentifs pour ecrire du
code correct.

Certes. Mais c'est une caractèristique de C++, qui n'a rien à faire avec
const:-).

Je ne sais pas si un developpeur C++ gagne plus qu'un developpeur C ou
Java ;-)

Ça dépend. Actuellement, je ne crois pas que les développeurs Java
gagnent autant que ça. Et les développeurs C peut-être encore moins.
Mais ce n'est pas que la plupart des développeurs C++ soient surpayés
non plus. En fait, à quelques rares exceptions (dont je fais partie), ce
qu'on gagne dépend plus des connaissances du domaine d'application --
ceux qui écrivent des programmes de marché gagnent beaucoup plus que
ceux qui écrivent des programmes numériques de récherche:-).

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

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
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).

2. On peut implicitement convertir char** en char const* const* en C++,
non en C.

3. En C++, une variable const de type entier, initialisée par une
expression constante entière, peut servir dans des expressions
constantes entières. Non en C.

Mais l'essentiel de const, c'est qu'il fait partie du typage. Je ne peux
pas, donc, passer un char const* à une fonction qui prend un char*.
Quand j'écris :

void f( int const* p ) ;

je promets de ne pas modifier l'int à travers *p dans la fonction. Et si
j'écris :

void g( int* p ) ;

je ne peux pas lui passer un int const*, ni l'adresse d'un int déclaré
const.

[...]

Et qu'est-ce que le const sur une référence fait en C ? C'est clair
que quand on applique const sur des choses qui n'existent pas en C,
le C++ est libre, sans soulever des problèmes de compatibilité.

- const sur une reference temporaire modifie sa duree de vie.

Voir ci-dessus.

Exact. Mais la duree de vie est differente avec et sans const, le tout
en C++. cf ma premiere remarque en debut de post.

D'où est-ce que tu as trouvé ça ? Le const n'a aucun effet sur la durée
de vie de quoique ce soit. Jamais.

Initialiser une référence avec un temporaire modifie la durée de vie du
temporaire. En C++, évidemment -- en C, il n'y a pas de références, et
la question ne se pose donc pas.

- const int se comporte comme un enum a l'exterieur d'une classe
(mais pas dedans).

Comment ? Const int ne se comporte jamais comme un enum.

En revanche, c'est vrai qu'un objet déclaré const peut faire partie
d'une expression constante, sous certaines conditions, alors que ce
n'est pas le cas en C.

C'est ce que j'ai dit.

Non, ce n'est pas ce que tu as dis. Un int (const ou non) a un type int,
et un enum a un type enum. En C++, à l'encontre de C, les constantes
d'enum n'ont pas de type int -- là, c'est une différence, mais c'est une
différence qui n'a rien à voir avec const.

Quelles sont les conditions dont tu parles? Il 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.

Je crois que tu confonds. En général (et partout), un type enum
convertit implicitement en type entier -- on peut donc utiliser un enum
comme un int. L'inverse n'est pas vrai, au moins en C++, et quelque
chose comme :
enum E e = 5 ;
est illégal en C++ (main non en C, si mes souvenirs sont bon). Mais là
aussi, je ne vois aucun rapport avec const.

Ce qu'on a en C++, mais non en C, c'est qu'une variable const de type
entier peut faire partie d'une expression entière constante. Sous
certaines conditions -- il faut que sa définition, avec
l'initialisation, soit visible, et que l'initialisation elle-même soit
une expression entière constante.

La reciproque n'est biensur pas vraie.

- const est ignore par l'overloading pour les arguments autres que
this s'il est au niveau le plus externe de la specification du type
mais il l'est pour les autres niveaux.

Et comment fonctionne la résolution de surcharge avec const en C.

Comme le const avec les références, la différence, ce n'est pas le
const. La différence, c'est que ce auquel on l'applique n'existe
carrément pas en C.

certe. Encore une fois, je ne compare pas C++ avec C, mais const vs no
const en C++.

Mais ce caractèristique n'est qu'une manifestation de l'aspect de base
de const (dans les deux langages) -- le const fait partie du système de
typage. Si j'écris en C :

void f( int * ) ;

je ne peux pas appeler la fonction avec un const int*. Ni en C++ ni en
C. Et des fonctions :
void f1( int* ) ;
void f2( const int* ) ;
ont des signatures différentes dans les deux langages.

En C, si ces deux fonctions avaient le même nom, ça serait une erreur.
En C++, c'est permis, et on dit qu'elles sont surchargées. À partir du
moment qu'on permet le surcharge des fonctions, il faut bien définir
comment le compilateur choisit laquelle à appeler. Le surcharge joue sur
le type des paramètres. Const fait partie du type, et à partir de ce
moment, il serait une anomalie s'il ne jouait pas dans la résolution du
surcharge.

Le C aussi a ses problemes (cf l'interminable post recent sur c.s.c a
propos de void** et ses variantes const, le titre du post etait une
question du style "broken type system?" ou qque chose comme ca).

J'y jetterai un coup d'oeil si je trouve le temps.

- j'en oublie surement...

J'ai oublie notament les static const int initialisable dans la classe
(seul cas particulier de ce type avec les enum). BS dit aussi que
c'est un "misfeature".

Si BS le dit...

En effet, c'est une incohérence. C'est aussi bien pratique, parfois. Je
ne sais pas si c'est un « misfeature », mais c'est certainement un hack.

Ce qu'il nous faut, en fait, c'est la possibilité de définir une
constante entière qui n'est pas un objet. Actuellement, la seule
possibilité (en C++), c'est avec #define. Souvent, dans la passée, on
trichait, et on se servait d'un enum, mais le type n'est pas correct, au
moins en C++. Ce qui a un effet notoire dans la résolution du surcharge
et surtout (parce que la probabilité qu'on ait une fonction surchargée
pour cet enum qui n'en est pas un, logiquement, est assez faible) dans
le cas des templates -- si j'écris « f( someEnum ) » et f est une
fonction templatée, c'est un autre f que si j'écris « f( 1 ) ».

et tout ca en plus de la semantique du C ou const signifie
simplement read-only et c'est tout.

Et dans C et dans C++, le const fait partie du système de typage. Tu
ne peux pas passer un char const* à un char*. C'est l'essentiel.
Pour la reste, on tombe dans des détails sécondaires, ou des choses
qui n'existent qu'en C++.

L'abondance de details peut nuire a l'apprentissage d'un language qui
necessitera des developpeurs plus chevronnes/attentifs pour ecrire du
code correct.

Certes. Mais c'est une caractèristique de C++, qui n'a rien à faire avec
const:-).

Je ne sais pas si un developpeur C++ gagne plus qu'un developpeur C ou
Java ;-)

Ça dépend. Actuellement, je ne crois pas que les développeurs Java
gagnent autant que ça. Et les développeurs C peut-être encore moins.
Mais ce n'est pas que la plupart des développeurs C++ soient surpayés
non plus. En fait, à quelques rares exceptions (dont je fais partie), ce
qu'on gagne dépend plus des connaissances du domaine d'application --
ceux qui écrivent des programmes de marché gagnent beaucoup plus que
ceux qui écrivent des programmes numériques de récherche:-).

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

13/08/2004 à 11:00

"PRORIOL Fabien" wrote in message
news:<411b84e1$0$29670$...

Desolé, je donnait juste un avis personnel; En effet peut etre que
pour un PRO il y a des truc pas top; Mais pour apprendre je le trouve
bien;

Je l'est conseiller a 2 3 de mes collegues qui l'ont aussi acheté, et
il ne m'ent on pas dit du mal.

Il a surtout l'avantage de ne pas NOYER le lecteur newbee sous plein
de truc incomprehensible, et d'expliquer assez simplement.

Est-ce que tu as lu ce que Jean-Marc a cité ? On n'a pas dit que ce qui
était expliqué était mal expliqué. On a dit qu'il était erroné. Tu as
donc peut-être bien appris, et tu as donc l'impression d'avoir compris,
mais ce que tu as lu et que tu as appris est faux.

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

user

13/08/2004 à 11:44

Bonjour,

Pour le bidouillage, personellement, j'utilise le shell de Unix, avec
les outils classiques Unix -- y compris sous Windows, grace à CygWin.
Mais ce choix est beaucoup lié à mon histoire personnelle, et le type de
choses que je bidouille (rien avec GNU, par exemple) ; je ne crois pas
que ce soit la bonne solution pour tout le monde.

Formidables bash, awk, gnuplot, ...

J'ai entendu parler de deux possibilités portables : Python et TCL/TK.
Je ne les connais ni l'un ni l'autre, mais j'en ai entendu du bien,
surtout de Python. Alors, ce sont éventuellement des possibilités.

Je m'étais penché un moment sur Python. J'avais trouvé sur le net un
cours de programmation (une centaine de pages) basé sur ce langage, qui
abordait même l'écriture d'interfaces graphiques ! ça m'avait paru un
bon duo pour un débutant.
Il est paru il y a quelques mois un HS sur Perl qui à l'air très bien
aussi, peut-être plus proche de C/C++ dans la synthaxe.
Python a une particularité : il OBLIGE à indenter le code proprement
(bonne habitude à prendre). C'est comme ça qu'il définit les blocs
d'instruction.
De ruby, je sais seulement qu'il est similaire aux 2 précédents : python
et Perl.
TCL parait assez proche dans la forme du bash (pourles appels de
fonction). Perl, Python sont eux plus proches d'un langage de
programmation comme C/C++ Parcal ou Fortran. Ils sont tous "orientés
objets", ont une gestion d'exceptions : c'est du sérieux.
Ce sont des langages de haut niveaux, càd ayant des modules mermettant
de faire facilement des opérations qui seraient difficile en C++ : la
manipulations des expressions régulières par exemple.
Ce sont des langages interprétés ce qui impose que l'interpréteur et ses
librairies soient installées (pas standard sous windows) : ça entrave la
diffusion :-(
Il ne leur manque qu'un compilateur !

Aussi d'après ce que j'ai entendu dire, les langages de script d'Excel
ou de Word sont en fait du VB. Si on veut interagir avec ce genre de
programme, c'est probable que VB soit le meilleur choix.

à ce propos, j'ai découvert cette année AutoIt3 qui permet d'interagir
avec n'importe quelle application Windows, d'envoyer des messages à des
fenêtres ouvertes (tout ce que l'on taperait au claviers : les
raccourcis-clavier en particulier). C'est un langage "Basic-like" mais
qui peut être compilé !! Ce n'est pas portable à d'autres plateforme que
windows mais la compilation permet de diffuser un script sans obliger à
installer l'interpréteur.
Pour de la bidouille, c'est très utile ! Utilisable même avec des applis
qui ne propose pas VBA.
Ca ne remplace pas, bien sûr, un "vrai" langage de programmation mais ça
peut être utile.

cordialement,
MG

PS : précision, je ne connais pas les BASIC.

Bonjour,

Pour le bidouillage, personellement, j'utilise le shell de Unix, avec
les outils classiques Unix -- y compris sous Windows, grace à CygWin.
Mais ce choix est beaucoup lié à mon histoire personnelle, et le type de
choses que je bidouille (rien avec GNU, par exemple) ; je ne crois pas
que ce soit la bonne solution pour tout le monde.

Formidables bash, awk, gnuplot, ...

J'ai entendu parler de deux possibilités portables : Python et TCL/TK.
Je ne les connais ni l'un ni l'autre, mais j'en ai entendu du bien,
surtout de Python. Alors, ce sont éventuellement des possibilités.

Je m'étais penché un moment sur Python. J'avais trouvé sur le net un
cours de programmation (une centaine de pages) basé sur ce langage, qui
abordait même l'écriture d'interfaces graphiques ! ça m'avait paru un
bon duo pour un débutant.
Il est paru il y a quelques mois un HS sur Perl qui à l'air très bien
aussi, peut-être plus proche de C/C++ dans la synthaxe.
Python a une particularité : il OBLIGE à indenter le code proprement
(bonne habitude à prendre). C'est comme ça qu'il définit les blocs
d'instruction.
De ruby, je sais seulement qu'il est similaire aux 2 précédents : python
et Perl.
TCL parait assez proche dans la forme du bash (pourles appels de
fonction). Perl, Python sont eux plus proches d'un langage de
programmation comme C/C++ Parcal ou Fortran. Ils sont tous "orientés
objets", ont une gestion d'exceptions : c'est du sérieux.
Ce sont des langages de haut niveaux, càd ayant des modules mermettant
de faire facilement des opérations qui seraient difficile en C++ : la
manipulations des expressions régulières par exemple.
Ce sont des langages interprétés ce qui impose que l'interpréteur et ses
librairies soient installées (pas standard sous windows) : ça entrave la
diffusion :-(
Il ne leur manque qu'un compilateur !

Aussi d'après ce que j'ai entendu dire, les langages de script d'Excel
ou de Word sont en fait du VB. Si on veut interagir avec ce genre de
programme, c'est probable que VB soit le meilleur choix.

à ce propos, j'ai découvert cette année AutoIt3 qui permet d'interagir
avec n'importe quelle application Windows, d'envoyer des messages à des
fenêtres ouvertes (tout ce que l'on taperait au claviers : les
raccourcis-clavier en particulier). C'est un langage "Basic-like" mais
qui peut être compilé !! Ce n'est pas portable à d'autres plateforme que
windows mais la compilation permet de diffuser un script sans obliger à
installer l'interpréteur.
Pour de la bidouille, c'est très utile ! Utilisable même avec des applis
qui ne propose pas VBA.
Ca ne remplace pas, bien sûr, un "vrai" langage de programmation mais ça
peut être utile.

cordialement,
MG

PS : précision, je ne connais pas les BASIC.

Vous avez filtré cet utilisateur ! Consultez son message

Bonjour,

Pour le bidouillage, personellement, j'utilise le shell de Unix, avec
les outils classiques Unix -- y compris sous Windows, grace à CygWin.
Mais ce choix est beaucoup lié à mon histoire personnelle, et le type de
choses que je bidouille (rien avec GNU, par exemple) ; je ne crois pas
que ce soit la bonne solution pour tout le monde.

Formidables bash, awk, gnuplot, ...

J'ai entendu parler de deux possibilités portables : Python et TCL/TK.
Je ne les connais ni l'un ni l'autre, mais j'en ai entendu du bien,
surtout de Python. Alors, ce sont éventuellement des possibilités.

Je m'étais penché un moment sur Python. J'avais trouvé sur le net un
cours de programmation (une centaine de pages) basé sur ce langage, qui
abordait même l'écriture d'interfaces graphiques ! ça m'avait paru un
bon duo pour un débutant.
Il est paru il y a quelques mois un HS sur Perl qui à l'air très bien
aussi, peut-être plus proche de C/C++ dans la synthaxe.
Python a une particularité : il OBLIGE à indenter le code proprement
(bonne habitude à prendre). C'est comme ça qu'il définit les blocs
d'instruction.
De ruby, je sais seulement qu'il est similaire aux 2 précédents : python
et Perl.
TCL parait assez proche dans la forme du bash (pourles appels de
fonction). Perl, Python sont eux plus proches d'un langage de
programmation comme C/C++ Parcal ou Fortran. Ils sont tous "orientés
objets", ont une gestion d'exceptions : c'est du sérieux.
Ce sont des langages de haut niveaux, càd ayant des modules mermettant
de faire facilement des opérations qui seraient difficile en C++ : la
manipulations des expressions régulières par exemple.
Ce sont des langages interprétés ce qui impose que l'interpréteur et ses
librairies soient installées (pas standard sous windows) : ça entrave la
diffusion :-(
Il ne leur manque qu'un compilateur !

Aussi d'après ce que j'ai entendu dire, les langages de script d'Excel
ou de Word sont en fait du VB. Si on veut interagir avec ce genre de
programme, c'est probable que VB soit le meilleur choix.

à ce propos, j'ai découvert cette année AutoIt3 qui permet d'interagir
avec n'importe quelle application Windows, d'envoyer des messages à des
fenêtres ouvertes (tout ce que l'on taperait au claviers : les
raccourcis-clavier en particulier). C'est un langage "Basic-like" mais
qui peut être compilé !! Ce n'est pas portable à d'autres plateforme que
windows mais la compilation permet de diffuser un script sans obliger à
installer l'interpréteur.
Pour de la bidouille, c'est très utile ! Utilisable même avec des applis
qui ne propose pas VBA.
Ca ne remplace pas, bien sûr, un "vrai" langage de programmation mais ça
peut être utile.

cordialement,
MG

PS : précision, je ne connais pas les BASIC.

Martinez Jerome

13/08/2004 à 11:57

Fabien LE LEZ wrote:

(sockets, serialisation, graphique par exemple)

Sauf que ces trois-là n'auraient rien à faire dans une STL. Et qu'il y
a assez de bibliothèques disponibles (en C, au pire).

C'est pourtant un très gros reproche fait au C++ : sa SL, très très
limitée par rapport aux besoins d'aujourd'hui.
VB, Delphi, C#, Java pour ne prendre que quelques exemples que je
connais (très peu quand meme, je prefere C++ + WxWidgets ou la VCL pour
le moment), ont un bibliotheque standart qui inclu ce genre de choses,
le programmeur qui découvre un language n'a pas a se poser la question
de tester toutes les bibliothques tierces qui existent pour savoir celle
qui correspond a son besoin : tout est la, livré, packagé, et c'est ce
que le programmeur demande a la base. D'ou un grand succès en ce moment.

Il n'y a qu'a regarder les questions HS du newsgroup : sockets et
graphique dans 90% des cas. Les gens, en général, n'imagine meme pas
qu'un language ai pu laisser ca de coté...

Maintenant, entre la demande du programmeur lambda et ce qui doit
vraiment etre dans la SL, c'est un débat... Mais deja que le fil est long :)

Sayajin

13/08/2004 à 13:07

"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.

Je suis désolé pour toi. Je viens tout juste (il y a exactement
45 minutes) de regarder ce livre, par hasard...

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.

Si tu cherches un meilleur livre, fais en sorte qu'il parle
de std::, de std::string, de std::vector. Si le premier
exemple que tu vois fais un #include <iostream.h>, laisse-le
tomber. Tu veux voir <iostream> pas de .h.

Ton livre ne répond à aucun de ces critères.

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

Sayajin

13/08/2004 à 13:33

"Sayajin" a écrit dans le message de
news:cfi7cq$qqj$

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 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écidemment regardez ce commentaire sur Claude Delannoy pourtant que j'ai vu
recommandé maintes et maintes fois :

"J'aurais plutôt tendance à déconseiller le bouquin de Delannoy : il utilise
beaucoup de choses qui ne sont pas standard et certains chapitres sont très
flous.

En bouquins français, je conseillerais "Programmation C++ par la pratique"
(deuxième édition), de Oualline chez O'Reilly, et "L'essentiel du C++" de
Lippman et Lajoie chez Vuibert. Le deuxième est vraiment très bien, mais
coute vraiment très cher.

La FAQ Lite est très bien faite, voir
http://www.parashift.com/c++-faq-lite/(...) pour la version anglaise et
http://www.ensta.fr/~diam/c++/online/c++-faq-lite/(...) pour la VF (n'a pas
l'air de répondre en ce moment). "

source : http://linuxfr.org/forums/20/2897.html

Sayajin

13/08/2004 à 13:39

"Sayajin" a écrit dans le message de
news:cfi8u6$h2j$

Décidemment regardez ce commentaire sur Claude Delannoy pourtant que j'ai
vu

recommandé maintes et maintes fois :

"J'aurais plutôt tendance à déconseiller le bouquin de Delannoy : il
utilise

beaucoup de choses qui ne sont pas standard et certains chapitres sont
très

flous.

En bouquins français, je conseillerais "Programmation C++ par la pratique"
(deuxième édition), de Oualline chez O'Reilly, et "L'essentiel du C++" de
Lippman et Lajoie chez Vuibert. Le deuxième est vraiment très bien, mais
coute vraiment très cher.

Encore moi sinon vous connaissez ce bouquin : "Comment programmer en c++" de
Deitel et Deitel

http://www.amazon.fr/exec/obidos/ASIN/2893772900/qid92396975/sr=2-1/ref=sr_2_25_1/171-7895405-0660237

Jean-Marc Bourguet

13/08/2004 à 13:43

"Sayajin" writes:

Encore moi sinon vous connaissez ce bouquin : "Comment programmer en c++" de
Deitel et Deitel

http://www.amazon.fr/exec/obidos/ASIN/2893772900/qid92396975/sr=2-1/ref=sr_2_25_1/171-7895405-0660237

http://www.accu.org/cgi-bin/accu/rvout.cgi?from
u_d&file=cp003204a

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Newbies en C++ !

10 réponses

Veuillez sélectionner un problème