Verwirrung in Programiersprachen!Wer schaft mir Klartext?
-
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.
-
Erhard Henkes schrieb:
Beide Argumente (Kosten für Speicher, Low Level vs. High Level Programmierung) gab es bei der Entwicklung der PCs ebenfalls.
ja, aber nicht so extrem. PCs sowie sämtlicher end-user schrott, lassen sich gut vertickern, indem man viel bunte reklame macht, sinnlose features einbaut und den leuten erzählt, sie würden sowas unbedingt brauchen. man kann die kisten teuer machen, weil der kundenkreis nach emotionalen kriterien kauft. schickes gehäuse, verchromter kühlkörper, marken-grafikkarte, etc. zählen mehr als ein gutes preis- leistungsverhältnis. im gegensatz dazu, kalkulieren µC-einkäufer knallhart. angenommen man hat die wahl zwischen einem 32bit-boliden und einem 8bit popelteil. für den 32-bitter würde die softwareentwicklung (in java) 2 wochen dauern, für den 8-bitter 6 monate (in assembler). weiterhin angenommen (der faktor 'time-to-market' wird hier mal vernachlässigt), man braucht 100.000 stück und der 32-bitter kostet 5 euronen mehr als der 8-bitter. dann kannst dir, glaub ich, gut vorstellen, für welchen µC man sich entscheidet.
-
Talla schrieb:
Der Borland Code ist C++ (wahrscheinlich noch aus einer Vor Standard Zeit) mit irgend ner Bibliotheksfunktion die da mitkommt, aber halt C++. Der zweite Code mit dem Convert::String ist wirklich eine andere Sprache: C++/CLI. Sie ist zwar "abwärtskompatibel" zu C++, aber nur zur Interoperabilität, sie ist und bleibt eine .Net Sprache mit ihren Vor- und Nachteilen. Convert:ToString ist aber wiederum nichts C++/CLI spezifisches sondern eine Bibliotheksfunktion von .Net.
Danke! Genau das ist die Antwort die ich ersucht habe
Es geht doch!
-
sothis_ schrieb:
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
Was hat OOP mit Java zu tun?
Zu der NanoVM: Ist halt blos eine Abstraktionsebene, damit man nicht auf einen Compiler/Hardware beschraenkt ist. Wenn man also moeglichst viel Hardware abdecken will, dann ist die NanoVM sicher gut.
-
DEvent schrieb:
Zu der NanoVM: Ist halt blos eine Abstraktionsebene, damit man nicht auf einen Compiler/Hardware beschraenkt ist. Wenn man also moeglichst viel Hardware abdecken will, dann ist die NanoVM sicher gut.
das kann man auch mit C, ohne dass viel veränderungen am code notwendig wären, zumal µC-programme sowieso schon extrem in ihrer größe begrenzt sind (zumindest auf den 8-Bit varianten). übersichtlichkeit kann da auch nicht die motivation gewesen sein. nunja offensichtlich wirds ja auch seit 2006 nicht mehr weiterentwickelt