Objekte anlegen - ich bin völlig verwirrt!

0xyD

Hallo,

ich bin nun vollends verwirrt und verstehe leider garnicht mehr, wo mein Fehler liegt. Ich habe ein Klasse in welcher ich ein int per setter beschreibe und mit einem getter auslese. In meiner main() möchte ich nun mein Objekt vom Typ meiner Klasse anlegen.

Und hier gehts los:

Ich versteh absolut nicht mehr, WIE ich denn nun ein Objekt korrekt anlege bzw. deklariere.

Ich habe bereits auf mehreren Seiten gesucht und meine zwei C++ Bücher gewälzt, aber nirgends finde ich eine schlüssige Form dessen bzw. teilweise sogar drei verschiedene Möglichkeiten.

Es wäre nett, wenn mir Jemand ganz klipp und klar und einfach erklären könnte, WIE genau ich ein Objekt anlege und damit arbeite. Ich verstehe auch nicht so ganz, WANN und WIE das in C++ mit dem "this" funktioniert, mal lese ich

this->xxx

und mal nur

*this

Ich arbeite im Moment mit der Umgebung code::blocks und dort bekomme ich folgende Fehlermeldung beim Kompilieren meiner Klasse:

obj\Debug\main.o||In function `main':|
main.cpp|8|undefined reference to `myTestClass::myTestClass()'|
main.cpp|10|undefined reference to `myTestClass::setAnz(int)'|
main.cpp|12|undefined reference to `myTestClass::getAnz()'|
||=== Build finished: 3 errors, 0 warnings ===|

Hier meine Klassendateien und meine main Datei:

myTestClass.h

#pragma once
#include <iostream>

using namespace std;

class myTestClass {

    public:
        myTestClass(void);
        ~myTestClass(void);
        void setAnz(int anz);
        int getAnz();

    private:
        int anz;
};

myTestClass.cpp

#include <iostream>
#include "myTestClass.h"

using namespace std;

myTestClass::myTestClass(void);

myTestClass::~myTestClass(void);

void myTestClass::setAnz(int anz) {
    this->anz = anz;
}

int myTestClass::getAnz() {
    return this->anz;
}

main.cpp

#include <iostream>
#include "myTestClass.h"

using namespace std;

int main(void) {

    myTestClass *myObj = new myTestClass();

    myObj->setAnz(10);

    cout << myObj->getAnz() << endl;

    return 0;
}

Was läuft hier falsch? Wo ist mein Fehler??

Gruss

0xyD

Definiere die Funktionen, bevor du sie aufrufst.

myTestClass::myTestClass(void)
{
	;
}

myTestClass::~myTestClass(void)
{
	;
}

Und this ist ein Zeiger auf die Klasse. Also this->a ist gleich mit (*this).a

0xyD

Ok, also ich hatte die {} - Klammern vergessen dabei, das stimmt, aber es sind ja keine Funktionen, sondern das sind Kostruktor und Destruktor meiner Klasse.

Aber auch nachdem ich es jetzt verbessert habe:

#include <iostream>
#include "myTestClass.h"

using namespace std;

myTestClass::myTestClass(void) { }

myTestClass::~myTestClass(void) { }

void myTestClass::setAnz(int anz) {
    this->anz = anz;
}

int myTestClass::getAnz() {
    return this->anz;
}

kommt immer noch der selbe Fehler:

main.cpp|8|undefined reference to `myTestClass::myTestClass()'|

0xyD

So und gerade habe ich das Projekt unter Eclipse für C/C++ erstellt und er kompiliert es einwandfrei ohne Fehler.

oO

Es ist jetzt genau das selbe Projekt, 1:1 übernommen!

Ich versteh nicht was hier los ist....

unskilled

0xyD schrieb:

#include "myTestClass.h"

#include <iostream>

using namespace std;

myTestClass::myTestClass(void) { }

myTestClass::~myTestClass(void) { } //void als parameter in c++ hinzuschreiben wird vieler orts als schlechter stil angesehen

void myTestClass::setAnz(int anz) {
    this->anz = anz; //wieso nimmste nicht _anz? dann kannste einfach anz = _anz schreiben
}

int myTestClass::getAnz() { //diese funktion solltest du als const deklarieren und definieren - häufig werden so triviale getter (und setter) auch gleich im header definiert - weil sie dann automatisch geinlined werden
    return this->anz; //wieso ein this-> ? ist hier überflüssig
}

Außerdem:
using namespace std; sollte man niemals in headern nutzen...
und warum includierst du iostream im test-class header? selbst im source brauchst du es nicht?!

und als letzten pkt:
myTestClass *myObj = new myTestClass();
wieso schlägst du dich hier mit pointern rum, wenn es doch auch ganz bequem geht:
myTestClass myObj;
dementsprechend erfolg der zugriff auf Member über den . operator :
myObj.setBla(123456);

deine einrückung und namensgebung ist zwar geschmackssache, aber ich find sie hässlich ^^

also komme ich auf so was in etwa:

/*main.cpp*/
#include <iostream>
#include "test_class.h"

int main()
{
Ttest test; //dadurch entfällt das delete am ende (was du eh vergessen hattest) -> zu JEDEM new gehört ein delete, zu jeden new[] ein delete[]
test.setAnz(12);
std::cout << test.getAnz() << std::endl; //mit using namespace würden die beiden male std:: natürlich entfallen - ist auch wieder geschmackssache
//return 0; brauchst du nicht - also normalerweise muss jede funktion auch das zurückgeben, was sie sollte - aber bei der main-fkt erledigt das der compiler für uns
}

/*test_class.h*/
#if _MSC_VER >= 1020
# pragma once //pragma once ist noch nicht immer da...
#endif //beim msvc ist es ab buildnr. 1020 verfügbar...

#ifndef TEST_H_INCLUDED //include-guards
#define TEST_H_INCLUDED

class Ttest
{
private:
 int anz;
public:
 Ttest();
 ~Ttest();

 void SetAnz(int _anz) {anz = _anz;} //erspart das this und ist weniger zu tippen (man sollte aber aufpassen, dass man immer nur einen unterstrich verwendet, weil alles mit 2 unterstrichen am anfang für die IDE/den compiler reserviert ist
 int GetAnz() const {return anz;} //funktionen, die das objekt nicht verändern, sollten als const deklariert sein...
};

#endif //#ifndef TEST_H_INCLUDED

/*test_class.cpp*/

#include "test_class.h"

Ttest::Ttest()
: anz(0) //initialisierungsliste
{}

Ttest::~Ttest()
{}

ich hoffe, es hat dir geholfen und du liest es dir auch durch ^^

bb

PS: ok - damit hätte sich das #ifdef vor #pragma once erledigt... weiß nicht, wie es in code::blocks ist - aber das ist ja nun auch eher nebensächlich ^^

0xyD

Noch ein Nachtrag:

Wenn ich den selben Inhalt aller drei Dateien kopiere und in einem ganz normalen Editor einfüge, diese Dateien speichere und dann von Hand per Konsole und dem g++ Compiler kompiliere, dann funktioniert es ebenfalls komplett OHNE Fehler!

Es wird eine saubere .exe kompiliert die auch ausgeführt werden kann.

Kann es sein, dass in code::blocks ein Bug vorhanden ist??

0xyD

Hi unskilled,

ich probiere das gleich aus was Du geschrieben hast. Danke!!

Mein letzter Beitrag hatte sich mit Deinem überschnitten.

Gruss

0xyD

Gut,

ich habe das Ganze jetzt abgeändert in die Art und Weise, wie Du es geschrieben hast.

main.cpp

#include <iostream>
#include "myTestClass.h"

using namespace std;

int main(void) {

    myTestClass myObj;

    myObj.setAnz(10);

    cout << myObj.getAnz() << endl;

    return 0;
}

myTestClass.h

#ifndef TEST_H_INCLUDED
#define TEST_H_INCLUDED

class myTestClass {

    public:
        myTestClass();
        ~myTestClass();
        void setAnz(int _anz);
        const int getAnz();

    private:
        int anz;
};

#endif

myTestClass.cpp

#include "myTestClass.h"

myTestClass::myTestClass() : anz(0) {

}

myTestClass::~myTestClass() {

}

void myTestClass::setAnz(int _anz) {
    anz = _anz;
}

const int myTestClass::getAnz() {
    return anz;
}

Und der Fehler bleibt immer noch exakt der selbe, wiederum lässt es sich fehlerfrei unter Eclipse C/C++ kompilieren.

unskilled

also erst mal was, was nichts mit dem fehler zu tun hat:

const int myTestClass::getAnz() {
    return anz;
}

hier ist nicht die funktion als const gemarkt, sondern der rückgabewert - ist aber relativ sinnlos, weil es keinen unterschied zwischen so etwas gibt:

const int bla{return 3;}
int bla2 [return 2;}

//richtig wäre:
rückgabewert klassenname::funktionsname() const {
  return anz;
}

(und trotzdem würde ich so einfach getter und setter in den header schreiben )

Zu deinem eigentlichen Fehler:
Kann es sein, dass du die Datei wo anders liegen hast, als die main? (apropos: int main(void) - auch hier gilt die Sache mit dem void als fkt-parameter)
Falls ja, kann es sein, dass du der IDE noch dieses Verzeichnis "bekannt machen" müsstest... obwohl er dir dann eher sagen würde, dass er die datei nicht includen kann ><

also keine ahnung: anscheind konnte er die datei includen, also sollte er auch die deklaration des Konstruktors haben...

aber du hast wirklich alles haargenau so, wie du es gepostet hast?

0xyD

LOL

Ok, ich habe das Problem gelöst nach Deinem letzten Hinweis.

Also vorab:

Das mit dem "const" habe ich verstanden, habs geändert. Und das mit den gettern und settern im Header, na ja, ich habs gerne strikt so aufgeteilt. Aber Jedem das seine.

So, nun zum Kernproblem:

Ja, es lag tatsächlich daran, dass meine "myTestClass.cpp" nicht im Bulid Target enthalten war.

In code::blocks sieht die Struktur meines Projekts so aus:

Projekt
---|

---	-> Sources
---	---
---	---
---
---	-> Headers
---
---	-> myTestClass.h

Ich habe mal bisschen rumprobiert und dabei mit der rechten Maustaste auf den Projekt HomeOrdner und dann auf den Menüeintrag: "Properties". Dort dann auf die Reiterkarte "Build Targets".

Und dort findet sich ganz unten ein Fenster mit der Überschrift: "Build Target Files:".

main.cpp und myTestClass.h waren mit Häkchen versehen, myTestClass.cpp war nicht aktiviert. Nachdem ich diese Datei auch aktiviert habe (musste ich für Debug und Release jeweils machen) ließ sich das Projekt komplett fehlerfrei kompilieren und die fertige .exe ausführen.

Also in diesem Sinne schonmal viiiielen Dank für Deine Hilfe!!!

Was mich aber ein wenig sauer macht ist die Tatsache, dass es wünschenswert wäre, dass die Fehlermeldung ein wenig mehr darüber aussagt, was da schief läuft (denn ich habe der Fehlermeldung entnommen, dass etwas mit meinem Programmcode nicht stimmt und nicht, dass eine falsche Konfiguration der Entwicklungsumgebung daran Schuld ist) oder, dass zumindest eine Funktion implementiert ist, die dafür sorgt, dass JEDE neue Datei (egal ob Header oder Source) sofort nach dem Anlegen mit im Build Target aktiviert ist.

Ich kann mir gut vorstellen dass es Leute gibt, die mehr als einen Tag damit verbringen, um so einem, im Grunde simplen, Problem auf die Spur zu kommen!

Dravere

Sag das mal den Code::Blocks Entwicklern und nicht uns. Ich bin absolut einverstanden mit deiner Kritik. Ist eines der Features, welches mir am meisten stört bei Code::Blocks.
Beim MSVS kliche ich auf "Add New File", bekomme den Wizard, wo ich das File auswähle (1 Click) den Namen direkt unten einfüge und Enter drücke. Fertig, das File wird auch kompiliert und verwendet.
In Code::Blocks braucht man dagegen im Vergleich eine halbe Ewigkeit und es ist sogar Fehleranfällig, bis man endlich ein weiteres File dem Projekt dazugefügt hat. Da kann man durch bis zu 3 Wizard Pages durchgehen und benötigt bis zu 10 Clicks, bis man endlich das Ding hat. Und die Endungen werden teilweise nicht mal automatisch dazugefügt. Grauenhaft ...

Grüssli

0xyD

Ich sehe das ähnlich. Ok, ich bins auch gewöhnt, das Ganze im Unterricht mit MSVS zu machen aber das bekomme ich nicht fehlerfrei bei mir zum laufen.

Darum nutze ich auch code::blocks (auch erst seit kurzem und bisher gefällts mir ganz gut) und alternativ Eclipse C/C++.

Ansich auch kein Problem, aber wenns dann an solchen Sachen hakt, dann ist da noch einiges verbesserungsbedürftig. Ich überlege, ob ich die Code::Blocks Entwickler anschreibe und den Punkt mal anspreche.

Noch eine Frage zu der Sache mit "this" vond er Vorseite.

unskilled, Du hattest ja geschrieben, dass ich auf "this" verzichten kann, und statt dessen einfach nur den Namen zuweise bzw. zurückgebe.

Meine Fragen dazu:

1. Hat der Unterstrich, in meinem konkreten Beispiel

anz = _anz

, etwas zu bedeuten? Ist das so eine Art andere Schreibweise für die "this"-Variante? Oder ist der Unterstrich nur als optisch sichtbarer Unterschied zu "anz" ohne Unterstrich da?

2. Warum kann ich auf "this" überhaupt komplett verzichten? Ok Ja, ich gebe zu, dass ich eher aus der Java Ecke stamme und dort ist es geläufig, in Klassen mit z.B.:

this.xyz = xyz

zu arbeiten. this dient ja als Referenz auf das eigene Objekt.

Warum ist das hier in C++ zwar auch möglich aber unnötig??

Bindet die Zuweisung über this den Wert der Variablen dann trotzdem an mein Objekt? Und wenn Ja, warum??

Wäre dankbar für ein wenig Klarheit in dieser Sache.

0xyD

Ums noch etwas konkreter zu machen:

Wo genau liegen jetzt die Unterschiede zwischen:

void myTestClass::setAnz(int anz) {
    this->anz = anz;
}

int myTestClass::getAnz() const {
    return this->anz;
}

und

void myTestClass::setAnz(int _anz) {
    anz = _anz;
}

int myTestClass::getAnz() const {
    return anz;
}

?

Dravere

Ist genau das gleiche, wie in Java übrigens auch.

Der Unterstrich dient nur zur optischen Unterscheidung und auch für den Compiler, falls der Parameter und die Membervariable gleich heissen. Oft werden auch den Membervariablen irgendwelche Postfixe oder Prefixe gegeben. Ich selber mach zum Beispiel ein m_ vor jeder Membervariable. Das ganze ist aber ziemlich umstritten und gilt im allgemeinen als Geschmacksache.

Unterschiedliche Vorgehensweisen:

// Deklaration:
int m_var; // (1)
int _var;  // (2)
int var_;  // (3)
int var_m; // (4)
int var;   // (5)

// Zugriff:
void Class::foo(int var)
{
  m_var = var;     // (1)
  _var = var;      // (2)
  var_ = var;      // (3)
  var_m = var;     // (4)
  this->var = var; // (5.1) <- Nur hier ist das this wirklich nötig,
                   //          weil die Variablen den gleichen Namen besitzen.
                   //          var ist hier der Übergabeparameter.
                   //          this->var die Membervariable.
}

// Oder
void Class::foo(int _var, int var_)
{
  var = _var; // (5.2)
  var = var_; // (5.3)
}

Gibt wohl noch mehr Kombinationen. Aber nur das ist mir bisher alles unter die Augen gekommen.

Grüssli

0xyD

Hi,

Ich denke, ich stand grade bisschen auf dem Schlauch bin heute auch nicht so ganz beisammen beim Programmieren.

Aber jetzt wirds mir auch deutlich klar, dass meine Funktion/Methode ja bei der Zuweisung unterscheiden muss und dass ich dann "this" verwenden "muss", wenn ich beiden Variablen den selben Namen gebe sonst würde ich mir den selben Wert einfach nochmals zuweisen.

Danke für die Beschreibung!

Gruss

drakon

Ich selber mach zum Beispiel ein m_ vor jeder Membervariable. Das ganze ist aber ziemlich umstritten und gilt im allgemeinen als Geschmacksache.

Ich mache auch ein m_ davor und zwar aus dem einfachen Grund, dass ich dann bei der Codevervollständigung direkt zu meinem Variablen komme und ich mich nicht zuerst durch tausende von ähnlich klingenden Funktionen diverser API's zu wühlen.

unskilled

drakon schrieb:

Ich selber mach zum Beispiel ein m_ vor jeder Membervariable. Das ganze ist aber ziemlich umstritten und gilt im allgemeinen als Geschmacksache.

Ich mache auch ein m_ davor und zwar aus dem einfachen Grund, dass ich dann bei der Codevervollständigung direkt zu meinem Variablen komme und ich mich nicht zuerst durch tausende von ähnlich klingenden Funktionen diverser API's zu wühlen.

Na wenn das mal kein Grund ist, es immer so zu machen - ich meine... Sonst könnte es ja vorkommen, dass man mal 2 Buchstaben eintippen müsste, oder - Gott bewahre - so gar 3... Und das ganze auch noch direkt hintereinander... Ab jetzt werde ich meine Membervariablen auch immer so verunstalten *scnr*
Naja - mal im Ernst: Ich finds hässlich und alles andere als nützlich - aber jedem das Seine...

bb

Dravere

@drakon, unskilled und jeder andere, der meint er müsse noch einen Kommentar dazu abgeben:
Lasst es endlich ruhen! Es gab schon viel zu viele Diskussionen darüber. Man muss sich da nicht rechtfertigen, es hat keinen Sinn. Gegen das Argument von drakon könnte man zum Beispiel auch sagen, das ein this-> diese Filterung automatisch durchführt, usw. usf.
Hört mit dem Unsinn auf. Ich habe doch geschrieben, dass es Geschmacksache ist, also lasst es dabei bleiben ... Es ging ja nur um die Erklärung, was das sein soll.

Grüssli

0xyD

Hi,

im Ansatz zu gestern hätte ich noch zwei weitere Fragen.

Erstmal was zum Kopierkonstruktor:

Ich habe hier in meinem Skript folgendes Beispiel:

class Auto {
   public:
      Auto(void); //Standardkonstruktor
      Auto(const Auto& mercedes);
}

Was hat es mit dem Kopierkonstruktor in diesem Beispiel auf sich?

Ich versteh die zugehörige Aussage nicht, dass der Kopierkonstruktor dann wichtig ist, wenn es um Call-By-Value geht und um die richtige Referenzierung von Objekten in Rückgabewerten.

Der nächste Punkt ist meine Frage zu den get- und set-Methoden/Funktionen.

Ich finde das andere Skript leider nicht mehr und gerade auch nichts passendes im Netz, aber ich weiss noch aus dem Gedächtnis, dass es da so einen Fallstrick gab, was di Zuweisung einer Variablen in einem setter betrifft.

Ich nehme mal das Beispiel von gestern:

void myTestClass::setAnz(int _anz) {
    anz = _anz;
}

Um zu gewährleisten, dass meine Objektvariable den Wert auch wirklich behält und dieser nicht überschrieben werden kann, gab es die Vorgehensweise, dass man (und nu kommt der Punkt, an dem ich nicht mehr weiss, was genau man da verwendet hat) entweder mit

memcpy

oder

strcpy

arbeitet.

Also sowas hier:

void myTestClass::setAnz(int _anz) {
    memcpy(anz = _anz);
}

oder

void myTestClass::setAnz(int _anz) {
    strcpy(anz = _anz);
}

Könnte mir dazu Jemand auf die Sprünge helfen bzw. allgemein erklären, was da sichergestellt werden soll beim setter meines Objekts?

Sorry wenn ich da jetzt bisschen was mische, ich weiss es wirklich nur noch ganz grob aus dem Gedächtnis. Ich hoffe mal, dass es verständlich ist, was ich damit meine.

Gruss

drakon

@Dravere:
Ich habe nicht darüber diskutiert. Ich habe lediglich gesagt, wie ich es mache und warum. Ob man das jetzt gut findet, oder andere Möglichkeiten hat ist mir schlussendlich egal. Darum habe ich auch auf unskilled's Antwort nicht geantwortet. Weils mir einfach zu blöd ist über sowas zu diskutieren.

@0xyD
1. Bitte sag nicht Skript. Das ist wie eine Dolchstoss. Sag Source, Code, oder sonst was, aber bitte nicht Skript zu C++ Code.

Also ich denke mal, dass du ein wenig ein durcheinander hast.

Das Problem ist folgendes. Wenn du eine Klasse hast, die gewisse Resourcen anfordert, die auch wieder freigegeben werden müssen (von der Klasse selbst), dann musst du beim Kopieren und Zuweisen aufpassen.

Beispiel:

class myArray
{
  myArray ( int n )
  :
  data ( new int[n] ), // fordere n ints an und
                      // lasse data auf den Anfang zeigen
  anzahl ( n )
  {                   
  }

  ~myArray ()
  {
    delete[] data; // myArray wird zerstört, 
                   // also auch Speicher wieder freigeben
  }

  int* data;
  int anzahl;
};

Schön und gut. Da könnte man meinen, dass das so in Ordnung ist, da ich ja den Speicher am Ende wieder freigebe.

Nun. Was passiert, da jetzt, wenn ich ein myArray mit dem Objekt Initialisiere?
(Kopierkonstruktor wird aufgerufen).

void some_function ()
{
  myArray ar1 ( 2 );
  myArray ar2 ( ar1 );
..

Da ich keinen Kopierkonstruktor implementiert hat, macht der Compiler einen für mich. Ich sage danke und code mal weiter.

..
//mache tolle Sachen mit ar1 und ar2
} // ar1 und ar2 werden zerstört.

Ung genau bei dem letzten } passierts. Du bekommst einen Speicherzugrifsfehler. Doch warum?

Schauen wir mal das an, was der Compiler für unseren Kopierkonstruktor erstellt hat.

class myArray
{
...
   myArray ( const myArray & other )
   :
   data ( other.data ),
   anzahl ( other.anzahl)
   {
   }
...
};

Hmm. Da fehlt doch irgendetwas? Genau da fehlt ein new. Das heisst, wenn jetzt ar1 zerstört wird, wird korrekterweise in dessen Destruktor delete[] data gemacht.
Nun kommt er zu ar2 und macht es auch wieder. Nun haben wir aber 1 new und 2 delete's gehabt. Und das kann ja gar nicht funktionieren.

Das führt uns zu der Annahme, dass der Compiler generierte Kopierkonstruktor falsch ist. Ist er auch.

Dabei sollte es ja in etwa das hier sein:

class myArray
{
...
   myArray ( const myArray & other )
   :
   anzahl ( other.anzahl ),
   data ( new int [other.anzahl] )
   {
      // kopiere alle Elemente von other.data zu data
   }
...
};

Der Speicher muss neu alloziert werden und alle Elemente müssen kopiert werden. Dann hat man eine richtige Kopie.

Ergänzenderweise sei hier noch die Strategie der Referenzzählens erwähnt, wo man das eben nicht macht. Dort wird lediglich gezählt, wieviele Objekte auf den Speicher referenzieren und der Speicher wird erst freigegeben, wenn alle Objekte zerstört woden sind.

Du verwechselt, nehme ich mal an Getter und Setter mit dem Zuweisungoperator, der wahrscheinlich nach dem aussieht, was du im Kopf hast.

Nun, um das Beispiel oben nochmal aufzugreifen. Wir wissen jetzt ja, wie man ein Objekt richtig durch Kopie erzeugt, aber was ist den nun, wenn man es durch Zuweisung ändern will?

Hier gibt es viele Strategien, wie man das machen könnte. Die wohl am meisten anzutrefende nennt sich Copy&Swap.

class myArray
{
...
 myArray & operator = ( const myArray & other )
 {
  myArray ( other ).swap ( *this );
  return *this;
 }

 myArray & swap ( myArray & other )
 {
  std::swap ( data , other.data );
  std::swap ( anzahl , other.anzahl );
  return *this;
 }
...
};

Der Trick dahinter ist, dass durch die Erstellung eines temporären Objektes und dann durch die schlichte Austauschung der Variablen sich nicht um die Erstellung + Zerstörung von Speicher kümmern muss, da das alles durch das temporäre Objekt geschiecht (Konstruktor erstellt den Speicher, Destruktor gibt ihn wieder frei und zwischendurch wurden die Inhalte der Variablen vertauscht.)
(std::swap macht nichts anderes, als den Inhalt des ersten Argumentes mit dem Inhalt des zweiten Argumentes zu vertauschen.)

Getter und Setter sind trivial und ergeben keine Probleme.

class foo
{
 void SetIrgendwas ( int i ) { irgendwas = i; }
 int GetIrgenwas () const { return irgendwas; } // Auf konst achten, da es das Objekt ja nicht verändert.
 int irgendwas;
};

Da gibt es eigentlich nur 2 Sachen, wo man drauf achten muss:
1. Das man keinen Zeiger/ Referenzen zurückgibt ( zuminest keine Zeiger auf nicht-konstante Objekte)
2. Bei dem Setter sollte man auch keinen nackten Speicher oder so zuweisen, da ansonten alter verloren geht. ( Das war wahrscheinlich auch das, was du meintest)

kleines Beispiel:

class myArray
{
...
 SetData ( int* new_data , int n )
 {
  data = new_data; // data wird zuerst nicht zerstört und verschwindet 
                   // inst Nirvana.. 
  anzahl = n;
 }
...
};

Das kann ein Problem sein, muss es aber nicht. Heutzutage muss man sich mit solchen Sachen in C++ kaum noch rumschlagen, da man gleich entweder ein RAII Objekt programmiert, oder ansonsten nur RAII Objekte vorliegen hat. ( z.B std::vector, std::string usw. )

So. Ich glaube ich habe ein wenig weit ausgeholt..

Noch kleiner Link zu smartpointer, auf die ich jetzt nicht mehr eingehe.

http://en.wikipedia.org/wiki/Smart_pointer

Achja, um es nochmal ganz klar deutlich zu machen:

Arbeite nicht mit strcpy, memcpy (und anderen C-Funktionen) ausser du weisst ganz genau, was du machst!
Benutz die Standardbibliothek von C++ und die dazugehörigen Container und du wirst viel glücklicher sein, ausser du magst es Nächte mit deinem Debugger zu verbringen und ein Memoryleak zu suchen.

0xyD

@drakon

Hi,

ich habe Deinen Beitrag erst jetzt gelesen, hatte keine Zeit vorher.

Danke für Deine intensiven Ausführungen ich muss das erstmal bisschen verdauen weil ich nicht alles ganz verstanden habe.

Ich melde mich sicherlich demnächst mir Fragen dazu!

Gruss

0xyD