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

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é

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;

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

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

...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.

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 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.

...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.

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...

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

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.

bb

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

=>

push 35
pop eax

btw:
Warum benutzt du VC++05 ?

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?

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.

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

bb

nexus, wie hast du den so schnell gefunden? oO

Ich habe nach "Anweisung" und Autor "Tachyon" gesucht, da ich noch ziemlich genau wusste, was er damals sagte...

unskilled schrieb:

nexus, wie hast du den so schnell gefunden? oO

Ich habe nach "Anweisung" und Autor "Tachyon" gesucht, da ich noch ziemlich genau wusste, was er damals sagte...

Hmm... wow ^^
Entweder es hat dich so beschäftigt oder es is normal sich so ne Dinge zu merken und ich hab Allzeimer ^^
Übrigens hab ich noch mal gesucht und nirgendwo auch nur einen Hinweis gefunden, dass der compiler das wegoptimiert...
mal gucken, ob ich meinen Compiler dazu bringen kann, mir die Frage zu beantworten ^^

bis später

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?

Ich sehe im Standard nix, was dagegen spricht das ganze wegzuoptimieren, sofern es das Verhalten des Codes nicht verändert.

ISO/IEC 14882 8.3.2/3 schrieb:

It is unspecified whether or not a reference requires storage (3.7).

besagt ja, dass man durchaus so etwas, wie eine Kopie erstellen darf. Sofern man das Objekt natürlich verändert geht das nicht mehr.

Auch wenn Referenzen rausoptimiert werden könnten, würde ich mich jetzt nicht darauf verlassen. Zumal im Normalfall nichts gegen Kopie spricht (als Ausnahme beispielsweise Templates).

#include <iostream>

using namespace std;

void Ausgeben(const char& ausgeben)
{
	const char ausgeben2 = ausgeben + 2;
	if(ausgeben2 == 'A')
		throw std::runtime_error("asd");
	cout << ausgeben << " => " << ausgeben2 << endl;
}//musste ja gucken, dass er sie nicht inlined, deshalb die exception...

int main()
{
	char t(0);
	cin >> t;
	Ausgeben(t);
}

macht in der main-fkt also:

int main()
{
003C11F0  push        ecx  
	char t(0);
	cin >> t;
003C11F1  mov         ecx,dword ptr [__imp_std::cin (3C3074h)] 
003C11F7  lea         eax,[esp+3] 
003C11FB  push        eax  
003C11FC  push        ecx  
003C11FD  mov         byte ptr [esp+0Bh],0 
003C1202  call        dword ptr [__imp_std::operator>><char,std::char_traits<char> > (3C3070h)] 
	Ausgeben(t);
003C1208  lea         edx,[esp+0Bh] 
003C120C  push        edx  
003C120D  call        Ausgeben (3C1130h) 
}

(die fkt Ausgeben hab ich ma weggelassen)
außer nen kleines stück (der ausgabe am ende der fkt), was in meinen augen meine vermutung doch noch untermauert:

003C119F  mov         edx,dword ptr [__imp_std::endl (3C3048h)] 
003C11A5  mov         eax,dword ptr [esp+4]

die Compiler Optionen meines VS 2008 Prof.:

/O2 /Oi /GL /D "_MBCS" /FD /EHsc /MD /Gy /Fo"Release\\" /Fd"Release\vc90.pdb" /W3 /nologo /c /Zi /TP /errorReport:prompt

bb