STL-Container von "private" nach "public"?

[goran]

Hallo, ich habe eine Frage zu einem Problem was sich mir immer wieder stellt.

Und zwar schreibe ich immer wieder "get" und "set" Methoden um einen "private" STL-Container zu nutzen.

Die "get" und "set" Methoden sind aber so mächtig das der jeweilige STL-Container auch gleich als "public" definiert werden kann und ich mir die "set" bzw. "get" Methoden sparen kann.

Was meint ihr? Soll ich den Container bei einem wie o.g. Szenario gleich "public" machen?

Gruß
Goran

[asc]

goran schrieb:

Die "get" und "set" Methoden sind aber so mächtig das der jeweilige STL-Container auch gleich als "public" definiert werden kann und ich mir die "set" bzw. "get" Methoden sparen kann.

Die erste Frage wäre: Macht es wirklich Sinn überhaupt direkte Zugriffe auf einen Container nach außen zu geben. Aber vollkommen davon abgesehen...

goran schrieb:

Was meint ihr? Soll ich den Container bei einem wie o.g. Szenario gleich "public" machen?

...ein eindeutiges nein zu dieser Überlegung.

Getter/Setter sind immer besser als public Member. Der Grund ist schlicht und ergreifend alleine schon das man später noch Bedingungen und Prüfungen implementieren kann. Falls du Performancebedenken hast, mach sie von mir aus inline.

cu André

[spanner]

zeig mal den code, wie deine getter und setter im moment aussehen.

[goran]

z.B.:

public:
	void addSomeString(const std::string& aSomeString);
	const unsigned& int getSomeStringSize() const;
	const std::string getSomeString(const unsigned int& aPos) const;
	void delSomeString(const unsigned int& aPos);

Dahinter versteckt sich nichts als

private:
	std::vector<std::string> itsSomeStrings;

[Nexus]

Die Angelegenheit wurde hier kürzlich besprochen.

Du solltest übrigens primitive Typen wie int kopieren und nicht per Const-Referenz übergeben.

[spanner]

würd ich auf jeden fall so lassen wie es ist, sonst weichst du nur völlig grundlos die kapselung auf.

die const unsigned int& sind ein bissl ungewöhnlich. nimm doch std::size_t, und die referenz ist sowieso bestenfalls unnützer optischer ballast.

[goran]

das mit int und referenz ist ein copy fehler. aber danke für die antworten. ich lasse es dann so.

[drakon]

Das kommt ja auf den Verwendungszweck an, aber wenn du wirklich die ganze Schnittstelle des Containers brauchst, kannst du ja so etwas, wie SetVector() machen und da eine Referenz übergeben, und dann innerhalb deiner Funktion deinen privaten Container füllen. Wenn du später irgendwelche Überprüfungen brauchst, dann kannst du das immernoch in dieser Funktion hinzufügen.

[Simon2]

Nexus schrieb:

...Du solltest übrigens primitive Typen wie int kopieren und nicht per Const-Referenz übergeben.

Nicht, dass ich widersprechen wollte, aber: Warum?
Weil es einfacher zu lesen ist ?
Weil es evtl. für den Compiler einfacher zu optimieren oder sonstwie schneller ist ?
Weil ... ?

Würde mich ehrlich und ergebnisoffen interessieren.

Gruß,

Simon2.

[drakon]

Simon2 schrieb:

Nexus schrieb:

...Du solltest übrigens primitive Typen wie int kopieren und nicht per Const-Referenz übergeben.

Nicht, dass ich widersprechen wollte, aber: Warum?
Weil es einfacher zu lesen ist ?
Weil es evtl. für den Compiler einfacher zu optimieren oder sonstwie schneller ist ?
Weil ... ?

Würde mich ehrlich und ergebnisoffen interessieren.

Gruß,

Simon2.

Ich bin mir jetzt nicht ganz sicher, aber ich glaube mal irgendwo was aufgeschnappt zu haben, dass es minimale Leistungseinbussen geben kann, wenn man einen primitiven Typen per Referenz übergibt. ( Leistungseinbussen, welche sonst bei grossen Typen wettgemacht wird).
Aber ansonsten spielt es nicht wirklich eine Rolle. Vor allem, wenn ich eine templateklasse schreibe, kann es durchaus vorkommen, dass da halt bei der Instanzierung von primitive Datentypen Zeiger übergeben werden.

[Nexus]

Simon2 schrieb:

Nexus schrieb:

...Du solltest übrigens primitive Typen wie int kopieren und nicht per Const-Referenz übergeben.

Nicht, dass ich widersprechen wollte, aber: Warum?

Ich glaube, bei primitiven Typen lohnt sich eine Kopie mehr, weil die Dereferenzierung durch die Referenz ja auch Performance braucht (gerade bei vielen Zugriffen auf die Variable).

Und das mit dem Besser Lesen ist natürlich ein schöner Seiteneffekt.

[Simon2]

Nexus schrieb:

