mir fallen leider offensichtlich die richtigen Bezeichnungen für mein Problem nicht ein - deshalb finde ich nichts. Ich hoffe jmd. kann mir helfen.

Ich habe eine Template Methode, die auf den Template Parameter eine Methode aufrufen soll. Nun macht es für den Aufruf natürlich einen Unterschied, ob das ein Pointer/Shared-Pointer oder nicht ist:

template<class Input>
void doSomething(Input i) { i.called(); }

doSomething<Input*>(&myvar);
doSomething<Input>(myvar);

Wie kann ich das Template so gestalten, dass ich das richtig implementiere?

Herzlichen Dank im Voraus!

template< typename T >
auto doSomething( T&& t ) -> decltype(t.called()) { return t.called(); }

template< typename T >
auto doSomething( T&& t ) -> decltype(t->called()) { return t->called(); }

#include <iostream>
#include <memory>

int main()
{
	struct A
	{
		void called(){ std::cout << "called!\n"; }
	};

	doSomething( A{} );
	doSomething( new A );
	doSomething( std::unique_ptr<A>{new A} );
}

Vor allem ist es normalerweise keine gute Idee, Smart-Pointer zu übergeben, wenn du nur das Pointee-Objekt verändern willst. Und zwar weil du beim unique_ptr den Besitz raubst und bei shared_ptr eine teuere Kopie anfertigst. Smart-Pointer per Referenz zu übergeben ist nur sinnvoll, wenn Zugriff auf den Smart-Pointer selbst nötig ist.

das mit dem "Fordern" find ich nicht richtig und ich weiß noch nicht, wie ich es verwenden will. Von einem unique_ptr hab ich nie gesprochen... Das ist klar, dass man den nicht einfach weitergeben darf.

Vorschlag 1 läuft schon mal.
Vorschlag 2 probier ich gerade noch aus, weil ich natürlich schon auch gern die Option auf shared_ptr hätte!

danke derweilen!

Irgendwer eine Idee, wie ich Variante 2 in eine Klasse bringen kann?

danke

das mit dem "Fordern" find ich nicht richtig und ich weiß noch nicht, wie ich es verwenden will.

Ähm... Die ganze Idee hinter API-Design besteht darin, klar definierte Schnittstellen anzubieten, die ein Benutzer intuitiv einsetzen kann. Überlegungen wie "fügen wir Feature X ein, allein schon weil es möglich ist" und "bieten wir doch beides an, Hauptsache alle sind glücklich" sind genau der Grund, wieso so viele APIs vermurkst sind. Bitte mach nicht den gleichen Fehler.

Ausserdem, APIs sollten aus User-Perspektive entworfen werden. Wenn du noch nicht weisst, wie du es benutzen willst, dann lohnt es sich, sich zuerst diese Überlegung zu machen, damit du nachher nicht ständig refactoren musst.

So viel zum Allgemeinen. Nun konkret, wer ruft den deine Funktion auf und kann sich nicht auf Zeiger oder Referenz festlegen?

Wenn du noch nicht weisst, wie du es benutzen willst, dann lohnt es sich, sich zuerst diese Überlegung zu machen, damit du nachher nicht ständig refactoren musst.

Ich will das mal umformulieren.

Wenn du noch nicht weisst, wie du es benutzen willst, dann lohnt es sich nicht, es zu implementieren.

Hat trotzdem jmd eine Lösung, wie ich beides (in einer Klasse) unterstützen könnte?

Danke

wobei bei einem template ja egal sein sollte, womit man es füttert

Du verstehst Templates falsch. Sie sind nicht dazu da, unklaren Umgang mit Typen zu korrigieren. Insbesondere sollen sie die Typsicherheit erhöhen, nicht abschwächen.

swalkner schrieb:

Hat trotzdem jmd eine Lösung, wie ich beides (in einer Klasse) unterstützen könnte?

Unsere Einwände stehen nicht ohne Grund da. Eventuell könnte deine Lösung ganz anders (wahrscheinlich einfacher) aussehen, aber dazu müsstest du einsehen, dass deine Vorgehensweise möglicherweise nicht die beste ist, und uns erklären, was du erreichen willst -- und nicht wie du dir eine spezifische Umsetzung vorstellst, ohne das Problem zu beschreiben.