std::fill vs memset pour les structures.

Version imprimable

06/10/2008, 10h10
zenetcalme

std::fill vs memset pour les structures.
Bonjour,

Je viens d'apprendre que "memset" dans du code "c++", il faut éviter!:koi:
"std::fill" serait la pour le remplacer.

j'essaye, mais je bloque a ce niveau:
Code:

1 2 3 4 5 6 typdef struct { int a; char b[125]; unsigned long c; }MaStruct;
comment dois je ecrire le std::fill?
pour l'instant, j'ai fait:
Code:

1 2 MaStruct Test[5]; std::fill(Test,Test+5, 1);
ps: je remplie de 1 car mon déboguer initialise tout à 0...

Merci d'avance,
06/10/2008, 10h41
Médinoc

std::fill(), c'est une fonction template: Elle ne fera pas l'équivalent de memset, car ce que fait memset() n'est pas type-safe.
06/10/2008, 10h48
zenetcalme

heuuuu... oui!!!!:roll:

Donc, j'utilise std::fill juste pour les tableaux, les 'vector', etc, mais pas pour les structures?
06/10/2008, 11h56
Médinoc
Tu peux utiliser fill() pour les structures, mais ça ne marche pas comme ça. fill() prend un objet du bon type en paramètre:
Code:

1 2 3 MaStruct Test[5]; MaStruct init = {42, "toto", 0x12345678}; std::fill(Test,Test+5, init);
06/10/2008, 12h15
loufoque

std::fill n'initialise pas la mémoire, mais les objets.
06/10/2008, 20h07
Davidbrcz

je me permet de renvoyer vers ce billet d'emmanuel deloget:
http://blog.emmanueldeloget.com/inde...89-c-et-memset
07/10/2008, 08h25
zenetcalme

Merci pour ces infos.

J'avais bien vu le billet d'emmanuel deloget, mais j'ai peut être lu un peu vite!

donc, si j'ai bien tout compris:
- memset : initialise la mémoire en direct.
- std::fill : init les objet ( du std::vector, à nos propres classes!)

memset à encore de beau jours devant lui dans mon code!
je garde quand même a l'esprit de ne PAS le faire quand ma structure ne contient pas que des membres POD.

Merci à tous!:king:
07/10/2008, 10h29
Sylvain Togni

Citation:

Envoyé par zenetcalme

memset à encore de beau jours devant lui dans mon code!
je garde quand même a l'esprit de ne PAS le faire quand ma structure ne contient pas que des membres POD.

Si tu code en C ça peut être normal que tu utilise memset. En C++ par contre je me pose des questions, c'est une fonction qu'on utilise très rarement, on lui préfère std::fill, les constructeurs, ...
Le problème à utiliser memset en C++ c'est qu'un POD peut vite devenir non-POD, suite à l'ajout d'un membre std::string par exemple, et là soit tu oublie que tu as fait plein de memset partout et ça donne des bugs difficiles à trouver, soit tu y pense mais et tu es bon pour remplacer tous les memset par autre chose, alors autan ne pas utiliser memset dès le départ.
07/10/2008, 15h01
koala01

Salut,

Tu pourras me traiter d'extrémiste si tu le veux, mais, ma philosophie générale est toujours de ne pas utiliser une fonction ou une manière de faire propre au C là où il existe une alternative propre au C++.

En effet, je ne comprend pas vraiment l'intérêt de se "casser la tête" à utiliser un tableau dynamique de caractères au lieu d'utiliser une std::string, sachant que la classe std::string est bien plus sécurisante à l'emploi, fournit un éventail de fonction qui permet de faire à la limite bien mieux que ce que ne peut permetrre la gestion d'un char*, et permet même, le cas échéant, de récupérer un char*, entre autre parce qu'il faudrait envoyer le contenu vers une application écrite en C ou parce qu'il faudrait le faire transiter sur un réseau...

