Warum immer nur C ?

[ogni42]

In java gibt es noch den zusätzlichen Ballast, dass alles in ein JRE gepackt wird, dass nochmal Speicher verbraucht.

new/delete sehe ich nicht als großes Problem, da man das ohne großen Aufwand über malloc/free nachbilden kann. Exceptions sind für mich auch ohne Belang. Ich benutze ja auch kein setjmp/longjmp (die Entsprechung in C)- OK na gut, ein-, zweimal in 17 Jahren C Programmierung habe ich es schon benutzt.

Und was Vererbung und Polymorphie angeht: Da sind die vtables der Preis den man zahlen muss (der nicht sehr hoch ist).

Was Code und Laufzeitexplosion angeht stimme ich Sprinter zu. Da sollte man schon wissen, was man tut. Das gilt für C zwar genau so, aber bei C++ (und ebenso bei Java) sind da einige Dinge mehr zu beachten.

Der größte Nachteil ist im Moment, dass der Debugger/Simulator im WinAVR nicht mit C++ Code zurecht kommt. De facto der einzige Grund, der mich vom Wechsel zu C++ abhält.

[SprinterSB]

Also Java ist definitiv viel schlimmer als C++, da es eben nur interpretiert wird. (ein C++ Programm wird vom Compiler in richtigen Maschinencode übersetzt)

Wenn du deinem Java-Compiler sagst, daß er ausführbaren Code machen soll, wird er das gerne für dich tun. Wo steht geschrieben, daß Java nur auf einer VM laufen darf?

Versuch mal ein gcj (GNU compiler for java, just a flavour of GCC) aus. Etwas schade ist, daß nur bis Java 1.3 unterstützt wird (zumindest was die libjava angeht). Andererseits... wenn man im Sinn hat swing zu benutzen, wird es bestimmt nicht auf einem AVR sein...

also warum sollt ein C++ kein Befehl gemantelt sein, der auch Bitweise zugreifen kann...

Wie gesagt, daß ist natürlich kein Thema. Ich hab das einst mal ausgetextet.

Macht einfach mal folgendes Jungs: Schreibt euch Klassen, die schön euren µC abstrahieren. Z.B. ein Port-Klasse, die es euch erlaubt, ein Port-Bit als In oder Out zu setzen, als HIGH oder als LOW oder zu togglen. Dann schaut euch den Code an und wir sprechen uns wieder. Entweder macht man die Methoden static inline und kann nicht ableiten, oder man kommt zu super breitem, nicht-atomarem Code. ...ok, wir können unser Port-Setzen ja atomisieren, aber dann haben solch simplen Aktionen schon empfindliche Auswirkungen auf die IRQ-Latenz.

BTW, indem man so unterwegs ist nun schön seine ATmega8-Klasse implementiert und verwendet, *verliert* man Portierbarkeit!

Im Endeffekt textet man dann die Features mit C-Code nach, proggt an der Objektorientierung vorbei, etc.

Bei welchem Beispiel bringt C++ Vorteile wie portierbareren, schnelleren, transparenteren oder schlankeren Code?

[damaltor]

Also meines wissens... in keinem =/

und java... nunja, man kann es kompilieren, muss man aber nicht =)

wenn man will, kann man auch das ganze ding in Brainf..k programmieren (eine Programmiersprache, die nur aus den zeichen

[]+-,.<>

besteht, siehe http://de.wikipedia.org/wiki/Brainfuck), die frage ist einfach ob das sinn macht. wer langeweile hat kann auch selbst eine programmiersprache entwerfen, einen entsprechenden compiler dazu schreiben und diese verwenden.

aber warum sollte man das tun? c reicht doch völlig aus... und wer gern bascom, java oder c++ benutzen will, der soll das doch tun =) wenn eine programmiersprache so viele nachteile hätte, dass diese gegenüber den vorteilen überwiegen (was jeder für sich selbst entscheiden muss) dann benutzt man sie halt nicht. aber das muss jeder für sich überlegen...


aber der erste, der es schafft nur mithilfe von brainf..k die frontled zum leuchten zu bringen, der bekommt nen kasten bier =)

[SprinterSB]

So schlecht finde ich das Brainfuck garnicht mal. Schön übersichtlich, im Gegensatz zu INTERCAL (--> http://de.wikipedia.org/wiki/INTERCAL) wo es so schöne Befehle wie ComeFrom gibt, das Inverses [sic!] zu goto!

Für Brainfuck wäre noch die Semantik von getchar und putchar zu klären. Gehen die auf's RAM? Ist wohl das sinnvollste, den RAM als Band herzunehemen.

[damaltor]

ich würde mal spontan sagen dass das vom compiler abhängt, oder nicht?
also im standart-compiler den man des öfteren findet geht es nach stdin und stdout, also keyboard un bildschirm.

ich habe es mal irgendwann geschafft, in INTERCAL ein Programm zu schreiben, das HELLO WORLD in zwei zeilen untereinander ausgibt. dann hab ich es gelassen =)

also ComeFrom ist wirklich einer der härtesten befehle überhaupt... o0 man muss sich einfach drauf verlassen, dass der prozessor bzw interpreter genau an dieser stelle, die mittem im programmcode liegen kann, die unterroutine ausführt... daran kann man sich ncih gewöhnen =)

[ogni42]

Falls jemand noch nach Sprachen sucht:

http://www.ntecs.de/old-hp/uu9r/lang/html/lang.de.html

[EDH]

programmiersprahcne gibt es schon sehr viele. aber ich schätze bei den meisten ist es genauso wie bei den ungefähr 15 000 kleinen linux distributionen.
sie werden einfach aus spaß an der sache entweickelt. was für einen praktischen nutzen (auser die gehirnzellen zu trainiern) hat eine programmiersprache die nur aus [ ] + - , . < > besteht?
das nimmt in der praxis warscheinlich niemand her

[damaltor]

da könntest du recht haben =)

wobei: diese programmiersprache ist SEHR nach an einer Turingmaschine empfunden, und das ist auch was schönes =) also könnte man evtl, anstelle eines kompilers, einen mega8 und ein lochkartenlesegerät mit einem lcd und keyboard koppeln und dann anstatt zu programmeiren, einfach lochen =)

dann sind wir wieder zurückversetzt... aber ob das sinn macht...

=)

es gibt auch eine programmiersprache, die als quellcode ein bitmap will (http://de.wikipedia.org/wiki/Piet). daran könnte man sich mal versuchen...