ich hab folgende Frage, die ich trotz langem Suchen noch immer nicht im Netz gefunden hab (ehrlich gesagt weiss ich nicht mal genau, wie ich danach suchen soll )

Ich habe ganz viele Bedingungen für eine if-Schleife:

if (selection==1 || selection ==2 || selection==3 ... und das ganze geht bis ungefähr 30 weiter...)

Man sieht schon, dass das sehr umständlich zu notieren ist.

Meine Frage: Gibts da eine Schreibweise, mit der ich das vereinfachen kann???

Der Code ist leider historisch so gewachsen und es kommen immer noch weitere "selections" dazu. Auch sind manche selections nicht dabei (4, 7, 14-18...), weshalb ich andere Auswahlkriterien bisher noch nicht anwenden konnte.

Hat wer eine Idee, gibts da was?

Glg Robozer

if (selection==1 || selection ==2 || selection==3 ... und das ganze geht bis ungefähr 30 weiter...)

Man sieht schon, dass das sehr umständlich zu notieren ist.

Meine Frage: Gibts da eine Schreibweise, mit der ich das vereinfachen kann???

Der Code ist leider historisch so gewachsen und es kommen immer noch weitere "selections" dazu. Auch sind manche selections nicht dabei (4, 7, 14-18...), weshalb ich andere Auswahlkriterien bisher noch nicht anwenden konnte.

Refaktorieren?

Um Tastaturanschläge zu sparen geht auch ein switch/case

switch(selection){
case 1: case 2:
  // ...
  break;
case 4:
case 7:
case 14: case 15: case 16: case 17: case 18:
  //....
  break;
}

Nicht schön...aber minimalinvasiv.

Wenn es nur gelegentlich vorkommt, und sich die einführung von zus. Containern nicht recht lohnt, kann nat. auch ein bisschen spielen

template <int... i>
bool is_in(int v)
{
    bool result = false;
    bool res[sizeof...(i)+1] = { result = result || v == i ... };
    return result;
}

(das constexpr zu machen ist ein bisschen komplizierter).
Erweiterung auf ganze Zahlenbereiche ist ebenso möglich.

Anwendung

if ( is_in<4, 7, 14, 15, 16, 17, 18>(selection) )

bool activatableGroup = selection==1 || selection ==2 || selection==3;
if (activatableGroup)
	activate();
else if (printableGroup)
	printGroup();

Dann hat man auch einen Überblick welche selections in welchen Gruppen sind und wie darauf reagiert wird. Den is_in-Kram kann man noch zusätzlich verwenden.

Effektiv fasst du hier die selections in Gruppen mit gemeinsamen Eigenschaften zusammen. Diesen Gruppen sollte man einfach entsprechende Namen geben:

Gute Idee. Gruppe, das ist doch fast das gleiche Wort wie Menge. Menge ist sogar genauer, denn das Wort Gruppe impliziert auch eine Art Beziehung, die hier aber nicht gegeben ist. Hmm, Mengen nennt man im Englischen set. Irgendwo habe ich das Wort doch schon einmal gehört . Wenn man einem Element einer Menge etwas zuordnet, zum Beispiel eine Aktion, dann nennt der Mathematiker das eine Abbildung. Die englischen Mathematiker nennen es map. Wieder so ein Wort, dass ich auch schon woanders einmal gehört habe.

(Ich will mich nicht über den Vorschlag lustig machen, sondern nur zeigen, dass es der erste Schritt auf dem Weg zu meinem Vorschlag ist, denn als nächstes fragst du dich nämlich, ob man diese "Gruppen" nicht auch irgendwie formalisieren kann, a la campers is_in-Vorschlag und als übernachstes entwickelst du dann ein Konzept, wie man die Bindung von Gruppenelement an Aktion abstrahieren könnte.)

(wobei der Begriff in diesem Zusammenhang nicht einmal so falsch ist)

template <int... i>
bool is_in(int v)
{
    bool result = false;
    bool res[sizeof...(i)+1] = { result = result || v == i ... };
    return result;
}

(das constexpr zu machen ist ein bisschen komplizierter)

Ist kaum schwerer, nur mehr Boilerplate.

constexpr bool is_in(int) { return false; } // Anker
template <int i> constexpr bool is_in(int v) { return v==i; } // Aktion
template <int i, int a, int... b> constexpr bool is_in(int v)
{ return is_in<i>(v) || is_in<a, b...>(v); } // Verknüpfung

