En début d'année, je vais suivre une formation dans l'automatisme et
l'informatique Industriel.
cependant je ne connais rien en langage de programmation. je suis à la
recherche de site voir des livres, afin de prendre de l'avance.
Question au passage, pour apprendre le C++ j'entend différente sons de
cloche, certain dissent qu'il faut apprendre le C au parvant, d'autre le
conseil fortement enfin d'autre que cela n'est absolument pas nécessaire.
On Mon, 01 Sep 2008 11:28:24 +0200, Mickaël Wolff :
Et pourquoi pas wxwidget ou gtkmm ? ;)
wxWidgets a, pour des raisons historiques, une particularité qui rend son utilisation assez pénible : des wxString partout au lieu de std::string, et même des wxStringArray au lieu de std::vector<std::string>. Du coup, il y a des conversions (heureusement souvent implicites) presque à chaque appel de fonction.
On Mon, 01 Sep 2008 11:28:24 +0200, Mickaël Wolff
<mickael.wolff@laposte.net>:
Et pourquoi pas wxwidget ou gtkmm ? ;)
wxWidgets a, pour des raisons historiques, une particularité qui rend
son utilisation assez pénible : des wxString partout au lieu de
std::string, et même des wxStringArray au lieu de
std::vector<std::string>. Du coup, il y a des conversions
(heureusement souvent implicites) presque à chaque appel de fonction.
On Mon, 01 Sep 2008 11:28:24 +0200, Mickaël Wolff :
Et pourquoi pas wxwidget ou gtkmm ? ;)
wxWidgets a, pour des raisons historiques, une particularité qui rend son utilisation assez pénible : des wxString partout au lieu de std::string, et même des wxStringArray au lieu de std::vector<std::string>. Du coup, il y a des conversions (heureusement souvent implicites) presque à chaque appel de fonction.
Demande à Addison-Wesley/Pearson (ou l'auteur, son email est publique :-)
-- Gaby
James Kanze
On Sep 2, 8:29 am, "" wrote:
On 1 sep, 10:52, Gabriel Dos Reis wrote:
> | Je pense que le passage d'arguments par référence > constante doit | arriver assez tôt,
> Définis « assez tôt » :-)
En l'occurrence, assez tôt, ça voulait dire pour moi dès qu'on veut passer des vectors à des fonctions, ce qui arrive probablement juste après qu'on ait appris les boucles et les fonctions.
Après qu'on a appris la plupart des méchanismes de contrôle de flux (boucles, if), donc. Et après qu'on a apris les types de base.
Aussi, c'est assez rare (très, très rare, même) de passer un vector à une fonction en C++ idiomatique. On passe des itérateurs.
En tout cas bien avant que l'on ait commencé à apprendre les types définis par l'utilisateur, donc assez tôt.
Là, je ne suis pas si sûr. Je envisagerais bien enseigner des classes avant les tableaux (qui ne sont en somme qu'un cas particulier de la composition).
> | si l'on veut donner de bonnes habitudes, non ?
> Lesquelles ?
> Passer des doubles ou floats ou ints par référence const n'est pas une > bonne habitude. Dans mon expérience, dès que tu mentionnes quelque > chose comme ça, il y a deux réactions possibles : > (1) ils commencent à en foutre partout, ou > (2) ils sont complètement tétanisés à l'idée de voir leurs > programmes tout d'un coup inefficaces parce qu'ils n'ont pas mis > assez de const ref.
Donc tu proposes de tout passer par copie au début, même des structures lourdes, et de leur montrer le passage par référence const bien plus tard ?
Dans beaucoup de cas, le passage par référence const n'est réelement qu'une optimisation. À ne présenter, donc, que bien tardivement.
A quel moment ? Après qu'ils aient vu les constructeurs par copie te semble un bon endroit ? A un autre moment encore ?
Après qu'ils aient maîtrisé les éléments de base. Au même momen t que le surcharge des opérateurs, peut-être.
-- James Kanze (GABI Software) email: 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
On Sep 2, 8:29 am, "loic.actarus.j...@numericable.fr"
<loic.actarus.j...@numericable.fr> wrote:
On 1 sep, 10:52, Gabriel Dos Reis <g...@cs.tamu.edu> wrote:
> | Je pense que le passage d'arguments par référence
> constante doit | arriver assez tôt,
> Définis « assez tôt » :-)
En l'occurrence, assez tôt, ça voulait dire pour moi dès qu'on
veut passer des vectors à des fonctions, ce qui arrive
probablement juste après qu'on ait appris les boucles et les
fonctions.
Après qu'on a appris la plupart des méchanismes de contrôle de
flux (boucles, if), donc. Et après qu'on a apris les types de
base.
Aussi, c'est assez rare (très, très rare, même) de passer un
vector à une fonction en C++ idiomatique. On passe des
itérateurs.
En tout cas bien avant que l'on ait commencé à apprendre les
types définis par l'utilisateur, donc assez tôt.
Là, je ne suis pas si sûr. Je envisagerais bien enseigner des
classes avant les tableaux (qui ne sont en somme qu'un cas
particulier de la composition).
> | si l'on veut donner de bonnes habitudes, non ?
> Lesquelles ?
> Passer des doubles ou floats ou ints par référence const n'est pas une
> bonne habitude. Dans mon expérience, dès que tu mentionnes quelque
> chose comme ça, il y a deux réactions possibles :
> (1) ils commencent à en foutre partout, ou
> (2) ils sont complètement tétanisés à l'idée de voir leurs
> programmes tout d'un coup inefficaces parce qu'ils n'ont pas mis
> assez de const ref.
Donc tu proposes de tout passer par copie au début, même des
structures lourdes, et de leur montrer le passage par
référence const bien plus tard ?
Dans beaucoup de cas, le passage par référence const n'est
réelement qu'une optimisation. À ne présenter, donc, que bien
tardivement.
A quel moment ? Après qu'ils aient vu les constructeurs par
copie te semble un bon endroit ? A un autre moment encore ?
Après qu'ils aient maîtrisé les éléments de base. Au même momen t
que le surcharge des opérateurs, peut-être.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
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
> | Je pense que le passage d'arguments par référence > constante doit | arriver assez tôt,
> Définis « assez tôt » :-)
En l'occurrence, assez tôt, ça voulait dire pour moi dès qu'on veut passer des vectors à des fonctions, ce qui arrive probablement juste après qu'on ait appris les boucles et les fonctions.
Après qu'on a appris la plupart des méchanismes de contrôle de flux (boucles, if), donc. Et après qu'on a apris les types de base.
Aussi, c'est assez rare (très, très rare, même) de passer un vector à une fonction en C++ idiomatique. On passe des itérateurs.
En tout cas bien avant que l'on ait commencé à apprendre les types définis par l'utilisateur, donc assez tôt.
Là, je ne suis pas si sûr. Je envisagerais bien enseigner des classes avant les tableaux (qui ne sont en somme qu'un cas particulier de la composition).
> | si l'on veut donner de bonnes habitudes, non ?
> Lesquelles ?
> Passer des doubles ou floats ou ints par référence const n'est pas une > bonne habitude. Dans mon expérience, dès que tu mentionnes quelque > chose comme ça, il y a deux réactions possibles : > (1) ils commencent à en foutre partout, ou > (2) ils sont complètement tétanisés à l'idée de voir leurs > programmes tout d'un coup inefficaces parce qu'ils n'ont pas mis > assez de const ref.
Donc tu proposes de tout passer par copie au début, même des structures lourdes, et de leur montrer le passage par référence const bien plus tard ?
Dans beaucoup de cas, le passage par référence const n'est réelement qu'une optimisation. À ne présenter, donc, que bien tardivement.
A quel moment ? Après qu'ils aient vu les constructeurs par copie te semble un bon endroit ? A un autre moment encore ?
Après qu'ils aient maîtrisé les éléments de base. Au même momen t que le surcharge des opérateurs, peut-être.
-- James Kanze (GABI Software) email: 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
James Kanze
On Sep 1, 1:30 pm, Mickaël Wolff wrote:
[...]
Cependant, je trouve aussi étrange le choix de FLTK, qui est tout de même un abandonware si l'on en croit la doc (la dernière version date de début 2007).
Je vois une release qui date de 29 août, 2008, ce qui n'est pas si ancien que ça.
-- James Kanze (GABI Software) email: 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
On Sep 1, 1:30 pm, Mickaël Wolff <mickael.wo...@laposte.net> wrote:
[...]
Cependant, je trouve aussi étrange le choix de FLTK, qui est tout de
même un abandonware si l'on en croit la doc (la dernière version date de
début 2007).
Je vois une release qui date de 29 août, 2008, ce qui n'est pas
si ancien que ça.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
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
Cependant, je trouve aussi étrange le choix de FLTK, qui est tout de même un abandonware si l'on en croit la doc (la dernière version date de début 2007).
Je vois une release qui date de 29 août, 2008, ce qui n'est pas si ancien que ça.
-- James Kanze (GABI Software) email: 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
Fabien LE LEZ
On Tue, 2 Sep 2008 02:07:12 -0700 (PDT), James Kanze :
Cependant, je trouve aussi étrange le choix de FLTK, qui est tout de même un abandonware si l'on en croit la doc (la dernière version date de début 2007).
Je vois une release qui date de 29 août, 2008, ce qui n'est pas si ancien que ça.
Apparemment la dernière activité humaine est effectivement très récente :
r6162 | matt | 2008-08-15 14:18:27 -0700 (Fri, 15 Aug 2008) | 1 line
Replaced badly named type Fl_FontSize with Fl_Font_Descriptor. This type is only used in the core files and not available to the user.
On Tue, 2 Sep 2008 02:07:12 -0700 (PDT), James Kanze
<james.kanze@gmail.com>:
Cependant, je trouve aussi étrange le choix de FLTK, qui est tout de
même un abandonware si l'on en croit la doc (la dernière version date de
début 2007).
Je vois une release qui date de 29 août, 2008, ce qui n'est pas
si ancien que ça.
Apparemment la dernière activité humaine est effectivement très
récente :
r6162 | matt | 2008-08-15 14:18:27 -0700 (Fri, 15 Aug 2008) | 1 line
Replaced badly named type Fl_FontSize with Fl_Font_Descriptor. This
type is only used in the core files and not available to the user.
On Tue, 2 Sep 2008 02:07:12 -0700 (PDT), James Kanze :
Cependant, je trouve aussi étrange le choix de FLTK, qui est tout de même un abandonware si l'on en croit la doc (la dernière version date de début 2007).
Je vois une release qui date de 29 août, 2008, ce qui n'est pas si ancien que ça.
Apparemment la dernière activité humaine est effectivement très récente :
r6162 | matt | 2008-08-15 14:18:27 -0700 (Fri, 15 Aug 2008) | 1 line
Replaced badly named type Fl_FontSize with Fl_Font_Descriptor. This type is only used in the core files and not available to the user.
Mickaël Wolff
James Kanze a écrit :
Je vois une release qui date de 29 août, 2008, ce qui n'est pas si ancien que ça.
C'est vrai que je me base toujours sur la date de la documentation. Je ne devrais pas, mais bon, si la documentation n'est pas récente, c'est qu'il y a un problème ;)
Je vois une release qui date de 29 août, 2008, ce qui n'est pas
si ancien que ça.
C'est vrai que je me base toujours sur la date de la documentation.
Je ne devrais pas, mais bon, si la documentation n'est pas récente,
c'est qu'il y a un problème ;)
Je vois une release qui date de 29 août, 2008, ce qui n'est pas si ancien que ça.
C'est vrai que je me base toujours sur la date de la documentation. Je ne devrais pas, mais bon, si la documentation n'est pas récente, c'est qu'il y a un problème ;)
> Je vois une release qui date de 29 août, 2008, ce qui n'est pas > si ancien que ça.
C'est vrai que je me base toujours sur la date de la documentation. Je ne devrais pas, mais bon, si la documentation n'est pas récente, c'est qu'il y a un problème ;)
Si l'interface de la bibliothèque évolue tellement vite qu'il faut une remise à jour de la documentation trop souvent, il y a un problème.
-- James Kanze (GABI Software) email: 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
On Sep 2, 3:16 pm, Mickaël Wolff <mickael.wo...@laposte.net> wrote:
James Kanze a écrit :
> Je vois une release qui date de 29 août, 2008, ce qui n'est pas
> si ancien que ça.
C'est vrai que je me base toujours sur la date de la documentation.
Je ne devrais pas, mais bon, si la documentation n'est pas récente,
c'est qu'il y a un problème ;)
Si l'interface de la bibliothèque évolue tellement vite qu'il
faut une remise à jour de la documentation trop souvent, il y a
un problème.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
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
> Je vois une release qui date de 29 août, 2008, ce qui n'est pas > si ancien que ça.
C'est vrai que je me base toujours sur la date de la documentation. Je ne devrais pas, mais bon, si la documentation n'est pas récente, c'est qu'il y a un problème ;)
Si l'interface de la bibliothèque évolue tellement vite qu'il faut une remise à jour de la documentation trop souvent, il y a un problème.
-- James Kanze (GABI Software) email: 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
Jean-Marc Bourguet
Mickaël Wolff writes:
James Kanze a écrit :
> Si l'interface de la bibliothèque évolue tellement vite qu'il > faut une remise à jour de la documentation trop souvent, il y a > un problème.
C'est marrant comme ta phrase peut être interprété de deux manières. Certes, je comprends que tu veuilles dire qu'une documentation qui change toutes les deux minutes ce n'est pas top. Mais que la documentation ne change pas, mais que le code évolue peut signifier que l'API change trop souvent pour être documentée :)
Les deux sont des problemes. -- 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
Mickaël Wolff <mickael.wolff@laposte.net> writes:
James Kanze a écrit :
> Si l'interface de la bibliothèque évolue tellement vite qu'il
> faut une remise à jour de la documentation trop souvent, il y a
> un problème.
C'est marrant comme ta phrase peut être interprété de deux
manières. Certes, je comprends que tu veuilles dire qu'une documentation
qui change toutes les deux minutes ce n'est pas top. Mais que la
documentation ne change pas, mais que le code évolue peut signifier que
l'API change trop souvent pour être documentée :)
Les deux sont des problemes.
--
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
> Si l'interface de la bibliothèque évolue tellement vite qu'il > faut une remise à jour de la documentation trop souvent, il y a > un problème.
C'est marrant comme ta phrase peut être interprété de deux manières. Certes, je comprends que tu veuilles dire qu'une documentation qui change toutes les deux minutes ce n'est pas top. Mais que la documentation ne change pas, mais que le code évolue peut signifier que l'API change trop souvent pour être documentée :)
Les deux sont des problemes. -- 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
Mickaël Wolff
James Kanze a écrit :
Si l'interface de la bibliothèque évolue tellement vite qu'il faut une remise à jour de la documentation trop souvent, il y a un problème.
C'est marrant comme ta phrase peut être interprété de deux manières. Certes, je comprends que tu veuilles dire qu'une documentation qui change toutes les deux minutes ce n'est pas top. Mais que la documentation ne change pas, mais que le code évolue peut signifier que l'API change trop souvent pour être documentée :)
Si l'interface de la bibliothèque évolue tellement vite qu'il
faut une remise à jour de la documentation trop souvent, il y a
un problème.
C'est marrant comme ta phrase peut être interprété de deux manières.
Certes, je comprends que tu veuilles dire qu'une documentation qui
change toutes les deux minutes ce n'est pas top. Mais que la
documentation ne change pas, mais que le code évolue peut signifier que
l'API change trop souvent pour être documentée :)
Si l'interface de la bibliothèque évolue tellement vite qu'il faut une remise à jour de la documentation trop souvent, il y a un problème.
C'est marrant comme ta phrase peut être interprété de deux manières. Certes, je comprends que tu veuilles dire qu'une documentation qui change toutes les deux minutes ce n'est pas top. Mais que la documentation ne change pas, mais que le code évolue peut signifier que l'API change trop souvent pour être documentée :)
> Si l'interface de la bibliothèque évolue tellement vite qu'il > faut une remise à jour de la documentation trop souvent, il y a > un problème.
C'est marrant comme ta phrase peut être interprété de deux manières. Certes, je comprends que tu veuilles dire qu'une documentation qui change toutes les deux minutes ce n'est pas top. Mais que la documentation ne change pas, mais que le code évolue peut signifier que l'API change trop souvent pour être documentée :)
Ou que les auteurs ont pris soin que les modifications du code n'impactent pas l'API.
En fait, dans le cas en question, il y a une version stable, et différents « snapshots ». La version stable date bien d'il y a un an, ou plus, et j'imagine que la documentation s'y rapporte. C'est aussi à mon avis une bonne politique : il faut bien expérimenter, mais l'utilisateur lambda ne veut pas une version expérimentale.
-- James Kanze (GABI Software) email: 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
On Sep 3, 8:07 am, Mickaël Wolff <mickael.wo...@laposte.net> wrote:
James Kanze a écrit :
> Si l'interface de la bibliothèque évolue tellement vite qu'il
> faut une remise à jour de la documentation trop souvent, il y a
> un problème.
C'est marrant comme ta phrase peut être interprété de deux
manières. Certes, je comprends que tu veuilles dire qu'une
documentation qui change toutes les deux minutes ce n'est pas
top. Mais que la documentation ne change pas, mais que le code
évolue peut signifier que l'API change trop souvent pour être
documentée :)
Ou que les auteurs ont pris soin que les modifications du code
n'impactent pas l'API.
En fait, dans le cas en question, il y a une version stable, et
différents « snapshots ». La version stable date bien d'il y a
un an, ou plus, et j'imagine que la documentation s'y rapporte.
C'est aussi à mon avis une bonne politique : il faut bien
expérimenter, mais l'utilisateur lambda ne veut pas une version
expérimentale.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
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
> Si l'interface de la bibliothèque évolue tellement vite qu'il > faut une remise à jour de la documentation trop souvent, il y a > un problème.
C'est marrant comme ta phrase peut être interprété de deux manières. Certes, je comprends que tu veuilles dire qu'une documentation qui change toutes les deux minutes ce n'est pas top. Mais que la documentation ne change pas, mais que le code évolue peut signifier que l'API change trop souvent pour être documentée :)
Ou que les auteurs ont pris soin que les modifications du code n'impactent pas l'API.
En fait, dans le cas en question, il y a une version stable, et différents « snapshots ». La version stable date bien d'il y a un an, ou plus, et j'imagine que la documentation s'y rapporte. C'est aussi à mon avis une bonne politique : il faut bien expérimenter, mais l'utilisateur lambda ne veut pas une version expérimentale.
-- James Kanze (GABI Software) email: 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
