Ich hab eine Fifo-Klasse und muss das Array definieren. Ich bekomme das
leider nicht hin. Beim Initialisieren vom Fifo möchte ich festlegen, wie
groß der Fifo(Array) sein soll, weil ich welche mit unterschiedlichen
Größen habe. Den Größenparameter übergebe ich im Konstruktor.
Ich muss das Array aber auch vorher im Header definieren, damit ich es
anderswo einbinden kann.
Wie krieg ich das hin mit unterschiedlichen Initialwerten? Oder muss ich
mit Konstanten arbeiten und dann z.B. fifo1.h/fifo1.cpp,
fifo2.h/fifo2.cpp ... mit Festwerten in dem Header initialiseren? Das
wäre ja ziemlich umständlich.
Headerdatei:
1
#ifndef FIFO_H
2
#define FIFO_H
3
4
#include "mbed.h"
5
6
// Headerdatei
7
8
class Fifo {
9
public:
10
uint8_t Put (uint16_t element);
11
uint8_t Get (uint16_t *element);
12
void Clear ();
13
uint16_t Anzahl ();
14
uint8_t RingBuffer(uint16_t size);
15
private:
16
uint16_t buffer_size;
17
uint16_t buffer_mask;
18
uint16_t data[buffer_size]; // <--- Hier ist der Fehler
Anfänger schrieb:> weil ich welche mit unterschiedlichen> Größen habe. Den Größenparameter übergebe ich im Konstruktor.
entweder mit C++ Templates arbeiten oder mit malloc den Speicher im
Konstruktor anfordern.
Anfänger schrieb:> meinst Du so?
ja, denke aber ans Freigeben vom Speicher und das der Kopierkonstruktor
und der Zuweisungsoperator jetzt für deine Klasse nicht mehr sinnvoll
arbeiten.
und anstelle von malloc benutzt du natürlich new!
Es gäbe noch eine dritte Variante.
In der stellt man sich auf den Standpunkt, dass gar nicht die FiFo
Klasse das Array bereitstellen muss, sondern derjenige, der ein FiFo
Objekt erzeugt dafür zuständig ist. Im Konstuktor muss man dann
mitgeben, welches Array zu benutzen ist und dessen Länge. Das Objekt
merkt sich dann einen Pointer auf dieses Array.
Ist nicht unbedingt schön und geht auch ein wenig am OOP Prinzip vorbei.
Peter II schrieb:> Karl Heinz schrieb:>> und anstelle von malloc benutzt du natürlich new!>> was ist das gegenstück zu realloc?
gibt es nicht.
Array wegwerfen und neu allokieren. Hat dann auch den Vorteil, dass
entsprechende Konstruktoren bzw. Destruktoren aufgerufen werden, wenn es
sich um ein Array aus einem Objekttyp handelt.
Allerdings: er wird in seinem Programm auf einem µC kein realloc
brauchen. :-)
Karl Heinz schrieb:> Es gäbe noch eine dritte Variante.> In der stellt man sich auf den Standpunkt, dass gar nicht die FiFo> Klasse das Array bereitstellen muss, sondern derjenige, der ein FiFo> Objekt erzeugt dafür zuständig ist. Im Konstuktor muss man dann> mitgeben, welches Array zu benutzen ist und dessen Länge. Das Objekt> merkt sich dann einen Pointer auf dieses Array.
Ich hab mich für diese Variable entschieden, weil der Fifo auf einem
Mikrocontroller laufen soll und mit malloc und new bin ich mir nicht so
sicher, ob das gut ist in nem uC. Deshalb hab ich mir jetzt das
ausgedacht:
Jetzt krieg ich aber die Fehlermeldung:
No instance of constructor Fifo::Fifo matches the argument list
uint16_t fifo_array1[FIFO1_LENGTH];
Was bedeutet denn das? Übergebe ich nicht richtig die Parameter an den
Konstruktor?
Aoperator=(constA&rhs);// not implemented by intention
16
};
17
18
19
voidA::setElement(size_tindex,intvalue)
20
{
21
if(index<len_)
22
dataSpace_[index]=value;
23
}
24
25
intA::getElement(size_tindex)const
26
{
27
if(index<len_)
28
return_dataSpace[index];
29
30
return-1;
31
}
32
33
#define DATA_LEN 8
34
35
intmain()
36
{
37
intmySpace[DATA_LEN];
38
AmyData(mySpace,DATA_LEN);
39
inti;
40
41
for(i=0;i<DATA_LEN;i++)
42
myData.setElement(i,2*i);
43
44
for(i=0;i<DATA_LEN;i++)
45
printf("%d %d\n",i,myData.getElement(i);
46
}
Noch einfacher gehts nicht. Was immer du an diesem Code nicht verstehst
ist ein Hinweis darauf, dass dir absolute Grundlagen fehlen. Auch wenn
in Desktop-C++ Pointer nicht mehr ganz so häufig gebraucht werden, ist
die Array-Pointer Dualität und Pointerarithmetik nach wie vor
unabdingbares Basiswissen. Speziell wenn man aufgrund
Nebenbeschränkungen dynamische Speicherallokierung nicht benutzen
will/kann und daher auch nicht die STL Containerklassen benutzen kann.
Karl Heinz schrieb:> Noch einfacher gehts nicht. Was immer du an diesem Code nicht verstehst> ist ein Hinweis darauf, dass dir absolute Grundlagen fehlen.
Mag sein, aber ein Fifo ist das nicht und der TE will einen Fifo haben.
Hier fehlt ein Semikolon:
gonso schrieb:> Karl Heinz schrieb:>> Noch einfacher gehts nicht. Was immer du an diesem Code nicht verstehst>> ist ein Hinweis darauf, dass dir absolute Grundlagen fehlen.>> Mag sein, aber ein Fifo ist das nicht und der TE will einen Fifo haben.
Schön.
Dann soll er einen schreiben.
Ich bin nicht sein persönlicher unentgelticher "Schreib mal Code für
mich". Ich zeig ihm gerne das, was ihm syntaktisch fehlt, aber umsetzen
muss er es alleine.
> Hier fehlt ein Semikolon:
Gratulation. Soll vorkommen, dass man kleinere Syntaxfehler macht, wenn
man Code direkt hier eintippt.