Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

Werbeanzeige

drakon

Supermoderator

Beiträge: 6 513

Wohnort: Schweiz

Beruf: Entrepreneur

  • Private Nachricht senden

21

24.10.2009, 17:40

Zitat von »"Nexus"«

"Signatur" ist für mich einfach ein Begriff, mit dem man im Standard effektiv arbeitet. Sonst - gerade bei Überladung - wäre die ganze Zeit von "Signatur ohne Rückgabetyp" oder so die Rede, was ja auch nicht das Wahre sein kann.

Das ist der springende Punkt. Es sollte ebenfalls eine Überladung möglich sein.

Zur Realisierung:
Ich würde da einfach schauen lassen, in welchem Kontext die Funktion aufgerufen wird und dann entscheiden lassen, welche Funktion genommen wird.
Bsp:

C-/C++-Quelltext

1
2
3
4
5
6
7
8
9
int foo (){..}
bool foo (){..}

...

int i = foo (); // ruft int foo auf

bool b = foo (); // ruft bool foo auf


if ( foo() ); // ruft bool foo auf


Umwandlungen wären dann gleich, wie sonst auch. Aber wir kommen wieder extrem vom Thema ab. :p

22

24.10.2009, 18:02

Zitat von »"drakon"«

Zur Realisierung:
Ich würde da einfach schauen lassen, in welchem Kontext die Funktion aufgerufen wird und dann entscheiden lassen, welche Funktion genommen wird.
Das heisst, du musst massiv viele Aufrufe, bei denen der erwartete Typ nicht 100% dem Rückgabetyp entspricht, verbieten.

C-/C++-Quelltext

1
long l = foo(); // Fehler

Das heisst auch, Benutzung in Templates ist unmöglich, weil mehrdeutig.

C-/C++-Quelltext

1
2
3
4
template <typename T>
void bar(T t);

bar(foo()); // Fehler

Ausserdem heisst das, Ausdrücke der folgenden Art müssten verboten werden (wenn du meinst, bool hätte in arithmetischen Ausdrücken nichts zu suchen, nimm short vs. int).

C-/C++-Quelltext

1
2.3 * foo() // Fehler

Dein Ansatz würde also das halbe Typsystem von C++ über den Haufen werfen. Es ist nicht mehr möglich, den Typ eines Ausdrucks zu bestimmen. Implizite Konvertierungen zwischen arithmetischen Typen gehören zur Sprache, Überladung des Rückgabetypen würde diese sehr stark einschränken.

Das, was du erreichen willst, lässt sich bereits jetzt über benutzerdefinierte Konvertierungsoperatoren implementieren:

C-/C++-Quelltext

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
struct MyClass
{
    operator int() const
    {
        std::cout << "INT" << std::endl;
        return 33;
    }
    
    operator bool() const
    {
        std::cout << "BOOL" << std::endl;
        return false;
    }

};


int main() 
{
    MyClass c;
    int a = c;
    bool b = c;
    
    if (MyClass())
    {
        std::cout << "OK" << std::endl;
    }
} 

Der Code ist eindeutig, das Verhalten wie erwartet.

drakon

Supermoderator

Beiträge: 6 513

Wohnort: Schweiz

Beruf: Entrepreneur

  • Private Nachricht senden

23

24.10.2009, 18:13

Du hast die genau gleichen Probleme, wie bei der Parameterüberladung.

Eine implizite Umwandlung ist möglich und wenn man halt Typen, wie short und int hat, dann muss halt entschieden werden. (nötigenfalls mit einem cast).

24

24.10.2009, 18:30

Zitat von »"drakon"«

Du hast die genau gleichen Probleme, wie bei der Parameterüberladung.
Was die Mehrdeutigkeit und deren Auflösung betrifft, in erster Linie ja. Aber die Auswirkungen sind anders. Dass ein Ausdruck plötzlich keinen bestimmbaren Typen mehr hat, ist eine starke Abweichung vom C++-Typensystem, findest du nicht? Das heisst unter anderem, dass ein Funktionsaufruf nicht mehr für sich stehen kann. Oder dass weder sizeof, noch auto, noch decltype funktionieren. Andere Beispiele habe ich ja oben schon erwähnt.

Ich sehe keinen Vorteil in deinem Vorschlag. Was gefällt dir an den Konvertierungsoperatoren nicht? Damit kannst du genau das erwünschte Verhalten erreichen, ohne Grundkonzepte der Sprache zu verbiegen. :)

drakon

Supermoderator

Beiträge: 6 513

Wohnort: Schweiz

Beruf: Entrepreneur

  • Private Nachricht senden

25

24.10.2009, 18:46

Ja. Mit den neuen Konzepten lässt besonders nicht mehr vereinigen. (Das Gegenargumten zu dem Punkt wegen dem alleine stehen lasse ich jetzt mal aus, ich hasse mich selbst überhaupt für den Gedanken. :p siehe Eiffels command / query )

Vorteile sehe ich halt wenn anhand des Rückgabetypen andere Funktionen aufrufen muss. (ich hatte IIRC wirklich mal einen Fall, wo ich mir das gewünscht hätte, weiss aber die Umstände nicht mehr).

26

24.10.2009, 19:46

Okay. Kann ja durchaus sein, dass man je nach Rückgabetyp eine andere Funktion aufrufen möchte. In solchen Fällen habe ich wahrscheinlich eine Entscheidung zur Laufzeit oder eine andere Technik, die das realisiert, gewählt...

Wenn dir das Beispiel wieder einmal einfallen sollte, kannst du es ja hier posten, wäre sicher noch interessant. ;)

Sizzla

Frischling

  • »Sizzla« ist der Autor dieses Themas

Beiträge: 72

Wohnort: Klagenfurt

  • Private Nachricht senden

27

24.10.2009, 23:08

Na da hat mein Thread aber mal was ins Rollen gebracht :D
Künstliche Intelligenz ist leichter zu ertragen als natürliche Dummheit !
--------------------------
http://www.kasser-manuel.com

Faule Socke

Community-Fossil

Beiträge: 1 915

Wohnort: Schreibtischstuhl

  • Private Nachricht senden

28

29.10.2009, 22:09

Das Problem, warum der Rückgabetyp nicht zur Signatur gehört ist denke ich ganz einfach, denn folgender Aufruf wäre dann nicht mehr möglich:

C-/C++-Quelltext

1
2
3
4
5
int foo() {/* [...] */}
float foo() {/* [...] */}

// [...]

foo();


Ob der Aufruf sinn macht, hängt natürlich vom Code ab. Wenn der Rückgabetyp nicht interessiert, kann die aufzurufende Funktion nicht mehr eindeutig bestimmt werden. Und das würde sehr sehr sehr sehr sehr sehr [...] sehr sehr sehr viel C++ Code inkompatibel machen -> das "feature" ist zu teuer. Von den ganzen anderen Problemen die oben angesprochen wurden, mal ganz zu schweigen. Die Leute haben sich schon was dabei gedacht, als sie das weggelassen haben, das war nicht blos faulheit ;-)

Socke

Werbeanzeige