Bonsoir
Je ne savais pas trop quel titre donner à mon post. Ce que je souhaite,
c'est assurer qu'un membre template hérite d'une classe donnée.

un bon exemple vaut mieux qu'un long discourt :

#include <iostream>

class A
{
public:
A() {}
void Do() { std::cout << "A" << std::endl; }
};

class B : public A
{
public:
B() {}
void Do() { std::cout << "B" << std::endl; }
};

class C
{
public:
C() {}
void Do() { std::cout << "C" << std::endl; }
};

class D
{
public:
D() {}

void Test()
{
Do<B>(); // OK, ca doit compiler
Do<A>(); // ne doit pas compiler
Do<C>(); // ne doit pas compiler
}

// template <class T : public A> ne fonctionne pas, dommage
template <class T>
void Do(void)
{
T t;
t.Do();
}
};

int main()
{
D d;
d.Test();
return 0;
}

C'est possible ?
Si oui, comment ?
Merci
--
Jérémie

jeremie fouche wrote on 09/05/2008 00:21:
> Bonsoir
> Je ne savais pas trop quel titre donner à mon post. Ce que je souhaite,
> c'est assurer qu'un membre template hérite d'une classe donnée.

dans votre exemple, ni la classe D, ni sa fonction membre 'Do'
"n'hérite" de la classe B ou A ou C. la garantie serait plus
comment s'assurer que la méthode Do reçoit un paramètre donnée.
votre question est donc: comment définir une fonction paramétrable
qui n'accepte qu'un un seul type de paramètre donné ?!

êtes-vous sur que cela a du sens ? ou que votre contrainte est
clairement expliquée ?

Sylvain.

Sylvain SF a écrit :
> jeremie fouche wrote on 09/05/2008 00:21:
>> Bonsoir
>> Je ne savais pas trop quel titre donner à mon post. Ce que je souhaite,
>> c'est assurer qu'un membre template hérite d'une classe donnée.
>
> dans votre exemple, ni la classe D, ni sa fonction membre 'Do'
> "n'hérite" de la classe B ou A ou C. la garantie serait plus
> comment s'assurer que la méthode Do reçoit un paramètre donnée.
> votre question est donc: comment définir une fonction paramétrable
> qui n'accepte qu'un un seul type de paramètre donné ?!

Absolument.

> êtes-vous sur que cela a du sens ? ou que votre contrainte est
> clairement expliquée ?

Je pensais, avec l'exemple donné.
Je souhaite refuser d'utiliser la méthode D:o avec autre chose qu'une
classe héritant de A.
C'est plus pour apprendre, car aujourd'hui, en laissant le code tel
quel, cela fonctionne correctement dans mon produit. Je voudrais juste
savoir si c'est possible ou non.
Merci pour le recadrage sur la question
--
Jérémie

On Fri, 09 May 2008 00:21:26 +0200, jeremie fouche <jfouche@voila.fr>:

> void Do(void)

Note en passant : le deuxième "void" est totalement inutile, et
typique d'un code en C. En C++ on écrira plutôt :

void Do()



>class B : public A
> Do<B>(); // OK, ca doit compiler
> Do<A>(); // ne doit pas compiler
> Do<C>(); // ne doit pas compiler

En résumé :

- si T = A, erreur de compilation
- sinon, si T dérive de A, OK
- sinon, erreur

C'est bien ça ?

Ça ressemble fort aux sections 2.7 et 2.1 de "Modern C++ Design"
(Alexandrescu).


Apparemment que le code suivant répond à la question :

#include "static_check.h"
#include "TypeManip.h"

class D
{
public:
void Test()
{
Do<B>(); // OK, ca doit compiler
//Do<A>(); // ne doit pas compiler
//Do<C>(); // ne doit pas compiler
}

public:
template <class T>
void Do()
{
STATIC_CHECK (SUPERSUBCLASS_STRICT (A, T), T_doit_deriver_de_A);
...
}
};

Les deux .h se trouvent dans Loki.
La version d'origine (basée sur le livre, et sur laquelle se base le
code ci-dessus) se trouve à l'adresse
<http://www.awprofessional.com/content/images/0201704315/sourcecode/loki.zip>.
Pour le reste, cf <http://en.wikipedia.org/wiki/Loki_%28C%2B%2B%29>.

On Fri, 09 May 2008 00:44:51 +0200, jeremie fouche <jfouche@voila.fr>:

