Discussion :

[Invit�]

Bonjour,
J'ai une fonction qui prend en param�tre un LPVOID soit un char* ou voir unsigned char* pour �crire dedans (me renvoy� le resultat)

J'aimerais bien utilis� le string ici pour pas a avoir a utilis� malloc free etc donc comment je peut faire �a depuis un string ? comment la fonction peut m'�crire dans mon std::string ?

si c'est trop compliqu� je vais utilis� un char* et puis c'est tout...

[Bousk]

Salut,

on a beau attendre un char*, utiliser string n'est pas la bonne chose � faire.
Ce qu'il faut utiliser c'est vector ou array.

[dalfab]

Bonjour,

une std::string n'est pas adapt�e pour servir de buffer de r�ception. Des optimisations internes font que m�me si la destination finale est une std::string, il est plus optimum de passer par un interm�diaire.
Le buffer LPVOID doit avoir une taille pr�conis�e maximum, dans ce cas un simple tableau doit �tre utilis�, il faut �viter les allocations m�moire.

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
constexpr size_t LgMax = 100;
std::array<char,LgMax> buffer;
fonction( buffer , buffer.size() );  // requête fonction C en indiquant la taille max
// après contrôle que tout est okay
std::string str_result{ buffer.data() };
// ou si la fonction a retourné la longueur lg, on peut aussi faire
str.assign( buffer.begin() , buffer.begin()+lg );

[koala01]

Salut,

il faut �viter les allocations m�moire.

Je suis tout � fait d'accord avec le principe, mais encore faut il voir la taille du tampon...

Si cette taille est de "quelques dizaines" de bytes, le fait d'�viter l'allocation de m�moire ne devrait pas poser de probl�mes (� moins, bien sur, d'en arriver � multiplier les tampons, dans un appel r�cursif qui nous aurait �chapp�, par exemple).

Mais, d�s que la taille du tampon devient "trop importante" (ne serait-ce que 65 535 -- voire moins (16 mille et une fafiote )-- qui correspond, en gros, � la valeur maximale repr�sentable � l'aide d'un short), je crois quand m�me que l'utilisation d'un std::vector se justifie pleinement pour �viter les stack overflow...

[camboui]

Cette discussion soul�ve toute la difficult� � m�langer du C++ avec C

Mais il y a des solutions et les gourous qui pensent le C++ ont enfin trouv� la parade
Je prends donc les autres intervenants � contre-pied pour affirmer que, oui, on peut utiliser std::string pour appeler une fonction qui demande un char *.
C'est ainsi que depuis C++17 la methode data() est (enfin !) d�clin�e en une deuxi�me version non const qui renvoit un char *.

Perso j'utilise depuis tr�s longtemps du code dans ce genre avec succ�s:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
std::wstring StrDateTime(bool localtime)
{
	SYSTEMTIME st;
	if (!localtime)
		GetSystemTime(&st);
	std::wstring sdt(31, '\0');
	int len = GetDateFormatEx(
		LOCALE_NAME_INVARIANT, 0ul, localtime ? NULL : &st,
		L"yyyy'-'MM'-'dd ", &sdt[0], (int)sdt.size(), NULL) - 1;
	len += GetTimeFormatEx(
		LOCALE_NAME_INVARIANT, 0ul, localtime ? NULL : &st,
		L"HH':'mm':'ss", &sdt[len], (int)sdt.size() - len) - 1;
	sdt.resize(len);
	return sdt;
}

Il suffit d'�tre prudent et bien comprendre ce que fait la fonction qui demande un char *

[M�dinoc]

Mais est-ce que la plate-forme sur laquelle imprimante compile supporte C++17, l� est la question.

[Wankyx]

On peut pas utiliser la propriet� de c_str() de l'objet string ?

[Luc Hermitte]

Je r�sume.

Deux cas de figure => deux solutions.
1- Si ta fonction lit l'information derri�re le pointeur sans la modifier -> std::string::c_str().

2- Si ta fonction re�oit une chaine que tu dois stocker quelque part, alors d�finis un vecteur (si la taille est dynamique) (ou un std::array sinon), dimensionne le comme il se doit et lis dedans � partir de data(v), ou &v[0], ce qui est pareil ici. Tu pourras ensuite convertir ton tableau en std::string si tu le souhaites/en as besoin -- voire en std::string_view (C++17) ce qui sera plus efficace selon ce que tu fais de la chaine ensuite.

[koala01]

C'est ainsi que depuis C++17 la methode data() est (enfin !) d�clin�e en une deuxi�me version non const qui renvoit un char *.

Oui, enfin, l'utilisation de data() au lieu de c_str() ne va r�soudre qu'une partie du probl�me, et en ignorer royalement deux autres:
D'un cot�, data() permet, effectivement, de fournir un char * dont le contenu peut �tre modifi� par une fonction C, mais

1. la fonction qui re�oit ce char * doit veiller � ne pas d�passer la taille du tableau qu'il repr�sente et
2. l'id�e de ce char * reste de repr�senter ... une chaine de caract�res. Or, un tempon peut envisager d'utiliser -- par exemple -- quatre byte pour repr�senter un (unsigned) int, et la valeur de ce (unsigned) int (*) pourrait tout � fait contenir un ou plusieurs byte(s) nul(s) et / ou correspondant � un / des caract�re(s) particulier(s) (typiquement : n'importe quel caract�re dont la valeur est comprise entre 0 et 31 inclus)

(*) le tout, sans m�me consid�rer le probl�me du boutisme utilis� pour la repr�sentation de cette valeur.

Nous sommes bien d'accord sur le fait que le premier point soulev� ici est commun � std::string et � std::vector</*unsigned*/ char>.

Mais le gros probl�me viendra du deuxi�me point, sp�cifique � l'utilisation de std::string, qui consid�rera forc�ment chaque byte comme un caract�re, et qui l'interpr�tera en cons�quence.

C'est sans doute la raison qui a fait que, nous disposons , depuis C++17, de std::byte qui nous permet justement d'�viter la confusion entre la valeur num�rique d'un caract�re et son interpr�tation ASCII.

Et c'est la raison pour laquelle, quitte � avoir un tampon "de taille fixe" (� l'ex�cution), il est largement pr�f�rable d'opter pour std::vector<std::byte> si la taille du tampon est d�finie � l'ex�cution ou pour std::array<std::byte, taille_predefinie> si la taille peut �tre d�finie � la compilation et qu'elle ne pose pas de probl�me en terme d'utilisation de la pile.