Setproperty und Getproperty...

Hi,

ich habe ursprünglich C# programmiert und versuche nun auf C++ umzusteigen. Ich habe aber noch eine grundsätzliche Frage:

In C# habe ich einfach eine Property definiert und diese dann nach belieben aufgerufen und verändert. In meinem C++ Buch ist oft die Rede von Setproperty(...) und Getproperty Funktionen. Wieso muss ich dafür in C++ extra Funktionen schreiben? Ist es unschön/ unsicher oder so, wenn ich die Property direkt ändere???

lg

HighLigerBiMBam

Weil es dies nicht von Haus aus gibt. Mach doch mal ein Codebeispiel/Vergleich, dann können wir dir genauer helfen.

Tachyon

Properties verbinden normalerweise ein Attribut einer Klasse mit einer Methode (wobei das Optional ist). Wenn Du z.B. ein GUI-Element hast, und dort die Property setColor , dann wird nicht nur das Attribut auf die gegebene Farbe gesetzt, sondern es wird auch der nötige Code zum Ändern der Farbe am Bildschirm ausgeführt. Wenn Du einfach nur public Attribute hast, dann geht das so nicht. Also: Setter/Getter-Methoden bereitsstellen. Das bietet auch noch andere Vorteile.

Wenn ich mal genauer drüber nachdenke, gibt es das ja auch bei C# mit den get- set Accessoren...

Kann ich folgendes so machen oder birgt das Nachteile?:

class A
{
public:
    A() {}
    string property;
};

class B
{
public:
    void method()
    {
        A instance = A();
        instance.property = "DarfIchDas?";
    }
};

Wofür brauche ich dann die Setproperty() und die Getproperty() Methoden?

HighLigerBiMBam

Weil man über get/set-Methoden Grenzwerte abfragen und abfangen kann z.B.. Ja man kann mit dem .-Operator auf public member zugreifen. Private Member entsprechen einem korrekten objektorientieren Ansatz.

SeppJ

Das darf man so machen. Der Nachteil ist, dass dies nicht so tolles Design ist. Das Designprinzip das du verletzt nennt sich Kapselung. Muss man sich nicht dran halten, hat aber bei komplizierten Problemen einige Vorteile.

Aber das wird's doch wohl auch bei C# geben?

Nexus

Nachteile sind halt die üblichen: Man kann den Zugriff nicht nachverfolgen, es gibt mehr Fehlermöglichkeiten (aus Versehen geändert), man kann nicht nachträglich die Implementierung ändern, ...

class A;
class B
{
private:
    A* a;
public:
    void SetA(const A*& aNew)
    {
	    a= aNew; //Error
    }
    const A& GetA() const
    {
	    return *a;
    }

};

Wie würden die get, set Methoden für obiges Beispiel aussehen? Beim Set gibt es einen Fehler: "const A * kann nicht in A* konvertiert werden".

Das würde wohl so aussehen, aber ob das ganze Sinn macht?

class A;

class B
{
    private:
        A* a;

    public:
        void SetA(A* aNew)
        {
            a = aNew;
        }
        A* GetA() const
        {
            return a;
        }
};

Wieso hattest du call-by-reference bei der set-Methode verwendet?

lg

Wieso sollte es keinen Sinn machen? Der Pointer geht auf eine abstrakte Klasse, die per get und set aufgerufen wird. ISt das untypisch?

DocShoe

Hier treffen Welten aufeinander. C# verwendet eine Speicherverwaltung mit Garbage Collection, in C++ gibt´s das nicht. In C# werden Objekte mit new angelegt, in C++ sollte das die Ausnahme sein, wenn dynamischer Speicher benötigt wird bietet die STL/TR1/boost deutlich bessere Möglichkeiten als die Verwendung von Rohzeigern.
Du solltest dir zunächst einmal darüber klar werden, wie C++ Speichermanagement funktioniert und welche Arten der Parameterübergabe in C++ existieren (Gugelmoser hat das Thema ja bereits angeschnitten).
Am besten versuchst du das, was du in C# gelernt hast, zu vergessen und beginnst mit C++ von vorn. Syntaktisch ähneln sich die Sprachen zwar sehr, aber tatsächlich unterscheiden sie sich stark und die Programmierkonzepte sind nicht 1:1 übertragbar.

Edit:
Hab gerade erst gesehen, dass A eine Abstrakte Klasse sein soll. Dann macht es natürlich Sinn, Zeiger zu verwenden. Aus dem Design sollte allerdings hervorgehen, wer Besitzer des mit new angelegten Objekts ist, damit er es wieder abräumen kann, falls es nicht mehr benötigt wird. Wie gesagt, in C++ gibt es keine Garbage Collection und dynamisch erzeugte Objekte werden nicht automatisch wieder abgeräumt.