2d array (vector*vector) schnell initialisieren

Columbo

Und wenn ich es sequenced haben will?

Gut geschlafen?

Nathan

Arcoth schrieb:

Und wenn ich es sequenced haben will?

Gut geschlafen?

Function call von evaluate ist definitiv nicht sequenced. Damit meine ich Seiteneffekte von func.
Und das Proposal dafür ist ein Proposal und afaik nirgendwo implementiert.
Worauf willst du also hinaus?

volkard

Nathan schrieb:

Aber das ist halt der Nachteil, dass arr[x][y], eine expression ist, anstatt wie sonst auch zwei verschiedene.

Versteh das Problem weiterhin nicht.
arr.at(y,x) ist ja *ein* Ding, so auch arr[y][x]. arr[y] hat überhaupt keine Bedeutung.

T& Sparse::at(int y,int x){
//   return maps[y][x];
//   return queue[y][x];
//   return uoMaps[y][x];
   return map[make_pair(y,x)];
   return uoMap[make_pair(y,x)];
}

Nathan

volkard schrieb:

Nathan schrieb:

Aber das ist halt der Nachteil, dass arr[x][y], eine expression ist, anstatt wie sonst auch zwei verschiedene.

Versteh das Problem weiterhin nicht.
arr.at(y,x) ist ja *ein* Ding, so auch arr[y][x]. arr[y] hat überhaupt keine Bedeutung.

Hier sollte jetzt eigentlich ein Argument stehen, dass überladene Operatoren ansonsten auch die Semantiken von built-ins haben, aber dann vielen mir , && und || ein, und ich musste dir zustimmen. Das ist kein Problem.

Columbo

Function call von evaluate ist definitiv nicht sequenced. Damit meine ich Seiteneffekte von func.

Ich nehme an, du meinst die Auswertungsreihenfolge der Argumente?

N3337 [dcl.init.list]/4 schrieb:

Within the initializer-list of a braced-init-list, the initializer-clauses, including any that result from pack expansions (14.5.3), are evaluated in the order in which they appear. That is, every value computation and side effect associated with a given initializer-clause is sequenced before every value computation and side effect associated with any initializer-clause that follows it in the comma-separated list of the initializer-list.

x

Und das Proposal dafür ist ein Proposal und afaik nirgendwo implementiert.

Welches Proposal?

Nathan

Arcoth schrieb:

Function call von evaluate ist definitiv nicht sequenced. Damit meine ich Seiteneffekte von func.

Ich nehme an, du meinst die Auswertungsreihenfolge der Argumente?

Ja.

N3337 [dcl.init.list]/4 schrieb:

Within the initializer-list of a braced-init-list, the initializer-clauses, including any that result from pack expansions (14.5.3), are evaluated in the order in which they appear. That is, every value computation and side effect associated with a given initializer-clause is sequenced before every value computation and side effect associated with any initializer-clause that follows it in the comma-separated list of the initializer-list.

evaluate{ func(bla)... }; ist AFAIK kein initializer-clause.

Und das Proposal dafür ist ein Proposal und afaik nirgendwo implementiert.

Welches Proposal?

Das Proposal. N4228

Da sind auch so tolle Sachen wie Modules, operator.(), Ranges, Default comparision, Atomic Smart Pointer, Operator assert, uvm.
C++17 wird awesome.

Columbo

evaluate{ func(bla)... }; ist AFAIK kein initializer-clause.

evaluate{ func(bla)... } ist selbstverständlich keine initializer-clause, jedenfalls nicht ohne Kontext.
Aber func(bla)... sind welche. Und zwar für die initializer list mit der die Temporary initialisiert wird.

Nathan

Arcoth schrieb:

evaluate{ func(bla)... }; ist AFAIK kein initializer-clause.

evaluate{ func(bla)... } ist selbstverständlich keine initializer-clause, jedenfalls nicht ohne Kontext.
Aber func(bla)... sind welche. Und zwar für die initializer list mit der die Temporary initialisiert wird.

Dann hält sich GCC scheinbar nicht daran.
http://ideone.com/ueQiBN

Columbo

Nathan schrieb:

Dann hält sich GCC scheinbar nicht daran.
http://ideone.com/ueQiBN

Ja, das ist ein längst gemeldeter Bug.

Nathan

Arcoth schrieb:

Nathan schrieb:

Dann hält sich GCC scheinbar nicht daran.
http://ideone.com/ueQiBN

Ja, das ist ein längst gemeldeter Bug.

Gut zu wissen.
So lange nutze ich halt char-Arrays.

happystudent

Hm, hätte mir wohl denken können dass das wieder mal nicht so leicht ist wie anfangs gedacht

Aber dieses N4228 proposal liest sich ja schonmal interessant, danke für den Link. Vielleicht wirds ja dann in C++17 mal was mit matrix[i, j] .

Nathan

happystudent schrieb:

Vielleicht wirds ja dann in C++17 mal was mit matrix[i, j] .

Nein, wieso sollte es?
Das bricht existierenden Code. Und der meiste C+++ Code ist schon geschrieben, die Sprache ist alt und etabliert. Man kann es sich nicht mehr leisten, Code zu brechen.

volkard

happystudent schrieb:

Hm, hätte mir wohl denken können dass das wieder mal nicht so leicht ist wie anfangs gedacht

Aber dieses N4228 proposal liest sich ja schonmal interessant, danke für den Link. Vielleicht wirds ja dann in C++17 mal was mit matrix[i, j] .

Ok, nach Proxy googlen war zu schwer.

http://www.c-plusplus.net/forum/57613-full
http://www.c-plusplus.net/forum/321185-full
http://www.c-plusplus.net/forum/113709-full

happystudent

Nathan schrieb:

Nein, wieso sollte es?
Das bricht existierenden Code. Und der meiste C+++ Code ist schon geschrieben, die Sprache ist alt und etabliert. Man kann es sich nicht mehr leisten, Code zu brechen.

Es müsste nicht zwingend alten Code brechen. Man könnte es auch so machen dass alter Code bestehen bleibt und nur im Falle eines überladenen operator[](int, ...) die Indizierung anders interpretiert wird:

struct alter_code {
    int value;
    int &operator[](int i) { return value; }
};

struct neuer_code {
    int value;
    int &operator[](int i, int j) { return value; }
};

int main() {
    alter_code ac;
    neuer_code nc;

    ac[0, 0] = 1; // operator[](int), da kein operator[] mit mehr als 1 argument überladen
    nc[0, 0] = 2; // operator[](int, int), da operator[] mit > 1 argument vorhanden
}

Dadurch würde nichts brechen, da alter Code ja keinen operator[] mit mehr als einem überladenen Argument enthalten kann.

Edit:

volkard schrieb:

Ok, nach Proxy googlen war zu schwer.

http://www.c-plusplus.net/forum/57613-full
http://www.c-plusplus.net/forum/321185-full
http://www.c-plusplus.net/forum/113709-full

Nein, wie bereits (mehrmals) geschrieben geht es um eine indizierung per matrix[i, j] und nicht um eine proxy addressierung mittels matrix[i][j] , da das ja dann keine matrix struktur darstellt sondern eher was wie vector<vector<T>> .

Mechanics

happystudent schrieb:

Nein, wie bereits (mehrmals) geschrieben geht es um eine indizierung per matrix[i, j] und nicht um eine proxy addressierung mittels matrix[i][j] , da das ja dann keine matrix struktur darstellt sondern eher was wie vector<vector<T>> .

Hab jetzt nicht alles gelesen, aber warum nicht matrix(i, j)? Ist evtl. noch schöner als matrix[i][j].

volkard

happystudent schrieb:

Nein, wie bereits (mehrmals) geschrieben geht es um eine indizierung per matrix[i, j] und nicht um eine proxy addressierung mittels matrix[i][j] , da das ja dann keine matrix struktur darstellt sondern eher was wie vector<vector<T>> .

haben und ein 2D-Array meinen: Eine Matrix.

volkard

Mechanics schrieb:

happystudent schrieb:

Nein, wie bereits (mehrmals) geschrieben geht es um eine indizierung per matrix[i, j] und nicht um eine proxy addressierung mittels matrix[i][j] , da das ja dann keine matrix struktur darstellt sondern eher was wie vector<vector<T>> .

Hab jetzt nicht alles gelesen, aber warum nicht matrix(i, j)? Ist evtl. noch schöner als matrix[i][j].

Weils kein Funktor/Funktion/Lamda ist, sondern ein 2D-Array.
Also nicht arr(3,4), sondern arr.at(3,4) oder arr[3][4].

happystudent

volkard schrieb:

haben und ein 2D-Array meinen: Eine Matrix.

Du sagst es, man meint eine Matrix. Hat aber (im allgemeinen) ein array aus arrays und kann eine tatsächliche Matrix indizierungstechnisch nicht von einem array aus arrays unterscheiden, wobei die einzelnen unter-arrays ja auch unterschiedliche Längen haben können (was dem Prinzip einer Matrix wiederspricht).

Und darauf wird ja gerade in diesem Forum immer viel Wert gelegt.

volkard

happystudent schrieb:

Und darauf wird ja gerade in diesem Forum immer viel Wert gelegt.

Keine Ahnung, warum SeppJ da (,) vorschlug. Globalmoderatoren dürfen aber auch mal Drogen nehmen.
Naja, in alten C++-Büchern wurde oft mal (,) auf 2D-Arrays vorgemacht, um ein Beispiel für Operatorenüberladung zu haben.
Sieh einfach [][] als die C++-Syntax dafür an.

happystudent

Ok, auf jeden Fall wieder eine sehr interessante Diskussion