case label does not reduce to an integer constant??

pumuckl

Hallo mal wieder.
Ich steh grade wie der Ochs vorm Berg:

const int nSetFiles = //...

  const int MP_NOMPI  = nSetFiles + 1;
  const int MP_DIRECT = nSetFiles + 2;
  const int MP_DATA   = nSetFiles + 3;

//...

  switch (f) {
  case MP_DATA: file_name += "data.root"; break; //Zeile 69
  case MP_NOMPI: file_name += pytFileName(pVersion, nompiSet, nompiParam.PARP81min); break;
  case MP_DIRECT: file_name += pytFileName(pVersion, dirSet, dirParam.PARP81min); break;
  default: file_name += pytFileName(pVersion, pSet, P81min + f);
  }

//...

Sagt der Compiler:

####/mctune_parabola.h:69: error: case label
   does not reduce to an integer constant
####/mctune_parabola.h:70: error: case label
   does not reduce to an integer constant
####/mctune_parabola.h:71: error: case label
   does not reduce to an integer constant

Was soll das?

Simon2

Compilerfehler ?

Bei mir (gcc) tut's das tadellos...

Gruß,

Simon2.

pumuckl

*seufz* ich hatte noch Hoffnung, dass es NICHT am Compiler liegt. Ich HASSE das Teil -.- aber Umstieg ist leider auch nicht moeglich...

camper

Wird nSetFiles durch einen konstanten Ausdruck initialisiert? evtl. kannst du ja noch versuchen, die Konstanten statisch zu machen.

pumuckl

nSetFiles wird durch eine Summe anderer Konstanten initialisiert, die aber abhaengig von Funktionsparametern aus einem globalen Array geholt werden.

camper

pumuckl schrieb:

nSetFiles wird durch eine Summe anderer Konstanten initialisiert, die aber abhaengig von Funktionsparametern aus einem globalen Array geholt werden.

Dann sind diese Konstanten keine konstanten Ausdrücke (und ihr Wert kann folglich nicht bereits beim Compilieren bestimmt werden) und das ganze ist kein Compilerfehler.

Simon2

pumuckl schrieb:

...aber abhaengig von Funktionsparametern ...

OK, das ist was Anderes !
Das wird mit meinem Compiler bestimmt auch nicht funktionieren.

Als "Eselsbrücke" merke ich mir immer: Kann der Compiler das Teil schon ersetzen ? => Dann geht's, sonst nicht.

.. und Funktionsaufrufe kann er natürlich nicht ersetzen (woher soll er wissen, mit welchen Parametern irgendwann mal ein Modul diese Funktion aufrufen wird ?).
Sagen wir mal so: Wenn Du mit der Bestimmung wirklich flexibilisieren (und nicht nur Schreibarbeit sparen oder Übersichtlichkeit erzeugen) willst, machst Du dem Compiler einen Strich durch die Rechnung.

Gruß,

Simon2.

CStoll

Und wenn du wirklich Wert darauf legst, daß die case-Marken von deinen Funktionsparametern abhängen, müsstest du eventuell die Berechnung invertieren:

const int nSetFiles = //...

  const int MP_NOMPI  = 1;
  const int MP_DIRECT = 2;
  const int MP_DATA   = 3;

//...

  switch (f - nSetFiles) {
  case MP_DATA:
    file_name += "data.root"; break;
  case MP_NOMPI:
    file_name += pytFileName(pVersion, nompiSet, nompiParam.PARP81min); break;
  case MP_DIRECT:
    file_name += pytFileName(pVersion, dirSet, dirParam.PARP81min); break;
  default:
    file_name += pytFileName(pVersion, pSet, P81min + f);
}

(in der Version kann der Compiler alles auswerten, was er benötigt)

pumuckl

danke, das wird gehen. Supi

Simon2

CStoll schrieb:

Und wenn du wirklich Wert darauf legst, daß die case-Marken von deinen Funktionsparametern abhängen, müsstest du eventuell die Berechnung invertieren:...

Coole Idee !!!

Ich hab' sowas zwar prinzipiell schon oft programmiert, aber noch nie als "Trick, case-Marken von Funktionsparametern abhängig zu machen" interpretiert !
Spannend !! (s.Sig. )

Danke,

Simon2.