>Je souhaite refuser d'utiliser la méthode D:o avec autre chose qu'une
>classe héritant de A.

Là où j'ai du mal à comprendre le sens, c'est que tu acceptes B mais
refuses A.

On Fri, 09 May 2008 00:57:41 +0200, Fabien LE LEZ :

>Apparemment que le code suivant

Ja parler la France aussi bien que Johnny...
Désolé.

Fabien LE LEZ wrote on 09/05/2008 00:57:
>
> template <class T> void Do()
> {
> STATIC_CHECK (SUPERSUBCLASS_STRICT (A, T), T_doit_deriver_de_A);
> ...
> }

je pensais bien à un typeid mais les infos ne sont disponibles
qu'au runtime pas à la compil., c'est le cas ici ?
(j'ai parcouru le wiki mais pas éplucher tout le zip).

"T_doit_deriver_de_A" correspond à quoi ? (juste un bool utilisé
par STATIC_CHECK pour comparer ses 2 membres ?)

Sylvain.

Sylvain SF wrote on 09/05/2008 02:09:
>
> c'est le cas ici ?

j'ai trouvé mes réponses ... et je ne les ai pas comprises!

Sylvain.

On Fri, 09 May 2008 02:09:53 +0200, "Sylvain SF" :

>je pensais bien à un typeid mais les infos ne sont disponibles
>qu'au runtime pas à la compil., c'est le cas ici ?

Non, non, ici tout est statique.
L'OP voulait un système tel que la ligne "Do<B>();" compile, et les
lignes "Do<A>();" et "Do<C>();" ne compilent pas. C'est le cas : les
deux derniers déclenchent une erreur de compilation.

"SUPERSUBCLASS_STRICT (A, T)" est une valeur, calculée par le
compilateur, égale à 1 si T dérive (strictement) de A, et à 0 sinon.

"STATIC_CHECK (true, ..." est une no-op.
"STATIC_CHECK (false, ..." est un code incorrect.

En fait, on pourrait l'implémenter comme ceci :

#define STATIC_CHECK(x) { char dummy[x]; }
Si x vaut 0, le code n'est pas correct, et le compilo râle ; si x>0,
ce code ne fait rien d'utile.


C'est très différent de assert(x), qui ne déclenche jamais d'erreur de
compilation (mais peut parfois arrêter le programme à l'exécution.)


>"T_doit_deriver_de_A" correspond à quoi ?

C'est censé être le message d'erreur qui s'affiche. En pratique, ça ne
semble pas fonctionner (avec Comeau), et je n'ai pas trop le courage
d'aller voir pourquoi.
Tu peux mettre n'importe quel identifiant à la place.


En passant, je rappelle que tout ça sort du bouquin "Modern C++
Design" (Alexandrescu), dont je conseille fortement la lecture. C'est
le livre qui m'a fait réellement comprendre toute la puissance des
templates.

On May 9, 2:09 am, "Sylvain SF" <sylv...@boiteaspam.info> wrote:
> Fabien LE LEZ wrote on 09/05/2008 00:57:

> > template <class T> void Do()
> > {
> > STATIC_CHECK (SUPERSUBCLASS_STRICT (A, T), T_doit_deriver_de_A);
> > ...
> > }

> je pensais bien à un typeid mais les infos ne sont disponibles
> qu'au runtime pas à la compil., c'est le cas ici ?
> (j'ai parcouru le wiki mais pas éplucher tout le zip).

> "T_doit_deriver_de_A" correspond à quoi ? (juste un bool utilisé
> par STATIC_CHECK pour comparer ses 2 membres ?)

Je te conseille le Vandevoorde et Josuttis : il décrit en
détail ce genre de chose, et c'est extrèmement bien écrit. Dans
ce cas-ci, grosso modo :

La principe de base, c'est de se servir de la résolution du
surcharge des fonctions (dont des fonctions templatées) pour
choisir selon les caractèristiques du type. Mais évidemment, on
ne veut pas réelement appeler les fonctions, ce qui de toute
façon ne se fera que lors de l'exécution. L'astuce, ici, c'est
de se servir de sizeof pour obtenir une constante de compilation
qui dépend de la résolution du surcharge : sizeof( func(...) )
vaut la taille du type du rétour de la fonction, et le
compilateur effectue bien la résolution du surcharge sans jamais
appeler la fonction.

Alors, pour commencer, on a besoin de deux types de taille
garantie différente, donc :

typedef char FalseType ; // sizeof( FalseType ) == 1, garanti
struct TrueType
{
char dummy[ 2 ] ;
} ; // sizeof( TrueType ) > 1, garanti

Note que c'est moins évident qu'on pourrait penser, parce que
la taille renvoyée par sizeof comprend un éventuel rembourrage
nécessaire pour l'alignement, et que la norme impose bien peu de
contraints sur les tailles rélatives. Ceci est la solution
classique, et je crois que c'est garanti, du fait que dans
TrueType, l'adresse de dummy[1] doit bien être &dummy[0]+1.

Ensuite, il faut définir l'ensemble des fonctions pour
discriminer ; commençons par un cas ultrasimple, où tu exiges A
ou dérivé d'A :

class A {} ; // Il faut qu'elle soit connu:-).

FalseType discrimintator( ... ) ;
TrueType discrimintator( A* ) ;

template< typename T >
class SeulementDeriveeD_A
{
char dummy[ sizeof( discrimintator( (T*)( 0 ) ) ) - 1 ] ;
} ;

Note bien que si tu instancies SeulementDeriveeD_A avec A, ou
une classe dérivée d'A, la résolution du surcharge dans la
définition de dummy va choisir la deuxième déclaration de
discrimintator, sinon la première. Note bien aussi le choix de
paramètres formels et l'expression du paramètre réel. On fait
attention d'éviter le moindre exigeance supplémentaire, genre
copiable, ou un constructeur sans paramètres. Si on peut
initialiser un A* avec un T*, le compilateur choisit
discrimintator( A* ), parce que tout autre choix est préférable
à utiliser le ... Du coup, le sizeof renvoie quelque chose
supérieur à 1, et le code reste légal. Si l'appel de
discrimintator( A* ) n'est pas légal avec un T*, le compilateur
n'a pas le choix, il choisit discrimintator( ... ), le sizeof
renvoie 1, on retranche 1, et on a une déclaration d'un tableau
à taille 0. Et donc, une erreur à la compilation.

Ici, j'ai laissé la déclaration dans la classe même, pour rester
simple. Ce qui augment la taille de la classe. La plupart du
temps, on cherche à éviter cette augmentation de taille en
cachant la déclaration ailleurs, mais dans quelque chose qui est
certain d'être instantié lors de l'instantiation de la classe.
La plus sûr, c'est probablement de le coller dans une union
anonyme avec un autre élément de la classe -- une autre
solution fréquente, c'est de le mettre dans une fonction inline
qui est appelée dans le destructeur (ce qui permet encore des
déclarations des pointeurs aux types non voulus, mais déclenche
une erreur dès qu'il y a un objet du type).

Enfin, on est prèsque arrivé où tu voulais. Il ne reste qu'à
écarter le cas où la classe est la classe de base même. Et c'est
assez facile à tester pour une classe précise :

template< typename T >
FalseType discrimintator( T* ) ;
TrueType discrimintator( A* ) ;

Pour tout type sauf A, l'instantiation du template
correspondrait exactement, tandis que la deuxième déclaration
exigera une conversion. C'est donc l'instantiation du template
qui est choisi. Pour A même, les deux correspond exactement, et
quand le compilateur a à choisir entre deux fonctions qui
correspond de la même dégrée, c'est le non-template qui a
précédance sur le template.

En combinant les deux, on a :

FalseType discrimintator( ... ) ;
template< typename B >
TrueType discrimintator( A*, B* ) ;
FalseType discrimintator( A*, A* ) ;

template< typename T >
class SeulementDeriveeD_A
{
char dummy[ sizeof( discrimintator( (T*)( 0 ), (T*)( 0 ) ) ) -
1 ] ;
} ;

Finalement, on cherche à jouer avec le nom de la variable, etc.,
pour avoir quelque chose dans le message d'erreur qui donne une
indication d'où se trouve la vraie erreur. Mais vue les
variations dans les messages d'erreur, ce n'est pas toujours
évident.

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

Fabien LE LEZ a écrit :
> On Fri, 09 May 2008 00:21:26 +0200, jeremie fouche <jfouche@voila.fr>:
>
>> void Do(void)
>
> Note en passant : le deuxième "void" est totalement inutile, et
> typique d'un code en C. En C++ on écrira plutôt :

ET oui, je sais bien, tu me l'as déjà expliqué, mais les habitudes ont
(encore un peu) la vie dure. Note que j'ai réussi pour les autres

> En résumé :
>
> - si T = A, erreur de compilation
> - sinon, si T dérive de A, OK
> - sinon, erreur
>
> C'est bien ça ?

Voui

> Ça ressemble fort aux sections 2.7 et 2.1 de "Modern C++ Design"
> (Alexandrescu).
>
>
> Apparemment que le code suivant répond à la question :...

Merci pour vos réponses
En fait, je pensais qu'on pouvait faire un truc dans le genre sans
passer par de gros trucs.
--
Jérémie

James Kanze wrote on 09/05/2008 10:53:
>
> Je te conseille le Vandevoorde et Josuttis : il décrit en
> détail ce genre de chose, et c'est extrèmement bien écrit. Dans
> ce cas-ci, grosso modo : [...]

merci pour toutes tes explications (à Fabien également),
c'est beaucoup plus clair avec. un peu de lecture, V&J,
serait bienvenue en effet.

Sylvain.

In article <0da8bd52-a6ba-4da9-8a7e-6a803a0cea16@a23g2000hsc.googlegroups.com>,
James Kanze <james.kanze@gmail.com> wrote:
>Je te conseille le Vandevoorde et Josuttis : il décrit en
>détail ce genre de chose, et c'est extrèmement bien écrit. Dans
>ce cas-ci, grosso modo :
>
>La principe de base, c'est de se servir de la résolution du
>surcharge des fonctions (dont des fonctions templatées) pour
>choisir selon les caractèristiques du type. Mais évidemment, on
>ne veut pas réelement appeler les fonctions, ce qui de toute
>façon ne se fera que lors de l'exécution. L'astuce, ici, c'est
>de se servir de sizeof pour obtenir une constante de compilation
>qui dépend de la résolution du surcharge : sizeof( func(...) )
>vaut la taille du type du rétour de la fonction, et le
>compilateur effectue bien la résolution du surcharge sans jamais
>appeler la fonction.

Tiens, moi j'avais lu ca chez Alexandrescu, qui decrit aussi tres en
detail ce genre de choses, et pas mal d'autres trucs tres space.

La moquette de Vandevoorde et Josuttis est de meme qualite ? pour pondre
des trucs pareils, c'est clair qu'Alexandrescu fume du tres bon synthetique...

On Fri, 9 May 2008 10:48:58 +0000 (UTC), espie@lain.home (Marc Espie):

> pour pondre
>des trucs pareils, c'est clair qu'Alexandrescu fume du tres bon synthetique...

Et encore, t'as rien vu : le chapitre 2 est un recensement de quelques
petites techniques de base pour construire les choses sérieuses à
partir du chapitre 3.

On Fri, 09 May 2008 11:10:33 +0200, jeremie fouche <jfouche@voila.fr>:

>En fait, je pensais qu'on pouvait faire un truc dans le genre sans
>passer par de gros trucs.

Tu remarqueras que la modification dans ton code se résume à une seule
ligne, relativement compréhensible :

STATIC_CHECK (SUPERSUBCLASS_STRICT (A, T), T_doit_deriver_de_A);

Effectivement, l'implémentation (dans les .h) est un peu plus
compliquée, mais nettement plus simple et plus courte que celle d'un
truc aussi basique que std::string.

In article <n5q8249lo38m9g3j5q03gc1mt1hmv12j6u@4ax.com>,
Fabien LE LEZ <usenet15@x.edulang.com> wrote:
>On Fri, 9 May 2008 10:48:58 +0000 (UTC), espie@lain.home (Marc Espie):
>
>> pour pondre
>>des trucs pareils, c'est clair qu'Alexandrescu fume du tres bon synthetique...

>Et encore, t'as rien vu : le chapitre 2 est un recensement de quelques
>petites techniques de base pour construire les choses sérieuses à
>partir du chapitre 3.

Faudra que tu prennes des cours de lecture de posts, hein. J'ai lu tout
le bouquin d'Alexandrescu.

espie@lain.home (Marc Espie) writes:

| In article <n5q8249lo38m9g3j5q03gc1mt1hmv12j6u@4ax.com>,
| Fabien LE LEZ <usenet15@x.edulang.com> wrote:
| >On Fri, 9 May 2008 10:48:58 +0000 (UTC), espie@lain.home (Marc Espie):
| >
| >> pour pondre
| >>des trucs pareils, c'est clair qu'Alexandrescu fume du tres bon synthetique...
|
| >Et encore, t'as rien vu : le chapitre 2 est un recensement de quelques
| >petites techniques de base pour construire les choses sérieuses Ã
| >partir du chapitre 3.
|
| Faudra que tu prennes des cours de lecture de posts, hein. J'ai lu tout
| le bouquin d'Alexandrescu.

Je crois que Fabien voulait dire qu'il a lu le chapitre 2, et qu'il
est en train de lire le chapitre 3 ;-}

-- Gaby

On May 9, 6:48am, es...@lain.home (Marc Espie) wrote:
[...]
> La moquette deVandevoordeet Josuttis est de meme qualite ? pour pondre
> des trucs pareils, c'est clair qu'Alexandrescu fume du tres bon synthetique...

Non, c'est du parquet chez nous, mais le bois exotique c'est
interessant aussi... ;-)

David

On 09 May 2008 15:00:15 -0500, Gabriel Dos Reis <gdr@cs.tamu.edu>:

>Je crois que Fabien voulait dire qu'il a lu le chapitre 2, et qu'il
>est en train de lire le chapitre 3 ;-}

Non, je faisais référence au début de la discussion. Ou plutôt, je
croyais à tort que Marc faisait référence au début de la discussion.
Enfin bon, comme d'hab', j'ai répondu à un message sans le lire :-/

vandevoorde@gmail.com writes:

| On May 9, 6:48am, es...@lain.home (Marc Espie) wrote:
| [...]
| > La moquette deVandevoordeet Josuttis est de meme qualite ? pour pondre
| > des trucs pareils, c'est clair qu'Alexandrescu fume du tres bon synthetique...
|
| Non, c'est du parquet chez nous, mais le bois exotique c'est
| interessant aussi... ;-)
|
| David

