Quand on créer une variable CString, elle aloue de la mémoire a une autre variable de type LPTSTR (ou dans le genre).  
Mais je voudrais bien savoir quand est-ce que celle-ci est détruite (il faut bien). Dans le destructeur ? oui mais pas quand on passer cette var Cstring a une autre LPTSTR. Dans ce cas, où la mémoire est elle libéré ?

dans le cas d'une string la methode c_str() renvoie un const char* qui est alloue dans l'objet. c'est l'objet qui a la charge de desallouer cette memoire, donc au plus tard dans le destructeur.
les methodes qui utilisent ce char* doivent en tenir compte et eventuellement faire une copie de la chaine.
 
J'imagine qu'avec les Cstring c'est la meme chose.

je sais que dans CString ya un sys d'incrémentation pour la variable qui est partagé.
Celle-ci est détruite uniquement si la var d'incrémentation est égale à zero.  
Mais par exemple:
 
CString func()
{
    CString t;
    t = "salut";
    return t;
}
 
ca marche mais comment CString sait qu'il faut incrémenter a ce moment ? car le destructeur devrai détruire la variable comme elle n'a qu'une seule ref.

Quel compteur de reference... Je ne pense pas qu'il y ai de pointeur intelligent dans les CString.
Ton exemple de code c'est du C++ standard.
 
au return est cree une copie de t par le constructeur de copie Cstring(const CString&) qui est automatiquement genere si il n'a pas ete defini. cette copie est passe en sortie et t est detruit.
 
Il n'y a rien de sorcier...

non c pas comme ca.
CString possède un pointeur de LPTSTR. Quand CString est copié, elle copy le pointeur et non pas la chaine.
Je suis sur quil ya une variable d'incrémentation mais je voudrai savoir quand elle est incrémenter

Si il y a une variable d'incrémentation, elle est modifié dans les constructeurs et destructeurs.
 
CString func()  
                {  
                    CString t; // refcount = 1
                    t = "salut";  
                    return t; // construction par copie d'un temporaire pour la valuer de retour, refcount = 2  
               } // destruction de t, refcount = 1

C'est l'implementation ca, il pourrait la copier ca ne changerait pas gd chose (sauf en perf)
 
mais si tu obtiens le LPTSTR (char * je suppose) puis que tu dtruits le CString... ton pointeur il n'est plus bon...

Si parce que le destructeur ne va pas libérer la mémoire du buffer sous jacent si refcount != 0.

Je suis desolee...
 
Je me suis mal fait comprendre...
si tu fait
CString *Var1 =new CString( "J'ai raison" );
char *Var2 = Var1.ceQuilfaut();
delete Var1;
 
ben Var2 y pointe sur n'importe quoi...

Certes mais c'est pas comme ça qu'il faut s'en servir, tu mixes un pointeur bête et un objet encapsulant un buffer et tu fais exprès de contourner le mécanisme de comptage de référence
En plus MS déconseille d'allouer des Cstring sur le tas.

Dis le que je fais rien qu'a t'embetter...
En fait je n'ai jamais utilise de CString et je pensais en fait a :
string *var1 = new string("meme quand j'ai tors" );
char *var2 = var1->c_str();
delete var1;
 
et ce qui m'y a fait penser c'est la phrase :
"mais pas quand on passer cette var Cstring a une autre LPTSTR."

comment il fait ca ? c dans un contructeur ? un operateur ?lekel ?

si c le constructeur pale je pense pas qu'il est appelé quand on utilise return

Comme ta fonction retourne un objet Cstring, le constructeur est appelé pour le fabriquer au retour de la fonction. Ce n'est pas t qui est retourné mais un cstring construit par copie.

ca va pas:
 
Test Get()
{
    Test g;
    return g;
}
 
int main()
{
    Test t;
    t = Get();
};
 
le prog fait comme çà :
- constructeur de t;
- constructeur de g;
- return;
- destructeur de g;
- operateur= de t avec g (mais ki est détuit !);
- destructeur de g;
- destructeur de t;
 
donc après return ya le destructeur et la variable ne s'incrémente pas avec l'op= de Test.
aussi juste après return, la variable est détruite en ayant qu'une ref. et l'égale possède un g dont le pointeur interne a été détruit.
 
Comment fait CString puisque la var n'est pas détruite après return ?

Non le compilo c++ ajoute des trucs dans ton dos, il est malin.
La séquence est :
- constructeur de t;  
- constructeur de g;  
- constructeur de temp par copie  
- destructeur de g;  
- operateur= de t avec temp  
- destructeur de temp  
- destructeur de t;

c koi l'implementation du constructeur de temp par copie.
C surement pas Test() j'ai essayer.
j'ai trouvé l'ordre en metant des printf dans chaque impl.

Si tu ne donnes pas de constructeur par copie, le compilo le génère lui-même.
 
Ajoute le constructeur suivant et tu verras:
Test(const Test& ){printf("Constructeur par copie\n" );}

[edit]--Message édité par Verdoux--[/edit]

Merci je l'avais complétement oublier celui là.
En fait, je voulai faire une classe  semblable à CString car je déteste MFC.

>Non le compilo c++ ajoute des trucs dans ton dos, il est malin.  
 
Oui, le compilo il fait ce que le standard lui dit de faire. Je te conseille de relire The C++ Programming Language de Stroustrup (3e edition) a la section 11.3.4 au sujet du default copy constructor.
A+,

Pourquoi ne pas utiliser la strinb STL plutot que de faire quelque chose qui a deja ete fait plusieurs fois ?