Das folgende ist ein Code-Konstrukt, das irgendwie immer wieder auftrat und mir auch immer wieder ein Dorn im Augen war - es geht um das Abspeichern und Lesen von "polymorphen" Objekten, bei denen die Basisklasse echte Funktionalität bietet, und nicht einfach nur alles "runterreicht". Das "Name"-Attribut habe ich jetzt einfach mal als Repräsentant für soetwas hergenommen.

class Base {
public:
	Base(string name) : name_(move(name)) {}

	void ChangeName(string name) { name_ = move(name); }
	string GetName() { return name_; }

public:
	// Some ist eine Methode, die alle Base-Objekte haben sollen.
	virtual void Some() = 0;

	virtual void Write(stream s) {
		s << name_;
	}

	virtual ~Base() {}
private:
	string name_;
};

class Derived : 
	public Base
{
public:
	Derived(string name) : Base(name) {}

	static shared_ptr<Derived> Read(stream& s)
	{
		scoped_read_guard guard(s);
		string name;
		s >> name;
		return make_shared<Derived>(std::move(name));
		// Die abgelittene Klasse muss also der Basisklasse ihre Parameter
		// auslesen und sie immer durch ihren eigenen Konstruktor schleifen
		// und einen guard um das gesamte Objekt legen
	}

	void Write(stream s) override
	{
		scoped_write_guard guard(s);
		Base::Write(s);  // Ich muss dafür sorgen, dass Base geschrieben wird
		// Zudem kann Base im Stream keine "Hülle" um das gesamte Objekt legen
		// (Ich verwende gerne Scoped-Reader und -Writer, die das Dateiformat mit
		// Navigations und Redundanz-Daten anreichern.
		s << "blah";
	}

	void Some() override {}

	// ... und mehr Methoden
};

shared_ptr<Base> ReadObject1(stream& s)
{
	// Irgendwie wird der Typ herausgefunden
	return Derived::Read(s);
}

void WriteObject1(stream& s, Base& b)
{
	b.Write(s);
}

Das Problem habe ich in den Kommentar geschrieben, bislang ist mir dafür irgendwie noch keine gute Lösung eingefallen.
Nun kommt der Ansatz der Typ - Ausradierung:

class Concrete2;

class Base2 {
public:
	Base2(string name) : name_(name) {}

	void Some() {
		content_->Some();
	}

	static shared_ptr<Base2> Read(stream& s) {
		scoped_read_guard guard(s);
		string name;
		s >> name;
		auto result = make_shared<Base2>(name);
		// Irgendwie wird der Typ herausgefunden und das Äquivalent zu dieser
		// Anweisung generiert.
		result->Assign(Concrete2::Read(s));
		return result;
	}

	void Write(stream& s) {
		scoped_write_guard guard(s);
		s << name_;
		// Irgendwie wird der Typ herausgefunden
		content_->Write(s);
	}

private:
	Base2() {}

	// "Type-Erasure"-Boilerplate
	template< typename T > Assign(T&& obj) {
		content_.reset(new concrete_wrapper<T>(move(obj)));
	}

	struct wrapper_base {
		virtual void Some() = 0;
		virtual void Write(stream& s) = 0;
	};

	template< typename Content >
	struct concrete_wrapper : public wrapper_base
	{
		template< typename... Args >
		concrete_wrapper(Args&&... args) : content_(forward<Args>(args)...) {}

		void Some() override { content_.Some(); }
		void Write(stream& s) override { content_.Write(s); }
		Content content_;
	};

private:
	unique_ptr<wrapper_base> content_;
	string name_;
};

class Concrete2 {
public:
	void Some() {}
	void Write(stream& s) {}
	static Concrete2 Read(stream& s) {}
};

Was ist jetzt das Problem? Man kommt an keine Referenz von einem Typ, der sowohl das Interface von Base als auch das von Concrete2 anbietet. Das heißt, Client-Code, der sich auf spezifische Typen bezieht, muss mehr oder weniger zwei Referenzen mitschleppen, eine auf das Base2-Objekt und eine auf das typisierte Concrete2. Also nächster Anlauf:

class Concrete3;

class Base3 {
public:
	Base3(string name) : name_(name) {}

