bool || void

[iTrodan]

Sollte ich hierfür bool oder void benutzen

1.
class Kap
{
public:
short zahl;
bool setZahl(short zahl){
this->zahl = zahl;
return true;
}
};
2.
class Kap
{
public:
short zahl;
void setZahl(short zahl){
this->zahl = zahl;
}
};

[Actidnoide]

Die Methode setzt nur ein Attribut. Da gibt es keine Ausnahme oder Sonstiges, wozu also ein Rueckgabewert?

[iTrodan]

Originally Posted by Actidnoide

Die Methode setzt nur ein Attribut. Da gibt es keine Ausnahme oder Sonstiges, wozu also ein Rueckgabewert?

In meinem Buch wird oft bool statt void verwendet und ich weiß nicht wieso (die Funktion hat keinen Rückgabe Wert)

[XxharCs]

setter - Methoden brauchen keinen Rückgabewert, getter widderum schon.
Normalerweise verwendet man setter/getter bei privat deklarierten Variablen.

Was für ein Buch verwendest du, dass da setter - Methoden, Rückgabewerte (bool in deinem Fall) haben/verwenden?

[iTrodan]

Originally Posted by XxharCs

setter - Methoden brauchen keinen Rückgabewert, getter widderum schon.
Normalerweise verwendet man setter/getter bei privat deklarierten Variablen.

Ich weiß schon bescheid, dieser Code diente nur als Beispiel (mir fiel nichts besseres ein).

Was für ein Buch verwendest du, dass da setter - Methoden, Rückgabewerte (bool in deinem Fall) haben/verwenden?

C++ Lernen und professionell anwenden verwende ich.
Ich habe mich nun dazu entschieden, bei 0 anzufangen und jede Seite gründlich
durchzulesen, mir ist nämlich klar geworden, dass ich die Seiten zum größten Teil überflogen habe.

[LcPlayer1]

Du kannst einen boolean verwenden, um Fehlschläge zu erkennen und zu verarbeiten, also als Alternative/Erweiterung zu Exceptions. Ob das notwendig/sinnvoll ist, ist situationsabhängig. Z.B. beim Verbindungsaufbau zu einer Datenbank kannst du so überprüfen, ob es geklappt hat. Bei einer einfachen Setter-Methode wie in deinem Beispiel ist es eher unnötig.

Beispiel (Pseudocode):

bool connectToDB(...){ ... }
void createTable(...){ ... }

int main()
{
if(connectToDB(...))
{ createTable(...); }
return 0;
};

[Mostey]

Originally Posted by LcPlayer1

Du kannst einen boolean verwenden, um Fehlschläge zu erkennen und zu verarbeiten, also als Alternative/Erweiterung zu Exceptions. Ob das notwendig/sinnvoll ist, ist situationsabhängig. Z.B. beim Verbindungsaufbau zu einer Datenbank kannst du so überprüfen, ob es geklappt hat. Bei einer einfachen Setter-Methode wie in deinem Beispiel ist es eher unnötig.

Wenn eine Verbindung zur Datenbank fehlschlägt, kann das mehrere Ursachen haben und es können dementsprechend mehrere Exceptions fliegen. Daher reicht hier ein boolean meiner Meinung nach nicht mehr. Ich wüsste auch nicht, an welchen Stellen die Verwendung von booleans als Fehlererkennung den Exceptions vorzuziehen ist.

[MrSm!th]

An den Stellen, an denen ein einfaches True/False reicht und die Performance-Einbußen durch Exceptions nicht gerechtfertigt sind.

Außerdem gibt es boolsche Indikatoren gerne in Verbindung mit einer Art LastError Variable, von daher bedeutet ein Bool nicht gleich, dass keine weiteren Informationen möglich sind.

[iTrodan]

Ich verstehe nicht genau was diese Fachbegriffe zu bedeuten haben, ich denke aber dass sich dieses schon sehr bald ändern wird.

[Mostey]

Originally Posted by MrSm!th

An den Stellen, an denen ein einfaches True/False reicht und die Performance-Einbußen durch Exceptions nicht gerechtfertigt sind.

Zum Beispiel? Fehlermeldungen sicherlich nicht.

Originally Posted by MrSm!th

Außerdem gibt es boolsche Indikatoren gerne in Verbindung mit einer Art LastError Variable, von daher bedeutet ein Bool nicht gleich, dass keine weiteren Informationen möglich sind.

Wenn du das so siehst, gibt es noch viele andere Indikatoren um Fehler festzustellen. Eine LastError Variable ist sowas von unnötig und ineffizient, wenn man Exceptions nutzen kann aber das brauche ich dir ja nicht erklären.

€: Weil mich snowi nervt: Ich spreche nicht von Performance.

Originally Posted by iTrodan

Ich verstehe nicht genau was diese Fachbegriffe zu bedeuten haben, ich denke aber dass sich dieses schon sehr bald ändern wird.

Du kannst gerne fragen wenn du etwas nicht verstehst, dafür ist das Forum ja da.

[iTrodan]

Was sind Exceptions?

[Padmak]

Bitte, das lässt sich durch eine einfache Google-Suche herausfinden.
SOLCHE Fragen musst du hier nicht stellen..

Padmak

[iTrodan]

Mostey meinte ich könne die Fragen auch hier stellen und da ich das Internet nicht 100%ig vertraue wollte ich die Frage hier stellen. Naja dann google ich erstmal ein bisschen bevor ich die Fragen online stelle.

[Tasiro]

Originally Posted by iTrodan

[...] da ich das Internet nicht 100%ig vertraue wollte ich die Frage hier stellen.

Dieses Forum befindet sich im Internet. (Es würde mich nicht wundern, wenn dein Beitrag bald in einer Signatur zu finden ist.)

Originally Posted by iTrodan

Naja dann google ich erstmal ein bisschen bevor ich die Fragen online stelle.

Unbedingt.

[Nightblizard]

Originally Posted by MrSm!th

Performance-Einbußen durch Exceptions

Das ist Unsinn und in der Praxis ist oft sogar das genaue Gegenteil der Fall!
Ich habe da mal ein kleines Beispielprogramm geschrieben:


Im Release Modus mit Visual Studio 2013 compiliert bekomme ich folgendes Ergebnis:

with exceptions: 47.8477 seconds
without exceptions: 47.8797 seconds

Wer sich nun fragt warum die "Performancefresser" schneller sind: die Antwort darauf ist relativ simpel.
Durch all die ifs in dem Code, die du einfügen musst um sicher zu gehen, dass nirgens eine Funktion fehlgeschlagen ist, fressen wesentlich mehr Performance als ein einzelnes throw das jemals könnte!
Zusätzlich dazu blähen dir die ifs den Code dermaßen stark auf, dass du weit mehr als das doppelte an Code schreiben musst, um ein ansatzweise gleichwertiges Ergebnis zu bekommen. Das führt dann dazu, dass dein Code nicht nur schwerer zu warten und zu lesen wird, er wird auch gleich sehr viel fehleranfälliger!

Dass Exceptions dein Programm langsamer machen ist alter Aberglaube der C Fanatiker und - vorausgesetzt man macht es richtig - in der Praxis sind sie meistens sogar schneller, weil sie extrem viel overhead aus dem Code raus nehmen.
Und selbst wenn sie langsamer sein sollten, alleine schon druch den Gewinn an Lesbarkeit in deinem Code sollte man immer zuerst auf sie zurückgreifen, denn Performance ist erst dann ein Argument, wenn du mit einem Profiler dein Programm überprüfst und dann als Ergebnis diese eine throw Anweisung aufgeführt wird.