[c++]move semantic e deserializzazione

[giuseppe500]

ciao.
Ho una necessità di creare un meccanismo di serializzazione / deserializazione binaria in un progetto di grafica 3d a cui sto lavorando.

Ho pensato alla move semantics.
e all' esempio che mi ha scritto shodan:

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);
}

i modelli in formato raw(binario) possono tenere anche piu' di 150 mb anche se me li trovo molto spezzettati, non tutti in un vector come nel tuo esempio bensi in oggetti come texture o triangoli ma il procedimento è lo stesso.
Posso avere ad es una texture con un array di char(un uimmagine bitmap) da 30 MB in cui il procedimento sembra lo stesso dell' esempio o altri 50 MB in un array di vector(punti 3d).

Mi chiedevo se posso trarre un guadagno di memoria e tempo usando le move semantics?
quello che non riesco a capire è questo : non basta usare un riferimento per spostare i dati?
o le move semantics servono solo per le copie dei dati?Come per es fare un clone del modello 3d

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

    std::vector<std::string>* pTemp = new std::vector<std::string>();
    pTemp->resize(4000 * 1024); // 4MB
    /* varie operazioni sul vector */
    return pTemp;
}

grazie

[shodan]

Originariamente inviato da giuseppe500
Mi chiedevo se posso trarre un guadagno di memoria e tempo usando le move semantics?

E' più veloce copiare un file di 50MB in un'altra directory o spostarlo in quella directory?

quello che non riesco a capire è questo : non basta usare un riferimento per spostare i dati?
o le move semantics servono solo per le copie dei dati?Come per es fare un clone del modello 3d

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

    std::vector<std::string>* pTemp = new std::vector<std::string>();
    pTemp->resize(4000 * 1024); // 4MB
    /* varie operazioni sul vector */
    return pTemp;
}

Così non sposti proprio nulla: ottieni solo una zona di memoria da manipolare a piacimento e se perdi il riferimento a quella zona di memoria sei fritto (traslasciando il fatto che in questa specifica funzione restituire un puntatore a un std::vector<> è assurdo).
Il fatto che il C++11 abbia introdotto la move semantics è per evitare copie inutili durante il passaggio di temporanei (move semantics implicita), o passaggio di variabili che si creano nelle funzioni e che in teoria muoiono li (move semantics esplicita con std::move()). Questo rende più efficiente il passaggio di parametri in entrata e uscita dalle funzioni.
Scope e vantaggio di questo meccanismo è di evitare (per quanto possibile) di maneggiare dati nel modo su riportato.

Ti faccio io una domanda: secondo te perché il C++ ha introdotto i vari container (list, vector, string) e gli smart pointer (unique_ptr, shared_ptr)?

[giuseppe500]

se la domanda è seria cerco di fornire una risposta seria:
secondo me per fornire una standardizzazione al modo di programmare, smart pointer e container sono resi standard per evitare un uso improprio e metodi di programmazione impropria o deprecata per il tempo e per il linguaggio.
ma forse sbaglio.

comunque non volevo perdere tempo o farti perdere tempo, era solo per capire.
ciao.

[shodan]

La domanda era seria (altrimenti ci avrei messo le faccine).

secondo me per fornire una standardizzazione al modo di programmare, smart pointer e container sono resi standard per evitare un uso improprio e metodi di programmazione impropria o deprecata per il tempo e per il linguaggio.

Esatto, e il vero motivo di tutto ciò è: evitare che il programmatore debba occuparsi dei dettagli nella gestione della memoria, cioè puntatori.
Se ci fai caso, nei libri sul C++ viene mostrata la gestione di stringhe in stile C contrapposto alle std::string, oppure agli array dinamici (fatti con new o malloc) vs std::vector.
Oltre a mostrare la semplicità di gestione delle strutture dati C++, di solito viene messo in rilievo il comportamento dei due stili di programmazione in relazione alle eccezioni. Nel primo caso è il programmatore a doversi preoccupare di gestire la memoria per evitare memory leak, nel secondo caso è la struttura dati (string, vector o quel che è) a occuparsene in automatico. E questo è un punto fondamentale perché non si sa mai se e quando viene lanciata un'eccezione.
La move semantics non è un'idea nuova, ne aveva già parlato Alexandrescu nel 2003, ma solo con una modifica nel kernel del linguaggio poteva essere effettuata nativamente.
L'idea di fondo è: invece di copiare i dati durante i vari passaggi di variabili è possibile semplicemente trasferire questi dati, mantenendo una minima exception safety?
Perché il nocciolo della questione è tutta qui: affidare la gestione delle risorse al programmatore rischia di causare problemi non immediatamente visibili; lasciarla al linguaggio tramite paradigma RAII, invece, fa dormire al programmatore sonni relativamente tranquilli, proprio perché sa che le risorse saranno rilasciate in automatico (non dimenticare che la memoria è solo una risorsa e in certi casi è pure la meno importante).
Per gli smart pointer il discorso è simile ed quanto di più vicino si avvicini a un raw pointer. Hanno dei limiti intrinseci, ma per il 90% dei casi possono gestire la memoria per te.
In sostanza Il C++ moderno cerca di minimizzare e scoraggiare l'uso di raw pointer e privilegiare invece l'uso di container o strutture dati "intelligenti" che gestiscano la memoria senza intervento del programmatore, ma fino al C++11 l'uso di queste strutture era scoraggiato dal fatto che potevano essere solo copiate se restituite da una funzione. E se queste strutture (Es. Un vector di strutture) era grosse, le performance ne risentivano.
La move semantics, permettendo il trasferimento dei dati, velocizza l'operazione che in pratica diventa immediata. E tutto questo lasciando la exception safety e gestione risorse al linguaggio.
Dal mio punto di vista, più che lambda function, smart pointer o il nuovo range for, è la move semantics ad aver migliorato il C++.

comunque non volevo perdere tempo o farti perdere tempo, era solo per capire.

Non so che ti abbia dato questa impressione, ma imparare e/o spiegare non è mai una perdita di tempo.

[giuseppe500]

ho capito.
Ho pero' un dubbio che ti chiedo subito:
Ad es sto lavorando ad un progetto per l'importazione di dati da un formato architettonico , dove prendo delle strutture che sono immagazzinate in delle collezioni per trasferirle a una classe che trasforma queste strutture in oggetti della mia applicazione.
In questo caso accumulavo tutto in una collezione di strutture di descrizione degli oggetti e poi enumeravo la collezione di strutture per creare i vari oggetti.
Il problema è che con gli smart pointer liberavo la memoria tutto alla fine, quando svuotavo la collezione di strutture e la memoria non era gestita bene e questo uno potrebbe dire : colpa degli smart pointer!.
Invece era colpa del cattivo design del progetto.
Adesso leggiamo le strutture una per una e creiamo subito l'oggetto come mi ha suggerito il mio collega e gli smart pointer liberano le risorse in automatico.
Questo è un esempio molto semplice ,per dire come il cattivo design non sia colpa degli strumenti o del c++ o degli smart pointer , ma è indipendente.
Creare strumenti che fanno il lavoro ad alto livello non è sufficente , non esiste un punto di rottura netto tra quello che c'era prima e quello che c'è dopo (piu ad alto livello), ci vuole una conoscenza generale delle cose che stanno "sotto" penso anche se ho letto pareri diversi .
Il c++ è considerato un linguaggio a basso livello?
perche ho letto su questo forum anche che è a basso livello perchè "puoi gestire la memoria come ti pare" , contapponedosi ai linguaggi con la memoria gestita dal Garbage Collection.
non so , questo non l'ho capito.
ciao Shodan