Questions tordues - C++ (French)

C++Talk.NET
C++ language newsgroups

Archives

FAQ

Memberlist

Usergroups

Profile

Questions tordues

C++Talk.NET Forum Index -> C++ (French)

View previous topic :: View next topic

Author

Message

Aurélien REGAT-BARREL
Guest

Posted: Mon Apr 04, 2005 4:05 pm Post subject: Questions tordues

Hello, j'ai deux mini questions tordues: namespace // anonyme { int a; // a1 } int a; // a2 Pour désigner a2, on utilise ::a. Mais peut-on désigner a1 ? est-ce que le code suivant est légal ? int * i = new int[ 100 ]; char * c = reinterpret_cast<char*>( i ); delete [] c; Merci. -- Aurélien REGAT-BARREL

Falk Tannhäuser
Guest

Posted: Mon Apr 04, 2005 4:17 pm Post subject: Re: Questions tordues

Aurélien REGAT-BARREL wrote:

Quote:

namespace // anonyme
{
int a; // a1
}
int a; // a2

Pour désigner a2, on utilise ::a. Mais peut-on désigner a1 ?

Le namespace anonyme est équivalent à

namespace NomUniqueAuquelOnNAPasDAcces
{
int a;
}
using namespace NomUniqueAuquelOnNAPasDAcces;

il faudrait donc écrire "NomUniqueAuquelOnNAPasDAcces::a" pour résoudre
l'ambiguïté mais malheureusement on ne connaît pas "NomUniqueAuquelOnNAPasDAcces"...

Quote:

est-ce que le code suivant est légal ?
int * i = new int[ 100 ];
char * c = reinterpret_cast<char*>( i );
delete [] c;

Non, voir § 5.3.5/3 :
"[...] In the second alternative (delete array) if the
dynamic type of the object to be deleted differs from
its static type, the behavior is undefined."

Falk

Aurélien REGAT-BARREL
Guest

Posted: Mon Apr 04, 2005 4:55 pm Post subject: Re: Questions tordues

Falk Tannhäuser wrote:

Quote:

Aurélien REGAT-BARREL wrote:

namespace // anonyme
{
int a; // a1
}
int a; // a2

Pour désigner a2, on utilise ::a. Mais peut-on désigner a1 ?

Le namespace anonyme est équivalent à

namespace NomUniqueAuquelOnNAPasDAcces
{
int a;
}
using namespace NomUniqueAuquelOnNAPasDAcces;

il faudrait donc écrire "NomUniqueAuquelOnNAPasDAcces::a" pour
résoudre
l'ambiguïté mais malheureusement on ne connaît pas
"NomUniqueAuquelOnNAPasDAcces"...

Ok.

Quote:

est-ce que le code suivant est légal ?
int * i = new int[ 100 ];
char * c = reinterpret_cast<char*>( i );
delete [] c;

Non, voir § 5.3.5/3 :
"[...] In the second alternative (delete array) if the
dynamic type of the object to be deleted differs from
its static type, the behavior is undefined."

Falk

Je m'en doutais, mais, _apparement_, ça pose pas de problème dans le test
que j'ai fait, ça m'a surpris.

Bon allez, une dernière pour la route:

class A
{
private:
typedef int MonType1; // types privés
class MonType2 {};

public:
void Test1( MonType1 );
void Test2( MonType2 * );
};

A a;
a.Test1( 0 );
a.Test2( 0 );

je suis étonné que ça marche, vu que dans la définition d'une fonction
publique j'utilise un type privé. Pour le typedef je pense qu'il y a une
histoire d'alias, mais pour Test2, j'ai un cast implicite en MonType2 * qui
est fait, hors je n'ai pas le droit d'utiliser MonType2.
surtout que je découvre une nuance entre le bon vieux cast C qui est
interdit (?) et static_cast / reinterpret_cast (!) qui sont eux autorisés:

a.Test2( static_cast<A::MyType *>( 0 ) ); // OK
a.Test2( reinterpret_cast<A::MyType *>( 10 ) ); // OK
a.Test2( (A::MyType *)( 0 ) ); // ERREUR

