Bof. Si les éléments sont connus à la compilation et qu'une initialisation de tableau de la sorte :
int & f( int idx ) { static int datas[] = { a , b , ... } ; // ... }
est possible, je ne vois pas l'intérêt.
Ben... En gros, on se retrouve avec des variables globales.
J'ai oublié de reprendre le nom de la fonction dont nous parlions : Ccpu::dToR(). Mais tu as raison, l'idée est d'encapsuler des variables dans une certaine portée (ici la classe Ccpu).
Autant je suis parfaitement d'accord si on renvoie un "int const&", autant ici je suis plus dubitatif.
Pourquoi ?
--drkm
Fabien LE LEZ <gramster@gramster.com> writes:
On Fri, 19 Nov 2004 20:34:21 +0100, drkm <usenet.fclcxx@fgeorges.org>:
Bof. Si les éléments sont connus à la compilation et qu'une
initialisation de tableau de la sorte :
int & f( int idx ) {
static int datas[] = { a , b , ... } ;
// ...
}
est possible, je ne vois pas l'intérêt.
Ben... En gros, on se retrouve avec des variables globales.
J'ai oublié de reprendre le nom de la fonction dont nous parlions :
Ccpu::dToR(). Mais tu as raison, l'idée est d'encapsuler des
variables dans une certaine portée (ici la classe Ccpu).
Autant je suis parfaitement d'accord si on renvoie un "int const&",
autant ici je suis plus dubitatif.
Bof. Si les éléments sont connus à la compilation et qu'une initialisation de tableau de la sorte :
int & f( int idx ) { static int datas[] = { a , b , ... } ; // ... }
est possible, je ne vois pas l'intérêt.
Ben... En gros, on se retrouve avec des variables globales.
J'ai oublié de reprendre le nom de la fonction dont nous parlions : Ccpu::dToR(). Mais tu as raison, l'idée est d'encapsuler des variables dans une certaine portée (ici la classe Ccpu).
Autant je suis parfaitement d'accord si on renvoie un "int const&", autant ici je suis plus dubitatif.
