Warnung 4250

Kann ich die Compiler-Warnung C4250 ignorieren?
Sie tritt bei Mehrfachvererbung auf.
Gibt es einen Trick der die Warnung aufhebt?

Danke

Woems

Welcher Compiler?

BasicMan01

Du kannst ja mal versuchen, am Anfang deies Programms dies hier einzufügen:

#pragma warning( disable : 4250)

net 0

sysdata schrieb:

Kann ich die Compiler-Warnung C4250 ignorieren?
Sie tritt bei Mehrfachvererbung auf.
Gibt es einen Trick der die Warnung aufhebt?

sorry für die blöde antwort, aber vielleicht solltest du auf mehrfachvererbung verzichten? es geht immer ohne bzw. mehrfachvererbung kann eine böse fehlerquelle sein.

Michael E.

BasicMan01: Es ist nicht gut, wenn du ne Warnung ignorierst, es sei denn, du weißt ganz genau, was du tust. Da du die fehlermeldung nicht kennst, weißt dus nicht.

sysdata: In der Doku deines Compilers wirst du so etwas finden (nur ein Ausschnitt):

VS 2005 Beta 1 Documentation schrieb:

' class1 ' : inherits ' class2 :: member ' via dominance

Two or more members have the same name. The one in class2 is inherited because it is a base class for the other classes that contained this member.

Because a virtual base class is shared among multiple derived classes, a name in a derived class dominates a name in a base class. For example, given the following class hierarchy,

Compiler Warning (level 2) C4250

'class1' : inherits 'class2::member' via dominance

There were two or more members with the same name. The one in class2 was inherited since it was a base class for the other classes that contained this member.

This warning is for informational purposes only.

Michael E.

net schrieb:

sysdata schrieb:

Kann ich die Compiler-Warnung C4250 ignorieren?
Sie tritt bei Mehrfachvererbung auf.
Gibt es einen Trick der die Warnung aufhebt?

sorry für die blöde antwort, aber vielleicht solltest du auf mehrfachvererbung verzichten? es geht immer ohne bzw. mehrfachvererbung kann eine böse fehlerquelle sein.

Nicht schon wieder. Wir haben doch schon geklärt, dass Mehrfachvererbung manchmal durchaus nützlich sein kann.

Shade Of Mine

net schrieb:

sorry für die blöde antwort, aber vielleicht solltest du auf mehrfachvererbung verzichten? es geht immer ohne bzw. mehrfachvererbung kann eine böse fehlerquelle sein.

Interessant: dann erklär mir mal, wie ich 2 interfaces implementieren soll. Natürlich kann man es jetzt auch ganz ohne interfaces machen, aber wenn wir zB von plugins ausgehen, dann kann man nicht überall Templates verwenden. Und hier sind interfaces sehr nützlich.

Interessanter wäre es zu erfahren was diese Warnung besagt: meistens sollte man Warnungen nämlich nicht ignorieren (obwohl man es manchmal doch machen muss)

net 0

Shade Of Mine schrieb:

Interessant: dann erklär mir mal, wie ich 2 interfaces implementieren soll.

geht das nicht auch so?
EineKlasse ---> ZwischenKlasseMitInterface1 ---> EndgültigeKlasseMitInterface2

Artchi

Mehrfachvererbung ist eine tolle Sache! Und wenn mir C++ dieses als Sprachfeature anbietet, wird das schon seinen Sinn haben.

net's Lösungsansatz halte ich für unglücklich, unschön, unpraktikabel... ach, eigentlich ist der Lösungsansatz ein Blender!

Bjarne Stroustrup hat das in seinem Buch sehr schön erklärt, wie man Mehrfachvererbung mit sogar gleichnamigen Methodennamen (!) lösen kann.

Mehrfachvererbung vermisse ich in Java wie Hölle. Regelmäßig bin ich am fluchen, warum ich keine zur Verfügung habe. Ganz einfach weil ich es sehr oft benötige... jedenfalls verhältnismäßig oft, dafür das man angeblich auch ohne auskommt.

ness

toll:

template<class B>
class interface1
    :public B
{
}

template<class B>
class interface2
    :public B
{
};

template<class interfacelist>
struct interfacehelper
{
    typedef typename interfacelist::Head<typename interfacehelper<typename interfacelist::Tail>::type> type;
};

template<>
struct interfacehelper<Loki::NullType>
{
    typedef Loki::NullType type
};

