make_pair - Speicherfresser?

Nachfolgend sind die Dateigrößen eines Dummyprogramms zu sehen

$ ls -lah
16 -rwxr-xr-x 1 uwe uwe 13772 9. Apr 05:08 dummy

...

$ ls -lah
16 -rwxr-xr-x 1 uwe uwe 22050 9. Apr 05:08 dummy

Bei ersterem ist

// Diese Deklaration ist in beiden Versionen vorhanden, kann daher als Auslöser ausgeschlossen werden
  // std::vector<std::pair<char, std::string> > args;

  // ------
  args.push_back(std::make_pair('m', "moo"));
  // ------

ausgeklammert, ansonsten sind beide Programme völlig identisch.

Wie kommt es also, dass sich die Programmdatei ob der Verwendung von make_pair um mehr als 8KB (was immerhin mehr als 50% der ursprünglichen Größe entspricht - also nicht unbeachtlich) "aufbläht"?

Ratsuchende Grüße,
Uwe

Was ich vergaß zu erwähnen:

gcc-Version 4.1.2 (Gentoo 4.1.2)

Auch std::pair generell - also ohne der Verwendung von make_pair - führt zu dem signifikant höheren Speicherbedarf.

std::pair<char,std::string> moo;
  args.push_back(moo);

volkard

args.push_back(std::make_pair('m', "moo"));
args ist map<char,string>?
ja, vielleicht, weil "moo" erstmal nen konstruktor von string aufruft. der wiederum ruft strlen, und strcpy und die operator new auf. die wiederum kann ne exception schmeißen, weshalb das exception-handling reincompiliert wird. die exceptions haben virtuelle funktionen, weshalb vtbls dazukommen. vielleicht noch die pseudofunktion für pure-virtual-function-calls. für den ganzen mist sind 8k ganz schön wenig.

volkard

könntest du mal testen, was make_pair kostet, wenn es um ein pair<int,int> geht?

volkard schrieb:

könntest du mal testen, was make_pair kostet, wenn es um ein pair<int,int> geht?

Ebenfalls ~22K.
An den std::string Routinen kann es nicht liegen, die werden auch andersweitig im Programm verwendet.

Ich merke aber gerade, dass das Verhalten auf std::vector.push_back zurückzuführen ist - ich sollte im Dämmerzustand keine Vermutungen über vermeintliche Fehlverhalten anstellen ohne den Fehler vorher exakt eingegrenzt zu haben. Werde mich morgen mit den anderen "Array-Klassen" ala list und dequeue befassen, vielleicht sind diese in der Benutzung, bzw Speichernutzung angenehmer als vector - wobei das im Prinzip auch nicht wirklich einen riesigen Unterschied darstellen wird.

Das Thema kann bei Bedarf 'gen Dustbin verschoben werden...

Grüße und Danke,
Uwe

.filmor

uwe_guest schrieb:

Werde mich morgen mit den anderen "Array-Klassen" ala list und dequeue befassen, vielleicht sind diese in der Benutzung, bzw Speichernutzung angenehmer als vector - wobei das im Prinzip auch nicht wirklich einen riesigen Unterschied darstellen wird.

Lass das. Du wählst einen Container danach aus, was du zur Laufzeit für Anforderungen an ihn stellst (schnelles Einfügen/Löschen, Random-Access-Iteratoren etc.), nicht danach, wieviel Code der Compiler generiert. Hast du übrigens mal versucht, die Binärdatei zu "strip"pen?! std::vector hat einige Methoden, die mit dem push_back aufgerufen werden könnten und deren Code, Namen (und vielleicht noch andere Informationen bis hin zum gesamten Programmtext je nach -g-Einstellung) in die Datei, die der Compiler ausspuckt reinkommen.

Lass das. Du wählst einen Container danach aus, was du zur Laufzeit für Anforderungen an ihn stellst (schnelles Einfügen/Löschen, Random-Access-Iteratoren etc.), nicht danach, wieviel Code der Compiler generiert.

Schon klar. Da ich mich aber bisher nicht wirklich mit den Containerformaten beschäftigt habe, ist das mit "Benutzung" gemeint gewesen - die Speichernutzung ist nur ein Effekt, der mit am Rande aufgefallen ist, bei den heutigen Datenmengen aber größtenteils vernachlässigbar ist - auch wenn Optimierung natürlich auch seine Vorzüge hat.

Hast du übrigens mal versucht, die Binärdatei zu "strip"pen?! std::vector hat einige Methoden, die mit dem push_back aufgerufen werden könnten und deren Code, Namen (und vielleicht noch andere Informationen bis hin zum gesamten Programmtext je nach -g-Einstellung) in die Datei, die der Compiler ausspuckt reinkommen.

Jupp, ges'trip't isses wieder bei ~19K. MIt den entsprechenden Compilerflags habe ich mich ehrlich gesagt ebenfalls noch nie eingehend beschäftigt. Solange das Programm die gewünschten Funktionen erfüllte, war mir das bis dato immer egal gewesen.