Hello,

une petite question

soit le code suivant :

C'est valide de faire un delete d'une référence, comme c'est fait dans le code ?
valide, mais en pratique on ne code jamais comme ça ?

Merci !

tu va deleter l'adresse de l'objet en référene c'est tout

tu veux dire qu'il va y avoir une memory leak ?

oui c'est bon ça marche.
pour mémoire, delete a comme prototype
 

 
donc si tu lui passe l'adresse d'un objet créé avec new (c'est le cas ici), il va le détruire.
Tu peux t'en convaincre avec un code du genre:
 

 
tu compiles avec un coup de `make main` (avec GNU make) ou `g++ -o main main.cpp`,
chez moi ça donne:

 
Par contre j'ai rarement vu ça dans du code de prod (c'est plutôt un cas d'école). En général, on préfère garder les pointeurs,
ne serait-ce que parce que ça permet de voir tout de suite quels objets sont alloués dynamiquement.

Merci , c'est bien ce que je pensais.
je suis surpris de voir que Joel  s'est "vautré" sur ce coup là

c'ets bien ce que j'ai dit ... tu vas detruire le truc que tu references .. ou alors j'ai aps compris la question la fois d'avant :E

Joel n'avait pas tort dans sa réponse...
C'est pas très propre comme syntaxe, c'est même trompeur puisque les références sont rarement utilisées pour garder le "ownership" d'un pointeur, mais c'est conforme.

c'est ça qui est space dans ce langage, qu'il faille jongler entre deux syntaxes , pour désigner la même chose.
ça laisse tout de même un sentiment de concept "pas très carré"

non, juste que les pointeurs sont là pour la compatibilité avec le C.
Le vrai truc à utilisé serait les références et des trucs comme des shared_ptr.
Les pointeurs sont pas aprce que personne n'a eu le courage de jeter C aux orties en créant C++.
 
Et c'est pas 'pas carré', c'ets "expressif"

hum, en meme temps je trouve ça bien qu'on puisse encore coder en C-like dans une app C++, quand les perf sont recherchées, ça reste un bon compromis, le C pur c'est un peu sec pour des grosses app...

les perfs du C++ sont équivalentes à celle du C hein :E

bah à partir du moment ou le C++ wrappe les fonctions du C...je vois mal comment
cf string vs char* , IO du C++ vs IO du C, vector vs tableau à la C etc

bah rencadre toi, fais des benchs et arrete de croire
j'ai passé ma thèse à bencher ce genre de chose. L'overhead est indiscernable du bruit sur le temps systeme ...

ça c'est sick quand même

je le repete. Arretez de croire, benchez

mais y a pas des bons liens à ce sujet sur le net? , je trouve rien de vraiment complet..

Un lien vers ta thèse ?
Ca m'interresse

C'ets sur ma page pro
par contre, je sais plus si c'ets dedans ou si ca fait parti des trucs fait mais pas rédigé. Je vais vori à remettre la main sur les benchs.

ben donne moi le titre et l'abstract au moins

http://www.lri.fr/~falcou/#[[Formation%20Doctorale]]

ok j'ai vu ça, merci !
Mentien TH en 2006, elles n'ont pas été supprimées les mentions sur les thèses ??

y en a pls que 3 : rien , honorable, TH.
autant te dire que rien, t'es pas frais.
 
C'est les feloches du jury qui ont disparu formellement même si on lesz reçoit informellement

c'est les frères Bogdanov qui ont eu "rien", non ?
merci pour le lien en tt cas

 
Le C est plus rapide. fait un test entre du code qui utilise du char* et un code qui utilise du string, tu verras que le le char étoilé consomme moins de millisecondes....

une preuve ? des benchs ? Du C++ correctment écrit n'est pas plus lent hein :E

Prends le code que j'ai posté dans ostream vide/bidon
change la foction getTimer en string
Utilise ça comme main :
 
#include <windows.h>
int main(int arv,char** argv)
{  
    LARGE_INTEGER start, end, freq;
    double elapsed;    
    QueryPerformanceFrequency(&freq);    
    QueryPerformanceCounter(&start);    
 
 for(int i=0;i<10000;i++)
 {  
  WriteLog(DEBUG) << "debug";
   WriteLog(CRITIQUE) << "critique";  
 }
 WriteLog(FLUSH);
 
 
 QueryPerformanceCounter(&end);                                  
    elapsed = (1000.0 * (end.QuadPart - start.QuadPart)) / freq.QuadPart;  
    printf("%.0f millisecondes entre start et end.\n", elapsed);    
 system("pause" );
}
 
et constate que le cahr * consomme moins de milliseconde que le string
 
===> Le C est plus rapide que le C++, CQFD
 

si tu renvois une string par copie c'ets normal. Mais bon, en principe on renverra pas ça comme ça mais via un const &
En outre c'ets un pb qui disparait avec les rvalue reference.

Ensuite tu apprendras que un cas particuliers ne fait pas une preuve et que bencher de i/o n'a pas de sens.

bah t'as des bench des liens qui confirme ce que tu dis ?

Le probleme ets de trouvée une base qui a du sens. C'ets bien le pb de tout ces benchs inter-langages, tout le monde triche en ecrivant du code hyper moche.

* Articles ou on voit que la comparaison ets necessairement biaisée :
http://unthought.net/c++/c_vs_c++.html
http://www.objectmentor.com/resour [...] UsingC.pdf

* Le Technical Report sur les perfs mandées par le stadnard :
http://anubis.dkuug.dk/jtc1/sc22/w [...] /n1430.pdf

* En vrac :
http://groups.google.com/groups?se [...] .dfncis.de
http://news.gmane.org/gmane.comp.lang.c++.perfometer/
news://news.gmane.org/gmane.comp.lang.c++.perfometer
http://www.eventhelix.com/Realtime [...] rmance.htm
http://www.eventhelix.com/Realtime [...] mance2.htm
http://www.eventhelix.com/Realtime [...] PPCode.htm

En gros, sur de vrais noyeaux applciatifs, l'overhead n'est guère enorme sauf si on code comme des cochons (pas de references, copies à tout va etc)

EDIT :
J'oubliais le boulot de Veldhuizen :
http://ubiety.uwaterloo.ca/~tveldh [...] index.html
http://ubiety.uwaterloo.ca/~tveldh [...] echniques/
http://ubiety.uwaterloo.ca/~tveldh [...] ascon95.ps