Pourquoi le cast C++ est-il autorisé ?

--
Aurélien REGAT-BARREL

Patrick 'Zener' Brunet
Guest

Posted: Mon Apr 04, 2005 6:08 pm Post subject: Re: réponse boîteuse

Bonsoir.

"Aurélien REGAT-BARREL" <nospam-aregatba (AT) yahoo (DOT) fr.invalid> a écrit dans le
message de news: 42516fa1$0$12952$626a14ce (AT) news (DOT) free.fr...
[...]

Quote:

Bon allez, une dernière pour la route:

class A
{
private:
typedef int MonType1; // types privés
class MonType2 {};

public:
void Test1( MonType1 );
void Test2( MonType2 * );
};

A a;
a.Test1( 0 );
a.Test2( 0 );

je suis étonné que ça marche, vu que dans la définition d'une fonction
publique j'utilise un type privé. Pour le typedef je pense qu'il y a une
histoire d'alias, mais pour Test2, j'ai un cast implicite en MonType2 *
qui
est fait, hors je n'ai pas le droit d'utiliser MonType2.
surtout que je découvre une nuance entre le bon vieux cast C qui est
interdit (?) et static_cast / reinterpret_cast (!) qui sont eux autorisés:

a.Test2( static_cast<A::MyType *>( 0 ) ); // OK
a.Test2( reinterpret_cast<A::MyType *>( 10 ) ); // OK
a.Test2( (A::MyType *)( 0 ) ); // ERREUR

Pourquoi le cast C++ est-il autorisé ?

Est-ce que ça ne serait pas un cas particulier lié au fait que le
compilateur utilise "int" par défaut pour se récupérer lorsqu'il se trouve
face à une déclaration manquante (ou inaccessible) ?

Par exemple, une faute de frappe dans le nom d'une constante d'enum conduit
à une tentative d'interprétation comme une variable typée "int" par
défaut...
Est-ce que le comportement est le même si MonType1 et MonType2 sont définis
pour ne pas être naturellement compatibles avec la constante 0 ?

Ou alors en invoquant avec une autre valeur :

private:
typedef char const MonType2;

puis

a.Test2( "prends toi ça !" );

Cordialement,

--

/***************************************
* Patrick BRUNET
* E-mail: lien sur http://zener131.free.fr/ContactMe
***************************************/

Fabien LE LEZ
Guest

Posted: Mon Apr 04, 2005 9:28 pm Post subject: Re: Questions tordues

On Mon, 4 Apr 2005 18:55:48 +0200, "Aurélien REGAT-BARREL"
<nospam-aregatba (AT) yahoo (DOT) fr.invalid>:

Quote:

Je m'en doutais, mais, _apparement_, ça pose pas de problème dans le test
que j'ai fait, ça m'a surpris.

Ben oui, c'est un comportement indéfini : ça peut très bien marcher
pendant des mois, puis, au moment où tu fais une modification dans un
tout autre module, BOUM !

Cela dit, il y a une explication plus simple : pour les types de base,
delete[], delete et free() ont à peu près le même comportement : ils
se contentent de libérer la mémoire, sans appeler de destructeur.
Du coup, leur passer un pointeur "brut" (i.e. non typé, ou avec un
type fantaisiste) ne fait a priori pas planter le bazar -- ce qui ne
veut pas dire qu'il faut le faire ;-)

--
;-)

Franck Branjonneau
Guest

Posted: Mon Apr 04, 2005 10:10 pm Post subject: Re: Questions tordues

"Aurélien REGAT-BARREL" <nospam-aregatba (AT) yahoo (DOT) fr.invalid> écrivait:

Quote:

class A
{
private:
typedef int MonType1; // types privés
class MonType2 {};

public:
void Test1( MonType1 );
void Test2( MonType2 * );
};

A a;
a.Test1( 0 );
a.Test2( 0 );

