Template Parameter Pointer oder nicht

Hallo,

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!

Fytch

template<class Input>
void doSomething(Input i) { i.called(); }
template<class Input>
void doSomething(Input* i) { i->called(); } // vll. auch eher (Input const* i)

Columbo

Das muss einfach noch generischer gemacht werden:

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} );
}

Nexus

Warum kannst du nicht verlangen, dass immer oder nie ein Zeiger übergeben wird? Finde ich sauberer als im Nachhinein wieder eine Fallunterscheidung einzubauen.

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.

Hallo,

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!

Ich würde das ganze gern in einer Template Klasse machen.
Da kann ich das überladen so aber leider nicht machen.

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

danke

Nexus

swalkner schrieb:

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?

Nexus schrieb:

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.

Danke für eure Anmerkungen (wobei bei einem template ja egal sein sollte, womit man es füttert)

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

Danke

Nexus

swalkner schrieb:

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.

Ok - danke für eure Antworten.
Hab nun Variante 2 geschafft