bonjour, jaimerai savoir si new est lent ? et si delete est lent aussi?
Par rapport a quoi? Ca doit avoir a peut de choses pres la meme vitesse que malloc et free.
Les expressions new T et delete p declanchent aussi des appels aux constructeurs et destructeurs, ce qui peut prendre du temps.
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" <qsdqd@sss.ss> writes:
bonjour, jaimerai savoir si new est lent ?
et si delete est lent aussi?
Par rapport a quoi? Ca doit avoir a peut de choses pres la meme
vitesse que malloc et free.
Les expressions
new T
et
delete p
declanchent aussi des appels aux constructeurs et destructeurs, ce qui
peut prendre du temps.
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
bonjour, jaimerai savoir si new est lent ? et si delete est lent aussi?
Par rapport a quoi? Ca doit avoir a peut de choses pres la meme vitesse que malloc et free.
Les expressions new T et delete p declanchent aussi des appels aux constructeurs et destructeurs, ce qui peut prendre du temps.
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
Julien Lamy
dark poulpo wrote:
bonjour, jaimerai savoir si new est lent ? et si delete est lent aussi?
Ca dépend :-) new alloue la mémoire (par exemple avec malloc), et appelle le constructeur de l'objet. delete appelle le destructeur et libère la mémoire. Donc si tes constructeurs et ton destructeur font des calculs de folie pendant des heures, new et delete seront lents. Si le constructeur se contente d'initialiser un entier et que le desctructeur ne fait rien, je ne vois pas de raison pour qu'ils soient lents. -- Julien (enlever le NOSPAM pour répondre)
dark poulpo wrote:
bonjour, jaimerai savoir si new est lent ?
et si delete est lent aussi?
Ca dépend :-)
new alloue la mémoire (par exemple avec malloc), et appelle le
constructeur de l'objet. delete appelle le destructeur et libère la mémoire.
Donc si tes constructeurs et ton destructeur font des calculs de folie
pendant des heures, new et delete seront lents. Si le constructeur se
contente d'initialiser un entier et que le desctructeur ne fait rien, je
ne vois pas de raison pour qu'ils soient lents.
--
Julien
(enlever le NOSPAM pour répondre)
bonjour, jaimerai savoir si new est lent ? et si delete est lent aussi?
Ca dépend :-) new alloue la mémoire (par exemple avec malloc), et appelle le constructeur de l'objet. delete appelle le destructeur et libère la mémoire. Donc si tes constructeurs et ton destructeur font des calculs de folie pendant des heures, new et delete seront lents. Si le constructeur se contente d'initialiser un entier et que le desctructeur ne fait rien, je ne vois pas de raison pour qu'ils soient lents. -- Julien (enlever le NOSPAM pour répondre)
dark poulpo
c surtout pour faire des new char[xx] et des delete [] ... mais oui jen aurais enormement, car c'est pour un interpreteur de script. si effectievment vous em dites que c lent je passerai au plan b
"Julien Lamy" a écrit dans le message de news:conefc$kgg$
dark poulpo wrote:
bonjour, jaimerai savoir si new est lent ? et si delete est lent aussi?
Ca dépend :-) new alloue la mémoire (par exemple avec malloc), et appelle le constructeur de l'objet. delete appelle le destructeur et libère la mémoire.
Donc si tes constructeurs et ton destructeur font des calculs de folie pendant des heures, new et delete seront lents. Si le constructeur se contente d'initialiser un entier et que le desctructeur ne fait rien, je ne vois pas de raison pour qu'ils soient lents. -- Julien (enlever le NOSPAM pour répondre)
c surtout pour faire des new char[xx] et des delete [] ...
mais oui jen aurais enormement, car c'est pour un interpreteur de script.
si effectievment vous em dites que c lent je passerai au plan b
"Julien Lamy" <julien.NOSPAMlamy@ircad.u-strasbg.fr> a écrit dans le message
de news:conefc$kgg$1@news.u-strasbg.fr...
dark poulpo wrote:
bonjour, jaimerai savoir si new est lent ?
et si delete est lent aussi?
Ca dépend :-)
new alloue la mémoire (par exemple avec malloc), et appelle le
constructeur de l'objet. delete appelle le destructeur et libère la
mémoire.
Donc si tes constructeurs et ton destructeur font des calculs de folie
pendant des heures, new et delete seront lents. Si le constructeur se
contente d'initialiser un entier et que le desctructeur ne fait rien, je
ne vois pas de raison pour qu'ils soient lents.
--
Julien
(enlever le NOSPAM pour répondre)
c surtout pour faire des new char[xx] et des delete [] ... mais oui jen aurais enormement, car c'est pour un interpreteur de script. si effectievment vous em dites que c lent je passerai au plan b
"Julien Lamy" a écrit dans le message de news:conefc$kgg$
dark poulpo wrote:
bonjour, jaimerai savoir si new est lent ? et si delete est lent aussi?
Ca dépend :-) new alloue la mémoire (par exemple avec malloc), et appelle le constructeur de l'objet. delete appelle le destructeur et libère la mémoire.
Donc si tes constructeurs et ton destructeur font des calculs de folie pendant des heures, new et delete seront lents. Si le constructeur se contente d'initialiser un entier et que le desctructeur ne fait rien, je ne vois pas de raison pour qu'ils soient lents. -- Julien (enlever le NOSPAM pour répondre)
Gabriel Dos Reis
"dark poulpo" writes:
| c surtout pour faire des new char[xx] et des delete [] ...
Une raison particuliere pour ne pas utiliser std::vector<char> ?
| mais oui jen aurais enormement, car c'est pour un interpreteur de script. | si effectievment vous em dites que c lent je passerai au plan b
qui est ?
-- Gaby
"dark poulpo" <qsdqd@sss.ss> writes:
| c surtout pour faire des new char[xx] et des delete [] ...
Une raison particuliere pour ne pas utiliser std::vector<char> ?
| mais oui jen aurais enormement, car c'est pour un interpreteur de script.
| si effectievment vous em dites que c lent je passerai au plan b
| c surtout pour faire des new char[xx] et des delete [] ...
Une raison particuliere pour ne pas utiliser std::vector<char> ?
| mais oui jen aurais enormement, car c'est pour un interpreteur de script. | si effectievment vous em dites que c lent je passerai au plan b
qui est ?
-- Gaby
Fabien LE LEZ
On Thu, 2 Dec 2004 17:14:23 +0100, "dark poulpo" :
c
C'est. Et ne réponds pas à l'envers -- cf <http://www.giromini.org/usenet-fr/repondre.html>.
surtout pour faire des new char[xx] et des delete [] ...
Bvarf... Utilise donc std::string et laisse-le faire le travail -- il y a de bonnes chances pour qu'il s'en sorte bien mieux que si tu bricoles avec des char[].
-- ;-)
On Thu, 2 Dec 2004 17:14:23 +0100, "dark poulpo" <qsdqd@sss.ss>:
c
C'est.
Et ne réponds pas à l'envers -- cf
<http://www.giromini.org/usenet-fr/repondre.html>.
surtout pour faire des new char[xx] et des delete [] ...
Bvarf... Utilise donc std::string et laisse-le faire le travail -- il
y a de bonnes chances pour qu'il s'en sorte bien mieux que si tu
bricoles avec des char[].
On Thu, 2 Dec 2004 17:14:23 +0100, "dark poulpo" :
c
C'est. Et ne réponds pas à l'envers -- cf <http://www.giromini.org/usenet-fr/repondre.html>.
surtout pour faire des new char[xx] et des delete [] ...
Bvarf... Utilise donc std::string et laisse-le faire le travail -- il y a de bonnes chances pour qu'il s'en sorte bien mieux que si tu bricoles avec des char[].
-- ;-)
Arnaud Meurgues
dark poulpo wrote:
c surtout pour faire des new char[xx] et des delete [] ... mais oui jen aurais enormement, car c'est pour un interpreteur de script. si effectievment vous em dites que c lent je passerai au plan b
Je ne vois pas trop pourquoi ce serait spécialement plus lent que malloc.
De plus, on peut fort bien imaginer que les performances dépendent de la plateforme et/ou du compilateur. Le mieux est donc de faire des tests de performance.
-- Arnaud (Supprimez les geneurs pour me répondre)
dark poulpo wrote:
c surtout pour faire des new char[xx] et des delete [] ...
mais oui jen aurais enormement, car c'est pour un interpreteur de script.
si effectievment vous em dites que c lent je passerai au plan b
Je ne vois pas trop pourquoi ce serait spécialement plus lent que malloc.
De plus, on peut fort bien imaginer que les performances dépendent de la
plateforme et/ou du compilateur. Le mieux est donc de faire des tests de
performance.
--
Arnaud
(Supprimez les geneurs pour me répondre)
c surtout pour faire des new char[xx] et des delete [] ... mais oui jen aurais enormement, car c'est pour un interpreteur de script. si effectievment vous em dites que c lent je passerai au plan b
Je ne vois pas trop pourquoi ce serait spécialement plus lent que malloc.
De plus, on peut fort bien imaginer que les performances dépendent de la plateforme et/ou du compilateur. Le mieux est donc de faire des tests de performance.
-- Arnaud (Supprimez les geneurs pour me répondre)
dark poulpo
"Fabien LE LEZ" a écrit dans le message de news:
On Thu, 2 Dec 2004 17:14:23 +0100, "dark poulpo" :
c
C'est. Et ne réponds pas à l'envers -- cf <http://www.giromini.org/usenet-fr/repondre.html>.
surtout pour faire des new char[xx] et des delete [] ...
Bvarf... Utilise donc std::string et laisse-le faire le travail -- il y a de bonnes chances pour qu'il s'en sorte bien mieux que si tu bricoles avec des char[].
bein non,parceque je faisdesnew char[]mais c pas forcement pour y mettre du
text, mais ca peut servir comme simple data pour des octets
"Fabien LE LEZ" <gramster@gramster.com> a écrit dans le message de
news:aohuq0td4i4hjcfaj7lmckd4qrt3d0s5lk@4ax.com...
On Thu, 2 Dec 2004 17:14:23 +0100, "dark poulpo" <qsdqd@sss.ss>:
c
C'est.
Et ne réponds pas à l'envers -- cf
<http://www.giromini.org/usenet-fr/repondre.html>.
surtout pour faire des new char[xx] et des delete [] ...
Bvarf... Utilise donc std::string et laisse-le faire le travail -- il
y a de bonnes chances pour qu'il s'en sorte bien mieux que si tu
bricoles avec des char[].
bein non,parceque je faisdesnew char[]mais c pas forcement pour y mettre du
text, mais ca peut servir comme simple data pour des octets
On Thu, 2 Dec 2004 17:14:23 +0100, "dark poulpo" :
c
C'est. Et ne réponds pas à l'envers -- cf <http://www.giromini.org/usenet-fr/repondre.html>.
surtout pour faire des new char[xx] et des delete [] ...
Bvarf... Utilise donc std::string et laisse-le faire le travail -- il y a de bonnes chances pour qu'il s'en sorte bien mieux que si tu bricoles avec des char[].
bein non,parceque je faisdesnew char[]mais c pas forcement pour y mettre du
text, mais ca peut servir comme simple data pour des octets
Gabriel Dos Reis
"dark poulpo" writes:
| bein non,parceque je faisdesnew char[]mais c pas forcement pour y mettre du | text, mais ca peut servir comme simple data pour des octets
Alors:
typedef unsigned char byte; std::vector<byte>
-- Gaby
"dark poulpo" <qsdqd@sss.ss> writes:
| bein non,parceque je faisdesnew char[]mais c pas forcement pour y mettre du
| text, mais ca peut servir comme simple data pour des octets
| c surtout pour faire des new char[xx] et des delete [] ...
Une raison particuliere pour ne pas utiliser std::vector<char> ?
oui, car je dois faire des *((long/float/vecteur/matrice *)data) ( data sera initilaisé par les new char[])
| mais oui jen aurais enormement, car c'est pour un interpreteur de script.
| si effectievment vous em dites que c lent je passerai au plan b
qui est ?
de remplacer 90% des utilisations de new pas des char data[16*4]; qui seront la taille max pour tout les types predefinis. mais la on secarte.
James Kanze
Arnaud Meurgues writes:
|> dark poulpo wrote: |> > c surtout pour faire des new char[xx] et des delete [] ... mais |> > oui jen aurais enormement, car c'est pour un interpreteur de |> > script. si effectievment vous em dites que c lent je passerai au |> > plan b
|> Je ne vois pas trop pourquoi ce serait spécialement plus lent que |> malloc.
|> De plus, on peut fort bien imaginer que les performances dépendent |> de la plateforme et/ou du compilateur. Le mieux est donc de faire |> des tests de performance.
Dans le temps, on « savait » tous que l'allocation dynamique était chère. Mais c'était dans le temps -- je sais qu'aujourd'hui, la seule raison de s'en passer, c'est la fiabilité.
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
|> dark poulpo wrote:
|> > c surtout pour faire des new char[xx] et des delete [] ... mais
|> > oui jen aurais enormement, car c'est pour un interpreteur de
|> > script. si effectievment vous em dites que c lent je passerai au
|> > plan b
|> Je ne vois pas trop pourquoi ce serait spécialement plus lent que
|> malloc.
|> De plus, on peut fort bien imaginer que les performances dépendent
|> de la plateforme et/ou du compilateur. Le mieux est donc de faire
|> des tests de performance.
Dans le temps, on « savait » tous que l'allocation dynamique était
chère. Mais c'était dans le temps -- je sais qu'aujourd'hui, la seule
raison de s'en passer, c'est la fiabilité.
--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
|> dark poulpo wrote: |> > c surtout pour faire des new char[xx] et des delete [] ... mais |> > oui jen aurais enormement, car c'est pour un interpreteur de |> > script. si effectievment vous em dites que c lent je passerai au |> > plan b
|> Je ne vois pas trop pourquoi ce serait spécialement plus lent que |> malloc.
|> De plus, on peut fort bien imaginer que les performances dépendent |> de la plateforme et/ou du compilateur. Le mieux est donc de faire |> des tests de performance.
Dans le temps, on « savait » tous que l'allocation dynamique était chère. Mais c'était dans le temps -- je sais qu'aujourd'hui, la seule raison de s'en passer, c'est la fiabilité.
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
