Danke schonmal..

Einerseits gibt es die Plattform-spezifischen APIs wie pthread_create(..) (posix) und CreateThread(..) bzw. _beginthreadex(..) (WinAPI), andererseits gibt es Libraries wie z.B. Boost, in der Boost.Thread enthalten ist.
(Andere Libraries sind z.B. POCO, ...).

Simon

theta schrieb:

Plattform-spezifischen APIs wie pthread_create

Aeh, nein!

Äh, doch?

pthreads oder POSIX Threads ist lediglich eine Spezifikation, die eine Schnittstelle beschreibt.
Implementationen dieser Spezifikation existieren für die meisten POSIX-Systeme
(weitestgehend allen POSIX-konformen UNIXoiden wie BSD, Linux oder Mac OS X).

Im Gegensatz zu den oben genannten unterstützt Windows pthreads nicht nativ,
dafür gibt es aber ein Projekt, welches an einer Windows-Implementation arbeitet:
http://sourceware.org/pthreads-win32/

Mit den Windows-Services for UNIX kommt übrigens auch eine native Umsetzung der pthreads für Windows daher.

Somit könnte man pthreads schon als plattformunabhängig bezeichnen...

Kommt eben darauf an, wie strikt man "plattformunabhängig" definiert.

Und Pi muss ich hier mal Recht geben
Es hindert einen niemand daran, die Spezifikation für irgendein Nicht-POSIX-System zu implementieren...

Du erklärst gerade richtigerweise, dass es pthreads nur auf POSIX-konformen Plattformen gibt und behauptest dann, pthreads wären plattformunabhängig? Zumal auch noch die verbreitetste Plattform nicht POSIX-konform ist?

Du meinst Windows? Einer der wenigen nicht nur POSIX konformen sondern auch certifizierten OS. Dazu noch in der Version 1.0/1.X/2.0 schaltbar.

Old Billi hat nebenbei mit XENIX die erste 8086 UNIX Portierung auf ATNT Codebasis entwickelt, woraus später SystemV , Open Server und Solaris entstanden ist.

MS hat mehr mit UNIX zu tun als Linux auch Patentrechtlich.

Wobei es natürlich seien könnte, dass unter der Api auch pthreads zum Einsatz kommen. Ist nicht ganz abwegig.

Im neuen C++11 sind Threads mit std::thread zudem Teil der Standardbibliothek.

Stimmt, dafür hats mehr als die W32 API.

Was denn z.B.!?

Dean schrieb:

Wobei es natürlich seien könnte, dass unter der Api auch pthreads zum Einsatz kommen. Ist nicht ganz abwegig.

Doch, das ist sehr abwegig

Danke an euch alle, ich glaub ich werd mir mal das Boost anschauen, das hört sich nicht schlecht an. Danke

Was spricht gegen die Threads der Standardbibliothek? Wieso auf alternative Bibliotheken ausweichen, die fast exakt das Selbe Interface implementieren wie die Standardbibliothek?

Danke an euch alle, ich glaub ich werd mir mal das Boost anschauen, das hört sich nicht schlecht an. Danke

Was spricht gegen die Threads der Standardbibliothek? Wieso auf alternative Bibliotheken ausweichen, die fast exakt das Selbe Interface implementieren wie die Standardbibliothek?

Ich nenn dir einen einfachen Grund: Unterstützung von aktuellen Kompilern.

Grüssli

Ethon schrieb:

Danke an euch alle, ich glaub ich werd mir mal das Boost anschauen, das hört sich nicht schlecht an. Danke

Was spricht gegen die Threads der Standardbibliothek? Wieso auf alternative Bibliotheken ausweichen, die fast exakt das Selbe Interface implementieren wie die Standardbibliothek?

Ich nenn dir einen einfachen Grund: Unterstützung von aktuellen Kompilern.

Grüssli

GCC läuft überall. Der TE programmiert ganz offensichtlich privat, also könnte er auch den nehmen.

C++11 ist das Beste was C++ seit langem widerfahren ist, also soll jeder neuen Features einfach nutzen anstatt noch 10 Jahre C++03 zu programmieren, dann etablieren sich die Features auch schneller.

C++11 ist das Beste was C++ seit langem widerfahren ist, also soll jeder neuen Features einfach nutzen anstatt noch 10 Jahre C++03 zu programmieren, dann etablieren sich die Features auch schneller.

