Re: Une question

non pas dur du tout, en fait pour la lib en question, il n'y meme aucune, zero, nada specification de duree de vie, le compilateur gere tout tout seul.

Grosso modo, mais attention je suis neophyte en C++ et rust donc si des personnes plus experimentees peuvent confirmer, je suis preneur:

• pour tous les cas facile, rust se debrouille tres bien sans aucune indication supplementaire par exemple si tu fais

fn create_vector_of_string() -> Vec<String> {
 let mut myvector = Vec::with_capacity(10);
 for i in range(0, 10u) {
 let i_as_string = i.to_string();
 myvector.push(i_as_string);
 }
 return myvector;
}
fn main() {
 for string in create_vector_of_string().iter() {
 println!("{}", string);
 }
}

ici rust est intelligent et devine que myvector a pour unit but d'etre passer en valeur de retour, et donc ne sera pas "copier" (en C++ si je me trompe pour avoir la meme chose on aurait du passer myvector en tant que parametre par reference ?)

pareil pour i_as_string ce qui en c++ aurait du forcer l'utilisation de fonction special de std::vector introduite uniquement recemment

l'exemple un peu plus poilu que j'ai en tete, pour ma lib par exemple qui communique avec C et donc pour laquelle rust a un moment "perd de vue" les donnees, typiquement le probleme est resolu en faisant

fn new_complex_object () -> Box<ComplexObject> {
 // code qui construit et retourne une nouvelle instance de complexe object
} 
fn use_complex_object (instance: &ComplexObject) {
 // utilisation en read only de ComplexObjet
}
fn free_complex_object (instance: Box<ComplexObject) {
 let _ = instance;
}

deja en conversion C, Box et & ont la meme transposition en pointeur, la difference etant uniquement pour rust, Box offrant la garantie qu'on ai le seul a posseder ce pointeur, ce qui veut dire que:

Pour mon new, je dis "le morceau de code qui recupera ma Box en sera le seul et unique detenteur, moi je m'en lave les mains"

Pour mon use je dis "je peux utiliser l'objet temporairement, mais je dois le rendre intacte a celui qui me l'a passe"

et pour mon free je dis "on me passe l'objet et j'en deviens l'unique detenteur, vu que je n'en fais rien, alors je peux le detruire et liberer sa memoire sans creer d'effet de bord"

Apres evidemment il y a des cas plus complexes, mais des lors

• soit en effet on doit utiliser des indicateurs de duree de vie, et ca deviens un poil plus complique, mais une fois que le compilo dit que c'est ok, on est sur que ca marche, alors qu'en C / C++ on a pas besoin de le preciser pour la bonne et unique raison que personne est la pour verifier nos optimisations de magie noire, donc ca peut tres bien nous peter a la gueule
• soit on clone a gogo les objets pour eviter le probleme, certe c'est moins efficaces (plus lent/plus consomatteur de source) mais apres avoir eu son programme qui nous crash 20 fois a la gueule on aurait surement fini par faire pareil en C++

En gros pour moi, Rust n'a que des avantages sur C++ a part evidemment les desavantages du a sa jeunesse (i.e pas encore stable, compilateur n'ayant pas encore recu tout l'amour du monde sur lapartie "optimization pour faire du code rapide comme l'eclair"), surtout du fait qu'on peut tout a fait utiliser les librairies C existanstes depuis Rust.