Il faudrait que tu en ramènes à Sophia Antipolis, le mois prochain --
cela pourrait aider après des journées tendues :-).

-- Gaby

On 9 mai, 12:48, es...@lain.home (Marc Espie) wrote:
> In article
> <0da8bd52-a6ba-4da9-8a7e-6a803a0ce...@a23g2000hsc.googlegroups.com>,
> James Kanze <james.ka...@gmail.com> wrote:

> >Je te conseille le Vandevoorde et Josuttis : il décrit en
> >détail ce genre de chose, et c'est extrèmement bien écrit. Dans
> >ce cas-ci, grosso modo :

> >La principe de base, c'est de se servir de la résolution du
> >surcharge des fonctions (dont des fonctions templatées) pour
> >choisir selon les caractèristiques du type. Mais évidemment, on
> >ne veut pas réelement appeler les fonctions, ce qui de toute
> >façon ne se fera que lors de l'exécution. L'astuce, ici, c'est
> >de se servir de sizeof pour obtenir une constante de compilation
> >qui dépend de la résolution du surcharge : sizeof( func(...) )
> >vaut la taille du type du rétour de la fonction, et le
> >compilateur effectue bien la résolution du surcharge sans jamais
> >appeler la fonction.

> Tiens, moi j'avais lu ca chez Alexandrescu, qui decrit aussi
> tres en detail ce genre de choses, et pas mal d'autres trucs
> tres space.

