geen function overloading ??

[Verwijderd]

ik was ff wat verschillende dingentjes aan t proberen in C++, toen ik t volgende probeerde:

code:

class __main {
    public:
        __main() {;}
        __main(int x) {val=x;}
    
        int sval() {return val;}
        void sval(int x) {val=x;}
    private:
        int     val;
};

bij de constructor ( __main ) snap ik dat ie daar geen function overloading geeft, maar ik had verwacht dat mijn compiler zou gaan schreeuwen op de function overloading bij int sval() en void sval(int x).

kan iemand mij uitleggen waarom dit niet zo is

[Verwijderd]

Functies hebben een verschillende handtekenig dus de compiler heeft niet zo bar veel moeite ze uit erlkaar te houden dus klaagt ook niet.

[Gerco]

Ik snap het probleem niet? Overloading kan en mag toch gewoon?

Ook met die constructor moet dat geen probleem zijn, doet 'ie het nou WEL of niet?

[mbravenboer]

Functie overloading is juist een feature van een taal (een primitieve vorm van polymorphisme).

[Verwijderd]

hmmzz, jah ik kan me van 'vroeger' herrinneren dat me compiler altijd zwaar begon te gillen als ik dit soort geintjes uithaalde. maar ik ben er wel blij om...

x = sval();
sval(x);
yeah baby

Ook met die constructor moet dat geen probleem zijn, doet 'ie het nou WEL of niet?

hij doettet wel, maar ik was ff verbaasd, dat me compiler dit nu wel slikt, en vroeger niet... nja,

[Gerco]

Op donderdag 04 oktober 2001 07:57 schreef Reflex het volgende:
hij doettet wel, maar ik was ff verbaasd, dat me compiler dit nu wel slikt, en vroeger niet... nja,

Nou ja, maak een leuk dansje ofzo, hij doet het en da's ook de bedoeling. Is gewoon een feature van de taal. Ik geloof dat het in C niet kon, maar daar ban ik niet zeker van, in C++ kan het iig wel.

[stylee]

Nee C kent idd geen contructors en al helemaal geen function overloading

Ik ben hier niet zeker van maar volgens mij

code:

int sval() {return val;}
void sval(int x) {val=x;}

is dit geen functon overloading meer, maar 2 compleet verschillende functies? Kweenie hoe het zit met C++ maar had het hier een keertje over met mijn Java leraar en die beweerde dat 2 functies met verschillende return-types niet meer vallen onder het function-overloading motto. Is dit waar? Ik vind het iig niet zo erg logisch klinken... maar nogmaals we hadden het over Java, niet C++