...Ich glaube, bei primitiven Typen lohnt sich eine Kopie mehr, weil die Dereferenzierung durch die Referenz ja auch Performance braucht (gerade bei vielen Zugriffen auf die Variable)....

hmmmm, aber das sieht mir eher nach "Mikrooptimierung" aus, aus der ich keine so zentrale und allgemeingültige Designvorschrift wie
"...Du solltest übrigens primitive Typen wie int kopieren und nicht per Const-Referenz übergeben...."
konstruieren wollen würde. Gerade bei templates würde der einem eine Menge Ärger einhandeln... (Mal ganz abgesehen davon, dass es bestimmt genügend Fälle gibt, in denen der Compiler die Dereferenzierung wegoptimieren kann).

Einer Aussage wie: "Bei primitiven Typen sind Kopien manchmal schneller als const-Refs" dagegen, würde ich zustimmen.

Gruß,

Simon2.

[Nexus]

Naja, ich denke so als Faustregel fährt man besser, wenn man primitive Typen per Value übergibt. Klar gehört das eher in den Mikrooptimierungsbereich, aber das gilt ja für die Const-Ref auch.

Bei Templates etc. bin ich natürlich mit dir einig. Wenn man sich nicht sicher ist, ob das Objekt grösser sein könnte, nimmt man besser eine Referenz. Aber ich würde primitve Typen im Allgemeinen als Wert übergeben, man verliert ja dabei nichts.

Simon2 schrieb:

(Mal ganz abgesehen davon, dass es bestimmt genügend Fälle gibt, in denen der Compiler die Dereferenzierung wegoptimieren kann).

Da wäre ich mir jetzt nicht sicher. Zumindest die Übergabe als Referenz oder Kopie ist eine klare Anweisung an den Compiler. Aber das ist wahrscheinlich alles implementationsabhängig...

[unskilled]

Nexus schrieb:

Simon2 schrieb:

(Mal ganz abgesehen davon, dass es bestimmt genügend Fälle gibt, in denen der Compiler die Dereferenzierung wegoptimieren kann).

Da wäre ich mir jetzt nicht sicher. Zumindest die Übergabe als Referenz oder Kopie ist eine klare Anweisung an den Compiler. Aber das ist wahrscheinlich alles implementationsabhängig...

Also als ich damals (vll vor 5Monaten) mal gesagt hatte, dass ich denke, mal gelesen zu haben, dass const referenzen bei zu kleinen Datentypen wegoptimiert werden, wurde mir eindeutig wiedersprochen - ich habe auch nirgendwo Anhaltspunkte dazu gefunden gehabt - aber das muss natürlich nichts heißen...

bb

[drakon]

dass const referenzen bei zu kleinen Datentypen wegoptimiert werden, wurde mir eindeutig wiedersprochen - ich habe auch nirgendwo Anhaltspunkte dazu gefunden gehabt - aber das muss natürlich nichts heißen...

Zeit mal den Beitrag.

Ansonsen gilt die Regel: "Wenn es nicht im Standard ist, ist es Implementierungsabhängig". Wenn es dein Compiler macht, dann ist das schön für dich, ist aber keine allgemeingültige Regel.

[unskilled]

ich suche noch... die suche war ja auch schon mal schneller - aber mit google habe ich nichts mehr darüber gefunden gehabt... falls ichs noch finde, werd ichs posten - aber ich weiß nich ma mehr ansatzweise, um was es in dem thread eigentlich ging ^^

bb

[Badestrand]

Ich wollte es kurz mal testen, mein Compiler (VC++ 2005 Express) hat aber "zu viel" optimiert:

int foo( const int& a )
{
	return a * 5;
}
int __cdecl WinMainCRTStartup()
{
	int a = 7;
	return foo( a );
}

=>

push 35
pop eax

[drakon]

:p
Du sollst es ihm auch nicht so einfach machen.

btw:
Warum benutzt du VC++05 ?

[Nexus]

drakon schrieb:

Zeit mal den Beitrag.

Ich hab ihn gefunden: http://www.c-plusplus.net/forum/viewtopic-var-t-is-217599-and-postdays-is-0-and-postorder-is-asc-and-start-is-20.html

Tachyon sagte darin:

Tachyon schrieb:

Nein, die Benutzung des Referenzoperators ist eine klare Anweisung und keine Empfehlung. Es wird mit Sicherheit keine Kopie erzeugt.

Also was gilt nun? Sagt der Standard diesbezüglich etwas?

[Badestrand]

drakon schrieb:

Warum benutzt du VC++05?

Zu VC++ 08 (Express) bin ich irgendwie noch nicht konvertiert. Hab's mir zwar geholt, verspreche mir im Moment von einer Umstellung aber nicht allzu viel Zumal ich noch nicht wegen Kompatibilitäten geschaut habe, also welche CRT-Sachen man dazu installieren muss usw.

[unskilled]

nexus, wie hast du den so schnell gefunden? oO

ich hab meine gesamten Beiträge angeguckt und gesucht xD hatte ihn gerade auch gefunden ^^

bb