Abgrenzung privater Member

hustbaer

Es gibt IIRC irgendeine Möglichkeit IntelliSense dazu zu bringen gewisse Dinge nicht anzuzeigen. Leider weiss ich nicht auswendig wie es geht
Es ist möglich dass man dazu Einträge in einem bestimmten File machen muss - das wäre dann weniger praktikabel.
Wenn es so ginge dass man einfach einen bestimmten Tag in ein Kommentar schreibt, oder ein #pragma oder ähnliches setzt, dann fände ich das eine Möglichkeit über die man durchaus nachdenken könnte.

Vor allem wenn man an irgendwelchen Libraries arbeitet die dann mehrere Leute verwenden, denn übersichtlicher ist es IMO schon wenn man gleich nur die public/protected Teile sieht. Lästig wird es dagegen dann wenn man selbst Änderungen an diesen Klassen durchführt, denn man selbst bekommt die Vorschläge von IntelliSense ja dann auch nichtmehr.

drakon

hustbaer schrieb:

Es gibt IIRC irgendeine Möglichkeit IntelliSense dazu zu bringen gewisse Dinge nicht anzuzeigen. Leider weiss ich nicht auswendig wie es geht

Ich denke einmal nicht. Aber dafür kannst du dir ja VA holen. - Dort kannst du glaube ich auch gewisse Sachen filtern.

Wie wärs, die private Methoden einfach in nen anonymen namespace zu stecken, falls sie nicht all zu viele member brauchen.

hustbaer

drakon schrieb:

hustbaer schrieb:

Es gibt IIRC irgendeine Möglichkeit IntelliSense dazu zu bringen gewisse Dinge nicht anzuzeigen. Leider weiss ich nicht auswendig wie es geht

Ich denke einmal nicht. Aber dafür kannst du dir ja VA holen. - Dort kannst du glaube ich auch gewisse Sachen filtern.

Irgendeine Studio Version hat zumindest mal von den MFC Klassen die privaten Member ausgeblendet. Kann aber auch sein dass das hardcoded war/ist.

Nexus

Okay. Mal eine etwas andere Frage: Implementiert ihr Funktionen, die die Klasse in ihrer Arbeitsweise unterstützen und möglicherweise von Memberfunktionen aufgerufen werden, aber keinen direkten Zugriff auf Membervariablen haben müssen, immer als freie Funktionen?

Also nach dem Prinzip: möglichst nur das als Memberfunktion, was auch wirklich nötig ist?

life

Du meinst so?

namespace WebBrowserStuff {
    class WebBrowser {...};
    void clearBrowser(WebBrowser& wb);
    ...
}

drakon

Ich eigentlich nicht. Wenn ich die Funktion möglicherweise irgendwo anders brauche kann, dann probiere ich die schon allgemeingültig zu abstrahieren, aber wenn es dann auf das hinausläuft, dass man alle Funktionen auslagert und mit einem Zeiger/Referenz auf das Objekt übergibt, dann sind wir eigentlich wieder bei C angelangt.

DEvent

volkard schrieb:

Nexus schrieb:

Wie macht ihr das? Für jede kleine Klasse das Pimpl-Idiom einzusetzen finde ich übertrieben, obwohl es halt schon die Schnittstelle sauber hält.

die privaten sachen sind eh nicht teil der schnittstelle, also wozu pimpeln?

Das erklaere mir mal wieso ich jedesmal das gesammte Projekt neu kompilieren muss, wenn ich an einem private-Member was veraendere?

volkard

die schnittstelle ist das, was die anderen programmierer über deine klasse wissen müssen, um sie benutzen zu können. also die public-sachen (gegebenenfalls noch ein wenig protected).
die privaten vars gehören nicht zur schnittstelle, denn die kannst du heimlich ändern, ohne den anderen programmieren eine mail schreiben zu müssen, in der du um verzeihung bittest, daß du so spät im projet was änderst und sie diese änderung berücksichtigen müssen.
was das mit dem neucompilieren zu tun hat, weiß ich nicht.