De la même manière, il faut se rappeler que le C ne va jamais travailler qu'avec des types POD, qui sont éventuellement des agrégats de type POD (voire des agrégats contenant des pointeurs vers des types POD)...

Il n'y a donc a priori aucun problème à utiliser memset en C parce que, justement, on ne risque pas d'aller "chatouiller" autre chose que... des données.

A l'extrême limite, je concevrais également de répondre à Emanuel que, finalement, l'operator sizeof vient bien à point pour éviter d'aller initialiser quelque chose à quoi l'on n'aurait pas du aller toucher.

Mais cette remarque n'est valide que dans le cas où l'on parle d'un langage n'utilisant que des types POD...

En effet, du simple fait que le C++ est orienté objet - et même s'il faut éviter de restreindre la notion d'orienté objet à ce fait - les objets et les types que l'on est amené à manipuler en C++ sont finalement très rarement POD...

De plus, il est vrai que la S(T)L est suffisemment bien fournie - en classes et en fonctions diverses - et suffisemment "mature" pour nous éviter autant que possible d'avoir à utiliser des tableaux "C style" - quel que puis être le type de donnée manipulé par ce tableau - de manière sécurisante...

Dés lors, je ne vois finalement aucune raison de préférer quelque chose dont on sait que cela peut amener un tas de problèmes en cas d'inattention ou de modification (parfois finalement très superficielle) à quelque chose dont on a la certitude que le comportement est sécurisé et adapté en toutes circonstances...

That was my 2 penny's hour
08/10/2008, 01h29
nicroman

Sans revenir sur le débat des strings...
(personnelement, je n'utilise des 'string' que quand je dois *stocker* une chaine ASCII, ce qui est somme toute assez rare, sauf dans de très rares cas d'IO, pour le stockage des chaines j'utilise wstring [la même version unicode], et sinon, dès que ca passe en paramètre, c'est du const wchar_t*, size_t maxlength )

