È corretto esportare i membri dei dati? (C ++)

Question

Come suggerisce il titolo, è corretto o valido importare / esportare dati statici all'interno di una classe C ++?

Ho scoperto il mio problema: l'autore della classe che stavo guardando stava cercando di esportare dati statici scrivibili che non sono supportati su questa piattaforma.

Molte grazie comunque per le risposte.

Answer 1

È corretto in quanto funzionerà e farà ciò che ti aspetti? Supponendo che tu stia parlando dell'utilizzo di _declspec (dllexport / dllimport) su una classe o su un membro della classe, sì, puoi farlo e dovrebbe darti il ??risultato atteso - i dati statici sarebbero accessibili al di fuori della tua dll e altri codici C ++ potrebbero accedere a condizione che la specifica di accesso C ++ (pubblica / protetta / privata) non blocchi in primo luogo l'accesso esterno.

È una buona idea? Personalmente non la penso così perché esponerai gli interni della classe non solo all'interno della tua biblioteca ma al mondo esterno, il che significa che sarà praticamente impossibile cambiare ciò che è un dettaglio di implementazione alla fine della giornata. Chiediti se sei sicuro al 100% se l'interfaccia di questa classe e gran parte della sua implementazione non cambierà mai e poi mai ...

Answer 2

Una classe C ++ esportata significa che i client DLL devono utilizzare lo stesso compilatore della DLL a causa della modifica del nome e di altri problemi. Questo in realtà è un grosso problema, una volta ho dovuto scrivere wrapper C in un gruppo di classi C ++ perché i programmi client erano passati a MSVC9, mentre la stessa DLL utilizzava MSVC71. [Ci sono state alcune altre complicazioni con il passaggio della DLL a MSVC90]. Da allora sono stato piuttosto scettico su questa attività di esportazione di classi e preferisco scrivere un wrapper C per tutto.

Ora, se sei disposto a pagare il prezzo delle classi esportatrici, direi che l'esportazione di dati statici non peggiora ulteriormente il problema. Probabilmente, tra i tipi di cose che potresti esportare, è più sicuro esportare costanti statiche. Anche così, preferirei non farlo, perché come dice Timo, ora sei bloccato in questa implementazione.

Uno dei framework su cui ho lavorato ha richiesto ai suoi clienti di fornire una serie di costanti di codici di errore. Nel tempo, abbiamo scoperto che l'uso di un semplice gruppo di costanti era troppo fragile e siamo passati a un design OO. Avevamo un'implementazione predefinita che avrebbe restituito i codici di errore comuni, ma a ciascuno dei codici di errore si accedeva utilizzando una funzione virtuale che poteva essere sovrascritta dai singoli client - e lo utilizzavano da una gestione avanzata degli errori specifici del dispositivo. Questa soluzione si è dimostrata lontana più scalabile di quella basata sull'esportazione di costanti.

Ti suggerirei di riflettere a lungo su come ti aspetti che il componente si evolva prima di esportare variabili statiche.

Answer 3

dllexport (o import) su un membro di dati (non statico) di una classe non fa nulla. Articoli "quotati" esportati sono funzioni o dati globali (sebbene questa sia una scelta di progettazione discutibile). dllexport su una classe è solo una scorciatoia per dire " esporta tutte queste funzioni " ;.