ich benutze oft den scopeguard von alexandrescu (http://www.ddj.com/cpp/184403758). wer es nicht kennt: durch ein einfaches interface, kann man ressourcen freigeben lassen (oder transaktionen durchführen).

beispiel aus dem artikel:

void* buffer = std::malloc(1024);
ScopeGuard freeIt = MakeGuard(std::free, buffer);
FILE* topSecret = std::fopen("cia.txt");
ScopeGuard closeIt = MakeGuard(std::fclose, topSecret);

der trick ist folgender:

// class ScopeGuardImplBase
    void Dismiss() const throw()
    {    dismissed_ = true;    }
protected:
    ScopeGuardImplBase() : dismissed_(false)
    {}
    ScopeGuardImplBase(const ScopeGuardImplBase& other)
    : dismissed_(other.dismissed_)
    {    other.Dismiss();    }

wenn dismiss_ true ist, werden die ressourcen freigegeben. ansonsten nicht. damit das nur einmal passiert gibt es den aufruf von Dismiss() im copy ctor.

wenn ich nun aber nur ressourcen freigeben will (so wie mit boost::scoped_ptr z.b.) brauche ich den dismiss-mechanismus gar nicht.

aber wie kopiere ich dann meinen modifizierten scopeguard aus makeGuard heraus? ich muss ja verhindern, dass meine ressourcen zweimal freigegeben werden. den copy constructor kann ich nicht verbieten, weil ich sonst nicht mehr makeGuard aufrufen kann. dismiss_ einfach rausschmeißen geht auch nicht, weil dann das problem von oben entsteht.

kann man das irgendwie beheben?

scopeguard muss ja kopierbar sein und da es kopierbar muss es ownership verwalten und dafuer braucht es state.

Shade Of Mine schrieb:

was stoert dich an dismiss? (einfach private setzen wenn der user dismiss() nicht aufrufen soll)

ich brauche es nicht. das objekt soll in jedem fall die ressourcen freigeben.

scopeguard muss ja kopierbar sein und da es kopierbar muss es ownership verwalten und dafuer braucht es state.

d.h. es gibt keine möglichkeit makeGuard so umzuschreiben, dass ich ohne kopie auskomme? (nur zur erinnerung: das objekt wird außer bei makeGuard nicht kopiert.)

{
  ScopeGuard g = makeGuard(&foo, var);
} // g wird ansonsten nicht kopiert

alternativ geht auch ein movable ansatz ala Mojo...

namespace detail
{
	template<class T>
	struct foo
	{
		foo(T) {}
	};
} // detail

class base {};

template <class T>
class bar : public base
{
	typedef detail::foo<T> foo;

public:
	bar(foo) {}

private:
	bar(const bar&);
	bar& operator= (const bar&);
};

template<class T>
detail::foo<T> fun(T t)
{
	return detail::foo<T>(t);
}

int main()
{
	const base& b = fun(2);
}

mein compiler findet den konstruktor von bar nicht (g++ 4.1.2). wie kann ich das beheben?

copy.cpp:36: error: invalid initialization of reference of type 'const base&' from expression of type 'detail::foo<int>'

Also so spontan würde ich da mal sagen, dass das ist, weil es private ist...

das typedef ist private, aber da es eben nur ein alias ist, spielt das keine rolle.

ich habe den code inzwischen vereinfacht (keine templates). der compiler erkennt immer noch nicht, dass es eine umwandlung von foo nach const base& gibt, allerdings habe ich keine ahnung warum. bar steht doch im selben namespace und der compiler sollte den konstruktor finden und als mögliche konvertierung erkennen.

namespace detail
{
	struct foo
	{
		foo(int) {}

	};
} // detail

class base {};

class bar : public base
{
public:
	bar(detail::foo) {}

private:
	bar(const bar&);
	bar& operator= (const bar&);
};

detail::foo fun(int t)
{
	return detail::foo(t);
}

int main()
{
	const base& b = fun(2);
}

das ginge nur, wenn du fun ein bar zurückgeben lassen würdest.

es gibt auch keine umwandlung von detail::foo nach base.

doch, gibt es (existiert):

detail::foo -> bar -> const base&

als test kann man folgendes in die main-funktion schreiben:

const bar& a = fun(2);
	const base& b = a;

oder meinst du, es gibt keine umwandlung (findet keine statt), weil der compiler nicht nach einem entsprechenden konstruktor suchen muss?

Was willst du eigentlich machen? Du kannst anhand der Daten die dir makeGuard() liefert das notwendige Objekt erstellen. Du musst das Objekt nicht sofort erstellen...

oder: makeGuard kann zB das ScopeGuard objekt erstellen und du verwendest im Client Code nur einen ScopeGuard holder - wrappst also den echten ScopeGuard nur.

wenn ich nun aber nur ressourcen freigeben will (so wie mit boost::scoped_ptr z.b.) brauche ich den dismiss-mechanismus gar nicht.

Wenn du nur Resourcen freigeben willst, dann bastel dir eigene RAII Klassen für diese Resourcen.

Die "ScopeGuard" Lösung ist zwar nicht SEHR aufwändig, aber sicher aufwändiger als die Verwendung einer fertigen, spezialisierten RAII Klasse. Ohne diese RAII Klassen tippst du die ScopeGuard Lösung immer wieder und wieder und wieder, und überlegst dir immer wieder und wieder ob man da nicht was besser machen könnte.

Die "ScopeGuard" Lösung ist zwar nicht SEHR aufwändig, aber sicher aufwändiger als die Verwendung einer fertigen, spezialisierten RAII Klasse. Ohne diese RAII Klassen tippst du die ScopeGuard Lösung immer wieder und wieder und wieder, und überlegst dir immer wieder und wieder ob man da nicht was besser machen könnte.

Aeh... nicht wirklich.

Du tippst:

FILE* f=fopen();
ON_BLOCK_EXIT(fclose, f);

Das ist oft weitaus besser als die komplette api zu wrappen. Denn man braucht ScopeGuard genau dann wenn du es mit einer C API zu tun hast. Und die komplette API in schoenes C++ zu wrappen ist nicht trivial und kostet sehr viel zeit.

// Version 1 (flexibel, schnell zu schreiben, einfach)
class FileHandle : private boost::noncopyable
{
public:
    FileHandle() : m_file(0) {}
    explicit FileHandle(FILE* file) : m_file(file) {}

    ~FileHandle()
    {
        if (m_file)
            fclose(m_file);
    }

    FILE* m_file; // ja, public!
};

// Version 2 ("schöner")
class FileHandle : private boost::noncopyable
{
public:
    FileHandle() : m_file(0) {}
    explicit FileHandle(FILE* file) : m_file(file) {}

    ~FileHandle()
    {
        if (IsValid())
            fclose(m_file);
    }

    FILE* Get() const;
    bool IsValid() const;

    void Reset(FILE* file = 0);
    FILE* Release();

private:
    FILE* m_file;
};

Dadurch reduziert sich das ganze in der Anwendung auf:

FileHandle f(fopen(...));

Was einfacher ist.
Sobald man ein FILE* o.ä. als Member in einer Klasse braucht wird der Unterschied noch deutlicher:

// mit ScopeGuard
Foo::Foo(...)
{
    m_file = fopen(...);
    ScopeGuard fileGuard = makeGuard(&fclose, m_file);
    // ... ein haufen anderes Zeug welches Exceptions werfen oder sonstwie schief gehen könnte ...
    fileGuard.Dismiss();
}

Foo::~Foo()
{
    fclose(m_file);
}

// mit spezialisierter RAII Klasse:
Bar::Bar(...)
{
    m_file.Reset(fopen(...));
    // ... ein haufen anderes Zeug welches Exceptions werfen oder sonstwie schief gehen könnte ...
}

Bar::~Bar()
{
}

Es ist zeitweise durchaus praktisch solche minimalen wrapper zu schreiben - aber oft reicht ein scopeguard locker aus. ein scopeguard kann naemlich auch member sein - das bitte nicht vergessen

manchmal finde ich es einfach besser keine klasse nur wegen RAII zu verwenden: beispielsweise wenn ich mir speicher ueber eine spezielle alloc Funktion hole, zB GlobalAlloc. Ich mag den rohen Speicher nicht wirklich kapseln und mir den Aufwand einer neuen Klasse antun. Genau fuer solche Sachen ist ScopeGuard einfach ideal.

fuer FILE* wuerde ich wohl eher einen vollwertigen wrapper basteln - aber das lustige an ScopeGuard ist ja, ich bekomme exakt deine Wrapper Klasse automatisch:

ScopeGuard m = makeGuard(fclose, fopen("foo","w"));
if(m.get()!=NULL) {
}

klappt problemlos.

Und das "m.get()" kann IMO nicht funktionieren da ScopeGuard nix davon weiss dass ein FILE* drinsteckt. Wenn dann müsste man also schon das entsprechende Template direkt verwenden anstatt es in einem ScopeGuard zu verstecken...

Also was eine "halbe lösung" ist ist ja wohl sehr subjektiv
Ich halte hier eher den ScopeGuard für die "halbe lösung".

Und das "m.get()" kann IMO nicht funktionieren da ScopeGuard nix davon weiss dass ein FILE* drinsteckt. Wenn dann müsste man also schon das entsprechende Template direkt verwenden anstatt es in einem ScopeGuard zu verstecken...

stimmt natuerlich - dazu muss man etwas rumbasteln. ScopeGuard<FILE*> guard = makeGuard(fclose, f); oder man verwendet generell ein Makro zur Definition. Das ganze ist aber nur dann relevant wenn man es wirklich als Member einer klasse haben will - in den meisten Faellen reicht ein ON_BLOCK_EXIT() locker.

die ganze idee hinter scopeguards ist es ja den unnoetigen aufwand fuer jede resource eigene wrapper zu schreiben zu eliminieren. man spart sich aufwand - denn jeder programmierer sollte 2mal denken wenn er im prinzip den selben code X mal schreiben muss.

scopeguard bietet die selbe funktionalitaet wie deine minimalen wrapper klassen - kostet mich aber nur minimalen aufwand.