Il y a une énorme différence entre initiliaser la mémoire et initialiser un objet... Initialiser la mémoire, encore une fois, est rarement utile sauf pour débugger (et en général, en mode debug, nos compilateurs le font pour nous avec une valeur qui n'est pas 0).
Je n'arrive d'ailleurs même plus à trouver un cas ou initialiser la mémoire soit vraiment utile...
08/10/2008, 01h50
koala01

Citation:

Envoyé par nicroman

Sans revenir sur le débat des strings...
(personnelement, je n'utilise des 'string' que quand je dois *stocker* une chaine ASCII, ce qui est somme toute assez rare, sauf dans de très rares cas d'IO, pour le stockage des chaines j'utilise wstring [la même version unicode], et sinon, dès que ca passe en paramètre, c'est du const wchar_t*, size_t maxlength )

Je ne suis qu'en partie d'accord avec toi...

Non pas sur le fait de préférer wstring à string - car l'unicode a effectivement ses avantages - mais sur l'utilisation de la classe (w)string...

Si je conçois pleinement que l'on renvoie un (w)char* en retour de fonction, pour la raison bien connue qui veut que les différents compilateurs peuvent gérer les (w)string de manière différente, et donc, pour assurer un minimum de compatibilité lorsque l'on travaille sur une dll, je préférerais fortement utiliser la (w)string, tant en passage de paramètre (une référence (constante) sur une (w)string) que pour l'usage local...

En effet, le passage d'un (w)char* à la place d'une référence sur (w)string est parfaitement autorisé, et, dés le moment où la fonction est compilée - que ce soit dans le cadre d'une bibliothèque statique ou dynamique, ou même dans le cadre d'une application "finale" - le problème ne se pose plus vraiment: au sein d'une dll, seul le retour de fonction peut poser problème en cas de divergence de point de vue de compilateur, et, les bibliothèques statiques sont de toutes manières compilées... pour un compilateur particulier ;)

Dés lors, je ne vois absolument pas l'intérêt de s'empêtrer dans la gestion (toujours fastudieuse) d'un (w)char* au sein même des fonctions ;)

Citation:

Il y a une énorme différence entre initiliaser la mémoire et initialiser un objet... Initialiser la mémoire, encore une fois, est rarement utile sauf pour débugger (et en général, en mode debug, nos compilateurs le font pour nous avec une valeur qui n'est pas 0).
Je n'arrive d'ailleurs même plus à trouver un cas ou initialiser la mémoire soit vraiment utile...

Là dessus, par contre, je suis tout à fait d'accord avec toi ;)
08/10/2008, 09h08
zenetcalme

J'ai l'impression d'avoir lancé un vieux trool la... :aie:

sinon, en ce qui concerne l'initialisation de ma structure, peut être qu'un peu plus de détail doit être fournit!

En effet, je développe une API (DLL) qui sert d'interface entre le PC et du matériel USB entre autre. J'ai une structure imposé qui contient pas mal d'information, ou il n'est pas question d'y mettre des pointeurs, des objets etc.

Lorsque je crée une structure de ce type, je voudrais être sur à 100% que celle ci contient bien que des 0.
Dans ce cas la, le memset me paraissait parfaitement convenir, et je trouve que la, std::fill alourdirais mon code, et risquerais de le rendre moins lisible.

il y a le sizeof qui me permet de ne pas craindre de débordement.

Enfin, si j'en arrive à vouloir initialiser certaines variables, le compilateur y est pour beaucoup... J'ai de plus en plus de mal a lui faire confiance!:bug:

maintenant, je suis bien d'accord avec ce qui a été dit plus haut! quand je fais du c++, j'ai de moins en moins de type purement POD... et le std::fill sera de plus en plus utilisé!:yaisse2:
09/10/2008, 03h55
loufoque

Si je comprends bien, tu envoies la mémoire de tes objets.
Le bon truc pas portable...
09/10/2008, 08h26
zenetcalme

L'api est imposée par une norme...
Je doit renvoyer un pointeur sur une structure!

moi je vais tout faire pour pas risquer de problème, mais la norme, c la norme!
franchement, si les gens qui pondais ce genre de truc codait, ça se serais depuis longtemps!:kill:

de plus, je me poserais pas tant de question!!!

Code:

1
2
3
4
5
std::vector<MaStruct> v;
v.reserve(5); //Non nécéssaire mais va éviter les réallocs.
MaStruct init = {42, "toto", 0x12345678};
std::fill_n(v.begin(),5, init);
return &v[0];

Et youpiya, on renvoie un beau pointeur.

13/10/2008, 09h07
Médinoc

Et hop, on renvoie un beau pointeur vers un truc qui aura été désalloué par le destructeur de v...
13/10/2008, 13h49
deadalnix

Oui, tu as raison, c'était a prendre comme un pseudo code. Ce que je voulais mettre en avant c'était l'utilisation de &v[0] et non la gestion de la mémoire.

Mais effectivement, il convient de ne pas renvoyer des pointeur vers des objets dans la pile, ou des composantes de ces objets.

Salut

Code:

1
2
3
4
std::vector<MaStruct> v;
v.reserve(5); //Non nécéssaire mais va éviter les réallocs.
MaStruct init = {42, "toto", 0x12345678};
std::fill_n(v.begin(),5, init);

tu initialise un tableau de taille 0 ??
Y as de forte chance que tu te prenne une exception ou un beau plantage si tu n est plus grand que ton reserve.

tu peut faire

Code:

1
2
3
std::vector<MaStruct> v(5);//tableau de taille 5
MaStruct init = {42, "toto", 0x12345678};
std::fill(v.begin(),v.end(), init);

soit

Code:

1
2
3
4
std::vector<MaStruct> v;//tableau de taille 5
v.reserve(5);//si tu veut
MaStruct init = {42, "toto", 0x12345678};
std::fill_n(std::back_inserter (v), 5, 11);