//Möglichkeit 1:
const keine_loesung = INT_MAX;
int nullstelle(const Gerade& g)
{
	//...
	if(keineNullstelle)
		return keine_loesung;
	//...
	return ergebnis;
}

//Möglichkeit 2:
bool nullstelle(cont Gerade& g, int& nullstelle)
{
	//...
	if(keineNullstelle)
		return false;
	nullstelle = ergebnis;
	return true;
}

//Möglichkeit 3:
class KeineNullstelle
{
	//...
}
int nullstelle(const Gerade& g)
{
	//...
	if(keineNullstelle)
		throw KeineNullstelle();
	//...
	return ergebnis;
}

//Möglichkeit 4:
boost::tuple<int, bool> nullstelle(const Gerade& g)
{
	//...
	if(keineNullstelle)
		return boost::tuple<int, bool>(0, false);
	//...
	return boost::tuple<int, bool>(ergebnis, true);
}

Ich denke mal, 1 und 3 kommen nicht in Frage.
Wie würdet ihr es machen?

if( bool deineFunktion() )
    blablaabla;
else
    cout << " Keine Lösung";

So auf die Art würde ich es jetzt machen;-)

Aber denke ist auch situatuionsabhängig was das Programm machen soll falls es nicht klappt, bzw falls es klappt.

Wie würdet ihr es machen?

vector zurückgeben, denn das prog wächst eh und wird bald parabeln und kreise lernen.

@JaykopX Danke, meine Frage war an fr33g gerichtet. Du hast ja klar gesagt, welche du vorziehst.

ja ich würde die nullstelle dann als referenz zurückgeben.
so wies ja glaub ich in deinem vorschlag auch ist.
du hast in deiner main funktion eine variable int nullstelle.
so und das ergebnis deiner funktion teilst du dann der nullstelle zu.
da die als referenz übergeben wird, hast du ja damit die nullstelle in deiner main funktion;-)

@volkard: Für Nullstellen wohl die beste Lösung, aber das sollte nur ein Beispiel für eine Funktion sein, die einen "speziellen" Rückgabewert für "keine Lösung" (aber nicht "Fehler") braucht.

Allgemein läßt sich keine Aussage machen.
Nehmen wir kleine Objekte, geht meistens pair<bool,Object>, werden sie größer, mut vielleicht bool foo(Object&) sein, Aber was ist, wenn es keine ungültigen Objekte geben kann, dann geht nur Zeiger, aber und und und. Ganz zu vergessen von Überladung mit ungültigen Werten, wie INVALID_HANDLE_VALUE, geschloseenen fstreams, 0 als Zeiger, -1 als Array-Index und so.

int ns;
if (nullstelle(gerade, ns))
{
    // ...
}

Beim Paar ist es zwar nicht viel komplizierter, ich mag es allerdings, wenn man den Rückgabewert direkt nutzen kann und nicht erst zerlegen muss.

std::pair<bool, int> pair = nullstelle(gerade);
if (pair.first)
{
    // ...
}

Eine Exception würde ich nicht verwenden und auf INT_MAX abzufragen finde ich auch nicht besonders sinnvoll.

typedef std::list<double> Zeros // oder complex oder float oder ...

Zeroes nullstellen()
// oder ...
void nullstellen(Zeroes& zs)

Was spricht denn nun dagegen, Nullstellen in einer Liste (oder vergleichbares) zurueckzugeben?

Nichts. (nur sind die Nullstellen wie gesagt nur ein Beispiel)
Würdest du auch einen Container verwenden, wenn maximal 1 Element zurückgegeben wird?

Würdest du auch einen Container verwenden, wenn maximal 1 Element zurückgegeben wird?

Wäre mir mit Standard-Containern zu teuer.
Aber ich muß es mal testen. Einen Container für 0 oder 1 Element habe ich noch rumliegen.

Was spricht denn nun dagegen, Nullstellen in einer Liste (oder vergleichbares) zurueckzugeben?

Nichts. (nur sind die Nullstellen wie gesagt nur ein Beispiel)
Würdest du auch einen Container verwenden, wenn maximal 1 Element zurückgegeben wird?

In Haskell wird es so gemacht. Zwar gibt es Maybe, aber meist greift man doch auf [] bzw. [a] zurueck.

Aber ich muß es mal testen. Einen Container für 0 oder 1 Element habe ich noch rumliegen.

Naja, es gibt auch Maybe fuer C++, aber da haengt dann aber noch der ganze Monadkram dran.

