Note que de toute façon, les valeurs devront être copiées, puisque le contenu de "LISTITEM_COLUMNS_WIDTH" est marqué const, et ne peut donc pas être modifié.
On Sun, 26 Jul 2009 15:52:03 +0200, tsalm <tsalm@free.fr>:
const int LISTITEM_COLUMNS_WIDTH[4] = {40,40,40,40} ;
int arr[4] = LISTITEM_COLUMNS_WIDTH ;
Note que de toute façon, les valeurs devront être copiées, puisque le
contenu de "LISTITEM_COLUMNS_WIDTH" est marqué const, et ne peut donc
pas être modifié.
Note que de toute façon, les valeurs devront être copiées, puisque le contenu de "LISTITEM_COLUMNS_WIDTH" est marqué const, et ne peut donc pas être modifié.
Mathias Gaunard
On 26 juil, 15:52, tsalm wrote:
Bonjour,
En essayant de faire : const int LISTITEM_COLUMNS_WIDTH[4] = {40,40,40,40} ; int arr[4] = LISTITEM_COLUMNS_WIDTH ;
mon compilateur me retourne une erreur de compilation error C2440: 'initialisation' : impossible de convertir de 'cons t int [4]' en 'int [4]'
Est-il possible de valoriser, sans passer par un memcpy, "arr" avec les valeurs de LISTITEM_COLUMNS_WIDTH ?
Quel est le problème avec memcpy ? Un bon compilateur devrait remplacer ça dans les cas où cela a du sens.
On 26 juil, 15:52, tsalm <ts...@free.fr> wrote:
Bonjour,
En essayant de faire :
const int LISTITEM_COLUMNS_WIDTH[4] = {40,40,40,40} ;
int arr[4] = LISTITEM_COLUMNS_WIDTH ;
mon compilateur me retourne une erreur de compilation
error C2440: 'initialisation' : impossible de convertir de 'cons t int
[4]' en 'int [4]'
Est-il possible de valoriser, sans passer par un memcpy, "arr" avec les
valeurs de LISTITEM_COLUMNS_WIDTH ?
Quel est le problème avec memcpy ?
Un bon compilateur devrait remplacer ça dans les cas où cela a du
sens.
En essayant de faire : const int LISTITEM_COLUMNS_WIDTH[4] = {40,40,40,40} ; int arr[4] = LISTITEM_COLUMNS_WIDTH ;
mon compilateur me retourne une erreur de compilation error C2440: 'initialisation' : impossible de convertir de 'cons t int [4]' en 'int [4]'
Est-il possible de valoriser, sans passer par un memcpy, "arr" avec les valeurs de LISTITEM_COLUMNS_WIDTH ?
Quel est le problème avec memcpy ? Un bon compilateur devrait remplacer ça dans les cas où cela a du sens.
James Kanze
On Jul 26, 11:28 pm, Mathias Gaunard wrote:
On 26 juil, 15:52, tsalm wrote:
> En essayant de faire : > const int LISTITEM_COLUMNS_WIDTH[4] = {40,40,40,40} ; > int arr[4] = LISTITEM_COLUMNS_WIDTH ;
> mon compilateur me retourne une erreur de compilation > error C2440: 'initialisation' : impossible de convertir de 'const in t > [4]' en 'int [4]'
> Est-il possible de valoriser, sans passer par un memcpy, > "arr" avec les valeurs de LISTITEM_COLUMNS_WIDTH ?
Quel est le problème avec memcpy ? Un bon compilateur devrait remplacer ça dans les cas où cela a du sens.
Le problème, c'est que si on remplace le tableau avec quelque chose de plus raisonable (p.e. std::vector> par la suite, ça ne marche plus, bien que ça compile sans erreur. Le problème, c'est que si on remplace double par un type défini par l'utilisater (p.e. BigDecimal) par la suite, ça ne marche plus, bien que ça compile.
Utiliser std::copy, plutôt que memcpy, me semble le minimum.
-- James Kanze (GABI Software) email: 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
On Jul 26, 11:28 pm, Mathias Gaunard <loufo...@gmail.com> wrote:
On 26 juil, 15:52, tsalm <ts...@free.fr> wrote:
> En essayant de faire :
> const int LISTITEM_COLUMNS_WIDTH[4] = {40,40,40,40} ;
> int arr[4] = LISTITEM_COLUMNS_WIDTH ;
> mon compilateur me retourne une erreur de compilation
> error C2440: 'initialisation' : impossible de convertir de 'const in t
> [4]' en 'int [4]'
> Est-il possible de valoriser, sans passer par un memcpy,
> "arr" avec les valeurs de LISTITEM_COLUMNS_WIDTH ?
Quel est le problème avec memcpy ?
Un bon compilateur devrait remplacer ça dans les cas où cela a
du sens.
Le problème, c'est que si on remplace le tableau avec quelque
chose de plus raisonable (p.e. std::vector> par la suite, ça ne
marche plus, bien que ça compile sans erreur. Le problème, c'est
que si on remplace double par un type défini par l'utilisater
(p.e. BigDecimal) par la suite, ça ne marche plus, bien que ça
compile.
Utiliser std::copy, plutôt que memcpy, me semble le minimum.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
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
> En essayant de faire : > const int LISTITEM_COLUMNS_WIDTH[4] = {40,40,40,40} ; > int arr[4] = LISTITEM_COLUMNS_WIDTH ;
> mon compilateur me retourne une erreur de compilation > error C2440: 'initialisation' : impossible de convertir de 'const in t > [4]' en 'int [4]'
> Est-il possible de valoriser, sans passer par un memcpy, > "arr" avec les valeurs de LISTITEM_COLUMNS_WIDTH ?
Quel est le problème avec memcpy ? Un bon compilateur devrait remplacer ça dans les cas où cela a du sens.
Le problème, c'est que si on remplace le tableau avec quelque chose de plus raisonable (p.e. std::vector> par la suite, ça ne marche plus, bien que ça compile sans erreur. Le problème, c'est que si on remplace double par un type défini par l'utilisater (p.e. BigDecimal) par la suite, ça ne marche plus, bien que ça compile.
Utiliser std::copy, plutôt que memcpy, me semble le minimum.
-- James Kanze (GABI Software) email: 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
Mathias Gaunard
On 27 juil, 09:40, James Kanze wrote:
Utiliser std::copy, plutôt que memcpy, me semble le minimum.
Le problème de std::copy, c'est qu'en pratique il va faire un memmove et pas un memcpy.
On 27 juil, 09:40, James Kanze <james.ka...@gmail.com> wrote:
Utiliser std::copy, plutôt que memcpy, me semble le minimum.
Le problème de std::copy, c'est qu'en pratique il va faire un memmove
et pas un memcpy.
Utiliser std::copy, plutôt que memcpy, me semble le minimum.
Le problème de std::copy, c'est qu'en pratique il va faire un memmove et pas un memcpy.
std::copy va copier les éléments un par un.
J'ai du mal à comprendre la différence entre memmove et memcopy ici, et le problème que ça pose, mais de toute façon aucune des deux ne sera appelée.
James Kanze
On Jul 27, 12:39 pm, Mathias Gaunard wrote:
On 27 juil, 09:40, James Kanze wrote:
> Utiliser std::copy, plutôt que memcpy, me semble le minimum.
Le problème de std::copy, c'est qu'en pratique il va faire un memmove et pas un memcpy.
Qu'est-ce que tu raccontes là ? Il ne doit faire ni l'un ni l'autre. Mais il va copier les objets, non des bytes. Ce qui veut dire d'une part qu'il marche avec n'importe quel type d'objet qui supporte la copie correctement, et de l'autre, qu'il y a même des chances qu'il soit plus rapid, parce que le compilateur a plus d'informations. (Il pourrait savoir, par exemple, que les pointeurs sont alignés.)
-- James Kanze (GABI Software) email: 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
On Jul 27, 12:39 pm, Mathias Gaunard <loufo...@gmail.com> wrote:
On 27 juil, 09:40, James Kanze <james.ka...@gmail.com> wrote:
> Utiliser std::copy, plutôt que memcpy, me semble le minimum.
Le problème de std::copy, c'est qu'en pratique il va faire un
memmove et pas un memcpy.
Qu'est-ce que tu raccontes là ? Il ne doit faire ni l'un ni
l'autre. Mais il va copier les objets, non des bytes. Ce qui
veut dire d'une part qu'il marche avec n'importe quel type
d'objet qui supporte la copie correctement, et de l'autre, qu'il
y a même des chances qu'il soit plus rapid, parce que le
compilateur a plus d'informations. (Il pourrait savoir, par
exemple, que les pointeurs sont alignés.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
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
> Utiliser std::copy, plutôt que memcpy, me semble le minimum.
Le problème de std::copy, c'est qu'en pratique il va faire un memmove et pas un memcpy.
Qu'est-ce que tu raccontes là ? Il ne doit faire ni l'un ni l'autre. Mais il va copier les objets, non des bytes. Ce qui veut dire d'une part qu'il marche avec n'importe quel type d'objet qui supporte la copie correctement, et de l'autre, qu'il y a même des chances qu'il soit plus rapid, parce que le compilateur a plus d'informations. (Il pourrait savoir, par exemple, que les pointeurs sont alignés.)
-- James Kanze (GABI Software) email: 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
