Posts by zrs1

    ZeHa hat mich auf ein weiteres Problem aufmerksam gemacht, das zu falschen Checksummen führen kann:


    Für geshiftete Zeichen gibt es in PETSCII verschiedene mögliche Codierungen. Im BASIC-Text ist das zunächst mal kein Problem, da alle Codierungen mit Bit 7 den BASIC Tokens vorbehalten sind -- der Rest ist eindeutig. Innerhalb eines Strings habe ich aber z.B. für ein geshiftetes A zwei Möglichkeiten, es zu codieren: $61 oder $c1. Der BASIC Editor nimmt immer $c1. Wenn aber ein BASIC-Programm mit irgendeinem anderen Tool (am PC) erstellt wurde, kann es sein, dass die "falsche" Codierung genommen wird. Bei der Ausführung ist das egal, aber mksums würde in diesem Fall mit $61 rechnen, beim Abtippen bekomme ich aber eine Prüfsumme mit $c1. :huh:


    Deshalb habe ich vorhin eine neue Version auf github eingecheckt, bei der mksums per default innerhalb von Strings "falsche" Codierungen korrigiert. Ich habe nicht jeden einzelnen Fall getestet, meine Annahme ist folgende:


    Die Range $60-$7f bzw $c0-$df enthält die gedoppelten Zeichen in PETSCII. Der BASIC Editor nimmt dabei immer die Codierung der Range $c0-$df. Das Zeichen π (pi) ist dabei eine Ausnahme, es kommt sogar 3 mal vor und wird vom BASIC Editor als $ff codiert. Kann mir jemand sagen, ob das so richtig ist? :)

    Ist halt ähnlich wie mit den ganzen "überlebenswichtigen" OR-Mappern die jeder haben muss, weil sonst kein Programmierer Datenbanken verwenden will, weil sein Weltbild nicht Set-basierend sondern Schleifen-basierend ist. :bgdev

    Ich hatte mal besagtes "Marktführer" ERP auseinandergenommen, weil angeblich die Langsamkeit "wegen SQL Server zu langsam" entstand, anstatt das Standard-Backend PervasiveSQL zu verwenden.

    Da wurde für eine Suche, JEDE Row einzeln durchgelooped (!!!) und verglichen mit dem Suchkriterium. Sowas fällt auch nur einem OOP Coder oder OR-Mapper Entwickler ein. :D

    Naja, was solchen Schwachsinn angeht, das macht EF mit seiner LINQ-API an sich schon richtig (irgendwas wie container.FirstOrDefault(x => x.Name == "foo"), was in "sinnvolles" SQL übersetzt wird). Wer dann natürlich statt auf der Basis ein Query zu schreiben lieber alles lädt und im Speicher durchsucht, dem ist nicht zu helfen. Also zumindest mit EF *kann* man es durchaus richtig machen. Ich bin trotzdem kein großer Freund dieser Dinger.


    Wenn man natürlich in seiner Anwendung eher einen Storage für eine Sammlung lokaler Objekte braucht als eine relationale Datenbank, dann sollte man besser über das verwendete Tool nachdenken und sich mal die ganzen "nosql" Systeme anschauen.

    Der Link ist kaputt..

    Sorry, fehlte ne Klammer am Ende (oder hat die das Forum gefressen?) Neuer Versuch: https://docs.microsoft.com/en-…08-r2/ms177443(v=sql.105) (edit: ja, das Forum "frisst" die, man muss manuell verlinken wenn ne Klammer am Ende ist)

    Dann werd ich mir wohl selbst ein kleines Testprogramm schreiben...

    Dann aber nicht mit EF ;) Da wäre die Aussagekraft nahe null ...

    PS: Sollten wir unsere Fachsimpeleien vielleicht besser in einem eigenen Thread haben?

    Hmm, das ist hier schon länger ziemlich abgedriftet :o

    "Clustered" heisst zumindest beim SQLServer, dass die Datensätze physisch nach diesem Schlüssel sortiert abgelegt werden.

    Richtig, mit Hilfe eines B*-Tree

    GUID ist aber zumindest in der C#-Implementierung eine sehr zufällige Zahl, und Neuanlage von Datensätzen ist "drastisch" langsamer, und einen Mehrwert durch den Clustered hat man nicht mehr.

    Letzteres halte ich für ein Gerücht. GUID *soll* "sehr zufällig" sein, und das kommt einer Organisation im B*-Tree doch eher entgegen, weil es seltener die Notwenigkeit gibt, den ganzen Baum neu zu balancieren.

    In VB war bei uns Konvention, Instanzen mit einem Kürzel des Klassen-Namens anfangen zu lassen, wie FmMain für Formulare. So hab ich es jedenfalls damals von meinen Kollegen übernommen, die von C auf Atari und DOS gekommen sind.

    Das ist übrigens auch eine Konvention von vorgestern: https://de.wikipedia.org/wiki/Ungarische_Notation#Kritik

    Dieses Yoda-SQL, das in C# eingebaut ist: Schön nicht es ist.

    Du sprichst vermutlich von LINQ ... das ist eben KEIN SQL -- wer sagt denn, dass es nur eine "query language" geben darf? ;) Ich persönlich mag übrigens beides nicht (und bevorzuge es, "LINQ-APIs" direkt mit lambdas zu verwenden).

    "Für Primärschlüssel nimmt man heute GUIDs, auch wegen Replikation und so". Und dann haut EF da nen clustered Index drauf.

    Da solltest du mal erklären, was daran als default schlecht sein soll. Aber abgesehen davon: EF halte ich auch nicht für der Weisheit letzter Schluss. Wir halten davon bewusst Abstand.

    while (exit == false)

    Ähm bitte was? Am besten auch noch if (exit == true)? Das halte ich für mit den schlimmsten Murks, den man schreiben kann. if erwartet einen Ausdruck mit Wahrheitswert ... wenn ich schon einen Wahrheitswert habe, den mit einem anderen Wahrheitswert zu vergleichen um einen Wahrheitswert zu bekommen ... äh ja ... :o

    Übrigens gibt es keine kompaktere Schreibweise um ein beliebiges int als "bool" (0 oder 1) zu normalisieren als !!a, durchaus ein gängiges Idiom.

    Mischen von Datentypen, pfui!

    bool ist kein Datentyp in C -- ein "bool" ist traditionell ein int, "gemischt" wird hier also gar nichts. Seit C99 gibt es bool als (optional nutzbares) Makro für den neuen Typ _Bool, der ebenfalls ein Integertyp mit mindestens 8 bit ist, allerdings muss _Bool tatsächlich nicht mehr als 0 oder 1 darstellen können, der Rest dürfen theoretisch "trap representations" sein. Außerdem gibt's dazu die Makros true und false, kaum überraschend definiert als 1 und 0. Dank "integer promotion" Regeln wird jeder integer-Typ für Berechnungen ohnehin mindestens auf die Größe eines int konvertiert -- !!a wäre also immer noch völlig korrekt, wenn man für a tatsächlich den Typ _Bool nimmt. Für int sowieso.

    All das hat nichts mit Code wie a = b++; zu tun -- das ist völlig ok und wohldefiniert.

    Trotzdem sollte man so etwas vermeiden.


    Edit: Genauso wie den Nicht Operator (!) oder den ternären Operator (Ausdruck) ? x : y;

    Das halte ich in dieser Allgemeinheit für Unsinn. Ternäre Ausdrücke werden leicht unleserlich, wenn das passiert weiß man, dass man es falsch gemacht hat. In einer einfachen Form sind sie aber sogar viel besser lesbar als unnötiges if-else-geschachtel.


    Was gegen ! sprechen soll erschließt sich mir so absolut nicht. Gedacht ist der Operator für simple Anwendungen wie


    Code
    1. int has_foo = 0;
    2. ...
    3. if (! has_foo)
    4. {
    5.     ...
    6. }


    Natürlich wäre eine Anwendung wie if (!(a < b)) kompletter Unsinn und der Produzent dieses Codes gehört geteert und gefedert.


    Übrigens gibt es keine kompaktere Schreibweise um ein beliebiges int als "bool" (0 oder 1) zu normalisieren als !!a, durchaus ein gängiges Idiom.

    Der MISRA C Standard schreibt z.B. folgendes vor:

    MISRA ist in weiten Teilen ziemlicher Mist (dürfte aber das Ziel, dass auch Programmierer mit "durchschnittlichen" C-Kenntnissen sicher coden, trotzdem erreichen). Die zitierte Regel ergibt Sinn, ist aber unsinnig formuliert. Eine "order of evaluation" ist in C gar nicht definiert, lässt sich aber aus der Grammatik ableiten. Nur hilft die hier nichts, die sagt dir am Ende nur, welche Operatoren stärker binden. Der Beispielcode aus dieser Regel:

    x = b[i] + i++;

    ist schlicht undefined behavior. Das liegt daran, dass i hier zweimal evaluiert wird, ohne sequence point dazwischen, wobei aber i++ einen Seiteneffekt hat. Die beiden Evaluationen sind "unsequenced", damit könnte der Seiteneffekt passieren, bevor b[i] gelesen wird, oder auch danach. "Order of evaluation" hilft hier nichts, selbst etwas wie

    x = b[i] * (a + i++);

    wäre UB, obwohl hier (a + i++) vor der Multiplikation berechnet werden muss. Trotzdem ist es unsequenced und damit auch undefiniert, auf welches Element von b zugegriffen wird. Es geht hier lediglich um "sequence points", die definieren, an welchen Stellen Seiteneffekte abgeschlossen sein müssen.


    Jedes ; in C ist ein sequence point, es gibt allerdings noch ein paar andere :)


    All das hat nichts mit Code wie a = b++; zu tun -- das ist völlig ok und wohldefiniert.


    edit: im Text der Regel ist das meiste tatsächlich korrekt, leider ist auch hier die Rede von "order of evaluation", dabei geht es nicht ums evaluieren sondern darum, wann ein Seiteneffekt passiert ...

    Ich werfe mal Python in die Runde, da gibt es weder Klammern noch EndIf, aber die Einrueckung als Syntax finden viele ja auch total schlimm. Ich finds geil :D

    Ja, allerdings, das ist ja die Steigerung von BASIC (wo "nur" die Zeilenenden Semantik haben) -- ich HASSE es, wenn Whitespace irgendeine Bedeutung hat, dafür gibt es Whitespace ;)


    Aber wie du auch sagst, sehr vieles ist reine Gewohnheit.

    Seit über 45 Jahren wird immer wieder dieser Fehler gemacht, und genau so lange hätte schon ein := geholfen, bzw. lässt VB6 gar nicht erst Zuweisungen innerhalb von Ausdrücken zu.

    Irgendeine Unterscheidung zwischen Zuweisung und Vergleich sollte man haben. Das war immer ein grober Mangel in BASIC. Ich finde zwar auch, dass := vs = (Pascal) sinnvoller ist als = vs == (C) -- aber da C# nunmal der C Grammatik entspricht wäre es maximal verwirrend, sich an DIESER einen Stelle stattdessen an Pascal zu orientieren. Letztendlich ist es Gewohnheitssache.

    - ; als Endezeichen statt Zeilenumbruch + Zeichen zur Fortsetzung.

    Ein ; hinter dem FOR kann man ewig suchen, und der STRG+C/V/V-Fehler kann mit CRLF statt ; auch nicht passieren.

    Zeilenenden mit Semantik finde ich persönlich das schlimmste, was man tun kann. Vermutlich läuft aber auch das auf "Gewohnheit" hinaus.

    - { } statt endif, wend, next...

    Für mich der Grund, BASIC als "Labersprache" zu bezeichnen. Warum sollte ich für so etwas simples wie Blöcke mehr als ein Zeichen tippen? Abgesehen davon, die Übersicht leidet (sinnvoll formatierten und eingerückten Code vorausgesetzt), wenn da umfangreiche Keywords statt simpler Klammern genutzt werden -- die lenken nämlich nur vom eigentlichen Code ab.

    - Und Freund von Groß/Kleinschreibung bin ich auch nicht.

    Ich sehe immer noch keinen Nutzen darin, mich nicht nur auf die Worte, sondern auch auf deren genaue Schreibweise konzentrieren zu müssen.

    Besonders nützlich finde ich das auch nicht. Aber wie relevant ist das in Zeiten von "Intellisense" und ähnlichen Tools?

    - Dass ich Objekte über die Webschnittstelle reinbekomme, die einen Scheissdreck validiert sind, find ich aber übel. Und das schient nicht daran zu liegen, dass ich das passende Feature noch nicht entdeckt oder falsch angewendet hätte. Ist kein Rückschritt gegenüber VB6, aber in Anbetracht von .wsdl enttäuschend.

    wsdl gehört zur SOAP Welt, SOAP ist mit gutem Recht tot -- das war ein Irrweg mit sehr viel Komplexität für praktisch keinen Nutzen. Allgemein würde ich sagen: Validierung gehört zur Fachlogik, wenn ich irgendeinen Payload vom Framework in Objekte deserialisieren lasse, dann wird automatisch "validiert", dass die Konvertierung möglich ist -- alles weitere ist Teil meiner Schnittstelle, das muss ich erstmal ausspezifizieren und dann natürlich auch validieren. Value Objects können helfen, das übersichtlich zu halten.

    Und dann war da dieser Typ, der "Jay, Reflection!!" gerufen und das gleich als Kernelement ins Framework gebaut hat. In VB6 war "Call by Name" noch so böse wie goto, und jetzt hat man hochoffiziell Methoden, die scheinbar unbenutzt, dem Compilertest entzogen, aber doch benutzt sind.

    "Reflection" ist zur Lösung bestimmter Probleme (z.B. generisch serialisieren/deserialisieren) unabdingbar, aber selbstverständlich ist der Einsatz von Reflection wenn es auch anders ginge ein deutlicher "code smell" :)

    Beide Sprachen ezeugen ja auch den gleichen Bytecode und verwenden im wesentlichen die gleichen Bibliotheken.

    Es gibt schon diverse Unterschiede, nicht alles lässt sich 1:1 zwischen C# und vb.net übersetzen, so dass exakt der gleiche Code herauskommt -- aber das ist in der Tat minimal. Der Hauptunterschied ist, dass vb.net mittlerweile eine Art Zombie ist -- es bewegt sich zwar noch irgendwie, ist aber dennoch tot (siehe Codebeispiele und eigene Repos von Microsoft, siehe praktisch nicht vorhandene Weiterentwicklung der Sprache, aber auch allgemein auf github etc verfügbaren Code).


    Meiner Meinung nach kein Verlust, diese "Labersprache" hat mich immer genervt :)

    Deswegen funktionieren auch die Konverter recht gut.

    http://converter.telerik.com/ z.B.

    Versuch mal das:

    Code
    1. private static(int lowest, int highest, string LuckyName) GetSomeTuple(IReadOnlyCollection < int > numbers) {
    2. int lowest = numbers.Min(n => n);
    3. int highest = numbers.Max(n => n);
    4. return (lowest, highest, "Johnny Boy");
    5. }

    Da dürfte die fehlende Weiterentwicklung bei vb.net zuschlagen ;)

    Ich dachte auch an das Auslesen von irgendwelchen Analogwerten innerhalb des Rechners

    Soweit ich weiß gibt es an "auslesbaren Analogwerten" nur die POTX/POTY Eingänge des SID für die Paddles. Die sind dafür wohl kaum zu gebrauchen ;)


    Die Grundidee ist aber an sich naheliegend. Gerne hergenommen wird $d012 (aktuelle Rasterzeile) oder auch $dc04 (lowbyte timer A von CIA #1). Außerdem bietet der SID die Möglichkeit, den Wert von Oszillator 3 auszulesen ... wenn man den stumm schaltet und Rauschen aktiviert, erhält man hier pseudozufällige Werte (das Rauschen wird vom SID per LFSR erzeugt). Alles nicht analog, aber erfüllt wohl den Zweck, an den du dachtest. Wobei ich mit solchen Eingaben immer eher einen PRNG seeden würde, als sie wiederholt für Zufall zu nutzen (zu dem Zweck taugt dann wohl auch ausschließlich die Variante mit dem SID OSC3).

    Ich dachte auch an das Auslesen von irgendwelchen Analogwerten innerhalb des Rechners

    Soweit ich weiß gibt es an "auslesbaren Analogwerten" nur die POTX/POTY Eingänge des SID für die Paddles. Die sind dafür wohl kaum zu gebrauchen ;)


    Die Grundidee ist aber an sich naheliegend. Gerne hergenommen wird $d012 (aktuelle Rasterzeile) oder auch $dc04 (lowbyte timer A von CIA #1). Außerdem bietet der SID die Möglichkeit, den Wert von Oszillator 3 auszulesen ... wenn man den stumm schaltet und Rauschen aktiviert, erhält man hier pseudozufällige Werte (das Rauschen wird vom SID per LFSR erzeugt). Alles nicht analog, aber erfüllt wohl den Zweck, an den du dachtest. Wobei ich mit solchen Eingaben immer eher einen PRNG seeden würde, als sie wiederholt für Zufall zu nutzen (zu dem Zweck taugt dann wohl auch ausschließlich die Variante mit dem SID OSC3).

    ein Mehrmündiges "Das ist falsch und Du bist blöd, weil Du nicht einfach glaubst, was ich Dir sage!"

    Der Thread ist ja nun für alle einsehbar. Das stand da nirgends. Wenn man "völligen Unsinn" schreibt darf man aber auch mal den Kommentar "das ist völliger Unsinn" aushalten, auch wenn der gerade nicht, wie behauptet "diplomatisch" formuliert ist. Es ist trotzdem so erstmal kein Angriff "ad hominem" und wenn noch begründet wird, warum es Unsinn ist, dann ist das vielleicht nicht die netteste Art, aber vertretbar. Wenn man sich dann aber, aus gekränktem Stolz, jeder Belehrung verweigert, gibt man ein wenig überzeugendes Bild ab.

    ohne mir eine Quelle zu nennen, mit der ich eure Aussagen nachvollziehen kann

    Die Schemabilder vom 6502 sind keine Quelle? Oder auch die reine Logik, wie sich denn bitte unintended Opcodes (die es bei weitem nicht nur beim 6502 gab) mit einer "Befehlstabelle" erklären ließen?

    Aner nachgewiesen glaubwürdigen Quelle vertrauen

    Deine Erinnerung an "irgendeine Fernsehsendung" ist "nachgewiesen glaubwürdig"? Vermutlich ist "glaubwürdig" zu subjektiv, um das jetzt auszudiskutieren.

    Und ich nehme an, das ist "in Hardware verdrahtet" [EDIT] (= "primitive" Gatterschaltung) [/EDIT] , da muss nichts in einer Befehlstabelle nachgeschaut werden, wie damit umzugehen ist - ansonsten kann ich mir die wenigen Takte, die der Befehl braucht nicht erklären.

    Dass hier keine Tabelle verwendet wird zeigt ja schon die Funktionstüchtigkeit von "unintended Opcodes" ;)

    Ich meinte, was haben die Forscher damals gemacht, um RISC zu entwickeln. Welche Intension hatten sie, was war ihr Ausganspunkt.

    Komplexität reduzieren. Eben das KISS-Prinzip. Alleine das Dekodieren von Befehlen unterschiedlicher Länge führt ja zu Fallunterscheidungen.

    Da Prozessoren nie eine lange Liste von Befehlen sequentiell durchsucht haben hat garantiert auch nie jemand darüber nachgedacht, dieses hypothetische Verhalten zu verbessern.

    Prozessoren durchsuchen keine Tabellen um Befehle zu "finden". Die Bitmuster im Befehl aktivieren bestimmte Schaltungen (sehr vereinfacht ausgedrückt).


    Performancevorteile hat RISC durch verschiedene Eigenschaften wie z.B. einheitliches Format und Länge aller Befehle (damit tut der "fetch" immer das gleiche und dauert immer gleich lang), einheitlicher Aufbau der Abarbeitung (was Pipelining simpler und effizienter macht) usw...