2D Array an Methode übergeben?!
-
Hallo, ich suche nach einer Möglichkeit
ein 2D Array an meine Methode zu übergeben. Ich bin überrascht das es so nicht geht
void setMatrix(float **m) { for(int zeile=0; zeile<nSize; zeile++) { for( int spalte=0; spalte<nSize+1; spalte++) { data[zeile][spalte] = m[zeile][spalte]; } } }float test[][3] = { {1, 2, 3}, {4, 5, 6}}; PMat matrix1(2); matrix1.setMatrix(test);Kann mir bitte jemand weiter helfen.

-
DKlay schrieb:
Ich bin überrascht das es so nicht geht

Was passiert denn? Fehlermeldung?
-
oenone schrieb:
Was passiert denn? Fehlermeldung?
error: no matching function for call to 'PMat::setMatrix(float [2][3])' matrix1.setMatrix(test);Eine feste größe kann ich jedoch auch nicht in der Funktion definieren, da ich
die Klasse für das lösen einer LGS verwenden möchte
-
float[][3] und float** sind nicht ineinander umwandelbar.
-
Bashar schrieb:
float[][3] und float** sind nicht ineinander umwandelbar.
Wie sieht dann eine Lösung für das Problem aus?

-
DKlay schrieb:
Eine feste größe kann ich jedoch auch nicht in der Funktion definieren, da ich
die Klasse für das lösen einer LGS verwenden möchteDann würde ich die Matrix in ein eindimensionales Array stopfen.
(Am besten noch ne Wrapper-Klasse drum, die sich dann doch zweidimenional anfühlt mit [][], aber das ist nicht dringend.)
-
float test[][3] = {{1, 2, 3}, {4, 5, 6}}; void setMatrix(float* m) { for(int zeile=0; zeile < 2; zeile++) { for( int spalte=0; spalte < 2 + 1; spalte++) { data[3 * zeile + spalte] = m[3 * zeile + spalte]; } } } setMatrix(reinterpret_cast<float*>(test));
-
Wie waere es mit &test[0][0]?
-
@Mr.Long: Du meinst wohl eher
data[3 * zeile + spalte] = m[3 * zeile + spalte];? (beachte die 3 Änderungen!)
-
Kellerautomat schrieb:
Wie waere es mit &test[0][0]?
Nein funktioniert leider auch nicht.
main.cpp:19:33: error: invalid types 'float[int]' for array subscript matrix1.setMatrix(&test[0][0]);Hab mich jetzt für die Möglichkeit von Mr Long entschieden mit der
Änderung von Th69.Danke an dieser Stelle

Hab aber noch eine Frage. Ist es nicht so das casts auf ein
Design Fehler hindeuten?
-
Man hat bewusst Namen wie static_cast, reinterpret_cast usw. ausgewählt, da sie hässlich aussehen sollen. Ich würde dabei nicht von einem Designfehler sprechen, sondern mehr von einem schlechten Stil, aber in manchen Fällen kann man eben nicht auf Casts verzichten.
Nur alte C-Casts solltest du nicht verwenden.
-
Ist es nicht so das casts auf ein Design Fehler hindeuten?
dynamic_castdeutet meistens auf einen Design-Fehler hin.
static_castdeutet fast nie auf einen Design-Fehler hin.
const_castsolltest du praktisch nirgends benutzen (außer du hantierst mit irgendwelchen legacy-APIs rum die nicht const-correct sind, oder du nutzt es für Trick 17).Man hat bewusst Namen wie static_cast, reinterpret_cast usw. ausgewählt, da sie hässlich aussehen sollen
Das hört sich zumindest nach absolutem Quatsch an.
-
Arcoth schrieb:
Man hat bewusst Namen wie static_cast, reinterpret_cast usw. ausgewählt, da sie hässlich aussehen sollen
Das hört sich zumindest nach absolutem Quatsch an.
Stimmt aber.
-
Arcoth schrieb:
Das hört sich zumindest nach absolutem Quatsch an.
-
Moderator aha.
-
Mr.Long schrieb:
setMatrix(reinterpret_cast<float*>(test));Kellerautomat schrieb:
Wie waere es mit &test[0][0]?
Die ultimative Lösung ist
flat_begin(test):template <typename T> T *flat_begin(T &x) { return &x; } template <typename T, size_t N> auto flat_begin(T (&x)[N]) { return flat_begin(*x); } template <typename T> T *flat_end(T &x) { return &x + 1; } template <typename T, size_t N> auto flat_end(T (&x)[N]) { return flat_begin(x[N]); }
-
Kellerautomat schrieb:
Arcoth schrieb:
Das hört sich zumindest nach absolutem Quatsch an.
Dass man tatsächlich die Hässlichkeit bedacht hatte wusste ich gar nicht, danke für den Link.
Mr.Long schrieb:
Moderator aha.
Was ist denn deine Einsicht?@flat_land:
camper schrieb:
template <typename T> constexpr auto decayed_begin(T&& c) -> decltype(std::begin(std::forward<T>(c))) { return std::begin(std::forward<T>(c)); } template <typename T, std::size_t M, size_t N> constexpr auto decayed_begin(T(&c)[M][N]) -> decltype(decayed_begin(*c)) { return decayed_begin(*c); } template <typename T> constexpr auto decayed_end(T&& c) -> decltype(std::end(std::forward<T>(c))) { return std::end(std::forward<T>(c)); } template <typename T, std::size_t M, size_t N> constexpr auto decayed_end(T(&c)[M][N]) -> decltype(decayed_begin(c[M])) { return decayed_begin(c[M]); }
-
Arcoth schrieb:
@flat_land:
camper schrieb:
...Scheitert schon an dreidimensionalen Arrays, wie kann das besser sein?
-
Ausserdem ist decayed_begin ein misnomer, ich will von einem
int[2][3][4]aufint*und nicht aufint[2][3]*(was decayed bedeutet) oderint***(was deep_decayed bedeutet).
-
Du kannst mal meine Version aus demselben Thread versuchen (ungetestet ehrlich gesagt):
asfdlol schrieb:
template<typename T> T* RecBegin(T& Object) { return &Object; } template<typename T, std::size_t n> typename std::remove_all_extents<T>::type* RecBegin(T(&Array)[n]) { return RecBegin(Array[0]); } template<typename T> T* RecEnd(T& Object) { return &Object; } template<typename T, std::size_t n> typename std::remove_all_extents<T>::type* RecEnd(T(&Array)[n]) { return RecBegin(Array[n]); }Edit:
Achso, du hast gar nicht nach einer Lösung gefragt. Sorry. Bisschen durch den Wind heute.
-
asfdlol schrieb:
Du kannst mal meine Version aus demselben Thread versuchen (ungetestet ehrlich gesagt):
Abgesehen von dem Off-By-One error in RecEnd scheint die zu stimmen.
Gute Idee mit remove_all_extents, das macht den Code C++11-konform.
Ich denke der Gewinner ist
template <typename T> constexpr T *flat_begin(T &x) { return &x; } template <typename T, size_t N> constexpr typename std::remove_all_extents<T>::type *flat_begin(T (&x)[N]) { return flat_begin(*x); } template <typename T> T *flat_end(T &x) { return &x + 1; } template <typename T, size_t N> constexpr typename std::remove_all_extents<T>::type *flat_end(T (&x)[N]) { return flat_begin(x[N]); }