3. [(static) const member array] initialisierung verzwickt

[(static) const member array] initialisierung verzwickt

  • M

    Problem:

    //A.h
namespace A
{
  const int EAST  = 0;
  const int NORTH = 1;
  const int WEST  = 2;
  const int SOUTH = 3;

  const int MAX_DIR = 3;
}
//B.h
class B
{
public:
  B() {}
protected:
  const double array1[A::MAX_DIR+1];  
  static const double array2[A::MAX_DIR+1];  //oder so, soll mir egal sein
};
//B.cpp
//irgendwas wie:
array1[A::EAST  ] = 1.0;
array1[A::NORTH ] = 2.0;
array1[A::WEST  ] = 3.0;
array1[A::SOUTH ] = 4.0;
array2[A::EAST  ] = 1.0;
array2[A::NORTH ] = 2.0;
array2[A::WEST  ] = 3.0;
array2[A::SOUTH ] = 4.0;

    habe da schon hin und her probiert, aber nichts davon hat der compiler geschluckt. hier im forum wurde die sachemeist mit dem elementinitialisierer gelöst, was hie rnicht geht, weil der index abhängig des namespaces ist und durchaus mal geändert werden kann.

    mich erschleicht das böse gefühl, dass das nicht funzt...

    edit: rasch die array groesse gefixed

    0
  • C

    Erstens ist der Index eines Arrays ein normaler int/size_t Wert, die Namen EAST, NORTH etc. sind also zur Initialisierung nicht wirklich nötig.

    Und zweitens:

    const double B::array2[A::MAX_DIR]={1,2,3,4};

    (das Array1 müsstest du im Ctor initialisieren, aber da bin ich mir auch nicht sicher, wie)

    0
  • M

    naja, hier im BSP vielleicht nicht, aber bei uns im Programm arbeiten wir ausschließlich mir EAST, WEST, NORTH, SOURTH, etc. (in 3D haben wir z.B. 15 bzw 27 richtungen). dadurch koennen wir dieselben code fragmente letztlich für verschiedene berechnungsverfahren verwenden.
    und wenn einer meiner HIWIS dann so späße wie = { 1, 2, 3, 4 } (<- was ich der elementinitialisierer lösung gemient habe 😉 ) übrigens mit einbaut, dann ist das mehr als eine katastrphe, denn evtl ist es im anderen modell durch andere EASt, WESt zuweisung ja sowas wie = { 1, 3, 2, 4 }. und sowas findet man nur mit gehörigem zeitaufwand.
    nein, nein. ich brauche es exakt wie beschrieben.
    hat noch ein anderer eine idee

    0
  • C

    muffmolch schrieb:

    und wenn einer meiner HIWIS dann so späße wie = { 1, 2, 3, 4 } (<- was ich der elementinitialisierer lösung gemient habe 😉 ) übrigens mit einbaut, dann ist das mehr als eine katastrphe, denn evtl ist es im anderen modell durch andere EASt, WESt zuweisung ja sowas wie = { 1, 3, 2, 4 }. und sowas findet man nur mit gehörigem zeitaufwand.

    Wenn jemand die Zuordnungen dort ändert, hast du auf jeden Fall ein Problem (besonders wenn du Daten zwischen verschiedenen Versionen austauschen willst).

    Randfrage: Wozu brauchst du's?

    0
  • S

    BTW: Deine Arrays sind jeweils um ein Element zu klein.

    MfG SideWinder

    0
  • S

    Eine solche Initialisierung ist in C++ soweit ich das jetzt in Erfahrung bringen konnte *nicht* möglich. Warum das so ist kann ich allerdings nicht sagen, in den meisten Fällen reicht wohl sowieso ein static-Array.

    Sollen tatsächlich unterschiedliche Konstruktoren das Array auf unterschiedliche Werte setzen hast du offenbar Pech gehabt.

    MfG SideWinder

    0
  • D

    Imho hast du sowieso ein Problem, wenn Du dich darauf verlaesst, dass die Elemente in A VOR der (statischen) Membervariable in B intialisiert werden (weil eben das nicht definiert ist).

    Aber als Loesung vielleicht folgendes:

    namespace A
{
  const int EAST  = 0;
  const int NORTH = 1;
  const int WEST  = 2;
  const int SOUTH = 3;

  const int MAX_DIR = 4;
}
//B.h
class B
{
public:
  typedef std::vector<double> DVec;
  DVec const array2;

  B();

private:
  DVec const InitializeMe();
};

B::B()
    : array2(InitializeMe())
{
}

B::DVec const B::InitializeMe()
{
    DVec v(A::MAX_DIR);
    v[A::EAST] = 1.0;
    v[A::NORTH] = 2.0;
    v[A::WEST] = 3.0;
    v[A::SOUTH] = 4.0;
    return v;
}

    Also einfach eine Methode zum initialisieren. Geht auch mit einem statischen Buffer darin und einem C-sytle Array bzw. wie in deiner 2. Version für eine statische Membervariable.

    Gruss,
    DeSoVoDaMu

    0
  • M

    DeSoVoDaMu schrieb:

    Imho hast du sowieso ein Problem, wenn Du dich darauf verlaesst, dass die Elemente in A VOR der (statischen) Membervariable in B intialisiert werden (weil eben das nicht definiert ist).

    bisher hatten wir damit noch keine probleme und das paket existiert seit 5 jahren 😉

    DeSoVoDaMu schrieb:

    Also einfach eine Methode zum initialisieren. Geht auch mit einem statischen Buffer darin und einem C-sytle Array bzw. wie in deiner 2. Version für eine statische Membervariable.

    ja, so hab eich es derzeit auch implementiert...
    hatte schonmal das problem mit nem static const array in nem namespace und da musste und v.a. konnte ich auch ne fixe reihenfolge definieren.

    schade... so sieht es eben etwas dahingemurcksz aus, aber was soll's.

    @CStoll:
    wir programmieren u.a. einen interaktiven strömungssimulator auf der basis von der lattice boltzmann methode. naja und um es kurz zu fassen: es gibt diverse LB modelle und dort gibt es im wesentlichen diskrete richtungen die mit 0-X definiert sind. ein ähnliches modell hat auch 0-X richtungen, aber eine andere nummerieung. geomtrisch eineindeutig sind eben himmelsrichtungen. und somit dienen die namespace zur identigizieung des jeweiligen geschwindigkeitsindex... die namesräume sind natürlich wesentlich grösser und mächtiger... aber man abrajiert eben bei fragen hier aufs wesentliche und dann schaut es meistens sinnlos aus... not my fault 😃

    0
Anmelden zum Antworten