je suis étonné que ça marche, vu que dans la définition d'une fonction
publique j'utilise un type privé.

Mais tes appels de fonctions n'utilisent ni Montype1 ni Montype2 mais
0.

Quote:

surtout que je découvre une nuance entre le bon vieux cast C

Il n'est pas bon, juste vieux.

Quote:

qui est interdit (?)

Enlever le point d'interrogation.

Quote:

et static_cast / reinterpret_cast (!)

Ajouter des points d'exclamations.

Quote:

qui sont eux autorisés:

a.Test2( static_cast<A::MyType *>( 0 ) ); // OK
a.Test2( reinterpret_cast<A::MyType *>( 10 ) ); // OK
a.Test2( (A::MyType *)( 0 ) ); // ERREUR

Pourquoi le cast C++ est-il autorisé ?

Pour pouvoir t'aider il faudrait savoir ce qu'est MyType et d'où vient
ce fragment de code (fonction membre ou non). Quelle est l'erreur ?
--
Franck Branjonneau <fasbjx (AT) free (DOT) fr>

Falk Tannhäuser
Guest

Posted: Mon Apr 04, 2005 10:11 pm Post subject: Re: Questions tordues

Fabien LE LEZ wrote:

Quote:

On Mon, 4 Apr 2005 18:55:48 +0200, "Aurélien REGAT-BARREL"
Je m'en doutais, mais, _apparement_, ça pose pas de problème dans le test
que j'ai fait, ça m'a surpris.
Ben oui, c'est un comportement indéfini : ça peut très bien marcher
pendant des mois, puis, au moment où tu fais une modification dans un
tout autre module, BOUM !

Ou quand on change de compilo, ou lorsqu'un jour on fait la même chose
avec des types ayant un destructeur non trivial, ou parce qu'on compile
une nuit de pleine lune, ou ...

Falk

Fabien LE LEZ
Guest

Posted: Mon Apr 04, 2005 10:23 pm Post subject: Re: Questions tordues

On Tue, 05 Apr 2005 00:11:51 +0200, Falk Tannhäuser
<tannhauser86549spam (AT) free (DOT) fr>:

Quote:

ou parce qu'on compile
une nuit de pleine lune, ou ...

Évite de compiler les nuits de pleine lune, ou alors, assure-toi
d'avoir une gousse d'ail à portée de la main.

--
;-)

Falk Tannhäuser
Guest

Posted: Mon Apr 04, 2005 10:37 pm Post subject: Re: Questions tordues

Franck Branjonneau wrote:

Quote:

"Aurélien REGAT-BARREL" <nospam-aregatba (AT) yahoo (DOT) fr.invalid> écrivait:
qui sont eux autorisés:

a.Test2( static_cast<A::MyType *>( 0 ) ); // OK
a.Test2( reinterpret_cast<A::MyType *>( 10 ) ); // OK
a.Test2( (A::MyType *)( 0 ) ); // ERREUR

Pourquoi le cast C++ est-il autorisé ?

Pour pouvoir t'aider il faudrait savoir ce qu'est MyType et d'où vient
ce fragment de code (fonction membre ou non). Quelle est l'erreur ?

