D
Bitte ein Bit schrieb:
Ähh ja. Und ein void Test(const uint8_t× Data) funktioniert da nicht?
Wenn du damit meinst, dass ich ein solches Array vom Caller bereitstellen lassen soll - genau das ist der Punkt. Genau das soll der Caller nicht brauchen.
dachschaden schrieb:
Dann müssen(!) alle Elemente auf TRUE gesetzt sein. Der Programmierer soll kein eigenes TRUE-Array erstellen (womöglich noch auf dem Stack!), das ist redundant und fehleranfällig. Lieber einmal ordentlich geinlined.
Bitte ein Bit schrieb:
Aber ich glaube ich weis worauf du hinaus willst. Du wirst mich vermutlich steinigen wenn ich empfehle: inline const uint8_t× GetData().
Wieso? Der Effekt über die externe globale Variable, die ich jetzt habe, sorgt zusätzlich dafür, dass ich garantiert keine doppelten Felder in Objektdateien rumliegen habe. Ich habe ein Array, statisch und konstant, für alle Fälle, solange eine bestimmte Größe nicht überschritten wird (und auch hier kann ich noch eine Prüfung einfügen - ein bisschen redundant immer noch, aber soweit ich sehe besser als die Alternativen).
Mit einer solchen Funktion würde ich aber in jeder Übersetzungseinheit ein solches Array erzeugen. Weil die Funktion inlined wird, erhält jede TU ihre eigene Kopie, mit einem eigenen statischen Speicherbereich. Das ist auch reichlich bala-bala.
Bitte ein Bit schrieb:
Reden wir hier von Multithreading oder Multitasking?
Ich rede von Multithreading.
Das sind sehr oft aufgerufene Funktionen, sozusagen die wohldefinierte Schnittstelle, über die Daten in Speicherstrukturen eingefügt werden. Wegen so einer Kinderkacke einen Lock für jede Instanz einer Arraygröße zu erstellen sollte ebenso komplett unnötig sein wie die Erzeugung eines Arrays bei jedem Call.
Bitte ein Bit schrieb:
Evt. auf einem Mikrocontroller?
Auch. Es handelt sich um ein Modul einer größeren Bibliothek. Und verschiedene Teile davon laufen auf verschiedenen Systemen.
Bitte ein Bit schrieb:
Ab C11 existieren rudimentäre Threading Strukturen (Mutex, Condition Vatiable,...)
Das Problem ist nicht, dass ich diese nicht verwenden kann.
Das Problem ist, dass ich diese für erwähnte Kinderkacke nicht verwenden will. Um ein Feld, welches nicht doppelt angelegt werden soll, ordentlich zu initialisieren, soll ich ein Lock verwenden, weil die Sprache mir nicht erlaubt, statisch einen Nicht-Null-Standardwert zuzuweisen? Da gackern ja die Hühner!
(Außerdem bin ich mir nicht sicher, ob Visual Studio C11 soweit unterstützt. Der GCC hat eine Extension, um so einen Standardwert zuweisen zu können, aber für Windows bringt mir das natürlich nichts.)
Bitte ein Bit schrieb:
Und Makro Tricks funktionieren da nicht?
Der Grund, warum ich überhaupt erstmal nicht weiß, wie viele Elemente ich drin habe, ist weil ich mich streng genommen bereits in einem Makro befinde. Die Anzahl der Elemente ist ganz leicht über ein sizeof auf ein Feld in einer angegebenen Struktur zu ermitteln, aber wenn ich den Code schreibe, weiß ich nicht, wie viele Elemente da eigentlich drin sind. Die Größe ist zur Kompilierzeit bekannt, aber nicht zur Programmierzeit.
Wenn du Maktotricks kennst, über die man Initialisierungslisten generieren kann, sag' mir Bescheid. Bisher habe ich noch nichts gefunden - aber seit ich die obige Version eingefügt habe, habe ich zugegebenermaßen auch nicht mehr nachgeschaut.
Bitte ein Bit schrieb:
Weist du zur Compilezeit wie groß dein Feld ist? Ich habe schon gesehen wie man mittels eines #include aus Textdateien zur Compilezeit ein Enum generierte und so an die Anzahl der Elemente kam und eine dazugehörige Variable.
Was bringt mir das, wenn ich doch nur wieder an der Initialisierungsliste scheitere? Das Array generiere ich in der passenden Größe ohne Probleme, die Zuweisung der Standardwerte ist's, wo's bricht.
Aber wie gesagt, derzeit arbeite ich lieber mit der externen Variabel. Ich werde wahrscheinlich noch ein define einfügen, über das man die maximale Anzahl an Elementen steuern kann, dann habe ich noch eine Chance, auf Reads außerhalb meines Arrays zu reagieren.
