Jedenfalls hat myObject zwar noch den Wert 0 im catch, aber das new wurde ja bereits aufgerufen - so gesehen also doch ein Speicherleck?

MyClass* myObject=0;
	try
	{
		myObject= new MyClass ( functionThrowingException() );
	}
	catch(...)
	{
		return false;
	}

Problematisch wäre folgender Fall:

MyClass* myObject=0;
    try
    {
        myObject= new MyClass ( functionThrowingException() );
        // Hier eine Exception
    }
    catch(...)
    {
        return false;
    }
    // Oder auch hier

Da du nicht das RAII-Idiom verwendest (warum nicht? Das hätte nur Vorteile), wäre da ein Speicherleck.

^*: Falls MyClass selber Ressourcen beschlagnahmt hat, bevor die Exception kam, muss es diese natürlich trotzdem wieder richtig freigeben. Siehe meinen Tipp über RAII, wie dieser Vorgang automatisiert werden kann.

So nix Speicherlöcher mehr.

Wenn ich im VS mit dem Debugger durchsteppe, so wird zuerst void* __cdecl operator new(size_t nSize) aufgerufen, und erst dann functionThrowingException().
Also laut dem, was ich im Debugger sehe, gibts ein Speicherleck!

Also laut dem, was ich im Debugger sehe, gibts ein Speicherleck!

Speicherlecks haben es so an sich, dass sie nicht dann auftreten, wenn man sie erwartet, sondern an einer anderen Stelle.

Bei dir ist es jedenfalls so, dass im Fall von return false kein Speicherleck ist.

Dass es bei solchem Code woanders auftritt ist allerdings sehr wahrscheinlich. Leute die Pointer verwenden, diese auf 0 initialisieren und mit Exceptions spielen wie vor 30 Jahren sind immer suspekt.

Grund war:

Dass es bei solchem Code woanders auftritt ist allerdings sehr wahrscheinlich. Leute die Pointer verwenden, diese auf 0 initialisieren und mit Exceptions spielen wie vor 30 Jahren sind immer suspekt.