Questo sito utilizza cookies solo per scopi di autenticazione sul sito e nient'altro. Nessuna informazione personale viene tracciata. Leggi l'informativa sui cookies.
Username: Password: oppure
C/C++ - Ritornare un oggetto di tipo diverso per ogni classe nella gerarchia
Forum - C/C++ - Ritornare un oggetto di tipo diverso per ogni classe nella gerarchia

Avatar
TheDarkJuster (Member)
Guru^2


Messaggi: 1620
Iscritto: 27/09/2013

Segnala al moderatore
Postato alle 18:54
Giovedì, 20/09/2018
Buongiorno a tutti,
Sto studiando un libro sulle opengl ed ogni nuovo concetto che incontro cerco di farlo mio scrivendoci un wrapper attorno.

Ora... Un vbo di per se è legato ad un buffer in memoria video e come deve essere interpretato il suo contenuto è un compito lasciato al programmatore. Quindi io ho creato la classe VertexBuffer che rappresenta un vbo (senza informazioni sul suo utilizzo o su cosa contenga) e una classe VertexAttributes che eredita da VertexBuffer, ma che contiene delle informazioni aggiuntive, ovvero il numero di attributi contenuti ed il descrittore dei contenuti. Per intenderci un VertexAttributes può contenere informazioni del tipo: ho 35 vertici, ognuno formato da 3 float.

Fin qui nessun problema, il tutto è semplicemente fantastico ed elegante da usare.

Leggo nel libro che esiste un glMapNamedBuffer() o un nome simile, che permette di portare il buffer nella memoria accessibile alla mia applicazione per leggerlo e/o modificarlo.

Quindi ho creato una classe MappedMemory come sottoclasse protetta di VertexBuffer e una funzione virtuale che ritorna un oggetto di quel tipo.

Ora voglio che una chiamata a quella funzione su un oggetto di tipo VertexAttributes mi restituisca un oggetto la cui classe eredita da MappedMemory, ma che possa fare delle cose in più.

A questo punto mi rendo conto che non avrei dovuto usare, come tipo di ritorno un MappedMemory, ma bensì un MappedMemory& oppure un MappedMemory*, ma nessuna delle due opzioni mi aggrada: il riferimento finirebbe ad essere un riferimento a memoria che verrebbe distrutta dal return stesso, e il puntatore mi forzerebbe a pensare a un metodo di gestione della memoria (potrei ovviare usando uno unique_ptr o uno shared_ptr, ma poi ogni volta che uso tale funzione dovrei fare un dynamic_cast per poter chiamare funzioni disponibili solo sulla implementazione di MappedMemory relativa ad un VertexAttrubutes).

Un'altra soluzione potrebbe essere quella di mantenere come membro privato un oggetto del tipo corretto e ritornarne il riferimento, pregando però ogni santo di non dimenticare mai di chiamare glUnmapNamedBuffer() quando chi usa la libreria (io) avrà finito di usare il buffer, perché il risultato potrebbe essere catastrofico e il bug diffile da trovare!!!!

Sono un po indeciso sulla strada da seguire, e mi farebbe piacere sentire il vostro parere.

PM Quote
Avatar
pierotofy (Admin)
Guru^2


Messaggi: 6230
Iscritto: 04/12/2003

Segnala al moderatore
Postato alle 19:10
Domenica, 23/09/2018
Questo e' un po' il problema di tutti i wrappers intorno a librerie grafiche. Semplificare le chiamate oppure avere sorprese inaspettate?

Non so se ti aiuta, ma a me piace l'approccio usato da librerie come SFML. https://github.com/SFML/SFML/tree/master/src/SFML/Graphics


Il mio blog: https://piero.dev
PM Quote
Avatar
TheDarkJuster (Member)
Guru^2


Messaggi: 1620
Iscritto: 27/09/2013

Segnala al moderatore
Postato alle 22:26
Domenica, 23/09/2018
Ti ringrazio per la risposta, alla fine ho rivalutato il tutto ho pensato di cambiare approccio: definire l'interfaccia di un oggetto disegnabile.

Ogni oggetto poi si disegna da solo quando viene invocato draw(...) Su quell'oggetto.

Ho scelto questo approccio perché quello di wrappare le api introduceva un overhead inutile, oltre che a forzarmi di scrivere il wrapper stesso.

Inoltre ho visto che mantenere il wrapper mi rallentava troppo nella lettura.....

PM Quote