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
Ça ne commence pas à faire spaghetti et illisible ?
C'est toujours structure. Pas structure c'est des choses comme
switch (c%4) { case 0: while (c) { x(); --c; case 3: x(); --c; case 2: x(); --c; case 1: x(); --c; } }
que je ne suis d'ailleurs pas sur d'avoir ecrit correctement. Ou bien
if (c) { truc(); lbl: machin(); } else { bidule(); if (cond()) goto lbl; foo(); }
qui n'est meme pas conforme.
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
Richard Delorme <abulmo@nospam.fr> writes:
[...]
Ça ne commence pas à faire spaghetti et illisible ?
C'est toujours structure. Pas structure c'est des choses comme
switch (c%4) {
case 0: while (c) { x(); --c;
case 3: x(); --c;
case 2: x(); --c;
case 1: x(); --c;
}
}
que je ne suis d'ailleurs pas sur d'avoir ecrit correctement. Ou bien
if (c) {
truc();
lbl:
machin();
} else {
bidule();
if (cond()) goto lbl;
foo();
}
qui n'est meme pas conforme.
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
Ça ne commence pas à faire spaghetti et illisible ?
C'est toujours structure. Pas structure c'est des choses comme
switch (c%4) { case 0: while (c) { x(); --c; case 3: x(); --c; case 2: x(); --c; case 1: x(); --c; } }
que je ne suis d'ailleurs pas sur d'avoir ecrit correctement. Ou bien
if (c) { truc(); lbl: machin(); } else { bidule(); if (cond()) goto lbl; foo(); }
qui n'est meme pas conforme.
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
Fabien LE LEZ
On Tue, 10 Aug 2004 17:31:31 +0200, "Alain Naigeon" :
Oui, c'est ça, Carnegie Hall avant le solfège.
Non, le maniement de l'archet avant l'étude de la fabrication d'un violon.
-- ;-)
On Tue, 10 Aug 2004 17:31:31 +0200, "Alain Naigeon"
<anaigeon@free.fr>:
Oui, c'est ça, Carnegie Hall avant le solfège.
Non, le maniement de l'archet avant l'étude de la fabrication d'un
violon.
On Tue, 10 Aug 2004 17:31:31 +0200, "Alain Naigeon" :
Oui, c'est ça, Carnegie Hall avant le solfège.
Non, le maniement de l'archet avant l'étude de la fabrication d'un violon.
-- ;-)
Laurent Deniau
Arnaud Debaene wrote:
Laurent Deniau wrote:
Arnaud Debaene wrote:
Laurent Deniau wrote:
En quoi le C++ propose un typage plus fort que le C?
L'héritage et le polymorphisme, la généricité (template) et RTTI me viennent en tête sans trop me fatiguer, mais je pense que nous n'utilisont pas tous le mot "typage" dans le même sens dans ce thread.
Effectivement, nous n'utilisons le meme sens pour "typage fort". Tout ce que tu cites a l'exception des RTTI "affaiblit" le systeme de typage. Le compilateur doit etre "plus intelligent et plus vigilant" pour gerer tout ca.
En quoi les templates peuvent ils affaiblir le système de type? Il me semble que vector<MonObjet> est plus "sûr" qu'un container en C stockant des void*, non?
Je n'ai pas dit que les templates affaiblissaient le systeme de type, mais qu'ils le rendent "vunerable" et que le compilateur (et le developpeur) doit etre plus intelligent et plus vigilant pour eviter un "affaiblissement" du systeme de type.
ennoncent quelques uns des problemes possibles lies aux templates.
Precise l'orientation que tu donnes a abstration.
Un langage avec un bon niveau d'abstraction permet au développeur de se concentrer sur la sémantique et le fonctionnel de son application sns avoir à (trop) se préoccuper des détails d'implémentation. Ca va comme définition?
S'en est une. Mais *selon ton ennonce*, C++ n'a pas un bon niveau d'abstraction si on va au dela d'une utilisation simple de la STL dans des petits programmes didactiques. La pluspart des langages orientes objets ont un meilleur niveau d'abstraction (toujours selon ton ennonce), notamment parce qu'ils sont moins compliques a utiliser et qu'ils proposent moins de paradigmes.
a+, ld.
Arnaud Debaene wrote:
Laurent Deniau wrote:
Arnaud Debaene wrote:
Laurent Deniau wrote:
En quoi le C++ propose un typage plus fort que le C?
L'héritage et le polymorphisme, la généricité (template) et RTTI me
viennent en tête sans trop me fatiguer, mais je pense que nous
n'utilisont pas tous le mot "typage" dans le même sens dans ce
thread.
Effectivement, nous n'utilisons le meme sens pour "typage fort". Tout
ce
que tu cites a l'exception des RTTI "affaiblit" le systeme de typage.
Le compilateur doit etre "plus intelligent et plus vigilant" pour
gerer
tout ca.
En quoi les templates peuvent ils affaiblir le système de type? Il me semble
que vector<MonObjet> est plus "sûr" qu'un container en C stockant des void*,
non?
Je n'ai pas dit que les templates affaiblissaient le systeme de type,
mais qu'ils le rendent "vunerable" et que le compilateur (et le
developpeur) doit etre plus intelligent et plus vigilant pour eviter un
"affaiblissement" du systeme de type.
ennoncent quelques uns des problemes possibles lies aux templates.
Precise l'orientation que tu donnes a abstration.
Un langage avec un bon niveau d'abstraction permet au développeur de se
concentrer sur la sémantique et le fonctionnel de son application sns avoir
à (trop) se préoccuper des détails d'implémentation. Ca va comme définition?
S'en est une. Mais *selon ton ennonce*, C++ n'a pas un bon niveau
d'abstraction si on va au dela d'une utilisation simple de la STL dans
des petits programmes didactiques. La pluspart des langages orientes
objets ont un meilleur niveau d'abstraction (toujours selon ton
ennonce), notamment parce qu'ils sont moins compliques a utiliser et
qu'ils proposent moins de paradigmes.
En quoi le C++ propose un typage plus fort que le C?
L'héritage et le polymorphisme, la généricité (template) et RTTI me viennent en tête sans trop me fatiguer, mais je pense que nous n'utilisont pas tous le mot "typage" dans le même sens dans ce thread.
Effectivement, nous n'utilisons le meme sens pour "typage fort". Tout ce que tu cites a l'exception des RTTI "affaiblit" le systeme de typage. Le compilateur doit etre "plus intelligent et plus vigilant" pour gerer tout ca.
En quoi les templates peuvent ils affaiblir le système de type? Il me semble que vector<MonObjet> est plus "sûr" qu'un container en C stockant des void*, non?
Je n'ai pas dit que les templates affaiblissaient le systeme de type, mais qu'ils le rendent "vunerable" et que le compilateur (et le developpeur) doit etre plus intelligent et plus vigilant pour eviter un "affaiblissement" du systeme de type.
ennoncent quelques uns des problemes possibles lies aux templates.
Precise l'orientation que tu donnes a abstration.
Un langage avec un bon niveau d'abstraction permet au développeur de se concentrer sur la sémantique et le fonctionnel de son application sns avoir à (trop) se préoccuper des détails d'implémentation. Ca va comme définition?
S'en est une. Mais *selon ton ennonce*, C++ n'a pas un bon niveau d'abstraction si on va au dela d'une utilisation simple de la STL dans des petits programmes didactiques. La pluspart des langages orientes objets ont un meilleur niveau d'abstraction (toujours selon ton ennonce), notamment parce qu'ils sont moins compliques a utiliser et qu'ils proposent moins de paradigmes.
a+, ld.
Fabien LE LEZ
On Tue, 10 Aug 2004 17:20:00 +0200, "Alain Naigeon" :
Et puis, à force de lire "enseigner à des débutants", il faut bien souligner que cette expression n'a aucun sens, si ce n'est de vouloir dire "à des gens dont nous décidons qu'ils n'ont pas besoin de savoir".
Non, à des gens dont nous savons pertinemment qu'ils sont incapables d'apprendre l'intégralité du langage en une seule heure de cours. Il faut donc choisir un ordre, et donc décider de ce qu'il faut enseigner en premier. L'approche que je préconise est de commencer par les trucs à la fois fondamentaux et relativement simple, comme vector<> et string, et de laisser les détails compliqués et peu utiles (comme la cuisine interne de vector<> et string) pour plus tard.
Prenons un poste de radio. Tu peux décider d'étudier les théories de l'électromagnétisme et des semi-conducteurs, puis de concevoir des transistors, des condensateurs, des selfs, etc., puis étudier la manière de les arranger entre eux, le tout sans avoir la moindre idée de l'endroit où tout ça va te mener. Je préfère l'approche inverse : commencer par prendre un poste de radio tout fait, apprendre à s'en servir, apprécier la musique qu'il permet d'écouter, puis, un jour, poussé par la curiosité, l'ouvrir, et voir ce qu'il y a dedans, "découper" petit à petit : d'abord, une antenne, un haut-parleur, et des piles, tout ça relié à une plaque avec des machins dessus. Déjà, on comprend que les piles donnent du courant à la plaque, qui reçoit les ondes par l'antenne et envoie un signal au haut-parleur. Ensuite, on démonte le haut-parleur pour comprendre comment il fonctionne. On peut aussi étudier la plaque, s'apercevoir que c'est de l'epoxy, avec, soudés dessus, des transistors (des machins qui amplifient le courant), des condensateurs (des petits accus), etc. Mais un transistor, comment ça marche ? Etc.
Tu l'auras compris, mon approche est de voir d'abord à quoi sert tel ou tel machin, comment on s'en sert, et ensuite seulement comment ça marche. Surtout quand étudier le fonctionnement d'un condensateur est nettement plus compliqué que tourner le bouton d'une radio.
-- ;-)
On Tue, 10 Aug 2004 17:20:00 +0200, "Alain Naigeon"
<anaigeon@free.fr>:
Et puis, à force de lire "enseigner à des débutants", il faut
bien souligner que cette expression n'a aucun sens, si ce
n'est de vouloir dire "à des gens dont nous décidons qu'ils
n'ont pas besoin de savoir".
Non, à des gens dont nous savons pertinemment qu'ils sont incapables
d'apprendre l'intégralité du langage en une seule heure de cours. Il
faut donc choisir un ordre, et donc décider de ce qu'il faut enseigner
en premier. L'approche que je préconise est de commencer par les trucs
à la fois fondamentaux et relativement simple, comme vector<> et
string, et de laisser les détails compliqués et peu utiles (comme la
cuisine interne de vector<> et string) pour plus tard.
Prenons un poste de radio. Tu peux décider d'étudier les théories de
l'électromagnétisme et des semi-conducteurs, puis de concevoir des
transistors, des condensateurs, des selfs, etc., puis étudier la
manière de les arranger entre eux, le tout sans avoir la moindre idée
de l'endroit où tout ça va te mener.
Je préfère l'approche inverse : commencer par prendre un poste de
radio tout fait, apprendre à s'en servir, apprécier la musique qu'il
permet d'écouter, puis, un jour, poussé par la curiosité, l'ouvrir, et
voir ce qu'il y a dedans, "découper" petit à petit : d'abord, une
antenne, un haut-parleur, et des piles, tout ça relié à une plaque
avec des machins dessus. Déjà, on comprend que les piles donnent du
courant à la plaque, qui reçoit les ondes par l'antenne et envoie un
signal au haut-parleur. Ensuite, on démonte le haut-parleur pour
comprendre comment il fonctionne. On peut aussi étudier la plaque,
s'apercevoir que c'est de l'epoxy, avec, soudés dessus, des
transistors (des machins qui amplifient le courant), des condensateurs
(des petits accus), etc. Mais un transistor, comment ça marche ? Etc.
Tu l'auras compris, mon approche est de voir d'abord à quoi sert tel
ou tel machin, comment on s'en sert, et ensuite seulement comment ça
marche. Surtout quand étudier le fonctionnement d'un condensateur est
nettement plus compliqué que tourner le bouton d'une radio.
On Tue, 10 Aug 2004 17:20:00 +0200, "Alain Naigeon" :
Et puis, à force de lire "enseigner à des débutants", il faut bien souligner que cette expression n'a aucun sens, si ce n'est de vouloir dire "à des gens dont nous décidons qu'ils n'ont pas besoin de savoir".
Non, à des gens dont nous savons pertinemment qu'ils sont incapables d'apprendre l'intégralité du langage en une seule heure de cours. Il faut donc choisir un ordre, et donc décider de ce qu'il faut enseigner en premier. L'approche que je préconise est de commencer par les trucs à la fois fondamentaux et relativement simple, comme vector<> et string, et de laisser les détails compliqués et peu utiles (comme la cuisine interne de vector<> et string) pour plus tard.
Prenons un poste de radio. Tu peux décider d'étudier les théories de l'électromagnétisme et des semi-conducteurs, puis de concevoir des transistors, des condensateurs, des selfs, etc., puis étudier la manière de les arranger entre eux, le tout sans avoir la moindre idée de l'endroit où tout ça va te mener. Je préfère l'approche inverse : commencer par prendre un poste de radio tout fait, apprendre à s'en servir, apprécier la musique qu'il permet d'écouter, puis, un jour, poussé par la curiosité, l'ouvrir, et voir ce qu'il y a dedans, "découper" petit à petit : d'abord, une antenne, un haut-parleur, et des piles, tout ça relié à une plaque avec des machins dessus. Déjà, on comprend que les piles donnent du courant à la plaque, qui reçoit les ondes par l'antenne et envoie un signal au haut-parleur. Ensuite, on démonte le haut-parleur pour comprendre comment il fonctionne. On peut aussi étudier la plaque, s'apercevoir que c'est de l'epoxy, avec, soudés dessus, des transistors (des machins qui amplifient le courant), des condensateurs (des petits accus), etc. Mais un transistor, comment ça marche ? Etc.
Tu l'auras compris, mon approche est de voir d'abord à quoi sert tel ou tel machin, comment on s'en sert, et ensuite seulement comment ça marche. Surtout quand étudier le fonctionnement d'un condensateur est nettement plus compliqué que tourner le bouton d'une radio.
-- ;-)
Luc Hermitte
Fabien LE LEZ wrote in news::
Février-mars : RAS. Avant : désolé, j'ai paumé mes archives. Elles doivent se trouver quelque part sur un CD-ROM...
Lol. Tu veux les miennes ? 47.3 Mo depuis Février 2003. ^^
-- Luc Hermitte <hermitte at free.fr> FAQ de <news:fr.comp.lang.c++> : <http://www.cmla.ens-cachan.fr/Utilisateurs/dosreis/C++/FAQ/> Dejanews : <http://groups.google.com/advanced_group_search>
Fabien LE LEZ <gramster@gramster.com> wrote in
news:8pihh09spba4q16mg067i6tetjoukihup0@4ax.com:
Février-mars : RAS.
Avant : désolé, j'ai paumé mes archives. Elles doivent se trouver
quelque part sur un CD-ROM...
Lol.
Tu veux les miennes ? 47.3 Mo depuis Février 2003. ^^
--
Luc Hermitte <hermitte at free.fr>
FAQ de <news:fr.comp.lang.c++> :
<http://www.cmla.ens-cachan.fr/Utilisateurs/dosreis/C++/FAQ/>
Dejanews : <http://groups.google.com/advanced_group_search>
Je conteste absolument l'opinion implicite selon laquelle ce ne serait pas amusant de se masturber.
Oui mais de là à conseiller à un autre comment se masturber? Bon j'arrête là, on va dériver ;-)
Arnaud
Loïc Joly
M. B. wrote:
"Loïc Joly" a écrit dans le message de news: cf9su1$cq6$
M. B. wrote:
Pourquoi est-ce une heresie de passer par le C pour apprendre C++ ?
[...]
Comme toujours, la réponse est que oui, il est possible d'écrire des programmes orientés objet en C. Mais là n'est pas la question. De toute façon, même avec le C++, les premiers programmes écrits ne seront pas orientés objet, mais procéduraux.
Il n'en reste pas moins que le C oblige à faire constemment attention à des détails de bas niveau, et ce dès le premier programme qu'on écrit.
Il est donc bien plus difficile d'accès. Je préfère 100 fois devoir expliquer à des débutants std::string que char*.
Les char * seront eux aussi appris, mais plus tard, quand les concepts de base que sont une fonction, ou une structure de contrôle seront vus, connus, maitrisés.
C'est une question de progressivité.
Surtout que pour apprendre le C++, il est plus direct d'apprendre la C++. Dire le contraire, ce serait prétendre qu'il faut enseigner aux gosses de primaire le latin, et que le français viendra plus tard.
La STL n'est pas, au sens strict du terme, le langage C++. Ce n'est qu'une bibliotheque.
La STL fait au sens strict partie du C++, du moins autant que le printf ou le exit font partie du langage C. De plus, je n'ai ici nullement parlé de STL...
Pour ma part j'ai toujours suivi la demarche de Stroustrup dans l'enseignement du C++.
Le démarche dépend de l'auditoire. Pour un auditoire composé de programmeur C, le programme que tu cite me semble convenable. Pour un auditoire de débutants, c'est une ânerie. Comment parler d'un meilleur C à des gens ne connaissant pas le C ?
Chapitre 1 : ... Un meilleur C ... Chapitre 2 : Declaration et constantes
[...]
-- Loïc
M. B. wrote:
"Loïc Joly" <loic.actarus.joly@wanadoo.fr> a écrit dans le message de news:
cf9su1$cq6$1@news-reader2.wanadoo.fr...
M. B. wrote:
Pourquoi est-ce une heresie de passer par le C pour apprendre C++ ?
[...]
Comme toujours, la réponse est que oui, il est possible d'écrire des
programmes orientés objet en C. Mais là n'est pas la question. De toute
façon, même avec le C++, les premiers programmes écrits ne seront pas
orientés objet, mais procéduraux.
Il n'en reste pas moins que le C oblige à faire constemment attention à
des détails de bas niveau, et ce dès le premier programme qu'on écrit.
Il est donc bien plus difficile d'accès. Je préfère 100 fois devoir
expliquer à des débutants std::string que char*.
Les char * seront eux aussi appris, mais plus tard, quand les concepts
de base que sont une fonction, ou une structure de contrôle seront vus,
connus, maitrisés.
C'est une question de progressivité.
Surtout que pour apprendre le C++, il est plus direct d'apprendre la
C++. Dire le contraire, ce serait prétendre qu'il faut enseigner aux
gosses de primaire le latin, et que le français viendra plus tard.
La STL n'est pas, au sens strict du terme, le langage C++. Ce n'est qu'une
bibliotheque.
La STL fait au sens strict partie du C++, du moins autant que le printf
ou le exit font partie du langage C. De plus, je n'ai ici nullement
parlé de STL...
Pour ma part j'ai toujours suivi la demarche de Stroustrup dans
l'enseignement
du C++.
Le démarche dépend de l'auditoire. Pour un auditoire composé de
programmeur C, le programme que tu cite me semble convenable. Pour un
auditoire de débutants, c'est une ânerie. Comment parler d'un meilleur C
à des gens ne connaissant pas le C ?
Chapitre 1 : ... Un meilleur C ...
Chapitre 2 : Declaration et constantes
"Loïc Joly" a écrit dans le message de news: cf9su1$cq6$
M. B. wrote:
Pourquoi est-ce une heresie de passer par le C pour apprendre C++ ?
[...]
Comme toujours, la réponse est que oui, il est possible d'écrire des programmes orientés objet en C. Mais là n'est pas la question. De toute façon, même avec le C++, les premiers programmes écrits ne seront pas orientés objet, mais procéduraux.
Il n'en reste pas moins que le C oblige à faire constemment attention à des détails de bas niveau, et ce dès le premier programme qu'on écrit.
Il est donc bien plus difficile d'accès. Je préfère 100 fois devoir expliquer à des débutants std::string que char*.
Les char * seront eux aussi appris, mais plus tard, quand les concepts de base que sont une fonction, ou une structure de contrôle seront vus, connus, maitrisés.
C'est une question de progressivité.
Surtout que pour apprendre le C++, il est plus direct d'apprendre la C++. Dire le contraire, ce serait prétendre qu'il faut enseigner aux gosses de primaire le latin, et que le français viendra plus tard.
La STL n'est pas, au sens strict du terme, le langage C++. Ce n'est qu'une bibliotheque.
La STL fait au sens strict partie du C++, du moins autant que le printf ou le exit font partie du langage C. De plus, je n'ai ici nullement parlé de STL...
Pour ma part j'ai toujours suivi la demarche de Stroustrup dans l'enseignement du C++.
Le démarche dépend de l'auditoire. Pour un auditoire composé de programmeur C, le programme que tu cite me semble convenable. Pour un auditoire de débutants, c'est une ânerie. Comment parler d'un meilleur C à des gens ne connaissant pas le C ?
Chapitre 1 : ... Un meilleur C ... Chapitre 2 : Declaration et constantes
[...]
-- Loïc
Loïc Joly
Richard Delorme wrote:
Ce qui manque terriblement à mon avis, c'est un ouvrage qui ne présenterais que le sous ensemble du C++ suffisant à un débutant pour programmer proprement, en présentant par exemple std::vector, les namespace, iostream, etc. et en omettant de parler de pointeurs, de fonctions virtuelles, de polymorphisme, etc.
Le début d'accelerated C++ est comme ça. Mais la deuxième moitié parle de ces fonctions plus avancées.
Richard Delorme wrote:
Ce qui manque terriblement à mon avis, c'est un ouvrage qui ne
présenterais que le sous ensemble du C++ suffisant à un débutant pour
programmer proprement, en présentant par exemple std::vector, les
namespace, iostream, etc. et en omettant de parler de pointeurs, de
fonctions virtuelles, de polymorphisme, etc.
Le début d'accelerated C++ est comme ça. Mais la deuxième moitié parle
de ces fonctions plus avancées.
Ce qui manque terriblement à mon avis, c'est un ouvrage qui ne présenterais que le sous ensemble du C++ suffisant à un débutant pour programmer proprement, en présentant par exemple std::vector, les namespace, iostream, etc. et en omettant de parler de pointeurs, de fonctions virtuelles, de polymorphisme, etc.
Le début d'accelerated C++ est comme ça. Mais la deuxième moitié parle de ces fonctions plus avancées.
Arnaud Debaene
Laurent Deniau wrote:
Un langage avec un bon niveau d'abstraction permet au développeur de se concentrer sur la sémantique et le fonctionnel de son application sns avoir à (trop) se préoccuper des détails d'implémentation. Ca va comme définition?
S'en est une. Mais *selon ton ennonce*, C++ n'a pas un bon niveau d'abstraction si on va au dela d'une utilisation simple de la STL dans des petits programmes didactiques. La pluspart des langages orientes objets ont un meilleur niveau d'abstraction (toujours selon ton ennonce), Je ne vois pas pourquoi. Le 1er exemple qui me vient à l'esprit : la
libération correcte des ressources en cas d'exception. En Java ou en C#, ca se fait grâce à des blocs "finally" qui restent donc de la responsabilité du programmeur tout au long du code. En C++, l'diome RAII fait ca "pour nous" si on s'y prend correctement, ca fait donc un détail d'implémentation de moins à gérer.
notamment parce qu'ils sont moins compliques a utiliser Ca c'est vrai...
et qu'ils proposent moins de paradigmes. Justement, le fait d'avoir le choix du paradigme permet d'adapter son mode
de programmation au problème en cours, plutôt que d'essayer de faire rentrer des ronds dans des carrés. Je ne vois pas en quoi sa nuit au niveau d'abstraction.
Ceci dit, il ne suffit pas d'avoir un haut niveau d'abstraction, encore faut-il que cette abstraction soit de qualité. La preuve, VB a un plus haut niveau d'abstraction que C++ ;-) (PS : je parle de VB<=6 là, VB.NET étant pour ainsi dire la même chose que C# à la syntaxe près).
Arnaud
Laurent Deniau wrote:
Un langage avec un bon niveau d'abstraction permet au développeur de
se concentrer sur la sémantique et le fonctionnel de son application
sns avoir à (trop) se préoccuper des détails d'implémentation. Ca va
comme définition?
S'en est une. Mais *selon ton ennonce*, C++ n'a pas un bon niveau
d'abstraction si on va au dela d'une utilisation simple de la STL dans
des petits programmes didactiques. La pluspart des langages orientes
objets ont un meilleur niveau d'abstraction (toujours selon ton
ennonce),
Je ne vois pas pourquoi. Le 1er exemple qui me vient à l'esprit : la
libération correcte des ressources en cas d'exception. En Java ou en C#, ca
se fait grâce à des blocs "finally" qui restent donc de la responsabilité du
programmeur tout au long du code. En C++, l'diome RAII fait ca "pour nous"
si on s'y prend correctement, ca fait donc un détail d'implémentation de
moins à gérer.
notamment parce qu'ils sont moins compliques a utiliser
Ca c'est vrai...
et
qu'ils proposent moins de paradigmes.
Justement, le fait d'avoir le choix du paradigme permet d'adapter son mode
de programmation au problème en cours, plutôt que d'essayer de faire rentrer
des ronds dans des carrés. Je ne vois pas en quoi sa nuit au niveau
d'abstraction.
Ceci dit, il ne suffit pas d'avoir un haut niveau d'abstraction, encore
faut-il que cette abstraction soit de qualité. La preuve, VB a un plus haut
niveau d'abstraction que C++ ;-) (PS : je parle de VB<=6 là, VB.NET étant
pour ainsi dire la même chose que C# à la syntaxe près).
Un langage avec un bon niveau d'abstraction permet au développeur de se concentrer sur la sémantique et le fonctionnel de son application sns avoir à (trop) se préoccuper des détails d'implémentation. Ca va comme définition?
S'en est une. Mais *selon ton ennonce*, C++ n'a pas un bon niveau d'abstraction si on va au dela d'une utilisation simple de la STL dans des petits programmes didactiques. La pluspart des langages orientes objets ont un meilleur niveau d'abstraction (toujours selon ton ennonce), Je ne vois pas pourquoi. Le 1er exemple qui me vient à l'esprit : la
libération correcte des ressources en cas d'exception. En Java ou en C#, ca se fait grâce à des blocs "finally" qui restent donc de la responsabilité du programmeur tout au long du code. En C++, l'diome RAII fait ca "pour nous" si on s'y prend correctement, ca fait donc un détail d'implémentation de moins à gérer.
notamment parce qu'ils sont moins compliques a utiliser Ca c'est vrai...
et qu'ils proposent moins de paradigmes. Justement, le fait d'avoir le choix du paradigme permet d'adapter son mode
de programmation au problème en cours, plutôt que d'essayer de faire rentrer des ronds dans des carrés. Je ne vois pas en quoi sa nuit au niveau d'abstraction.
Ceci dit, il ne suffit pas d'avoir un haut niveau d'abstraction, encore faut-il que cette abstraction soit de qualité. La preuve, VB a un plus haut niveau d'abstraction que C++ ;-) (PS : je parle de VB<=6 là, VB.NET étant pour ainsi dire la même chose que C# à la syntaxe près).
Arnaud
Loïc Joly
PurL wrote:
Il y a au moins un bon conseil à donner : s'il ne parle pas de (std::)vector<> et (std::)string dès le départ, et longtemps avant d'aborder la notion de pointeur, il est totalement inadapté à un débutant.
On est obligé d'utiliser la stl pour faire du C++ ?
La sous partie de la SL souvent nommée STL n'est pas nécessaire pour programmer en C++. On peut aussi faire du C sans printf ni FILE*.
Maintenant, je ne considèrerais pas quelqu'un n'ayant aucune connaissance de std::cout, de std::string, de std::vector, de std::complex ou de std::map comme connaissant le C++.
On peut maintenant décider de ne pas l'utiliser sur un projet spécifique, ou uniquement en partie. Pour un nouveau projet, les raisons sont plus dures à trouver, mais pour de l'historique, c'est totalement justifiable. Je dirais que le plus gros avantage de la STL est s'être standard, et son plus gros défaut est d'être arrivée un peu trop tard, ce qui a donné lieu à une multitude d'alternatives non compatibles.
-- Loïc
PurL wrote:
Il y a au moins un bon conseil à donner : s'il ne parle pas de
(std::)vector<> et (std::)string dès le départ, et longtemps avant
d'aborder la notion de pointeur, il est totalement inadapté à un
débutant.
On est obligé d'utiliser la stl pour faire du C++ ?
La sous partie de la SL souvent nommée STL n'est pas nécessaire pour
programmer en C++. On peut aussi faire du C sans printf ni FILE*.
Maintenant, je ne considèrerais pas quelqu'un n'ayant aucune
connaissance de std::cout, de std::string, de std::vector, de
std::complex ou de std::map comme connaissant le C++.
On peut maintenant décider de ne pas l'utiliser sur un projet
spécifique, ou uniquement en partie. Pour un nouveau projet, les raisons
sont plus dures à trouver, mais pour de l'historique, c'est totalement
justifiable. Je dirais que le plus gros avantage de la STL est s'être
standard, et son plus gros défaut est d'être arrivée un peu trop tard,
ce qui a donné lieu à une multitude d'alternatives non compatibles.
Il y a au moins un bon conseil à donner : s'il ne parle pas de (std::)vector<> et (std::)string dès le départ, et longtemps avant d'aborder la notion de pointeur, il est totalement inadapté à un débutant.
On est obligé d'utiliser la stl pour faire du C++ ?
La sous partie de la SL souvent nommée STL n'est pas nécessaire pour programmer en C++. On peut aussi faire du C sans printf ni FILE*.
Maintenant, je ne considèrerais pas quelqu'un n'ayant aucune connaissance de std::cout, de std::string, de std::vector, de std::complex ou de std::map comme connaissant le C++.
On peut maintenant décider de ne pas l'utiliser sur un projet spécifique, ou uniquement en partie. Pour un nouveau projet, les raisons sont plus dures à trouver, mais pour de l'historique, c'est totalement justifiable. Je dirais que le plus gros avantage de la STL est s'être standard, et son plus gros défaut est d'être arrivée un peu trop tard, ce qui a donné lieu à une multitude d'alternatives non compatibles.
