class object_t {
public:
	template< typename T >
	object_t(T x) : self_(std::make_unique < model < T >> (std::move(x)))
	{}

	void draw(std::ostream& out, size_t position) const
	{
		self_->draw_(out, position);
	}

	object_t(object_t && other)
		: self_(std::move(other.self_))
	{}

private:
	object_t(const object_t&);
	void operator=(const object_t&);

	struct concept_t {
		virtual ~concept_t()
		{}

		virtual void draw_(std::ostream&, size_t) const = 0;
	};

	template< typename T >
	struct model : concept_t {
		model(T x) : data_(std::move(x) )
		{}

		void draw_(std::ostream& out, size_t position) const
		{
			data_.draw(out, position);
		}

		T data_;
	};

	std::unique_ptr< const concept_t > self_;
};

class class1 {
public:
	void draw(std::ostream& out, size_t position) const 
	{
		out << "class1 :: draw\n";
	}
};

class class2 {
public:
	void draw(std::ostream& out, size_t position) const
	{
		out << "class2 :: draw\n";
	}
};

int main(int argc, char* argv[])
{
	std::vector< object_t > objects;

	objects.emplace_back(class1());
	objects.emplace_back(class2());

	for (const auto& object : objects) object.draw(std::cout, 0);

	return 0;
}

Und ich so, wtf? Das ist doch irgendwie ein Pimpl zusammengeworfen mit einem Handle zu einem konstanten Objekt = Supertoll?
Und dann redet er davon, dass es keine Einschränkung wäre, dass Models Immutable wäre und von COW - Hauptsache ist, das eine Objekt, das irgendjemand referenziert, wird nicht verändert.
Mal davon abgesehen, dass es wohl zu ekligsten Compilerfehlern führt, wenn das gegebene Objekt nicht die geforderte Schnittstelle erfüllt - wie kann das überhaupt praktikabel sein? Ich meine, das Model ist doch in den meisten Programmen dazu da, vom Programm selber oder dem Benutzer verändert zu werden. Wie kann man dann als Allheilmittel sagen: Da machen wir das Model konstant, dann haben wir auch keine Multithreading-Probleme?

Hat da jemand mehr Erfahrung und kann das in das rechte Licht rücken?

Das mit const/immutable und COW verstehe ich nicht ganz, das const kann da genasogut entfernt werden. Gleich mit multithreading.

Vielleicht meinte er const=threadsafe, aber das lässt sich nicht so recht in Zusammenhang mit diesem Code bringen. Ok mal geraten:

objects[0] = class1()

ist fast(tm) threadsafe. Um ganz threadsafe zu sein müsste unique_ptr mit einem atomic<model_t*> implementiert sein. Deshalb wahrscheinlich COW. Man macht alles const=threadsafe. Um zu verändert kopiert man das Zeugs und steckt das veränderte dann wieder rein. Aber deine Beschreibung, kp.

<OT>
Die Strousttrup-Vorträge hauen mich irgendwie auch nicht mehr vom Hocker. Hatte gestern da mal reingezappt und fragte mich, wie sinnig Konzepte (concepts) sind, die nur für genau eine Funktion aus <algorithm> gemacht wurden: Sortable, Mergable. Und die Verlagerung der Komplexität der Requirments aus std::merge nach Mergable war jetzt eine Leistung? "Guckt mal, jetzt steht da nur noch requires Mergable<...>()". Toll, dafür hast du jetzt ein dickes unnützes Mergable-Konzept.
</OT>

und fragte mich, wie sinnig Konzepte (concepts) sind, die nur für genau eine Funktion aus <algorithm> gemacht wurden

Genau so sinnig wie Funktionen die nur ein mal aufgerufen werden.

Waehrend bei einer Funktion die Implementierung von aussen betrachtet voellig egal ist, muss man bei einem Concept wissen, was die Anforderungen an den Typ sind. Letzten endes bringt das also rein gar nichts, meiner Meinung nach.

Das Argument verstehe ich nicht. Ein Concept erfordert eine bestimmte Schnittstelle, keine bestimmte Implementierung. Du hast bei der Benutzung des Konzepts ebenso eine Abstraktion wie beim Aufruf einer Funktion.

Ob die einzelnen Konzepte wirklich einen Mehrwert bringen, ist dann eine andere Frage.

Ich finde den PIMPL-Handle-Trick (Oder ihr nennt es Type-Erasure) eigentlich ganz nett, aber wie handhabt man nun, dass der Client-Code bei seinen Objekten eben die Kompatibilität sicherstellen kann?
Mit Basisklassen hilft einem schon die IDE dabei und sagt dass eine Implementierung fehlt, mit dieser Type-Erasure bekommt man wahrscheinlich eine große Menge unleserlicher Fehlermeldungen erst zur Compile-Zeit. Sollte man vielleicht noch auf Concepts warten, um sowas umzusetzen?

Mit Basisklassen hilft einem schon die IDE dabei und sagt dass eine Implementierung fehlt, mit dieser Type-Erasure bekommt man wahrscheinlich eine große Menge unleserlicher Fehlermeldungen erst zur Compile-Zeit. Sollte man vielleicht noch auf Concepts warten, um sowas umzusetzen?

Man kann die Existenz von Memberfunktionen zur Compilezeit checken und dann static_asserts durchführen. Mit Concepts wäre das einfacher, aber ein simples
CONCEPT_CHECK(T, std::is_copy_constructible, std::is_nothrow_move_constructible, ...) was dann ein static_assert für jede Bedingung an T ausführt, ist schnell geschrieben.

Kellerautomat schrieb:

Waehrend bei einer Funktion die Implementierung von aussen betrachtet voellig egal ist, muss man bei einem Concept wissen, was die Anforderungen an den Typ sind. Letzten endes bringt das also rein gar nichts, meiner Meinung nach.

Das Argument verstehe ich nicht. Ein Concept erfordert eine bestimmte Schnittstelle, keine bestimmte Implementierung. Du hast bei der Benutzung des Konzepts ebenso eine Abstraktion wie beim Aufruf einer Funktion.

Ob die einzelnen Konzepte wirklich einen Mehrwert bringen, ist dann eine andere Frage.

Ein Concept hat keine "Implementierung", es ist eine Liste an Anforderungen und damit Teil des Interfaces. Bei einer Funktion trifft das nicht zu. Die Funktion ist also eine Abstraktion. Das Concept fuer eine einzige funktion nicht, es ist nur eine Verschiebung des Problems.

Wenn du eine Funktion aufrufst, kann es sein, dass diese nicht direkt sort aufruft, sondern der Aufruf kann irgendwo tief in einer Kette von Aufrufen verfolgen. In dem Fall ist es gut, wenn du direkt im Interface der Funktion einstellen kannst, dass das übergebene Objekt sortable ist. Insbesondere wenn dann im aufrufstack noch wrappertypen und alles mögliche andere hinzu kommt, kann es für eher unerfahrene Programmierer - und die Welt besteht aus unerfahrenen Programmierern - unmöglich sein, den Fehlermeldungen des Compilers noch sinnvolle Informationen zu entnehmen.

Ich hab selbst erlebt, wie Leute quasi hilflos vor einer Din-A4 Seite langen Fehlermeldung saßen und einfach nicht wussten, wie sie damit umgehen sollen. Ein "Objekt ist nicht sortable" ist dann doch klarer.

---
Und natürlich kann ein freie Funtion als Teil des Interfaces angesehen werden:

begin(container)
end(container)