class ende
    :public typename interfacehelper<TYPELIST_2(interface1,interface2)>::type
{
}

Wenn dir das besser gefällt

net 0

Artchi schrieb:

Mehrfachvererbung vermisse ich in Java wie Hölle.

in java haste doch 'interfaces'. davon kannste mehrere in eine klasse reintun. c++ hat dafür mehrfachvererbung

Artchi

Ja, und die Interfaces haben keine Implemetierung... ganz super! Das ist ja gerade der Witz! Javas Interface sind in meinen Augen nur ne Krücke.

Ich kann ja nicht mal zwei Interface in meine Klasse packen, wenn diese Methodennamen haben, die sich gleichen. Javas Interfaces sind _fast_ nur Schablonen in meinen Augen, um mich daran zu erinnern, was ich bitte implementieren soll. Java kommt aber mit einem blauen Auge davon, das zur Laufzeit wenigstens noch die Typinfos vorhanden sind und ich casten muß.

In C++ kann ich das machen:

class cowboy {
public:
    draw() { ... }
};

class sprite {
    draw() { ... }
};

class my_player : public cowboy : public sprite {
};

In Java würde das im Chaos enden. Selbst wenn cowboy und sprite Interfaces wären, würde der Compiler meckern. Und selbst wenn die beidem Methnoden unterschiedliche Namen hätten, müsste ich die auch noch selber implementieren.

Gemerkt, das ich keinen einzigen positiven Punkt finden konnte? Wogegen C++ mir alle Freiheiten lässt?

ROFLMAO

net 0

Artchi schrieb:

In C++ kann ich das machen:

class cowboy {
public:
    draw() { ... }
};

class sprite {
    draw() { ... }
};

class my_player : public cowboy : public sprite {
};

aber dann nicht das:

my_player mp;
mp.draw();     // error - welches draw() :confused:

sowas kriegt, glaub ich, python auf die reihe. c++ aber nicht

audacia

net schrieb:

aber dann nicht das:

my_player mp;
mp.draw();     // error - welches draw() :confused:

Das wäre ja auch herzlich schwachsinnig, denn wovon hinge dann ab, welches draw aufgerufen wird?

Moritz

Artchi

Eben, für C++ kein Problem:

class my_player : public cowboy : public sprite {
public:
    void draw() {
       cowboy::draw();
       sprite::draw();
};

net 0

audacia schrieb:

net schrieb:
aber dann nicht das:
my_player mp;
mp.draw();     // error - welches draw() :confused:
Das wäre ja auch herzlich schwachsinnig, denn wovon hinge dann ab, welches draw aufgerufen wird?

ok, dann mit nur einem draw

class base
{
public:
    void draw() {}

};

class cowboy : public base 
{
};

class pferd : public base 
{
};

class my_player : public cowboy, pferd 
{
};

...
    my_player mp;
    mp.draw();    // geht auch nicht  :confused:  :confused: 
...

vor allem die fehlermeldung ist witzig

main.cpp:39: error: request for member `draw' is ambiguous
main.cpp:19: error: candidates are: void base::draw()
main.cpp:19: error: void base::draw()

audacia

net schrieb:

ok, dann mit nur einem draw

...
    my_player mp;
    mp.draw();    // geht auch nicht  :confused:  :confused: 
...

Dazu gibts virtuelle Vererbung. Z.B. so:
[cpp]
class base
{
public:
void draw() {}

};

class cowboy : virtual public base
{
};

class pferd : virtual public base
{
};

class my_player : public cowboy, pferd
{
};

...
my_player mp;
mp.draw(); // und schon geht es
...
[/cpp]

Moritz

net 0

audacia schrieb:

Dazu gibts virtuelle Vererbung.

das ist cool

Slin

net schrieb:

aber dann nicht das:

my_player mp;
mp.draw();     // error - welches draw() :confused:

Es gibt aber ne Möglichkeit mit der man spezifizeiren kann, welches der beiden draws aufgerufen werden muss. Ich glaubd as ging auch irgendwie mit virtuel, aber ohne den Schritt über die zwischenklassen zu machen. Das ist auch im Standard festgelegt. Wo im übrigen auch stehen müsste, dass solange keine zyklischen Abhängigkeiten vorkommen bei der Mehrfachvererbung keine Probleme und schon gar kein undefiniertes Verhalten auftreten.
Alles ne Frage der sorgfalt.