Enum + Logik^^



  • 1.) hmm naja gut, aber die reglungwäre doch möglich oder?
    2.) Was ist ein Guter Einsatzort für enumatoren?



  • Wikinger75 schrieb:

    2.) Was ist ein Guter Einsatzort für enumatoren?

    Der Name sagts ja schon.. Aufzählungen. Sachen, die zur Laufzeit nur die Zustände annehmen können. Irgendwelche Fehlerflags z.B.



  • Nexus schrieb:

    Enumerationen haben den Sinn, einen Typen kennzuzeichnen, der nur eine gewisse Anzahl vorgegebener Stati annehmen kann. Nimm doch ein float , int oder was weiss ich, aber kein enum .

    Tun sie doch auch bei ihm. Sein Border kann dünn, dick, fett etc. sein !?

    Wenn er nur bestimmte Zustände für die Dicke will, dann ist enum hier genau richtig.


  • Administrator

    Oder zum Beispiel Warnstufen:

    class Log
    {
    public:
      enum Level
      {
        MESSAGE,
        WARNING,
        ERROR,
        FATAL
      };
    
      // ...
    };
    

    Enums werden vor allem dazu verwendet, um magische Nummern zu entfernen. Zum Beispiel wenn ein Modus über eine ID eingestellt wird, dann nimmt man ein Enum, weil die ID nichts über den Modus aussagen würde.

    set_mode(394); // <- sagt einem nichts
    set_mode(BLEND_MODE); // <- sagt einem deutlich mehr
    

    Aber bei zum Beispiel sowas:

    set_border_thickness(10); // <- da braucht es nichts mehr, ist schon alles klar.
    

    Ich hoffe das hilft weiter.

    Grüssli



  • Wikinger75 schrieb:

    2.) Was ist ein Guter Einsatzort für enumatoren?

    Der Name sagts ja schon.. Aufzählungen. Sachen, die zur Laufzeit nur die Zustände annehmen können. Irgendwelche Fehlerflags z.B.

    ahso jetzt versteh ich endlich den sinn von enumatoren xD
    Also wäre zumbeispiel, damit ich das richtig verstanden hab das hier ein guter einsatz:

    enum MONAT 
    {
       JANUAR=1;
       FEBRUAR;
       MAERZ;
       APRIL;
       MAI;
       JUNI;
       JULI;
       AUGUST;
       SEPTEMBER;
       OKTOBER;
       NOVEMBER;
       DEZEMBER;
    };
    

    Damit könnte jetzt nur einer dieser Werter übergeben werden und eine Funktion könnte damit fehlerfrei ein Datum erzeugen, da er hier kein 13 eintippen kann und sich an die Konstanten halten muss, so kann praktisch kein ungültiger wert reinkommen. Hab ichs so richtig verstanden?


  • Administrator

    Wikinger75 schrieb:

    Damit könnte jetzt nur einer dieser Werter übergeben werden und eine Funktion könnte damit fehlerfrei ein Datum erzeugen, da er hier kein 13 eintippen kann und sich an die Konstanten halten muss, so kann praktisch kein ungültiger wert reinkommen. Hab ichs so richtig verstanden?

    Ein falscher Wert kann trotzdem ganz leicht reinkommen. Aber für den Benutzer der Bibliothek ist es womöglich lesbarer:

    set_month(3); // fängt es bei 0 an, dann wäre das April, bei 1 dann März, was nun?
    set_month(APRIL); // alles klar!
    

    Eben, das eliminieren von magischen Nummern.

    Grüssli



  • Wikinger75 schrieb:

    1.) hmm naja gut, aber die reglungwäre doch möglich oder?

    Welche Regelung?

    Wikinger75 schrieb:

    2.) Was ist ein Guter Einsatzort für enumatoren?

    Wie von drakon gesagt Aufzählungen. Um es zu verdeutlichen, einige Beispiele:

    • Webseiten-Design: Klassisch, kitschig-pink, metallisch.
    • Betriebssystem: Windows, Mac oder Linux.
    • Raumschifftyp: Jäger, Korvette, Sternenzerstörer.

    Irgendwas halt, das keinen wirklichen Bezug zu einer Zahl hat und leicht über den Konstantenbezeichner angesprochen werden soll. Kann manchmal als Erweiterung von bool angesehen werden, bei dem nur zwei Zustände möglich sind.

    KasF schrieb:

    Wenn er nur bestimmte Zustände für die Dicke will, dann ist enum hier genau richtig.

    Finde ich nicht. Er will die einzelnen Werte schliesslich als Zahlen behandeln und ihnen sogar Zahlen zuweisen. Zudem hat er so viele Schritte, die sich voneinander jeweils gleich stark unterscheiden.

    Wikinger75 schrieb:

    Also wäre zumbeispiel, damit ich das richtig verstanden hab das hier ein guter einsatz: [...] Hab ichs so richtig verstanden?

    Ja, genau.

    P.S. Nächstes Mal schicke ich den Beitrag ab, ohne 5 mal auf "Vorschau" zu klicken. :p



  • Dravere schrieb:

    Eben, das eliminieren von magischen Nummern.

    Und die dadurch entstehende Flexibilität. Nicht nur, dass man sich die Nummer nicht mehr merken muss, sondern man kann auch bequem einen neuen Enumerator zwischen die bestehenden einschieben, ohne dass sich der Code an anderen Stellen ändert.



  • Ah gut dan ist alles geklärt^^
    Jetzt seh ich eig. erst das praktische in enum^^

    P.S. Nächstes Mal schicke ich den Beitrag ab, ohne 5 mal auf "Vorschau" zu klicken. :p

    LOL 😃



  • Dravere schrieb:

    Aber bei zum Beispiel sowas:

    set_border_thickness(10); // <- da braucht es nichts mehr, ist schon alles klar.
    

    Jetzt weiß man doch trotzdem nicht, ob 10 dick oder dünn ist.

    Nexus schrieb:

    Er will die einzelnen Werte schliesslich als Zahlen behandeln

    Wissen wir doch gar nicht, ob er das will. 🙂

    Mit int, float etc. könnte er "unbegrenzt" große Breiten angeben, das will man aber unter Umständen natürlich nicht.



  • Nexus schrieb:

    ohne dass sich der Code an anderen Stellen ändert.

    Nicht wenn man an diesen anderen Stellen ausschließlich mit dem ENUM arbeitet.

    Aber, irgendwo tief in seinem Code müssen den enums Werte zugeordnet werden, um die Breite zu setzen, da führt kein Weg dran vorbei, aber das soll einem ja nicht davon abhalten den Code auf Client-Seite mit ENUMS "schön" zu machen.



  • KasF schrieb:

    Jetzt weiß man doch trotzdem nicht, ob 10 dick oder dünn ist.

    Das ist aber eh relativ..

    So:

    set_border_thickness_in_pixel(10);
    

    🙂



  • drakon schrieb:

    set_border_thickness_in_pixel(10);
    

    Da war aber nun stark gepokert 😃



  • KasF schrieb:

    Wissen wir doch gar nicht, ob er das will. 🙂

    Mit grosser Wahrscheinlichkeit aber schon: 😉

    Wikinger75 schrieb:

    was die dicke eines Rahmens bestimmen soll von 1 bis 10.
    1 ist ein Relatib dünner und 10 ein relativ größer rahmen (is ja auch klar!).
    Wie sollte ich diese benenen, da er Sinnvolle namen sein sollten und nicht so wie ich schrieb...

    3.)
    Kann dem Aufzäglungstyp auch eine zahl übergeben werden?

    KasF schrieb:

    Mit int, float etc. könnte er "unbegrenzt" große Breiten angeben, das will man aber unter Umständen natürlich nicht.

    Das Problem hast du aber immer bei den arithmetischen Typen. Du willst für irgendwas eine Skalierung, die im Bereich ]0.f, 1.f] sein muss. Was machst du bei negativen Zahlen? Bei Null? Bei Zahlen grösser Eins?


  • Administrator

    KasF schrieb:

    Dravere schrieb:

    Aber bei zum Beispiel sowas:

    set_border_thickness(10); // <- da braucht es nichts mehr, ist schon alles klar.
    

    Jetzt weiß man doch trotzdem nicht, ob 10 dick oder dünn ist.

    set_border_thickness(PIXEL, 10);
    set_border_thickness(CENTI_M, 1);
    set_border_thickness(MILLI_M, 10);
    set_border_thickness(INCH, 4);
    

    Man kann es auch so machen 🙂
    Wenn man ohne diese Angaben arbeitet, nehme ich automatisch an, dass es um Pixel geht.

    Grüssli



  • Aber, irgendwo tief in seinem Code müssen den enums Werte zugeordnet werden, um die Breite zu setzen, da führt kein Weg dran vorbei[...]

    Das kann man aber ebenfalls mit den enums machen. Dann spielt es keine Rolle, was es für eine Zahl hat. (solange man natürlich keine Zahlen nimmt). (Dann müsste die Zuweisung dann halt mit einem switch/case machen und nicht einfach zuweisen, aber das ist bei enums ja eh sinnvoll).



  • Argh, schon wieder so eine Threadflut. Wenn da wenigstens nicht noch drakon und Dravere dazwischenspammen würden. :p
    Edit: Natürlich nicht auf drakons letzten Post bezogen. Überhaupt nicht allzu ernst gemeint... 😉

    KasF schrieb:

    Nexus schrieb:

    ohne dass sich der Code an anderen Stellen ändert.

    Nicht wenn man an diesen anderen Stellen ausschließlich mit dem ENUM arbeitet.

    Das hab ich jetzt nicht ganz verstanden. Wenn man ein zentrales enum hat und an anderen Orten auf die Konstanten (per Enumerator-Bezeichner) zugreift, ist es irrelevant, welche Zahl dahintersteckt. Das meinte ich mit meinem Satz; man kann den internen Aufbau des enum s umstrukturieren, ohne die Funktionalität zu verändern.

    KasF schrieb:

    Aber, irgendwo tief in seinem Code müssen den enums Werte zugeordnet werden, um die Breite zu setzen, da führt kein Weg dran vorbei, aber das soll einem ja nicht davon abhalten den Code auf Client-Seite mit ENUMS "schön" zu machen.

    Ja, "schön" ist grundsätzlich nie schlecht, aber fraglich, ob es dadurch wirklich schöner wird. Um beim Dicke-Beispiel zu bleiben: Wie würdest du Bezeichner wählen? VeryThin, LittleBitThin, MediumThin, NotSoThin ? 😃

    Wenn es um ein Zahlenmass geht, sind enum s normalerweise nicht das Richtige.


  • Administrator

    Im übrigen wollte er die Dicke von border in HTML angeben. Dort kann man frei wählen, was man angibt, das muss nicht in irgendwelche speziellen Zahlen oder Wörter umgewandelt werden. Höchsten könnte man über die Enums entsprechen das Suffix angeben, also cm, em, px usw. 😉

    @KasF,
    Gibt es einfach zu, das war ein FAIL von dir 🙂 😃 🤡

    Grüssli



  • Nexus schrieb:

    Argh, schon wieder so eine Threadflut.

    Wahrlich eine Flut. Da schreibt man was und wird direkt von allen angesprungen 🙂
    Naja, wenn ihr drei so fest davon überzeugt seid, nehme ich das mal so auf und widme mich weiter meinen Bäumen zu.

    Dravere schrieb:

    Gibt es einfach zu, das war ein FAIL von dir

    Solange ich aus diesem FAIL etwas dazulerne, finde ich dies gar nicht mal so schlimm 😉

    Langsam verstehe ich eure Argumentationen ja auch ...


Anmelden zum Antworten