ich war schon mal mit einer ähnlichen Frage bei euch.
Ausgangssituation is folgende:
1. wir dürfen kein Boost verwenden, deshalb versuch ich mir für die Zeit etwas annehmbares selbst zu schreiben.
2. Ich möchte Template Parameter einschränken, geht das?

Hier das Beispiel:

template <class T>
T read(T lowerBound,T upperBound)
{
// code der irrelevant ist
}

Frage ist folgende: Kann ich wenn möglich, Template Parameter in diesem Fall nach den Standardtypen einschränken, also int,float.... und Konsorten.
Wenn nein, was wäre eine Alternative?

Oder:
Würdet ihr diese Methode so belassen aber den Verwender bei der Benutzung von eigenen Datentypen dazu auffordern die Operatoren < und > zu überladen?

Viele Grüße und Danke fürs Lesen.

Morgen Leute,

ich war schon mal mit einer ähnlichen Frage bei euch.
Ausgangssituation is folgende:
1. wir dürfen kein Boost verwenden, deshalb versuch ich mir für die Zeit etwas annehmbares selbst zu schreiben.
2. Ich möchte Template Parameter einschränken, geht das?

Hier das Beispiel:

template <class T>
T read(T lowerBound,T upperBound)
{
// code der irrelevant ist
}

Frage ist folgende: Kann ich wenn möglich, Template Parameter in diesem Fall nach den Standardtypen einschränken, also int,float.... und Konsorten.

Wozu? Damit mein Typ Rational für Bruchzahlen nicht mehr klappt? Ich würde Dir ins Popöchen treten!

Firefighter schrieb:

Wenn nein, was wäre eine Alternative?

Einfach nix tun. Wie meistens in der Informatik könnte es auch hier die beste Lösung sein.

Firefighter schrieb:

Würdet ihr diese Methode so belassen aber den Verwender bei der Benutzung von eigenen Datentypen dazu auffordern die Operatoren < und > zu überladen?

Wenn er's nicht tut, kommt doch ein wunderbarer Compilerfehler geflogen. Dann weiß er schon bescheid.

2. Ich möchte Template Parameter einschränken, geht das?

Ja. Am schönsten mit SFINAE.

Also kann ich aus deinem ersten Beitrag schließen ich soll die Methode so belassen wie sie ist, aber am besten in der Doku einen Hinweis darauf machen das der Operator < > für User-defined Types implementiert werden muss. Mal abgesehen von dem operator>> , richtig?

Ja.
Vielleicht so: http://www.cplusplus.com/reference/algorithm/inplace_merge/
Also eindeutig im Text und nicht als nervige Tabellenaufzählung.
Und es wäre nett, nur den op< zu verwenden, der reicht hier ja.

Und auf jeden Fall anders nennen als nur read. Oder die beteiligten Stream übergeben lassen. Mag Funktionen haben, die keine Doku brauchen.

Und zum Thema überladung: Evtl. machts sinn alle anderen überladenen sachen auch umzubenennen?

Ich weiß nich, bin aber für alle Tips dankbar.

Edit: Warum wird euch boost eigentlich verboten?

Und jeder Funktion den Namen geben was sie macht? Wäre ne Idee.

Eine klasse Idee. Dann stünde nämlich im Quelltext das, was passiert. Und nicht immer nur read.

Hebt das aber nicht etwas die Usability auf?

Nein, im Gegenteil. Damit müsste der Entwickler nurnoch schreiben, was er möchte, anstatt bei jeder Gelegenheit nur "read" zu schreiben und zu hoffen, dass durch glückliche Umstände auch eine Funktion gerufen wird, die tut, was er gerne hätte.

Das klingt bei dir ein wenig so, als ob jede Funktion, egal ob sie liest, schreibt, multipliziert oder Erbsen zählt, auf jeden Fall read heißt

Hier noch meine Restlichen Überladungen:

template<class T>
T read()
{
	T object;
	details::getInput(object);
	return object;
}
template<class T>
T read(const std::string& promptMessage,bool withNewLine = false)
{
	if(withNewLine)
	 std::cout<<promptMessage<<std::endl;
	else
	 std::cout<<promptMessage;

return read<T>();
}
template <class T>
T read(bool (*Validate)(T),const std::string& prompt)
{
	T obj;
	do
	{
		std::cout<<prompt;
		obj = read<T>();
	}while(!Validate(obj));

	return obj;
}

Und die bereits gezeigte Überladung für die Grenzen.

Firefighter schrieb:

Und jeder Funktion den Namen geben was sie macht? Wäre ne Idee.

Eine klasse Idee. Dann stünde nämlich im Quelltext das, was passiert. Und nicht immer nur read.

Hebt das aber nicht etwas die Usability auf?

Nein, im Gegenteil. Damit müsste der Entwickler nurnoch schreiben, was er möchte, anstatt bei jeder Gelegenheit nur "read" zu schreiben und zu hoffen, dass durch glückliche Umstände auch eine Funktion gerufen wird, die tut, was er gerne hätte.

Das klingt bei dir ein wenig so, als ob jede Funktion, egal ob sie liest, schreibt, multipliziert oder Erbsen zählt, auf jeden Fall read heißt

Schöne Argumente pumuckl, werd sie auf jedenfall Berücksichtigen.

Alle umbenennen? Ihr meint also ich soll die Überladungne komplett aufgeben? Und jeder Funktion den Namen geben was sie macht? Wäre ne Idee. Hebt das aber nicht etwas die Usability auf?

Nein! Natürlich nicht read_int, read_double und read_VolkardsBruchzahlentyp.

Ich meine

template<typename T>
T read_until_range_check_succeeds(istream& in,ostream& placeForInputPromptsAndUserNamecallings,T lowerBoundInclusive,T upperBoundExclusive){
   ...
}

Oder soll es nur auf cin+cout laufen? Rein in den Funktionsnamen. Oder soll es gar keine Schleife sein, sondern im Fehlerfall eine Exception werfen? Rein in den Funktionsnamen. Oder den Fehlerfall nur den Stream-Status setzen? Nee, dann würde sie ja den istream zurückgeben.

edit: Viel zu spät gepostet. Ist ja schon alles geklärt.

@volkard: Eine frage hätte ich aber noch: Wo liegt der Vorteil/Nachteil den Stream als Template PArameter mitzugeben? Wo liegen da generell Vorteile/Nachteile? Warum sollte ich den Stream als Templateparameter mitgeben und wann sollte ich ihn als Funktionsparameter mitgeben?

Das war ein Tippfehler, als ich die Streams oben als Templateargumente machte. Gar keine Absicht.

Theoretisch sollten für volle Generizität die Streams auch sogar Tamplateargumente sein, weil damit auch Stream genommen werden könnten, die wide characters nehmen.