Was taugt Boost?

SirLant

volkard schrieb:

shared_ptr schrieb:

Am beliebtesten ist wohl: boost::shared_ptr

tja, auch so eine sache, die ich absolut nicht nachvollziehen kann.

Und warum?

picocat

1. wo finde ich die erklärung denn für windows? (brauche boost für borland c++ builder 6, bcc32 und dev-cpp)
2. borland c++: d.h., ich muss den boost-ordner nur ins verzeichnis "include" kopieren?

Andreas2

Einige der Boost-Libs funktionieren als "Erweiterung" der STL. D.h., man erhält z.B. Datenstrukturen oder Algorithmen in Form von Templates. Diese Libs funktionieren ohne kompilieren. Andere (z.B. regex) müssen zuerst kompiliert werden, bevor man sie benutzen kann. Einfaches kopieren nützt also nix, wenn man alle Libs nutzen will...

picocat

ich brauche dringend thread

DEvent

John Doe schrieb:

Und wer erstellt die libs für regex, filesystem, thread,... für dich ??

mfg JJ

bezieht sich das auf meine frage?
mein compiler erstellt die libs...
man brauch nur die entsprechenden cpp dateien zu inkluden

Artchi

Naja, eigentlich sollte man einmalig mit jam alle Libs autom. compilieren lassen. Dann kommen am Ende alle wichtigen Libs (Release, Deabug, DLLs usw.) bei raus. Wenn du das alles per Hand mit cpp-Dateien machst, brichst du dir ja nen Ast ab. Jam macht das halt alles autom. für dich. Bei mir ist das Boost-Verzeichnis nach dem Erstellen mit Jam über 250 MB groß. Willste das alles per Hand compilieren?

John Doe

Hi DEvent,

,allerdings. Ich hab im Sourceforge-Paket zumindest noch keine compiler - spezifischen Projektdateien gesehen. Insofern frage ich mich wie du die libs
zusammengebaut bekommst.

mfg JJ

peterchen

SirLant schrieb:

volkard schrieb:
shared_ptr schrieb:
Am beliebtesten ist wohl: boost::shared_ptr

tja, auch so eine sache, die ich absolut nicht nachvollziehen kann.

Und warum?

Hey - das war MEINE Frage!

volkard

SirLant schrieb:

volkard schrieb:

shared_ptr schrieb:

Am beliebtesten ist wohl: boost::shared_ptr

tja, auch so eine sache, die ich absolut nicht nachvollziehen kann.

Und warum?

weil ich sie nicht oder nur exrem selten brauche. ich habe keinen bedarf. ich weiß nicht, warum andere leute bedarf haben. ich schaue leute, die dauernd shared_ptr verwenden, genauso schief an, wie leute, die dauernd dynamic_cast oder switch verwenden.
vielleicht liegt das daran, daß ich gerne besitz und sortierung trenne, wenn oft umsortiert werden muss? also nen schlichten container wie vector als besitzer und nen komischen wie hash_map als index. vielleicht noch mehr indizes, ist ja egal. oder vielleicht weil ich auto_ptr verwende, wenn es nur um schlichte sender-empfänger-probleme gibt? vielleicht auch, weil ich gar nicht weiß, was exceptionsicherheit bedeutet oder weil ich in c++ nur einfache sachen baue und die komplexen lieber in java, wo man diese probleme nicht hat.

DEvent

John Doe schrieb:

compiler - spezifischen Projektdateien gesehen

was meiste damit?
wendu boost::thread brauchst, inkludest du halt die entsprechenden cpp dateien in dein projekt, wo istn da das problem ?
und die libs dafür musst du dann auch nur einmal vom compiler erstellen lassen.

DEvent schrieb:

John Doe schrieb:

compiler - spezifischen Projektdateien gesehen

was meiste damit?
wendu boost::thread brauchst, inkludest du halt die entsprechenden cpp dateien in dein projekt, wo istn da das problem ?
und die libs dafür musst du dann auch nur einmal vom compiler erstellen lassen.

Das ist bestimmt nur eine Ausrede, weil du die INstallation nicht hinbekommen hast.

Ausserdem ist deine Methode mit dem Hin- und Herkopieren voll umst'ndlich.

