Performance vs. Design

d.h.

States oS;

int i= oS[5];

wird inline so optimiert:

States oS;

int i=oS.m_vStates[5];

ghorst

ja. solange du deinen compiler lässt. will heißen: im debug mode wird er es nicht tun, aber sonst schon.

hustbaer

aber es gibt 64bit compiler, die ein 32bit int definiert haben.

MSVC zum bleistift

Nexus

ghorst schrieb:

size_t sollte nicht so groß wie int sondern wie der systemübliche zeiger sein. das ist auf den meisten systemen haarspalterei, aber es gibt 64bit compiler, die ein 32bit int definiert haben.

Ich dachte, das wäre so definiert, also Integer-Grösse:

typedef unsigned int size_t;

ghorst

@nexus so kann es definiert werden, wenn int und die größe des zeigers zusammenfallen. aber bei einem compiler, der eine unterschiedliche größen für ints und zeiger hat (wie der von hustbaer erwähnte 64bit-compiler von ms), wird er normalerweise über die größe des zeigers realisiert, damit bspw vector<char> auch den kompletten speicher nutzen kann.

OptimzerC schrieb:

diese zustände will ich iterieren (was schnell gehen muss).

Woher weißt du, dass das scnellgehen muss? hast du das gemessen oder geschätzt?

Nexus

ghorst schrieb:

@nexus so kann es definiert werden, wenn int und die größe des zeigers zusammenfallen. aber bei einem compiler, der eine unterschiedliche größen für ints und zeiger hat (wie der von hustbaer erwähnte 64bit-compiler von ms), wird er normalerweise über die größe des zeigers realisiert, damit bspw vector<char> auch den kompletten speicher nutzen kann.

Aber ist das nicht irgendwo festgelegt? Denn wenn ich im VC++ 2008 mit dem Cursor über size_t fahre, kommt ein Tipp mit typedef unsigned int size_t. Aber die Deklaration konnte ich nicht finden, ist sie in einer Bibliothek? Oder ist das vom Compiler selbst abhängig?

hustbaer schrieb:

aber es gibt 64bit compiler, die ein 32bit int definiert haben.

MSVC zum bleistift

Ist mir erst jetzt aufgefallen

ghorst

Nexus schrieb:

Aber ist das nicht irgendwo festgelegt?

leider nein.

Nexus schrieb:

Oder ist das vom Compiler selbst abhängig?

ja. jeder compiler darf selber entscheiden, wie er das realisiert. er muss nur die c/c++-regeln aus dem standard einhalten.

tntnet

ghorst schrieb:

size_t sollte nicht so groß wie int sondern wie der systemübliche zeiger sein. das ist auf den meisten systemen haarspalterei, aber es gibt 64bit compiler, die ein 32bit int definiert haben.

Gibt es denn 64 bit compiler, bei denen int 64 bit hat?

ghorst

wie ich schon schrieb: der gcc nutzt meines wissen nach int mit 64bit.

sothis_

ghorst schrieb:

wie ich schon schrieb: der gcc nutzt meines wissen nach int mit 64bit.

nein
gcc mit x64 target:

int 32bit
long 64bit
long long 64bit

cl mit x64 target:

int 32bit
long 32bit
long long 64bit

ghorst

danke für die korrektur. ich habe keinen gcc für 64bit, sondern las nur, dass dieser erhebliche probleme bereitet und ints mit 64bit veranschlagt. aber das ist offensichtlich falsch. daher ziehe ich meine kommentare zurück.

Hi OptimzerC,

meiner Meinung nach sind das keine Kriterien über die du dir Gedanken machen
mußt. Wenn es allerdings wirklich so zeitkritisch ist, würde ich eine
Funktion:

const std::vector<int>& getStates() const;

machen und dann so drüber iterieren:

const std::vector<int>& vec = obj->getStates();
std::vector<int>::const_iterator end = vec.end();
for(std::vector<int>::const_iterator it = vec.begin(); it!=end; ++it){
int j = *it;
}

Das ist glaube ich einen Zeiger-Zugriff schneller als die Adressierung per
Index. Lasse mich aber auch gerne vom Gegenteil überzeugen ^^
Alternativ kannst du natürlich auch zwei Methoden in deiner Klasse zur
Verfügung stellen:

typedef std::vector<int>::const_iterator const_iterator;

const_iterator begin() const;
const_iterator end() const;

States::const_iterator end = obj->end();
for(States::const_iterator it = obj->begin(); it!=end; ++it){
int j = *it;
}

EDIT: obj->end() vor for-Schleife gezogen.

Gruß,
CSpille