Verwirrung in Programiersprachen!Wer schaft mir Klartext?
-
sothis_ schrieb:
pauschalisierende aussagen
ich dachte du lernst vielleicht wenn ich etwas überzeichne.
float und double sind unterschiedliche datentypen. dass es atof heisst anstatt atod oder atofl ist einfach ein design fehler. es ist kein showstopper, aber ein fehler in der library. ähnlich die das inkonistente d und lf für double.hindert einen das daran gute programme zu schreiben? nein.
ist es ein designfehler? ja.warum ist das so schwer zu aktzeptieren. std::string ist auch ein designfehler. Fast überall sieht man sie - warum kann man sie dann nicht aktzeptieren?
-
Beantworte erst mal Shades Frage, bevor du mit weiteren Haarspaltereien kommst.
-
Shade Of Mine schrieb:
...
warum ist das so schwer zu aktzeptieren. std::string ist auch ein designfehler. Fast überall sieht man sie - warum kann man sie dann nicht aktzeptieren?
Was an std::string ist ein Designfehler? :o
-
Zeus schrieb:
Shade Of Mine schrieb:
...
warum ist das so schwer zu aktzeptieren. std::string ist auch ein designfehler. Fast überall sieht man sie - warum kann man sie dann nicht aktzeptieren?
Was an std::string ist ein Designfehler? :o
Alles.
Genauer: dass std::string mutable ist.
Noch genauer: alles.
-
Shade Of Mine schrieb:
Fast überall sieht man sie - warum kann man sie dann nicht aktzeptieren?
das verstehe ich jetzt nicht :S. ich akzeptiere sie doch, ich schreibe damit programme ohne mir gedanken darüber zu machen, ob es jetzt schlechtes design ist oder nicht. vieles rührt eben noch aus der vergangenheit, in der atof() eben noch kein double zurückgegeben hat. es stört mich persönlich nicht im geringsten ob es nun atof() oder atod() oder stringtofloatingpointnumberwith64bitprecision() heißt, da ich mich entweder damit arrangiert habe, der compiler mich warnt das etwas mit dem rückgabetyp nicht stimmt oder es eindeutig aus der referenzdokumentation hervorgeht.
-
sothis_ schrieb:
fricky schrieb:
nicht im pc-bereich, aber sonst schon. es gibt prozessoren für alle anwendungsfälle, die sich gut verkaufen. tendenz steigend, siehe z.b. hier: http://www.esacademy.com/automation/faq/primer/3.htm
und dafür braucht man auch programmierer, die noch mit bits und bytes 'per du' sind. tendenz ebenfalls steigend. die leute, die sich für systemprogrammierung interessieren, fangen heute bloss anders an, als damals. damals musste ja jeder, um seiner kiste speed zu entlocken, in assembler coden und wurde zwangsweise zum low-level freak.stimmt, der mikrocontrollermarkt bildet da derzeit wohl eine ausnahme. aber selbst da wird mir manchmal angst und bange, wenn überlegungen angestellt werden, wie man die denn am besten mit c++ programmieren könnte.
jo, ich hab schon projekte gesehen, wo man im C++ -abstraktionswahn µC-projekte angefangen hat, dann irgendwann gemerkt hat, dass es vorn und hinten hakelt, schliesslich immer mehr zu C zurückgekehrt ist und am schluss ein übler salat aus C und C++ herauskam. zum glück fallen nicht all zu viele embedded-leute auf stroustrups schöne worte rein (z.b. embeddedc++, ein c++ subset, der speziell für µC entwickelt wurde, fristet ein relativ unbeachtetes schattendasein).
sothis_ schrieb:
nicht dass es sonderlich schlimm wäre, aber auch hier könnte ein versteifen auf hardwarearchitekturen stattfinden, wenn man mehr und mehr abstraktion in der softwareschicht einführt.
das gibts da auch, aber geht nur über wenige generationen. etwa im kampf um kunden und marktanteile bohren die hersteller ihre chips immer weiter auf. aber sind die verkaufszahlen rückläufig, dann werden die dinger innerhalb kürzester zeit abgekündigt. da kennen sie nix. die meistens hersteller sind ohnehin mit einer vielzahl von architekturen parallel im markt vertreten. aber im unterschied zur PC-welt, gibts bei den µCs keinen mächtigen softwaregiganten wie m$, der den hardwareherstellern das messer an die kehle hält, sondern es ist umgekehrt. die toolhersteller kommen kaum damit hinterher, compiler etc. für neue prozessoren zu entwickeln. softwareanbieter etwa, die z.b. libraries verkaufen, müssen nicht, wie PC-softwareanbieter, nur für linux und windows, sondern für eine matrix aus prozessortyp*entwicklungsumgebung ihr zeug anbieten
-
sothis_ schrieb:
das verstehe ich jetzt nicht :S. ich akzeptiere sie doch, ich schreibe damit programme ohne mir gedanken darüber zu machen, ob es jetzt schlechtes design ist oder nicht.
nein, du aktzepierst es nicht du ignorierst es.
deshalb gefallen dir bessere lösungen nicht - weil du die fehler der vorhandenen nicht siehst.
-
fricky schrieb:
jo, ich hab schon projekte gesehen, wo man im C++ -abstraktionswahn µC-projekte angefangen hat, dann irgendwann gemerkt hat, dass es vorn und hinten hakelt, schliesslich immer mehr zu C zurückgekehrt ist und am schluss ein übler salat aus C und C++ herauskam. zum glück fallen nicht all zu viele embedded-leute auf stroustrups schöne worte rein (z.b. embeddedc++, ein c++ subset, der speziell für µC entwickelt wurde, fristet ein relativ unbeachtetes schattendasein).
ich meine es sollte durchaus alternativen zu C und assembler im embedded bereich geben, das kann nicht schaden. aber objektorientierung hat im lowlevel sektor, gar nichts, aber auch rein gar nichts verloren, zumindest nicht auf heutigen prozessorarchitekturen
fricky schrieb:
aber im unterschied zur PC-welt, gibts bei den µCs keinen mächtigen softwaregiganten wie m$, der den hardwareherstellern das messer an die kehle hält, sondern es ist umgekehrt. die toolhersteller kommen kaum damit hinterher, compiler etc. für neue prozessoren zu entwickeln. softwareanbieter etwa, die z.b. libraries verkaufen, müssen nicht, wie PC-softwareanbieter, nur für linux und windows, sondern für eine matrix aus prozessortyp*entwicklungsumgebung ihr zeug anbieten
stimmt, und ich hoffe das bleibt auch so, da viele sich dann eher genötigt fühlen auf frei verfügbare varianten zurückzugreifen, insbesondere was die compiler angeht
-
Shade Of Mine schrieb:
nein, du aktzepierst es nicht du ignorierst es.
nein, ich arrangiere mich damit.
Shade Of Mine schrieb:
deshalb gefallen dir bessere lösungen nicht - weil du die fehler der vorhandenen nicht siehst.
das ist eine unterstellung. korrigiere mich, wenn ich falsch liege, aber ich habe an keiner stelle dieser diskussion angemerkt, dass mir andere lösungen nicht gefallen, insbesondere weil ich fehler nicht erkenne. wenn du persönlich werden willst, da du jetzt ja schon unterstellungen vom stapel lässt, dann können wir das auch gerne per email klären.
-
sothis_ schrieb:
vielleicht sehe ich es auch zu steif aus der meiner sicht. wenn man lange mit standard-c bibliotheken programmiert, ist ein atoi() eben genau so selbstverständlich, wie ein if-else-konstrukt oder switch-block. man sieht sofort was es macht, und, wenn man sich die mühe macht auch den quellcode der crt/libc zu analysieren, wie es dies macht. von daher ist es für mich eben genau so verständlich, wie für dich ein lexical_cast.
danke
alleine das konzept eines atoi ist für konvertierungen ungeeignet. klar funktioniert es, aber es hat eine menge probleme...
-
sothis_ schrieb:
...aber objektorientierung hat im lowlevel sektor, gar nichts, aber auch rein gar nichts verloren, zumindest nicht auf heutigen prozessorarchitekturen
das würde ich nicht sagen. oop und lowlevel sind durchaus kein widerspruch. nur darfs nicht so wie C++ sein, mit seinen versteckten fussangeln, performance-bremsen und speicherfress-mechanismen. z.b. sind hardware-beschreibungssprachen wie vhdl schon so ziemlich objektorientiert, können kapselung in entities, funktionsüberladung usw.
fricky schrieb:
...da viele sich dann eher genötigt fühlen auf frei verfügbare varianten zurückzugreifen, insbesondere was die compiler angeht
leider sind die embedded-gcc's nicht annähernd so gut, wie die für die grossen systeme.
-
fricky schrieb:
leider sind die embedded-gcc's nicht annähernd so gut, wie die für die grossen systeme.
Du hast sie ja alle schon getestet, gelle?
-
Shade Of Mine schrieb:
sothis_ schrieb:
vielleicht sehe ich es auch zu steif aus der meiner sicht. wenn man lange mit standard-c bibliotheken programmiert, ist ein atoi() eben genau so selbstverständlich, wie ein if-else-konstrukt oder switch-block. man sieht sofort was es macht, und, wenn man sich die mühe macht auch den quellcode der crt/libc zu analysieren, wie es dies macht. von daher ist es für mich eben genau so verständlich, wie für dich ein lexical_cast.
danke
alleine das konzept eines atoi ist für konvertierungen ungeeignet. klar funktioniert es, aber es hat eine menge probleme...
ich fragte an welcher stelle dieser diskussion ich angemerkt habe, dass mir andere lösungen nicht gefallen, insbesondere weil ich fehler nicht erkenne. deine antwort ist wie:
Q: Wie wird das Wetter heute?
A: bunt, aber vielleicht auch rot, wenn wir glück haben
-
fricky schrieb:
leider sind die embedded-gcc's nicht annähernd so gut, wie die für die grossen systeme.
kann ich ehrlich gesagt nicht beurteilen, da ich immer gcc verwendet habe
-
Tim schrieb:
fricky schrieb:
leider sind die embedded-gcc's nicht annähernd so gut, wie die für die grossen systeme.
Du hast sie ja alle schon getestet, gelle?
den für arm, v850 und s12 habe ich getestet. alle wurden von kommerziellen compilern arm/iar, v850/greenhills s12/codewarrior in bezug auf schnellen und schlanken code, gandenlos abgehängt. und zwar *alle*. das lässt mich darauf schliessen, dass auch andere gccs, bis vielleicht auf die für x86, nicht so toll optimieren können.
-
jo, ich hab schon projekte gesehen, wo man im C++ -abstraktionswahn µC-projekte angefangen hat
In der µC-Programmierung wird man vermutlich den gleichen Weg gehen wie bei den PCs, nämlich von ASM über C zu OOP-Sprachen wie C++ oder Java. Warum auch nicht? Zumindest bei größeren Programmen. Momentan ist das aber vorwiegend gekapseltes C, new und delete fehlen noch, und so weiter.
Die derzeitgen Speichergrößen (SRAM von wenigen KByte) sind für OOP noch nicht ausgelegt. Das ist aber nur eine Frage der Zeit. In wenigen Jahren wird man nicht mehr verstehen, warum man bei µC mit ASM gearbeitet hat.
-
Erhard Henkes schrieb:
jo, ich hab schon projekte gesehen, wo man im C++ -abstraktionswahn µC-projekte angefangen hat
In der µC-Programmierung wird man vermutlich den gleichen Weg gehen wie bei den PCs, nämlich von ASM über C zu OOP-Sprachen wie C++ oder Java.
http://www.harbaum.org/till/nanovm/index.shtml
Erhard Henkes schrieb:
Die derzeitgen Speichergrößen (SRAM von wenigen KByte) sind für OOP noch nicht ausgelegt. Das ist aber nur eine Frage der Zeit. In wenigen Jahren wird man nicht mehr verstehen, warum man bei µC mit ASM gearbeitet hat.
µCs werden meistens in grossen stückzahlen verkauft und solange die kleinen chips billiger sind als grosse, und wenn es nur wenige cent sind, werden sie nicht aussterben.
-
sothis_ schrieb:
ich meine es sollte durchaus alternativen zu C und assembler im embedded bereich geben, das kann nicht schaden. aber objektorientierung hat im lowlevel sektor, gar nichts, aber auch rein gar nichts verloren, zumindest nicht auf heutigen prozessorarchitekturen
Wieso nicht? Wenn man OO-Problemloesungen braucht, wieso also keine OOP einsetzen? Anstatt vielen if-then-else oder switch, baut man einfach generische Objekte. OOP ist doch blos Datenkapselung, Vererbung und dynamische Objekte.
Man muss ja nicht C++ oder Python dafuer nehmen
-
DEvent schrieb:
sothis_ schrieb:
ich meine es sollte durchaus alternativen zu C und assembler im embedded bereich geben, das kann nicht schaden. aber objektorientierung hat im lowlevel sektor, gar nichts, aber auch rein gar nichts verloren, zumindest nicht auf heutigen prozessorarchitekturen
Wieso nicht? Wenn man OO-Problemloesungen braucht, wieso also keine OOP einsetzen? Anstatt vielen if-then-else oder switch, baut man einfach generische Objekte. OOP ist doch blos Datenkapselung, Vererbung und dynamische Objekte.
Man muss ja nicht C++ oder Python dafuer nehmen
warum? nagut, wenn ich einige hundert kilobyte SRAM habe mag das dann eine überlegung wert sein. aber wenn ich das lese was fricky da verlinkt hat schauderts mich. JavaVM auf AVR 8bit risc controllern. WARUM, WARUM nur machen die das? ich habe nur 2K SRAM und 32K flash für's programm nachdem ich diesen mist drauf habe habe ich nur noch 1K SRAM und 24K flash für's program. wofür? um das ding mit java zu programmieren? um ein paar pins abhängig vom programmablauf auf low oder high zu setzen, ein paar messungen mit dem adc durchführen und die timer konfigurieren, damit ich die PWM einsetzen kann, Ist dafür Java notwendig? um gottes willen nein. das macht nur jemand, der entweder absoluter oop fanboi ist, nicht c programmieren kann oder einfach nur beweisen will, dass es mit java geht und mit c++ nicht
-
µCs werden meistens in grossen stückzahlen verkauft und solange die kleinen chips billiger sind als grosse, und wenn es nur wenige cent sind, werden sie nicht aussterben.
Ist dafür Java notwendig? um gottes willen nein. das macht nur jemand, der entweder absoluter oop fanboi ist, nicht c programmieren kann oder einfach nur beweisen will, dass es mit java geht und mit c++ nicht
Beide Argumente (Kosten für Speicher, Low Level vs. High Level Programmierung) gab es bei der Entwicklung der PCs ebenfalls. Warum wird sich dennoch MS Vista als Betriebssystem und C#/.NET als Programmiersprache für die Windows-Programmierung durchsetzen? Fallende Preise für Prozessoren/Speicher und Bequemlichkeit/leichte Wartung. Bei den µC wird es sich in gewissen Bereichen ähnlich entwickeln. Für Elektronikmassenanwendungen ist ein kleiner Chip programmiert in ASM dann die bezüglich der Massenfertigung kostenoptimierte Variante.
Java gibt es sowohl für den Asuro (da macht es wirklich wenig Sinn), als auch für den Nibo (hier ist man in einem Grenzbereich). Im Robotikbereich werden sich "OS" und "Engines" durchsetzen, weil es keinen Sinn macht, immer die Basics neu zu programmieren.
