Qual è la logica di progettazione tra GCC che esporta tutti i simboli per impostazione predefinita e MSVC non esporta nulla per impostazione predefinita?

Question

Una delle molte differenze chiave tra i compilatori C++ GCC & MSVC è che nel primo tutti i simboli di una libreria condivisa vengono esportati per impostazione predefinita, mentre MSVC non esporta nulla.

Alcune implicazioni sono che in, in MSVC, è necessario esportare classi di modelli istanziati di explict.

Mentre ho accettato questo come un dato di fatto, mi chiedevo quali sono le implicazioni del design, i compromessi, dal punto di vista del progettista di compilatori, ecc. Di ciascun approccio?

Answer 1

Probabilmente ha qualcosa a che fare con ciò che i file eseguibili e le librerie sono nei rispettivi sistemi operativi.

Su Windows, sia le librerie (DLL) che i file eseguibili sono la stessa cosa. Letteralmente, è possibile rinominare un file .dll in .exe e verrà eseguito lo stub della modalità protetta ed emesso un errore (di nuovo, in modalità protetta, quindi funzionerà solo su un sistema a 16 bit). Dato che sono uguali, e puoi (e fai!) Esportare simboli da file eseguibili reali, ti aspetteresti che il valore predefinito non sia esportare nulla giusto?

Su Linux, tuttavia, gli eseguibili sono la loro cosa, e le librerie di codice (oggetti condivisi, .so) sono qualcos'altro. Infatti i file .so sono più vicini agli archivi (.a, una specie di librerie gcc - ma non sono in realtà archivi) se ricordo correttamente. Non è necessario includere un .lib per utilizzare la libreria condivisa come in Windows perché è un file di libreria di sorta. Dato che stai compilando esplicitamente il tuo output come questa libreria condivisa, non vedo nulla di strano con esso, solo esportando tutto per impostazione predefinita.