Quel livre pour bien commencer ?

Version imprimable

Voir 40 message(s) de cette discussion en une page

16/09/2006, 18h09
Bakura

Bon courage ^^. Le livre est très compréhensible. C'est avec lui que j'ai compris la surcharge des opérateurs :aie:.
16/09/2006, 20h42
Geekolin

En tout cas je m'amuse beacoup avec, c'est déjà ça ;)
17/09/2006, 09h51
ash.ice.loky

Oui je trouve qu'il y a deja suffisement de couleures.

Les encadrés violets et les mots clefs en rouge sont tres bien de ce que je me souviens.

Ensuite certain diront "oui mais il ne parle pas de pre incrementeur plus optimisé que le post ...." mais a ce niveau tu t'en fou (et même a tous les niveaux quasiment ;-) )

bon amusement
17/09/2006, 10h21
Bakura

Citation:

Envoyé par ash.ice.loky

Ensuite certain diront "oui mais il ne parle pas de pre incrementeur plus optimisé que le post ...." mais a ce niveau tu t'en fou (et même a tous les niveaux quasiment ;-) )

Dit moi en plus :aie:
17/09/2006, 11h32
Luc Hermitte

Un bouquin pédagogique n'a pas à être une référence qui parle de tout.
Et cvant d'en arriver là, il y a plus important : const-correctness, exception-safety, LSP vs réutilisation, distinction des sémantiques de valeur et d'entité, ...
Tiens. Je viens de voir qu'AC++ introduisait ++v comme l'opération d'incrémentation. Donc, dans les premiers chapitres.
18/09/2006, 06h57
ash.ice.loky

Citation:

Envoyé par Luc Hermitte

Un bouquin pédagogique n'a pas à être une référence qui parle de tout.
Et cvant d'en arriver là, il y a plus important : const-correctness, exception-safety, LSP vs réutilisation, distinction des sémantiques de valeur et d'entité, ...
Tiens. Je viens de voir qu'AC++ introduisait ++v comme l'opération d'incrémentation. Donc, dans les premiers chapitres.

En effet 2 philosophies, 2 pédagogies.

Je penses qu'il ne faut pas tout mélanger et s'encombrer de "détails" n'aide pas vraiment à la compréhension.
18/09/2006, 07h47
Jean-Marc.Bourguet

Citation:

Envoyé par ash.ice.loky

En effet 2 philosophies, 2 pédagogies.

Je penses qu'il ne faut pas tout mélanger et s'encombrer de "détails" n'aide pas vraiment à la compréhension.

Ce n'est pas s'encombrer ou pas de détails, c'est savoir comment on organise l'apprentissage de l'ensemble. L'inconvénient de l'approche C(anal) historique, c'est la nécessité de mélanger les niveaux d'abstractions très tôt, ou d'avoir des incantations magiques. Les étudiants ont déjà que trop tendance à utiliser des incantations magiques, et le mélange des niveaux d'abstraction non encore maîtrisés n'aide en rien la compréhension.
18/09/2006, 20h14
Geekolin

Génial !!! :P

Ahhh il y a peu de sujets qui m'aient captivés autant 8O . Vraiment quel language fabuleux le C++, et dire que j'en connais encore presque rien :-D
18/09/2006, 20h35
Luc Hermitte

Certes "const" c'est à peu près autant un détail que ++i ou i++.
En revanche, LSP vs réutilisation, et sémantiques, sont des aspects de design qu'il est important de sentir, à défaut de parfaitement comprendre dans un premier temps. Ce sont des aspects qui vont décider de la modélisation de la solution au problème. Aspects qui vont au final se traduire en élements de syntaxe qui relèvent assez du détail.
La mécompréhension de ces éléments conduit aux erreurs de newb' telles que : - des héritages bancaux, - des opérateurs surchargés n'importe comment, - une sémantique de recopie complètement à l'ouest, ...

Bref des éléments importants qui ne sont pas des détails. Alors qu'apprendre d'autres langages peut se résumer à apprendre une syntaxe (et les bibliothèques standard qui vont avec), la compréhension du C++ nécessite la compréhension d'éléments qui vont bien au delà de la syntaxe.

