Voilà, il y a encore 1 mois, j'étais sous Windoz XP et je "bidouillais"
en VisualBasic 6.0
Depuis je suis passé sous Linux Suse 9.1 et je souhaiterais continuer à
"bidouiller", je ne cherche pas à développer des applications énormes,
mais juste des petits trucs pour m'amuser.
J'ai vu que sous Linux, le C++ avait l'air très répendu, j'ai donc
installé KDevelop qui permet de programmer en C++.
Et voilà, j'en suis à ce stade, j'ai acheté un bouquin sur le C++, j'en
suis à la page 10 ! et je me dis que ça a l'air un peu compliqué ...
Pouvez vous me conseiller ? est ce que le C++ est un bon choix pour moi
qui n'y connait rien ?
Merci pour votre aide.
A Bientot
--
Mail envoyé depuis Thunderbird
Sous Linux Suse 9.1 Pro
Malheureusement, je dois bien avouer que cela ferait du bien au domaine.
Oui, mais là il y a un problème éthique
Que ce soit clair : lorsque je dis « Malheureusement, je dois bien avouer que ... », il ne s'agit en aucun cas de cautionner une telle pratique
Supposons que toute personne veuillant apprendre le C++ vienne demander conseil sur fclc++. Les "mauvais bouquins" dont on parle ne se vendront plus, et seront mis au pilon. L'autodafé capitaliste au lieu de l'autodafé religieux, en somme.
Le problème éthique dont je parle est assez simple à énoncer : faut-il sacrifier des élèves en les laissant acheter de mauvais bouquins, ou vaut-il mieux sacrifier les mauvais auteurs en dirigeant les élèves vers les bons ?
Je ne parlerais pas alors d'autodaffé. Plutôt de quelque chose comme une sélection à laquelle on peut décider de ne pas adhérer. L'autodaffé empêche quiconque de lire certains livres, puisqu'ils sont physiquement détruits. Critiquer de manière objective (ou non, d'ailleurs) un livre, et le déconseiller, n'est absolument pas la même chose.
Et si l'auteur ne peut en vivre, il lui faudra se recycler. Que sa production soit ou non de qualité, d'ailleurs.
--drkm, en recherche d'un stage : http://www.fgeorges.org/ipl/stage.html
Fabien LE LEZ <gramster@gramster.com> writes:
On Fri, 13 Aug 2004 01:39:38 +0200, drkm <usenet.fclcxx@fgeorges.org>:
Malheureusement, je dois bien avouer que cela ferait du bien au
domaine.
Oui, mais là il y a un problème éthique
Que ce soit clair : lorsque je dis « Malheureusement, je dois bien
avouer que ... », il ne s'agit en aucun cas de cautionner une telle
pratique
Supposons que toute personne veuillant apprendre le C++ vienne
demander conseil sur fclc++. Les "mauvais bouquins" dont on parle ne
se vendront plus, et seront mis au pilon. L'autodafé capitaliste au
lieu de l'autodafé religieux, en somme.
Le problème éthique dont je parle est assez simple à énoncer : faut-il
sacrifier des élèves en les laissant acheter de mauvais bouquins, ou
vaut-il mieux sacrifier les mauvais auteurs en dirigeant les élèves
vers les bons ?
Je ne parlerais pas alors d'autodaffé. Plutôt de quelque chose
comme une sélection à laquelle on peut décider de ne pas adhérer.
L'autodaffé empêche quiconque de lire certains livres, puisqu'ils sont
physiquement détruits. Critiquer de manière objective (ou non,
d'ailleurs) un livre, et le déconseiller, n'est absolument pas la même
chose.
Et si l'auteur ne peut en vivre, il lui faudra se recycler. Que sa
production soit ou non de qualité, d'ailleurs.
--drkm, en recherche d'un stage : http://www.fgeorges.org/ipl/stage.html
Malheureusement, je dois bien avouer que cela ferait du bien au domaine.
Oui, mais là il y a un problème éthique
Que ce soit clair : lorsque je dis « Malheureusement, je dois bien avouer que ... », il ne s'agit en aucun cas de cautionner une telle pratique
Supposons que toute personne veuillant apprendre le C++ vienne demander conseil sur fclc++. Les "mauvais bouquins" dont on parle ne se vendront plus, et seront mis au pilon. L'autodafé capitaliste au lieu de l'autodafé religieux, en somme.
Le problème éthique dont je parle est assez simple à énoncer : faut-il sacrifier des élèves en les laissant acheter de mauvais bouquins, ou vaut-il mieux sacrifier les mauvais auteurs en dirigeant les élèves vers les bons ?
Je ne parlerais pas alors d'autodaffé. Plutôt de quelque chose comme une sélection à laquelle on peut décider de ne pas adhérer. L'autodaffé empêche quiconque de lire certains livres, puisqu'ils sont physiquement détruits. Critiquer de manière objective (ou non, d'ailleurs) un livre, et le déconseiller, n'est absolument pas la même chose.
Et si l'auteur ne peut en vivre, il lui faudra se recycler. Que sa production soit ou non de qualité, d'ailleurs.
--drkm, en recherche d'un stage : http://www.fgeorges.org/ipl/stage.html
Christophe de VIENNE
Fabien LE LEZ wrote:
On Fri, 13 Aug 2004 11:44:14 +0200, :
Python a une particularité : il OBLIGE à indenter le code proprement
Je pense qu'un langage qui impose ses normes d'indentation me gonflerait profondément, mais c'est sans doute un plus pour un débutant...
On s'y fait très vite. Il faut juste s'habituer à utiliser les fonctions d'indentation de blocs entier de ton éditeur parce que sinon dès que tu ajoute un if: c'est l'enfer.
-- Christophe de Vienne
Fabien LE LEZ wrote:
On Fri, 13 Aug 2004 11:44:14 +0200, user@domain.invalid:
Python a une particularité : il OBLIGE à indenter le code proprement
Je pense qu'un langage qui impose ses normes d'indentation me
gonflerait profondément, mais c'est sans doute un plus pour un
débutant...
On s'y fait très vite. Il faut juste s'habituer à utiliser les fonctions
d'indentation de blocs entier de ton éditeur parce que sinon dès que tu
ajoute un if: c'est l'enfer.
Python a une particularité : il OBLIGE à indenter le code proprement
Je pense qu'un langage qui impose ses normes d'indentation me gonflerait profondément, mais c'est sans doute un plus pour un débutant...
On s'y fait très vite. Il faut juste s'habituer à utiliser les fonctions d'indentation de blocs entier de ton éditeur parce que sinon dès que tu ajoute un if: c'est l'enfer.
-- Christophe de Vienne
Laurent Deniau
drkm wrote:
Laurent Deniau writes:
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. 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...
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. En C on a le cas trivial:
{ // Ok C++ pas C const int size = 10; int array[size];
// ... }
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.
Je n'ai pas encore repondu a James parce que son post est long et que je n'ai pas le temps maintenant...
a+, ld.
drkm wrote:
Laurent Deniau <Laurent.Deniau@cern.ch> writes:
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. 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...
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. En C on a le cas trivial:
{ // Ok C++ pas C
const int size = 10;
int array[size];
// ...
}
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.
Je n'ai pas encore repondu a James parce que son post est long et que je
n'ai pas le temps maintenant...
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. 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...
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. En C on a le cas trivial:
{ // Ok C++ pas C const int size = 10; int array[size];
// ... }
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.
Je n'ai pas encore repondu a James parce que son post est long et que je n'ai pas le temps maintenant...
a+, ld.
Gabriel Dos Reis
Alexandre Bacquart writes:
| Fabien LE LEZ wrote: | | > A condition de vouloir rester débutant. J'ai des doutes sur la | > formation qu'apporte l'apprentissage du Basic. | | Il a le mérite d'être facile à apprendre pour les autoditactes. Il | apporte les bases de la programmation,
Les bases de la programmation ? Lesquelles ?
| de la manière la plus simple | possible. Introduction de concepts dont peu de langages peuvent se | passer : les variables, les structures de contrôle, les | fonctions... ^^^^^^^^^
Là tu parles d'un dérivé hydro-carbonique, pas de BASIC.
-- Gaby
Alexandre Bacquart <tek512@hotmail.com> writes:
| Fabien LE LEZ wrote:
|
| > A condition de vouloir rester débutant. J'ai des doutes sur la
| > formation qu'apporte l'apprentissage du Basic.
|
| Il a le mérite d'être facile à apprendre pour les autoditactes. Il
| apporte les bases de la programmation,
Les bases de la programmation ? Lesquelles ?
| de la manière la plus simple
| possible. Introduction de concepts dont peu de langages peuvent se
| passer : les variables, les structures de contrôle, les
| fonctions...
^^^^^^^^^
Là tu parles d'un dérivé hydro-carbonique, pas de BASIC.
| Fabien LE LEZ wrote: | | > A condition de vouloir rester débutant. J'ai des doutes sur la | > formation qu'apporte l'apprentissage du Basic. | | Il a le mérite d'être facile à apprendre pour les autoditactes. Il | apporte les bases de la programmation,
Les bases de la programmation ? Lesquelles ?
| de la manière la plus simple | possible. Introduction de concepts dont peu de langages peuvent se | passer : les variables, les structures de contrôle, les | fonctions... ^^^^^^^^^
Là tu parles d'un dérivé hydro-carbonique, pas de BASIC.
-- Gaby
Gabriel Dos Reis
writes:
[...]
| Dans la pratique, quand un script commence à dépasser plusieurs | milliers de lignes, il est temps de penser à C++.
pour le convertir à des millions de lignes C++ ?
-- Gaby
kanze@gabi-soft.fr writes:
[...]
| Dans la pratique, quand un script commence à dépasser plusieurs
| milliers de lignes, il est temps de penser à C++.
| Dans la pratique, quand un script commence à dépasser plusieurs | milliers de lignes, il est temps de penser à C++.
pour le convertir à des millions de lignes C++ ?
-- Gaby
drkm
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'
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.
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 ?
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 ?
--drkm, en recherche d'un stage : http://www.fgeorges.org/ipl/stage.html
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'
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.
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 ?
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 ?
--drkm, en recherche d'un stage : http://www.fgeorges.org/ipl/stage.html
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'
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.
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 ?
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 ?
--drkm, en recherche d'un stage : http://www.fgeorges.org/ipl/stage.html
Gabriel Dos Reis
"Alain Naigeon" writes:
| "Gabriel Dos Reis" a écrit dans le message | news: | | > (3) Imagine quelqu'un qui veut apprendre le français, mais se refuse | > à toute construction standard et préfère ses onomatopées maison | > au prétexte que l'homme de la pierre taillée faisait de même. | | Tss... là tu déformes ; tu es pour l'usage des expressions standard | sans compréhension de leurs éléments (provisoirement). D'autres | pensent que c'est bien - en tout cas pas nuisible ! - de connaître | les mots avant de les assembler. Ce débat entre lecture globale | ou pas a déjà eu lieu, avec les résultats qu'on connaît.
C'est là que tu déformes : être pour un apprentissage des constructions idiomatiques ne veut pas dire qu'on est pour une lecture globale.
| Tu parles couramment C++, et tu crois, en toute bonne foi, que | pour y arriver il n'y a *que* la méthode globale d'apprentissage, | qui ressemble évidemment à ta pratique actuelle. | Mais : | Comment peux-tu dire que toute autre méthode conduit à ne | pas comprendre le langage et à l'enfermer dans son passé,
J'ai posé deux fois la question : que proposes-tu à la place std::string et std::vector<>. Je n'ai pas eu de réponse. Juste de la rhétorique. Est-ce à dire que l'autre tenant faite juste de la figuration ?
| alors que ceux-là même qui l'ont fait évoluer ont été, évidemment, | formés sans les outils qu'ils ont eux-même inventés par la suite ? | Il y a comme un bug dans ce beau raisonnement
Peut-être qu'il y a un bug, mais c'est sans importance pour le sujet dont il est question ici : que proposes-tu à la place de std::string et std::vector<> ? Note bien que je ne prones pas une « lecture globale » comme tu as tenté de le faire croire.
-- Gaby
"Alain Naigeon" <anaigeon@free.fr> writes:
| "Gabriel Dos Reis" <gdr@integrable-solutions.net> a écrit dans le message
| news: m31xifw804.fsf@uniton.integrable-solutions.net...
|
| > (3) Imagine quelqu'un qui veut apprendre le français, mais se refuse
| > à toute construction standard et préfère ses onomatopées maison
| > au prétexte que l'homme de la pierre taillée faisait de même.
|
| Tss... là tu déformes ; tu es pour l'usage des expressions standard
| sans compréhension de leurs éléments (provisoirement). D'autres
| pensent que c'est bien - en tout cas pas nuisible ! - de connaître
| les mots avant de les assembler. Ce débat entre lecture globale
| ou pas a déjà eu lieu, avec les résultats qu'on connaît.
C'est là que tu déformes : être pour un apprentissage des
constructions idiomatiques ne veut pas dire qu'on est pour une lecture
globale.
| Tu parles couramment C++, et tu crois, en toute bonne foi, que
| pour y arriver il n'y a *que* la méthode globale d'apprentissage,
| qui ressemble évidemment à ta pratique actuelle.
| Mais :
| Comment peux-tu dire que toute autre méthode conduit à ne
| pas comprendre le langage et à l'enfermer dans son passé,
J'ai posé deux fois la question : que proposes-tu à la place
std::string et std::vector<>. Je n'ai pas eu de réponse. Juste de la
rhétorique. Est-ce à dire que l'autre tenant faite juste de la
figuration ?
| alors que ceux-là même qui l'ont fait évoluer ont été, évidemment,
| formés sans les outils qu'ils ont eux-même inventés par la suite ?
| Il y a comme un bug dans ce beau raisonnement
Peut-être qu'il y a un bug, mais c'est sans importance pour le sujet
dont il est question ici : que proposes-tu à la place de std::string
et std::vector<> ? Note bien que je ne prones pas une « lecture
globale » comme tu as tenté de le faire croire.
| "Gabriel Dos Reis" a écrit dans le message | news: | | > (3) Imagine quelqu'un qui veut apprendre le français, mais se refuse | > à toute construction standard et préfère ses onomatopées maison | > au prétexte que l'homme de la pierre taillée faisait de même. | | Tss... là tu déformes ; tu es pour l'usage des expressions standard | sans compréhension de leurs éléments (provisoirement). D'autres | pensent que c'est bien - en tout cas pas nuisible ! - de connaître | les mots avant de les assembler. Ce débat entre lecture globale | ou pas a déjà eu lieu, avec les résultats qu'on connaît.
C'est là que tu déformes : être pour un apprentissage des constructions idiomatiques ne veut pas dire qu'on est pour une lecture globale.
| Tu parles couramment C++, et tu crois, en toute bonne foi, que | pour y arriver il n'y a *que* la méthode globale d'apprentissage, | qui ressemble évidemment à ta pratique actuelle. | Mais : | Comment peux-tu dire que toute autre méthode conduit à ne | pas comprendre le langage et à l'enfermer dans son passé,
J'ai posé deux fois la question : que proposes-tu à la place std::string et std::vector<>. Je n'ai pas eu de réponse. Juste de la rhétorique. Est-ce à dire que l'autre tenant faite juste de la figuration ?
| alors que ceux-là même qui l'ont fait évoluer ont été, évidemment, | formés sans les outils qu'ils ont eux-même inventés par la suite ? | Il y a comme un bug dans ce beau raisonnement
Peut-être qu'il y a un bug, mais c'est sans importance pour le sujet dont il est question ici : que proposes-tu à la place de std::string et std::vector<> ? Note bien que je ne prones pas une « lecture globale » comme tu as tenté de le faire croire.
-- Gaby
Gabriel Dos Reis
"Alain Naigeon" writes:
| "Gabriel Dos Reis" a écrit dans le message | news: | | > Quelles sont tes alternatives à std::vector<> et std::string? | | L'énorme et intéressante quantités de choses qui servent | à les écrire :-o
Mais encore.
| *je* ne suis pas partisan de les ignorer, simplement je trouve | provocant - et en tout cas questionnable - la position consistant | à dire qu'il est démodé d'enseigner comment ça marche !
T'aurais pris un coup de canicule ?
Je ne dis pas qu'il est démodé d'enseigner comment ça marche. Je dis que pour apprendre aux débutants à programmer en C++, ce ne devrait pas être la première chose à faire.
| Oui, je sais... " à un *dé-bu-tant*". Ok, eh bien, Wittgenstein a | dit, avec pertinence: "Le vrai sens d'un théorème, c'est sa preuve".
Même si ce brave monsieur avait raison, cela n'a aucune espèce d'importance ici : nous ne parlons pas de théorème.
| Tu ne sais pas ce qu'est une chose avant de savoir "comment ça | marche".
C'est pour respecter ce principe que tu apprendrais au débutant -- qui veut juste à apprendre à programmer en C++ -- de commencer d'abord en binaire, plus en langage d'assemblage, puis en C en enfin en C++ sans doute ?
| Tu peux aussi enseigner, en conduite accompagnée, en expliquant | à chaque instant vers où, et de combien, il faut tourner le volant.
Quel est le rapport avec la choucroute ?
-- Gaby
"Alain Naigeon" <anaigeon@free.fr> writes:
| "Gabriel Dos Reis" <gdr@integrable-solutions.net> a écrit dans le message
| news: m3oeljwbom.fsf@uniton.integrable-solutions.net...
|
| > Quelles sont tes alternatives à std::vector<> et std::string?
|
| L'énorme et intéressante quantités de choses qui servent
| à les écrire :-o
Mais encore.
| *je* ne suis pas partisan de les ignorer, simplement je trouve
| provocant - et en tout cas questionnable - la position consistant
| à dire qu'il est démodé d'enseigner comment ça marche !
T'aurais pris un coup de canicule ?
Je ne dis pas qu'il est démodé d'enseigner comment ça marche. Je dis
que pour apprendre aux débutants à programmer en C++, ce ne devrait
pas être la première chose à faire.
| Oui, je sais... " à un *dé-bu-tant*". Ok, eh bien, Wittgenstein a
| dit, avec pertinence: "Le vrai sens d'un théorème, c'est sa preuve".
Même si ce brave monsieur avait raison, cela n'a aucune espèce
d'importance ici : nous ne parlons pas de théorème.
| Tu ne sais pas ce qu'est une chose avant de savoir "comment ça
| marche".
C'est pour respecter ce principe que tu apprendrais au débutant -- qui
veut juste à apprendre à programmer en C++ -- de commencer d'abord en
binaire, plus en langage d'assemblage, puis en C en enfin en C++ sans
doute ?
| Tu peux aussi enseigner, en conduite accompagnée, en expliquant
| à chaque instant vers où, et de combien, il faut tourner le volant.
| "Gabriel Dos Reis" a écrit dans le message | news: | | > Quelles sont tes alternatives à std::vector<> et std::string? | | L'énorme et intéressante quantités de choses qui servent | à les écrire :-o
Mais encore.
| *je* ne suis pas partisan de les ignorer, simplement je trouve | provocant - et en tout cas questionnable - la position consistant | à dire qu'il est démodé d'enseigner comment ça marche !
T'aurais pris un coup de canicule ?
Je ne dis pas qu'il est démodé d'enseigner comment ça marche. Je dis que pour apprendre aux débutants à programmer en C++, ce ne devrait pas être la première chose à faire.
| Oui, je sais... " à un *dé-bu-tant*". Ok, eh bien, Wittgenstein a | dit, avec pertinence: "Le vrai sens d'un théorème, c'est sa preuve".
Même si ce brave monsieur avait raison, cela n'a aucune espèce d'importance ici : nous ne parlons pas de théorème.
| Tu ne sais pas ce qu'est une chose avant de savoir "comment ça | marche".
C'est pour respecter ce principe que tu apprendrais au débutant -- qui veut juste à apprendre à programmer en C++ -- de commencer d'abord en binaire, plus en langage d'assemblage, puis en C en enfin en C++ sans doute ?
| Tu peux aussi enseigner, en conduite accompagnée, en expliquant | à chaque instant vers où, et de combien, il faut tourner le volant.
Quel est le rapport avec la choucroute ?
-- Gaby
Gabriel Dos Reis
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.
Non, ils ne ne le sont pas. En C, on est toujours obligé d'utiliser des macros ou des enums pour avoir des expressions constantes entières. Je pense que'une sémantique raisonablement utile de const devrait couvrir les expressions constantes entières.
En fait, j'irais même à dire que la sémantique de const en C rend cette fonctionnalité presque initule.
-- Gaby
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.
Non, ils ne ne le sont pas. En C, on est toujours obligé d'utiliser
des macros ou des enums pour avoir des expressions constantes
entières. Je pense que'une sémantique raisonablement utile de const
devrait couvrir les expressions constantes entières.
En fait, j'irais même à dire que la sémantique de const en C rend
cette fonctionnalité presque initule.
| 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.
Non, ils ne ne le sont pas. En C, on est toujours obligé d'utiliser des macros ou des enums pour avoir des expressions constantes entières. Je pense que'une sémantique raisonablement utile de const devrait couvrir les expressions constantes entières.
En fait, j'irais même à dire que la sémantique de const en C rend cette fonctionnalité presque initule.
-- Gaby
Gabriel Dos Reis
Jean-Marc Bourguet writes:
| 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 C, une variable entière déclarée const et initialisée avec une constant entière n'est pas une expression constante entière.
-- Gaby
Jean-Marc Bourguet <jm@bourguet.org> writes:
| 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 C, une variable entière déclarée const et initialisée avec une
constant entière n'est pas une expression constante entière.
| 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 C, une variable entière déclarée const et initialisée avec une constant entière n'est pas une expression constante entière.
