Wer räumt eigentlich den Speicher auf ;-)

sven_jo

Konrad schrieb:

sven_jo schrieb:

Noch ein Satz zu Feldern & Smart-Pointern: Die Smart-Pointer für Felder heißen std::vector und std::string.
Sven

Das sind keine SmartPtr sonder ein dynamisches Array und ein String, die verwalten zwar intern auch den benötigten Speicher aber SmartPtr sind etwas anderes.

Vollkommen korrekt! Da C++ Klassen für dynamische Arrays und Strings besitzt, braucht man keine Smart-Ptr für Felder. Daher meine Aussage: Die Smart-Pointer für Felder heißen std::vector und std::string.

Die Smart-Pointer boost::scoped_array und boost::shared_array könnten zum migrieren von altem Code verwendet werden. Diese Vorgehensweise kann ich nicht empfehlen.

Wenn man in seinem Code ein new[...] / delete ...[] verwendet, sollte man den Code auf echte C++-Klassen für dynamische Felder oder Strings umstellen. -> also: std::vector und std::string.

Sven

volkard

sven_jo schrieb:

Konrad schrieb:

sven_jo schrieb:

Noch ein Satz zu Feldern & Smart-Pointern: Die Smart-Pointer für Felder heißen std::vector und std::string.
Sven

Das sind keine SmartPtr sonder ein dynamisches Array und ein String, die verwalten zwar intern auch den benötigten Speicher aber SmartPtr sind etwas anderes.

Vollkommen korrekt! Da C++ Klassen für dynamische Arrays und Strings besitzt, braucht man keine Smart-Ptr für Felder. Daher meine Aussage: Die Smart-Pointer für Felder heißen std::vector und std::string.

so ein quatsch. strings stellen zeichenketten dar und vector stellet dynamische arrays dar.

außerdem: vector und string sind im allgemeinen gute sachen und smartpointers sind im allgemeinen schlechte sachen.

camper

volkard schrieb:

sven_jo schrieb:

Konrad schrieb:

sven_jo schrieb:

Noch ein Satz zu Feldern & Smart-Pointern: Die Smart-Pointer für Felder heißen std::vector und std::string.
Sven

Das sind keine SmartPtr sonder ein dynamisches Array und ein String, die verwalten zwar intern auch den benötigten Speicher aber SmartPtr sind etwas anderes.

Vollkommen korrekt! Da C++ Klassen für dynamische Arrays und Strings besitzt, braucht man keine Smart-Ptr für Felder. Daher meine Aussage: Die Smart-Pointer für Felder heißen std::vector und std::string.

so ein quatsch. strings stellen zeichenketten dar und vector stellet dynamische arrays dar.

außerdem: vector und string sind im allgemeinen gute sachen und smartpointers sind im allgemeinen schlechte sachen.

das von jemand, für den alle verallgemeinerungen falsch sind?

smartpointer sind ein mittel wie jedes andere, um probleme zu lösen - sie können nützlich sein; aber sie um der verwendung willen einzusetzen wird eher problem verursachen. das "schlechte" daran ist dann aber immer noch nicht der smartpointer, sondern der programmierer, der ihn benutzt.

otze

volkard schrieb:

sven_jo schrieb:

Konrad schrieb:

sven_jo schrieb:

Noch ein Satz zu Feldern & Smart-Pointern: Die Smart-Pointer für Felder heißen std::vector und std::string.
Sven

Das sind keine SmartPtr sonder ein dynamisches Array und ein String, die verwalten zwar intern auch den benötigten Speicher aber SmartPtr sind etwas anderes.

Vollkommen korrekt! Da C++ Klassen für dynamische Arrays und Strings besitzt, braucht man keine Smart-Ptr für Felder. Daher meine Aussage: Die Smart-Pointer für Felder heißen std::vector und std::string.

so ein quatsch. strings stellen zeichenketten dar und vector stellet dynamische arrays dar.

außerdem: vector und string sind im allgemeinen gute sachen und smartpointers sind im allgemeinen schlechte sachen.

du schuldest uns aber immernoch eine aufschlüsselung darüber, wieso

volkard

otze schrieb:

du schuldest uns aber immernoch eine aufschlüsselung darüber, wieso

smartpoiunter tauchen meistens dann auf, wenn man designfehler wegfrickeln muß. mehr dazu im letzten thread über smartpointer.

.filmor

Ein Container polymorpher Objekte ist ein Designfehler? Also bitte ...

volkard würde einen Wrapper um den Container schreiben der im Destruktor für jedes Element delete aufruft.

volkard

ao schrieb:

volkard würde einen Wrapper um den Container schreiben der im Destruktor für jedes Element delete aufruft.

vielleicht würde er auch einen container mit lösch-policy haben. alexandrescu er gelesen hat.

xaoC

camper

volkard schrieb:

ao schrieb:

volkard würde einen Wrapper um den Container schreiben der im Destruktor für jedes Element delete aufruft.

vielleicht würde er auch einen container mit lösch-policy haben. alexandrescu er gelesen hat.

alexandrescu smart pointer mag. ihnen einen großen teil von MCPPD eingeräumt hat.

Bitte deutsch, wir sind hier nicht im Kindergartenforum.

volkard

camper schrieb:

volkard schrieb:

ao schrieb:

volkard würde einen Wrapper um den Container schreiben der im Destruktor für jedes Element delete aufruft.

vielleicht würde er auch einen container mit lösch-policy haben. alexandrescu er gelesen hat.

alexandrescu smart pointer mag. ihnen einen großen teil von MCPPD eingeräumt hat.

alexandrescu mag vieles mögen. aber ich hab bei ihm keinen schwachsinn gesehen. und mindestens malk bedebkleich wäre es, statt bei einem objekt nachzufragen bei millionen von objekten nachzufragen. und im falle, daß man ein paar sachen aus <algorithm> verwenden mag, gleich mit shared_ptr aufzutrumpfen mit 100% speicheroverhead statt mit zeigern in nem smart container.

Sandkastenuser schrieb:

Bitte deutsch, hier nicht im Kindergartenforum wir sind.

deutsch wir sprechen doch.

otze

was wärs denn mit diesem szenario?

class BaseFile{
    public:
        const string& getName();
};

//je nach bs braucht man andere funktionen, also packen wir das in ne policy
//alternativ kann man sich hier irgendein anderes szenario ausdenken, an dem polymorphie nützlich ist, zb dass es verschiedene dateitypen gibt
template<class FilePolicy>
class ConcreteFile:public BaseFile{
    public:
        const string& getName();
};

//da wir keinen template wirrwarr in unsrem code dulden, und polymorphie eh nur ein mittel zum zweck ist, kapseln wir das schön weg

class File{
    private:
        BaseFile* file;
    public:
        File(BaseFile* file):file(file){}

        const string& getName(){
            return file->getName();
        }
        //dtor lass ich erstmal weg
};

//nun brauchen wir ne factory class
template<class FilePolicy>
class FileFactory{
    public:
        File openFile(std::string& path);
}

man kann mir zwar als designfehler unterstellen, dass ich File unbedingt auf dem Stack haben will, aber das erleichtert dem benutzer das verwenden dieser Objekte ungemein. Ausserdem ist son stack objekt beiweitem weniger kryptisch als ein smart_ptr.

Wo wir grad bei smart_ptr sind: class File braucht natürlich einen. Hat damit zu tun, dass das ding kopiert werden kann ;). Die frage ist nun, welcher: Da wir hier keine deep copy des objektes brauchen, da dateien einmalig sind, brauchen wir uns net damit zu beschäftigen, dass es keinen smart_ptr gibt, der deep copy unterstützt(*heul*). Andererseits ist es natürlich nicht so, dass wir File überhaupt nicht kopieren, das ist einerseits durch die Factory gegeben, andererseits werden solche Handles gerne mal rumgereicht, sodass ein delete im dtor nicht mehr ausreicht(bzw ein scoped_ptr, btw: ein scoped_ptr mit deep copy policy wär mal richtig nice, dann könnte man ihn sogar innerhalb von Objekten sinnvoll nutzen).
auto_ptr schließen wir auch aus, weil gerne mehrere klassen die möglichkeiten haben wollen, auf diese daten zuzugreifen. Bleibt also nurnoch der shared_ptr, weil wir hier referenzzählung brauchen.

class File{
    private:
        boost::shared_ptr<BaseFile> file;
    public:
        File(boost::shared_ptr<BaseFile> file):file(file){}

        const string& getName(){
            return file->getName();
        }
        //dtor brauch ich nimmer
};

Und wo ist jetzt der Sinn Templates zu verwenden, wenn du eh keinen Gebrauch davon machst?

otze

Sinn schrieb:

Und wo ist jetzt der Sinn Templates zu verwenden, wenn du eh keinen Gebrauch davon machst?

die werden in der factory benutzt, und sind nach aussen hin nicht mehr da. das factory modul beeinflusst also nicht mehr den rest des user codes.
(könnte man auch über functoren erreichen, aber das ist nicht immer möglich/nötig)