> La moquette de Vandevoorde et Josuttis est de meme qualite ?
> pour pondre des trucs pareils, c'est clair qu'Alexandrescu
> fume du tres bon synthetique...

Je ne peux pas dire ; je n'ai jamais lu Alexandrescu. A priori,
d'après ces articles dans les news et dans des journaux, il me
donnait l'impression de s'amuser, plutôt que d'essayer des
choses pratiques et utilisables. Le Vandevoorde et Josuttis
explique les détails de tous ce qui concerne les templates --
j'avoue qu'il y avait beaucoup que je n'avais pas compris avant
de l'avoir lu. Je y ai trouvé une bonne équilibre entre le
théorique, et ce qui est peut-être possible, et la pratique,
c-à-d ce dont on peut réelement se servir. Et comme j'ai dit,
c'est exceptionnellement bien écrit.

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

On Sat, 10 May 2008 06:53:06 -0700 (PDT), James Kanze
<james.kanze@gmail.com>:

>Je ne peux pas dire ; je n'ai jamais lu Alexandrescu. A priori,
>d'après ces articles dans les news et dans des journaux, il me
>donnait l'impression de s'amuser,

J'ai l'impression qu'il y a deux visions des choses :

- "Effective C++" (Meyers) et "C++ Templates - The Complete Guide"
(Vandevoorde, Josuttis) sont des livres "de bas en haut" : ce sont des
cours où on indique les "bases" (même si le niveau final peut être
assez haut).

