oui mai : la j’ai un souci qui ce rajoute aux premier:
je me construis une class dédier aux conversion de type . (je passe sur le comment et le pourquoi)
la déclaration ce fait :
char * StringChar( std::string & my_string);
puis la fonction
char * cConvType::StringChar( std::string & my_string){
// créer le buffer pour copier la chaîne
size_t size = my_string.size() + 1;
char * buffer = new char[ size ];
// copier la chaîne
strncpy( buffer, my_string.c_str(), size );
// utiliser le buffer
std::cout << buffer << '\n'; // "une chaîne de caractères"
// libérer la mémoire
delete [] buffer;
return buffer;
}
donc évidement le delete est mal placer … on fait comment ? je le place dans le destructeur de la classe ?
je voudrai donc convertir mai string de façon a ce que basic_connections puisse le recevoir
ma string.
Ma fonction renvoiye un char *, et je suppose qu’il faudrait un char [] ?
bon la lib permet d’utiliser aussi basic_connection (const std::string &opt), mai bon je préfèrais savoir comment faire pour résoudre les 2 problèmes des fois que dans le future cela ne soie pas possible.
je resume
problème avec delete ?
faire une fonction de conversion string pour utiliser basic_connection (const char opt[]) ?
const char* to_char(std::string str)
{
using namespace std;
char* ret = new char[str.size()];
copy(str.begin(), str.end(), ret);
return ret;
}
}
int main(void)
{
using namespace std;
string coucou (“hello world !”);
afficher(to_char(coucou));
return 0;
}[/code]
Mon programme d’exemple a une memory leak (donc ne pas utiliser tel quel), en principe avec un smart pointer ça devrait pouvoir se régler mais je laisse quelqu’un qui touche un peu mieux le c++ que moi expliquer comment.
Je crois qu’il y a pas beaucoup de choix, le mieux si c’est possible c’est de taper dans les smart pointers C++11 (par exemple std::unique_ptr). Malheureusement j’ai pas vraiment eu l’occasion de m’y plonger donc je peux pas en dire beaucoup plus dessus, si ce n’est que std::unique_ptr est censé s’utiliser comme std::auto_ptr (move semantics).
En C++11 je crois aussi qu’on peut allouer sur la pile des tableaux dont la taille est définie par une variable (alors qu’en C++03 ça n’était possible qu’avec une constante connue à la compilation), ce qui évite d’avoir à gérer le delete[]. À vérifier, même si je ne mentionnerais pas cette possibilité si j’étais pas quasiment sûr de mon coup.
Par contre en C++03 std::auto_ptr<type[]> NE FONCTIONNE PAS (aucune spécialisation sur les tableaux, il utilise systématiquement delete et non pas delete[]), faut utiliser un std::vector si tu veux pouvoir gérer un tableau (ou bien créer une classe RAII spécifique).
Boost a aussi boost::scoped_array et boost::shared_array mais avec les contraintes équivalentes à boost::scoped_ptr (non-copiable) et boost::shared_ptr (ref-counted), c’est pas toujours ce qu’on veut.
@panthere : mis à part cette histoire de memory leak, les deux exemples de MisterFreez sont la “bonne” façon de faire, selon que tu as besoin de la chaîne ponctuellement ou que tu as besoin de la recopier.
Perso dans le deuxième cas (copie) j’utiliserais plutôt memcpy(buffer, str.c_str(), size) car y’a rien de moins sûr que le compilateur arrive à optimiser std::copy aussi efficacement que memcopy l’est. Mais c’est juste de l’optimisation prématurée (celle-là on a droit ).
Personnellement quand je fais du C++ je tente de bannir les méthodes C pour rester au maximum avec une sémantique objet.
Par exemple pour copy/memcpy, je pense que copy peut utiliser la sémantique move ce qui le rendrait plus performant.
Pour le reste c’est de la microoptimisation et il n’y a que si je vois que c’est un point de contention que je regarderais de plus prêt (mais si tu dois convertir des std:string en char* plusieurs milliers de fois par seconde le problème ne se trouve peut être pas dans la méthode de conversion …).
Le C++ étant justement un langage multi-paradigmes (contrairement au Java qui est exclusivement orienté objet si je ne m’abuse) je ne vois pas vraiment l’intérêt de faire des contorsions pour rester en objet quand l’équivalent procédural est tout aussi compréhensible et facile d’emploi, d’autant que la fonction en question fait explicitement partie du standard* (tiens ça me fait penser qu’il faut que j’achète le nouveau et, pire, que je le lise ). Pas plus que ça ne me dérange de mélanger joyeusement objet, procédural, fonctionnel, impératif et macros en Lisp : c’est un peu prévu pour.
Tant que le code est clair, pourquoi se priver d’un outil s’il est plus adapté à un usage donné ? Je vais mettre ça sur le compte de la rigidité de Java qui te donne des mauvaises habitudes, cf. « les méthodes C ». (râle pas c’est une boutade )
Cela dit ça dépend aussi du contexte. Je n’ai aucun remords à utiliser des fonctions C pour manipuler des chaînes C, mais tu me verras jamais faire ce genre de trucs par exemple pour copier un std::vector (et comme tu le dis si bien, si point de contention il y a alors faut revoir l’archi en priorité). Le tout est d’utiliser les choses à bon escient.
(*) si je voulais troller je dirais que ça en fait une fonction C++ et non pas C. Heureusement c’est pas encore le bon jour.
J’accuse mes vieux restes d’assembleur ! Ça a la vie dure ces p’tites bêtes.
Le C++ étant justement un langage multi-paradigmes (contrairement au Java qui est exclusivement orienté objet si je ne m’abuse) je ne vois pas vraiment l’intérêt de faire des contorsions pour rester en objet quand l’équivalent procédural est tout aussi compréhensible et facile d’emploi, d’autant que la fonction en question fait explicitement partie du standard* (tiens ça me fait penser qu’il faut que j’achète le nouveau et, pire, que je le lise ). Pas plus que ça ne me dérange de mélanger joyeusement objet, procédural, fonctionnel, impératif et macros en Lisp : c’est un peu prévu pour.[/quote]
Les macros moins tu y touche mieux tu te porte (aucune vérification du type, possibilité d’ajouter des bugs dans ton code très subtils,…).
D’une part il ne s’agit pas ici de contorsion, vu le profile des deux méthodes.
Mais comme je le disais il est probable que copy utilise des fonctionnalités du langage que le memcpy ignoreras.
D’une manière général (et ce quelque soit le langage), je suis pour fournir un maximum d’informations à mon compilateur/bibliothèque et le fait qu’une adresse est un objet en fait partie, à lui de ne pas y faire attention s’il en a besoin.
D’une part la question n’est pas de se cantonner à un paradigme mais d’en privilégier un. D’autre part j’ai ce comportement depuis mes premières semaines du C++ bien avant de toucher à Java
Mais plutôt ça sur le compte d’un fanatisme pour l’orienté objet (et aussi l’orienté fonctionnel).
Oui quand je fais du C++, je tente de faire d’utiliser au maximum, les fonctions qui me semblent plus dans l’esprit du langage que les méthodes qui me semblent être de l’héritage de C. Quand je manipule des fichiers et dossier, j’utilise des fonctions hérité du C, quand j’écris dedans en principe j’utilise iostream.
J’accuse mes vieux restes d’assembleur ! Ça a la vie dure ces p’tites bêtes. [/quote]
Personnellement, j’aime énormément en informatique le découpage des tâches/problématique. On est capable aujourd’hui, d’écrire du code de haut niveau et de laisser le travail d’optimisation au compilateur/interpréteur. Ce serait dommage de ne pas en profiter. De plus en cas de problème dans ces moulinettes, on peut faire corriger/ajouter des optimisations qui bénéficieront à tous. Note bien que je parle là de microoptimisation, il faut prendre en compte la complexité des algorithme et organiser ces traitements intelligemment.
C’est aussi l’un des trucs qui me fait adorer l’objet. On travail en boite noire. Je n’ai pas à et je ne peux pas aller taper dans l’implémentation de l’objet (oui en C++, Java et python on peut mais bon)(note que OSGi est vraiment l’une des technologies en vogue les plus avancées là dessus avec les bundles qui permettent un vrai cloisonnement). On travail en boite noire. C’est jolie, ça me fait plaisir. Si ton plaisir c’est de faire de l’optimisation tu peut te concentrer dessus, sinon tu utilise.
Enfin, c’est pour ça que j’aime la programmation par contrat comme devrait bientôt le permettre ADA (avec ADA 2012), Java avec JML ou D. On pose des post et des préconditions et des invariants de classe. On sait comment les utiliser et c’est vérifié statiquement si possible.
T’as à peu près tout dit, juste deux petites choses pour finir :
Concernant les macros, je parlais de Lisp ce qui n’a rien mais alors RIEN à voir (mis à part le nom) avec les macros C, c’est de la vraie méta-programmation sans les limites débiles des templates C++ (et j’en ai bouffé des templates… ). C’est un paradigme à part entière, c’est pour ça que je l’ai mis au même niveau que les autres.
Je constate qu’on est encore une fois d’accord sur les généralités. Un jour on arrivera à se comprendre du premier coup, j’en suis sûr. Pourtant j’suis pas compliqué, quand je dis “dans ce cas” faut pas chercher plus loin que ce cas précis.
[size=80](mais je maintiens que je vois mal un compilo arriver à battre une implémentation correcte de memcpy, vu à quel point cette fonction est optimisée)
(comment ça je suis têtu ?) [/size]
Merci pour vos réponse , je vais voir si sa tourne et essayer de comprendre un peux mieux le sujet
sorry pour la réponse tardive mai je suis en vacances en famille
?
).
)
). C’est un paradigme à part entière, c’est pour ça que je l’ai mis au même niveau que les autres.
[/size]
, je vais voir si sa tourne et essayer de comprendre un peux mieux le sujet 
