[C++] Syntax für friend operator new

[Krishty]

Ich werde noch bekloppt. Warum geht das hier nicht?

  class Foo {
    friend void * ::operator new(size_t, Foo &);
  };

Wenn ich das :: weglasse frisst VC es, aber dann habe ich einen operator new in der Klasse deklariert statt einen globalen. Ich habe auch schon

  class Foo {
    friend void * (::operator new)(size_t, Foo &);
  };

versucht; selber Fehler: error C2063: 'operator new' : not a function

Helft mir bevor ich hier alles zerlege!

[BeRsErKeR]

Ohne das :: ist es doch korrekt. Klar ist der Operator in der Klasse deklariert, aber durch das friend ist er ja dennoch global.

Du schreibst einen Stream-Operator ja auch so:

Code: Alles auswählen

friend std::ostream & operator<< (std::ostream &, const Foo &);

[Krishty]

Du hast recht; ich korrigiere:

  namespace X {
    class Foo {
      friend void * operator new(size_t, Foo &);
    };
  }

Er legt diesen operator new dann im namespace X an. Was Schwachsinn ist, weil operator new nicht in Namespaces deklariert werden darf. Dort will ich ihn auch garnicht haben. Wie kriege ich ihn global? Wenn ich :: davor schreibe kommt der Syntaxfehler :(

[BeRsErKeR]

http://stackoverflow.com/questions/2207 ... -namespace

[Krishty]

Ich habe auch schon

  class Foo {
    friend void * (::operator new)(size_t, Foo &);
  };

versucht; selber Fehler: error C2063: 'operator new' : not a function

[Krishty]

Oh warte; jetzt verstehe ich es – ich muss den Operator vorher deklarieren!

WTF?! Ich dachte, jede friend-Deklaration wäre eine … Deklaration! WTF WTF WTF, warum geht das nicht?

A reasonable person might ask why it does not suffice to write "friend class ::F;" (as shown in the OP's code), thus explicitly pushing F into the global namespace. I think the answer is along the lines of "a qualified-id never declares a new name" but am not sure exactly what the standard says on this point.

…

… also wieder üblicher C++-Syntax-Bullshit …

vielen Danke für Hilfe & Geduld!

[BeRsErKeR]

Ich nehme an das ist nötig, weil du es in einem separaten Namespace deklarierst. Das kompiliert übrigens auch, wenn du es im Namespace der Klasse hast und zusätzlich vorher eine zusätzliche Deklaration in diesem Namespace hast. Ich denke mal, dass das eigentlich der übliche Weg ist, aber es in diesem Fall zwingend nötig ist, damit der Compiler rafft, dass es in einem anderen Namespace deklariert wurde. Normal wird er einfach annehmen, dass sich die Deklaration im Namespace befindet, in dem sich auch die Klasse selbst befindet. Das ist hier dann aber nicht möglich.

Präziser ausgedrückt gehört zu der friend-"Deklaration" also immer die Extra-Deklaration im Namespace, nur kann es der Compiler im Normalfall (bei selbem Namespace) auch ohne diese Extra-Deklaration auflösen, da er den Namespace der Klasse selbst annimmt. Sauber wäre also, wenn das nie ohne die Extra-Deklaration kompiliert. "Deklaration" ist bei friend also eher eine Fehlinterpretation.

Code: Alles auswählen

namespace NAME
{
	void * operator new(size_t, NAME::Foo &); // Kann in diesem Fall vernachlässigt werden, da es sich um den selben Namespace handelt.

	class Foo
	{
        public:
            friend void * (operator new) (size_t, Foo &);
	};

	void * operator new (size_t, NAME::Foo & foo)
	{
		...
	}
};

[Krishty]

Ja; aber das (::operator new) ist ja 1. eindeutig global und 2. für Klassennamen im Rückgabewert sogar nötige Voraussetzung. Wenn er es in diesen Fällen rafft, warum dann nicht auch ohne vorherige Deklaration?

Zumal es ja illegal ist, new oder delete in einem Namespace zu deklarieren – was es noch eindeutiger macht.

[BeRsErKeR]

Ich nehme an aus dem selben Grund, aus dem der folgende Code das gleiche Problem verursacht, obwohl alles im Namespace NAME liegt:

Code: Alles auswählen

friend void * (NAME::operator new) (size_t, Foo &);

Sobald du explizit einen Namensraum angibst scheint der Compiler nicht mehr in der Lage zu sein, eigenständig die Deklaration hinzuzufügen. Die friend-"Deklaration" ist in meinen Augen keine Deklaration per se, sondern eher ein Verweis auf eine andere Deklaration. Und genau diese scheint der Compiler nur dann anzulegen, wenn man den Verweis (friend) nicht explizit mit Namespace festlegt. Ob das nun ein Bug ist oder einen tieferen Sinn hat, kann ich dir auch nicht sagen. Auf jeden Fall ist das nicht nur für den global namespace so.

Nachtrag: Könnte das eventuell mit ADL zu tun haben, das ich durch die Angabe des Namespaces ausheble?

[BeRsErKeR]

Gerade noch ein paar ähnliche Sachen auf SO gefunden. Geht zwar um friends bei Template-Klassen, aber da steht auch was zum Lookup:

When you declare a function as a friend of a class the declaration is strange in the sense that it declares a namespace level function, but the declaration of it will only be available through ADL on the enclosing type.

Because ADL looks in the class of the argument, and also in the base classes, this will effectively trigger lookup inside IneqCmp<IntCont> and that will find the friend declaration and thus the free function.

Another alternative would be to add a namespace where the generic operator!= will be defined (so that it won't be found otherwise) and a tag type. Then inherit from that tag: ...

Scheint also wirklich so zu sein wie ich dachte. ADL ermöglicht es, dass die Deklaration gefunden wird (auch wenn sie nur innerhalb der Klasse als friend ist) und bei expliziter Angabe eines Namespaces greift ADL nicht mehr und der Compiler guckt nur im angegebenen Namespace, wo dann natürlich keine Deklaration vorhanden ist. Eigentlich recht logisch, sofern man ADL mit einbezieht. Wie gesagt wäre ohne ADL immer die Extra-Deklaration im richtigen Namespace nötig.

[Krishty]

Ja; unter ADL-Betrachtung ist das tatsächlich sinnvoll – und lässt sich für inline friends vorzüglich als Feature missbrauchen. Danke!