- "Exceptional C++" et "More Exceptional C++" (Sutter) et "Modern C++
Design" (Alexandrescu) sont des livres "de haut en bas" : ils
explorent les limites du langage, et en profitent tout de même pour
donner assez de "bases" pour que le lecteur puisse suivre.

Il me semble que chacun appréciera telle ou telle méthode selon sa
propre sensibilité. Personnellement, je préfère la seconde : profiter
de l'exposé de trucs bien tordus pour comprendre les mécanismes de
base.


> plutôt que d'essayer des choses pratiques et utilisables.

Le livre "Modern C++ Design" est tout de même la description d'une
bibliothèque d'usage général (Loki). Par exemple, le but du chapitre 6
est d'implémenter une classe "singleton", utilisable dans un grand
nombre de cas (grâce au "policies"), pour éviter au programmeur
d'avoir à réimplémenter ce design pattern à chaque fois. J'avoue
n'avoir pas encore utilisé cette bibliothèque (pas plus que Boost
d'ailleurs), mais le but est éminemment pratique.

Fabien LE LEZ wrote:
> [...] Par exemple, le but du chapitre 6
> est d'implémenter une classe "singleton", utilisable dans un grand
> nombre de cas (grâce au "policies"), pour éviter au programmeur
> d'avoir à réimplémenter ce design pattern à chaque fois. J'avoue
> n'avoir pas encore utilisé cette bibliothèque (pas plus que Boost
> d'ailleurs), mais le but est éminemment pratique.

