| Autor |
Beitrag |
ace1905
 
Beiträge: 73
|
Verfasst: Do 31.01.08 20:48
hallo. ich fang grad mit c++ an und suche jemanden der mir vill ein wenig auf fragen antworten kann, die ich nirgendwo finden kann. im internet gibts meistens nur die fortgeschrittenen-foren. jedenfalls ist das was da drin steht nicht das was ich suche.
ich suche jemanden der mir ein paar fragen beantworten kann, sobald mal welche aufkommen.
dazu wärs nat. am besten wenn mir jemand über pm seine icq nummer geben könnt oder die e-mail adresse hinterlassen könnte.
fänds cool wenn sich jemand dazu bereit erklärt.
und keine angst. so viele fragen stell ich nicht, da ich ein sehr gutes buch habe aus dem ich das meiste selbst lerne.
eine frage möchte ich mal hier anbringen:
ich programmiere mit microsoft visual c++ 6.0 .
im moment arbeite ich noch mit konsolenanwendungen und habe heute gemerkt dass alle programme die eine klasse enthalten, sich nicht in der exe öffnen lassen bzw. sobald die klasse im programm zum einsatz kommt stürzt das programm ab.
hier mal ein kleines beispiel:
Einloggen, um Attachments anzusehen!
|
|
opfer.der.genauigkeit
Beiträge: 754
Erhaltene Danke: 1
|
Verfasst: Di 19.02.08 21:44
Für den Fall, dass du dein Problem nicht schon selbst gefunden hast...
Du rufst den Konstruktor nicht korrekt auf.
  Quelltext
1:
| Rechteck rect = Rechteck(a, b); |
Und einen Destruktor rufst du auch nicht auf. 
MfG _________________ Stellen Sie sich bitte Zirkusmusik vor.
|
|
tommie-lie
Beiträge: 4373
Ubuntu 7.10 "Gutsy Gibbon"
|
Verfasst: Di 19.02.08 22:53
 opfer.der.genauigkeit hat folgendes geschrieben: | Du rufst den Konstruktor nicht korrekt auf.
