Template Constraint

volkard

Firefighter schrieb:

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

Ja. Am schönsten mit SFINAE.

Firefighter

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?

volkard

Firefighter schrieb:

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.

Firefighter

Meinst du wirklich das mit anders nenne wäre ne Gute Idee? Dann geht mir ja die Überladung an der Stelle flöten? Und warum hilft mir bei dem Problem das inplace_merge ?

*Q* 1

Ich glaube der link zum inplace-merge war nur um zu zeigen wie die Dokumentation der Bedingungen für Benutzerdefinierte Typen aussehen könnte.

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

Firefighter

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?

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

*Q* 1

Um das beurteilen zu könnem musst du schon etwas mehr preisgeben - welche überladungen hast du, worin unterscheiden sich diese, was machen die ganzen sachen überhaupt jeweils?

Edit: Warum wird euch boost eigentlich verboten?

pumuckl

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

Firefighter

Hehe ja das is ne gute Frage, vermutlich ne Grundeinstellung des Professors. An und für sich ist das auch gut so, so lernen die Anfänger bei uns im Kurs wie man sich gewisse Sachen erstmal erarbeitet ehe man mit boost die Großen Kanonen rausholt.

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

pumuckl schrieb:

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.

volkard

Firefighter schrieb:

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.

Firefighter

@volkard. Super informationen. Danke. Das ich die Methoden nicht read_int und konsorten nenne is mit schon klar. Ich werd das nochmal überarbeiten. Danke auf jedenfall für die vielen Tips.

Firefighter

@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?

volkard

Firefighter schrieb:

@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.