Lorsque je mets MonType2 à la place de MyType, aucun de ces 3 casts
ne compile chez moi avec gcc 3.4.1 (dans un fonction non-membre -
en l'occurrence main()), tout comme il se doit.

Falk

Samuel Krempp
Guest

Posted: Mon Apr 04, 2005 11:00 pm Post subject: Re: Questions tordues

le Tuesday 05 April 2005 00:23, [email]gramster (AT) gramster (DOT) com[/email] écrivit :

Quote:

On Tue, 05 Apr 2005 00:11:51 +0200, Falk Tannhäuser
[email]tannhauser86549spam (AT) free (DOT) fr[/email]>:

ou parce qu'on compile
une nuit de pleine lune, ou ...

Évite de compiler les nuits de pleine lune, ou alors, assure-toi
d'avoir une gousse d'ail à portée de la main.

ah tiens donc, pour quoi faire ? il me semblait que l'ail repoussait les
vampires, et que ce sont les lycanthropes qui s'activent à la pleine lune.

--
Sam

kanze@gabi-soft.fr
Guest

Posted: Tue Apr 05, 2005 7:38 am Post subject: Re: Questions tordues

Aurélien REGAT-BARREL wrote:

Quote:

Falk Tannhäuser wrote:
Aurélien REGAT-BARREL wrote:

est-ce que le code suivant est légal ?
int * i = new int[ 100 ];
char * c = reinterpret_cast<char*>( i );
delete [] c;

Non, voir § 5.3.5/3 :
"[...] In the second alternative (delete array) if the
dynamic type of the object to be deleted differs from
its static type, the behavior is undefined."

Je m'en doutais, mais, _apparement_, ça pose pas de problème
dans le test que j'ai fait, ça m'a surpris.

C'est le propre des comportements indéfinis. Ils peuvent marcher
de temps en temps aussi. Typiquement, ils marchent pendant tous
vos tests, mais provoquent un crash du système le jour de la
grande démo devant le client.

Quote:

Pourquoi pas ? Tu n'as utiliser que 0 (avec un type int).

En fait, à quelques exceptions près, les contrôles d'accès se
portent surtout sur les noms. L'exemple classique, c'est avec un
membre de donnée privé -- tu ne peux pas le nommer, pour y
accéder directement, mais tu peux bien y accéder à travers d'un
pointeur ou d'une référence, ou même d'un pointer à membre.

Quote:

Pour le typedef je pense qu'il y a une histoire d'alias,

Tout à fait. La signature de la fonction contient « int » ; il
n'y a pas de type MonType1.

Quote:

mais pour Test2, j'ai un cast implicite en MonType2 * qui est
fait, hors je n'ai pas le droit d'utiliser MonType2.

Tu n'a surtout pas droit à utiliser le nom MonType2. (C'est plus
complexe que ça, évidemment, mais en gros...) Mais par exemple,
tu aurais pu écrire :

class A
{
// comme ci-dessus ...
public:
static MonType2 x ;
static MonType2 y ;
} ;

a.Test2( &A: Mad

) ;

Tu n'a pas accès au type, mais tu as bien accès aux variables du
type, ou aux fonctions qui utilisent le type.

Quote:

surtout que je découvre une nuance entre le bon vieux cast C
qui est interdit (?) et static_cast / reinterpret_cast (!) qui
sont eux autorisés:

a.Test2( static_cast<A::MyType *>( 0 ) ); // OK
a.Test2( reinterpret_cast<A::MyType *>( 10 ) ); // OK
a.Test2( (A::MyType *)( 0 ) ); // ERREUR

Je suppose que tu veux dire A::MonType2 dans tous les casts.
Sinon, je ne connais pas de compilateur qui accepterai aucun des
trois.

Quote:

Pourquoi le cast C++ est-il autorisé ?

Parce qu'il y a un bug dans ton compilateur ?

En gros (et peut-être à des exceptions près), ce que fait le
complateur, c'est :

-- il recherche le nom que tu as écris, et le « lie » à une
déclaration, sans tenir compte de l'accès,

-- il vérifie l'accès -- si tu n'y a pas le droit, c'est une
erreur, et finalement,

-- il interprète la sémantique de ce que tu as écris.

La première phase comprend aussi la résolution du surcharge, le
cas échéant.

Note bien comment ça s'applique à ton exemple « a.Test2( 0 ) ».
Il n'y a aucun problème avec la première phase, évidemment ; le
compilateur trouve des liaisons (des « bindings ») non ambigus
pour tous les symboles dans l'expression. Ni avec la deuxième,
non plus -- tous les liaisons s'attache à des noms publiques.
Dans la troisième phase, il interprète la sémantique, ce qui
fait bien intervenir le type MonType2, mais il a déjà fini avec
la vérification des accès. Et lui (le compilateur), évidemment,
connaît MonType2. Donc, pas de problème.