Der TE will aber mehr:

template <int L, int R> struct range {
  static constexpr bool check(int v) { return L<=v && v<R; }
};
template <int... i> struct one_of {
  static constexpr bool check(int v) { return is_in<i...>(v); }
};
template <int i> using single = range<i, i+1>; // ev. noch optimieren, dass == benutzt wird

struct impair { static constexpr bool check(int v) { return v%2; } }; // just for fun

template <typename T> constexpr bool is_in(int v) { return T::check(v); }
template <typename T, typename Q, typename... R> constexpr bool is_in(int v)
{ return is_in<T>(v) || is_in<Q, R...>(v); }

Jetzt kann er schreiben

for (int sel = 0; sel <= 20; ++sel) {
  bool a = is_in<4, 7, 14, 15, 16, 17, 18>(sel);
  bool b = is_in<single<4>, single<7>, range<14, 19>>(sel);
  bool c = is_in<one_of<4, 7>, range<14, 19>>(sel);
  assert(a==b&&b==c);
  assert((is_in<impair, single<2>>(sel) == sel%2||sel==2));
}

for (auto i : {1,2,3,5,6,9,22})
  if (selection == i)
  {
    dosomething();
    break;
  }

http://liveworkspace.org/code/2oA5y8$0

template <int i1>
constexpr bool is_in(int v)
{ return v == i1; }

template <int i1,
          int... in,
          typename = typename std::enable_if<sizeof...(in)>::type>
constexpr bool is_in(int v)
{ return v == i1 || is_in<in...>(v); }

(Unschön, aber so simpel wie es scheint ist es mir gar nicht gewesen)

Mit C++11 könnte man auch sowas machen:

for (auto i : {1,2,3,5,6,9,22})
  if (selection == i)
  {
    dosomething();
    break;
  }

if( std::set{1,2,3,5,6,9,22}.count(selection) )
   dosomething();

Klar, Performance-Killer, aber...

is_in;

2013:

template <int L, int R> struct range {
  static constexpr bool check(int v) { return L<=v && v<R; }
};
template <int... i> struct one_of {
  static constexpr bool check(int v) { return is_in<i...>(v); }
};
template <int i> using single = range<i, i+1>; // ev. noch optimieren, dass == benutzt wird

struct impair { static constexpr bool check(int v) { return v%2; } }; // just for fun

template <typename T> constexpr bool is_in(int v) { return T::check(v); }
template <typename T, typename Q, typename... R> constexpr bool is_in(int v)
{ return is_in<T>(v) || is_in<Q, R...>(v); }

is_in;

Ja, ich habe heute einen unlustigen Clown geabendgegessen

if( std::set{1,2,3,5,6,9,22}.count(selection) )
   dosomething();

Klar, Performance-Killer, aber...

performance killer ?
abgesehn davon das das set static const sein koennte

ist es beweisbar das die recursiven template loesungen welche hier gepostet wurden mit einer zur compile time unbekannten selection schneller sind?

ist es beweisbar das die recursiven template loesungen welche hier gepostet wurden mit einer zur compile time unbekannten selection schneller sind?

Schade, daß hier immer so ein Mist kommt.

#include <iostream>

int main()
{
    using namespace std;
    unsigned selection;
    cin>>selection;
    if(selection<31 &&
       selection["\0\0\1\1\0\1\0\1\0\0\0\1\0\1\0\0\0\1\0\1\0\0\0\1\0\0\0\0\0\1\0"])
        cout<<selection<<" ist eine Primzahl unter 32.\n";
}

kurze_frage schrieb:

ist es beweisbar das die recursiven template loesungen welche hier gepostet wurden mit einer zur compile time unbekannten selection schneller sind?

Schade, daß hier immer so ein Mist kommt.

Sieh dir mal deinen Code an. Flüchtigkeitsfehler?

Sieh dir mal deinen Code an. Flüchtigkeitsfehler?

Nö, läuft doch.
(Gebe ja zu, daß die Form ein Scherzchen ist. )
Wollte einwerfen, daß ein Arraynachgucker auch nicht gerade lahm ist.

Gebe ja zu, daß die Form ein Scherzchen ist.

Genau diese Form habe ich auch zum Spaß in einer Spielerei verwendet, aber ohne Escape-Sequenzen sondern mit den ASCII-Zeichen 0 und 1 und dafür dahinter ein -'0'. Ist einfacher zu lesen.