rüdiger

Code Dateien irgend wo zu inkludieren? WAS!

Lernt doch lieber bjam zu benutzen (Gibt doch genug Howtos dafür) oder benutzt vorkompilierte Pakete, anstelle so ein Müll zu machen.

Artchi

Man muß ja nicht mal mit bjam umgehen können. Die Step by Step Anleitung von Boost reicht völlig aus. Ich hab von bjam vorher nie was gehört, hab es runter geladen und die Boost-Anleitung durch gegangen und hat beim ersten Versuch geklappt. bjam hab ich seit dem auch nie wieder angefasst. Wer Boost nicht installiert bekommt, sollte sich Sorgen um sich selbst machen!

peterchen

@volkard: ist ein Grund.
Allerdings hat man viele der Probleme mit boost:~_ptr (oder ähnlichen smart pointern) auch nicht mehr

m.E. gwehören Smart Pointer zum handwerkszeug jedes "ordentlichen" C++ - Programmierers, weil man sich viele Ressourcenprobleme sparen kann.

Stellen, an denen ich Smart Pointer einsetze:

* Funktionen/Methoden die (komplexe) Objete erstellen.
Das Objekt wird ohne teure Kopie zum retval, kann also direkt weitergegeben werden, und der Erzeuger packt gleich die Anleitung dazu, wie das Objekt freizugeben ist.
bei

CFoo * GetFoo()

muß man dokumentieren und sich Gedanken machen wer den Zeiger wann freigbt.

* Implementation von Copy-On-Write
tritt seltener auf, ist geht aber mit einem ordentlichen smart pointer in der tasche hinreichend simpel.

* Entkopplung von Objekten
Objekt A braucht temporär ein Objekt B als State und will sich nicht drum scheren, ob und wann es B freigeben soll.

terraner

Lars Hupel schrieb:

ich brauche dringend thread

jetzt mal für alle windows-user, die es nicht schaffen die index.html zu lesen:
1. <Boost>\tools\build\jam_src\build.bat
starten. das script startet dann den compiler über die Registry.

2. nach <Boost> wechseln und
bjam "-sTools=COMPILER" install
ausführen

Compiler-Kürzel:

Compiler - Kürzel - Beschreibung
vc7  	        vc MS Visual C++ command-line tools from VisualStudioNET.
vc7-stlport 	vc MS Visual C++ cmd-line tools from Visual Studio .NET+STLPort.
vc-7_1 	        vc Visual C++ command-line tools from Visual Studio .NET 2003.
vc-7_1-stlport 	vc Microsoft Visual C++ command-line tools from Visual Studio .NET 2003 + STLPort.

- ungetestet -

mfg

volkard

peterchen schrieb:

m.E. gwehören Smart Pointer zum handwerkszeug jedes "ordentlichen" C++ - Programmierers, weil man sich viele Ressourcenprobleme sparen kann.

ganz deiner meinung.

* Funktionen/Methoden die (komplexe) Objete erstellen.
Das Objekt wird ohne teure Kopie zum retval, kann also direkt weitergegeben werden, und der Erzeuger packt gleich die Anleitung dazu, wie das Objekt freizugeben ist.

sieht nach auto_ptr aus.
achn nur wegen performance? warum glaubste nicht an RVO?

bei
CFoo * GetFoo()
muß man dokumentieren und sich Gedanken machen wer den Zeiger wann freigbt.

der macht frei, der angelegt hat? oder zur makeFoo die entsprechende destroyFoo.

* Implementation von Copy-On-Write
tritt seltener auf, ist geht aber mit einem ordentlichen smart pointer in der tasche hinreichend simpel.

naja, echt selten.

* Entkopplung von Objekten
Objekt A braucht temporär ein Objekt B als State und will sich nicht drum scheren, ob und wann es B freigeben soll.

temporäre variablen liegen auf dem heap.
für enbtkopplung ala pimpl gibts besseres.

Ich hab mich sowieso schon immer gefragt, warum man für dieses pimpl idiom einen smart pointer braucht, wos doch auch ein normaler tut.

Helium