	void Some() {
		content_->Some();
	}

	static shared_ptr<Base3> Read(stream& s) {
		scoped_read_guard guard(s);
		string name;
		s >> name;
		auto result = make_shared<Base3>(name);
		// Irgendwie wird der Typ herausgefunden und das Äquivalent zu dieser
		// Anweisung generiert.
		result->Assign(Concrete2::Read(s));
		return result;
	}

	void Write(stream& s) {
		scoped_write_guard guard(s);
		s << name_;
		// Irgendwie wird der Typ herausgefunden
		content_->Write(s);
	}

private:
	Base3() {}

	// "Type-Erasure"-Boilerplate
	template< typename T > Assign(T&& obj) {
		content_.reset(new concrete<T>(this, std::move(obj)));
	}

	struct concrete_base {
		virtual void Some() = 0;
		virtual void Write(stream& s) = 0;
	};

	template< typename Content >
	struct concrete : public Content, public concrete_base
	{
		template< typename... Args >
		concrete(Base3* this_, Args&&... args) : Content(std::forward<Args>(args)...), this__(this_) {}

		void Some() override { Content::Some(); }
		void Write(stream& s) override { Content::Write(s); }

		void GetName() { return this__->GetName(); }
		void SetName(string s) { this__->SetName(); }

	private:
		Base3* this__;
	};

private:
	unique_ptr<concrete_base> content_;
	string name_;
};

class Concrete3 {
public:
	void Some() {}
	void Write(stream& s) {}
	static Concrete3 Read(stream& s) {}
};

// Client-Code:
Base3::concrete<Concrete3>& base.get_typed<Concrete3>(); /* oder besser auto, aber hier wollte ich den Typ mal zeigen */

Jetzt kann jeder Code, der Concrete3 als erweiterte Base3 behandeln will, eben eine Referenz auf Base3::concrete<Concrete3> erhalten und bekommt beide Schnittstellen in einem Objekt.
Allerdings ist das Konstrukt schon sagen wir mal für das Problem extremal-komplex. Daher habe ich den Eindruck, mich megamäßig verrannt zu haben. Aus meinen Überlegungen über die Typausradierung und dem was ich hier versucht habe schließe ich folgendes: Des öfteren möchte ich zwar ableiten, aber "umgekehrt". Die abgeleitet Klasse soll nicht die Basisklasse "boxen", sondern andersherum (Und trotzdem sollen beide am Ende eine Einheit bilden). Und nichts anderes ist doch eigentlich Type-Erasure, das Umkehren der Besitzverhältnisse beim "Ableiten", beziehungsweise beim Ins-Verhältnis-Setzen von Typen.

Ich schätze, jemand von euch wird einige gute Vorschläge haben, die das Ausgangsproblem "richtig" angehen oder vielleicht auch gedankliche Fehler auf meinem Lösungsweg finden. Es würde mich sehr, freuen, wenn ihr sie hier kundtun könntet!

Bis denne!
Ratzefummel

Das Format ist dann ungefähr

Ork 
{
    x=10
    y=11
    z=2
    name=Hubert
}

Ghoul
{
    x=101
    y=34
    z=35
    name=Paul
    zauber=3,4,7,8,9,10,17
}

oder so. Die Klassen dazu wären

class ActiveObject{
    void doSomething()=0;
};
class Mob{
    Position pos;
};
class Monster:public Mob{
    string name;
};
class Ork:public Monster{
};
class Ghoul:public Monster{
    vector<int> zauber;
};

Implementiert ungefähr so, die Attributenamen zu schreiben und mit Prüfung wegzulesen, habe ich mal weggelassen.

class Base {
public:
	Base(string name) : name_(move(name)) {}
    Base(istream& in){
        in>>name_;
    }
	void ChangeName(string name) { name_ = move(name); }
	string GetName() { return name_; }
public:
	// Some ist eine Methode, die alle Base-Objekte haben sollen.
	virtual void Some() = 0;

	virtual void Write(stream& s) {
		s << name_ <<'\n';
	}
	virtual ~Base() {}
private:
	string name_;
};

