Was taugt Boost?
-
Optimizer schrieb:
nesting error: the tag 'Flamemode' is closed without having been opened previously.
the tag 'flamemode' was not closed proberly.*g*
-
Optimizer schrieb:
nesting error: the tag 'Flamemode' is closed without having been opened previously.
the tag 'flamemode' was not closed proberly.[CaseSensitivity="Off"]
[FlAmEmOdE]
ich hasse dich
[/fLaMEmODe]
[CaseSensitivity="on"]
-
kiddies, es reicht langsam.
-
Was haltet ihr von Boost?
Taugt Boost auch für prof. Anwendungen,
Noch nicht, da kein Standard und auch noch nicht klar ist, was eventuell übernommen wird.
oder ist das mehr eine akademische Spielwiese?
Yep.
-
volkard: müßte strangeFoo nicht legalerweise static sein? (wg. D3DText-member noch nicht initialisiert) Ist aber ne nette Idee.
Was ich noch nicht verstehe: Wie "merkt" sich D3DTexture das Bitmap?
mekt sich's ne Referenz, dann get die referenz doch auf ein temporary. Und kopieren kann er's ja auch nicht??!
-
peterchen schrieb:
volkard: müßte strangeFoo nicht legalerweise static sein?
jo, auf jeden fall static.
Was ich noch nicht verstehe: Wie "merkt" sich D3DTexture das Bitmap?
mekt sich's ne Referenz, dann get die referenz doch auf ein temporary. Und kopieren kann er's ja auch nicht??!weiß ich auch nicht. hab nur die vorgabe umgemodelt.
-
weiß ich auch nicht. hab nur die vorgabe umgemodelt.
He - ok
-
peterchen schrieb:
Was ich noch nicht verstehe: Wie "merkt" sich D3DTexture das Bitmap?
mekt sich's ne Referenz, dann get die referenz doch auf ein temporary. Und kopieren kann er's ja auch nicht??!Indem sie die Pixel der Bitmap ausliest und auf eine IDirect3DTexture8 kopiert (Mist, und ich dachte, ich hätte ein einfaches Praxisbeispiel gefunden
).
-
volkard schrieb:
liegt mir irgendwie mehr.
Interessant. Werde ich mir mal angucken, aber so richtig intuitiv und schön finde ich die Lösung gerade auch nicht. Kommt wohl auf nen Versuch an, wenn ich wieder nen schönen Fall habe.
-
volkard schrieb:
das meinste nicht ernst, oder?
Doch. Und ich glaube, dass das für dich so abwegig klingt, weil wir einfach ziemlich verschieden programmieren.
Ich verwende auch manchmal boost::noncopyable, wenn eine Klasse theoretisch kopierbar wäre, einfach nur um sicher zu gehen, dass es nicht passiert. Aber in pimpl-Klassen z.B. schreibe ich einen scoped_ptr und kein NO_COPY. Für mich ist ein einziger Member, der ein scoped_ptr ist, genug Dokumentation für "diese Klasse ist nicht kopierbar".
-
operator void schrieb:
Für mich ist ein einziger Member, der ein scoped_ptr ist, genug Dokumentation für "diese Klasse ist nicht kopierbar".
Oha, man muss also alle Nebeneffekte von boost kennen um deinen Code lesen zu koennen.
Da ich nie scoped_ptr verwendet habe, wuerde ich das nicht wissen. Und habe es bis zu diesem Thread auch nicht gewusst.
-
"noncopyable" sollte auf jeden fall in der interface-doku der Klasse stehen. Schließlich will ich nicht nach "boost::noncopyable" oder "volkard::NO_COPY" suchen müssen, um herauszufinden, ob die Klasse nun kopierbar ist.
-
peterchen schrieb:
"noncopyable" sollte auf jeden fall in der interface-doku der Klasse stehen
Klar, aber ich mag es auch, wenn der Code ohne Doku lesbar ist. Wenn ich den Code warte, dann will ich nicht dauernd in die Doku schaun muessen sondern aus dem Code selber die essentiellen Sachen rauslesen.
Und wenn da steht: noncopyable und ich mir die Klasse ansehe und nicht erkenne warum das so ist, dann ist irgendwas falsch.
-
> Klar, aber ich mag es auch, wenn der Code ohne Doku lesbar ist
Deswegen meine ich ja, die Doku sollte aus Code-Kommentaren generiert werden