Beiträge von gandro

    War mir dessen bewusst, habe aber keine Erklärung bzw. eine Lösung dafür gefunden (weil editiert hat den Beitrag nachweislich niemand). Werde mal DosAmps fix einspielen. Bei Gelegenheit sollte man auch mal prüfen ob das ein MyBB-Bug ist.

    Und noch ein einfaches JS:

    Ausgabe: count_even(3) = 22 + 2 = 5

    count_even zählt alle Zahlen kleiner "upto" welche durch zwei teilbar sind. Also count_even(3) gibt korrekterweise 2 zurück (0 und 2).


    Wie wirkt sich in dem Fall denn son , aus?


    Ein Ausdruck "x,y" berechnet zuerst x, verwirft das Resultat; berechnet dann y und gibt das zurück.

    printf("%d\n", (1+1, 2+2, 3+3)) berechnet zuerst 1+1, dann 2+2, dann 3+3 und übergibt dann 6 (=3+3) dem printf.

    (2,0 + 2,0) berechnet also zuerst 2, dann 2+0, dann 0 und verwendet 0 für die Ausgabe.

    Nachtrag. Zu den Warnungen, stimmt, doch nicht ganz standard-konform weil ich einen Integer als Float ausgebe.
    Korrekterweise müsste man printf("%f", (float) (2,0 + 2,0)) oder printf("%d", (2,0 + 2,0)) schreiben. Da 0 aber auch 0.0 in Float ist, funktioniert es.


    (20:35:21) DosAmp: (ich hab ehrlich gerade keinen plan, woran es liegt, dass mein c-programm uninitialisierten speicher liest und verarbeitet)


    Das Problem hier ist, dass die Evaluationsreihenfolge von "numbers[++i] = numbers[i]" nicht definiert ist. Der Assignment-Operator ( = ) in C ist kein Sequence-Point (+ übrigens auch nicht), das heisst der C-Compiler darf selber entschieden, welchen Ausdruck er wann evaluiert. Gleiches Phänomen wie thosch97 sein zweites Beispiel.

    Es wird also von deinem Compiler folgendes ausgeführt. Andere Compiler können das anders interpretieren.

    Code
    while (i < 6) {
        /* um eins erhöhen und in den Nachfolger schreiben */
        int tmp = ++i;
        numbers[tmp] = numbers[i] + 1;
      }


    Nachtrag: Ausserdem macht das hier nen Zugriff auf numbers[6], also ausserhalb des Arrays, was auch böse ist.


    Ich hab ja noch nichtmal was dagegen, systemd als reines Initsystem zu nutzen. Aber der Scheiß soll sich aus Sachen wie Login, Terminalverwaltung, Logging, {insert random foo here} raushalten. Ist ja fast so schlimm wie Emacs mit seinen ganzen Unterfunktionen, die jedem Sinn widersprechen..


    [ ] Artikel gelesen.

    (Hint: Der Artikel ist von einem systemd-Gegner. Dein Argument zerreisst er trotzdem in der Luft.)


    für mich unterscheidet sich der artikel von einem destruktiven trollgeflame nur dadurch, dass er auf beide seiten einhaut. nen konstruktiven ansatz liefert er leider überhaupt nicht...


    Konstruktiven Ansatz wofür meinst du jetzt?

    Der Text ist ja eine (sehr treffende) Analyse/Rant über systemd-Diskussionen, nicht über systemd an sich.

    Er zeigt ja auch, dass das systemd-Diskussionen rein strukturell gar nicht funktionieren können. Eben weil weder die Diskussionsubjekte (die Opponenten und Proponenten) kaum gemeinsame Ziele/Werte verflogen; und weil das Diskussionssubjekt nicht wohldefiniert ist. Darum kann es in der Konklusion keine fruchtvolle Diskussion über systemd als solches geben kann. Die Frage nach dem konstruktiven Ansatz einer systemd-Diskussion erübrigt sich.

    Bezüglich der generelleren Probleme die Init-Systeme mitbringen verweist er ja auf diverse konstrkutive Blogbeiträge aus dem letzten Jahrzehnt. Das wäre ein Ansatz, den man fahren kann: Die technischen Probleme von ihrem politischen Balast (und damit von systemd) trennen, und separat diskutieren.

    Der systemd-Artikel um alle systemd-Artikel zu beenden:

    The systemd debate is rarely a technical argument for either side, instead it is an ideological and cultural war.

    Ein Entwickler von uselessd (systemd-Alternative) zerhaut in dem Text einfach mal 90% aller Argumente beider Seiten, die in systemd-Diskussionen so gebracht werden. Wirklich sehr schön zu lesen, da es praktisch auch auf alle systemd-Flames hier im Forum und IRC zutrifft.

    Für mich ist es auch ein Signal, uselessd als ernstzunehmendes Projekt wahrzunehmen (anders als etwa die Debian Heugabeln). Der Mensch weiss sehr genau, wovon er spricht.


    Ich spielte jetzt prinzipiell nur auf Die Aussage an „Gugg ma, neue CPU ist 33-50% schneller als ein ähnliches Modell vor nem Jahr“, weil das bei ARM zumindest bis jetzt ja mehr oder minder wirklich gegeben ist, diese speed boosts, IMHO nix besonderes.


    Der Apple A8 ist aktuell, nicht vom letzten Jahr. Als Apple letztes Jahr mit Cyclone rauskam, hat man den auch mit älteren Designs verglichen.

    Ausserdem vermute ich nach wie vor, dass Apple sowas wie den Cyclone-Sprung nicht nochmals schafft. Ich glaube nicht daran, dass Apple Tick-Tock implementiert. Aber das sehen wir ja dann nächstes Jahr.

    iPhone 5s hatte ja schon 1400 Punkte, iPad Air 2 hat nun 1800, das bei einer Taktrate von 1,50GHz.

    Wüsste ja jetzt nicht was daran spektakulär ist.


    Es ist ein neuer Rekord für ARM Consumer-Geräte? Und wie oreissig schon sagte, so langsam erreichen wir x86-Laptop-Niveau. Das ist schon spektakulär.

    Finde ich durchaus erwähnenswert. Apple hat den Cyclone-Vorsprung halt inzwischen verloren. Auch interessant, dass der Tegra K1 noch eine Instruktion breiter ist als Cyclone/A8.