[C++] parent method aanroepen vanuit child

[dirkpostma]

Ik wil een class afleiden van een andere, bv. ik leidt class B af van A. Vervolgens wil ik een methode uit A herdefinieren in B, bv. method1. Kan ik in B::method1 dan een call doen naar A::method1?

NB: ik weet wel een workaround, nl. de method in B een andere naamgeven, maar ik wil juist dezelfde methode naam hanteren.

Voorbeeld:

code:

class A
{
private:
 char* woordje = "hallo";

public:
  void printString(void);
}

void A::method1(void)
{
  cout << woordje;
}


class B : public A
{
public:
  void printString(void);
}

void B::printString(void)
{
  super->printString(); // print "hallo"
  cout << " wereld!";
}

Probleem is dus dat het met "super" niet werkt...

[dirkpostma]

tikfoutje (ik kan niet meer wijzigen ):

code:

A::method1

moet zijn:

code:

A::printString

[Verwijderd]

code:

void B::printString(void)
{
  A::printString();  // Zo simpel is het
  cout << " wereld";
}

[curry684]

Ennuh ik zou die method virtual maken, anders werkt de volgende code niet correct:

code:

A* Object = new B;
Object->printString();

[Verwijderd]

Op woensdag 19 september 2001 18:21 schreef curry684 het volgende:
Ennuh ik zou die method virtual maken, anders werkt de volgende code niet correct:

code:

A* Object = new B;
Object->printString();

Die code is wel degelijk correct. In sommige gevallen wil je misschien helemaal geen polymorphic behaviour..

[curry684]

Op woensdag 19 september 2001 19:06 schreef Sneech het volgende:
Die code is wel degelijk correct. In sommige gevallen wil je misschien helemaal geen polymorphic behaviour..

In 'hello world' wel als je niet 'hello' wil zien


(jaja met 'correct' bedoelde ik 'wat Dirk verwacht', sorry )

[curry684]

Ik moest even zoeken, maar jawel: ook in deze thread is iets te benchmarken!!! En wel het verschil tussen virtual functions en regular functions:

code:

// ------------------------------------------------------------------------
// Test cases
// ------------------------------------------------------------------------

class AReg
{
public:
  void Print()      { }
};

class BReg : public AReg
{
public:
  void Print()      { AReg::Print(); }
};

class AVir
{
public:
  virtual void Print()  { }
};

class BVir : public AVir
{
public:
  virtual void Print()  { AVir::Print(); }
};

// ------------------------------------------------------------------------
// Main program
// ------------------------------------------------------------------------
        
int main()
{
// Define benchmark code
MPrepareBenchmark(10000000);

MBeginBenchmark(Regular);
  BReg  MyClass;
  MyClass.Print();
MEndBenchmark;

MBeginBenchmark(Virtual);
  BVir  MyClass;
  MyClass.Print();
MEndBenchmark;

// Wait for keypress before exit
printf("\nPress any key to exit...");
while(!getch());
return 0;
}

// ------------------------------------------------------------------------

De resultaten:
Method 'Regular' took 3404 milliseconds
Method 'Virtual' took 6819 milliseconds

(ook deze thread weer gered voordat ie een benchmarkloze dood zou sterven... )

[.oisyn]

tsss dat doe je ook alleen maar om mij voor te zijn

[curry684]

Op donderdag 20 september 2001 01:48 schreef OiSyN het volgende:
tsss dat doe je ook alleen maar om mij voor te zijn

rawr

[Korben]

Tss ik zou zeggen begin een apart forum... Het Curry/OiSyN ultieme benchmarking forum...

[curry684]

Op donderdag 20 september 2001 15:48 schreef Xenophage het volgende:
Tss ik zou zeggen begin een apart forum... Het Curry/OiSyN ultieme benchmarking forum...

Tis best educatief, ik had persoonlijk geen factor 2 verschil verwacht in dit geval. Illustreert duidelijk voor die jongen dat virtual methods soms nodig zijn, en dat ze een blok aan je performancebeen zijn als je ze overbodig gebruikt.

[Verwijderd]

Op donderdag 20 september 2001 01:45 schreef curry684 het volgende:
De resultaten:
Method 'Regular' took 3404 milliseconds
Method 'Virtual' took 6819 milliseconds

Wat een rare uitkomsten. Die virtuals zijn inlined, en het is in deze code niet nodig om virtual calls op te zetten, er is geen call via een baseclass pointer of reference, dus het is eenduidig welke methodes bedoeld zijn. De compiler zou de virtuals dus moeten inlinen, en er zouden geen verschillen in de uitkomsten moeten zitten. Of dit is gecompiled zonder optimizing, of de compiler stinkt

[curry684]

Op donderdag 20 september 2001 20:02 schreef mietje het volgende:
Wat een rare uitkomsten. Die virtuals zijn inlined, en het is in deze code niet nodig om virtual calls op te zetten, er is geen call via een baseclass pointer of reference, dus het is eenduidig welke methodes bedoeld zijn. De compiler zou de virtuals dus moeten inlinen, en er zouden geen verschillen in de uitkomsten moeten zitten. Of dit is gecompiled zonder optimizing, of de compiler stinkt

Hoe wil je een virtual inlinen, daar in principe pas op runtime duidelijk is welke versie van de method je wilt aanroepen? Ennuh ja het was debugbuild, anders was ik niet weggekomen met lege implementaties ja

