template et #define

PurL wrote:

[...]
Par contre je définis aussi :

#define ENTETE_VERSION 6

et quand je fais :

WriteData<int>(ENTETE_VERSION);

mon compilateur m'indique :
[C++ Erreur] UnitFichier.cpp(32): E2121 ) manquante dans l'appel de
fonction

[C++ Erreur] UnitFichier.cpp(32): E2188 Syntaxe de l'expression

Pourquoi cette erreur ?

A tout hasard, tu n'aurais pas un point-virgule a la fin de ton define ?
#define ENTETE_VERSION 6 ;
au lieu de
#define ENTETE_VERSION 6

Si ce n'est pas ca, essaye de voir le fichier généré par le precompilateur.
Ya une option sur certains compilo (mais je ne connais pas BCB5)

A tout hasard, tu n'aurais pas un point-virgule a la fin de ton
define ? #define ENTETE_VERSION 6 ;
au lieu de
#define ENTETE_VERSION 6

et bam ! en plein dedans !
Merci pour ton aide, j'essairai de faire plus attention la prochaine fois...

PurL

"PurL" <purl-nospam@chez.com> a écrit dans le message de
news:c94in0$848$1@news-reader5.wanadoo.fr...

A tout hasard, tu n'aurais pas un point-virgule a la fin de ton
define ? #define ENTETE_VERSION 6 ;
au lieu de
#define ENTETE_VERSION 6

et bam ! en plein dedans !
Merci pour ton aide, j'essairai de faire plus attention la prochaine
fois...

PurL

d'où le gros danger des #define... Tu aurais fait
const int ENTETE_VERSION = 6;
tu n'aurais pas eu de pb car le compilo aurait pu detecter un ; en moins....

Franchement, à part les #define MACHIN_H pour prévenir les inclusions
multiples (#infdef MACHIN_H...#endif) qui peut me donner un avantage des
#define justifiant leur utilisation en C++ ? pour les macros mieux vaut une
fonction (inline à la rigueur), un template, etc... et pour les constantes
mieux vaut... une constante.

"Alexandre" <alex.g@netcourrier.com> writes:

qui peut me donner un avantage des #define justifiant leur
utilisation en C++ ?

Il y a toujours le cas

#ifdef SYSTEM_HAS_FEATURE_XXX
#include "header_providing_XXX.h"
#endif

...

#ifdef SYSTEM_HAS_FEATURE_XXX

du code utilisant header_providing_XXX.h

#endif

Ou bien des "vraies" macros, qui jouent avec les identificateurs :

#define DUMP(x) cout << #x << " = " << x << endl

Mais bon, sinon, les macros, ça sert surtout à faire des erreurs de
syntaxe, des messages d'erreurs incompréhensibles du compilateur, à
empêcher le débuggeur de faire son boulot, ... Ah, et ça sert surtout
à rassurer les programmeurs C. ;-)

--
Matthieu

On Thu, 27 May 2004 18:41:04 +0200, "Alexandre"
<alex.g@netcourrier.com> wrote:

qui peut me donner un avantage des
#define justifiant leur utilisation en C++ ?

Herb Sutter.
<http://www.gotw.ca/gotw/032.htm>

--
;-)
FLL, Epagneul Breton

On Thu, 27 May 2004 18:41:04 +0200, "Alexandre"
<alex.g@netcourrier.com> wrote:

qui peut me donner un avantage des #define

Le mot "avantage" est AMHA mal choisi : généralement, #define n'a pas
d'avantages sur d'autres solutions, c'est juste qu'on le choisit parce
qu'il n'y a pas d'autre solution ;-)

--
;-)
FLL, Epagneul Breton

Le mot "avantage" est AMHA mal choisi : généralement, #define n'a pas
d'avantages sur d'autres solutions, c'est juste qu'on le choisit parce
qu'il n'y a pas d'autre solution ;-)

oui, bien sûr. Je voulais dire "quand il y a une autre solution".

--
;-)
FLL, Epagneul Breton

Herb Sutter.
<http://www.gotw.ca/gotw/032.htm>

oui, c'est grosso modo les seuls cas où je les utilises...
Mais en tout cas ni comme macros ni comme constantes..

--
;-)
FLL, Epagneul Breton

Franchement, à part les #define MACHIN_H pour prévenir les inclusions
multiples (#infdef MACHIN_H...#endif) qui peut me donner un avantage des
#define justifiant leur utilisation en C++ ?

Peut-être pour l'optimisation, sur ce genre de code:

int i;
for ( i = 0 ; i < CONSTANTE ; i ++ ) { ... }

Dans le cas où constante est issu d'un #define, le compilateur peut
dérouler la boucle, mais le fait-il dans le cas d'une définition de
variable const ? Je ne connais pas bien C++, mais même quand une
variable est marquée const, elle peut quand même être modifiée avec des
choses sales du genre ça, non ?

const int i;
scanf( "%dn", (int *) &i );

Donc le compilateur ne peut pas être certain que la constante est
vraiment constante, à moins qu'une ruse m'ait échappé.

--
BBP

Brieuc Jeunhomme <bbp@via.ecp.fr> writes:

|> > Franchement, à part les #define MACHIN_H pour prévenir les
|> > inclusions multiples (#infdef MACHIN_H...#endif) qui peut me
|> > donner un avantage des #define justifiant leur utilisation en C++
|> > ?

|> Peut-être pour l'optimisation, sur ce genre de code:

|> int i;
|> for ( i = 0 ; i < CONSTANTE ; i ++ ) { ... }

|> Dans le cas où constante est issu d'un #define, le compilateur
|> peut dérouler la boucle, mais le fait-il dans le cas d'une
|> définition de variable const ?

|> Je ne connais pas bien C++, mais même quand une variable est
|> marquée const, elle peut quand même être modifiée avec
|> des choses sales du genre ça, non ?

|> const int i;
|> scanf( "%dn", (int *) &i );

Non. C'est un comportement indéfini.

Reflechis-y un moment. Je peux bien écrire :

int const size = 42 ;

char buffer[ size ] ;

Quel en serait la signification si size pourrait être modifié ?

Je crois que tu confonds avec des choses comme :

int i = 42 ;

void
f( int const& param )
{
std::cout << param << 'n' ;
++ i ;
std::cout << param << 'n' ;
++ const_cast< int& >( param ) ;
std::cout << param << 'n' ;
}

int
main()
{
f( i ) ;
return 0 ;
}

Ce programme a un comportement défini, et doit sortir :

42
43
44

quelque soit le compilateur utilisé à le compiler. Le compilateur
ne peut pas supposer dans f que ce qui est référencé par param
est const. De même, quand il génère l'appel à f, il ne peut
pas supposer que son paramètre ne serait pas modifié.

|> Donc le compilateur ne peut pas être certain que la constante est
|> vraiment constante, à moins qu'une ruse m'ait échappé.

La seule « ruse », c'est la définition du langage.

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