struct UID {
    explicit UID(const char *uid) { }
};

struct Test{
    Test(const UID& s){}
    void fct(){}
};

const char *v="Test";

int main() {
    Test    t(UID("Test"));
    t.fct();

    Test    t2(UID(v));
    t2.fct();

    return 0;
}

entsteht das Problem, dass das Object t die Memberfunktion fct() aufrufen kann. t2 kann dies jedoch nicht.
Die Fehlermeldung (g++-4.3.2 und auch g++-3.4) ist

Test.cc: In function ‘int main()’:
Test.cc:17: error: request for member ‘fct’ in ‘t2’, which is of non-class type ‘Test ()(UID)’

Ich verstehe das Problem aber nicht. Wenn ich den constructor in UID nicht explicit mache, geht es. Wenn er explicit ist, tritt das Problem auf. Wieso?

Kann mir da jemand weiter helfen? Ist dieses Verhalten richtig/Standard oder hat der Compiler hier einen Bug.

Grüße und Danke
Mysterio

UID u(v);
    Test t2( u ); 
    t2.fct();

Test    t2(UID(v));

scheint als Funktionsdeklaration aufgefasst zu werden.

Was mich allerdings ein wenig erstaunt, da UID(v) eigentlich keine Parameterdeklaration ist...

Das hier geht:

UID u(v);
    Test t2( u ); 
    t2.fct();

Ja stimmt, hatte ich auch schon rausgefunden, aber leider vergessen mit reinzuschreiben.

Ich versteh aber nicht warum es so geht, aber wenn ich es als temporäres Objekt habe nicht. Ist mir nicht klar, zumal der Fehler nicht beim Aufbau des Objektes passiert, sondern später.

Test t2( UID(static_cast<const char*>(v)) );

und

Test t2( (UID(v)) );

Keine Ahnung was da läuft...
Insbesondere das Zweite gibt mir zu denken.

Unter MSVC++ erhält man ebenso einen Fehler. Wie gesagt erkennt der Compiler die Zeile als Funktionsdeklaration. Ich bin selbst ein wenig verwirrt; eventuell hat das mit der Auswertungs-/Parserreihenfolge des Kompilierens zu tun...

Du hast meinen Beitrag wohl übersehen, da du 5 Sekunden später auch gleich gepostet hast...

Ja hatte ich wohl.

Nexus schrieb:

Unter MSVC++ erhält man ebenso einen Fehler. Wie gesagt erkennt der Compiler die Zeile als Funktionsdeklaration. Ich bin selbst ein wenig verwirrt; eventuell hat das mit der Auswertungs-/Parserreihenfolge des Kompilierens zu tun...

Und was kann ich dann jetzt daraus schließen? Haben beide Compiler einen bug? Ist dies ein Problem im Standard? Habe keine Ahnung. Ich meine es gibt ja workarounds, wie tandem ja schon gezeigt hat. Aber ist dies die Lösung?

Gruß

void foo (int (bar));

MSVC, GCC, BCC und Comeau compilieren das anstandslos. Bei BCC resultiert typeid (foo).name () in "void (*)(int)"; was aus dem bar wird, ist mir momentan nicht nachvollziehbar.

Ich vermute ein parserbedingtes Defizit. Sobald man bar durch einen bekannten Typen ersetzt, z.B. int, wird das Argument zu einem Funktionszeiger ("void ()(int ()(int))").

std::vector<double> vec(
	std::istream_iterator<double>(std::cin),
	std::istream_iterator<double>());

Hier passiert der gleiche Fehler.
Sobald man diese Version verwendet, um ein Objekt zu konstruieren, darf man leider nicht bei allen Argumenten einen Typen angeben. (Ich hoffe den Satz kann man verstehen :))
Also sowas würde bereits wieder funktionieren:

std::istream_iterator<double> iend;

std::vector<double> vec(
	std::istream_iterator<double>(std::cin),
	iend);

Entweder man nimmt die Argumente raus und erstellt sie, bevor man sie dem Konstruktor übergibt. Oder man verwendet die alternative Schreibeweise:

std::vector<double> vec =
	std::vector<double>(
		std::istream_iterator<double>(std::cin),
		std::istream_iterator<double>());

// bzw. auf das andere Beispiel bezogen:
Test t2 = Test(UID(v));

// bzw. hier sogar, da der Konstruktor von Test nicht explicit ist
// und nur ein Argument erwartet wird:
Test t2 = UID(v);

Hat also überhaupt nichts mit einem Bug zu tun, sondern ist absolut korrektes Standardverhalten. Auch wenn der Standard in dem Bereich ein wenig unsinnig ist. Ich habe bisher keinen Fall kennen gelernt, wo eine Funktionsdeklaration in einer Funktion wirklich sinnvoll war.

Grüssli

Sehr bekanntes Problem.

Dann sieh dir bitte mal meine Reduktion an und sage mir, was der Compiler mit bar macht.

Dravere schrieb:

Sehr bekanntes Problem.

Dann sieh dir bitte mal meine Reduktion an und sage mir, was der Compiler mit bar macht.

Er lässt es dort, für ihn ist es das gleiche wie:

void foo(int bar);

Diese Klammerung kann man zum Teil auch sinnvoll einsetzen:

template<typename T, std::size_t N>
std::size_t getArraySize(T const (&arr)[N])
{
  return N;
}

Da hast du auch solche Klammern, nur sind sie hier von belang. Beim anderen sind sie halt überflüssig.

Grüssli

audacia schrieb:

Dravere schrieb:

Sehr bekanntes Problem.

Dann sieh dir bitte mal meine Reduktion an und sage mir, was der Compiler mit bar macht.

Er lässt es dort, für ihn ist es das gleiche wie:

void foo(int bar);

Aah, daß der Parameter in Klammern gesetzt werden darf, war mir nicht mehr bewußt.

Dravere schrieb:

Diese Klammerung kann man zum Teil auch sinnvoll einsetzen:

template<typename T, std::size_t N>
std::size_t getArraySize(T const (&arr)[N])
{
  return N;
}

Tatsächlich - ich kann mich sogar erinnern, das schon einmal benutzt zu haben.

Ist wohl doch schon etwas spät

Es ist also ein Problem mit der Kontextsensitivitaet von C/C++. Weiss jemand, ob dies vielleicht in der zukuenftigen Version des Standards geaendert wird.

Gruss