class Derived : 
	public Base
{
public:
	Derived(string name) : Base(name) {}
    Derived(istream& in) : Base(in) /*,more base classes and members*/{
        //read attributes from derived
    }
	void Write(stream s) override
	{
		Base::Write(s);  // Ich muss dafür sorgen, dass Base geschrieben wird
		// Zudem kann Base im Stream keine "Hülle" um das gesamte Objekt legen
		// (Ich verwende gerne Scoped-Reader und -Writer, die das Dateiformat mit
		// Navigations und Redundanz-Daten anreichern.
		s << "blah";
		//Jo, die Hülle macht aber die Lese-Schreib-Factory drum.
	}

	void Some() override {}

	// ... und mehr Methoden
};

shared_ptr<BaseObject> readOrk(stream& in){
    shared_ptr<BaseObject> p(new Ork(in));
    return p;
}
shared_ptr<Base> ReadObject1(stream& in)
{
	// Irgendwie wird der Typ herausgefunden
	string type;
	in>>type;
	in.checkAndIgnore('{');
	shared_ptr res=readermap(type)(s);
	in.checkAndIgnore('}');
	return res;
}

void WriteObject1(stream& s, Base& b)
{
    s<<b.getClassName()<<'\n';
    s<<'{'<<'\n';
	b.Write(s);
    s<<'}'<<'\n';
    s<<'\n';
}

Das Format war sehr schnell und für mich genau richtig, weil ich in den Daten per Hand rumfuchteln wollte. Und später hätte ich ja nach TextStream und BinaryStream erweitern können. Aber so (mit leichten Speed-Änderungen) war es schon mehr als zehnmal so schnell wie Vorgängerlösung.

Während ich in der Zwischenzeit so darüber nachgedacht habe, kam mir der Gedanke, dass es doch auch irgendwie cool wäre, wenn C++ "reversed virtual"- und "reversed hiding"-Funktionen hätte. Bei denen eben die Version in der Basisklasse die in der abgeleite Klasse überschreibt bzw. verdekt - aber der Kontext da ist, um von dort die abgeleitete Implementierung aufzurufen.

Ratzefummel

class A
{
public:
    void write(std::ostream& s)
    {
        s << 55 << '\n';
        over_write(s);
    }
private:
   virtual void over_write(std::ostream& s)
   {}
};

class B : public A
{
public:
private:
   void over_write(std::ostream& s) final override
   {
        s << 77 << '\n';
   }
};

Ansonsten gäbe es noch die Möglichkeit, dass die Objekte einfach eine std::function next_write im Konstruktor nehmen.

ja - leider habe ich hier durchaus mit Veerbung von mehr als einer Stufe zu tun, daher ist dieser Ansatz auch "unschön".
Ich bin gerade am überlegen, beim Lesen keinen Stream durchzureichen, sondern einen Kontext, der per Type-Erasure (boost::any oder soetwas) Objekte zwischenspeichern kann, die dann in der umgekehrten Reihenfolge wieder zerstört werden. So kann jede Basisklasse etwas um die abgeleitete Klasse drumherumbasteln, bei dem die abgeleitete Klasse nicht zwischenfunken kann. Damit wäre der Konstruktionsfall schon einmal abgehandelt. Das müsste beim Zerstören eigentlich auch funktionieren, solange eben die abgeleitete Klasse daran denkt, die Basisklasse aufzurufen. Ja ich weiß, bei mir hat Type-Erasure gerade Hochkonjunktur
Ich warte aber auf jeden Fall ab, ob volkard noch etwas genauer auf diese Reader-Writer-Factory eingeht, die Chancen stehen immerhin gut, dass das eine total gute Lösung wäre, wenn ich sie nur vor meinen inneren Augen hätte!

Ratzefummel

In Deiner Lösung verschiebst Du jetzt (für mich leider) das Problem, das ich zu lösen gedachte in die externe "Lese-Schreib-Factory". Wie sähe die denn aus?

Die steht fast vollständig schon da.

shared_ptr<BaseObject> readOrk(stream& in){
    shared_ptr<BaseObject> p(new Ork(in));
    return p;
}
//Oder auch als
template<class T> read(istream& in){
    shared_ptr<BaseObject> p(new T(in));
    return p;
}
//oder als 
template<class T>
struct Reader{
    shared_ptr<BaseObject> read(istream& in)...
}
//oder ohne Namen als lamda

