Hi 9356 xor 2608 = ?
Der ganz faule Windows-calc.exe-Nutzer erhält in der Programmierer-Ansicht 11.964 als Ergebnis, aber ob das stimmt? selbst mit den Zwischenschritten bin->dez((dez->bin) XOR (dez->bin)) kommt das gleiche Ergebnis
apfel schrieb: > 9356 xor 2608 = ? Mike B. schrieb: > ... 11.964 als Ergebnis, aber ob das stimmt? Im Zweifel direkt die CPU befragen. Hier eine Routine für x86 (32 Bit):
1 | void asmtest () |
2 | {
|
3 | // C/C++, GNU Inline Assembler (AT&T-Syntax)
|
4 | // Hier benötigte includes: <stdio.h>, <stdint.h>
|
5 | // Mögl. Mnemonics sind hier z.B. xorl, andl, orl, addl, subl, adcl, sbbl
|
6 | #define asmcmd "xorl %%ecx, %%eax;"
|
7 | |
8 | uint32_t IOvar[3]; // asm-I/O-Variablen ([0]=Output, [1],[2]=Input) |
9 | |
10 | IOvar[1] = 9356; IOvar[2] = 2608; |
11 | // IOvar[1] = 0x11010101; IOvar[2] = 0x10110011; // Test
|
12 | asm volatile ( // asm-template :outputs :inputs :clobbers |
13 | "movl %1, %%eax; movl %2, %%ecx;" asmcmd "movl %%eax, %0;" |
14 | :"=ra"(IOvar[0]) :"ra"(IOvar[1]),"rc"(IOvar[2]) :"%eax","%ecx" ); |
15 | printf("Test, asm-Befehl: %s\n\n", asmcmd); |
16 | printf("input EAX= 0x%08x, %11ld\n", (int) IOvar[1], (long) IOvar[1]); |
17 | printf("input ECX= 0x%08x, %11ld\n", (int) IOvar[2], (long) IOvar[2]); |
18 | printf("output EAX= 0x%08x, %11ld\n", (int) IOvar[0], (long) IOvar[0]); |
19 | return; |
20 | }
|
:
Bearbeitet durch User
apfel schrieb: > 9356 xor 2608 = ? Ich hab mal in mein Mathebuch geschaut. Da kommen zwar viele Operationen vor, die man mit zwei Zahlen anstellen kann wie addieren, multiplizieren oder potenzieren, "xor" kommt da aber nicht vor. Mike B. schrieb: > Der ganz faule Windows-calc.exe-Nutzer erhält in der > Programmierer-Ansicht 11.964 als Ergebnis, aber ob das stimmt? Auch bei 9356.0 xor 2608.0? Muß ja mathematisch das Gleiche sein. MfG Klaus
Klaus schrieb: > Auch bei 9356.0 xor 2608.0? Muß ja mathematisch das Gleiche sein. xor ist eine logische Operation die einzelne Bits verknüpft und sinnfrei bei float-Zahlen
Yalu X. schrieb: > In welcher Programmiersprache? Hat nix mit Programmierung zu tun! Walter S. schrieb: > xor ist eine logische Operation die einzelne Bits verknüpft und sinnfrei > bei float-Zahlen Genau so sieht das aus. Und wenn man das Umwandelt dez->bin und das dann einfach auf einem Blatt Papier exklusiv-oder verknüpft, kommt tatsächlich 11964 raus. Aber das kann man doch auch selber herausfinden, oder?
Ein Fallstrick könnte sein, das "modulo 2 add" fälschlicherweise auch als XOR bezeichnet werd, es aber wegen den Carry zu anderen Bitmustern/Ergebnissen kommt: http://homepage.cs.uiowa.edu/~ghosh/2-24-09.pdf so ein XOR mit Übertrag wird bei Codierungen gern benutzt, Galois-Felder und so. Mike B. schrieb: > selbst mit den Zwischenschritten bin->dez((dez->bin) XOR (dez->bin)) > kommt das gleiche Ergebnis muss nicht unbedingt decimal sein könnte auch hex sein, oder ASCII.
Walter S. schrieb: > xor ist eine logische Operation die einzelne Bits verknüpft und sinnfrei > bei float-Zahlen Im Titel steht: XOR-Verknüpfung 2er Zahlen. Und eine logische Operation außer größer, kleiner oder gleich ist bei allen Zahlen sinnlos. In lua z.B. sind Zahlen immer floating point, in anderen Sprachen ebenso. Die ganze Frage ist sinnfrei und ein etwaiges Ergebnis höchstens Zufall. MfG Klaus
Hallo Zwei Zahlen bitweise XOR verknüpfen, geht doch ganz einfach auf einen Stück Papier. Zahlen nach binär, dann verXodern, dann wieder nach dezimal
1 | 0010 0100 1000 1100 9356 |
2 | 0000 1010 0011 0000 2608 |
3 | |||| |||| |||| |||| |
4 | VVVV VVVV VVVV VVVV xor |
5 | 0010 1110 1011 1100 11964 |
Gruß Ulf
Klaus schrieb: > In lua z.B. sind Zahlen immer floating point, in anderen > Sprachen ebenso. Du willst damit sagen, daß es keine ganzen Zahlen gibt? Nirgends? Die Tatsache, daß hier zwei Zahlen stehen, in denen kein Komma vorkommt, macht dich gar nicht stutzig? Das sind also auch keine ganzen Zahlen, sondern Kommazahlen? Du sagst: > "immer floating point, in anderen Sprachen ebenso." Also ist die Integer-Zahl "1234" ebenfalls "floating point"? Mach dich mal bitte schlau über Zahlensysteme...
Hallo
IMHO ist XOR mathematisch gesehen die Addition zweier Repräsentanten
modulo 2. (Also Addition ohne Übertrag - daher auch manchmal Halbadder
genannt)
9356 xor 2608 = 9356 + 2608 (mod 2) = 0 + 0 (mod 2) = 0
Die meisten Programmiersprachen (vermutlich auch Personen) meinen aber
mit xor im Context mit Zahlen eigentlich "bitweise xor". (Pascal
basierte Sprachen z.B.)
Unter der Annahme es handelt sich um Zahlen des Dezimalsystems (so wie
es gängige Konvention ist)
9356 xor 2608 =
(10010010001100)d
xor (101000110000)d =
(10010010001100)d
xor (00101000110000)d =
--------------------------
(10111010111100)d = 11964
9356 xor 2608 = 11964
MfG
Also falls der TO wirklich an einem Ergebnis interessiert ist: a) sollen Deine Zahlen HEX- oder Dezimalzahlen sein? (binär und oktal fällt zum glück aus) b) möchtest Du das Ergebnis in Hex, Dezimal, Binär, ASCII oder mittels CRC-CCITT gesichert? c) wie sieht Dein bisheriger Ansatz aus, was klappt, was nicht?
Bernd schrieb: > Yalu X. schrieb: >> In welcher Programmiersprache? > Hat nix mit Programmierung zu tun! Dass die Frage im Forum "PC-Programmierung" gestellt worden ist, lässt vermuten, dass sie sehr wohl etwas mit Programmierung zu tun hat. Viele Programmiersprachen definieren tatsächlich einen Operator, der zwei Integer-Zahlen bitweise XOR-verknüpft. Nur heißt dieser Operator – abgesehen von ein paar nicht der Norm entsprechenden Basic- und Pascal-Dialekten – meist nicht "xor", sondern bspw. "^". Meine Rückfrage habe ich deswegen gestellt, weil ich nicht alle Programmiersprachen kenne und es durchaus denkbar ist, dass es welche gibt, die xor nicht als bitweise, sondern als logische Operation (äquivalent zu x&&!y || !x&&y in C) definieren. Ansonsten dürfte es für den TE kein großer Aufwand sein, den Ausdruck in der (in der Hausaufgabe ganz sicher angegebenen) Programmiersprache einzugeben, um damit auch ohne Hilfe dieses Forums auf das Ergebnis zu kommen. Dazu müsste er aber evtl. sein Apfel-Telefon weglegen und den PC einschalten.
:
Bearbeitet durch Moderator
npn schrieb: > Du willst damit sagen, daß es keine ganzen Zahlen gibt? Nirgends? > Die Tatsache, daß hier zwei Zahlen stehen, in denen kein Komma vorkommt, > macht dich gar nicht stutzig? Das sind also auch keine ganzen Zahlen, > sondern Kommazahlen? Richtig, mathematisch ist das so. Und stutzig macht mich da gar nichts, führende Nullen schreibt man nicht, ein Komma, wenn nur Nullen folgen, auch nicht. Menschliche Faulheit oder Papier sparen. npn schrieb: >> "immer floating point, in anderen Sprachen ebenso." > Also ist die Integer-Zahl "1234" ebenfalls "floating point"? Richtig, Zahlen in lua sind immer floating point, gibt auch andere Sprachen, die so arbeiten. In wieder anderen Systemen sind Zahlen strings, so wie man es schreibt, und die können auch rechnen. Oder sie werden je nach Operation immer passend gewandelt. apfel schrieb: > 9356 xor 2608 = ? ist sinnfrei, wenn man nicht noch einige Bedingungen dazu schreibt: die beiden Zahlen müssen Ganzzahlen sein, sie müssen intern binär im Zweierkomplent dargestellt werden, nicht BCD und auch nicht als Zeichenstring, ... MfG Klaus
Klaus schrieb: > Richtig, Zahlen in lua sind immer floating point Warum wird dann in lua zwischen "integer" und "float" unterschieden? Zitat (Wiki): "Neben den Datentypen nil, boolean, number (mit den internen Subtypen integer und float)," ================= Oder noch ein anderes Zitat (lua reference manual): "The conversion from float to integer checks whether the float has an exact representation as an integer (that is, the float has an integral value and it is in the range of integer representation). If it does, that representation is the result. Otherwise, the conversion fails." Wie kann eine Conversion fehlschlagen, wenn es doch nur "floating point" gibt? Wie kann es sein, daß es überhaupt eine Conversion zwischen "integer" und "float" gibt, wenn es laut deiner Aussage nur "float" gibt? Und an vielen Stellen des manuals wird ausdrücklich auch von "integer" gesprochen! Also entweder lügt das lua reference manual, oder der Irrtum ist auf deiner Seite!
npn schrieb: > Also entweder lügt das lua reference manual, oder der Irrtum ist auf > deiner Seite! Hast aber recht, da hat sich wohl was geändert. Im "Programming in lua" von Roberto Ierusalimschy, was ich grad aufgeschlagen hab, steht > The number type represents real (double-precision floating-point) > nunmbers. Lua has no integer type, as it does not need it. in einem neueren Text steht: > Therefore, the programmer may choose to mostly ignore the difference > between integers and floats Aber falls dir lua nicht gefällt, schau mal bei Javasript vorbei. > JavaScript has only one type of number. > Numbers can be written with, or without, decimals: > var x = 3.14; // A number with decimals > var y = 34; // A number without decimals MfG Klaus PS: "lügt" ist ja schlimm, kommt das manual dann in die Hölle? Bei mir ist das zum Glück ja nur ein Irrtum.
Klaus schrieb: > PS: "lügt" ist ja schlimm, kommt das manual dann in die Hölle? Bei mir > ist das zum Glück ja nur ein Irrtum. Naja, entweder lag dort der Fehler oder bei dir. Eine andere Möglichkeit sah ich nicht. War vielleicht etwas drastisch ausgedrückt. Aber schön, daß wir diesen Irrtum ausgeräumt haben :-) War nicht persönlich gemeint... Nichts für ungut :-)
Beitrag #5134380 wurde von einem Moderator gelöscht.
npn schrieb: > War nicht persönlich gemeint... > Nichts für ungut :-) Hab ich auch nicht so aufgefasst. Was sich aber ergeben hat ist, daß über die Zeit sich die Innereien von lua geändert haben. Mein Zitat bezieht sich auf die Version 5.0, deines IMHO auf 5.3. Beide sind sicher nicht grundfalsch, eher kontext oder zeitabhängig. Daher stoßen mir moralische Begriffe wie "Lüge" im technisch-wissenschaftlichen Bereich sauer auf. Das wollte ich mit meinem Bezug auf "Hölle", die ebenfalls keine wirkliche technische Relevanz hat, zum Ausdruck bringen. Hätte vielleicht ;) dahinter schreiben sollen MfG Klaus
C. A. Rotwang schrieb: > Mike B. schrieb: > >> selbst mit den Zwischenschritten bin->dez((dez->bin) XOR (dez->bin)) >> kommt das gleiche Ergebnis > > muss nicht unbedingt decimal sein könnte auch hex sein, oder ASCII. Auf Grund einer fehlenden Angabe einer speziellen Basis oder eines speziellen Formates bin ich standardmäßig von dezimal angegebenen Zahlen ausgegangen. Wer 9356, 2608 und 11964 flux auf dem Papier von dez zu bin umwandeln kann, ja der kann diese Aufgabe auf dem Papier lösen. ;-)
Mike B. schrieb: > Wer 9356, 2608 und 11964 flux auf dem Papier von dez zu bin umwandeln > kann, ja der kann diese Aufgabe auf dem Papier lösen. ;-) Stell dir vor, der Taschenrechner wurde schon erfunden! Gibt's übrigens auch als App für's Handy :-)
Adele schrieb: > Stell dir vor, der Taschenrechner wurde schon erfunden! > Gibt's übrigens auch als App für's Handy :-) Jepp, man kann dumm bleiben und es sich einfach machen oder man übt mal sowas mit 'Hirn' zu lösen. :-)
Der Andere schrieb: > Adele schrieb: >> Stell dir vor, der Taschenrechner wurde schon erfunden! >> Gibt's übrigens auch als App für's Handy :-) > > Jepp, man kann dumm bleiben und es sich einfach machen oder man übt mal > sowas mit 'Hirn' zu lösen. > :-) Genau, und eine Baugrube für ein Hochhaus hebt man auch mit der Sandkastenschippe aus. Man soll es sich ja nicht zu einfach machen und geeignete Werkzeuge dafür benutzen! ;-)
Der Andere schrieb: > man kann dumm bleiben und es sich einfach machen oder man macht es wie Klaus und erklärt einfach, dass es eine XOR-Verknüpfung zweier Zahlen überhaupt nicht gibt - Problem gelöst, Gehirn geschont. Georg
Georg schrieb: > oder man macht es wie Klaus und erklärt einfach, dass es eine > XOR-Verknüpfung zweier Zahlen überhaupt nicht gibt - Problem gelöst, > Gehirn geschont. Wenn man das denn hat :-) Irgendwie scheint mit die Diskussion recht sinnfrei - da gibt es schlicht nichts zu diskutieren!
hört auf euch zu streiten ich habe um 13:06Uhr nur > Wer 9356, 2608 und 11964 flux auf dem Papier von dez zu bin umwandeln > kann, ja der kann diese Aufgabe auf dem Papier lösen. ;-) deswegen geschrieben, weil Ulf L. um 8:34Uhr schrieb > geht doch ganz einfach auf einen Stück Papier. natürlich darf jeder seinen Grips anstrengen und das per Hand zu Fuß errechnen oder eben ein geeignetes Werkzeug benutzen. Kindergarten hier...
Georg schrieb: > oder man macht es wie Klaus und erklärt einfach, dass es eine > XOR-Verknüpfung zweier Zahlen überhaupt nicht gibt Klar gibt es die, nennt sich XOR-Verschlüsselung: https://www.heise.de/security/artikel/XOR-Verschluesselung-270952.html
Bitwurschtler schrieb: > XOR-Verschlüsselung: Für Schwachmaten? Nix Verschlüsselung - einfach XOR ... nix besonderes.
Ulf L. schrieb: > Zwei Zahlen bitweise XOR verknüpfen, geht doch ganz einfach auf einen > Stück Papier. Zahlen nach binär, dann verXodern, dann wieder nach > dezimal >
1 | > 0010 0100 1000 1100 9356 |
2 | > 0000 1010 0011 0000 2608 |
3 | > |||| |||| |||| |||| |
4 | > VVVV VVVV VVVV VVVV xor |
5 | > 0010 1110 1011 1100 11964 |
6 | > |
Oder für Faule, weil ja bald Hex eingeführt wird (scnr):
1 | 1001 0011 0101 0110 9356 |
2 | 0010 0110 0000 1000 2608 |
3 | |||| |||| |||| |||| |
4 | VVVV VVVV VVVV VVVV xor |
5 | 1011 0101 0101 1110 D55E |
Johann L. schrieb: > Oder für Faule, weil ja bald Hex eingeführt wird (scnr) Hätte Gott gewollt, dass der Mensch Computer baut, hätte er ihm 16 Finger gegeben.
Rolf M. schrieb: > Johann L. schrieb: >> Oder für Faule, weil ja bald Hex eingeführt wird (scnr) > > Hätte Gott gewollt, dass der Mensch Computer baut, hätte er ihm 16 > Finger gegeben. Jetzt frag ich mich wieviel Finger ein Baske hat, oder ein Babyloner hatte: https://en.wikipedia.org/wiki/List_of_numeral_systems 8-O
Rolf M. schrieb: > Hätte Gott gewollt, dass der Mensch Computer baut, hätte er ihm 16 > Finger gegeben. Wozu denn? 10 Finger sind zum Schälen einer Banane voll ausreichend, zum Bau von Computern ebenso. C. A. Rotwang schrieb: > Jetzt frag ich mich wieviel Finger ein Baske hat, oder ein Babyloner Weiß ich auch nicht, habe aber gelesen, daß es bei Bewohnern im Bereich des Bikini-Atolls nach den A-Bombentests Nachwuchs mit 6 Fingern pro Hand gegeben haben soll. Von "besser rechnen können" war da aber keine Rede.
Rainer V. schrieb: > Rolf M. schrieb: >> Hätte Gott gewollt, dass der Mensch Computer baut, hätte er ihm 16 >> Finger gegeben. > > Wozu denn? 10 Finger sind zum Schälen einer Banane voll ausreichend, zum > Bau von Computern ebenso. > > C. A. Rotwang schrieb: >> Jetzt frag ich mich wieviel Finger ein Baske hat, oder ein Babyloner > > Weiß ich auch nicht, habe aber gelesen, daß es bei Bewohnern im Bereich > des Bikini-Atolls nach den A-Bombentests Nachwuchs mit 6 Fingern pro > Hand gegeben haben soll. Von "besser rechnen können" war da aber keine > Rede. Die 6-fingrigkeit gibt es erst nicht erst seit den Wasserstoffbombentest, genetisch also "von Gott" ist wohl die Tierwelt ohnehin auf eine variierende Anzahl von Fingern vorprogrammiert, die auch nicht unbedingt symmetrisch verteilt sein muß: https://de.wikipedia.org/wiki/Polydaktylie Die "Zivilisationsstifter" im Zweistromland (Sumerer) rechneten im 60iger system, die in Amerika (Maya) dagegen im Zwanziger. Und schaut man sich das römische Zahlensystem an, glaubt man fast, das wäre im Sägewerk entstanden. -> ein natürliches System gibt es IMHO nicht, es ist immer subjektiv welches System angewandt wird. Und da macht es Sinn Operatoren für beliebige Symbolbreiten zu definieren, wie man es in der Algebra mit dem https://de.wikipedia.org/wiki/Galoisfeld macht. Da aber die Arbeiten der Akademiker und Kryptographen nicht in der Allgemeinheit vertraut sind, entsteht der Eindruck das XOR nur bitweise Sinn macht - dem ist aber nicht so. PS: Interessanter Fakt: Das "XOR-Problem" hätte fast die Forschung zu Neuronalen Netzen beendet, weil die ursprünglich modellierten Netze keine XOR-Funktion erlernen konnten.
Yalu X. schrieb: > Viele Programmiersprachen definieren tatsächlich einen Operator, der > zwei Integer-Zahlen bitweise XOR-verknüpft. Nur heißt dieser Operator – > abgesehen von ein paar nicht der Norm entsprechenden Basic- und > Pascal-Dialekten – meist nicht "xor", sondern bspw. "^". Das ist genau, was ich an diesen C-lern so abgrundtief hasse. Die Arroganz, "ihre" Sprache für die allgemein gültige Norm zu halten. Im übrigen: was ist wohl leichter als xor-Operation zu lesen, das, wo direkt "xor" dransteht oder das, wo irgendein ziemlich willkürlich gewähltes Zeichen die entsprechende Operation repräsentiert? Soll heißen: C ist ein Sprache, die geschaffen wurde, um möglichst kryptisch und unlesbar zu sein. Basic und Pascal hingegen wurden geschaffen, damit man den Code recht einfach lesen kann, zumindest wenn man Englisch als natürliche Sprache kann.
ah, c-hater ist auch schon auf. Kein Thread, in dem der Buchstabe "C" auftacht, ohne den lieben c-hater.
c-hater schrieb: > was ist wohl leichter als xor-Operation zu lesen, das, wo > direkt "xor" dransteht oder das, wo irgendein ziemlich willkürlich > gewähltes Zeichen die entsprechende Operation repräsentiert? Und was ist leichter zu lernen und schneller zu schreiben? Außerdem kannst Du Dir in sehr vielen aktuellen Versionen von heute genutzten Hochsprachen die Operatoren so definieren wie Du willst, auch in ausgeschriebenem Englisch. Pascal erzwingt seine eigene Syntax weil die Grundidee bei der Entwicklung von Pascal ein "besserer Programmierstil" war. Da wird einem noch eher alles aufgezwungen. Basic ist fast immer eine Interpretersprache und ist als Einsteigersystem gedacht und nicht zur resourcenschonenden+hardwarenahen Entwicklung. c-hater schrieb: > C ist ein Sprache, die geschaffen wurde, um möglichst > kryptisch und unlesbar zu sein. Eigentlich waren die Gründe für C genau das Gegenteil. Es ist auf jeden Fall besser und angenehmer in C als in Assembler zu arbeiten.
Chris F. schrieb: > Es ist auf jeden > Fall besser und angenehmer in C als in Assembler zu arbeiten. Aber nur, wenn man mit Assembler nicht umgehen kann. -Feldkurat-
Feldkurat K. schrieb: > C als in Assembler zu arbeiten. > > Aber nur, wenn man mit Assembler nicht umgehen kann. Ich denke das kannst Du nicht beurteilen und den Vergleich auch garnicht anstellen.
Chris F. schrieb: > Ich denke das kannst Du nicht beurteilen und den Vergleich auch garnicht > anstellen. Bist Du der große Zampano oder was?! Wenn ich das nicht beurteilen könnte, hätte ich es nicht geschrieben. -Feldkurat-
Chris F. schrieb: > Bist Du es? Was soll der Müll? Ich sage: Assembler ist leichter zu erlernen und übersichtlicher als C. Du sagst das Gegenteil. Sei's drum -wir kommen auf keinen Nenner. Trotzdem sage ich, was ich zu sagen habe. -Feldkurat-
Rainer V. schrieb: > Rolf M. schrieb: >> Hätte Gott gewollt, dass der Mensch Computer baut, hätte er ihm 16 >> Finger gegeben. > > Wozu denn? 10 Finger sind zum Schälen einer Banane voll ausreichend, zum > Bau von Computern ebenso. Du weißt, warum unser Zahlensystem "zufällig" die Basis 10 hat? Wenn man mit Computern arbeitet, rechnet sich's bekanntlich auf Basis 16 besser, was für uns sehr natürlich wäre, wenn das auch die Anzahl unserer Finger gewesen wäre. > C. A. Rotwang schrieb: >> Jetzt frag ich mich wieviel Finger ein Baske hat, oder ein Babyloner > > Weiß ich auch nicht, habe aber gelesen, daß es bei Bewohnern im Bereich > des Bikini-Atolls nach den A-Bombentests Nachwuchs mit 6 Fingern pro > Hand gegeben haben soll. Von "besser rechnen können" war da aber keine > Rede. Warum sollte man mit 6 Fingern pro Hand auch besser rechnen können?
Rolf M. schrieb: > Warum sollte man mit 6 Fingern pro Hand auch besser rechnen können? 60 Finger wären korrekter, braucht(e) man aber gar nicht: https://de.wikipedia.org/wiki/Sexagesimalsystem Rechenmeister Mittring richtet sein KalenderimKopf-Rechensystem auf die Zahl 12 aus, ist also nicht weit davon weg.
Chris F. schrieb: > Und was ist leichter zu lernen Als C? Pascal und Basic natürlich. Denn genau dafür wurden sie ja geschaffen. > und schneller zu schreiben? Mit modernen IDEs? Pascal und Delphi natürlich. Dank der höheren Redundanz im Code kann eine Codevervollständigung á la MS "IntelliSense" hier viel effizienter und treffender erahnen, was der Benutzer als nächstes wohl schreiben will. Sehr schön kann man das im direkten Vergleich in VS zwischen C# und VB sehen. Beides erzeugt ja de facto den gleichen (CIL-)Zwischencode und greift auch auf die gleichen Bibliotheken zurück. Aber C# ist recht "C'isch" und kommt deshalb statistisch mit wesentlich weniger Zeichen im Quelltext aus als VB. Geht das Schreiben von Code dadurch schneller? DEFINITIV NEIN. Und das gleich aus mehreren Gründen. Zum einen kommt, wie gesagt, Intellisense (genauer: der tokenizer) hier auf Grund der geringeren Quelltext-Redundanz viel öfter "aus dem Tritt" als in VB. Das führt u.a. auch dazu, dass beim kleinsten Tippfehler gleich gerne mal tausende Zeilen eingefalteten Codes einfach mal ausgefaltet werden, was ein "very annoying behaviour" ist... Zum anderen werden in C# Sachen als Kommentar nötig, die in VB bereits durch den Quelltext selbst dokumentiert werden. Ich denken da z.B. an die typische Wüste schließender curly braces zum Ende von wasauchimmer hin, wo der C'ler (und auch der C#'ler) dann gerne mal Kommentare einstreut á la " } //end if". Das ist in VB nicht nötig, da steht dann nämlich einfach schon "end if", "next", "end structure", "end class", "end namespace" usw.... > kannst Du Dir in sehr vielen aktuellen Versionen von heute genutzten > Hochsprachen die Operatoren so definieren wie Du willst, auch in > ausgeschriebenem Englisch. Ja, gerade dieses Feature (operator overloading) bietet sich an, um jeden Quelltext endültig zu "Klartext-Verschlüsseln". Man sollte dieses Feature eher nur sparsam einsetzen. Dazu gehört ganz sicher nicht, Standard-Operatoren für Standard-Datentypen (der jeweiligen Sprache) zu ersetzen. Das ist allerdings ganz offensichtlich spezielles Hobby einiger C#- und C++-Wichser geworden... BTW: Natürlich kann man auch in VB.net Operatoren überladen... > Eigentlich waren die Gründe für C genau das Gegenteil. Es ist auf jeden > Fall besser und angenehmer in C als in Assembler zu arbeiten. Tja, das war tatsächlich der Plan, insofern gebe ich dir Recht. Er ist nur leider ziemlich kläglich gescheitert... De facto kann man in C nicht kompetent programmieren, ohne über fast so weitgehende Kenntnisse über das Zielsystem zu verfügen, wie sie auch für Assemblerprogrammierung nötig sind. Weil das so ist, gibt es auch so viele unsäglich schlechte C-Programme und so ungeheuer viele Sicherheitslücken in C-Programmen... Also: Wenn Hochsprache, dann doch besser sowas wie C#, Java oder VB.net. Erst auf diesem Level kann man tatsächlich oft (aber leider immer noch nicht grundsätzlich) auf spezielle Kenntnisse über die Zielmaschine verzichten und viele Standardfehler (=potentielle Sicherheitslücken), die aus der Unkenntnis dieser Details resultieren, werden standardmäßig von der Laufzeitumgebung abgefangen.
Ja klar, Makroassembler und Spaghetticodeschleifen sind natürlich viel besser. scnr Ein C++-Wichser wünscht Dir einen schönen Sonntag.
c-hater schrieb: > Weil das so ist, gibt es auch so > viele unsäglich schlechte C-Programme und so ungeheuer viele > Sicherheitslücken in C-Programmen... Und wenn 90% Pascal, Ruby, Haskell oder sonstwas programmieren würden, gäbe es vermutlich genausoviele Idioten wie bei C, die mit der Sprache Unsinn anstellen. Vermutlich zwar weniger harte Crashes, aber mehr algorithmischen Schrott. Wer "richtig" programmieren kann, kann das IMO prinzipiell in jeder Sprache. Und wenn er dann Fehler macht, macht er in jeder Sprache welche, nur eben andere. BTW: Meine "Erfahrungen" mit einigen scheinbar guten Pascal/Delphi/Lazarus-Missionaren sind jedenfalls nicht so toll. Grosse Klappe, wie toll das alles ist und wo C/C++ überall "lagt" und dann bei echten Problemen das Projekt aufgeben und die Schuld überall anders suchen. Danke, brauche ich nicht mehr. > Also: Wenn Hochsprache, dann doch besser sowas wie C#, Java oder VB.net. Java? Echt jetzt? Ich habe noch von keiner Sprachplattform soviele Crashes aka Stacktraces gesehen, wie von Java. Und damit meine ich nicht Bastelzeug, sondern "produktive" Programme *). Das Gedöns ist ein mimosenhaftes Aufeinandergestaple von Runtime-Anforderungen und komplexen Frameworks, das keiner mehr durchblickt. Wird nur noch übertroffen von Javascript, aber da gehört das so ;) *) Ja, es gibt auch grosse Java-Anwendungen, die offensichtlich funktionieren. Finde ich durchaus bewundernswert...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.