(btw. VC++ stinkt ook )

[whoami]

Op donderdag 20 september 2001 20:37 schreef curry684 het volgende:

[..]


(btw. VC++ stinkt ook )

Waarom?

[curry684]

Op donderdag 20 september 2001 20:42 schreef whoami het volgende:
Waarom?

Hoho, voordat er hier ook een troll-war ontstaat: er stond een luid lachende smiley achter!!!

VC++ is bij lange na niet perfect, maar voldoet ruimschoots voor veel dingen. Borland is net zo verre van perfect, en voldoet ruimschoots voor veel (heel andere) dingen.

[whoami]

Ik wil hier vooral geen troll-war starten hoor. Ik zelf gebruik vooral Borland C++ Builder, omdat ik vooral database applicaties maak. Visual C++ heb ik eigenlijk nog nooit nodig gehad, 'k heb er wel al wat tijd ingestoken in het leren ervan, maar als je het nooit nodig hebt, waarom zou je het dan gaan leren. (Heb er trouwens een stuk of 4 boeken van liggen). Zet maar eens een mooie databank app in elkaar met VC++!
De MFC is gewoon veel moeilijker onder te knie te krijgen dan de VCL. Voordeel van VC++ is wel dat het puurdere C++ is dan hetgeen je in BCB gebruikt. (De VCL is in object pascal geschreven.).

[curry684]

Ah op zo'n manier

Kort samengevat mijn mening over de 2 (werk dagelijks met allebei):
- BCB pak je voor GUI's.
- VC++ pak je voor low(er)level en consolewerk.

Zowel thuis als op m'n werk schrijf ik core-libraries in VC++ die ik vervolgens in Borland in een GUI binnenlink.

[Verwijderd]

Op donderdag 20 september 2001 20:58 schreef curry684 het volgende:
Ah op zo'n manier

Kort samengevat mijn mening over de 2 (werk dagelijks met allebei):
- BCB pak je voor GUI's.
- VC++ pak je voor low(er)level en consolewerk.

Zowel thuis als op m'n werk schrijf ik core-libraries in VC++ die ik vervolgens in Borland in een GUI binnenlink.

FF toevoeging:

- VC++ pak je ook voor games (3d dan, dat vind ik dan makkelijker)

[curry684]

Op donderdag 20 september 2001 21:04 schreef mgfun het volgende:
- VC++ pak je ook voor games (3d dan, dat vind ik dan makkelijker)

Games zijn een heel eind lowerlevel dan GUI's, dus had ik al gezegd

[Verwijderd]

Op donderdag 20 september 2001 20:37 schreef curry684 het volgende:
Hoe wil je een virtual inlinen, daar in principe pas op runtime duidelijk is welke versie van de method je wilt aanroepen? Ennuh ja het was debugbuild, anders was ik niet weggekomen met lege implementaties ja

Maar de compiler weet wel welke versie hij gaat gebruiken Je doet je method-calls niet via een baseclass-pointer of -reference, dus weet de compiler al in compile-time welke versie van de method gebruikt moet worden. Dan kan die virtual dus ingelined worden, en een goede compiler doet dat ook.

http://www.faqs.org/faqs/C++-faq/part8/ :

[28.6] Are "inline virtual" member functions ever actually "inlined"?
Occasionally...
When the object is referenced via a pointer or a reference, a call to a
virtual[20] function cannot be inlined, since the call must be resolved
dynamically. Reason: the compiler can't know which actual code to call until
run-time (i.e., dynamically), since the code may be from a derived class that
was created after the caller was compiled.
Therefore the only time an inline virtual call can be inlined is when the
compiler knows the "exact class" of the object which is the target of the
virtual function call. This can happen only when the compiler has an actual
object rather than a pointer or reference to an object. I.e., either with a
local object, a global/static object, or a fully contained object inside a
composite.
Note that the difference between inlining and non-inlining is normally much
more significant than the difference between a regular function call and a
virtual function call. For example, the difference between a regular function
call and a virtual function call is often just two extra memory references, but
the difference between an inline function and a non-inline function can be as
much as an order of magnitude (for zillions of calls to insignificant member
functions, loss of inlining virtual functions can result in 25X speed
degradation! [Doug Lea, "Customization in C++," proc Usenix C++ 1990]).

Amen

[Verwijderd]

Op donderdag 20 september 2001 21:06 schreef curry684 het volgende:

[..]

Games zijn een heel eind lowerlevel dan GUI's, dus had ik al gezegd

Als die pokke server had gewerkt dan had je me edit kunnen zien, magoed Topics moest weer eens niet werken

edit:
Of is dit low level werk ?

[curry684]

Op donderdag 20 september 2001 21:08 schreef mietje het volgende:
Maar de compiler weet wel welke versie hij gaat gebruiken Je doet je method-calls niet via een baseclass-pointer of -reference, dus weet de compiler al in compile-time welke versie van de method gebruikt moet worden. Dan kan die virtual dus ingelined worden, en een goede compiler doet dat ook.

Oeps was even vergeten dat ik een stack-implementatie had gebenched ipv een base-pointer zoals ik een stuk hierboven voordeed

Ik denk dat de overhead puur in het construeren van de vtable voor de lege class zit.