[C++] Utilizzo sistema con smart pointer: Boost o TR1?

[giuseppe500]

ciao.
vorrei utilizzare un sistema con smart pointers.
il primo problema è :
boost o tr1 o c++ ultima release(mi sembra che li supporti).
uso vs 2010 .
Il secondo problema è: intrusivi o no.
Penso che per gli intrusivi bisogni derivare la classe dalla classe degli intrusive pointer e poi la gestione dei reference counter è automatica, ho utilizato gli smart pointer intrusivi in qualche applicazione opensource.
altrimenti c'è lo shared_ptr che ho visto anche supportato nel tr1, è portabile come boost il tr1?
infine , ho letto che lo weak_ptr serve per i casi in cui la shared_pointer ha riferimenti circolari, sbaglio?ad es un grafo con i child e un parent, ma non ho capito come usarlo in questo caso.
ci sono altri casi in cui il weak_ptr è utile?

grazie.

[shodan]

Usa gli std::shared_ptr quando puoi e i boost::shared_ptr quando devi mantenere un layer di compatibilità con boost. Usa std::unique_ptr se hai bisogno di uno smart pointer senza semantica di condivisione.
Lo weak_ptr serve appunto per evitare riferimenti circolari e l'unico suo scopo è di essere uno smart_pointer di tipo "observer", cioè che guarda cosa succede senza avere voce in capitolo. Mai usato.
Gli intrusive pointer, personalmente, li dimenticherei. Lo standard non li prevede e di fatto sono utili sono con le classi specifiche che li implementano. Il problema maggiore, a mio avviso, è che sono pericolosi da usare in ambito multithreading.
Se usi VS2010 inizia a studiare le rvalue references, lambda function e la move semantics in generale. In giro per la rete ormai si trovano molti esempi riguardo il nuovo standard C++11 e anche se VC++ 2010 ha appena iniziato a implementarlo, le cose importanti le ha.
(Anche se con il prossimo VC++ 2012 potevano sforzarsi un po' di più).

[giuseppe500]

Originariamente inviato da shodan
Gli intrusive pointer, personalmente, li dimenticherei. Lo standard non li prevede e di fatto sono utili sono con le classi specifiche che li implementano. Il problema maggiore, a mio avviso, è che sono pericolosi da usare in ambito multithreading.
Se usi VS2010 inizia a studiare le rvalue references, lambda function e la move semantics in generale.

questo in un ottica di studiare le Parallel Patterns Library (PPL)?
o indipendentemente?
personalmente non ho capito bene le rvalue references e la move semantics(adesso ci ritorno su ,le ho lette in due minuti, sono dell ultimo standard c++?) ma sto studiando le PPL e si usano largamente le lambda functions.

penso che la progettazione multicore sia da imparare oggigiorno con l'hardware che c'è che viene sfruttato al massimo al 50%(penso , ma questa è la mia opinione)

ciao Shodan.

[shodan]

Originariamente inviato da giuseppe500
...o indipendentemente?

Tempo fa lessi un articolo del blog di Raymond Chen (OldNewThing) che trattava lo stesso argomento per gli oggetti COM. Il pericolo è di invocare il metodo add_ref() quando un altro thread ha appena invocato release() sull'ultima istanza valida dell'oggetto COM. Il risultato è un crash. Ed questo ciò a cui mi riferivo. Personalmente non ci vedo nulla di male a usare intrusive_ptr, ma visto che già ho gli shared_ptr non sento la necessità di dover complicarmi la vita a implementare un reference counter (atomico) in una classe per poi gestirla con qualcosa non fornito di serie. Inoltre come detto, lo shared_ptr funziona con tutto, gli intrusive_ptr solo con classi predisposte.

personalmente non ho capito bene le rvalue references e la move semantics(adesso ci ritorno su ,le ho lette in due minuti, sono dell ultimo standard c++?) ma sto studiando le PPL e si usano largamente le lambda functions.

Si, è tutta roba di C++11. Tra l'altro la move semantics è l'innovazione più consistente nel nuovo C++ quindi è meglio capirla bene.

penso che la progettazione multicore sia da imparare oggigiorno con l'hardware che c'è che viene sfruttato al massimo al 50%(penso , ma questa è la mia opinione)

Togli pure il "penso che". Ormai la programmazione è solo multicore, quindi multithreading.
Come dice Bartowsz Milewski ( http://bartoszmilewski.com/ ), siamo passati dalla programmazione tradizionale alla programmazione "quantistica" dove il principio di indeterminazione regna sovrano.

[giuseppe500]

Se usi VS2010 inizia a studiare le rvalue references, lambda function e la move semantics in generale. In giro per la rete ormai si trovano molti esempi riguardo il nuovo standard C++11 e anche se VC++ 2010 ha appena iniziato a implementarlo, le cose importanti le ha

grazie, Shodan , ho letto le rvalue e la move semantics, ma non riesco a capirne bene l'importanza , forse programmo male , ma non tendo mai a fare tante copie e richiamare spesso il costruttore di copia.
a meno che questo speciale "costruttore di copia" si attivi anche quando uso i container stl , in quanto nei container stl tutto è passato per copia(penso).

poi mi sono posto due problemi : se rubo un dato da un oggetto e lo "sposto" in un altro , l'altro rimane senza dato !
che beneficio ne traggo oltre al risparmio di memoria?
forse fare "viaggiare" un dato da un punto a unaltro del codice copiandolo?
che è un po come farne lo shared(condividerlo,ma nel caso: quando serve)in uno shared pointer?
bo?
mi aiuti a capire?
grazie.

[shodan]

Originariamente inviato da giuseppe500
che beneficio ne traggo oltre al risparmio di memoria?

Ti risparmi un sacco di copie inutili.
Considera questo esempio:

std::vector<std::string> get_big_vector() {

    std::vector<std::string> temp;
    temp.resize(4000 * 1024); // 4MB
    /* varie operazioni sul vector */
    return temp;
}

std::vector<std::string> my_vector = get_big_vector();

Per avere my_vector il compilatore crea sullo stack una variabile temporanea di temp (con tanto di allocazione di 4MB e relativa copia di elementi), distrugga temp, crei my_vector (allocando altri 4MB di memoria), copi gli elementi dalla variabile temporanea a my_vector e distrugga la variabile temporanea.

Move semantics.

std::vector<std::string> get_big_vector() {

    std::vector<std::string> temp;
    temp.resize(4000 * 1024); // 4MB
    /* varie operazioni sul vector */
    return std::move(temp);
}

std::vector<std::string> my_vector = get_big_vector();

Qui per avere my_vector il compilatore crea una variabile temporanea sullo stack, ruba il puntatore e i dati interni a temp lasciandola in uno stato stabile, distrugge temp, crea my_vector rubando il puntatore e i dati interni alla variabile temporanea lasciandola in uno stato stabile. Al netto di ottimizzazioni da parte del compilatore ti risparmi due allocazioni e due copie inutili.
Domanda: quale delle due soluzioni è preferibile?