Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Langage C++ Reinterpret_cast ?

Reinterpret_cast ?

14 réponses
Avatar
Olivier Bruckner
Bonjour,

Je souhaites rendre du code écris en C, compilable par un compilateur
C++ (VC++ 2003).

Au sein d'une fonction j'ai le code suivant:

[...]

// le proto fe G_Alloc
// void G_Alloc(int size);

bot_state_t *bs;

if (!botstates[client])
botstates[client] = G_Alloc(sizeof(bot_state_t));

bs = botstates[client];

[...]

lors de la compilation j'obtiens le message d'erreur suivant:

error C2440: '=' : cannot convert from 'void *' to 'bot_state_t *'
Conversion from 'void*' to pointer to non-'void' requires an
explicit cast

J'utilise donc reinterpret_cast (pointeur sur un pointeur d'un autre
type si je ne me trompe pas) j'écris donc le code suivant:

[...]

bot_state_t *bs;

if (!botstates[client])
botstates[client] =
G_Alloc(sizeof(reinterpret_cast<int*>(bot_state_t))); // je suis sur de
me tromper dans l'écriture...

bs = botstates[client];

[...]


et là j'obtiens ce message d'erreur:

error C2226: syntax error : unexpected type 'bot_state_t'

Je me demande si vous pouvez m'éclairer sur ces convertions C/C++,
pourquoi le compilateur en a t'il besoin ?

Je vous remercie.
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2
Avatar
Fabien LE LEZ
On Wed, 22 Sep 2004 04:33:43 +0200, Olivier Bruckner
:

G_Alloc(sizeof(reinterpret_cast<int*>(bot_state_t)));

// je suis sur de me tromper dans l'écriture...


Je confirme.

reinterpret_cast<int*>(G_Alloc(sizeof(bot_state_t)));

--
;-)

Avatar
mmm
ou plus simple:
botstates[client] = (bot_state_t*)G_Alloc(sizeof(bot_state_t));
(je suis un feignant ;-) et j'aime pas les machin_cast :-) )

"Fabien LE LEZ" a écrit dans le message de
news:
On Wed, 22 Sep 2004 04:33:43 +0200, Olivier Bruckner
:

G_Alloc(sizeof(reinterpret_cast<int*>(bot_state_t)));

// je suis sur de me tromper dans l'écriture...


Je confirme.

reinterpret_cast<int*>(G_Alloc(sizeof(bot_state_t)));

--
;-)



Avatar
Fabien LE LEZ
On Wed, 22 Sep 2004 05:57:34 +0200, "mmm" :

et j'aime pas les machin_cast


Hum... Ce genre de réflexions en C++, avec en plus une réponse à
l'envers... ça s'appelle un troll, c'est bien ça ?
Dire que l'espace d'un instant, j'ai failli y tomber :-/


--
;-)

Avatar
mmm
Intelligent...
Réponse à l'envers? précise mon ami

Pas mal pour une première tentative de participation à ce forum... je suis
ravi...

"Fabien LE LEZ" a écrit dans le message de
news:
On Wed, 22 Sep 2004 05:57:34 +0200, "mmm" :

et j'aime pas les machin_cast


Hum... Ce genre de réflexions en C++, avec en plus une réponse à
l'envers... ça s'appelle un troll, c'est bien ça ?
Dire que l'espace d'un instant, j'ai failli y tomber :-/


--
;-)



Avatar
Fabien LE LEZ
http://www.giromini.org/usenet-fr/repondre.html

--
;-)
Avatar
Horst Kraemer
Olivier Bruckner wrote:

Bonjour,

Je souhaites rendre du code écris en C, compilable par un compilateur
C++ (VC++ 2003).

Au sein d'une fonction j'ai le code suivant:

[...]

// le proto fe G_Alloc
// void G_Alloc(int size);


Probablement

void * G_Alloc(int size);

pourquoi ne pas copier le texte littéral ?


bot_state_t *bs;

if (!botstates[client])
botstates[client] = G_Alloc(sizeof(bot_state_t));


botstates[client] (bot_state_t*)G_Alloc(sizeof(bot_state_t));

ou bien

botstates[client] static_cast<bot_state_t*>(G_Alloc(sizeof(bot_state_t)));


bs = botstates[client];

[...]


--
Horst

--
Lâche pas la patate!

Avatar
Loïc Joly
mmm wrote:

ou plus simple:
botstates[client] = (bot_state_t*)G_Alloc(sizeof(bot_state_t));
(je suis un feignant ;-)


Moi ausi, comme tout bon développeur

et j'aime pas les machin_cast :-) )


Pas moi. On peut objectivement trouver des avantages aux machin_cast,
comme par exemple le fait de mieux discerner de quel type de cast il
s'agit, le fait de permettre des choses que les anciens casts ne
permettent pas d'écrire, le fait d'être plus facilement grepables, soit
par un outil informatique, soit quand on parcours le code.

Peux-tu expliquer quels avantages tu vois aux anciens casts ?

--
Loïc

Avatar
mmm
"Fabien LE LEZ" wrote:
[...] en plus une réponse à l'envers...[...]

http://www.giromini.org/usenet-fr/repondre.html

--
;-)


Euh... merci :-) ... je recommencerai plus ;-)
Côté usenet je suis un newbie, veuillez m'en excuser.

Avatar
Fabien LE LEZ
On Wed, 22 Sep 2004 08:41:15 +0200, "mmm" :

Côté usenet je suis un newbie


Dans ce cas, j'en profite aussi pour te filer l'URL de la FAQ, au cas
où tu l'aurais ratée :
http://www.cmla.ens-cachan.fr/Utilisateurs/dosreis/C++/FAQ/

--
;-)

Avatar
mmm
"Loïc Joly" wrote:

et j'aime pas les machin_cast :-) )


Pas moi. On peut objectivement trouver des avantages aux machin_cast,
comme par exemple le fait de mieux discerner de quel type de cast il
s'agit, le fait de permettre des choses que les anciens casts ne
permettent pas d'écrire, le fait d'être plus facilement grepables, soit
par un outil informatique, soit quand on parcours le code.

Peux-tu expliquer quels avantages tu vois aux anciens casts ?


J'aurai pt etre même du commencer par ça ;-), déjà je dois avouer une chose,
j'ai commencé par le C, et je n'ai passé que qq petits jours à essayer les
..._cast(:-)) mais j'ai désormais une bonne experience en C++, et mon boulot
consiste essentiellement ds le dev de lib c++, et outils de dev divers.
Je m'explique pr les casts:

Dans un contexte de dev où les exceptions c++ sont utilisées
systématiquement en tant que système de gestion d'erreur global (erreurs
systèmes aussi bien qu'erreurs utilisateurs, la moindre fct peut renvoyer
une exception ou presque y compris les ctor d'objets, ...), où le multi
threading est lui aussi omniprésent, où les composants utilisés par l'appli
peuvent être déchargé, mis à jour à chaud, ... en gros où quasi rien n'est
linéaire, où la durée de vie des objets manipulés n'est garantissable qu'a
l'aide entre autre d'un système de ref count, où tout ou presque est
modulaire, ... pr moi le rève :-):
Les mécanismes du type dynamic_cast<type> sont de peux d'utilité, autant se
faire ses propres templates en utilisant une technique simili com (addref,
release, queryinterface, ... pointeurs observer<>, addrefer<>, ...) y
compris pour les objets sans ref count (getinterface) qui balance des
exceptions en cas de pb.

Les cast C je ne les utilise principalement que pour caster de void* <->
type* et en règle général quand je veux blouser le compilo mais j'évite
grave, il y a quelque rares cas(pr moi) où static_cast peut se réveler
indispensable (ex: cast d'une interface particulière/héritage multiple
basique d'une classe vers un truc style void** pr pas que le compilo
s'emmèle les pédales, le seul endroit où j'utilise ce type de cast).
Et l'intérêt du reinterpret_cast j'en vois pas, si ce n'est ce que tu
disais, le côté "grepable", qui peut être effectivement important, mais les
cast C à condition d'être "propre" peuvent l'être aussi (bon par type :-)
mais perso j'ai jamais eu à faire ça et c'est plus du à des carrences de nos
env de dev).
Les cast C sont, par contre relativement dangereux, et lorsqu'un peu plus de
contrôle serait bienvenu, les cast c++ ne me paraissent pas à la hauteur de
la tâche (ex: si en plus de la longueur de la syntaxe, je dois me taper le
test du retour pour balancer une exception au cas où la classe demandée
n'est pasdispo, ben je préfère refaire le truc...;-) ) .
En ce qui concerne la lisibilité, ayant une longue experience des languages
type syntaxe C, j'aime pas trop les languages trop littéraux (type vb,
cobol, pascal...), question de goût ou d'habitude, j'ai du coup plus de mal
à lire un truc du style reinterpret_cast<int*>(arg) que ça: (int*)arg.

En gros, pr moi l'idée est bonne, mais ça en fait trop peu, et ce serait
surtout intéressant si l'héritage multiple, le vrai (pas celui qu'avec une
classe de base et plein d'interface: ça c'était facile à gérer) marchait...
Si le c++ offrait un peu plus de possibilité pour le rendre un peu moins
statique (style: rtti améliorés permettant d'énumérer les membres d'une
instance de classe, ..., etc...) Pr moi ça fait parti des quelques pans du
C++ qui malheureusement ne sont pas terminés et sont à priori pas prêt de
l'être vu l'évolution de la norme, à quand le D++ ? :-)

Dans le même ordre d'idée j'ai banni l'utilisation des infos rtti de mes
sources, après avoir vu les faibles possibilités que ça offrait et que ça ne
me permettait pas de me passer ni même de simplifier mon propre système
d'info dynamique (class factory, publication de c++ pr du scripting, ...).

La question pr moi finalement ce serait plutôt: Quels avantages apportent
réellement les nouveaux cast, les infos rtti par rapport aux cast C, aux
"rtti à la mimine" dans le cadre des possibilités que nous offre aujourd'hui
nos machines, de l'évolution du dev en général, vu de ma lorgnette, où l'on
a de plus en plus besoin à la fois de dynamicité et de staticité (ex:
scripting embarqué ds une appli de gestion, avec pq pas un système de
plugins bdd, support d'images, modules métiers fournis par des boites
externes, ...) ?.

Voili, allez au boulot feignant ! (prenez le pas mal: je parle pr moi :-))


1 2