Logische Operatoren


  • Gesperrt

    @Wade1234 sagte in Logische Operatoren:

    @RBS2
    nein vernünftiger code ist solcher, der besonders leicht nachvollzogen, geändert und erweitert werden kann.

    Das ist mit ein Grund, weshalb der Bedarf an Rechenleistung und Speicher astronomisch angewachsen ist.



  • naja ich würde eher sagen, dass das daran liegt, dass alles dynamisch berechnet werden muss, weil man mit script- bzw. interpretersprachen arbeitet. also ob ich jetzt bei der programmierung eines mauerwerks für ein haus (sorry mir fällt grad nix besseres ein)

    #define STONES_FOR_LIVING_ROOM 100
    #define STONES_FOR_BEDROOM 500
    #define STONES_FOR_BATHROOM 300
    
    struct Stone st[STONES_FOR_LIVINGROOM + STONES_FOR_BEDROOM + STONES_FOR_BATHROOM];
    

    oder

    struct Stone st[900];
    

    schreibe, dürfte dem compiler ziemlich egal sein (wenn nicht, sollte ich mir einen anderen compiler suchen), aber es ist verständlicher und besser zu verändern und zu erweitern und weiter oben haben wir ja auch gesehen, dass der compiler seine arbeit vernünftig macht.


  • Mod

    @Wade1234 sagte in Logische Operatoren:

    und was haben optimierungen durch den compiler jetzt damit zu tun, vernünftigen code zu schreiben?

    @RBS2 sagte in Logische Operatoren:

    Vernünftiger Code ist solcher, der es dem Compiler besonders leicht macht. 🐱

    @Wade1234 sagte in Logische Operatoren:

    nein vernünftiger code ist solcher, der besonders leicht nachvollzogen, geändert und erweitert werden kann.

    Tollerweise ist das fast immer das gleiche: Der lesbarste und wartbarste Code ist auch der gleiche, den der Compiler am besten versteht und auch am besten optimieren kann.

    Schon oft haben wir hier Leute gesehen (war das nicht sogar oft RBS2?), die mit alten C-Optimierungstricks heutzutage voll auf's Maul fallen, wenn man tatsächlich mal misst, was am schnellsten ist. Ist eine Umformung zu äquivalentem, schnelleren Code möglich, dann findet sie der Compiler auch fast immer. Aber viele Optimierungstricks sind oft nicht exakt äquivalent (funktionieren z.B. nur im Falle von positiven Zahlen, etc.) und sind dann nicht mehr umformbar zu dem schnelleren Optimalcode.

    PS: Wobei ich es in diesem speziellen Fall schon krass finde, dass
    a) Der Compiler den gleichen Code für alle 3 Varianten erzeugt hat, besonders für die Variante von RBS2 die halt sehr schlecht ausdrückt, was der Programmierer möchte.
    b) Dass die optimierte Variante die ist, die fast 1:1 dem Code von RBS2 entspricht. Er hat also moralisch Recht, dass seine Variante auf Maschinenebene der (nach Meinung des Compilers) schnellsten Vorgehensweise entspricht.



  • @Wade1234 sagte in Logische Operatoren:

    und was haben optimierungen durch den compiler jetzt damit zu tun, vernünftigen code zu schreiben?

    Ganz einfach: du sollst nicht gut lesbaren Code durch unlesbaren "handoptimierten" Code ersetzen! ("handoptimiert" hier extra in Tüddelchen, weil es keine echte Optimierung ist)


  • Gesperrt

    @SeppJ sagte in Logische Operatoren:

    Tollerweise ist das fast immer das gleiche: Der lesbarste und wartbarste Code ist auch der gleiche, den der Compiler am besten versteht und auch am besten optimieren kann.

    Das ist wohl so, weil Compilerentwickler wissen, welche Code-Konstrukte oft von Programmierern verwendet werden. Bestimmt arbeiten moderne Compiler mit heuristischen Methoden, etwa so wie Virenscanner.


  • Gesperrt

    @SeppJ sagte in Logische Operatoren:

    a) Der Compiler den gleichen Code für alle 3 Varianten erzeugt hat, besonders für die Variante von RBS2 die halt sehr schlecht ausdrückt, was der Programmierer möchte.

    Nein, der Code drückt sogar sehr gut aus, was der Coder will. Er möchte, dass verzweigt wird, wenn der Input mit gesetztem Bit 5 dem char 'j' enspricht. Dazu muss der Compiler keine erweiterten Analysetechniken anwenden. Und das tut er wohl auch nicht. Mindestens für diese eine Zeile (nach Syntaxprüfung) wird er blind dem Programmierer vertrauen.



  • @RBS2 sagte in Logische Operatoren:

    Nein, der Code drückt sogar sehr gut aus, was der Coder will.

    Ihr definiert "der Coder" einfach nur unterschiedlich:

    Definition bei dir: der Coder = RBS2
    Bei SeppJ: der Coder = jeder Programmierer außer RBS2

    Daher die Verwirrung.


  • Gesperrt

    @Jockelx sagte in Logische Operatoren:

    Ihr definiert "der Coder" einfach nur unterschiedlich:
    Definition bei dir: der Coder = RBS2
    Bei SeppJ: der Coder = jeder Programmierer außer RBS2

    Ja, das passt etwa. Ich würde mir niemals anmaßen, für andere Programmierer zu sprechen. Als einfacher User dieses Boards biete ich nur Alternativen, unkonventionelle Sichtweisen, kann trollen und habe Spaß. SeppJ als "Global Moderator" hat einen ganz anderen Anspruch. Ich möchte jedenfalls nicht mit ihm tauschen.


  • Mod

    @RBS2 sagte in Logische Operatoren:

    Bestimmt arbeiten moderne Compiler mit heuristischen Methoden, etwa so wie Virenscanner.

    Zweifel.

    @RBS2 sagte in Logische Operatoren:

    Er möchte, dass verzweigt wird, wenn der Input mit gesetztem Bit 5 dem char 'j' enspricht.

    "Er" wollte aber, dass verzweigt wird, wenn das gesamte Bitmuster von input entweder identisch ist mit dem von 'j' oder mit dem von 'J'.

    Ich, du, die andren die hier noch posten, und (überraschenderweise) auch der Compiler wissen natürlich, wieso das - unter gewissen Voraussetzungen, die wir als gegeben ansehen können - die gleiche Bedingung ist. Aber ich wette mal, wir haben in dieser Diskussion @Mxrvin schon vor langer Zeit verloren. Er ist jedenfalls ziemlich still geworden.



  • @RBS2 sagte in Logische Operatoren:

    Ja, das passt etwa. Ich würde mir niemals anmaßen, für andere Programmierer zu sprechen.

    Das ist schlecht...es gibt nix schlimmeres, als Programmier-Kollegen, die sich nicht in andere Programmierer hinein versetzen können.
    Hoffe, du machst das nur als Hobby oder arbeitest wenigstens nicht im Team.

    Ps.: Kann mich noch gut an einen erinnern, der auch so ganz toll optimieren konnte:

    Zig mal im Code:

    i = i^i;
    

    Den hätte ich erschlagen können...


  • Gesperrt

    @Jockelx sagte in Logische Operatoren:

    @RBS2 sagte in Logische Operatoren:

    Ja, das passt etwa. Ich würde mir niemals anmaßen, für andere Programmierer zu sprechen.

    Das ist schlecht...es gibt nix schlimmeres, als Programmier-Kollegen, die sich nicht in andere Programmierer hinein versetzen können.
    Hoffe, du machst das nur als Hobby oder arbeitest wenigstens nicht im Team.

    In meiner aktiven Zeit habe ich Hardware entwickelt und mich immer über Programmierer geärgert, die ihren persönlichen Perfektionsfimmel feierten. Heute habe ich nur noch sporadisch damit zu tun.



  • @Jockelx sagte in Logische Operatoren:

    @RBS2 sagte in Logische Operatoren:

    Ja, das passt etwa. Ich würde mir niemals anmaßen, für andere Programmierer zu sprechen.

    Das ist schlecht...es gibt nix schlimmeres, als Programmier-Kollegen, die sich nicht in andere Programmierer hinein versetzen können.

    Man kann sich auch in andere hineinversetzen und trotzdem aus Respekt die Fresse halten. Das eine schließt nämlich das andere nicht aus.
    Abgesehen davon hilft die Diskussion hier dem TE absolut nicht. Die Optimierungen sind in dem Stadium,in dem sich der TE befindet, völlig unerheblich. Die Wartbarkeit und Intuitivität des Quellcodes stehen an erster Stelle.


  • Gesperrt

    @It0101 sagte in Logische Operatoren:

    Abgesehen davon hilft die Diskussion hier dem TE absolut nicht.

    Okay, weiter bei seinem Punkt 7:

    ob der Wert der int-Variablen zaehler nicht im Intervall [5,25] liegt:
    (für zaehler = 30)

    Ich schlage vor:

        if (zaehler > 4 && zaehler < 26) {} else
        {
            // Bedingung erfuellt
        }
    


  • und ich

    if(!(zaehler >= 5 && zaehler <= 25))
    {
    }
    

  • Gesperrt

    Oder mal richtig intuitiv: 🐱

    int aufgabe7 (int zaehler)
    {
        return zaehler > 4 ? zaehler < 26 ? 0 : 1 : 1;
    }
    
    


  • das mochte ich noch nie..........


Anmelden zum Antworten