Segna esplicitamente le funzioni non esportate in una DLL?

2

Quando si scrive una DLL Win32 non gestita che esporta le funzioni, non è raro avere alcune funzioni, variabili e / o classi che non sono destinate ad essere esportate e sono solo per uso interno all'interno della DLL. Dal momento che stavamo progettando applicazioni scritte sia su .NET che su Visual FoxPro al momento, era il modo di utilizzare un file .def invece della parola chiave __declspec(dllexport) .

Quando scrivi componenti di questa natura in una DLL come faccio di solito è con un #define che non si espande, ma mi aiuta a tenere traccia di quale sia lo scopo dietro al componente, cioè:

#define INTERNALUSE

// Function used internally by the DLL
VOID WINAPI INTERNALUSE StrDateToNumDate(wchar_t *wszDateString, int cchDate);
// Function exported by the DLL
BOOL WINAPI ValidateDateString(wchar_t *wszDateString, int cchDate);

Uno dei miei colleghi di questa azienda aveva commentato che questo era confuso e gonfiato nel codice quando ho scritto il componente e che, in genere, l'aspetto di una parola chiave aggiuntiva in una definizione di funzione in una DLL implica che il la funzione verrà esportata (a la #define PROJECTNAME __declspec(dllexport) righe generate automaticamente da MSVC), ma ho trovato molto più semplice mantenere il mantenimento in questo modo.

Non ho pensato a questo problema per un po ', ma scavare attraverso il mio vecchio codice mi ha riportato alla mente solo ora. Sono curioso di sapere se qualcuno ha qualche idea su questo argomento e su chi di noi è più corretto.

    
posta Govind Parmar 27.06.2016 - 22:59
fonte

1 risposta

1

Anche se non penso che questo tipo di "commento" a livello di pre-processore sia malvagio , non ne sono molto entusiasta. I tuoi strumenti non lo interpreteranno in alcun modo e non saranno in grado di cogliere eventuali errori causati dall'utilizzo accidentale di una funzione in un modo a cui non era destinato. Il tag è anche invisibile sul sito di chiamata.

Dato che si tratta in realtà solo di un commento, potresti ugualmente scriverlo come tale.

VOID WINAPI /* internal */ StrDateToNumDate(wchar_t *wszDateString, int cchDate);

Anch'io non sono un grande fan di questa soluzione, ma salverebbe il tuo collega l'onere cognitivo (probabilmente minimo) per capire cosa fa il token e serve ancora come documentazione che stai cercando. Preferirei inserire il commento (o la macro di tagging) dopo la funzione, comunque. Questo è anche il luogo in cui gli attributi delle funzioni (almeno nel mio compilatore) vanno.

Il tuo compilatore potrebbe effettivamente avere un tipo di annotazione per esprimere la semantica che vuoi trasmettere in un modo comprensibile al compilatore. Anche se oggi non ce l'ha, questo è in realtà un contro-argomento per usare commenti lessicali e una buona argomentazione per l'utilizzo della macro: se decidi di usare tali annotazioni (forse perché il compilatore aggiunge il loro supporto) puoi passare a loro semplicemente sta modificando la definizione della macro.

Una soluzione alternativa che sarebbe più intrusiva ma che ricorda anche l'"interiorità" della funzione nel sito di chiamata e che consente il supporto di strumenti limitati utilizzando una convenzione di denominazione. Ad esempio, tutte le funzioni interne potrebbero essere denominate con un carattere di sottolineatura finale. Questo può naturalmente essere combinato con il tagging o le annotazioni.

    
risposta data 27.06.2016 - 23:29
fonte

Leggi altre domande sui tag