#include <string>
#include <iostream>

int main()
{
    std::string prefix("->"), middle(), suffix("<-");
    std::cout << "This space has been intentionally left blank: "
              << prefix << middle << suffix
              << std::endl;

    return 0;
}

(Linker-)Fehlermeldung von VS2012:

1>Main.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol ""class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > __cdecl middle(void)" (?middle@@YA?AV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@XZ)" in Funktion "_main".
1>X:\FUUUUUU.exe : fatal error LNK1120: 1 nicht aufgelöste Externe

Ausgabe laut Ideone:

This space has been intentionally left blank: ->1<-

Hä??
Wieso?

Ich würde selbst eigentlich vermuten, dass da die Adresse der Funktion std::string middle() rauskommt. Aber das erklärt nicht die 1 beim GCC und der MSVC kann ja eigentlich auch mit nicht aufgerufenen Funktionen in der Ausgabe umgehen oO

Ich würde selbst eigentlich vermuten, dass da die Adresse der Funktion std::string middle() rauskommt. Aber das erklärt nicht die 1 beim GCC und der MSVC kann ja eigentlich auch mit nicht aufgerufenen Funktionen in der Ausgabe umgehen oO

Der GCC benutzt, dass eine Funktion nicht Adresse 0 haben kann und optimiert das daher zu true:

test.cc:8:28: warning: the address of \u2018std::string middle()\u2019 will always evaluate as \u2018true\u2019 [-Waddress]
               << prefix << middle << suffix

Der MSVC will hingegen wirklich die Adresse der Funktion wissen, bevor er sich darauf einlässt. Dummerweise ist sie nirgends definiert.

Ich würde, ohne den Standard zu wälzen, sagen, dass beide Recht haben. Der Standard sagt normalerweise nicht viel über Linkage. Ob es regulär ist, die Adresse einer nicht-existierenden Funktion zu nehmen würde ich daher als einen Fall vermuten, der im Standard gar nicht weiter erwähnt wird. Aber ich habe nicht geguckt. Ich warte selber auf die Antwort derer, die den Standard auswendig kennen.

ostream& operator<< (bool val);
ostream& operator<< (short val);
ostream& operator<< (unsigned short val);
ostream& operator<< (int val);
ostream& operator<< (unsigned int val);
ostream& operator<< (long val);
ostream& operator<< (unsigned long val);
ostream& operator<< (float val);
ostream& operator<< (double val);
ostream& operator<< (long double val);
ostream& operator<< (void* val);

Da gibt es nur eine Überladung die einen Zeiger nimmt. Aber da es ein void-Zeiger ist, geht das doch sowieso nicht. Ein Funktionszeiger kann nicht implizit in einen void-Zeiger konvertiert werden, oder täusch ich mich da nun?

Ein Funktionszeiger kann nicht implizit in einen void-Zeiger konvertiert werden, oder täusch ich mich da nun?

Nö, das ist nur für Objekttypen definiert

A prvalue of type “pointer to cv T,” where T is an object type, can be converted to a prvalue of type “pointer
to cv void”.

Ein Funktionszeiger kann nicht implizit in einen void-Zeiger konvertiert werden, oder täusch ich mich da nun?

Kann er eh nicht.
Muss er auch nicht.
Die implizierte Konvertierung nach bool funktioniert aber trotzdem.
Der Unterschied ist bloss, dass MSVC den Vergleich nicht wegoptimiert, ideone dagegen schon.

Aber letztlich ist der Fehler also, dass die Implementation der middle-Funktion fehlt und deshalb der Linker meckert?!

Ich würde, ohne den Standard zu wälzen, sagen, dass beide Recht haben.

So ist es.
Die Bestimmung der Adresse einer Funktion (in einem potentiell ausgewerteten Ausdruck) stellt eine ODR-Nutzung derselben dar (3.2/2).
Für jede nicht-inline Funktion, die ODR-genutzt wird, muss im Programm genau eine Definition existieren, eine Diagnose durch den Compiler ist aber nicht erforderlich (3.2/3).