2015-11-13 8 views
6

Perché specificare -std=c++11 durante la compilazione di un programma che utilizza direttamente o indirettamente std::thread non implica -pthread? Sembra strano che i dettagli di implementazione di std::thread che utilizzano pthreads sotto la cappa siano esposti al programmatore; se si tratta di dare all'utente una scelta di librerie di thread compatibili con posix, perché non è sufficiente impostare pthreads e avere qualche argomento --threading-model=<your_favorite_posix_threads_library> per sovrascriverlo?Perché è necessario -pthread per l'utilizzo di std :: thread in GCC e Clang?

+2

Ti aiuterebbe se pensi a "GCC per C++" come "' g ++ -pthread -std = C++ 11' "e non ti preoccupare del rumore lessicale nella definizione? –

+1

@KerrekSB Rende un problema quando si utilizza CMake e in realtà si cerca di essere multipiattaforma senza ricorrere a modifiche esplicite di CMAKE_CXX_FLAGS (il compilatore di Microsoft si lamenta dei flag sconosciuti ma li ignora) o mette condizionali di piattaforma/'find_library', specialmente se il comportamento _does_ finisce per cambiare alla fine. Una mailing list che ho trovato suggeriva l'uso di 'find_package (Threads)', ma non sembra funzionare con GCC o Clang. Non sto cercando una soluzione perché so già cosa fare, sto solo cercando di scoprire perché si comportano in quel modo. È solo all'indietro-compat? – JAB

+0

Non penso ci sia un motivo. A nessuno importava troppo per cambiare il comportamento, che è stato ereditato dal compilatore pre-C++ 11. – SergeyA

risposta

2

L'opzione -pthread non è universalmente necessaria per utilizzare std::thread - si tratta di una peculiarità di implementazione di qualsiasi piattaforma si stia sviluppando.

Compilazione:

#include <thread> 
#include <iostream> 

int main() 
{ 
    std::thread t{[]() 
     { 
      std::cout << "Hello World\n"; 
     }}; 
    t.join(); 
    return 0; 
} 

con

clang -std=c++11 ThreadTest.cpp -lc++ 

su MacOSX, costruisce e corre, e se lo facciamo:

otool -L a.out 
a.out: 
    /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.1.0) 
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1225.0.0) 

possiamo vedere che abbiamo bisogno di creare un collegamento niente di extra per fare questo lavoro - né è successo dietro le quinte. Sembra essere molto un dettaglio di implementazione della piattaforma che pthreads è una libreria separata.

Avere una scelta di librerie di threading con l'interfaccia pthread è bagaglio legacy su sistemi * NIX, molti dei quali partiti senza supporto thread, quindi ha attraversato una fase di thread spazio utente prima di avere il pieno supporto del kernel. Immagino che sia ancora lì perché a nessuno piace fare cambi repentini.

+0

"Immagino che sia ancora lì perché a nessuno piace fare cambi improvvisi" ma dal momento che devi comunque modificare il codice per usare std :: thread, non vedo come definirlo in modo tale da assumere lpthread se non viene specificato nient'altro romperebbe qualcosa? – Voo

+1

Il cambiamento a cui mi riferivo era la necessità di includere libpthread in qualsiasi programma che utilizza il threading su alcune piattaforme. Gli strumenti e le librerie compatibili con C++ 11 sono in gran parte retrocompatibili con le basi di codice C++ 03. Si deve davvero chiedersi perché i pthread siano ancora scomposti in una libreria separata. – marko

+1

Beh, questo è interessante. Per curiosità, quale libreria C++ è usata su OSX se si costruisce con Clang ma non si specifica '-lC++'? – JAB

Problemi correlati