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

[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

[Nexus]

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

[unskilled]

Nexus schrieb:

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

[drakon]

Nexus schrieb:

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.

[Nexus]

Hm... Naja, ich werde primitive Typen weiterhin als Wert statt als Const-Referenz übergeben. Eigentlich sollte ich dadurch keine Vorteile erhalten. Das Ganze sieht auch übersichtlicher aus - nicht nur, dass es weniger Platz benötigt, man erkennt auch gleich, dass es sich um "ein leichtes Objekt" handelt.

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

[unskilled]

also ich hab jz gerad mal nen bsp gebastelt in der er mir die fkt nicht geinlined hat - offenbar bleibt die referenz (wobei das zugegebenermaßen nur eine Schätzung ist - sollte ma jmd angucken, der über asm mehr als nur die synthax zu mov kennt ;o)):

#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