bool || void

05/30/2014 22:10 iTrodan#1
Sollte ich hierfür bool oder void benutzen

Code:
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;
}
};
05/30/2014 22:19 Actidnoide#2
Die Methode setzt nur ein Attribut. Da gibt es keine Ausnahme oder Sonstiges, wozu also ein Rueckgabewert?
05/30/2014 22:31 iTrodan#3
Quote:
Originally Posted by Actidnoide View Post
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) :confused:
05/30/2014 22:35 XxharCs#4
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?
05/30/2014 23:03 iTrodan#5
Quote:
Originally Posted by XxharCs View Post
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).

Quote:
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.
05/31/2014 09:23 LcPlayer1#6
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):

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

int main()
{
if(connectToDB(...))
{ createTable(...); }
return 0;
};
05/31/2014 10:21 Mostey#7
Quote:
Originally Posted by LcPlayer1 View Post
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.
05/31/2014 18:30 MrSm!th#8
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.
05/31/2014 19:33 iTrodan#9
Ich verstehe nicht genau was diese Fachbegriffe zu bedeuten haben, ich denke aber dass sich dieses schon sehr bald ändern wird.
05/31/2014 19:53 Mostey#10
Quote:
Originally Posted by MrSm!th View Post
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.

Quote:
Originally Posted by MrSm!th View Post
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.


Quote:
Originally Posted by iTrodan View Post
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.
05/31/2014 20:53 iTrodan#11
Was sind Exceptions?
05/31/2014 21:58 Padmak#12
Bitte, das lässt sich durch eine einfache Google-Suche herausfinden.
SOLCHE Fragen musst du hier nicht stellen..

Padmak
05/31/2014 22:20 iTrodan#13
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.
05/31/2014 22:38 Tasiro#14
Quote:
Originally Posted by iTrodan View Post
[...] 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.)

Quote:
Originally Posted by iTrodan View Post
Naja dann google ich erstmal ein bisschen bevor ich die Fragen online stelle.
Unbedingt.
05/31/2014 23:07 Nightblizard#15
Quote:
Originally Posted by MrSm!th View Post
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:
[Only registered and activated users can see links. Click Here To Register...]

Im Release Modus mit Visual Studio 2013 compiliert bekomme ich folgendes Ergebnis:
Quote:
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.