Worin liegt darin jetzt der Vorteil?
Über den Konstruktor könntest du nur einmal einen Wert übergeben, während man mit std::bind immer einen anderen Wert übergeben kann.
So sieht es in meinem Programm aus und funktioniert nicht
![^^](wcf/images/smilies/squint.png.pagespeed.ce.vVqemmKAwr.png)
.
Es wird immer wieder der selbe Thread gestartet. Ergebnis: Chaos.
Deine Beobachtung stimmt nicht ganz. Was du jetzt erhältst ist eine sequentiellen Aufruf der Funktion, weil am Ende der Schleife wird das Thread Objekt zerstört und intern wird thread.wait() aufgerufen, somit wird nach jeder Iteration gewartet bis der Thread beendet hat. Als läuft da gar nichts parallel.
Ich würde gerne einen Array von Threads nutzen in etwa so:
sf::Thread thread[16];
es kommt der Fehler:
sf::Thread::Thread': Kein geeigneter Standardkonstruktor verfügbar
Tja, ich weiß was das bedeutet. Und einen geeigneten Konstriktor bekomme ich nicht hin.
Sollte ich statt SMFL eine andere lib zu Threading nutzen, oder gibt es einen weg?
Ich empfehl dir kein Array zu verwenden, denn wie du ebenfalls in der Dokumentation nach lesen kannst, gibt es keinen Standardkonstruktor. Wenn du nicht weisst was das ist, oder was die Fehlermeldung bedeutet, solltest du noch einmal dein C++ Buch/Tutorial/etc zur Hand nehmen und nach schauen, was denn das genau ist...
Jedenfalls muss man, da es keinen Standardkonstruktor hat, die Objekte dynamisch generieren und da empfehle ich die Verwendung von std::vector und std::unique_ptr (soweit dein Compiler das unterstützt).
Das Ganze sieht dann so aus:
|
C-/C++-Quelltext
|
1
2
3
4
5
6
7
|
std::vector<std::unique_ptr<sf::Thread>> threads;
for (unsigned int i = 0; i < allocator.particleThreadNumber; ++i)
{
threads.push_back(std::unique_ptr<sf::Thread>(new sf::Thread(std::bind(&Accessor::physicalSimulation, &accessor, allocator.particleLocation[i]))));
threads.back()->launch();
}
|
Wenn du keine Ahnung hast was hier nun alles passiert, dann solltest du auch die Themen 'std::vector', 'std::unique_ptr', 'std::bind' erforschen gehen.