ot
De functies die niet gaan lopen sleutelen aan je private variabelen hoor je eigenlijk const te declareren: (int sval const { return val; }

[Verwijderd]

Op donderdag 04 oktober 2001 09:14 schreef stylee het volgende:
Nee C kent idd geen contructors en al helemaal geen function overloading

Ik ben hier niet zeker van maar volgens mij

code:

int sval() {return val;}
void sval(int x) {val=x;}

is dit geen functon overloading meer, maar 2 compleet verschillende functies? Kweenie hoe het zit met C++ maar had het hier een keertje over met mijn Java leraar en die beweerde dat 2 functies met verschillende return-types niet meer vallen onder het function-overloading motto. Is dit waar? Ik vind het iig niet zo erg logisch klinken... maar nogmaals we hadden het over Java, niet C++

ot
De functies die niet gaan lopen sleutelen aan je private variabelen hoor je eigenlijk const te declareren: (int sval const { return val; }

ik kom vanuit C aanzetten, allemaal zwaar wennen dat OO C vondt t een function overload, of illegal redefinition, als er 2 functies, met dezelfde naam maar verschillende args/return types waren.

[Verwijderd]

Op donderdag 04 oktober 2001 09:14 schreef stylee het volgende:
Kweenie hoe het zit met C++ maar had het hier een keertje over met mijn Java leraar en die beweerde dat 2 functies met verschillende return-types niet meer vallen onder het function-overloading motto. Is dit waar?

Het return type zit niet in de functie signature, dus als je twee gelijknamige functies in een scope hebt met verschillende parameters is dat gewoon overloading ook al zijn de return types verschillend (dacht ik).

[Gerco]

Op donderdag 04 oktober 2001 09:24 schreef Sneech het volgende:
Het return type zit niet in de functie signature

code:

// Functie prototype
void blaat(int foo, double bar, char* bas);

Het lijkt me dat die 'void' toch echt wel bij de signature hoort hoor.

[Verwijderd]

Op donderdag 04 oktober 2001 10:29 schreef Gerco het volgende:

[..]

code:

// Functie prototype
void blaat(int foo, double bar, char* bas);

Het lijkt me dat die 'void' toch echt wel bij de signature hoort hoor.

Nee, functie signatures worden onder andere gebruikt om overloaded functies te kunnen onderscheiden tijdens het compileren van een functie aanroep in een statement.
Hier een voorbeeld van een situatie waaruit blijkt dat het return type niet bij de functie signature hoort:

code:

char f () { return 'a'; }
int f () { return 6; }

Deze code compileert niet, omdat de twee functies een gelijke functie signature hebben (aangezien het return type er dus niet in is opgenomen); de compiler kan deze twee functies niet onderscheiden in een aanroep.

[Gerco]

de compiler kan deze twee functies niet onderscheiden in een aanroep.

Zo had ik er idd nog niet over nagedacht, maar dat neemt niet weg dat het return type volgens mij nog steeds bij de signature hoort.

Het is dan wel niet mogelijk om functies met een verschillend returntype te overloaden, maar het returntype is iets wat toch echt bij de definitie van een functie hoort.

[Verwijderd]

In mijn redenering ging ik er vanuit dat functie signatures alleen gebruikt worden om te bepalen welke functie wordt aangeroepen in geval van overloading, maar als die signatures ook nog ergens anders voor gebruikt worden zou het uiteraard goed kunnen dat het return type er ook in zit.

Overigens is het denk ik niet echt mogelijk precies te bepalen wat een functie signature is, omdat de standaard (of in ieder geval de draft) het er nauwelijks over heeft, en het vooral intern in de compiler verwerkt zit.

.edit-> Ik heb nog even in de draft gekeken, waar ik het volgende vond:

An ambiguity exists if the best match finds two functions with the same signature.

Uit het feit dat de twee functies die ik enkele posts geleden als voorbeeld gaf ambigu waren, kan je dus concluderen dat het return type niet in de functie signature zit.

[drm]

Op donderdag 04 oktober 2001 11:12 schreef Sneech het volgende:
In mijn redenering ging ik er vanuit dat functie signatures alleen gebruikt worden om te bepalen welke functie wordt aangeroepen in geval van overloading, maar als die signatures ook nog ergens anders voor gebruikt worden zou het uiteraard goed kunnen dat het return type er ook in zit.

Overigens is het denk ik niet echt mogelijk precies te bepalen wat een functie signature is, omdat de standaard (of in ieder geval de draft) het er nauwelijks over heeft, en het vooral intern in de compiler verwerkt zit.

.edit-> Ik heb nog even in de draft gekeken, waar ik het volgende vond:
[..]

Uit het feit dat de twee functies die ik enkele posts geleden als voorbeeld gaf ambigu waren, kan je dus concluderen dat het return type niet in de functie signature zit.

Amen!

* drm vraagt zich af, waarom je 2 functies binnen 1 scope met verschillende return types wil hebben.

Is het niet veel logischer om de functie ook een andere naam te geven, zodra hij een andere return type (c.q. functie) krijgt

[Verwijderd]

Op donderdag 04 oktober 2001 11:31 schreef drm het volgende:
* drm vraagt zich af, waarom je 2 functies binnen 1 scope met verschillende return types wil hebben.

Ik neem aan dat je gelijknamige functies bedoelt .

Ziehier een stukje <list>:

code:

iterator begin () { bla; }
const_iterator begin () const { bla; }

Note: deze twee functies verschillen dus niet alleen in return type, maar ook in const-ness, en dat zit dus kennelijk ook in een functie signature.

[drm]

Op donderdag 04 oktober 2001 11:43 schreef Sneech het volgende:
Ik neem aan dat je gelijknamige functies bedoelt .

typo

Ziehier een stukje <list>:

code:

iterator begin () { bla; }
const_iterator begin () const { bla; }

Note: deze twee functies verschillen dus niet alleen in return type, maar ook in const-ness, en dat zit dus kennelijk ook in een functie signature.

zit wat in...