Nexus

drakon schrieb:

Ich eigentlich nicht. Wenn ich die Funktion möglicherweise irgendwo anders brauche kann, dann probiere ich die schon allgemeingültig zu abstrahieren, aber wenn es dann auf das hinausläuft, dass man alle Funktionen auslagert und mit einem Zeiger/Referenz auf das Objekt übergibt, dann sind wir eigentlich wieder bei C angelangt.

Hm ja, das schon.

Ich habe nur momentan in einer Klasse so etwas:

public:
    void DoSomething(MyClass& Obj);
private:
    void DoALittleBitMore(MyClass& Obj);
    void DoAnythingElse(MyClass& Obj);

Die privaten Methoden werden dann von der öffentlichen DoSomething() aufgerufen. Sie ändern aber nichts an den Membern, sondern nur an der übergebenen MyClass -Referenz. So könnte ich die beiden Memberfunktionen auch als freie Funktionen implementieren, aber irgendwie scheint es mir so besser, da sie logisch auch zur Klasse gehören...

Tachyon

Nexus schrieb:

[...]Sie ändern aber nichts an den Membern [...] So könnte ich die beiden Memberfunktionen auch als freie Funktionen implementieren[...]

wie gesagt

übrigens schrieb:

Wie wärs, die private Methoden einfach in nen anonymen namespace zu stecken, falls sie nicht all zu viele member brauchen.

dann brauchst du dir auch keine gedanken machen, dass sie außerhalb falsch verwendet werden.
Wenn du sie als freie Funktionen machst auf die jeder zugreifen kann, dann hast du an der compilezeit ja garnix gewonnen.

volkard schrieb:

die privaten vars gehören nicht zur schnittstelle, denn die kannst du heimlich ändern, ohne den anderen programmieren eine mail schreiben zu müssen, in der du um verzeihung bittest, daß du so spät im projet was änderst und sie diese änderung berücksichtigen müssen.
was das mit dem neucompilieren zu tun hat, weiß ich nicht.

Wenn du ein größeres Projekt hast (noch größer ) und eine Klasse (z.B. Logging, Scenegraph...) die an vielen Stellen includiert wird und du änderst jetzt nur einen Parameter einer privaten Methode und darfst jetzt wieder 1000 Dateien 10 minuten lang kompilieren, dann weiß du was das mit compilezeit zu tun hat.

Nexus schrieb:

Okay. Mal eine etwas andere Frage: Implementiert ihr Funktionen, die die Klasse in ihrer Arbeitsweise unterstützen und möglicherweise von Memberfunktionen aufgerufen werden, aber keinen direkten Zugriff auf Membervariablen haben müssen, immer als freie Funktionen?

Also nach dem Prinzip: möglichst nur das als Memberfunktion, was auch wirklich nötig ist?

Also eigentlich: ja. Und diese freien Funktionen kommen dann nach Möglichkeit in ein eigenes Modul. Es gibt einfach prozeduale Bestandteile. Für etwas wie kreuzprodukt(vec a, vec b) macht es keinen Sinn, eine Klasse zu schreiben.

Nenne mal ein Beispiel. Also mir ist sowas eigentlich bei vernünftigem Design (wo ich sagen muss, dass das nicht immer der Fall ist ) nicht unter gekommen.

Nexus

Das mit dem anonymen Namensraum wäre gar nicht nötig, da die Funktionen gerade in den CPP-Dateien deklariert und definiert würden. Man sieht also rein gar nichts von aussen.

ProgChild, eigentlich mache ich das tendenziell auch so, aber vielleicht gibts da ja ein guter Grund dagegen. Bei mir habe ich irgendwie das Gefühl, es sei nicht nötig (keine Ahnung wieso).

Aber es stimmt schon, dann würde ich wahrscheinlich am Anfang der Implementierungsdatei die Deklarationen der lokalen freien Funktionen hinschreiben und anschliessend die Definitionen der Member- und freien Funktionen. Wobei ich an meinem Design generell noch ein wenig rumstudieren muss...