NB: AC++ a une approche assez pragmatique : ils sont bien moins formels que moi qui résume ses concepts en deux mots. P.ex. le truc est que les opérateurs et les sémantiques de copies sont présentées dans le chapitre qui parle des classes valeurs.

PS: désolé pour cette réponse baclée :oops:

Citation:

- des opérateurs surchargés n'importe comment

Hum... euh... on m'appelle ? :aie: ! Tiens, voilà de quoi te faire bondir au plafond je pense ^^ Ma classe vector (enfin les surcharges) !

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
CVector & operator= (const CVector & v); // Opérateur =
      CVector operator+ (const CVector & v); // Opérateur +
      CVector operator- (const CVector & v); // Opérateur -
      CVector operator* (const CVector & v); // Opérateur *
      CVector operator/ (const CVector & v); // Opérateur /
      CVector operator+ (float f); // Opérateur + n°2
      CVector operator- (float f); // Opérateur - n°2
      CVector operator* (float f); // Opérateur * n°2
      CVector operator/ (float f); // Opérateur / n°2
      void operator+= (const CVector & v); // Opérateur +=
      void operator-= (const CVector & v); // Opérateur -=
      void operator*= (const CVector & v); // Opérateur *=
      void operator/= (const CVector & v); // Opérateur /=
      void operator+= (float f); // Opérateur += n°2
      void operator-= (float f); // Opérateur -= n°2
      void operator*= (float f); // Opérateur *= n°2
      void operator/= (float f); // Opérateur /= n°2
      bool operator== (const CVector & v); // Opérateur ==
      bool operator!= (const CVector & v) {return !(*this == v);} // Opérateur !=

Pas tapay, pas tapay ^^

18/09/2006, 22h41
Luc Hermitte

Citation:

Envoyé par Bakura

Hum... euh... on m'appelle ? :aie: ! Tiens, voilà de quoi te faire bondir au plafond je pense ^^ Ma classe vector (enfin les surcharges)!

Ca va. Pour un vecteur, cela a du sens.
Il reste des détails à corriger, mais rien de grave ici.
(-> const-correctness, symétrie des opérations)
19/09/2006, 10h37
JolyLoic

Quoique l'opérateur *= ou /= prenant un vecteur en paramètre n'est pas hyper catholique... Je suppose qu'il s'agit d'opération membre à membre, mais pour ce genre de chose non classique mathématiquement parlant, je préfère une autre notation.

Ce que j'aime peu aussi, c'est que la taille des vecteurs n'est pas définie, et la sémentique en cas de taille différente n'apparaît pas clairement.

A part ça, et en plus des remarques de Luc, je ne suis pas gêné plus que ça.
19/09/2006, 10h45
Jean-Marc.Bourguet

Citation:

Envoyé par JolyLoic

Quoique l'opérateur *= ou /= prenant un vecteur en paramètre n'est pas hyper catholique... Je suppose qu'il s'agit d'opération membre à membre, mais pour ce genre de chose non classique mathématiquement parlant, je préfère une autre notation.

C'est relativement classique. Cet usage remonte au moins à APL (Iverson, 1962), ça commence à être difficile de faire plus vieux en matière d'usage pour des langages de programmations. C'est aussi la sémantique des jeux d'instructions vectorielles, du STAR 100 à SSE.

Citation:

Ce que j'aime peu aussi, c'est que la taille des vecteurs n'est pas définie, et la sémentique en cas de taille différente n'apparaît pas clairement.

On manque d'information pour savoir ce qu'il y a en dessous. C'est peut-être une interface légère vers SSE.

La chose que j'ai remarquée, c'est l'utilisation de float pour un paramètre isolé. Sauf bonnes raisons (et celle que je viens de citer en est une), il vaut mieux utiliser des doubles pour faire les calculs en flottant.
19/09/2006, 13h11
Bakura

Ok pour les double ^^... Sinon pour les const c'est vrai que j'ai du mal. Je pourrais déclarer les surcharges const pour != et == non ?
19/09/2006, 13h31
Médinoc

En effet.
Et si tu as des accesseurs ou une surcharge de l'opérateur [], du dois avoir également une version const (et selon les cas, avoir ou non une version non-const).

Voir 40 message(s) de cette discussion en une page