int *g =(int *)gauche->data; // data est void * (*g) = r;
ET
memcpy(gauche->data,&r,sizeof(int));
A priori *( (int*) gauche->data )= r; car le compilateur sait combien de char il doit copier, et utiliser éventuellement l'instruction qui va bien du processeur.
Alors que memcpy doit dynamiquement gérer sizeof(int) et peut-être même faire un appel de fonction.
Ceci dit, si quelqu'un me dit que sur sa platerforme, c'est le contraire, je serais pas étonné.
Marc Boyer -- Je ne respecte plus le code de la route à vélo depuis une double fracture due au fait que j'étais le seul à le respecter.
In article <419a0d8e$0$18771$8fcfb975@news.wanadoo.fr>, dark poulpo wrote:
bonjour,
d'apres vous, c'est quoi le plus rapide entre
int *g =(int *)gauche->data; // data est void *
(*g) = r;
ET
memcpy(gauche->data,&r,sizeof(int));
A priori
*( (int*) gauche->data )= r;
car le compilateur sait combien de char il doit copier,
et utiliser éventuellement l'instruction qui va bien
du processeur.
Alors que
memcpy
doit dynamiquement gérer sizeof(int) et peut-être même
faire un appel de fonction.
Ceci dit, si quelqu'un me dit que sur sa platerforme,
c'est le contraire, je serais pas étonné.
Marc Boyer
--
Je ne respecte plus le code de la route à vélo depuis une double fracture
due au fait que j'étais le seul à le respecter.
int *g =(int *)gauche->data; // data est void * (*g) = r;
ET
memcpy(gauche->data,&r,sizeof(int));
A priori *( (int*) gauche->data )= r; car le compilateur sait combien de char il doit copier, et utiliser éventuellement l'instruction qui va bien du processeur.
Alors que memcpy doit dynamiquement gérer sizeof(int) et peut-être même faire un appel de fonction.
Ceci dit, si quelqu'un me dit que sur sa platerforme, c'est le contraire, je serais pas étonné.
Marc Boyer -- Je ne respecte plus le code de la route à vélo depuis une double fracture due au fait que j'étais le seul à le respecter.
Jean-Marc Bourguet
"dark poulpo" writes:
bonjour,
d'apres vous, c'est quoi le plus rapide entre
int *g =(int *)gauche->data; // data est void * (*g) = r;
ET
memcpy(gauche->data,&r,sizeof(int));
Si ca a de l'importance, mesure, sinon fait le plus clair:
*static_cast<int*>(gauche->data) = r;
qui a priori sera plus rapide. Ca ne m'etonnerait pas que certains compilateurs fassent la meme chose pour les deux -- memcpy est standard et sizeof(int) est connu -- , mais ca m'etonnerait qu'il y en ait qui gerent mieux memcpy que l'assignation -- par exemple sur des machines avec des contraintes d'alignement fortes pour les int, la premiere version permet de supposer que gauche->data est correctement aligne, pas la deuxieme.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
"dark poulpo" <ggggggg@g.gg> writes:
bonjour,
d'apres vous, c'est quoi le plus rapide entre
int *g =(int *)gauche->data; // data est void *
(*g) = r;
ET
memcpy(gauche->data,&r,sizeof(int));
Si ca a de l'importance, mesure, sinon fait le plus clair:
*static_cast<int*>(gauche->data) = r;
qui a priori sera plus rapide. Ca ne m'etonnerait pas que certains
compilateurs fassent la meme chose pour les deux -- memcpy est
standard et sizeof(int) est connu -- , mais ca m'etonnerait qu'il y en
ait qui gerent mieux memcpy que l'assignation -- par exemple sur des
machines avec des contraintes d'alignement fortes pour les int, la
premiere version permet de supposer que gauche->data est correctement
aligne, pas la deuxieme.
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
int *g =(int *)gauche->data; // data est void * (*g) = r;
ET
memcpy(gauche->data,&r,sizeof(int));
Si ca a de l'importance, mesure, sinon fait le plus clair:
*static_cast<int*>(gauche->data) = r;
qui a priori sera plus rapide. Ca ne m'etonnerait pas que certains compilateurs fassent la meme chose pour les deux -- memcpy est standard et sizeof(int) est connu -- , mais ca m'etonnerait qu'il y en ait qui gerent mieux memcpy que l'assignation -- par exemple sur des machines avec des contraintes d'alignement fortes pour les int, la premiere version permet de supposer que gauche->data est correctement aligne, pas la deuxieme.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
kanze
"dark poulpo" wrote in message news:<419a0d8e$0$18771$...
d'apres vous, c'est quoi le plus rapide entre
int *g =(int *)gauche->data; // data est void * (*g) = r;
ET
memcpy(gauche->data,&r,sizeof(int));
Qu'importe, puisqu'il ne font pas la même chose. Si la sémantique du programme exige le premier, le séconde ne marche pas, et vice versa. (En général, le deuxième a un comportement indéfini, si data est un void*.)
-- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
"dark poulpo" <ggggggg@g.gg> wrote in message
news:<419a0d8e$0$18771$8fcfb975@news.wanadoo.fr>...
d'apres vous, c'est quoi le plus rapide entre
int *g =(int *)gauche->data; // data est void *
(*g) = r;
ET
memcpy(gauche->data,&r,sizeof(int));
Qu'importe, puisqu'il ne font pas la même chose. Si la sémantique du
programme exige le premier, le séconde ne marche pas, et vice versa. (En
général, le deuxième a un comportement indéfini, si data est un void*.)
--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
"dark poulpo" wrote in message news:<419a0d8e$0$18771$...
d'apres vous, c'est quoi le plus rapide entre
int *g =(int *)gauche->data; // data est void * (*g) = r;
ET
memcpy(gauche->data,&r,sizeof(int));
Qu'importe, puisqu'il ne font pas la même chose. Si la sémantique du programme exige le premier, le séconde ne marche pas, et vice versa. (En général, le deuxième a un comportement indéfini, si data est un void*.)
-- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
PurL
int *g =(int *)gauche->data; // data est void * (*g) = r;
ET
memcpy(gauche->data,&r,sizeof(int));
Qu'importe, puisqu'il ne font pas la même chose.
Soit plus précis ! l'autre exemple fait quoi s'il ne place pas la valeur de r à l'adresse gauche->data ?
PurL
int *g =(int *)gauche->data; // data est void *
(*g) = r;
ET
memcpy(gauche->data,&r,sizeof(int));
Qu'importe, puisqu'il ne font pas la même chose.
Soit plus précis ! l'autre exemple fait quoi s'il ne place pas la valeur de
r à l'adresse gauche->data ?
int *g =(int *)gauche->data; // data est void * (*g) = r;
ET
memcpy(gauche->data,&r,sizeof(int));
Qu'importe, puisqu'il ne font pas la même chose.
Soit plus précis ! l'autre exemple fait quoi s'il ne place pas la valeur de r à l'adresse gauche->data ?
PurL
Laurent Deniau
wrote:
"dark poulpo" wrote in message news:<419a0d8e$0$18771$...
d'apres vous, c'est quoi le plus rapide entre
int *g =(int *)gauche->data; // data est void * (*g) = r;
ET
memcpy(gauche->data,&r,sizeof(int));
Qu'importe, puisqu'il ne font pas la même chose. Si la sémantique du programme exige le premier, le séconde ne marche pas, et vice versa. (En général, le deuxième a un comportement indéfini, si data est un void*.)
Je ne crois pas que le deuxieme soit un UB si tu penses aux problemes d'alignement.
int r1, r2; r1; memcpy(gauche->data,&r1,sizeof(int)); r1=0; memcpy(&r2,gauche->data,sizeof(int));
meme si gauche->data n'est pas aligne pour recevoir un int (je suppose par contre qu'il y a la place de mettre un int), il n'y a pas de UB. memcpy considere les src et dst comme des array de unsigned char. Tant que cet array n'est pas interprete comme contenant un int, il ne devrait pas y avoir de UB.
a+, ld.
kanze@gabi-soft.fr wrote:
"dark poulpo" <ggggggg@g.gg> wrote in message
news:<419a0d8e$0$18771$8fcfb975@news.wanadoo.fr>...
d'apres vous, c'est quoi le plus rapide entre
int *g =(int *)gauche->data; // data est void *
(*g) = r;
ET
memcpy(gauche->data,&r,sizeof(int));
Qu'importe, puisqu'il ne font pas la même chose. Si la sémantique du
programme exige le premier, le séconde ne marche pas, et vice versa. (En
général, le deuxième a un comportement indéfini, si data est un void*.)
Je ne crois pas que le deuxieme soit un UB si tu penses aux problemes
d'alignement.
int r1, r2;
r1;
memcpy(gauche->data,&r1,sizeof(int));
r1=0;
memcpy(&r2,gauche->data,sizeof(int));
meme si gauche->data n'est pas aligne pour recevoir un int (je suppose
par contre qu'il y a la place de mettre un int), il n'y a pas de UB.
memcpy considere les src et dst comme des array de unsigned char. Tant
que cet array n'est pas interprete comme contenant un int, il ne devrait
pas y avoir de UB.
"dark poulpo" wrote in message news:<419a0d8e$0$18771$...
d'apres vous, c'est quoi le plus rapide entre
int *g =(int *)gauche->data; // data est void * (*g) = r;
ET
memcpy(gauche->data,&r,sizeof(int));
Qu'importe, puisqu'il ne font pas la même chose. Si la sémantique du programme exige le premier, le séconde ne marche pas, et vice versa. (En général, le deuxième a un comportement indéfini, si data est un void*.)
Je ne crois pas que le deuxieme soit un UB si tu penses aux problemes d'alignement.
int r1, r2; r1; memcpy(gauche->data,&r1,sizeof(int)); r1=0; memcpy(&r2,gauche->data,sizeof(int));
meme si gauche->data n'est pas aligne pour recevoir un int (je suppose par contre qu'il y a la place de mettre un int), il n'y a pas de UB. memcpy considere les src et dst comme des array de unsigned char. Tant que cet array n'est pas interprete comme contenant un int, il ne devrait pas y avoir de UB.
a+, ld.
kanze
Laurent Deniau wrote in message news:<cnfk02$f9k$...
wrote:
"dark poulpo" wrote in message news:<419a0d8e$0$18771$...
d'apres vous, c'est quoi le plus rapide entre
int *g =(int *)gauche->data; // data est void * (*g) = r;
ET
memcpy(gauche->data,&r,sizeof(int));
Qu'importe, puisqu'il ne font pas la même chose. Si la sémantique du programme exige le premier, le séconde ne marche pas, et vice versa. (En général, le deuxième a un comportement indéfini, si data est un void*.)
Je ne crois pas que le deuxieme soit un UB si tu penses aux problemes d'alignement.
Non. J'avais mal lu l'orginal, et je croyais que c'était le pointeur qu'on copiait. Copier un void* dans un int*, et puis espérer accéder à un int, a un comportement indéfini. Dans la mésure que les deux zones mémoire ont le même type, et qu'il s'agit des POD, en revanche, le memcpy doit marcher. (En ce qui concerne l'alignement, si le void* n'a pas été initialisé avec un int* avant, les deux versions ont un comportement indéfini.)
-- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Laurent Deniau <Laurent.Deniau@cern.ch> wrote in message
news:<cnfk02$f9k$1@sunnews.cern.ch>...
kanze@gabi-soft.fr wrote:
"dark poulpo" <ggggggg@g.gg> wrote in message
news:<419a0d8e$0$18771$8fcfb975@news.wanadoo.fr>...
d'apres vous, c'est quoi le plus rapide entre
int *g =(int *)gauche->data; // data est void *
(*g) = r;
ET
memcpy(gauche->data,&r,sizeof(int));
Qu'importe, puisqu'il ne font pas la même chose. Si la sémantique du
programme exige le premier, le séconde ne marche pas, et vice
versa. (En général, le deuxième a un comportement indéfini, si data
est un void*.)
Je ne crois pas que le deuxieme soit un UB si tu penses aux problemes
d'alignement.
Non. J'avais mal lu l'orginal, et je croyais que c'était le pointeur
qu'on copiait. Copier un void* dans un int*, et puis espérer accéder à
un int, a un comportement indéfini. Dans la mésure que les deux zones
mémoire ont le même type, et qu'il s'agit des POD, en revanche, le
memcpy doit marcher. (En ce qui concerne l'alignement, si le void* n'a
pas été initialisé avec un int* avant, les deux versions ont un
comportement indéfini.)
--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Laurent Deniau wrote in message news:<cnfk02$f9k$...
wrote:
"dark poulpo" wrote in message news:<419a0d8e$0$18771$...
d'apres vous, c'est quoi le plus rapide entre
int *g =(int *)gauche->data; // data est void * (*g) = r;
ET
memcpy(gauche->data,&r,sizeof(int));
Qu'importe, puisqu'il ne font pas la même chose. Si la sémantique du programme exige le premier, le séconde ne marche pas, et vice versa. (En général, le deuxième a un comportement indéfini, si data est un void*.)
Je ne crois pas que le deuxieme soit un UB si tu penses aux problemes d'alignement.
Non. J'avais mal lu l'orginal, et je croyais que c'était le pointeur qu'on copiait. Copier un void* dans un int*, et puis espérer accéder à un int, a un comportement indéfini. Dans la mésure que les deux zones mémoire ont le même type, et qu'il s'agit des POD, en revanche, le memcpy doit marcher. (En ce qui concerne l'alignement, si le void* n'a pas été initialisé avec un int* avant, les deux versions ont un comportement indéfini.)
-- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Laurent Deniau
wrote:
Laurent Deniau wrote in message
wrote: (En ce qui concerne l'alignement, si le void* n'a
pas été initialisé avec un int* avant, les deux versions ont un comportement indéfini.)
C'est la que je ne te suis pas. Est ce que:
{ unsigned char buf[sizeof(int)]; // buf pas aligne sur un int* int v1, v2;
v1; memcpy(buf,&v1,sizeof(int)); memcpy(&v2,buf,sizeof(int)); // equivalent de v2 = v1 }
a un UB? Je ne crois pas.
a+, ld.
kanze@gabi-soft.fr wrote:
Laurent Deniau <Laurent.Deniau@cern.ch> wrote in message
kanze@gabi-soft.fr wrote:
(En ce qui concerne l'alignement, si le void* n'a
pas été initialisé avec un int* avant, les deux versions ont un
comportement indéfini.)
C'est la que je ne te suis pas. Est ce que:
{
unsigned char buf[sizeof(int)]; // buf pas aligne sur un int*
int v1, v2;
v1;
memcpy(buf,&v1,sizeof(int));
memcpy(&v2,buf,sizeof(int));
// equivalent de v2 = v1
}
wrote: (En ce qui concerne l'alignement, si le void* n'a
pas été initialisé avec un int* avant, les deux versions ont un comportement indéfini.)
C'est la que je ne te suis pas. Est ce que:
{ unsigned char buf[sizeof(int)]; // buf pas aligne sur un int* int v1, v2;
v1; memcpy(buf,&v1,sizeof(int)); memcpy(&v2,buf,sizeof(int)); // equivalent de v2 = v1 }
a un UB? Je ne crois pas.
a+, ld.
Jean-Marc Bourguet
Laurent Deniau writes:
wrote:
Laurent Deniau wrote in message
wrote: (En ce qui concerne l'alignement, si le void* n'a
pas été initialisé avec un int* avant, les deux versions ont un comportement indéfini.)
C'est la que je ne te suis pas. Est ce que:
{ unsigned char buf[sizeof(int)]; // buf pas aligne sur un int* int v1, v2;
v1; memcpy(buf,&v1,sizeof(int)); memcpy(&v2,buf,sizeof(int)); // equivalent de v2 = v1 }
a un UB? Je ne crois pas.
Ce qui est copie peut ne pas etre un int acceptable par l'architecture.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Laurent Deniau <Laurent.Deniau@cern.ch> writes:
kanze@gabi-soft.fr wrote:
Laurent Deniau <Laurent.Deniau@cern.ch> wrote in message
kanze@gabi-soft.fr wrote:
(En ce qui concerne l'alignement, si le void* n'a
pas été initialisé avec un int* avant, les deux versions ont un
comportement indéfini.)
C'est la que je ne te suis pas. Est ce que:
{
unsigned char buf[sizeof(int)]; // buf pas aligne sur un int*
int v1, v2;
v1;
memcpy(buf,&v1,sizeof(int));
memcpy(&v2,buf,sizeof(int));
// equivalent de v2 = v1
}
a un UB? Je ne crois pas.
Ce qui est copie peut ne pas etre un int acceptable par
l'architecture.
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
wrote: (En ce qui concerne l'alignement, si le void* n'a
pas été initialisé avec un int* avant, les deux versions ont un comportement indéfini.)
C'est la que je ne te suis pas. Est ce que:
{ unsigned char buf[sizeof(int)]; // buf pas aligne sur un int* int v1, v2;
v1; memcpy(buf,&v1,sizeof(int)); memcpy(&v2,buf,sizeof(int)); // equivalent de v2 = v1 }
a un UB? Je ne crois pas.
Ce qui est copie peut ne pas etre un int acceptable par l'architecture.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Laurent Deniau
Jean-Marc Bourguet wrote:
Laurent Deniau writes:
wrote:
Laurent Deniau wrote in message
wrote:
(En ce qui concerne l'alignement, si le void* n'a pas été initialisé avec un int* avant, les deux versions ont un comportement indéfini.)
C'est la que je ne te suis pas. Est ce que:
{ unsigned char buf[sizeof(int)]; // buf pas aligne sur un int* int v1, v2;
v1; memcpy(buf,&v1,sizeof(int)); memcpy(&v2,buf,sizeof(int)); // equivalent de v2 = v1 }
a un UB? Je ne crois pas.
Ce qui est copie peut ne pas etre un int acceptable par l'architecture.
lequel? ou-t-il question d'un int, je ne vois que des sizeof(int) et des void*?
a+, ld.
Jean-Marc Bourguet wrote:
Laurent Deniau <Laurent.Deniau@cern.ch> writes:
kanze@gabi-soft.fr wrote:
Laurent Deniau <Laurent.Deniau@cern.ch> wrote in message
kanze@gabi-soft.fr wrote:
(En ce qui concerne l'alignement, si le void* n'a
pas été initialisé avec un int* avant, les deux versions ont un
comportement indéfini.)
C'est la que je ne te suis pas. Est ce que:
{
unsigned char buf[sizeof(int)]; // buf pas aligne sur un int*
int v1, v2;
v1;
memcpy(buf,&v1,sizeof(int));
memcpy(&v2,buf,sizeof(int));
// equivalent de v2 = v1
}
a un UB? Je ne crois pas.
Ce qui est copie peut ne pas etre un int acceptable par
l'architecture.
lequel? ou-t-il question d'un int, je ne vois que des sizeof(int) et des
void*?
(En ce qui concerne l'alignement, si le void* n'a pas été initialisé avec un int* avant, les deux versions ont un comportement indéfini.)
C'est la que je ne te suis pas. Est ce que:
{ unsigned char buf[sizeof(int)]; // buf pas aligne sur un int* int v1, v2;
v1; memcpy(buf,&v1,sizeof(int)); memcpy(&v2,buf,sizeof(int)); // equivalent de v2 = v1 }
a un UB? Je ne crois pas.
Ce qui est copie peut ne pas etre un int acceptable par l'architecture.
lequel? ou-t-il question d'un int, je ne vois que des sizeof(int) et des void*?
a+, ld.
Laurent Deniau
Laurent Deniau wrote:
wrote:
Laurent Deniau wrote in message
wrote:
(En ce qui concerne l'alignement, si le void* n'a pas été initialisé avec un int* avant, les deux versions ont un comportement indéfini.)
C'est la que je ne te suis pas. Est ce que:
{ unsigned char buf[sizeof(int)]; // buf pas aligne sur un int*
Lire char buf. Je ne sais pas pourquoi j'ai mis unsigned (bien que dans la pratique il n'y ait pas de difference pour ce qui suit).
int v1, v2;
v1; memcpy(buf,&v1,sizeof(int)); memcpy(&v2,buf,sizeof(int)); // equivalent de v2 = v1 }
a un UB? Je ne crois pas.
Mais en regardant 6.5-6 (effective type), j'ai un doute...
If a value is copied into an object having no declared type using memcpy or memmove, or is copied as an array of character type, then the effective type of the modified object for that access and for subsequent accesses that do not modify the value is the effective type of the *object from which the value is copied*, if it has one.
Est-ce que par hasard cela voudrait dire que memcpy et memmove seraient en droit d'optimiser la copie en fonction de l'alignement (et de la taille) de la src independament de la dst et donc que la dst doit repondre au meme contraintes d'alignement que la src? J'ai du mal a le croire car si la src vient d'un malloc, on aurait un UB sur la pluspart des dst qui ne viennent pas aussi d'un malloc.
a+, ld.
Laurent Deniau wrote:
kanze@gabi-soft.fr wrote:
Laurent Deniau <Laurent.Deniau@cern.ch> wrote in message
kanze@gabi-soft.fr wrote:
(En ce qui concerne l'alignement, si le void* n'a
pas été initialisé avec un int* avant, les deux versions ont un
comportement indéfini.)
C'est la que je ne te suis pas. Est ce que:
{
unsigned char buf[sizeof(int)]; // buf pas aligne sur un int*
Lire char buf. Je ne sais pas pourquoi j'ai mis unsigned (bien que dans
la pratique il n'y ait pas de difference pour ce qui suit).
int v1, v2;
v1;
memcpy(buf,&v1,sizeof(int));
memcpy(&v2,buf,sizeof(int));
// equivalent de v2 = v1
}
a un UB? Je ne crois pas.
Mais en regardant 6.5-6 (effective type), j'ai un doute...
If a value is copied into an object having no declared type using
memcpy or memmove, or is copied as an array of character type, then the
effective type of the modified object for that access and for subsequent
accesses that do not modify the value is the effective type of the
*object from which the value is copied*, if it has one.
Est-ce que par hasard cela voudrait dire que memcpy et memmove seraient
en droit d'optimiser la copie en fonction de l'alignement (et de la
taille) de la src independament de la dst et donc que la dst doit
repondre au meme contraintes d'alignement que la src? J'ai du mal a le
croire car si la src vient d'un malloc, on aurait un UB sur la pluspart
des dst qui ne viennent pas aussi d'un malloc.
(En ce qui concerne l'alignement, si le void* n'a pas été initialisé avec un int* avant, les deux versions ont un comportement indéfini.)
C'est la que je ne te suis pas. Est ce que:
{ unsigned char buf[sizeof(int)]; // buf pas aligne sur un int*
Lire char buf. Je ne sais pas pourquoi j'ai mis unsigned (bien que dans la pratique il n'y ait pas de difference pour ce qui suit).
int v1, v2;
v1; memcpy(buf,&v1,sizeof(int)); memcpy(&v2,buf,sizeof(int)); // equivalent de v2 = v1 }
a un UB? Je ne crois pas.
Mais en regardant 6.5-6 (effective type), j'ai un doute...
If a value is copied into an object having no declared type using memcpy or memmove, or is copied as an array of character type, then the effective type of the modified object for that access and for subsequent accesses that do not modify the value is the effective type of the *object from which the value is copied*, if it has one.
Est-ce que par hasard cela voudrait dire que memcpy et memmove seraient en droit d'optimiser la copie en fonction de l'alignement (et de la taille) de la src independament de la dst et donc que la dst doit repondre au meme contraintes d'alignement que la src? J'ai du mal a le croire car si la src vient d'un malloc, on aurait un UB sur la pluspart des dst qui ne viennent pas aussi d'un malloc.