//Pro konkreter Klasse muss es eine solche Funktion geben und sie muss 
//in der globalen map registriert werden. 

//Das kann man mit Makros fein erledigen...
#define registerClass(className) registerClassSub(#className,&read<className>)
//oder ähnlich. Dann schreibt man nur noch ans Ende der Derived.cpp
registerClass(Derived);
//und ab jetzt können die globalen Read- und Write-Funktionen damit umgehen. 

shared_ptr<Base> ReadObject1(stream& in)
{
    // Irgendwie wird der Typ herausgefunden
    string type;
    in>>type;
    in.checkAndIgnore('{');
    shared_ptr res=readermap(type)(s);//dafür die globale map
    in.checkAndIgnore('}');
    return res;
}
 
void WriteObject1(stream& s, Base& b)
{
    s<<b.getClassName()<<'\n';
    s<<'{'<<'\n';
    b.Write(s);
    s<<'}'<<'\n';
    s<<'\n';
}

Ich nannte sie nur factory, weil sie bei mir eine eine Klasse war. Und nicht ein paar globale Funktionen wie hier. Der Name erschien mir recht passend.

Während ich in der Zwischenzeit so darüber nachgedacht habe, kam mir der Gedanke, dass es doch auch irgendwie cool wäre, wenn C++ "reversed virtual"- und "reversed hiding"-Funktionen hätte. Bei denen eben die Version in der Basisklasse die in der abgeleite Klasse überschreibt bzw. verdekt - aber der Kontext da ist, um von dort die abgeleitete Implementierung aufzurufen.

Hmm. Ich bin nicht sicher, daß ich verstanden habe, was Du suchst.
Vielleicht sowas?

#include <iostream>
#include <string>
using namespace std;

class ActiveObject{
    public:
    virtual void write(ostream& out)=0;//per write only one virtual call
    template<typename Derived> void doWrite(ostream& out,Derived& derived,char const* className){//dispatcher
        cout<<className<<"{\n";
        derived.writeMembers(out);
        cout<<"}\n\n";
    }
    void writeMembers(ostream& out){
    }
};
class Mob:public ActiveObject{
    int pos;
public:
    Mob(int pos)
    :pos(pos){
    }
    void writeMembers(ostream& out){
        ActiveObject::writeMembers(out);
        out<<"  pos="<<pos<<'\n';
    }
};
class Monster:public Mob{
    string name;
    public:
    Monster(int pos,string name)
    :Mob(pos)
    ,name(name){
    }
    void writeMembers(ostream& out){
        Mob::writeMembers(out);
        out<<"  name="<<name<<'\n';
    }
};
class Ork:public Monster{
    public:
        Ork(int pos,string name)
        :Monster(pos,name){
        }
    void doSomething(){
        cout<<"sing 'I am an Ork an shmash your Head, lalala.'\n";
    }
    void writeMembers(ostream& out){
        Monster::writeMembers(out);
    }
    virtual void write(ostream& out){
        ActiveObject::doWrite(out,*this,"Ork");
    }
};

int main(){
    ActiveObject* o=new Ork(5,"Otto");
    o->write(cout);
}

Ausgabe:

Ork{
  pos=5
  name=Otto
}

Warum nicht so?

class Base {
public:
    Base(string name) : name_(move(name)) {}

    void ChangeName(string name) { name_ = move(name); }
    string GetName() { return name_; }

public:
    virtual void Read(stream s) {// Warum gabs die Methode in der Base nicht?
        s >> name_;
    }

    virtual void Write(stream s) {
        s << name_;
    }

    virtual ~Base() {}
private:
    string name_;
};

class Derived :
    public Base
{
public:
    Derived(string name) : Base(name) {}

    static shared_ptr<Derived> Read(stream& s)
    {
        Base::Read(s);
        //was auch immer hier noch gebraucht wird lesen
    }

    void Write(stream s) override
    {
        Base::Write(s);
        //was auch immer hier noch gebraucht wird schreiben
    }

};

