2d array of pointer



  • Hallo Forum,

    Leider gilt wohl: float data[100][100] != float **data;

    Wenn man sich die Verteilung der Daten auf die im Speicher belegten Adressen ansieht, findet man für den ersten Fall (float data[100][100]):
    data == &data[0][0];
    data +4 == &data[1][];
    usw...

    Nach der Initialisierung des zweiten Falls:

    float ** data = new float *[100];
    und dann data[1..100] = new float[100];

    liegt hier der erste Datenpunkt mehr als 400 byte weit weg von der durch data belegten Adresse, weswegen eine Umwandlung wohl nicht trivial sein dürfte.

    Für eine ältere Funktion, die ein "float ** data" übergeben haben möchte, würde ich gern ein data[100][100] übergeben - wie kann ich das eine in das andere umwandeln ?



  • &data und die Daten column- statt row-first reinschreiben.



  • Bist du sicher, dass die Funktion da nichts zurück liefern will?



  • 7x7-7 schrieb:

    Hallo Forum,

    Leider gilt wohl: float data[100][100] != float **data;

    Jupp

    7x7-7 schrieb:

    und dann data[1..100] = new float[100];

    Eher data[0..99]

    7x7-7 schrieb:

    liegt hier der erste Datenpunkt mehr als 400 byte weit weg von der durch data belegten Adresse, weswegen eine Umwandlung wohl nicht trivial sein dürfte.

    Für eine ältere Funktion, die ein "float ** data" übergeben haben möchte, würde ich gern ein data[100][100] übergeben - wie kann ich das eine in das andere umwandeln ?

    Von dem "echten" 2D-Array zu einem Doppelpointer geht es. Ugekehrt ist schwierig.

    float data_org[100][100] 
    
    float ** data = new float *[100];
    und dann data[i] = data_org[i]  mit i = 0 ...99
    


  • 7x7-7 schrieb:

    "float ** data" übergeben haben möchte, würde ich gern ein data[100][100] übergeben - wie kann ich das eine in das andere umwandeln ?

    Ohne UB gar nicht, denn die Typen sind inkompatibel.
    Fehlerverschleierungen via Zeigercast oder void* ändern daran nichts.



  • Hallo und danke für die vielen Beiträge.

    wie es aussieht, handelt es sich um einen historisch bedingten Effekt, der während der zunächst iterativ verlaufenden Entwicklung der Programmiersprache C entstanden ist. So übersetzt wohl der Compiler die semantisch identisch anmutende Zeichenfolgen a[1][2] und b[1][2] völlig unterschiedlich, wenn int**a und int b[100][100] definiert wurden.

    Hier ist der aufschlussreiche Beitrag aus dem die Info stammt:
    http://stackoverflow.com/questions/14183546/why-does-int-decay-into-int-but-not-int



  • 7x7-7 schrieb:

    historisch bedingten Effekt, der während der zunächst iterativ verlaufenden Entwicklung der Programmiersprache C entstanden ist.

    Tatsächlich ist C aus der Praxis heraus entstanden - d.h. von Profis, die wissen was sie können und wollen.
    Die meisten anderen Sprachen sind von Theoretikern entworfen worden, die Wert auf leichte intuitive Bedienbarkeit legen - quasi damit auch noch der letzte Depp als Programmierer Unheil anrichten kann.
    Problematisch wird es dann, wenn solche Sprachverständnisse aufeinandertreffen, wie bei C-Zeigern und C++.
    Dann wird nach dem C++-Motto einfach alles irgendwie (mit C++ Standard(!) Sprachmitteln) zurechtgecastet, weil die Typ"sicherheit" von C++ sowas verlangt, und hinterher wird rumgejammert, wenn man durch solche Casts den C++-Compiler zunächst mal ruhiggestellt hat, sich aber dann unerwartete Ergebnisse einstellen.
    Und deshalb gehören C Zeiger nicht C++ Hände und zumindest nur in solche, die von C kamen und "auf"gestiegen sind und nicht umgekehrt.

    7x7-7 schrieb:

    übersetzt wohl der Compiler die semantisch identisch anmutende Zeichenfolgen a[1][2] und b[1][2] völlig unterschiedlich, wenn int**a und int b[100][100] definiert wurden.

    Der C Compiler übersetzt "identisch anmutende Zeichenfolgen" nicht "völlig unterschiedlich" sondern "Ausdrücke" "immer gleich":
    Objekte haben Typ und Wert, der Compiler weiß natürlich, dass das eine den Typ Zeiger auf int* und das andere Zeiger auf int[100] hat, und übersetzt für unterschiedliche und inkompatible Typen natürlich was anderes.
    Du hast recht, C ist nicht intuitiv - das war auch nie der Anspruch von Ritchie (s.o.) und ist somit nichts für Anfänger oder Sprachumsteiger, die gewohnt sind, dass ihnen alles mundgerecht gereicht wird.