But éminemment pratique me semble mal désigner une pratique qui en fin
de compte est mauvaise.

Fondamentalement, l'intérêt des singleton se réduit au fait que le jour
où on fera l'effort de refactoriser pour supprimer cette dépendance sur
un objet global unique, ce sera un peu plus facile que si on avait
utilisé une variable globale.

On May 13, 10:39 am, Jean-Marc Desperrier <jmd...@alussinan.org>
wrote:
> Fabien LE LEZ wrote:
> > [...] Par exemple, le but du chapitre 6
> > est d'implémenter une classe "singleton", utilisable dans un grand
> > nombre de cas (grâce au "policies"), pour éviter au programmeur
> > d'avoir à réimplémenter ce design pattern à chaque fois. J'avoue
> > n'avoir pas encore utilisé cette bibliothèque (pas plus que Boost
> > d'ailleurs), mais le but est éminemment pratique.

> But éminemment pratique me semble mal désigner une pratique
> qui en fin de compte est mauvaise.

> Fondamentalement, l'intérêt des singleton se réduit au fait
> que le jour où on fera l'effort de refactoriser pour supprimer
> cette dépendance sur un objet global unique, ce sera un peu
> plus facile que si on avait utilisé une variable globale.

L'intérêt des singleton, c'est qu'il y a des classes qui
représentent des entités qui sont par leur nature unique. En
C++, un intérêt supplémentaire, souvent, c'est qu'ils permettent
à gérer l'ordre d'initialisation.

Quant à l'intérêt d'alourdir un concept fondamentalement assez
simple avec des policies multiples, en revanche...

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

In article <ce37c0fe-329a-464e-8724-e82ac0537416@m36g2000hse.googlegroups.com>,
James Kanze <james.kanze@gmail.com> wrote:
>Quant à l'intérêt d'alourdir un concept fondamentalement assez
>simple avec des policies multiples, en revanche...

Alexandrescu a des exemples plus utiles, quand meme.
Le chapitre sur les smart pointers, qui utilise les memes techniques,
est quand meme plus sympa.

Mais bon, c'est clair que dans son bouquin, c'est quand meme la premiere
partie (Techniques) la plus interessante. Je soupconne que la 2e est
tres utile a quelqu'un qui a besoin d'exemples concrets pour comprendre
la premiere...