Array by reference

[Simon2]

MastaEda schrieb:

...GetData(int &len, unsigned char &data)...

Hi,

bist Du sicher, dass diese Funktion für die Array-Übergabe geeignet ist?
Wie Nexus empfinde ich das als hochgradig unüblich...
Außerdem: Vielleicht ist es gar nicht verkehrt, wenn Du 0-en zurückbekommst.

drakon schrieb:

const unsigned int len=256;
unsigned char buf[len];
//füllen
GetData(len,buf);

...

Für die Schnittstelle kann len allerdings nicht const sein...

Gruß,

Simon2.

[Nexus]

Simon2 schrieb:

Für die Schnittstelle kann len allerdings nicht const sein...

Stimmt, das kommt noch dazu.

Was ist das für eine Funktion, die die Länge möglicherweise verändert? Falls das wirklich für Arrays gedacht ist und die Länge geändert werden soll, geht das sowieso nur mit dynamischen Arrays. Aber selbst dann ist die Signatur komisch...

[MastaEda]

Nexus schrieb:

Simon2 schrieb:

Für die Schnittstelle kann len allerdings nicht const sein...

Stimmt, das kommt noch dazu.

Was ist das für eine Funktion, die die Länge möglicherweise verändert? Falls das wirklich für Arrays gedacht ist und die Länge geändert werden soll, geht das sowieso nur mit dynamischen Arrays. Aber selbst dann ist die Signatur komisch...

Es geht darum Daten einzulesen und in len steht dann die tatsächlich gelesene Anzahl.
Da das mit buf[0] und *buf nicht funktioniert scheint wohl die Funktion Macken zu haben...

[Nexus]

Sag doch einfach mal, was nicht funktioniert. Das, was du bis jetzt geliefert hast, ist keine Fehlerbeschreibung.

Fordert die Funktion selber genügend Speicher an oder musst du sicher sein, dass du ein genügend grosses Array hast? Solche Dinge sind eben gefährlich und können zu Pufferüberläufen führen.

[drakon]

Simon2 schrieb:

Für die Schnittstelle kann len allerdings nicht const sein...

Jop. War nicht ganz dabei. Bin gerade sowieso ziemlich genervt..

[Tachyon]

Die Schnittstelle stimmt nicht. Sie muss

GetData(size_t len, unsigned char *data);

lauten und nicht

GetData(size_t len, unsigned char &data);

unsigned int& kann nicht unsigned int* referenzieren...

[Simon2]

Nexus schrieb:

...Was ist das für eine Funktion, die die Länge möglicherweise verändert? Falls das wirklich für Arrays gedacht ist und die Länge geändert werden soll, geht das sowieso nur mit dynamischen Arrays. Aber selbst dann ist die Signatur komisch...

Also aus den reinen C-Umfeld ist mir das sattsam bekannt: len ist dabei ein "update-Parameter":
- Input: Länge des bereitgestellten Buffers
- Output: Länge der tatsächlich genutzen Einträge (natürlich <= Input)
Hat diverse Nachteile (z.B. weiß man bei output=input nicht, ob das nun tatsächlich alle Daten waren), ist aber trotzdem eine durchaus gängige Methode.
Das heißt: Die Länge des Buffers wird gar nicht verändert.

Das kann ich natürlich nicht 100%ig auch für diesen Fall sagen, aber ich halte es für sehr wahrscheinlich.

Gruß,

Simon2.

[Simon2]

Tachyon schrieb:

Die Schnittstelle stimmt nicht. Sie muss

GetData(size_t len, unsigned char *data);

lauten ...

Ich vermute ja auch, dass das eigentlich gemeint ist (allerding mit len als & oder ... aber andererseits fällt mir gerade kein Argument ein es so zu machen:

GetData(size_t& len, unsigned char &data) {
   for(size_t i=0; i<len && i<23 ; ++i) {
      (&data)[i] = 0x12;
   }
   len = i;   
}

Wäre das verboten/falsch/unmöglich?

Gruß,

Simon2.

[Simon2]

drakon schrieb:

Simon2 schrieb:

Für die Schnittstelle kann len allerdings nicht const sein...

Jop. War nicht ganz dabei. Bin gerade sowieso ziemlich genervt..

Mein herzliches Beileid!
Solche Sachen sind extrem ätzend...

*daumen-drück*

Gruß,

Simon2.

[MastaEda]

Tachyon schrieb:

Die Schnittstelle stimmt nicht. Sie muss

GetData(size_t len, unsigned char *data);

lauten und nicht

GetData(size_t len, unsigned char &data);

unsigned int& kann nicht unsigned int* referenzieren...

Sie kann aber die Adresse des ersten Wertes eines Arrays übergeben.

Da ich die Funktion aus einer Dll aufrufe, dessen Quellcode mir nicht vorliegt, werd ich mal den Entwickler kontaktieren.

[Nexus]

Tachyon schrieb:

unsigned int& kann nicht unsigned int* referenzieren...

Aber unsigned int und dann indirekt den Zeiger über dessen Adresse. Wie kommst du eigentlich auf size_t ?

Simon2 schrieb:

Ich vermute ja auch, dass das eigentlich gemeint ist (allerding mit len als & oder ... aber andererseits fällt mir gerade kein Argument ein es so zu machen:

Daran habe ich eben auch gedacht, also dass intern die Adresse genommen wird und so die nächsten Elemente des Arrays gelesen werden können.

MastaEda schrieb:

Da ich die Funktion aus einer Dll aufrufe, dessen Quellcode mir nicht vorliegt, werd ich mal den Entwickler kontaktieren.

Hast du denn keine Dokumentation dazu? Falls doch, was sagt die zu den erwarteten Parametern?

[MastaEda]

Danke für die Antworten.
Es hat sich jetzt herausgestellt dass die Funktion in der DLL anderweitig fehlerhaft ist und das mit dem buf[0] bzw *buf funktionieren würde.

[Belli]

MastaEda schrieb:

Es hat sich jetzt herausgestellt dass ... das mit dem buf[0] bzw *buf funktionieren würde.

Das entspricht ja auch der Signatur der Funktion. Aber so kann man kein Array übergeben.

[MastaEda]

Belli schrieb:

MastaEda schrieb:

Es hat sich jetzt herausgestellt dass ... das mit dem buf[0] bzw *buf funktionieren würde.

Das entspricht ja auch der Signatur der Funktion. Aber so kann man kein Array übergeben.

Doch wie schon erwähnt wird die Adresse, des ersten Arrayelements übergeben. Mit Hilfe der Längen-Variablen weiß die Funktion dann wieviel Speicher beschrieben werden darf.

[Belli]

Das ist nicht ganz korrekt. Genaugenommen wird eine Referenz auf ein char übergeben. Die Adresse muß die Funktion mittels Adressoperator (zB unsigned char *pt = &data) selbst ermitteln.

[Nexus]

Und es wird niemand daran gehindert, nur einen einzelnen unsigned char zu übergeben. Okay, bei einem Zeiger könnte man auch einen einzelnen Wert referenzieren, aber da denkt man schon eher an ein Array.

Naja, normalerweise hat man das Problem eh nicht, da man mit Containern arbeitet. Da kann man sich auch veränderliche Dimensionsparameter sparen...
Bei einer DLL würde ich aber wenigstens eine C-Style-Funktion erwarten.