Bonjour a tous,
je debute en c++ et je ne trouve pas de reponse a une question :
je dispose d'une classe Vector1D ou il n'y a pas de constructeur par
default :
template<class K> class Vector1D
{
private:
unsigned int dim;
K *t;
public:
Vector1D(unsigned int dim):dim(dim),t(new K[dim])
{
assert(t);
}
Pour creer une classe Vector2D<K> je souhaite declarer un tableaux de
Vector1D<K>. Je connais la syntaxe type *toto = new type[NBITEM]
mais exise-t-il une syntaxe ou un moyen d'utiliser un autre constructeur
que le constructeur par default pour ne pas faire un truc du genre:
Vector1D<K> *t = new Vector1D<K>[NBITEM];
for(int i; i<NBITEM;i++)
{
/*Initialiser les donnees membres de t[i] avec le parametre dim*/
}
mais plutot :
je sais que cette syntaxe et fausse mais elle est porteuse de sens ...
Vector1D<K> *t= new Vector1D<K>(dim)[NBITEM];
bien a vous,
Seb
--
int main(){int j=1234,putchar();char t[]=":@abcdefghij-lmnopqrstuv"
"wxyz.\n",*i="@jq:.pn.q:ibf.gd\noz.dn@ew\nlwh-i",*strchr();while(*i)
{j+=strchr(t,*i++)-t;j%=sizeof t-1;putchar(t[j]);}return 0;}
'memcpy' n'est pas approprié pour copier des objets de n'importe quel type ! (Par exemple, imagine que tu instancies ton template avec 'Vector1D<double>' pour 'K' - où vont-ils pointer 'v.t[0].t' et 'this->t[0].t' ? Que se passe-t-il avec '*this' lorsque 'v' sera modifié, ou pire, détruit après cette affectation [ou vice-versa] ?) Faire plutôt :
std::copy(v.t, v.t + dim, t);
Avec un bon compilo, 'std::copy' est spécialisé afin d'utiliser 'memcpy' en interne pour les types pour lesquels cela est possible, de manière à ne pas perdre en performance.
Avec un bon compilo, « std::copy » serait d'office plus rapide que memcpy.
Avec certains compilos, memcpy est en fait un macro qui se résoud en quelque chose comme __builtin_memcpy. Dans ces cas-là, memcpy risque d'être plus rapide. Sinon, memcpy est une fonction isolée qui doit traiter tous les cas possibles (adresses non alignées, longueurs impaires...). Typiquement, en revanche, std::copy est une fonction inline, que le compilateur génère en place, avec toutes les informations nécessaires. Donc, si la longueur n'est pas élevée, et les adresses sont alignées (choses que le compilateur sait souvent), il est probable sur une architecture CISC que le compilateur ne génère aucune boucle, mais ce contente que quelques load/store en ligne.
-- 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
Falk Tannhäuser <falk.tannhauser@crf.canon.fr> wrote in message
news:<40F26DD1.1C866B6B@crf.canon.fr>...
docCarcass wrote:
template<class K> class Vector1D
{
private:
unsigned int dim;
K *t;
public:
Vector1D(unsigned int dim):dim(dim),t(new K[dim])
{
assert(t);
}
'memcpy' n'est pas approprié pour copier des objets de n'importe quel
type ! (Par exemple, imagine que tu instancies ton template avec
'Vector1D<double>' pour 'K' - où vont-ils pointer 'v.t[0].t' et
'this->t[0].t' ? Que se passe-t-il avec '*this' lorsque 'v' sera
modifié, ou pire, détruit après cette affectation [ou vice-versa] ?)
Faire plutôt :
std::copy(v.t, v.t + dim, t);
Avec un bon compilo, 'std::copy' est spécialisé afin d'utiliser
'memcpy' en interne pour les types pour lesquels cela est possible, de
manière à ne pas perdre en performance.
Avec un bon compilo, « std::copy » serait d'office plus rapide que
memcpy.
Avec certains compilos, memcpy est en fait un macro qui se résoud en
quelque chose comme __builtin_memcpy. Dans ces cas-là, memcpy risque
d'être plus rapide. Sinon, memcpy est une fonction isolée qui doit
traiter tous les cas possibles (adresses non alignées, longueurs
impaires...). Typiquement, en revanche, std::copy est une fonction
inline, que le compilateur génère en place, avec toutes les informations
nécessaires. Donc, si la longueur n'est pas élevée, et les adresses sont
alignées (choses que le compilateur sait souvent), il est probable sur
une architecture CISC que le compilateur ne génère aucune boucle, mais
ce contente que quelques load/store en ligne.
--
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
'memcpy' n'est pas approprié pour copier des objets de n'importe quel type ! (Par exemple, imagine que tu instancies ton template avec 'Vector1D<double>' pour 'K' - où vont-ils pointer 'v.t[0].t' et 'this->t[0].t' ? Que se passe-t-il avec '*this' lorsque 'v' sera modifié, ou pire, détruit après cette affectation [ou vice-versa] ?) Faire plutôt :
std::copy(v.t, v.t + dim, t);
Avec un bon compilo, 'std::copy' est spécialisé afin d'utiliser 'memcpy' en interne pour les types pour lesquels cela est possible, de manière à ne pas perdre en performance.
Avec un bon compilo, « std::copy » serait d'office plus rapide que memcpy.
Avec certains compilos, memcpy est en fait un macro qui se résoud en quelque chose comme __builtin_memcpy. Dans ces cas-là, memcpy risque d'être plus rapide. Sinon, memcpy est une fonction isolée qui doit traiter tous les cas possibles (adresses non alignées, longueurs impaires...). Typiquement, en revanche, std::copy est une fonction inline, que le compilateur génère en place, avec toutes les informations nécessaires. Donc, si la longueur n'est pas élevée, et les adresses sont alignées (choses que le compilateur sait souvent), il est probable sur une architecture CISC que le compilateur ne génère aucune boucle, mais ce contente que quelques load/store en ligne.
-- 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
usenet
Fabien LE LEZ wrote in message news::
En plus des réponses données : cherche "placement new" dans ton manuel. Note de traduction : dans (une vieille) VF du Stroustrup ils parlent de "syntaxe de placement" (section 10.4.11). C'est assez tordu, à tel point que je n'ai jamais eu l'occasion de l'utiliser,
Bof. On connait l'adresse à laquelle placer un objet. Mis à part ce point, on souhaite utiliser la sémantique du new sans placement. Ce n'est pas utile au quotidien, mais ce n'est pas vraiment tordu.
mais il me semble que c'est ce qu'utilise std::vector<>.
Tiens. Je n'arrive pas à voir pour quoi. Tu pense à quelque chose en particulier ?
--drkm
Fabien LE LEZ wrote in message news:<arcue0la4mh346ebqg4ppd7813lp8tu17d@4ax.com>:
En plus des réponses données : cherche "placement new" dans ton
manuel.
Note de traduction : dans (une vieille) VF du Stroustrup ils parlent
de "syntaxe de placement" (section 10.4.11).
C'est assez tordu, à tel point que je n'ai jamais eu l'occasion de
l'utiliser,
Bof. On connait l'adresse à laquelle placer un objet. Mis à part
ce point, on souhaite utiliser la sémantique du new sans placement.
Ce n'est pas utile au quotidien, mais ce n'est pas vraiment tordu.
mais il me semble que c'est ce qu'utilise std::vector<>.
Tiens. Je n'arrive pas à voir pour quoi. Tu pense à quelque chose
en particulier ?
En plus des réponses données : cherche "placement new" dans ton manuel. Note de traduction : dans (une vieille) VF du Stroustrup ils parlent de "syntaxe de placement" (section 10.4.11). C'est assez tordu, à tel point que je n'ai jamais eu l'occasion de l'utiliser,
Bof. On connait l'adresse à laquelle placer un objet. Mis à part ce point, on souhaite utiliser la sémantique du new sans placement. Ce n'est pas utile au quotidien, mais ce n'est pas vraiment tordu.
mais il me semble que c'est ce qu'utilise std::vector<>.
Tiens. Je n'arrive pas à voir pour quoi. Tu pense à quelque chose en particulier ?
--drkm
Arnaud Meurgues
drkm wrote:
[placement new]
mais il me semble que c'est ce qu'utilise std::vector<>. Tiens. Je n'arrive pas à voir pour quoi. Tu pense à quelque chose
en particulier ?
std::vector<> préalloue de la mémoire pour pouvoir s'agrandir sans faire une allocation à chaque fois que le vecteur s'agrandit. Ensuite, il place les nouveaux objets dans la mémoire déjà allouée.
-- Arnaud (Supprimez les geneurs pour me répondre)
drkm wrote:
[placement new]
mais il me semble que c'est ce qu'utilise std::vector<>.
Tiens. Je n'arrive pas à voir pour quoi. Tu pense à quelque chose
en particulier ?
std::vector<> préalloue de la mémoire pour pouvoir s'agrandir sans faire
une allocation à chaque fois que le vecteur s'agrandit. Ensuite, il
place les nouveaux objets dans la mémoire déjà allouée.
--
Arnaud
(Supprimez les geneurs pour me répondre)
mais il me semble que c'est ce qu'utilise std::vector<>. Tiens. Je n'arrive pas à voir pour quoi. Tu pense à quelque chose
en particulier ?
std::vector<> préalloue de la mémoire pour pouvoir s'agrandir sans faire une allocation à chaque fois que le vecteur s'agrandit. Ensuite, il place les nouveaux objets dans la mémoire déjà allouée.
-- Arnaud (Supprimez les geneurs pour me répondre)
drkm
Arnaud Meurgues writes:
drkm wrote:
[placement new]
mais il me semble que c'est ce qu'utilise std::vector<>. Tiens. Je n'arrive pas à voir pour quoi. Tu pense à quelque chose
en particulier ?
std::vector<> préalloue de la mémoire pour pouvoir s'agrandir sans faire une allocation à chaque fois que le vecteur s'agrandit. Ensuite, il place les nouveaux objets dans la mémoire déjà allouée.
La prochaine fois, je réfléchirai avant de poster ;-(
mais il me semble que c'est ce qu'utilise std::vector<>.
Tiens. Je n'arrive pas à voir pour quoi. Tu pense à quelque chose
en particulier ?
std::vector<> préalloue de la mémoire pour pouvoir s'agrandir sans
faire une allocation à chaque fois que le vecteur s'agrandit. Ensuite,
il place les nouveaux objets dans la mémoire déjà allouée.
La prochaine fois, je réfléchirai avant de poster ;-(
mais il me semble que c'est ce qu'utilise std::vector<>. Tiens. Je n'arrive pas à voir pour quoi. Tu pense à quelque chose
en particulier ?
std::vector<> préalloue de la mémoire pour pouvoir s'agrandir sans faire une allocation à chaque fois que le vecteur s'agrandit. Ensuite, il place les nouveaux objets dans la mémoire déjà allouée.
La prochaine fois, je réfléchirai avant de poster ;-(
Merci.
--drkm
Alain Naigeon
"drkm" a écrit dans le message news:
La prochaine fois, je réfléchirai avant de poster ;-(
C'est une décision héroïque, alors que souvent l'on poste pour éviter de réfléchir :-)
--
Français *==> "Musique renaissance" <==* English midi - facsimiles - ligatures - mensuration http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/ Alain Naigeon - - Strasbourg, France
"drkm" <usenet.fclcxx@fgeorges.org> a écrit dans le message news:
wkbrikb5bf.fsf@fgeorges.org...
La prochaine fois, je réfléchirai avant de poster ;-(
C'est une décision héroïque, alors que souvent l'on
poste pour éviter de réfléchir :-)
--
Français *==> "Musique renaissance" <==* English
midi - facsimiles - ligatures - mensuration
http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/
Alain Naigeon - anaigeon@free.fr - Strasbourg, France
