wrote:Laurent Deniau wrote in messagewrote:
(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.
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.
wrote:Laurent Deniau wrote in messagewrote:
(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.
Laurent Deniau wrote:wrote:Laurent Deniau wrote in messagewrote:
(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...
[de la norme C99]
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.
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...
[de la norme C99]
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.
Laurent Deniau wrote:wrote:Laurent Deniau wrote in messagewrote:
(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...
[de la norme C99]
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.
Laurent Deniau wrote in message
news:<cni5v6$d7p$...Laurent Deniau wrote:wrote:Laurent Deniau wrote in messagewrote:(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).
Moi aussi, j'utilise systèmatiquement unsigned char pour la mémoire
brute. En fait, je crois qu'en C++, char va aussi, mais qu'en C(90),
non, mais je suis loin d'en être sûr. Mais unsigned char marche dans
tous les cas, garanti, et au moins dans les milieux où j'ai travaillé,
c'est le type « standard » pour ce genre de chose. (En général, char
tout seul ne sert que pour des caractères.)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...
[de la norme C99]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.
En voilà du standardais. J'avoue que je n'y comprends que dalle. Or que
mon anglais n'est pas si mauvais que ça. (Pour commencer, je ne sais pas
ce qu'ils entendent par « no declared type ». Toutes les expressions en
C ou en C++ ont un type.)
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.
Je ne suis pas sûr, mais je crois que ce qu'il sont en train de dire
(voir le paragraphe suivant), c'est que si tu copies un int (disons)
dans un char[], le char[] contient un int -- tu peux la copier autant
que tu veux en tant que char[], mais si tu essaies à accéder à un des
copies en tant qu'autre chose que int ou char[] (ou un type compatible
avec un de ces deux), c'est un comportement indéfini.
Si c'est ça, c'est un peu ce que je disais dans mon autre réponse. Si tu
fais :
float f ;
int i ;
memcpy( &i, &f, sizeof( int ) ) ;
le type « effectif » de l'objet à l'adresse &f est un int, et si tu
essaies d'y accéder autrement que comme int ou comme char[], tu as un
comportement indéfini. (Et évidemment, toute utilisation de f va y
accéder en tant que float -- donc, comportement indéfini.) En revanche,
en supposant que des float soit assez grands, quelque chose comme :
float f ;
unsigned char* buf = (unsigned char*)&f
int i ;
memcpy( buf, &i, sizeof( int ) ) ;
memcpy( &i, buf, sizeof( int ) ) ;
est garanti. Je peux copier un int dans un float, tant que je n'accède
pas au float.
(Mais je suis loins d'être sûr. Comme j'ai dit, j'ai
beaucoup de mal à comprendre ce paragraphe.)
Laurent Deniau <Laurent.Deniau@cern.ch> wrote in message
news:<cni5v6$d7p$2@sunnews.cern.ch>...
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).
Moi aussi, j'utilise systèmatiquement unsigned char pour la mémoire
brute. En fait, je crois qu'en C++, char va aussi, mais qu'en C(90),
non, mais je suis loin d'en être sûr. Mais unsigned char marche dans
tous les cas, garanti, et au moins dans les milieux où j'ai travaillé,
c'est le type « standard » pour ce genre de chose. (En général, char
tout seul ne sert que pour des caractères.)
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...
[de la norme C99]
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.
En voilà du standardais. J'avoue que je n'y comprends que dalle. Or que
mon anglais n'est pas si mauvais que ça. (Pour commencer, je ne sais pas
ce qu'ils entendent par « no declared type ». Toutes les expressions en
C ou en C++ ont un type.)
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.
Je ne suis pas sûr, mais je crois que ce qu'il sont en train de dire
(voir le paragraphe suivant), c'est que si tu copies un int (disons)
dans un char[], le char[] contient un int -- tu peux la copier autant
que tu veux en tant que char[], mais si tu essaies à accéder à un des
copies en tant qu'autre chose que int ou char[] (ou un type compatible
avec un de ces deux), c'est un comportement indéfini.
Si c'est ça, c'est un peu ce que je disais dans mon autre réponse. Si tu
fais :
float f ;
int i ;
memcpy( &i, &f, sizeof( int ) ) ;
le type « effectif » de l'objet à l'adresse &f est un int, et si tu
essaies d'y accéder autrement que comme int ou comme char[], tu as un
comportement indéfini. (Et évidemment, toute utilisation de f va y
accéder en tant que float -- donc, comportement indéfini.) En revanche,
en supposant que des float soit assez grands, quelque chose comme :
float f ;
unsigned char* buf = (unsigned char*)&f
int i ;
memcpy( buf, &i, sizeof( int ) ) ;
memcpy( &i, buf, sizeof( int ) ) ;
est garanti. Je peux copier un int dans un float, tant que je n'accède
pas au float.
(Mais je suis loins d'être sûr. Comme j'ai dit, j'ai
beaucoup de mal à comprendre ce paragraphe.)
Laurent Deniau wrote in message
news:<cni5v6$d7p$...Laurent Deniau wrote:wrote:Laurent Deniau wrote in messagewrote:(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).
Moi aussi, j'utilise systèmatiquement unsigned char pour la mémoire
brute. En fait, je crois qu'en C++, char va aussi, mais qu'en C(90),
non, mais je suis loin d'en être sûr. Mais unsigned char marche dans
tous les cas, garanti, et au moins dans les milieux où j'ai travaillé,
c'est le type « standard » pour ce genre de chose. (En général, char
tout seul ne sert que pour des caractères.)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...
[de la norme C99]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.
En voilà du standardais. J'avoue que je n'y comprends que dalle. Or que
mon anglais n'est pas si mauvais que ça. (Pour commencer, je ne sais pas
ce qu'ils entendent par « no declared type ». Toutes les expressions en
C ou en C++ ont un type.)
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.
Je ne suis pas sûr, mais je crois que ce qu'il sont en train de dire
(voir le paragraphe suivant), c'est que si tu copies un int (disons)
dans un char[], le char[] contient un int -- tu peux la copier autant
que tu veux en tant que char[], mais si tu essaies à accéder à un des
copies en tant qu'autre chose que int ou char[] (ou un type compatible
avec un de ces deux), c'est un comportement indéfini.
Si c'est ça, c'est un peu ce que je disais dans mon autre réponse. Si tu
fais :
float f ;
int i ;
memcpy( &i, &f, sizeof( int ) ) ;
le type « effectif » de l'objet à l'adresse &f est un int, et si tu
essaies d'y accéder autrement que comme int ou comme char[], tu as un
comportement indéfini. (Et évidemment, toute utilisation de f va y
accéder en tant que float -- donc, comportement indéfini.) En revanche,
en supposant que des float soit assez grands, quelque chose comme :
float f ;
unsigned char* buf = (unsigned char*)&f
int i ;
memcpy( buf, &i, sizeof( int ) ) ;
memcpy( &i, buf, sizeof( int ) ) ;
est garanti. Je peux copier un int dans un float, tant que je n'accède
pas au float.
(Mais je suis loins d'être sûr. Comme j'ai dit, j'ai
beaucoup de mal à comprendre ce paragraphe.)
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));
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));
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));