Quelltext
1:
| Rechteck rect = Rechteck(a, b); | |
Doch, tut er. Deine Initialisierung durch assignment-expression würde allerdings auch gehen.
| opfer.der.genauigkeit hat folgendes geschrieben: | | Und einen Destruktor rufst du auch nicht auf. |
Muss er auch nicht.
Ansonsten sehe ich spontan keine Fehler und bei mir funktioniert das Programm auch (allerdings anderer Compiler und anderes Betriebssystem).
Allerdings würde ich Rechteck::Area(float,float) und Rechteck::Umfang(float,float) in ihrer derzeitigen Implementierung static deklarieren, weil die nichts mit einem konkreten Objekt zu tun haben. Oder stattdessen ein Rechteck::Area() nehmen, das die Grundfläche über this->itsWidth und this->itsHeight berechnet. _________________ Your computer is designed to become slower and more unreliable over time, so you have to upgrade. But if you'd like some false hope, I can tell you how to defragment your disk. - Dilbert
|
|
STATUS_ACCESS_DENIED
Ehemaliges Mitglied
Erhaltene Danke: 1
|
Verfasst: Di 19.02.08 22:57
| opfer.der.genauigkeit hat folgendes geschrieben: | Für den Fall, dass du dein Problem nicht schon selbst gefunden hast...
Du rufst den Konstruktor nicht korrekt auf.
Quelltext
1:
| Rechteck rect = Rechteck(a, b); |
Und einen Destruktor rufst du auch nicht auf.
MfG |
Hrmpf. This can only be a Scherz, hmm? Also "Opfer der Genauigkeit" stimmt hier 199%ig nicht! Denn beide Aussagen sind Quaaaaaaa(r)k.
1.) Der Konstruktoraufruf ist ganz korrekt und
Rechteck rect = Rechteck(a, b); ist nicht nur Quaaak, sondern ohne den operator=() reineweg gefährlich. Zufällig geht es hier ja, weil die Membervariablen alle integrale Typen sind, aber ansonsten zeigt dir das Programm den Stinkefinger.
2.) Wenn man ein Objekt auf dem Stack (was in Delphi ja bekanntlich nicht geht) instanziert, braucht man keinen Destruktor aufrufen - macht C++ nämlich mal jaaaanz automatisch.
Ich schicke gleich noch ein paar Anpassungen der Klasse, zusammen mit weiteren Erläuterungen hinterher. Aber vorher muß dringend mein Essen vom Herd 
|
|
STATUS_ACCESS_DENIED
Ehemaliges Mitglied
Erhaltene Danke: 1
|
Verfasst: Di 19.02.08 22:58
Als Nachtrag stimme ich dem Herrn Lie zu.
|
|
opfer.der.genauigkeit
Beiträge: 754
Erhaltene Danke: 1
|
Verfasst: Di 19.02.08 23:09
Dem naechsten C oder C++ Programmierer werde ich nur noch auf externe Links verweisen.
Denn mein Vorschlag hat funktioniert, ich hab es immerhin auch getestet.
Wenn es eine weiter Syntax gibt oder Spracherweiterungen... egal...
Benutz ich Delphi oder C++?
Mit dieser Art Kommentare wirst du dir viele Freunde im Forum machen.
Den Ersten hast du schon, du bist mit Sicherheit der letzte C/C++ Programmierer mit dem ich mich beschäftigt habe.
//Edit: @tommie-lie danke, wieder etwas dazu gelernt. _________________ Stellen Sie sich bitte Zirkusmusik vor.
|
|
STATUS_ACCESS_DENIED
Ehemaliges Mitglied
Erhaltene Danke: 1
|
Verfasst: Di 19.02.08 23:14
| opfer.der.genauigkeit hat folgendes geschrieben: | | Denn mein Vorschlag hat funktioniert, ich hab es immerhin auch getestet. |
Das ist nicht die Frage. Ich werde Näheres in kürze zusammen mit dem leicht angepaßten Code des OP erklären.
k.A. - deine Sache.
| opfer.der.genauigkeit hat folgendes geschrieben: | Mit dieser Art Kommentare wirst du dir viele Freunde im Forum machen.
Den Ersten hast du schon, du bist mit Sicherheit der letzte C/C++ Programmierer mit dem ich mich beschäftigt habe. |
Jetzt bin ich aber gaaaanz traurig. Quark bleibt aber Quark, ob man nun Sahne dazumacht oder einen Kuchen draus bäckt.
|
|
tommie-lie
Beiträge: 4373
Ubuntu 7.10 "Gutsy Gibbon"
|
Verfasst: Di 19.02.08 23:45
| STATUS_ACCESS_DENIED hat folgendes geschrieben: | | Hrmpf. This can only be a Scherz, hmm? Also "Opfer der Genauigkeit" stimmt hier 199%ig nicht! Denn beide Aussagen sind Quaaaaaaa(r)k. |
Ich hatte mir sowas extra noch verkniffen 
| STATUS_ACCESS_DENIED hat folgendes geschrieben: | | Rechteck rect = Rechteck(a, b); ist nicht nur Quaaak, sondern ohne den operator=() reineweg gefährlich. Zufällig geht es hier ja, weil die Membervariablen alle integrale Typen sind, aber ansonsten zeigt dir das Programm den Stinkefinger. |
Nö. copy-c'tor (und der wird hier verwendet, nicht operator=()) wird vom Compiler erzeugt und funktioniert in der Regel ganz gut, auch mit class-type members (bei Referenzen/Pointern ist es halt nur eine shallow copy, das sollte man wissen, ist jetzt aber nichts sooo dramatisches).
| opfer.der.genauigkeit hat folgendes geschrieben: | | Dem naechsten C oder C++ Programmierer werde ich nur noch auf externe Links verweisen. |
Zum Beispiel auf www.amazon.com/exec/...detail/-/0470846747/?
| opfer.der.genauigkeit hat folgendes geschrieben: | Denn mein Vorschlag hat funktioniert, ich hab es immerhin auch getestet.
Wenn es eine weiter Syntax gibt oder Spracherweiterungen... egal... |
Klar funktioniert deine Version, es wird ein Temporary mit Rechteck(float,float) erzeugt und anschließend der copy-constructor benutzt, um die Variable rect mit dem Temporary zu initialisieren. Funktionieren tut das, wie schon erwähnt, auch bei komplexeren Klassen relativ schmerzfrei.
Richtig falsch ist nur deine Aussage, daß der Code des OP falsch sei, denn das ist nicht der Fall. Das ist keine Spracherweiterung und ist im Gegensatz zu deiner Variante sogar die bevorzugte (da direkte) Variante, um Objekte zu intialisieren. _________________ Your computer is designed to become slower and more unreliable over time, so you have to upgrade. But if you'd like some false hope, I can tell you how to defragment your disk. - Dilbert
|
|
opfer.der.genauigkeit
Beiträge: 754
Erhaltene Danke: 1
|
Verfasst: Di 19.02.08 23:52
Hab ja gesagt, dass ich wieder etwas dazu gelernt habe. 
Ich rede ja auch nicht gerne Unsinn. 
Evtl. sollte ich wirklich mal ein C++ Buch in die Hand nehmen und lernen. 
Kann ich mich gleich mit dem Topicsteller zusammenschließen. _________________ Stellen Sie sich bitte Zirkusmusik vor.
|
|
STATUS_ACCESS_DENIED
Ehemaliges Mitglied
Erhaltene Danke: 1
|
Verfasst: Di 19.02.08 23:56
So, hier nun etwas ausführlicher. Im Anhang eine angepaßt Version mit Kommentaren an allen Ecken und Enden.
Konstruktoren (Ctors):
Es ist richtig, daß man es mit Zuweisungsoperator machen kann, was aber auch normalerweise voraussetzt, daß man erstmal einen definiert! Tut man es nicht, riskiert man, daß der Compiler es falsch macht (bspw. bei Pointern als Membervariablen). Daher ist es eine Unsitte, nach C-Manier seine Objekte nicht über den Konstruktor zu erzeugen.
Der C++-Compiler erzeugt zwar automatisch einen Copy-Ctor und einen Zuweisungsoperator (Assignment-Operator), aber das kann höchst gefährlich werden. Daher sollte man sie entweder
1.) selber definieren, oder
2.) privat deklarieren, aber nicht definieren (also nicht implementieren) um den Compiler daran zu hindern es automatisch zu tun.
Eine Faustregel ist es ebenfalls immer einen Copy-Ctor zu definieren/deklarieren, wenn man einen Zuweisungsoperator schon definiert/deklariert hat - und umgekehrt. Dadurch muß eben der Benutzer einer Klasse nicht wissen, daß das eine vielleicht implementiert ist, das ander aber nicht.
Nehmen wir obiges Beispiel:
Quelltext
1:
| Rechteck rect = Rechteck(a, b); |
Dieser Code ruft zuerst auf Rechteck::Rechteck(float,float) auf. Danach ruft er Rechteck::Rechteck(const Rechteck&) auf, welches der (ebenfalls automatisch erzeugte) Copy-Ctor ist ist. (korrigiert, tommie-lie hat hier natürlich recht. Innerhalb der Klasse - siehe unten - ist es allerdings tatsächlich der Zuweisungsoperator. 2tes Mal korrigiert, siehe tommie-lies Kommentar(e) weiter unten).
Hingegen:
Quelltext
ruft den angewiesenen Konstruktor Rechteck::Rechteck(float, float) auf.
In unserem Fall ist es ein geringer Overhead, so daß es zumindest aus Perspektive des Optimierens "keinen Unterschied" macht. Aber erstens ist ja hier offenbar ein C++-Anfänger am anderen Ende, dem man am besten solche Unsitten nicht erst angewöhnt, und zweitens könnte eine der Membervariablen auch gut selber eine Klasse sein, die vielleicht noch übers Netz kommuniziert. Bei Timeouts und Netzwerklatenz haben wir dann im ersten Fall schonmal doppelte Wartezeit, bei Nummero zwo hingegen nicht.
Soviel zu dem Teil.
Konstruktoren sollten die Membervariablen immer, sofern möglich, in der Initialisierungsliste initialisieren. Übrigens ist die Argumentation exakt die gleiche wie in dem Beispiel vorher.
Nehmen wir eine Klasse Foo mit einer enthaltenen Klasse Bar.
Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
| class Bar
{
public:
Bar() {}
};
class Foo
{
Bar m_bar;
public:
Foo(const Bar& bla) : m_bar(bla) {}
}; |
Nun ist für die Klasse Foo zweierlei Ansatz für den Ctor denkbar.
1.)
Foo(const Bar& bla) : m_bar(bla) {}in welchem Fall die Instanz für m_bla nur einmal erzeugt wird und sofort initialisiert ist.
2.)
Foo(const Bar& bla) { m_bar = bla; }in welchem Fall die Instanz für m_bla zwar auch nur einmal erzeugt wird aber per Default-Ctor für Klasse Bla. Hernach wird dann noch zusätzlich Bla& Bla::operator=(const Bla&) aufgerufen um die im Ctor-Body gegebene Zuweisung auszuführen.
Okay, nun haben wir die Konstruktoren soweit durch. Zumindest fast.
Kommen wir zu unserem geliebten Paar, den Zuweisungsoperatoren mit ihrem angeheirateten Copy-Ctor.
Bei einem Zuweisungsoperator (den der eine konstante Referenz des selben Typs nimmt) ist zuallererst wichtig, daß man Selbstzuweisung verhindern muß. Wieso? Nun, wenn man bspw. eine Selbstzuweisung bekommt und erstmal die Daten freigibt um sie hernach von ... oh ups, sich selber zu kopieren? Das kann nur schiefgehen.
Also:
Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
| Rechteck& Rechteck::operator=(const Rechteck& rhs)
{
if(this != &rhs)
{
// hier die Memberbvariablen kopieren
}
return *this;
} |
Der entsprechende Copy-Ctor sähe folgendermaßen aus:
Quelltext
1:
2:
3:
4:
5:
| Rechteck::Rechteck(const Rechteck& rhs)
: itsLength_(rhs.itsLength_)
, itsWidth_(rhs.itsWidth_)
{
} |
So, nun sind wir fast  durch mit Konstruktoren, nur noch ein Hinweis. Wenn man die Initialisierungsliste benutzt, sollte man der Lesbarkeit halber die Membervariablen in der Reihenfolge angeben, in der sie in der Klasse deklariert sind. Tut man es nicht, wird sich der Compiler nicht beschweren. Nähmen wir aber an, daß einige der Membervariablen voneinander abhängen, dann wird's schwierig. Denn egal welche Reihenfolge man in der Initialisierungsliste angibt, sie werden in der Reihenfolge ihrer Deklaration initialisiert. Das bedeutet, daß man böse Überraschungen erleben kann
Wie von tommie-lie erwähnt, sollte man bestimmte Funktionen - in diesem Fall bietet es sich sogar direkt an - statisch und normal deklarieren. Statisch bedeutet, daß keine Instanz existieren muß, damit man die entsprechende Methode aufrufen kann (siehe Kommentare im Source). So kann man gleichzeitig die Funktionalität den Instanzen anbieten, oder "externen" Benutzern.
Wenn weitere Fragen, immer losfragen. Wer nicht's fragt der nichts gewinnt ... oder so
Argh ... Anhang vergessen.
Zuletzt bearbeitet von STATUS_ACCESS_DENIED am Mi 20.02.08 12:05, insgesamt 3-mal bearbeitet
|
|
Assarbad
Ehemaliges Mitglied
Erhaltene Danke: 1
|
Verfasst: Mi 20.02.08 01:18
Okay, 'tschuldigung! Lag bestimmt am knurrenden Magen 
|
|
tommie-lie
Beiträge: 4373
Ubuntu 7.10 "Gutsy Gibbon"
|
Verfasst: Mi 20.02.08 10:21
| STATUS_ACCESS_DENIED hat folgendes geschrieben: | Konstruktoren (Ctors):
Es ist richtig, daß man es mit Zuweisungsoperator machen kann |
Wie? Die Syntax, die auch tatsächlich den operator= benutzt, wäre mindestens zweizeilig. Auch opfer.der.genauigkeit hätte *nicht* den Zuweisungsoperator benutzt,
| STATUS_ACCESS_DENIED hat folgendes geschrieben: | | was aber auch normalerweise voraussetzt, daß man erstmal einen definiert! Tut man es nicht, riskiert man, daß der Compiler es falsch macht (bspw. bei Pointern als Membervariablen). Daher ist es eine Unsitte, nach C-Manier seine Objekte nicht über den Konstruktor zu erzeugen. |
Was verstehst du unter falsch? Der Standard schreibt exakt vor, was der Default-Copy-c'tor macht, es ist wohldefiniertes verhalten, das nicht kaputt ist. Wenn es "gefährlich" wird, ist entweder dein Compiler kaputt, oder man hat erachtet garantiertes Verhalten als falsch, dann hat man aber den Standard nicht richtig verstanden.
| STATUS_ACCESS_DENIED hat folgendes geschrieben: | Nehmen wir obiges Beispiel:
Quelltext
1:
| Rechteck rect = Rechteck(a, b); |
Dieser Code ruft zuerst auf Rechteck::Rechteck() - auch bekannt als Default-Ctor, welchen der Compiler in unserer Klasse mal frisch und frei selber erzeugt hat. |
Hm? Bekommt dir das nordische Essen nicht? Ein Default-c'tor wird nicht erzeugt, sobald man einen eigenen Konstruktor hat (auch wenn der kein Default-c'tor ist). Es ist nicht garantiert, daß eine Klasse einen Default-c'tor besitzt und er wird in diesem Fall auch nicht aufgerufen (weilla ja ga nich da iss ). Was hier (formal) aufgerufen wird, ist der Konstruktor mit den Paramtern (float, float) und anschließend der Copy-c'tor. Mein GCC 4.2 ruft sogar nur den Konstruktor mit (float,float) auf, auch ohne Optimierungen. (Für mich eine Verletzung des Standards, ich sollte der Sache mal nachgehen).
| STATUS_ACCESS_DENIED hat folgendes geschrieben: | | Danach ruft er Rechteck::Rechteck(const Rechteck&) auf, welches der (ebenfalls automatisch erzeugte) Copy-Ctor ist ist. (korrigiert, tommie-lie hat hier natürlich recht. Innerhalb der Klasse - siehe unten - ist es allerdings tatsächlich der Zuweisungsoperator). |
Nope. 12.2.8:
| Zitat: | The implicitly-defined copy constructor for class X performs a memberwise copy of its subobjects. The order of copying is the same as the order of initialization of bases and members in a user-defined constructor (see 12.6.2). Each subobject is copied in the manner appropriate to its type:
— if the subobject is of class type, the copy constructor for the class is used; |
| STATUS_ACCESS_DENIED hat folgendes geschrieben: | | Foo(const Bar& bla) { m_bar = bla; }in welchem Fall die Instanz für m_bla zwar auch nur einmal erzeugt wird aber per Default-Ctor für Klasse Bla. Hernach wird dann noch zusätzlich Bla& Bla::operator=(const Bla&) aufgerufen um die im Ctor-Body gegebene Zuweisung auszuführen. |
Ach *das* ist für dich "innerhalb der Klasse"? Ok, ja, hier wird operator= aufgerufen.
Och, manchmal ist das ziemlich entspannend, mal nur Unsinn zu reden
| opfer.der.genauigkeit hat folgendes geschrieben: | | Evtl. sollte ich wirklich mal ein C++ Buch in die Hand nehmen und lernen. |
Ja. C++-Beiträge klingen zwar meist immer nach Paragraphenreiterei, aber an sich isses 'ne schöne Sprache, und bei den heutigen Compilern muss man sich auch nicht mehr allzuviel Gedanken darüber machen, was man da überhaupt tut. Du siehst ja, daß mein GCC den Copy-c'tor komplett wegoptimiert, selbst wenn ich die Optimierungen ausschalte.
Wenn weitere Fragen auftauchen, verweise ich mal vorsichtshalber an die [url="http://parashift.com/c++-faq-lite/"]C++-FAQ von Marshall Cline[/url], da stehen auch viele Hinweise zum besseren Stil drin. _________________ Your computer is designed to become slower and more unreliable over time, so you have to upgrade. But if you'd like some false hope, I can tell you how to defragment your disk. - Dilbert
|
|
STATUS_ACCESS_DENIED
Ehemaliges Mitglied
Erhaltene Danke: 1
|
Verfasst: Mi 20.02.08 12:14
| tommie-lie hat folgendes geschrieben: | | Wie? Die Syntax, die auch tatsächlich den operator= benutzt, wäre mindestens zweizeilig. Auch opfer.der.genauigkeit hätte *nicht* den Zuweisungsoperator benutzt, |
Exakt, mindestens zweizeilig. Wie in einer Klasse wo eine Membervariable eines Klassentyps erst im Body des Ctors initialisiert wird. Kann sein, daß es da Optimierungen geben kann, die wären aber implementationsspezifisch. Aber auch das widerspricht schon RAII. Und auch dabei handelt es sich um eine Konvention aufgrund von Erfahrungen.
Habe das schonmal in einer Binary anders gesehen. Muß ich wohl nochmal versuchen den Code zu finden und den Wortlaut mit dem Gefundenen abgleichen.
| tommie-lie hat folgendes geschrieben: | | Was verstehst du unter falsch? Der Standard schreibt exakt vor, was der Default-Copy-c'tor macht, es ist wohldefiniertes verhalten, das nicht kaputt ist. Wenn es "gefährlich" wird, ist entweder dein Compiler kaputt, oder man hat erachtet garantiertes Verhalten als falsch, dann hat man aber den Standard nicht richtig verstanden. |
Jemals eine Klasse erweitert? Jemals Code gehabt wo jemand deine Klasse erweitert hat, der Entwickler sich aber einbildete, daß C++ ja nur ein verbessertes C ist?
Du hast ja recht, wenn der Standard das so oder so sagt. Und zumindest werden solche Standards üblicherweise nur erweitert, nicht aber so geändert, daß es inkompatibel wird. Das Problem bleibt aber, daß die Automatismen in C++ ein paar böse Überraschungen bereithalten, zumal man sich oft eben nicht aussuchen kann wer wann wo am Code bastelt.
Unter falsch verstehe ich in diesem Fall, daß es falsch ist einem Anfänger das Gesamtbild vorzuenthalten. Und die ist meiner Erfahrung gemäß, daß Code sich im Fluß befindet und daher "plötzlich" Überraschungen winken, wenn einer der Entwickler sich auf den Compiler verläßt und der nächste "ja nur eine Membervariable hinzufügt". Nimm's als Praxiserfahrung. Muß nicht auf alle, alles oder jeden zutreffen, aber ich habe es schon mehrfach in verschiedenen Teams erlebt - inklusive automatisch generierter Copy-Ctors für Klassen mit Pointern ... die dann Dank einer Randbedingung im Produkt funktionierten, wo man dann aber den Heisenbug ewig sucht, weil irgendwer eben doch eine Instabilität oder einen Absturz hatte.
| tommie-lie hat folgendes geschrieben: | | Ein Default-c'tor wird nicht erzeugt, sobald man einen eigenen Konstruktor hat (auch wenn der kein Default-c'tor ist). Es ist nicht garantiert, daß eine Klasse einen Default-c'tor besitzt und er wird in diesem Fall auch nicht aufgerufen (weilla ja ga nich da iss ). Was hier (formal) aufgerufen wird, ist der Konstruktor mit den Paramtern (float, float) und anschließend der Copy-c'tor. Mein GCC 4.2 ruft sogar nur den Konstruktor mit (float,float) auf, auch ohne Optimierungen. (Für mich eine Verletzung des Standards, ich sollte der Sache mal nachgehen). |
Verschreiben darf man sich doch noch, oder? Eigentlich sollte die Aussage tatsächlich den (float,float)-ctor enthalten, habe ich aber bei meiner Korrektur übersehen, ist jetzt oben aber korrigiert. Danke für den Hinweis.
Das Wegoptimieren sollte gedeckt sein vom Standard, ist aber ebenso implementationsspezifisch.
| tommie-lie hat folgendes geschrieben: | | STATUS_ACCESS_DENIED hat folgendes geschrieben: | | Danach ruft er Rechteck::Rechteck(const Rechteck&) auf, welches der (ebenfalls automatisch erzeugte) Copy-Ctor ist ist. (korrigiert, tommie-lie hat hier natürlich recht. Innerhalb der Klasse - siehe unten - ist es allerdings tatsächlich der Zuweisungsoperator). |
Nope. 12.2.8:
| Zitat: | The implicitly-defined copy constructor for class X performs a memberwise copy of its subobjects. The order of copying is the same as the order of initialization of bases and members in a user-defined constructor (see 12.6.2). Each subobject is copied in the manner appropriate to its type:
— if the subobject is of class type, the copy constructor for the class is used; |
|
Nope? Ich wüßte nicht, wo meine Aussage etwas gegenteiliges besagt. Siehe zweites Zitat von dir und meine Reaktion (oben). Hätte vielleicht etwas expliziter sein sollen, warum ich meine, daß man sie definieren sollte, wenn man sie haben will und deklarieren aber nicht definieren sollte, wenn nicht. Und zwar meiner Meinung nach immer. Wie gesagt, weniger weil ich dem Compiler nicht vertraue, sondern vielmehr weil ich vielen C++-Entwicklern nicht traue.
Oder war das einfach nur bevor du das gelesen hast, was dich zu folgender Reaktion bewog?:
| tommie-lie hat folgendes geschrieben: | | Ach *das* ist für dich "innerhalb der Klasse"? Ok, ja, hier wird operator= aufgerufen. |
| tommie-lie hat folgendes geschrieben: | | Wenn weitere Fragen auftauchen, verweise ich mal vorsichtshalber an die [url="http://parashift.com/c++-faq-lite/"]C++-FAQ von Marshall Cline[/url], da stehen auch viele Hinweise zum besseren Stil drin. |
Jupp, Scott Meyers Werke zum Effektiveren C++ und Nutzung der STL nicht vergessen. "Modern Code Design" Alexandrescu ist auch ganz schön. Ich bevorzuge ja Bücher, auch wenn man Laptops mittlerweile auch mit aufs Klo nehmen kann.
Paragraphenreiterei ist cool ... ich sag ja immer, ich bin kein Krümelkacker, sondern Pedant
|
|
tommie-lie
Beiträge: 4373
Ubuntu 7.10 "Gutsy Gibbon"
|
Verfasst: Mi 20.02.08 21:41
| STATUS_ACCESS_DENIED hat folgendes geschrieben: | | Das Problem bleibt aber, daß die Automatismen in C++ ein paar böse Überraschungen bereithalten, zumal man sich oft eben nicht aussuchen kann wer wann wo am Code bastelt. |
Hm, Ansichtssache. Ok, wenn einer 'ne Bibliothek schreibt, erwarte ich, daß in der Dokumentation steht, ob der copy-c'tor und operator= eine deep oder eine shallow copy machen. Doxygen ist da ja sehr benutzerfreundlich: wenn da kein copy-c'tor auftaucht, ist's der, der vom Compiler erzeugt wird, und wie der sich verhält weiß ich
| STATUS_ACCESS_DENIED hat folgendes geschrieben: | | Verschreiben darf man sich doch noch, oder? |
Du nicht 
| STATUS_ACCESS_DENIED hat folgendes geschrieben: | | Das Wegoptimieren sollte gedeckt sein vom Standard, ist aber ebenso implementationsspezifisch. |
Haste da mal 'n Paragraph zu? Beim Überfliegen ist mir auch bei den Temporaries nichts verdächtiges aufgefallen. Aber du wirst wohl recht haben, einen so offensichtlichen Fehler würde ich im GCC nicht erwarten.
| STATUS_ACCESS_DENIED hat folgendes geschrieben: | | Oder war das einfach nur bevor du das gelesen hast, was dich zu folgender Reaktion bewog? |
Jupp.
| STATUS_ACCESS_DENIED hat folgendes geschrieben: | | Paragraphenreiterei ist cool ... ich sag ja immer, ich bin kein Krümelkacker, sondern Pedant |
Schreckt manche leider von C++ ab. Schließlich ist es ja auch eine Kusnt, den Standard überhaupt korrekt zu lesen, wenn man sich denn überhaupt mal die Mühe macht und ihn liest. Leider fallen einem ab und zu immer mal C++-Programmierer auf, die nicht wissen, wie sich C++ eigentlich verhalten sollte... _________________ Your computer is designed to become slower and more unreliable over time, so you have to upgrade. But if you'd like some false hope, I can tell you how to defragment your disk. - Dilbert
|
|
|