Quand tu écris la conversion de façon explicite, c'est autre
chose. Le compilateur fait bien la recherche et la liaison du
nom MonType2, et alors, ensuite, il vérifie les droits d'accès.
Et puisque tu n'as pas le droit d'utiliser ce symbol, il râle.
Ou au moins, il doit râler.

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

Aurélien REGAT-BARREL
Guest

Posted: Tue Apr 05, 2005 8:02 am Post subject: Re: Questions tordues

Quote:

Lorsque je mets MonType2 à la place de MyType, aucun de ces 3 casts
ne compile chez moi avec gcc 3.4.1 (dans un fonction non-membre -
en l'occurrence main()), tout comme il se doit.

Oui je me suis trompé en copiant-collant, c'est MonType2:

class A
{
private:
typedef int MonType1; // types privés
class MonType2 {};

public:
void Test1( MonType1 );
void Test2( MonType2 * );
};

int main()
{
A a;
a.Test1( 0 ); // OK
a.Test2( 0 ); // OK
a.Test1( static_cast<A::MonType1>( 0 ) ); // `class A::MonType1' is
private
a.Test2( static_cast<A::MonType2*>( 0 ) ); // `class A::MonType2' is
private
}

effectivement j'avais pas testé avec gcc, ça cause une erreur. C'est aussi
le vas avec VC++ 8 ("cannot access private class declared in class 'A'"),
mais VC++ 7.1 laisse passer.
Mais je comprends toujours pas pourquoi le 0 passe. Pour moi, les 2 lignes
étaitent équivalentes (0 avec et sans cast), car il y avait cast implicite.
Je pensais que le compilo considérait 0 comme un MonType1 / MonType2*
initialisé à 0, mais apparement non. Comment ça marche ? Où a lieu le cast
implicite ?

--
Aurélien REGAT-BARREL

Aurélien REGAT-BARREL
Guest

Posted: Tue Apr 05, 2005 8:40 am Post subject: Re: Questions tordues

Quote:

Pourquoi le cast C++ est-il autorisé ?

Parce qu'il y a un bug dans ton compilateur ?

Oui, VC++ 7.1 en l'occurence. C'est corrigé dans VC++ 8 Beta 1.

Quote:

En gros (et peut-être à des exceptions près), ce que fait le
complateur, c'est :

-- il recherche le nom que tu as écris, et le « lie » à une
déclaration, sans tenir compte de l'accès,

-- il vérifie l'accès -- si tu n'y a pas le droit, c'est une
erreur, et finalement,

-- il interprète la sémantique de ce que tu as écris.

La première phase comprend aussi la résolution du surcharge, le
cas échéant.

Mais l'origine de ma question c'est le cast implicite, il est effectué quand
? Après la vérification d'accès apparement.
L'exemple suivant semble le confirmer:

class A
{
private:
struct MonType
{
MonType( int ) {}
};

public:
void Test( const MonType & ) {};
};

int main()
{
A a;
a.Test( int( 0 ) ); // OK
}

c'est ce qui me surprend, car j'arrive à instancier un type privé depuis
une fonction non membre...

Quote:

Note bien comment ça s'applique à ton exemple « a.Test2( 0 ) ».
Il n'y a aucun problème avec la première phase, évidemment ; le
compilateur trouve des liaisons (des « bindings ») non ambigus
pour tous les symboles dans l'expression. Ni avec la deuxième,
non plus -- tous les liaisons s'attache à des noms publiques.
Dans la troisième phase, il interprète la sémantique, ce qui
fait bien intervenir le type MonType2, mais il a déjà fini avec
la vérification des accès. Et lui (le compilateur), évidemment,
connaît MonType2. Donc, pas de problème.

Ok. Je pensais que c'était un peu plus élaboré et qu'il faisait le cast
implicite au moment de la recherche de binding. D'ailleurs, je vois pas trop
comment il peut le faire après s'il est capable de trouver des bindings
ambigus à ce moment là. Dans l'exemple ci-dessus, comment peut-il trouver la
liaison entre int( 0 ) et A::MonType sans faire de cast lors de la phase 1 ?
Et s'il fait le cast, pourquoi la phase 2 ne le contrôle pas ?

Quote:

Quand tu écris la conversion de façon explicite, c'est autre
chose. Le compilateur fait bien la recherche et la liaison du
nom MonType2, et alors, ensuite, il vérifie les droits d'accès.
Et puisque tu n'as pas le droit d'utiliser ce symbol, il râle.
Ou au moins, il doit râler.

--
Aurélien REGAT-BARREL

kanze@gabi-soft.fr
Guest

Posted: Tue Apr 05, 2005 10:11 am Post subject: Re: Questions tordues

Aurélien REGAT-BARREL wrote:

[...]

Quote:

C'est de l'interprètation sémantique. Il n'entre en jeux qu'une
fois que le compilateur essaie d'évaluer ce que signifie
l'expression. Qu'il a donc fait la liaison de tous les symboles,
et en a validé la légalité de l'accès.

Quote:

Après la vérification d'accès apparement. L'exemple suivant
semble le confirmer:

class A
{
private:
struct MonType
{
MonType( int ) {}
};

public:
void Test( const MonType & ) {};
};

int main()
{
A a;
a.Test( int( 0 ) ); // OK
}

c'est ce qui me surprend, car j'arrive à instancier un type
privé depuis une fonction non membre...

Une fois de plus : les droits d'accès portent sur le nom. Il y
beaucoup de façons à accéder à des membres privés : par un
pointeur ou une référence, par exemple, ou si une fonction
virtuelle est privé dans la classe dérivée, mais publique dans
la classe de base.

Quote:

Globalement, je ne crois pas que ça serait possible. Dans le cas
général, il faut qu'il ait fait les bindings pour savoir s'il
faut un cast.

Quote:

D'ailleurs, je vois pas trop comment il peut le faire
après s'il est capable de trouver des bindings ambigus à ce
moment là. Dans l'exemple ci-dessus, comment peut-il trouver
la liaison entre int( 0 ) et A::MonType sans faire de cast
lors de la phase 1 ?

Il n'y a pas de liaison entre int( 0 ) et A::MonType lors de la
phase 1. Les paramètres n'entrevient pas dans la résolution du
name binding. Lors de la phase 1, le compilateur associe A à la
définition de la classe, MonType à la déclaration de la fonction
qui se trouve dans A, et int à un mot clé. Chacun séparément.
(Évidemment, ce n'est pas 100% séparément, parce qu'après A::,
il ne va chercher MonType que dans la portée désignée par A.
Mes ça se limite à des opérations qui jouent sur la portée.)

Dans le cas du surcharge des fonctions, on a un cas spécial
(avec beaucoup de règles spéciales) qui permet un binding à un
ensemble de déclarations dans la première phase -- mais même là,
il y a des limites, et il faut que 1) tous les déclarations
soient dans la même portée, et que toutes les déclarations
déclarent des fonctions. Mais l'essentiel reste. Le compilateur
effectue le binding symbole par symbole, sans régarder le
contexte autour du symbole. (Il y a une ou deux exceptions, je
crois -- surtout un hack pour la compatibilité C, mais ils
n'entrent pas en jeu ici.)

Quote:

Et s'il fait le cast, pourquoi la phase 2 ne le contrôle pas ?

Parce que la résolution du surcharge n'a lieu que dans la phase
3. Avant la phase 3, le compilateur n'a aucune idée sur le type
ou le nombre de paramètres de la fonction. Tout ce qu'il sait,
c'est où trouver la déclaration de la fonction quand il en
aura besoin.

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

Aurelien REGAT-BARREL
Guest

Posted: Tue Apr 05, 2005 5:54 pm Post subject: Re: Questions tordues

Ok tout est clair. Merci beaucoup pour ces explications. -- Aurélien REGAT-BARREL

Display posts from previous:

	C++Talk.NET Forum Index -> C++ (French)	All times are GMT
Page 1 of 1

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum