J´ai oublié pourquoi, mais quelle est la raison pour laquelle il faut utiliser l´opérateur de transtypage : ( char*) devant une chaine de caractère passée en argume genre :

strcmp( *(char*)..., ( char*)... )

Sinon on se paye les warning du compilateur ?

désolé je peux pas t´aider je m´y connais pas en programation. Maiss si c´est du C++ va sur le topic " jaides les personnes en c++" tu aura

tu aura surement des réponses ( désolé pour la coupure)

Personnelement j´ai jamais utilisé d´op de transcryptage ou de cast pour les fonctions de la bibliotheques ( à part malloc bien entendu). Donc si tu en as besoin c´est que ton type de base est foireux.

Si ton argument est de type char* ou const char* alors tu n´a pas de warning. C´est si tu passe un void* que tu auras un warning.

au passage un VRAI operateur de transtypage est en fait une conversion implicite ( operator ( type) ( )) , et non un reinterpret_cast
quant au warning, c´est clair qu´il vient d´une signature mal adaptée..

à moins que tu utilise des string plutot que des char* ?

P.S. pour LGV ou qqn d´autre, le " reinterpret_cast" c´est le compilo qui implémente une conversion entre les type comme il veut ? parce que je suppose que c´est pas terrible comme opération non ?

à moins que tu utilise des string plutot que des char* ?

P.S. pour LGV ou qqn d´autre, le " reinterpret_cast" c´est le compilo qui implémente une conversion entre les type comme il veut ? parce que je suppose que c´est pas terrible comme opération non ?

le reinterpret_cast ne marque que sur des pointeurs, il s´agit simplement de modifier la façon dont il est déréférencer ( donc l´adressage, dans le code généré). C´est standard, y´a pas 50 façons de le faire, et ça ne coute " rien".
p-e que tu voulais parler du static_cast, plutot non ? là il s´agit juste de representer une information codée dans un format donné, dans un autre format : c´est un peu plus couteux selon les types de départ et d´arrivée du cast, mais c´est pas non plus une horreur sans nom. Et au passage ça ne marche que sur des primitifs. En faisant juste qq static cast par-ci par la en se limitant au minimum ( et en exploitant la promotion et conversion implicite de types pour le reste), ça reste tres raisonnable ( si on regarde du code généré, les int => float se font à grand coup de FLD, quand ça reste de meme nature, c´est brutement un mappage de registres à coup d´adressage, seul le float => int demande un peu plus de boulot de par le fait qu´il faut convertir mantisse et exposant)
Reste le const_cast... qui ne fait rien à part permettre au compilo de compiler en le forcant à nous croire sur parole qu´on sait ce qu´on fait en outrepassants des consts
Au final, le plus interessant, le dynamic_cast qui lui est TRES couteux, et qui a besoin des RTTI pour etre fonctionnel. Utile uniquement pour du downcasting au sein d´une hierarchie de classes polymorphes. D´ailleurs c´est tellement couteux que si on peut on remplace par des versions maisons, en calculant le padding et les offset entre des protos de classe pour faire du reinterpret_cast modifié. Bref, là c´est déjà un peu plus amusant :D

( moins les fautes, j´ai du mal on dirait ce soir...)

c pas marrant...
a chaque fois que je post un topic d´aide ya que kelke floodeurs qui repondes
et lui tlm a l´air de comprendre et l´aider lol

je crois que les Qc sont pas tro appréciés sur jv.com...

lgv et dnoob, allez utiliser des string et reinterpret_cast en C ( cf topic) :P

Bon moi je retourne a mon compilo arm qui me renvoie " Warning: reinterpret_cast<>, C++ function not fully implemented"

je crois que les Qc

C´est quoi un QC ?

LGV
´Et au passage [static_cast] ne marche que sur des primitifs.´

Absolument pas.
static_cast<type>(expr) est valide quand type temp(expr) est valide.

LGV
´Au final, le plus interessant, le dynamic_cast qui lui est TRES couteux, et qui a besoin des RTTI pour etre fonctionnel. Utile uniquement pour du downcasting au sein d´une hierarchie de classes polymorphes. D´ailleurs c´est tellement couteux que si on peut on remplace par des versions maisons, en calculant le padding et les offset entre des protos de classe pour faire du reinterpret_cast modifié. Bref, là c´est déjà un peu plus amusant :D´

TRES couteux ? Il ne faut pas exagérer quand même. Il ne faut pas oublier que d´une part le compilateur sait optimiser un code ( et autrement plus efficacement qu´avec des bidouilles), et que d´autre part, les machines d´aujourd´hui tournent à 4Ghz... Donc on peut utiliser les dynamic_cast sans problème de performance.

Merci pour les réponses.
Pour être un peu plus explicite, je dirais que ce problème de warning survient quand j´essaye d´affecter une constante de chaine à un tableau de pointeurs de type char exemple ( et uniquement dans ce cas) :

char *test[] = {"hello"};

le compilo ( GCC 4.0.0) m´oblige à faire précéder la chaine de ( char*) ( bon en fait je pense que c´est assez légitime, mais je ne programmait en syntaxe C que sur des compilos C++ jusqu´à présent.

Par contre, bizarrerie que je ne m´explique pas :

void ProcessCommand( const char *cmd )
{
char *current = strtok( cmd, ( char*)" " ) ;
. .. / /etc
}

Je me prends un warning sur la ligne avec strtok : " discards qualifier from pointer target type" si je mets cmd sans ( char*) avant...

Pourtant strtok attends bel et bien un char*... la je ne vois pas...

QC c´est un quebecois ^^

Tu crois vraiment qu´on fait la difference frag21 ? ?

Tu crois franchement qu´avant de te répondre on regarde ta carte de visite pour voir d´ou tu viens?

kUfa : vi, j´ai bien vu qu´on était en C, mais avouons que le ( cast) du C correspond aux équivalents static ou reinterpret du C++. C´est juste pour clarifier un peu de quoi on parle donc Et arrete de te plaindre de ton compilo, le mien pour PS2 n´est pas mieux LOL ; )

Blawk :
" static_cast<type>(expr) est valide quand type temp(expr) est valide."
C´est exactement pour la meme raison que je dis que le static cast ne marche effectivement que sur des primitifs. Il n´y a QUE sur des primitifs qu´un static_cast génére effectivement du code qui correspond à une conversion. Si la syntaxe est bonne pour tout type supportant la conversion, il n´y a pas cast pour autant : sur des non-primitifs ça se résume à un gros " call @" en sortie.
C´est comme quand on fait " int a(1);" ; c´est valide ( et pratique parfois), c´est pas pourtant qu´il y aura construction ( au sens appel de constructeur).

" TRES couteux ? [...] Il ne faut pas oublier que d´une part le compilateur sait optimiser un code ( et autrement plus efficacement qu´avec des bidouilles)"
Je suis entierement d´accord... en ce qui concerne les architectures ! ! Je n´écris que tres rarement du code en ASM ( si ce n´est un peu de SSE ici ou là...), ou prenant en compte le netburst, ou autre. Parce que je suis entièrement conscient que le compilo bien a bien mieux connaissance de l´architecture que moi ( c´est de plus en plus vrai, notamment vu la complexité des archis des derniers processeurs).
Mais concernant les MECHANISMES softwares tu es bien mieux placé en tant que programmeur pour savoir exactement ce dont tu as besoin. As-tu besoin de la prise en main des exceptions, si tu ne t´en sers pas et ne fais aucun throw/catch ? Non. Donc on le active pas. Pareil pour du dynamic_cast : as-tu besoin de toutes les infos des RTTI dans ton programme ? La réponse est généralement non, d´où l´interet de mettre en place un méchanisme alternatif qui ne realise que ce dont tu as besoin.

" les machines d´aujourd´hui tournent à 4Ghz... Donc on peut utiliser les dynamic_cast sans problème de performance"
Qu´on ait 4GHz ou pas, on aime en profiter au maximum, surtout pour des jeux, non ?
Je le vois sur des PS2 ( 233Mhz), je le vois sur des XBox ( 700 Mhz), je le vois sur des PC ( ~2-3Ghz en moyenne actuellement), je l´ai vu sur des simus militaires ( cluster de 32 bi-xeon) : dans tous les cas, on cherche à tirer de toute la puissance disponible.
Le dynamic_cast COUTE, c´est indéniable ! Ca coute de la mémoire, et ca coute de la puissance : si on le sait et qu´on s´en satisfait, tres bien, on s´en sert en toute conscience de cause, et il n´y a rien à redire. Mais il faut aussi savoir que la mise en place de solutions maisons est chose courante ( toutes les machines actuelles sont loin d´avoir la puissance des PC standard, ni surtout la mémoire -hmmm la PS2 avec ses 32Mo-, et certains compilos ne supportent pas les RTTI)

intercalaire :

proto de strtok :

char *strtok(
char *strToken,
const char *strDelimit
) ;

ton cmd est un const char * ; il est naturel de passer un non-const où est attendu un const, mais l´inverse n´est pas vrai