Bug bei Struct (Dot-Notation)

  • Mir ist gerade ein Bug aufgefallen.

    Wenn man eine Struktur mit einem Datentyp-Array erstellt und dann versucht auf ein Element aus dem Array über eine Variable zuzugreifen, so wird immer 0 ausgegeben (@error = 3).

    Es sei denn man wandelt die Variable in eine Zahl um.

    Hier mal ein Beispiel-Script:

    Könnt ihr das bestätigen?

  • Kann ich bestätigen aber ein Bug ist es Definitionsgemäß meiner Meinung nach nicht.
    Denn: Ein Bug wäre ein Abweichen von einem vordefinierten Verhalten.
    Die Dot-Notation bei DllStruct und insbesondere die Ansprache von Array-Indizes über die Klammer ist jedoch überhaupt nicht definiert - zumindest kann ich in der Hilfe nix hierzu finden.

    Genauso sehen es die AutoIt-Devs auch.

    Es bleibt also ein Austesten undokumentierten Verhaltens und da du diese Variante anscheinend ja dennoch aktiv verwenden willst, wollen wir wenigstens einen Workaround zu deinem Problem finden.

    Die Lösung hierzu lautet: konsequent Doppelklammer nutzen:

    AutoIt
    Global $tStruct = DllStructCreate('uint64 data[3];')
    
    ; Zuweisung und Abfrage ueber eine Variable funktioniert nicht
    For $i = 1 To 3
        $tStruct.data(($i)) = 1234
        ConsoleWrite('@error: ' & @error & ' ')
        ConsoleWrite('$tStruct.data($i) = ' & $tStruct.data(($i)) & @CRLF)
    Next
  • Die Lösung hierzu lautet: konsequent Doppelklammer nutzen

    Ok! Das ist noch besser, als die Int- oder Number-Version. Danke! :)

    Ich könnte ja auch DllStruct(G/S)etData benutzen, um die Indizes anzusprechen, aber ich finde die Klammern ganz gut und leserlich im Code.

    Ich kann auch nicht verstehen, warum sich die Devs dagegen aussprechen.

  • Mal eine ganz blöde Frage zu den Structs, wenn ichs richtig sehe hier, gibt die Zahl in den Klammern, die Anzahl der Elemente an. Sprich:

    struct;char Name[4];char id[36];endstruct

    Beinhaltet im Bereich Name 4 Elemente und id 36 Elemente, richtig?

    Oder ist das nur beim Typ "data" der Fall und meine bisherige Annahme, das dies die maximale Zeichenlänge angibt, ist richtig?

    Einmal editiert, zuletzt von Moombas (2. Dezember 2022 um 09:18)

  • Beinhaltet im Bereich Name 4 Elemente und id 36 Elemente, richtig?

    Genau.

    Die Zahl in Klammern definiert ein festes Array dieses Datentyps mit der entsprechenden Anzahl an Elementen.

    Das ist klassische C-Syntax und im Speicher stehen diese Elemente einfach hintereinander.

    meine bisherige Annahme, das dies die maximale Zeichenlänge angibt

    Ist auch richtig. Man kann halt nur soviel Zeichen schreiben wie Platz im Char-Array ist.

    Man muss aber nicht so viele schreiben.

    Wenn es weniger werden sollen ist der String halt nullterminiert und gibt so dass vorzeitige Ende an.

    Im Speicher verbraucht es dennoch soviel Platz wie das Array von der Gesamtgröße her definiert wurde. egal ob man nur ein Zeichen reinschreibt oder 100.

  • struct;char Name[4];char id[36];endstruct

    Beinhaltet im Bereich Name 4 Elemente und id 36 Elemente, richtig?

    Richtig, wobei noch zu beachten ist, dass die DllStruct 1-basiert und ein Array 0-basiert ist!

    Ok! Das ist noch besser, als die Int- oder Number-Version. Danke! :)

    Aber auch nicht weniger inkonsistent! Bei der Suche nach "double brackets" habe ich weder im bugtracker noch in den einschlägigen Foren etwas dazu gefunden.

    Die Dot-Notation bei DllStruct und insbesondere die Ansprache von Array-Indizes über die Klammer ist jedoch überhaupt nicht definiert

    Schade eigentlich, dass sich da niemand für interessiert bzw. eine Definition forciert. Genau wie bei ObjCreateInterface, damit hatte ich mich über ein Jahr beschäftigt, und einige Dinge sind mir immer noch unklar. Nicht bezüglich der M$-Dokumentation der Funktionen, die ist astrein, aber bzgl. einiger "Ungereimtheiten" in der Implementierung.

    Ich habe immer mehr das Gefühl, dass, und das ist nicht nur bei den Programmiersprachen bzw. -techniken so, bei 90% der Entwicklung stehen geblieben wird, weil die letzten 10% Arbeit um es RICHTIG zu machen zu viel Aufwand erfordern...oder zu viel Skill bzw. knowhow...

    Und leider sind die "Spezialisten" dafür SEHR dünn gesät. Oder auf die wird nicht gehört...