Wer räumt eigentlich den Speicher auf ;-)

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)