designfrage: futures

hustbaer

thordk schrieb:

vom überladen des () operators rate ich übrigens ab. hab das ne zeitlang auch mal gemacht und es führte schlußendlich dazu, dass der code unglaublich unleserlich wurde. man mag sich erst denken, dass so ein operator ne tolle sache ist, weil er zeichen spart, aber im endeffekt sorgt er mehr für verwirrung.

Den () will ich auf jeden Fall überladen, damit das Ding ein Funktor ist. Einige Libraries (wie z.B. die STL selbst oder auch boost) können mit Funktoren schön umgehen, dadurch werden einige Dinge recht elegant möglich die sonst irgendwelche blöden Helferklassen oder zusätzliche Aufrufe von boost::bind benötigen würden.
Auf jeden Fall wird's aber zusätzlich eine "namentliche" Methode ala "get_result" geben.

Ich hab deinen Future zu sehr als Funktor mit Future-Funktion gesehen. Jetzt ist es klarer, es soll nur das Ergebnis repräsentieren, ok.

Badestrand

Danke für die ausführliche Erklärung hustbaer! Diese futures sind ja eine abgefahrene Sache an die mein bescheidener Verstand gar nicht zu denken gewagt hätte
Das Interface kommt jedenfalls schonmal in meine Schnipsel-Sammlung, wenn du nichts dagegen hast. Würde es dir etwas ausmachen, den kompletten Code zu posten, wenn die Klasse fertig ist?

hustbaer

@Badestrand:
Es geht um etwas mehr als bloss eine Klasse, das wird eine ganze Threading Library
Und es wird leider noch dauern (paar Monate schätze ich) bis die Sache fertig ist (Windows Version, andere OSe kommen später dran).

Kommt aber dann auf jeden Fall auf Source-Forge, und ich werde sicher hier kurz posten.

hustbaer

p.S.: was das "is_" oder nicht "is_" angeht: nachdem die Meinungen hier ziemlich 50:50 verteilt sind (wenn ich richtig gezählt habe) werde ich einfach nach meiner persönlichen Vorliebe "is_" und "get_" etc. verwenden.

(Was eigentlich irgendwie sowieso klar war, da die ganzen anderen Klassen in der Library auch eher "sprechend & lang zum schnell verstehen" als "schön kurz für kleine bildschirme" gehalten sind.)

Helium

hustbaer schrieb:

Eine andere Möglichkeit wäre der "is_finished" bzw. "is_ready" Funktion nen int als Returnwert zu verpassen wo dann 0 = läuft noch, 1 = erfolgreich, -1 = exception. Ist aber nicht sehr selbsterklärend, von daher werde ich das wohl eher nicht machen.

Wieso denn irgendwelche Zauberkonstanten? Wieso nicht eine Enumeration, die teil des futures ist, so dass man dann

if (foo.is_ready() == future<...>::exception)

schreibt.
Wobei das auch doof ist.

if (foo.is_ready())

Soll ja auch Funktionieren.

Dann müsste man sich da einen Tick mehr Mühe geben und irgendwas zurückliefern, das sich in if() verwenden lässt, aber auch mit bestimmten vorgefertigten Konstanten (successfull, ...) vergleichen lässt.

Artchi

Ich finde die Future-Sachen auch toll, sie werden höchstwahrscheinlich in C++0x oder TR2 enthalten. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2276.html
Bin sogar der Meinung, das Herb Sutter es mal als Sprachfeature (und nicht als Lib) vorgestellt hatte.

Helium

Als teil des Concur-Projekts

finix

Helium schrieb:

Wieso denn irgendwelche Zauberkonstanten? Wieso nicht eine Enumeration, die teil des futures ist, so dass man dann
if (foo.is_ready() == future<...>::exception)
schreibt.
Wobei das auch doof ist.
if (foo.is_ready())
Soll ja auch Funktionieren.

Vielleicht

switch (foo.get_state()) {
case future<...>::busy:
case future<...>::ready:
case future<...>::exception_occured:
}

und dazu

inline bool is_ready() const { return get_state() == ready; }
// etc.

http://www.mr-edd.co.uk/?tag=async

http://de.wikipedia.org/wiki/Overengineering

Badestrand

Ach net, ist irgendwie schade, dass du keinen Nick mehr hast

Badestrand schrieb:

Ach net, ist irgendwie schade, dass du keinen Nick mehr hast

warum? es hat sich kaum was dadurch verändert.

.filmor

Wenn es nicht schon draufsteht hustbaer, kannst du dann der Zu-tun-Liste auch noch ultraleichtgewichtige Threads hinzufügen? Ich möchte mehr erlang-Stil in C++, hab aber zz keine anständige „Umgebung“ um sowas zu basteln