ja also meine globalen Funktionen waren eigentlich statisch im Object1 und auch ich habe so eine "Registry", die mir typ-Namen oder ids typ_info-Objekte übersetzen kann. Das war das was ich in dem einen Kommentar mit "irgendwie" ausdrücken wollte, weil es ja nicht entscheidend für den Ablauf des Lese- oder Schreibvorgangs einer Klassenhierarchie war. Da wär mein Codebeispiel ja noch undurchsichtiger geworden^^.

Zu Deinem Beispiel: ich muss nocheinmal genau darüber nachdenken. Ich hatte jetzt eben die ganze Zeit in eine andere Richtung gedacht und muss nun erstmal wieder umdenken.
Folgendes Datenlayout im Stream würde so ja erstmal kein Problem darstellen:

object head
   object data
   type info
   sub-object head
      sub-object data
   sub-object tail
   final-object head
      final-object data
   final-object tail
object tail

Wobei final-object von sub-object ableitet und final-object der konkrete Typ war, der gespeichert wurde.
Was ich jetzt aber klasse fänd' wäre folgende Struktur:

object head
   object data
   type info
   final-object head
      sub-object head
         sub-object data
      sub-object tail
      final-object data
   final-object tail
object tail

Aber dafür müsste ich wohl irgendwie in der Initialisierer-Liste tricksen, beim Einlesen. Hrmmm. Auf jeden Fall sehe ich gerade, dass all meine initialen Ansätze sowieso nicht dafür getaugt hätten. Und ich habe gelernt, dass Type-Erasure nicht so gut dafür taugt, wenn man damit versucht Klassenhierarchien abzubilden!

Zur anderen Frage:
Was ich meinte war folgendes:

class A {
  reversevirtual void foo() {
      //...
      foo(); // innerhalb der funktion ruft man "nach oben" auf.
      //...      
  }
};

class B : A {
  void foo() underride {}
};

B b;
b.foo(); // ruft A::foo auf und A::foo ruft dann B::foo auf.

War nur so ein fixer Gedanke, das würde aus irgendwelchen Gründen in gewissen Situationen bestimmt überhaupt gar keinen Sinn ergeben.

Ratzefummel

class Derived :
    public Base
{
public:
    Derived(string name) : Base(name) {}

    static shared_ptr<Derived> Read(stream& s)
    {
        Base::Read(s); // Read ist einer echte Methode von Base,
                       // wie kann das hier funktionieren?
    }

    void Write(stream s) override
    {
        Base::Write(s);
        //was auch immer hier noch gebraucht wird schreiben
    }

};

Ich kann gerade nur vermuten, dass Deine Idee darauf beruht, dass man Base "leer" Standard-konstruieren kann, sodass man die Möglichkeit hat, nach der Konstruktion "Read" auszuführen?

Was ich jetzt aber klasse fänd' wäre folgende Struktur:

object head
   object data
   type info
   final-object head
      sub-object head
         sub-object data
      sub-object tail
      final-object data
   final-object tail
object tail

Die Typen verschachtelt zu schreibe und zu lesen ist natürlich auch kein Problem

class Ork{
   inherits Monster{
      inherits Mob{
        inherits ActiveObject{
        }
        has Position pos={
           int x=1
           int y=3
        }//end position
      }//end Mob
      has string name="Otto"
   }//end of Monster
}//end Ork

Aber mein Ansatz kann nur genau in der Kontruktionsreihenfolge streamen und der Klassenname der final-Klasse (Ork) muss am Anfang stehen. Alles außer "Ork", "1", "2" und "Otto" wäre fest und würde nur als Schmuck mit herausgeschrieben werden und beim Lesen ignortiert. Mit der Verschachtelung hatte ich auch angefangen, sie aber dann weitgehend wieder fallenlassen, es war zu umständlich in solchen Dateien per Hand Daten zu ändern. Eine Position schreibt sich evtl gerne als "pos{x=1;y=3}" in eine Zeile und viel Vererbung gibt man einfach auch nicht aus.

War halt für mich angemessen, weil ich mir das Schreibformat frei aussuchen konnte und es vorwiegend um Schreibgeschwindigkeit ging.

Klassen fangen bei mir nach Möglichkeit nie Default-Kunstruktoren, deswegen kann ich schonmal nicht

Ork* o=new Ork;
datei>>*o;
return 0;

machen.