weil ich sie nicht oder nur exrem selten brauche. ich habe keinen bedarf. ich weiß nicht, warum andere leute bedarf haben. ich schaue leute, die dauernd shared_ptr verwenden, genauso schief an, wie leute, die dauernd dynamic_cast oder switch verwenden.

Naja, durch Smartpointer kommen 99% aller Klasse ohne selbstgeschriebenen Destruktor aus. Das heißt man muss nurnoch Copy-C'tor und operator = implementieren oder ein NO_COPY-Makro einbauen.
Von wegen "Regel der großen Drei".

Ich bin sowieso jemand, der in der Richtung sehr extrem ist. Sowas, wie "close" oder ähnliches existiert bei mir eigentlich gar nicht mehr. Bei mir geht alles über RAII. Ich komme damit wunderbar klar, habe bisher keine Geschwindigkeitsprobleme gehabt, bin eigentlich immer Exceptionsicher und muss mich niemals ums freigeben kümmern.

Zurück zur eigentliche Frage. Boost ist keine Spielerei. Ohne Boost käme ich gar nicht mehr aus. Bei mir geibt es immer öfter boost::function und boost::bind. Einfach genial und inzwischen bei mir unverzichtbar.

Artchi

peterchen schrieb:

* Funktionen/Methoden die (komplexe) Objete erstellen.
Das Objekt wird ohne teure Kopie zum retval, kann also direkt weitergegeben werden, und der Erzeuger packt gleich die Anleitung dazu, wie das Objekt freizugeben ist.
bei
CFoo * GetFoo()
muß man dokumentieren und sich Gedanken machen wer den Zeiger wann freigbt.

Kommste auch ohne Boost aus, hier kann dir auto_ptr<> helfen. Ist sogar in den meisten Fällen sinnvoller als smart_ptr, wie ich finde. Außer man hat eine Factory, dann ist natürlich smart_ptr für den User komfortabler.

Bei öffentlichen Schnittstellen vermeide ich aber prinzipiell native Pointer. Nur bei privaten Methoden, wo ich weiß was passiert, sind native Pointer schon mal zu sehen.

peterchen

Stimmt, viele Sachen kann man auch anders lösen, auch effektiver.

Mein Gedanke ist: Smart Pointer braucht man sowieso. Wenn man sie also "fleißig" benutzt, ist man an ein paar Stellen vielleicht nicht so effektiv, aber hat insgesamt eine weniger komplexe Lösung.

Das folgende also nur warum *ich* an den gegebenen Stellen einen smart pointer bevorzuge (ob boost oder loki oder sonstwer ist mir fast egal, aber boost mag ich halt)

auto_ptr ist mein ganz persönlicher Feind. Löst zwar in den meisten Fällen das Problem genausogut, nur sind die Fälle schwieriger festzustellen, man muß ständig die Ownership im Hinterkopf behalten, es gibt immer eine "besondere" auto_ptr-Variable.

ein separates destroyFoo will ich ja gerade vermeiden - der Client soll nicht mehr darüber nachdenken müssen, wo er den Zeiger herbekommt. Die Flexibilität einer create/destroy - Schnittstelle bekommst du auch mit einem custom deleter hin. Das ist besonders nett, wenn du zwischen mehreren Factories wählen kannst / mußt. (gibt's nicht? hast du einen HDC, mußt du DeleteDC, ReleaseDC oder gar nix machen?)

Für PIMPL würd ich scoped_ptr verwenden :=)
Natürlich kümmert der sich "nur" um das eine kleine delete. Aber am Tagesende fragt mich mein Chef nicht, ob ich an alle deletes gedacht habe, sondern ob die Kurve schon krumm und bunt ist. Jede Sache die ich vergessen kann ist mir also recht.

Bei "Entkoppelung" denk ich an so simple Dinge wie: welchen Font verwendet mein Control heute zum Zeichnen. Ist eine Eigenschaft des Controls, soll der Client jederzeit ändern können. Natürlich darf der auf dem Heap liegen - aber vielleicht ja grad mal nicht? Oder kommt aus einer anderen Bibliothek die sich selbst drum kümmert? Mit einem guten Smart Pointer kann man dicht an der "schmalsten Brücke" bleiben, kann aber hat aberweniger zu beachten.

RVO: ist leider nicht garantiert.