Was ist mit boost::optional?

Das ist genau für solche Fälle gemacht

Leider spare ich mir trotzdem nicht die if-Abfrage.

Kann man sich die überhaupt sparen? Denn es muss ja ein anderer Ablaufpfad eingeschlagen werden, abhängig davon, ob die Funktion Nullstellen hat oder nicht. (Ich möchte jetzt nicht auf If-Workarounds wie Funktionszeiger oder sowas hinaus).

Kann man sich die überhaupt sparen? Denn es muss ja ein anderer Ablaufpfad eingeschlagen werden, abhängig davon, ob die Funktion Nullstellen hat oder nicht. (Ich möchte jetzt nicht auf If-Workarounds wie Funktionszeiger oder sowas hinaus).

Wenn man z.B. mehrere Rueckgabewerte hat, dann will man diese fuer gewoehlich weiterverarbeiten. Tu was mit allen Nullstelln, Tu was mit allen Matches des regulaeren Ausdrucks, ... Im einfachsten Fall moechte man diese erst mal ausgeben, also for*( it = matches.begin(); it != matches.end(); ++it)* oder mittels std::for_each(...). Ist jetzt der Container aber leer, so passiert gar nichts. Bei der Variante mit expliziten Rueckgabewert, std::pair oder boost::optional muss dieser erst geprueft werden. Diese Pruefung ist natuerl auch in der Variante mit for enthalten, aber sie ist implizit und muss nicht hingeschrieben werden. Und bei allem, was ich nicht dasteht, kann ich auch keine Fehler machen. Der Code hat etwas weniger Rauschen (Laerm, noise). Performanceunterschiede wird es wohl nicht geben.

Frager schrieb:

Was ist mit boost::optional?

Das ist genau für solche Fälle gemacht

Mag sein, aber es ist verboostelt und damit für mich indiskutabel.
Außerdem wollte ich einen CONTAINER, also mit begin() und end() bzw mit content().

Mag sein, aber es ist verboostelt und damit für mich indiskutabel.

Klingt nach ner emotionalen Entscheidung, die imo nichts bei der Wahl der Mittel für sowas zu suchen hat. Es sei denn "verboostelt" heißt sowas wie "zu allgemein und daher mit performance-overhead".

volkard schrieb:

Außerdem wollte ich einen CONTAINER, also mit begin() und end() bzw mit content().

Der OP wollte aber keinen Container sondern nur eine Möglichkeit, zusätzlich zur Menge der möglichen einzelnen Lösungen den Wert "keine Lösung" auszudrücken. Von begin(), end() etc. war nie wirklich die Rede.

volkard schrieb:

Mag sein, aber es ist verboostelt und damit für mich indiskutabel.

Klingt nach ner emotionalen Entscheidung, die imo nichts bei der Wahl der Mittel für sowas zu suchen hat. Es sei denn "verboostelt" heißt sowas wie "zu allgemein und daher mit performance-overhead".

volkard schrieb:

Außerdem wollte ich einen CONTAINER, also mit begin() und end() bzw mit content().

Der OP wollte aber keinen Container sondern nur eine Möglichkeit, zusätzlich zur Menge der möglichen einzelnen Lösungen den Wert "keine Lösung" auszudrücken. Von begin(), end() etc. war nie wirklich die Rede.

volkard schrieb:

Frager schrieb:

Würdest du auch einen Container verwenden, wenn maximal 1 Element zurückgegeben wird?

Wäre mir mit Standard-Containern zu teuer.
Aber ich muß es mal testen. Einen Container für 0 oder 1 Element habe ich noch rumliegen.

Frager schrieb:

volkard schrieb:

Einen Container für 0 oder 1 Element habe ich noch rumliegen.

Was ist mit boost::optional?

pumuckl schrieb:

Frager schrieb:

Was ist mit boost::optional?

Das ist genau für solche Fälle gemacht

Klingt danach, als sei boost genau für solche Fälle gemacht, wo man einen kleinen Container haben will.

Klingt danach, als sei boost genau für solche Fälle gemacht, wo man einen kleinen Container haben will.

Du hast den Container aufgebracht mit dem Argument dass später irgendwann mal eh mehrere Ergebnisse zurückgegeben werden müssten.
boost::optional ist eben kein wirklicher container (was du ja bemängelt hast, weils kein begin() und end() dabei ist), sondern eine Lösung für die Situationen wo ein Container overkill wäre.