Aber nur Compiler wechseln, damit man statt boost std hinschreiben kann?

Oder kann man mit g++ einfach unter Visual Studio kompilieren? Auf diese IDE würde ich persönlich nämlich nur ungern verzichten. Und selbst dann denke ich, dass man sich viele nützliche Features wie den Debugger verbaut.

Davon abgesehen hatte z.B. TR1.Random in der g++-Standardbibliothek bei meiner letzten Benutzung noch einige Bugs, obwohl es schon ein paar Jahre existiert. Von daher bin ich gegenüber Neuerungen eher vorsichtig, auch bei Microsoft. Hingegen sind etablierte Boost-Bibliotheken wie Thread (gibts schon ein Jahrzehnt!) tendenziell recht stabil...

...und bis dahin einfach boost::thread benutzen...

Genau oder sonstige Lösungen von entsprechenden Frameworks, welche man sowieso verwendet (Qt, SFML, usw.)

@Ethon,
Die Features werden sich etabilieren, sobald die gängigen Kompiler diese auch unterstützen. Du kannst das nicht erzwingen. MS wird diese Features nicht einführen, nur weil deine Bibliothek diese Features benötigt. Du wirst also einfach gewisse Leute/Projekte/usw. ausschliessen und wahrscheinlich eher die Mehrheit, weil noch ziemlich viele auf Kompilerunabhängigkeit schauen.

Würde mich nicht überraschen, wenn es noch gut 5 Jahre geht, bis C++11 richtig etabliert ist.

Grüssli

Würde mich nicht überraschen, wenn es noch gut 5 Jahre geht, bis C++11 richtig etabliert ist.

Na ja. Alle Bibliotheksfeatures kommen ja schon mit VS11, und das kommt vermutlich 2012. Und wenn man Microsoft glauben möchte, hängt der Rest ja nur an performanten variadic Templates, und sie sind zuversichtlich, das schnell nachliefern zu können. Und wenn Microsoft es schafft, bis Anfang 2013 einen vollständigen C++11 Compiler zu bauen, sollten die GCC Leute das doch wohl locker hinbekommen. Immer positiv denken. :xmas1:

Und wenn man Microsoft glauben möchte, hängt der Rest ja nur an performanten variadic Templates, und sie sind zuversichtlich, das schnell nachliefern zu können.

Da hast du (oder ich?) Microsoft falsch verstanden. Sie wollten mit der nächsten Version von MSVC auch die Varadic Templates bringen, aber haben anscheinend die Arbeit etwas unterschätzt. Daher soll wahrscheinlich für den nächsten MSVC später ein Patch nachgeliefert werden, welcher die Variadic Templates bringt.
Dann haben sie zwar Varadic Templates aber eine Menge anderer Features fehlen dann immer noch. Die kommen erst im nächsten Kompiler. Und die erscheinen im 2-3 Jahrestakt. Somit wäre der früheste Termin im 2014, aber wahrscheinlich eher 2015.

Und nicht vergessen sollte man, dass es wahrscheinlich noch 1-2 Jahre danach gehen wird, bis auch die letzten mühsamen Bugs beseitigt sind. Somit erst mit dem SP1 des 2015 MSVC ist meiner Meinung nach der früheste Termin zu sehen

cooky451 schrieb:

Und wenn Microsoft es schafft, bis Anfang 2013 einen vollständigen C++11 Compiler zu bauen, sollten die GCC Leute das doch wohl locker hinbekommen.

Die Leute vom GCC womöglich. Die Frage ist aber auch, ob die Leute von Clang es bis dahin schaffen. Clang bekommt zunehmend an Bedeutung. Bin sehr gespannt wie die Verteilung in 5 Jahren aussehen wird zwischen GCC und Clang.

cooky451 schrieb:

Immer positiv denken. :xmas1:

Ich denke lieber realistisch oder auch ein wenig pessimistisch. Da kann man fast nur positiv überrascht werden. Wenn man positiv denkt, wird man ständig enttäuscht

Grüssli

Solange man "Cross-Compiler" entwickelt, kommt man an VS und GCC halt nicht vorbei, von daher würde ich mit std::thread zumindest noch bis VS 11 warten.

Die meisten C++-Enthusiasten, die ich kenne, und die unter Windows arbeiten benutzen schon seit einer Weile den Windows-Port von GCC gerade aufgrund der mangelnden C++11 Unterstützung des MSVC.
Was spricht denn gegen MinGW ?