A. K. schrieb: > Jörg W. schrieb: >> kennt jemand heute noch Standleitungen mit Bitstrom-Protokollen? ;-) > > SDLC/HDLC? Das bildet die Basis des D-Kanal-Protokolls von ISDN. Das ist mir schon klar, aber wer hat denn heutzutage noch eine Mietleitung, die von A nach B führt und so ein Protokoll fährt?
Jörg W. schrieb: > Das ist mir schon klar, aber wer hat denn heutzutage noch eine > Mietleitung, die von A nach B führt und so ein Protokoll fährt? Diverse Unternehmen/Behörden, die Upstreams zu Satelliten angemietet haben. Okay, die "Mietleitung" besteht nicht aus Kupfer, aber es ist schon eine Leitung von A nach B. Ich habe da in den 90er Jahren Unix-Rechner über SDLC/HDLC über Uplinkschüsseln mit mehreren Metern Durchmesser an Satelliten angebunden. War ein sehr interessantes Projekt - auch wenn dann am anderen Ende kein Unix-Rechner, sondern ein IBM-Host stand.
:
Bearbeitet durch Moderator
Frank M. schrieb: > Diverse Unternehmen/Behörden, die Upstreams zu Satelliten angemietet > haben. Ah OK. Den Anwendungsfall kannte ich so nicht. Aber als reine Internet-Links (wie vor 20+ Jahren) dürften sie mittlerweile weitgehend verschwunden sein.
Frank M. schrieb: > A. K. schrieb: >> Weshalb das auch D heisst, und nicht C(Version20xx). > > Mift. Also ist der Name D schon belegt. Mit unserer eigens neu zu > schaffenden Programmiersprache müssen wir uns also zwischen C und D > quetschen. C++ ist ebenso schon belegt, bleibt also noch D-- übrig :-) Oder D♭ (des - auf Englisch "d flat"), analog zu C♯ (cis - auf Englisch C sharp). https://en.wikipedia.org/wiki/D%E2%99%AD_(musical_note) Nop schrieb: > Wir werden uns darüber eher nicht einig werden, aber Du siehst hier ja > zumindest, daß die Ansicht, Pascal sei eine Verbesserung im Vergleich zu > C, offensichtlich kontrovers ist. Ich vermute, dass er das bisher überhaupt nicht gesehen hat, da er seine eigene Meinung einfach zur unumstößlichen Tatsache und alle, die was anderes sagen, zu Idioten erklärt. Im übrigen ein Diskutierstil, der alles andere tut als den Fortschritt zu fördern.
Da wird grad bei D waren: Ich hatte mir das vor längerer Zeit mal angesehen, aber es hat sich seither weiter entwickelt. Es lohnt sich, da mal rein zu sehen: http://dlang.org/spec/spec.html https://en.wikipedia.org/wiki/D_(programming_language) Um ein paar Dinge zu nennen: So halte ich die Contracts für eine recht nette Idee. Klar, man kann (und sollte) das, was im Contract steht, sowieso in die Funktion packen. Aber man vergisst man das gerne und so ist es übersichtlicher. Dann gibt es einen Subset SafeD, in dem der Compiler sicherstellt, dass dieser Code keine unsicheren Speicherzugriffe durchführen kann. Die Deklarations-Syntax ist linear, nicht mehr anhand von Prioritäten verschachtelt. "int*[] a,b" statt "int *a[],*b[]" beispielsweise.
:
Bearbeitet durch User
A. K. schrieb: > Es lohnt sich, da mal rein zu sehen: > http://dlang.org/spec/spec.html > https://en.wikipedia.org/wiki/D_(programming_language) Ich lese da auch schon seit einer guten Stunde drin rum, sehr interessant :-) > So halte ich die Contracts für eine recht nette Idee. Ja, sehr interessant - auch wenn man das klassisch ebenso formulieren könnte. Nur bei den Invariants habe ich noch Verständnisprobleme. Wann werden die Prüfungen durchgeführt? Ausschließlich im Constructor? > Dann gibt es einen Subset SafeD, in dem der Compiler sicherstellt, dass > dieser Code keine unsicheren Speicherzugriffe durchführen kann. Was mich direkt zu den Arrays und den neuartigen Operatoren auf Arrays geführt hat, z.B. das Kopieren mittels:
1 | s[1..2] = t[0..1]; |
Wenn man so überlappende Speicherbereiche kopiert, gibts einen Fehler.
Sehr nett. :-)
Was ist mit Strings? Da ist zu lesen:
"A string is an array of characters.".
Also doch alles wie in C, was Strings betrifft?
Weiter:
"Since strings, however, are not 0 terminated in D, when
transferring a pointer to a string to C, add a terminating 0"
Wohl nicht, das terminierende NUL gibt es nicht in D...
Zuletzt: "printf() is a C function and is not part of D."
Upps, kein printf() in D. Um es zu verwenden, muss der D-String mittels
Terminierung in einen C-String umgewandelt werden:1 | str ~= "\0"; |
2 | printf("the string is '%s'\n", cast(char*)str);
|
Finde ich nicht so gelungen. > Die Deklarations-Syntax ist linear, nicht mehr anhand von Prioritäten > verschachtelt. "int*[] a,b" statt "int *a[],*b[]" beispielsweise. Multiple Definitionen von mehreren Variablen in einem Statement würde ich abschaffen. Finde ich überflüssig und unleserlich, egal ob jetzt in C oder in D.
:
Bearbeitet durch Moderator
Franz Ferkel schrieb: > Darf man fragen ob dieser Thread auch eine for(;;) ist ? Och komm, eine Diskussion über for(;;) selbst ist doch totlangweilig... :-) Außerdem ist heute Freitag. Hab noch was gefunden: "The best way is to use std.stdio.writefln, which can handle D strings:" import std.stdio; writefln("the string is '%s'", str); Man braucht also gar kein C-printf() und damit auch keine Terminierung in D. Ontopic: Eine Endlosschleife in D muss man wohl genau wie in C formulieren. Oh, watt is datt schlimm...
Jörg W. schrieb: > Mir ist so, als würde NetBSD „meine“ Implementierung nach wie vor > für PPP-over-Ethernet benutzen. Ist doch schoen, wenn es so ist, oder etwa nicht? :)
Kaj schrieb: > Ist doch schoen, wenn es so ist, oder etwa nicht? Yep, zumal das eine Anwendung ist, an die ich beim Erstellen der Software nicht einmal hätte denken können. ;)
Frank M. schrieb: > Was ist mit Strings? Da ist zu lesen: > > "A string is an array of characters.". > > Also doch alles wie in C, was Strings betrifft? > > Weiter: > > "Since strings, however, are not 0 terminated in D, when > transferring a pointer to a string to C, add a terminating 0" > > Wohl nicht, das terminierende NUL gibt es nicht in D... Und wo ist da der Fortschritt von D gegenüber C? Speicherblöcke, die '\0' enthalten können, kann man in C auch mit den mem... Funktionen behandeln. Innerhalb eines Strings hat ein Nullbyte keine sinnvolle Verwendung. In C kann man wegen der Nullterminierung einen String sehr einfach und effizient ohne Rumkopieren in mehrere Teilstrings aufteilen, indem man Trennzeichen durch '\0' ersetzt. In D ginge das nicht mehr. Toller Fortschritt!
Jobst Q. schrieb: > Speicherblöcke, die '\0' enthalten können, kann man in C auch mit den > mem... Funktionen behandeln. Es geht in D nicht darum, ob man damit etwas kann, was man in C nicht kann. Dem ist nicht so. Es geht um das wie, nicht um das ob. C ist Turing-vollständig. Du solltest also auf die Turing-Maschine umsteigen. Die kann alles was Assembler kann, alles was C kann, alles was C++ kann, alles was Java kann, alles was ... Und ist zudem viel leichter verständlich. ;-)
Ok ok, aber die entscheidende Frage ist doch: Kann man denn auch in D wirklich Fortran programmieren? duck
Nop schrieb: > Ok ok, aber die entscheidende Frage ist doch: Kann man denn auch in D > wirklich Fortran programmieren? *duck* Aber klar doch. Du kannst dir darin beispielsweise einen FORTRAN Compiler schreiben. Ist sogar leichter als umgekehrt. ;-)
A. K. schrieb: > Du kannst dir darin beispielsweise einen FORTRAN > Compiler schreiben. Das kann man auch in Pascal, insofern wäre das Cheaten. ;-)
Ist eine Sprache besser, wenn man sich mit ihr leichter ins Knie schiessen kann? Oder führt das am Ende bloss zu lauter Gehbehinderten? Es mag zwar vielen Schreinern gelingen, ein Bandsäge zu benutzen, ohne am Ende wie Monty Pythons Schwarzer Ritter auszusehen. Programmierern gelingt das jedoch nicht. Sie haben nur das Glück, dass es eher die anderen Leute sind, die dabei verlieren. Vielleicht wärs also besser, deren Alltagswerkzeuge etwas weniger gefährlich zu machen.
:
Bearbeitet durch User
A. K. schrieb: > Es geht in D nicht darum, ob man damit etwas kann, was man in C nicht > kann. Dem ist nicht so. Es geht um das wie, nicht um das ob. Umständlicher gehts immer. Das ist aber noch kein Fortschritt. C ist ein Riesenfortschritt gegenüber Assembler, weil es von der Hardware abstrahiert und mit guten Compilern fast die gleiche Effizienz erreichen kann. C++ ist ein Fortschritt gegenüber C, weil es objektorientiertes Programmieren ermöglicht, aber es eben nicht erzwingt, sondern einfaches C mit umfasst. D scheint da mehr ein C-- zu sein, da es die Möglichkeiten von C beschneidet und effiziente Funktionen durch umständlichere Methoden ersetzt.
Jobst Q. schrieb: > D scheint da mehr ein C-- zu sein, da es die Möglichkeiten von C > beschneidet und effiziente Funktionen durch umständlichere Methoden > ersetzt. Völlig richtig. Es wird deutlich umständlicher, sich ins Knie zu schiessen. Es mag dir seltsam vorkommen, aber ich sehe darin einen Fortschritt.
:
Bearbeitet durch User
Ich finde die entsprechende AN nicht aber von Atmel gibt es Tipps für Speicheroptimierung / Geschwindigkeit z.B. Atmel AVR4027: Tips and Tricks to Optimize Your C Code for 8-bit AVR Microcontrollers Im Endeffekt was der Compiler aus dem C Code macht. Sprich for (;;) wird vom Compiler "am Besten" umgesetzt.
Eine anfängertaugliche Programmiersprache gibt's doch schon seit 1964. Man muß keinen portablen Makroassembler nehmen, wenn man keine Performance haben will.
A. K. schrieb: > Völlig richtig. Es wird deutlich umständlicher, sich ins Knie zu > schiessen. Es mag dir seltsam vorkommen, aber ich sehe darin einen > Fortschritt. Mit einem Messer kann man sich erstechen, mit einem Gürtel kann man sich aufhängen. Aber warum sollte man das tun? Trotzdem möchte ich weder auf messer noch auf Gürtel verzichten. Und in so einer Pädagogenwelt, in der alles verboten ist, womit man sich schaden könnte, möchte ich nicht leben.
Jobst Q. schrieb: > Mit einem Messer kann man sich erstechen, mit einem Gürtel kann man sich > aufhängen. Das ist wahr. Aber warum tun Programmierer das andauernd? Also warum erstechen Programmierer immer mal andere Leute oder erhängen sie? Denn das tun sie immer und immer wieder. Würden sie nicht andere Leute damit plagen, sondern sich selber, wärs schnell aus mit Gürtel und Messer. Oder mit dem Programmierer.
:
Bearbeitet durch User
A. K. schrieb: > Aber warum tun Programmierer das andauernd? Tun sie nicht. Da, wo es geht, verwendet man heute kein C mehr. Und tunlichst auch kein C++. Server-Anwendungen im größeren Maßstab macht man nicht mehr in Lowlevelsprachen. Aber Mikrocontroller sind kostensensitiv. Eine Bloatsprache mit allen Sicherheitsnetzen erzwingt nunmal einen größeren und damit teureren Controller. Bei entsprechenden Stückzahlen ist man damit aus dem Rennen gegenüber der Konkurrenz. Da kann man es sich nunmal nicht leisten, den halben Controller schon mit Müsli zu füllen.
Nop schrieb: > Server-Anwendungen im größeren Maßstab macht > man nicht mehr in Lowlevelsprachen. Stimmt. Das macht man beispielsweise in PHP. ;-)
Nop schrieb: > Da kann man es sich nunmal nicht leisten, den > halben Controller schon mit Müsli zu füllen. Stimmt. Man bewirft mit dem Mirai-Müsli statt dessen den Rest der Welt.
A. K. schrieb: > Man bewirft mit dem Mirai-Müsli statt dessen den Rest der Welt. Mag sein, aber wenn man es nicht tut, ist man pleite, und zwar deutlich bevor die Konkurrenz wegen Sicherheitslücken ein Update bringen muß. Das ist ja auch der Grund für MISRA - daß man im Regelfall C auf sehr pascalhafte Weise programmiert. Nur, wenn es technisch begründbar angemessen ist, dann darf man auch davon abweichen. Man muß nur analysieren, daß das dann kein Problem ergibt.
Nop schrieb: > Mag sein, aber wenn man es nicht tut, ist man pleite, und zwar deutlich > bevor die Konkurrenz wegen Sicherheitslücken ein Update bringen muß. Yep. Jetzt kommen wir langsam zum Punkt. Also weshalb beispielsweise manche Routerhersteller nicht schon längst pleite sind, obwohl sie zusammengeschluderte Firmware lange bekannten Exploits bringen und nie fixen, dafür aber vorsätzlich gleich mehrere Backdoors einbauen. Tja, die Welt ist unfair. Hätte AVM nicht vorbildlich gehandelt - die wären jetzt wohl pleite. Die Konkurrenz aus Billigstan und Nochbilligerstan macht seelenruhig weiter und niemanden scheint es zu stören.
:
Bearbeitet durch User
A. K. schrieb: > Hätte AVM nicht vorbildlich gehandelt - die > wären jetzt wohl pleite. Soso. Die haben also ein Linux, was nicht in C programmiert ist. Interessant. (Es ging hier nicht um die Frage, ob man Updates bringt, wenn Lücken da sind, sondern darum, daß man nicht in C programmieren sollte, damit weniger Lücken entstehen!)
Nop schrieb: > Soso. Die haben also ein Linux, was nicht in C programmiert ist. > Interessant. Quark. > (Es ging hier nicht um die Frage, ob man Updates bringt, wenn Lücken da > sind, sondern darum, daß man nicht in C programmieren sollte, damit > weniger Lücken entstehen!) Meine Aussage war eine Reaktion auf die von dir genannten zutreffenden wirtschaftlichen Zwänge. Mit C hatte sie nichts zu tun. Das Problem liegt aber ähnlich. Es ist oftmals erlaubt, billigst zu bauen und die Scheisse zum Himmel stinken zu lassen. Sorgfalt kostet, egal ob per Sprache, Hardware, Zeit fürs Programmieren etc. Das hast du selbst geschrieben, nur nicht so verallgemeinert. Dort wo es nicht erlaubt ist, ist zumindest die Reaktion mitunter fixer.
:
Bearbeitet durch User
Nop schrieb: > Aber Mikrocontroller sind kostensensitiv. Eine Bloatsprache mit allen > Sicherheitsnetzen erzwingt nunmal einen größeren und damit teureren > Controller. Bei entsprechenden Stückzahlen ist man damit aus dem Rennen > gegenüber der Konkurrenz. Da kann man es sich nunmal nicht leisten, den > halben Controller schon mit Müsli zu füllen. Das ist Quatsch. Bei einem Chinamodul, daß portofrei fast nackt für < 2€ verkauft wird, mag das stimmen. Ansonsten kostet alleine das Schreiben des hier erforderlichen "Beipackzettels" in allen EU-Sprachen und alle anderen Posten wie Zulassung, Garantieabwicklung, Marketing ... bei einem Produkt viel, viel mehr, als die paar zusätzlichen Cent für einen größeren µC. Nur der Einkauf, die Entwicklung rechnen sich da schön, für die Bilanz hat das keine Bedeutung. MfG Klaus
A. K. schrieb: > Quark. War mir natürlich auch klar. ;-) > Mit C hatte sie nichts zu tun Eben. > das Problem liegt aber ähnlich. Stimmt. > Es ist oftmals erlaubt, billigst zu bauen und die Scheisse zum Himmel > stinken zu lassen. Klar. Consumer kaufen alles. Hauptsache, der Schrott wird entweder mit entsprechendem Image beworben oder ist billig. Aber, Fakt ist - wenn man ernsthaft Performance will, geht an C oder auch C++ wenig vorbei. Nehmen wir mal Schach-Engines. Die stärkste, die nicht in C/C++ geschrieben ist, liegt im Moment auf Platz 25 (Delphi). Mit einem Abstand von über 300 ELO auf die Spitze. Das ist anderthalb Klassen darunter.
Oftmals sind die Folgekosten von Produkten externalisiert. Der Hersteller verdient damit Geld, ist aber nicht für die Folgen verantwortlich. Die bleiben beim Kunden hängen. Zwar kann niemand von Herstellern verlangen, perfekte Software zu bauen. Aber man sollte vielleicht verlangen können, kritische Probleme für einen Mindestzeitraum als vorgesehene Lebensdauer zeitnah zu fixen. Da diese Kosten eingepreist werden müssen, wird das Zeug natürlich teurer und so mancher IoT Hype verschwindet schneller wieder als er kommt. Nur so kann eine Kultur entstehen, die Sorgfalt in der Herstellung lohnenswert macht. Ob das nun Werkzeuge oder Zeit betrifft. Und dann kann es für einen Hersteller auch lohnend sein, etwas Ressourcen für dein "bloat" einzurechnen.
Nop schrieb: > Nehmen wir mal Schach-Engines. Kein Problem damit. Die Folgen von Bugs sind da höchstens peinlich. Aber wieviel Software des alltäglichen Lebens ist an der Grenze der gut verfügbaren Performance? Also wirklich, nicht bloss weil 25ct gespart für 64K statt 128K Flash. Und wieviel davon steckt an Stellen, an denen nicht bloss Elo-Punkte abgezogen werden, sondern ernsthaftere Konsequenzen drohen. Und das betrifft nicht nur Banken und Gesundheit. Wenn 25% aller Kühlschränke gleichzeitig ausfallen, weil Bug oder Exploit im IoT-Modul, dann stinkt das ziemlich zum Himmel. Auch wörtlich. Wie lange können wir angesichts der Durchdringung mit Software, besondern vernetzter Software, die bisherige Qualitätsunkultur durchhalten?
:
Bearbeitet durch User
Jobst Q. schrieb: > A. K. schrieb: >> Völlig richtig. Es wird deutlich umständlicher, sich ins Knie zu >> schiessen. Es mag dir seltsam vorkommen, aber ich sehe darin einen >> Fortschritt. > > Mit einem Messer kann man sich erstechen, mit einem Gürtel kann man sich > aufhängen. Aber warum sollte man das tun? Trotzdem möchte ich weder auf > messer noch auf Gürtel verzichten. Und in so einer Pädagogenwelt, in der > alles verboten ist, womit man sich schaden könnte, möchte ich nicht > leben. Mit Schusswaffen kann man sich/jemand aus Versehen erschießen, deshalb gibts Sicherungen, um das zu verhindern. Und so gibt es Sprachen, die nach einem ähnlichen Prinzip funktionieren. Ein guter Mittelweg, wie ich finde. Zeigerfrimeleien mach ich eher im Treibercode, dass ich mich damit auch im Code der Steuerungslogik ins Knie schießen kann, ist unnötig.
Nop schrieb: > Aber, Fakt ist - wenn man ernsthaft Performance will, geht an C oder > auch C++ wenig vorbei. Nehmen wir mal Schach-Engines. Die stärkste, die > nicht in C/C++ geschrieben ist, liegt im Moment auf Platz 25 (Delphi). > Mit einem Abstand von über 300 ELO auf die Spitze. Das ist anderthalb > Klassen darunter. Ich bezweifle, dass das hauptsächlich an C/C++ liegt. 1. So hervorragende Kompiler (gcc, icc...), wie im C/C++ Umfeld, sind anderswo eher selten (wenn man mal bei den nativen Sprachen bleibt). Bei so viel Arbeit die da jeden Tag reingesteckt wird, ist es kein Wunder. Nutzt halt auch jeder, vor allem die Industrie. Das wirkt sich vor allem auf die Optimierung aus. 2. Wie viel Aufwand wurde denn in die Delphi-Variante im Vergleich zu den anderen Varianten reingesteckt? Wäre die Delphi-Variante genauso gut oder sogar besser als die C++-Variante auf Platz 1., wenn gleich viel Aufwand hineingesteckt werden würde? 3. Qualität Algorithmus? (Analog zu Punkt 2.) Natürlich ist die Performance von C und C++ hervorragend, andere Sprachen könnten es aber genauso sein, wenn sie die gleiche Aufmerksamkeit bekommen würden.
> ...andere Sprachen könnten es aber genauso sein, wenn > sie die gleiche Aufmerksamkeit bekommen würden. Und warum bekommen sie die nicht? Warum floppen praktisch alle erdachten Sprachen, die die (vermeintlichen?) Schwächen von C und Konsorten abstellen wollen? rhf
Roland F. schrieb: > Warum floppen praktisch alle erdachten > Sprachen, die die (vermeintlichen?) Schwächen von C und Konsorten > abstellen wollen? Mit der Qualität der Sprachen hat das nichts zu tun.
A. K. schrieb: > Aber warum tun Programmierer das andauernd? Also warum > erstechen Programmierer immer mal andere Leute oder erhängen sie? Denn > das tun sie immer und immer wieder. Echt? Ist das so? Der Mörder ist immer der Programmierer? Na ein Glück, dass ich nur wenige Programmierer persönlich kenne. Obwohl ich auch Programmierer bin, verspür ich überhaupt kein Bedürfnis, jemanden zu erstechen oder aufzuhängen.
Roland F. schrieb: > Und warum bekommen sie die nicht? Warum floppen praktisch alle erdachten > Sprachen, die die (vermeintlichen?) Schwächen von C und Konsorten > abstellen wollen? Ich denke Rust ist ein echter Kandidat, gibt es jetzt auch schon fuer AVR, bzw. man arbeitet dran. https://github.com/avr-rust/rust Warum sich gewisse Sprachen nicht durchsetzen ist einfach: Faulheit. Die Faulheit des Menschen, sein gewohntes aufzugeben, etwas neues zu lernen, anders zu denken... Schau dir doch nur mal die Disskusionen zu Python an, wie viele Leute sich an dem Syntaxtischen Whitespace stoeren. Oder Rust: Warum muss ich bei einer Variablen extra angeben, dass ich sie veraendern koennne moechte? (Also das gegenteil von const in C/C++) Ist meiner Meinung nach voelliger Bloedsinn, da man in der Regel wohl > 97% aller Variablen veraendern koennen moechte. Und so faengt es an, mit den Vorurteilen und der Ablehnung. Obwohl ich die Sprache bisher nie benutzt habe, habe ich jetzt schon das Vorurteil, dass die Sprache mist ist, mag sie auch noch so gute Konzepte enthalten. Und so duerfte es jeder neuen Sprache gehen. Dazu kommt, dass fast monatlich eine neue Sprache geboren wird, die verspricht, das non plus ultra zu sein, und alles besser zu machen. Wie soll ich mich aber mit einer Sprache hinreichend auseinander setzen, wenn es ja fast taeglich eine neue gibt? Bis ich mich mit einer Sprache ausreichend beschaeftigt habe, ist sie ja schon wieder veraltet, und die Disskusion geht von vorne los: Warum nutzt du denn so einen alten, unsicheren Quark? <Hier neue Sprache einfuegen> ist viel sicherer und besser weil: ... Ich wuerde mir echt gerne Rust naeher anschauen, aber bei genauerer betrachtung, bringt es mir keinen grossen Mehrwert. Warum? Rust ist wie C -> Alles muss man selber von Hand machen. Wenn ich mir Python und C anschaue, dann hat Python einen echten Mehrwert, weil es eine unglaubliche maechtige Standard Lib gibt. Nahezu alles was man braucht bringt Python von Hause aus mit. Deswegen beschaeftige ich mit C und Python, weil mir jede Sprache, der anderen gegenueber einen echten Mehrwert hat (Geschwindigkeit <==> Komfort). Rust und C sind fuer mich so, als wenn ich mir 2 Fahrraeder in den Keller Stelle: Ja, das eine ist neuer und bietet mir etwas mehr Sicherheit, aber der echte Mehrwert ist mMn relativ klein. Ausserdem ist C als Sprache stabil, da tut sich nicht mehr viel. Wenn ich mir z.B. Python anschaue, wo von Version 3.4 auf 3.5 Methoden umbenannt wurden (subprocess.call <==> subprocess.run), dann ist das doch irgendwie Mist. (Das Abschneiden von Zoepfen und aufraeumen der Std-Lib wie beim Sprung von 2 auf 3 finde ich ok!) Sprachen, die sich noch "aktiv in der Entstehung" sind, sind halt auch unbequem und machen Arbeit, weil der Code mit der naechsten oder uebernaechsten Version vielleicht nicht mehr laeuft. Auch das ist ein Punkt, wo ich sage: Da nutze ich lieber C, anstatt Rust, Julia, Go, oder wie sie nicht alle heissen. Python hat einen Release-Zyklus von (ich glaube) 18 Monaten. Das heisst, du musst im schlechtesten Falle, alle 18 Monate deinen Code ueberarbeiten, und dafuer Sorgen, dass er mit der Aktuellen Version und vielleicht noch mit den letzten beiden Versionen laeuft. (Uebertriebene Darstellung!) Oder noch schlimmer: Waehrend du an einem Projekt arbeitest aendert sich die Sprache so stark, dass man grosse Teile des Projektes wegwerfen und komplett neu machen muss. Da stellt sich natuerlich auch die Frage, ob man sich sowas Leisten kann und ob man sich sowas Leisten will. Darueberhinaus gibt es natuerlich das Problem des Wissens. Wie viele C-Programmierer findet man? Und wieviele Programmierer findet man zu Rust oder Julia? In C sind praktisch alle Fallstricke bekannt (Overflows, Pointer, etc.), sie werden nur nicht beachtet, weshalb sie immer und immer wieder auftauchen. Wie ist es um das Wissen und die Dokumentation der Fallstricke in Rust bestellt? Das alles sind Gruende, weshalb es neue Sprachen so schwer haben, und weshalb sich alte Sprachen wie C so lange halten.
Kaj schrieb: > Schau dir doch nur mal die Disskusionen zu Python an, wie viele Leute > sich an dem Syntaxtischen Whitespace stoeren. Der Unterschied zu vielen anderen Sprachen: Python wird trotzdem benutzt, auch von denen, die sich (wie ich) über die Whitespace-Sache ärgern.
Roland F. schrieb: > A. K. schrieb: >> Mit der Qualität der Sprachen hat das nichts zu tun. > > Aber womit dann? Menschen sind oft faul oder nehmen sich nicht mehr die Zeit, sich weiterzubilden. Ich bin viel zu vielen Menschen begegnet, die immer noch ungarische Notation einsetzten, keine Ahnung von C99 haben und seit dem Berufsleben technologisch stehen geblieben sind. (Einer davon ist sogar Professor und relativ jung). Oder schau mal ins Gnome/Gtk Lager, die machen 2016 GUI-Anwenungen immer noch in C (würg). Ok und Toolchain/Bibliotheken, also das ganze außen rum, sind bei den etablierten Sprachen ziemlich gut. Das macht natürlich auch was aus. Kaj schrieb: > Roland F. schrieb: >> Und warum bekommen sie die nicht? Warum floppen praktisch alle erdachten >> Sprachen, die die (vermeintlichen?) Schwächen von C und Konsorten >> abstellen wollen? > Ich denke Rust ist ein echter Kandidat, gibt es jetzt auch schon fuer > AVR, bzw. man arbeitet dran. > https://github.com/avr-rust/rust Ah sehr schön, kannte ich noch gar nicht. ARM Cortex geht schon länger, eigentlich schon immer, da der Rust Kompiler auf llvm aufsetzt. Da werde ich die nächste Zeit mal was damit machen. https://github.com/japaric/xargo http://antoinealb.net/programming/2015/05/01/rust-on-arm-microcontroller.html Kaj schrieb: > Schau dir doch nur mal die Disskusionen zu Python an, wie viele Leute > sich an dem Syntaxtischen Whitespace stoeren. Sowas ist ja auch relativ diskussionswürdig. Das blöde ist, dass Leerzeichen und Tabulatoren nicht zu unterscheiden sind. Wie es ständig mit YAML Probleme gab oder letztens mit einem Makefile (bei einer Regel Leerzeichen statt Tabulator)... Kaj schrieb: > Oder Rust: > Warum muss ich bei einer Variablen extra angeben, dass ich sie > veraendern koennne moechte? (Also das gegenteil von const in C/C++) > Ist meiner Meinung nach voelliger Bloedsinn, da man in der Regel wohl > > 97% aller Variablen veraendern koennen moechte. > > Und so faengt es an, mit den Vorurteilen und der Ablehnung. Obwohl ich > die Sprache bisher nie benutzt habe, habe ich jetzt schon das Vorurteil, > dass die Sprache mist ist, mag sie auch noch so gute Konzepte enthalten. Nur ist das, gerade bei Rust, kein Unsinn, sondern hat seine Gründe. 1. In C++ gibts zwar const-correctness, nur wird sie viel zu oft vergessen. Das sieht man oft bei fremden Code. Auch ich bekomme es nicht hin const-correctness komplett durchzuziehen, einfach weil man schnell das const vergisst. Bei Rust ist das nicht so, da bekomme ich es hin, weil Variablen automatisch immutable sind und ich sie explizit auf mutable setzen muss. Das empfinde ich als Vorteil. 2. Ist es wichtig const-correctness in Rust einzuhalten, da die Sprache Aliasing bei veränderbaren Variablen verbietet, um Raceconditions unmöglich zu machen (außer natürlich im unsafe Block). Bei Rust liegt der Fokus nämlich auch stark auf Nebenläufigkeit. Die Eliminierung von Aliasing hat aber auch den Vorteil, dass aggressiver vom Kompiler optimiert werden kann. BTW. 97% sind echt stark übertreiben. Ich hab mal mein Programm analysiert, dass Dateien übers Netzwerk überträgt, eine kleine Fingerübung um in Rust reinzukommen. 27 Variablen sind immutable und 17 mutable, also gerade mal ~39%. Viele Variablen sind nämlich nur da, um Ergebnisse (z.B. von aufgerufenen Methoden/Funktionen) zwischenzuspeichern und werden ausgewertet, aber nie wieder verändert. Kaj schrieb: > Dazu kommt, dass fast monatlich eine neue Sprache geboren wird, die > verspricht, das non plus ultra zu sein, und alles besser zu machen. Ja weil es unglaublich viele verschiedene Probleme gibt, die es mit Programmiersprachen zu lösen gilt. Wenn du aber anfängst zu filtern, also den Einsatzbereich einschränkst, fällt dir schnell auf, dass es gar nicht so viele sind. Ich meine, wie viele Sprachen sind rausgekommen, die sich für Lowlevel-Zeug wie Treiber-/Kernelentwicklung oder µC eignen? R nicht, Julia auch nicht. Auch nicht Go (Server), Nimrod? Ne auch nicht wirklich. Eigentlich nur Rust und D. Kaj schrieb: > Ich wuerde mir echt gerne Rust naeher anschauen, aber bei genauerer > betrachtung, bringt es mir keinen grossen Mehrwert. Warum? > Rust ist wie C -> Alles muss man selber von Hand machen. Bitte was? Das muss dann für C++ ebenfalls gelten. Rust bietet sehr viel "zero cost abstraction" Sprachelemente. C hat ja nicht mal Referenzen. Speicherverwaltung geht in Rust auch viel komfortabler und vor allem sicher! Eine wesentlich mächtigere (optionale!) Standardbibliothek als die von C besitzt Rust auch. Also von dem her verstehe ich nicht was du damit meinst, dass sich Rust nicht wie Java anfühlt ist klar, aber zu Fuß ist was anderes. Kaj schrieb: > Auch das ist ein Punkt, wo ich sage: Da nutze ich lieber C, anstatt > Rust, Julia, Go, oder wie sie nicht alle heissen. Also Rust und Go sind schon ziemlich stabil. Seit Version 1.0 achten beide auf Abwärtskompatibilität und der Sprachkern wird höchstens erweitert. Wo es momentan ziemlich heftig ist, ist Swift von Apple.
:
Bearbeitet durch User
Christopher C. schrieb: > 1. So hervorragende Kompiler (gcc, icc...), wie im C/C++ Umfeld, sind > anderswo eher selten (wenn man mal bei den nativen Sprachen bleibt). a) Pascal sollte sich sogar noch effektiver compilieren lassen, weil man da von vornherein kein Problem mit Aliasing hat, denn Pascal hat eine strenge Typisierung. Genau das ist ja auch ein Grund, wieso bei Numerik Fortran immer noch überlegen ist. b) und WARUM gibt es für andere Sprachen nicht so hervorrangende Compiler? > 2. Wie viel Aufwand wurde denn in die Delphi-Variante im Vergleich zu > den anderen Varianten reingesteckt? Verkehrte Frage; es geht darum, wieso sich all die anderen, deren Engines besser sind, für C/C++ entscheiden haben. Oder man könnte gemein sein und folgern, daß C/C++-Programmierer am meisten Mühe in ihr Projekt stecken. > 3. Qualität Algorithmus? (Analog zu Punkt 2.) C/C++-Programmierer machen also die besten Algorithmen? Zu der Sache mit syntaktischen Leerzeichen: Das war sinnvoll, als man noch mit Lochkarten gearbeitet hat, da kommt das nämlich her. Deswegen hat Fortran das, weil es aus dieser Zeit stammt. In Texteditoren ist das einfach nur dämlich, sowas zu einzuführen.
Kaj schrieb: > Wie soll ich mich aber mit einer Sprache hinreichend auseinander setzen, > wenn es ja fast taeglich eine neue gibt? Eben. > Auch das ist ein Punkt, wo ich sage: Da nutze ich lieber C, anstatt > Rust, Julia, Go, oder wie sie nicht alle heissen. Zumal, wenn man sich auf die neueste, hipste Modesprache einläßt: wer garantiert mir, daß es dafür in 10 Jahren überhaupt noch Compiler gibt? Und daß ich nicht am Ende mit dem Projekt in einer Sackgasse stecke? C-Compiler wird es auch in 30 Jahren noch geben. > Darueberhinaus gibt es natuerlich das Problem des Wissens. > Wie viele C-Programmierer findet man? > Und wieviele Programmierer findet man zu Rust oder Julia? Was insbesondere im gewerblichen Einsatz entscheidend ist, Stichwort Busfaktor. Es kommt hinzu, daß man als Programmierer weiß, daß es haufenweise Projekte gibt, die in C sind, so daß man damit auch gefragt ist. Mit der neuesten Modesprache kann man für Hobbies sicher arbeiten, aber beruflich?! C hat noch einen Vorteil - die Sprache ist nicht an das Wohlergehen einer bestimmten Firma geknüpft. Insbesondere gibt es sehr gute Tools für diverse Plattformen unter Opensource-Lizenzen. Das hat zwei Konsequenzen: a) man gerät nicht in einen vendor-lock-in wie z.B. bei sämtlichen Microsoft-Ausgeburten. b) man wird nicht bleich, wenn die Firma strauchelt. Daß Embarcadero gerade dieses Jahr den spanischen Standort dichtgemacht und 80 Leute gefeuert hat, ist da ein unangenehmes Beispiel. c) Oder daß man sich z.B. mit Java heutzutage eine Firma wie Oracle ins Boot holt, was man nicht wirklich will. Zwar ist es embedded auch so, daß schon eine neue Windowsversion dafür sorgen kann, daß kommerzielle embedded-Compiler nicht mehr laufen. Vor allem wegen wegen Kopierschutzproblemen. Aber sofern man die compiler-spezifischen Erweiterungen sauber gekapselt hat, kann man notfalls auch auf GCC wechseln, wenn sonst gar nichts mehr geht. Andere Sprachen mögen besser sein, aber solange ihr Mehrwert nicht die Opportunitätskosten für den Wechsel übersteigt, floppen sie. Das ist ein Faktor, der im akademischen Elfenbeinturm keine Rolle spielt, in der Realität schon. Das wird egerne als "Faulheit" abgetan - bevorzugt von denen, die die Opportunitätskosten nicht zu tragen hätten.
Jobst Q. schrieb: > In C kann man wegen der Nullterminierung einen String sehr einfach und > effizient ohne Rumkopieren in mehrere Teilstrings aufteilen, indem man > Trennzeichen durch '\0' ersetzt. In D ginge das nicht mehr. Toller > Fortschritt! Es ist tatsächlich genau andersrum. ;-) In C muss man umständlich den Originalstring manipulieren, um ihn in Teile zu zerlegen. Wenn man das Original nicht verändern darf, muss man es vorher kopieren. In D kann man Substrings direkt als Strings weiterverwenden, ohne umständlich Nullen reinzuschreiben. Da dynamische Arrays aus Länge+Pointer bestehen, zeigt der Substring direkt in die Daten des ursprünglichen Strings. http://dlang.org/spec/arrays.html Slicing an array means to specify a subarray of it. An array slice does not copy the data, it is only another reference to it. For example:
1 | int[10] a; // declare array of 10 ints |
2 | int[] b; |
3 | |
4 | b = a[1..3]; // a[1..3] is a 2 element array consisting of |
5 | // a[1] and a[2]
|
:
Bearbeitet durch User
In C++ nennt sich das string_view. Man darf in konkreten Fall C nicht ankreiden den Original-String zu beschädigen. Das macht im D-Beispiel nämlich eine Änderung an b auch: " b ist eine Referenz auf a[1..3] "
Carl D. schrieb: > Das macht im D-Beispiel nämlich eine Änderung an b auch: Aber eben erst eine nachträgliche Änderung von b, nicht schon die Zerlegung des Strings. In C ändert bereits die Zerlegung selbst den Inhalt.
:
Bearbeitet durch User
A. K. schrieb: > Carl D. schrieb: >> Das macht im D-Beispiel nämlich eine Änderung an b auch: > > Aber eben erst eine nachträgliche Änderung von b, nicht schon die > Zerlegung des Strings. In C ändert bereits die Zerlegung selbst den > Inhalt. welcher Teil von "string_view" war denn nicht zu lesen?
Ich bin grad nicht bei C++, sondern bei C und D. Dass C++ Strings anders arbeiten als C Strings ist mir bewusst.
Man muss in D etwas aufpassen, ob man es mit statischen oder dynamischen Arrays zu tun hat. In obigem Beispiel wird b = a[1..3]; eine Referenz auf Daten in a produzieren, ein späteres b = ...was anderes...; wird aber nicht den durch b referenzierten Inhalt von a überschreiben, sondern die Referenz b auf den neuen Inhalt verweisen lassen. Nur mit b[] = ...; b[2] = ...; b[1..$] = ...; wird der referenzierte Inhalt geändert.
:
Bearbeitet durch User
Kaj schrieb: > Warum sich gewisse Sprachen nicht durchsetzen ist einfach: Faulheit. > Die Faulheit des Menschen, sein gewohntes aufzugeben, etwas neues zu > lernen, anders zu denken... So ganz stimmt das nicht. Ich war BASIC gewohnt, als ich C lernte und habe es liebend gerne aufgegeben. Gefrustet von der Inkonsistenz (unklare Regeln und viele Ausnahmen), den vielen Schlüsselwörtern, die oft gleichzeitig Funktionen bzw Aktionen waren, der Umständlichkeit der Stringbearbeitung und vielen anderen Ärgernissen, war es eine Befreiung und ein Segen, C kennen zu lernen. Mit anderen Worten, eine neue Sprache setzt sich durch, wenn es sich lohnt gegenüber der alten. Das Problem bei neuen Sprachen ist weniger die Faulheit als die Erwartungen. Die Vorstellungen, dass es so sein muss, wie man es kennengelernt hat. Dass etwas falsch ist, wenn es dann anders ist. Der Schritt von der ersten zur zweiten Sprache ist oft der schwerste, wenn man die erste Sprache mit dem Programmieren an sich identifiziert. Falsche Erwartungen sind auch die Ursache der meisten Programmierfehler. Wer zB von strncpy erwartet, dass es eine begrenzte Form von strcpy ist, wird irgendwann merken, dass er sich getäuscht hat. Denn das Ergebnis ist nicht immer ein String wie bei strcpy, sondern bei Überlänge des Quellstrings nur ein gefülltes Array, dem zum String die abschließende Null fehlt. Dafür wird bei kürzeren Strings der Rest des angegebenen Puffers mit Null-Bytes gefüllt, was bis auf die eine Endnull bei Strings überflüssig ist. Die Funktion wäre also mit str2array treffender benannt. Das ist aber kein Fehler der Sprache C sondern der Library-Entwickler bzw ein Mißverständnis zwischen ihnen und dem Anwender. Zur Vermeidung solcher Fehler muss man alle Funktionen und Methoden, die man verwendet, genau kennen, am besten den Quelltext. Und die Quelltexte der C-Lib sind leichter erhältlich als die von anderen Sprachen. Wenn man sich die Funktionen selbst schreibt, hat man diese Probleme nicht, man kann sie genau so schreiben, wie man sie braucht. Natürlich ist das alles "von Hand", aber das ist kein wirkliches Problem. Man muss sie ja nicht für jedes Programm neu schreiben. Einmal geschrieben, kann man sie tausendfach verwenden.
A. K. schrieb: > Jobst Q. schrieb: >> In C kann man wegen der Nullterminierung einen String sehr einfach und >> effizient ohne Rumkopieren in mehrere Teilstrings aufteilen, indem man >> Trennzeichen durch '\0' ersetzt. In D ginge das nicht mehr. Toller >> Fortschritt! > > Es ist tatsächlich genau andersrum. ;-) > > In C muss man umständlich den Originalstring manipulieren, um ihn in > Teile zu zerlegen. Um zB einen Kommentar abzutrennen, schreib ich s1=split(s,'#'); Dann hab ich den String ohne Kommentar in s und den Kommentar in s1. Was ist daran umständlich? Die Funktion selbst ist auch kein Aufwand: char * split(char *s,char c){ while (*s && *s!=c )s++; if (*s==c)*s++=0; return s; } > Wenn man das Original nicht verändern darf, muss man > es vorher kopieren. Wann braucht man schon mal einen unveränderbaren Originalstring? Normalerweise liest man eine Zeile aus einer Datei oder Eingabe in einen Puffer, der sowieso mit jeder Zeile wieder neu beschrieben wird. Und einen String zu kopieren ist ja auch kein Drama, wenn es mal sein muss.
Oliver S. schrieb: > Mit C ist es wie mit Kochgeräten: > Thermomix , Backöfenautomatikprogramme, und was es da sonst noch an > Küchen"helferlein" gibt, oder einfach ein scharfes Messer. > > Letzteres ist bei ungeübter Anwendung gefährlich, man muß tatsächlich > lernen, damit umzugehen. Wenn man es aber kann, ist es unschlagbar > schnell und flexibel. Ich denke da an selber kochen vs. Mikrowellen-Essen aufwärmen. Ersteres ist mehr Aufwand, und es gibt mehr Möglichkeiten, was falsch zu machen, aber wenn man's kann, schmeckt das Ergebnis um Welten besser als das Mikrowellen-Futter. ;-) Christopher C. schrieb: > Menschen sind oft faul oder nehmen sich nicht mehr die Zeit, sich > weiterzubilden. Ich bin viel zu vielen Menschen begegnet, die immer noch > ungarische Notation einsetzten, keine Ahnung von C99 haben und seit dem > Berufsleben technologisch stehen geblieben sind. Das liegt meines Erachtens maßgeblich daran, dass Microsoft bei C auch auf diesem Level stehen geblieben ist. > Oder schau mal ins Gnome/Gtk Lager, die machen 2016 GUI-Anwenungen immer > noch in C (würg). Das war schon nicht sinnvoll, als sie damit angefangen haben. Ich wollte mich mal in die Gtk-Programmierung einlesen, um mich nicht nur auf meinen Qt-Horziont zu beschränken. Ich hatte aber ziemlich schnell keine Lust mehr darauf. OOP kann man zwar auch zu Fuß in C machen, aber Spaß macht das absolut nicht. Jobst Q. schrieb: > Die Funktion selbst ist auch kein Aufwand: > > char * split(char *s,char c){ > while (*s && *s!=c )s++; > if (*s==c)*s++=0; > return s; > } Warum nimmst du nicht strtok()?
Rolf M. schrieb: > Jobst Q. schrieb: >> Die Funktion selbst ist auch kein Aufwand: >> >> char * split(char *s,char c){ >> while (*s && *s!=c )s++; >> if (*s==c)*s++=0; >> return s; >> } > > Warum nimmst du nicht strtok()? strtok ist wesentlich komplizierter in der Ausführung und der Verwendung. Es kann dafür mehrere Trennzeichen auf einmal behandeln, aber das habe ich noch nie gebraucht.
Dazu kommt bei strtok() als Rückgabe der NULL-Pointer, wenn keins der Trennzeichen gefunden wurde, was eine extra Fehlerbehandlung zwingend erforderlich macht. Mein split() gibt dann einfach das Stringende, also einen gültigen Leerstring zurück. Es ist ja nicht gleich ein Fehler, wenn eine Zeile keinen Kommentar enthält.
Rolf M. schrieb: > Warum nimmst du nicht strtok()? Das ist eine der C Funktionen mit eingebauter Falltür. So kleinräumig angewandt ist sie kein Problem. Aber wenn sowas in dieser Art draus wird:
1 | ...
|
2 | for (char *p = strtok(s1, ","); p; p = strtok(NULL, ",")) |
3 | f(...); |
4 | ...
|
5 | void f(...) |
6 | {
|
7 | for (char *q = strtok(s2, " "); q; q = strtok(NULL, " ")) |
8 | ...
|
9 | }
|
dann wird man merken, dass strtok ein statisches Gedächtnis hat und das innere strtok(s2,..) die statische Information des äusseren strtok(s1,..) verwirft.
:
Bearbeitet durch User
A. K. schrieb: > dann wird man merken, dass strtok ein statisches Gedächtnis hat und das > innere strtok(s2,..) die statische Information des äusseren > strtok(s1,..) verwirft. Dafür gibt's dann strtok_r, wo diese Information beim Aufrufer gespeichert wird. Natürlich macht das die Anwendung noch etwas umständlicher. Was mich eher an strtok() gestört hat (bzw. dazu geführt hat, dass ich es meistens nicht nutzen kann) ist, dass es das Auftreten zweier direkt aufeinanderfolgender Delimeter nicht richtig behandelt. Statt dann einen leeren String zurückzugeben, überspringt es das einfach. Also kommt bei "a;b;;c" nur "a", "b" und "c" und nicht, wie ich es eigentlich praktisch immer brauche "a", "b", "" und "c". Beim Parsen von NMEA oder von CSV-Daten ist das ziemlich blöd, denn da können leere Elemente durchaus vorkommen, müssen aber berücksichtigt werden, weil sonst der Rest der Zeile falsch einsortiert wird.
:
Bearbeitet durch User
Rolf M. schrieb: > Was mich eher an strtok() gestört hat (bzw. dazu geführt hat, dass ich > es meistens nicht nutzen kann) ist, dass es das Auftreten zweier direkt > aufeinanderfolgender Delimeter nicht richtig behandelt. "Richtig" ist das, was in der Doku steht. Insofern passt es. > Beim Parsen von NMEA oder von CSV-Daten ist das ziemlich blöd, denn da > können leere Elemente durchaus vorkommen, müssen aber berücksichtigt > werden, weil sonst der Rest der Zeile falsch einsortiert wird. Klar. Nur hatte man bei strtok wohl eher PATH im Auge gehabt. Oder Leerzeichen, die ja auch mal im Rudel auftreten können. NMEA oder CSV gab es damals noch nicht.
A. K. schrieb: > "Richtig" ist das, was in der Doku steht. Insofern passt es. Dann lass mich "richtig" durch "sinnvoll" ersetzen. >> Beim Parsen von NMEA oder von CSV-Daten ist das ziemlich blöd, denn da >> können leere Elemente durchaus vorkommen, müssen aber berücksichtigt >> werden, weil sonst der Rest der Zeile falsch einsortiert wird. > > Klar. Nur hatte man bei strtok wohl eher PATH im Auge gehabt. Oder > Leerzeichen, die ja auch mal im Rudel auftreten können. NMEA oder CSV > gab es damals noch nicht. Wobei es bei einem strtok(), das auch leere Elemente zurückgibt, ein leichtes wäre, diese selber zu ignorieren. Mit einem strtok, das das schon von sich aus tut, kann man leider gar nichts anfangen, wenn man diese leeren Elemente braucht. Somit wäre ersteres eigentlich flexibler gewesen. Übrigens gibt's NMEA schon seit 1983, also immerhin 6 Jahre länger als die ANSI-Version von C.
:
Bearbeitet durch User
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.