Hallo,
mich würde mal interessieren wie ihr zu dem Thema objektorientierte
Programmierung in C steht.
Also ich versuche bei meinen C-Programmen immer Datenstrukturen und die
dazugehoerenden Member Funktionen in einer Struktur zusammenzufassen.
Dies fuehrt dann natuerlich zu erheblich mehr Tipparbeit. Man muss beim
hinzufuegen von neuen Funktionen immer an 4 stellen Änderungen
durchführen:
1. Funktionspointer im C Strukt hinzufügen
2. Prototyp im C File hinzufügen
3. Deklaration der Funktion
4. Initialisierung des Funktionspointers im "Konstruktor"
Ist es dieser Mehraufwand überhaupt Wert?
Wenn ja, geht ihr auch weiter und versucht Vererbung und Co.
nachzubilden?
Du musst hierbei zwischen der C++ und der Smalltalk Art der OOP
unterscheiden. Wenn Du in Richtung C++ gehen willst, gibt es Objective
C. Wenn Du in Richtung Smalltalk/Erlang gehen willst, nimmst Du einfach
ein Betriebssystem das Warteschlangen unterstützt und schickst darüber
Deine Botschaften. Objekte sind dann Prozesse. (Vererbung braucht man da
nicht)
Plong A. schrieb:> Ist es dieser Mehraufwand überhaupt Wert?
Nein! Wenn du wirklich Objekte brauchst, sollte man auch eine Sprache
verwenden, die dies unterstützt. "Früher", als C++ noch nicht so populär
war, hat man teilweise versucht, Objektorientierung in C nachzubauen
(IMHO XView war so ein Teil). War aber alles nicht schön. Wenn du das
unbedingt machen willst, dann packe wenigstens keine Methodenpointer
in die Strucs, sondern verwende allgemeine Methoden (add, del, draw,
usw), die halt dann aufgrund des Strucs/Objekts sich unterschiedlich
verhalten. Sonst blähen sich die Strucs unnötig auf. Der Methodenaufruf
sieht dann zwar wieder prozedural aus, aber IMHO sind Objekte, die 8
Byte Daten mitschleppen und dann (bei 64 Bit systemem) evtl. 64 Byte
Methodenpointer (wären nur 8 Methoden) krank.
User schrieb:> Wieso programmierst du nicht einfach C++?
Wenn ein Projekt schon in C existiert ist ein Wechsel auf C++ ja nicht
so einfach möglich ;)
Ex-C'ler schrieb:> Der Methodenaufruf> sieht dann zwar wieder prozedural aus, aber IMHO sind Objekte, die 8> Byte Daten mitschleppen und dann (bei 64 Bit systemem) evtl. 64 Byte> Methodenpointer (wären nur 8 Methoden) krank.
Stimmt. Darüber habe ich mir noch keine Gedanken gemacht.
Plong A. schrieb:> User schrieb:>> Wieso programmierst du nicht einfach C++?>> Wenn ein Projekt schon in C existiert ist ein Wechsel auf C++ ja nicht> so einfach möglich ;)
Sagt wer?
Die Mehrzahl der existierenden C-Projekte lassen sich mit geringen
Anpassungen auch durch einen C++ Compiler jagen. Genau das war ja auch
der 'Scharm' der C++ Lösung, dass dies möglich ist. Das hat sich zwar
historisch so ergeben, weil der allererste C++ Compiler nichts anderes
als ein Zwischencompiler war, der C++ nach C übersetzte und dann den
bereits vorhandenen C Compiler weiterbenutzte, hat aber der Akzeptanz
von C++ enorm weitergeholfen.
Da ich diesen Prozess schon mal gemacht habe (mit einem Programm namens
"Rayshade") kann ich durchaus sagen: So wild sind die Anpassungen gar
nicht, wenn dein C Programm nicht gerade die eher esoterischen
Feinheiten (vor allen Dingen die der neueren C-Versionen) der Sprache
ausnutzt. Hat man den C-Code erst mal so umgewandelt, dass er durch den
C++ Compiler geht, dann beginnt der eigentliche 'Fun-Part'. Nämlich das
rauswerfen all der händisch eingebrachten OOP-Hilfskonstrukte, die der
C++ Compiler von sich aus erledigt. Der Prozess beginnt damit, dass man
erst mal alle malloc()/free() durch new/delete ersetzt.
Ex-C'ler schrieb:> "Früher", als C++ noch nicht so populär war, hat man teilweise versucht,> Objektorientierung in C nachzubauen (IMHO XView war so ein Teil). War> aber alles nicht schön.
Sowas gibt's auch heute noch, z.B. bei gtk+. Das ist objektorientiert
und komplett in C implementiert. Aber da ist es (meiner Meinung nach)
alles andere als schön.
Ex-C'ler schrieb:> Der Methodenaufruf sieht dann zwar wieder prozedural aus, aber IMHO sind> Objekte, die 8 Byte Daten mitschleppen und dann (bei 64 Bit systemem)> evtl. 64 Byte Methodenpointer (wären nur 8 Methoden) krank.
pointer->funktion() schreiben zu können ist nichts weiter als der
berüchtigte syntaktische Zucker. Das ist es nicht, was objektorientierte
Programmierung ausmacht.
Plong A. schrieb:> User schrieb:>> Wieso programmierst du nicht einfach C++?>> Wenn ein Projekt schon in C existiert ist ein Wechsel auf C++ ja nicht> so einfach möglich ;)
Wenn du eh alles auf objektorientierte Programmierung umstellst, kannst
du auch gleich nach C++ wechseln.
> Ist es dieser Mehraufwand überhaupt Wert?
Nein.
Sehr selten wird ein Programm klarer und effizienter,
wenn man Vererbung und Funktionspointer verwendet.
Nur in den paar Fällen lohnt sich so eine Struktur,
in den meisten anderen Fällen wird es nur unnötig
komplexer und langsamer (und eben wartungsintensiver
und durch die mehreren Änderungsstellen fehleranfälliger).
> gibt es Objective C.
Oje.
Rolf Magnus schrieb:> pointer->funktion() schreiben zu können ist nichts weiter als der> berüchtigte syntaktische Zucker. Das ist es nicht, was objektorientierte> Programmierung ausmacht.
Hier geht es nicht nur um syntaktischen Zucker. Wenn man
Funktionspointer in einer Struktur hat, dann kann man die Funktionen in
seinem Modul als static deklarieren. D.h. dass diese dann nicht global
aufrufbar sind, sondern nur noch über das Strukturobjekt erreichbar
sind!
Das hat was mit Namensräumen zu tun. Mir ging es nicht um die
Schreibweise.
Plong A. schrieb:> Rolf Magnus schrieb:>> pointer->funktion() schreiben zu können ist nichts weiter als der>> berüchtigte syntaktische Zucker. Das ist es nicht, was objektorientierte>> Programmierung ausmacht.>> Hier geht es nicht nur um syntaktischen Zucker. Wenn man> Funktionspointer in einer Struktur hat, dann kann man die Funktionen in> seinem Modul als static deklarieren. D.h. dass diese dann nicht global> aufrufbar sind, sondern nur noch über das Strukturobjekt erreichbar> sind!
Schon klar.
Nichts desto trotz hast du damit eine komplette Tabelle mit
Funktionspointern in jedem Objekt. D.h. du verbrauchst Speicher, ohne
etwas Gravierendes dafür zu bekommen.
> Das hat was mit Namensräumen zu tun. Mir ging es nicht um die> Schreibweise.
Und genau da kommt dann eben C++ wieder ins Spiel, welches dieses
"Problem" für dich auf die einfachste Weise löst. D.h. selbst dann, wenn
du sonst nichts von C++ nutzt, hast du bereits einen Vorteil, wenn du
deinen Code auf einen C++ Compiler portierst und anfängst die Dinge
auszumisten, die du jetzt mühsam händisch erledigen musst.
Plong A. schrieb:> Also ich versuche bei meinen C-Programmen immer Datenstrukturen und die> dazugehoerenden Member Funktionen in einer Struktur zusammenzufassen.
Das Zusammenfassen zusammengehöriger Dinge ist in Ordnung, aber muss die
Zusammenfassung unbedingt in einer Struktur stattfinden?
Eine gängige Vorgehensweise ist die Zusammenfassung von Daten in einer
Struktur und die Zusammenfassung der auf diesen Daten operierenden
Funktionen (im OO-Jargon Methoden) zusammen mit der Datenstruktur in
einem Modul, d.h. einer Übersetzungseinheit.
Beispiel:
- Methodenaufrufe erfolgen grundsätzlich mit einem Zeiger auf das zu
bearbeitende Objekt als erstes Argument.
- Konflikte bei Methodennamen werden in C dadurch vermieden, dass man
jedem dieser Namen den (ggf. abgekürzten) Klassennamen voranstellt.
- Die C++-Konstruktoren bekommen in C einheitliche Namen, bspw.
<Klassenname>_init.
- Entsprechend können in C auch Destruktoren definiert werden, die aber
natürlich im Gegensatz zu C++ explizit aufgerufen werden müssen.
- Private Methoden in C++ werden in C als static deklariert und
tauchen im Header-File überhaupt nicht auf, so dass sie außerhalb des
Moduls nicht sichtbar sind. Bei diesen Methoden kann deswegen auch der
Klassenpräfix antfallen.
- Für private Datenelemente gibt es in C leider keine Entsprechung.
Damit hat man das Kapselungskonzept von C++ bei nur wenig mehr
Schreibarbeit fast vollständig in C nachgebildet.
> Wenn ja, geht ihr auch weiter und versucht Vererbung und Co.> nachzubilden?
Vererbung kann man in C ansatzweise dadurch nachbilden, dass in der
Struktur der abgeleiteten Klasse das erste Element die Struktur der
Basisklasse hat. Man kann dann Objekte der abgeleiteten Klasse an
Methoden/Funktionen übergeben, die ein Argument der Basisklasse
erwarten, allerdings im Gegensatz zu C++ nur als Referenz (d.h. Zeiger)
und nicht als Wert. Außerdem muss man, um Compiler-Warnungen zu
vermeiden, den übergebenen Zeiger in einen Basisklassenzeiger casten.
Dadurch wird leider die Typüberprüfung von C ausgehebelt, weswegen IMHO
die Vorteile, die das Vererbungskonzept bietet, durch den Nachteil der
eingeschränkten Typsicherheit wieder zunichte gemacht wird.
Alternativ könnte man mit
1
obj.basisobj
auch nur das enthaltene Basisobjekt als Argument übergeben, aber dann
bleibt zumindest syntaktisch von der Subtype-Polymorphie nicht mehr viel
übrig.
Mit den Funktionszeigern in den Datenstrukturen hast du versucht, das
C++-Konzept der virtuellen Methoden umzusetzen. Neben dem zusätzlich
Schreibaufwand steigt dabei auch der Speicherbedarf und und die
Rechenzeit für die Methodenaufrufe. Zumindest der Speicheraufwand könnte
dadurch reduziert werden, dass die Funktionszeiger wie in C++ in Virtual
Method Tables (VTables) organisiert werden.
Ob man Vererbung oder gar virtuelle Methoden wirklich braucht, hängt
stark von der Anwendung ab. Ich würde in C möglichst beides vermeiden
und bei etwaigem Bedarf gleich auf C++ umsteigen.
In GTK+ und m.W. auch im WinAPI wird trotzdem von diesen Möglichkeiten
Gebrauch gemacht. Auch der Linux-Kernel verwendet dieses Konzept für
eine einheitliche Treiberstruktur. Alle drei Beispiele stammen aber aus
einer Zeit, wo die Sprache C++ noch nicht sehr reif war und die Compiler
kaum einem einheitlich Standard folgten. Zumindest bei GTK+ bin ich mir
ziemlich sicher, dass es, wenn es erst heute entwickelt würde, direkt in
C++ implementiert würde. Das API würde dann so aussehen wie in GTKmm,
dem C++-Wrapper zu GTK+. Dieser Wrapper ist sehr sauber gemacht, und
gibt dem Nutzer die in GTK+ auf Grund der Psedovererbung verloren
gegangene Typsicherheit wieder zurück.
Man muss auch nicht unbedingt jede zu entwicklende Software in ein
OO-Korsett zwängen. Bei manchen Anwendungen (z.B. GUI-Frameworks oder
grafische Anwendungen) ist OOP durchaus sinnvoll, bei anderen
(algorithmenlastigen oder primär numerischen Anwendungen) kann OOP auch
hinderlich sein. Man muss sich immer fragen, welchen der potentiellen
Vorteile von OOP sich in einem konkreten Softwareprojekt tatsächlich
auch in einem messbaren Nutzen niederschlägt.
Plong A. schrieb:> Wenn man Funktionspointer in einer Struktur hat, dann kann man die> Funktionen in seinem Modul als static deklarieren. D.h. dass diese> dann nicht global aufrufbar sind, sondern nur noch über das> Strukturobjekt erreichbar sind!> Das hat was mit Namensräumen zu tun.
Wenn es dir primär um die Namensräume geht, reicht i.Allg. – wie oben
vorgeschlagen – auch ein entsprechender Präfix vor den Namen. Da würde
ich mir den zusätzlichen Aufwand mit den Funktionszeigern sparen.
Yalu X. schrieb:> Vererbung kann man in C ansatzweise dadurch nachbilden, dass in der> Struktur der abgeleiteten Klasse das erste Element die Struktur der> Basisklasse hat. Man kann dann Objekte der abgeleiteten Klasse an> Methoden/Funktionen übergeben, die ein Argument der Basisklasse> erwarten, allerdings im Gegensatz zu C++ nur als Referenz (d.h. Zeiger)> und nicht als Wert. Außerdem muss man, um Compiler-Warnungen zu> vermeiden, den übergebenen Zeiger in einen Basisklassenzeiger casten.>> Dadurch wird leider die Typüberprüfung von C ausgehebelt
das müsste sich vermeiden lassen
struct Primitiv
{
....
};
struct Rectangle
{
struct Primitiv base_;
double width, height;
};
void PR_tuwas( struct Primtiv* item )
{
...
}
machst du jetzt ein
struct Rectangle xy;
PR_tuwas( &xy );
dann mault der Compiler zu recht. Du musst einen
PR_tuwas( &(xy.base_) );
machen und alles ist wieder in Butter.
Schön ist es nicht. Aber es würde gehen.
Karl Heinz Buchegger schrieb:> das müsste sich vermeiden lassen>> ...>> Du musst einen>> PR_tuwas( &(xy.base_) );>> machen und alles ist wieder in Butter.
Ja, dadurch werden die Typprobleme behoben, was ich in meinem letzten
Beitrag auch schon angedeutet habe:
Yalu X. schrieb:> Alternativ könnte man mit>> obj.basisobj>> auch nur das enthaltene Basisobjekt als Argument übergeben, aber dann> bleibt zumindest syntaktisch von der Subtype-Polymorphie nicht mehr viel> übrig.
Noch ein weiterer Aspekt dieser Geschichte:
Von einer Basisklasse eine neue Klasse durch Einfügen der Basisstruktur
als Element der abgeleiteten Struktur hat generell den Nachteil, dass
bei jedem Zugriff auf Elemente der Basisklasse in der abgeleiteten
Klasse der Elementname des Basisobjekts angegeben werden muss, also
bspw.
1
x=obj.baseobj.baseelement;
In C++, wo echte Vererbung möglich ist, schreibt man stattdessen einfach
1
x=obj.baseelement;
Diese Schreibweise ist auch in C möglich, wenn man die Basisklasse nicht
als Struktur, sondern elementweise in die abgeleitete Struktur einfügt.
Um sich Schreibarbeit zu sparen und Fehler bei der Replikation der
Elementdeklarationen zu vermeiden, kann man diese auch in einem Makro
zusammenfassen, das sowohl in der Basis- also auch in allen davon
abgeleiteten Klassen verwendet wird.
Auch dieses Vorgehen läuft einem öfter über den Weg. Den einfacheren
Elementzugriff erkauft man sich allerdings mit dem Nachteil, dass man
den genannten Typproblemen nun tatsächlich nicht mehr aus dem Weg gehen
kann, da nun die Basis- und die abgeleitete Struktur aus Compiler-Sicht
gar nichts mehr miteinander zu tun haben.
Die sauberste Lösung dieses Problems besteht einfach darin, Vererbung
nur in denjenigen Sprachen zu verwenden, die sie von sich aus anbieten.
Und C gehört nun mal nicht dazu.
Das ist alles sehr interessant für mich, obwohl ich noch nicht viel
verstehe.
Wenn ich das so sehe, dann frag ich mich wieder wieso ich nicht doch
gleich C++ lernen soll?
Man riet mir in diesem Forum erst C zu lernen.
Irgendwie sieht C++ für mich viel klarer aus und die Sprache "spricht"
mit mir. Das Buch ist zwar irre dick und kaum zu händeln, trotzdem habe
ich mich auf den ersten Seiten beim lesen richtig wohl gefühlt, weil
alles nicht nur verständlich war, alles schien so klar. Es kam immer das
Gefühl auf, ja, so hätte ich das auch gemacht.
Lernen fällt mir eigentlich immer sehr schwer, doch mit diesem C++ Buch
blieb keine Frage offen.
Also nochmal die Frage: Soll ich dann nicht gleich lieber doch alles in
C++ machen?
Ich will doch nur ein paar Sachen mit uC machen und nächsten Monat bin
ich schon 50. Mit 55 wollte ich das eigentlich alles so können, dass ich
alle Standardaufgaben lösen kann. Dazu muss ich auch noch eine Menge
über Elektronik lernen.
Karl-Heinz, auf deine Meinung zähle ich besonders.
Vielen Dank!
Sorry, dass ich die Richtung etwas für einen Moment ableite.
Liebe Grüße
Frank
F. Fo schrieb:> Das ist alles sehr interessant für mich, obwohl ich noch nicht viel> verstehe.>> Wenn ich das so sehe, dann frag ich mich wieder wieso ich nicht doch> gleich C++ lernen soll?> Man riet mir in diesem Forum erst C zu lernen.
Weil der OOP Lern-Ansatz, wenn man ihn konsequent geht, anders
funktioniert. In einer OOP Welt hast du erst mal viele Dinge in Form von
Klassen fix fertig vorhanden, die du dir in C erst mal mühsam und
korrekt machen musst. Denk an String-Verarbeitung, denk an alles was mit
Datencontainern zu tun hat.
Beginnst du gleich (richtig) mit C++ zu arbeiten, dann verwendest du die
natürlich auch (wäre ja blöd, Dinge nicht zu verwenden, die man bereits
fix&fertig vorrätig hat). Der Nachteil ist dann aber auch, dass du die
darunterliegenden Mechanismen nicht kennst. String-Verarbeitung ist zb
so ein Thema. In C ist das ein 'pain in the ass', in C++ ist das ein
'piece of cake' weil sich die std::string Klasse um die ganzen kleinen
Details und Fallen kümmert. Trotzdem ist es manchmal notwendig, dass man
auf die C Ebene runter geht, vor allen Dingen dann, wenn man mit
externen Bibliotheken oder Datenkanälen kommunizieren muss. Und dann
steht man eben an, wenn man von diesen Dingen keine Ahnung hat.
Und jetzt überleg mal, woraus deine µC-Programme in der großen Mehrheit
bestehen? Richtig: Die kleineren Programme sind alle mehr oder weniger
I/O lastig. D.h. der Löwenanteil beschäftigt sich mit Ein/Ausgabe. Das
Geplänkel dazwischen, das sind ein paar Umrechnungen. Vielleicht auch
mal ein Timer, der eine Variable hochzählt oder so. Aber aus recht viel
mehr bestehen diese Programme nicht. OOP bringt dir da nicht viel. OOP
beginnt seine Vorteile auszuspielen, wenn das Gesamtsystem größer und
komplexer wird.
> alles nicht nur verständlich war, alles schien so klar. Es kam immer das> Gefühl auf, ja, so hätte ich das auch gemacht.
Ja, das ist oft so. OOP leht sich oft stark an der realen Welt an. Es
ist ein anderer Ansatz an ein Programmierproblem heranzugehen, ein
Programm zu strukturieren, als der traditionellen funktionale Ansatz.
Wenn auch die Übergänge fliessend sind und diejenigen, die intuitiv gute
funktionale Ansätze haben auch meistens sich in der OOP Welt auf Anhieb
gut zurecht finden.
Aber, ganz wichtig: belass es nicht beim Lesen. Installier dir einen
Compiler und mach Übungen. Kein Meister fällt vom Himmel und Üben ist
das Um und Auf in der Programmierung.
> Also nochmal die Frage: Soll ich dann nicht gleich lieber doch alles in> C++ machen?
Der springende Punkt ist:
Du musst es gar nicht sofort neu machen!
Dein C Code wird mit lediglich kleinen Änderungen durch den C++ Compiler
gehen. D.h. in ein paar Stunden hast du deinen Code soweit, dass dir die
C++ Welt ebenfalls offen steht. Und du kannst sukzessive deine
bisherigen C-Konstrukte gegen die Dinge austauschen, so wie sie in C++
vorgesehen sind und so wie dir der Compiler die Unterstützung für die
OOP Dinge gibt.
Ich hab grundsätzlich kein Problem damit, wenn du OOP mit C machen
willst. Aber es ist in dem Sinne etwas sinnlos, weil du im Grunde nichts
anderes machst, als das nachzubilden, was auch der C++ Compiler macht.
Wo liegt da der Sinn, sich unnötig Mehrarbeit aufzuzwirbeln, deren
Korrektheit auf deiner Selbstdisziplin beruht? Beschäftige dich mit den
Programmier-Problemen, die du lösen willst, und überlass die
Umsetzungsfeinheiten dem Compiler. Es ist schon ok, wenn man sich mal im
Detail ansieht, wie zb virtuelle Funktionen funktionieren und vom
Compiler implementiert werden. Aber in einem realen Projekt überlass ich
das lieber dem Compiler, das in der großen Masse dann auch konsequent
durchzuziehen.
Karl Heinz Buchegger schrieb:>> Weil der OOP Lern-Ansatz, wenn man ihn konsequent geht, anders> funktioniert. In einer OOP Welt hast du erst mal viele Dinge in Form von> Klassen fix fertig vorhanden, die du dir in C erst mal mühsam und> korrekt machen musst. Denk an String-Verarbeitung, denk an alles was mit> Datencontainern zu tun hat.>> Und jetzt überleg mal, woraus deine µC-Programme in der großen Mehrheit> bestehen? Richtig: Die kleineren Programme sind alle mehr oder weniger> I/O lastig. D.h. der Löwenanteil beschäftigt sich mit Ein/Ausgabe. Das> Geplänkel dazwischen, das sind ein paar Umrechnungen. Vielleicht auch> mal ein Timer, der eine Variable hochzählt oder so. Aber aus recht viel> mehr bestehen diese Programme nicht. OOP bringt dir da nicht viel. OOP> beginnt seine Vorteile auszuspielen, wenn das Gesamtsystem größer und> komplexer wird.>
Vielen leben Dank! Leuchtet mir ein, vor allem, weil ich ja auch 'die
Mechanissmen dahinter' verstehen will.
> Wenn ich das so sehe, dann frag ich mich wieder wieso ich nicht doch> gleich C++ lernen soll?> Man riet mir in diesem Forum erst C zu lernen.
weil C die Nachteile der OOP nicht hat, weil das gerade in Bezug auf das
Laufzeitverhalten relevant ist.
Außerdem frag ich wieso Du nicht gleich zu Java übergehst ... C++ ist
nach dem Erscheinen von Java praktisch überflüssig geworden, oder wenn
schon unbedingt der C-Zweig, dann nimm doch C# ... das soll ja noch 100
mal besser als C++ sein ?!
> Und jetzt überleg mal, woraus deine µC-Programme in der großen Mehrheit> bestehen? Richtig: Die kleineren Programme sind alle mehr oder weniger> I/O lastig. D.h. der Löwenanteil beschäftigt sich mit Ein/Ausgabe. Das> Geplänkel dazwischen, das sind ein paar Umrechnungen. Vielleicht auch> mal ein Timer, der eine Variable hochzählt oder so. Aber aus recht viel> mehr bestehen diese Programme nicht. OOP bringt dir da nicht viel. OOP> beginnt seine Vorteile auszuspielen, wenn das Gesamtsystem größer und> komplexer wird.
ganz genau und genau das kann auch zum je nach Komplexität des
C-Programms zum Fiasko für den TO werden, wenn das vorhandene C-Programm
nur grafisch etwas gepusht werden soll ?!
Dann ist auch die weitergehende Frage, ob ich Konzepte wie Vererbung
überhaupt brauche, wenn es nur um Grafik und bunte Fensterchen mit
allerlei Gadgets geht.
Sinnvoll wäre es für ihn sich mit GTK+ zu beschäftigen. Ansonsten hilft
nur - gilt für komplexe Programme - neu programmieren mit Nutzung der
alten Algorithmen, Wiederverwertbarkeit ist eher eine Mär.
C forever schrieb:> schon unbedingt der C-Zweig, dann nimm doch C# ... das soll ja noch 100> mal besser als C++ sein ?!
Für Mikrocontroller? Gibt es das? C# lernt mein Sohn gerade in der
Schule und sieht gut aus. Ich will ja µC Programmieren, wenn ich das
dann kann. Ich glaube dafür gibt es kein C# oder Java.
Nur in abgespeckter Form für große uCs, aber ich vermute er wollte eher
den Unterschied und die verschiedenen Anwendungsbereiche nochmal
verdeutlichen.
C forever schrieb:>> Wenn ich das so sehe, dann frag ich mich wieder wieso ich nicht doch>> gleich C++ lernen soll?>> Man riet mir in diesem Forum erst C zu lernen.> weil C die Nachteile der OOP nicht hat, weil das gerade in Bezug auf das> Laufzeitverhalten relevant ist.
C++ hat lediglich zusätzliche Features, die, wenn man sie in C zu Fuß
nachbildet, dort den gleichen Overhead haben.
> Dann ist auch die weitergehende Frage, ob ich Konzepte wie Vererbung> überhaupt brauche, wenn es nur um Grafik und bunte Fensterchen mit> allerlei Gadgets geht.
Gerade da wird's ohne solche Konzepte ziemlich schnell zur Hölle.
mar IO schrieb:> Soweit ich weiß, ist GObject eine Art der objektorientiertes> Programmieren unter C> http://de.wikipedia.org/wiki/GObject
Ich hatte mal mit GTK und somit mit GObject zu tun. Ganz ehrlich: Es
macht einen wahnsinnig. Alleine schon weil man ständig irgendwelche
Präprozessormakros braucht die die Soße in (auf??) den richtigen Typ
casten. Wenn ich die Wahl habe und Objektorientierung wirklich brauche
würde ich C++ lernen.
C++ Features müssen sich einem aber auch erschließen, damit man sie
gezielt benutzen kann. Andernfalls tönt man ständig von RIESIGEM
Overhead.
Wie heißt es so schön:
Was der Bauer nicht kennt, will er auch nicht als Programmiersprache
benutzen. Oder so.
> C++ hat lediglich zusätzliche Features, die, wenn man sie in C zu Fuß> nachbildet, dort den gleichen Overhead haben.
das stimmt so nicht - ansonsten spräche überhaupt nichts dagegen C++
auch für Microkontroller-Programmierung, etc. zu verwenden ... aber da
geht es aufgrund der bescheidenen Hardwarevorgaben eben nicht, der
Overhead ist bei C++ immer größer als bei C was bei einem guten PC
bedeutungslos ist!
Du kannst das auch daran erkennen, wenn Du komplexe C und C++ auf einem
minderwertigen PC ablaufen läßt. Mach den Vergleich.
Oder denke an die Compiler-Programmierung.
Noch besser im Sinne der Laufzeit für Microcontroller-Programmierung
wäre Assembler, aber wer will sich das schon antun ): ... das muß auch
heute nicht mehr sein.
> Gerade da wird's ohne solche Konzepte ziemlich schnell zur Hölle.
es gibt inzwischen genügend Alternativen, z.B. C# oder Java + etliche
andere unbekannte Programmiersprachen, die ein unbekanntes Dasein
fristen.
C++ war/ist eine gute Zwischenlösung gewesen ...
Ok, Vorteil ist natürlich die schier unendliche Dokumentation, ansonsten
wär schon lange Ende.
> Für Mikrocontroller? Gibt es das?
für Mikrocontroller gibt es Bascom-Basic als Alternative, wie gut oder
schlecht das ist weiß ich allerdings nicht.
> Andernfalls tönt man ständig von RIESIGEM Overhead.
wie gesagt, bei einer guten Hardware wirst Du gar nichts merken - erst
bei sehr komplexen Programmen schlägt das je nach Hardwareausstattung
eben doch geringfügig zu Buche, je nach Hardware und Komplexität des
Programms mehr oder weniger.
> Wenn ich die Wahl habe und Objektorientierung wirklich brauche> würde ich C++ lernen.
Schnee von gestern; Du übersiehst, was aktuell en vogue ist.
C forever schrieb:>> C++ hat lediglich zusätzliche Features, die, wenn man sie in C zu Fuß>> nachbildet, dort den gleichen Overhead haben.> das stimmt so nicht - ansonsten spräche überhaupt nichts dagegen C++> auch für Microkontroller-Programmierung, etc. zu verwenden ... aber da> geht es aufgrund der bescheidenen Hardwarevorgaben eben nicht, der> Overhead ist bei C++ immer größer als bei C was
... kompletter Unsinn ist. 95% aller C Programme sind gleichzeitig auch
C++ Programme. Overhead == 0
> Du kannst das auch daran erkennen, wenn Du komplexe C und C++ auf einem> minderwertigen PC ablaufen läßt. Mach den Vergleich.
Ja. Haben wir.
Das Pendel schlägt zugunsten von C++ aus.
Schon alleine deswegen, weil man mit C++ bessere Möglichkeiten zur
wartbaren Codestrukturierung hat. Und wenn man OOP Konzepte richtig
einsetzt, dann sind sie schneller als funktions-äquivalenter C Code.
Virtuelle Funktionen macht man ja nicht ohne Grund. Hab ich die Wahl
zwischen einer switch-case Orgie, basierend auf einem Type-Member, und
einer virtuellen Funktion, dann ist mir die Funktion sowohl in Punkto
Geschwindigkeit als auch in Punkto Zukunftssicherheit um einiges lieber.
Das man nicht alles von C++ in einem kleinen µC sinnvoll einsetzen kann
und wird, versteht sich auch von selbst. Aber einige Konzepte sind
sinnvoll anzuwenden. Und den Rest kann man exakt genau so machen, wie
man es auch in C gemacht hätte.
C forever schrieb:>> C++ hat lediglich zusätzliche Features, die, wenn man sie in C zu Fuß>> nachbildet, dort den gleichen Overhead haben.> das stimmt so nicht - ansonsten spräche überhaupt nichts dagegen C++> auch für Microkontroller-Programmierung, etc. zu verwenden ...
Richtig. Dagegen spricht auch nichts, außer vielleicht Vorurteile und
gefährliches Halbwissen ... und letztendlich das Fehlen von brauchbaren
C++-Compilern für manche µC-Plattformen.
> aber da geht es aufgrund der bescheidenen Hardwarevorgaben eben nicht,> der Overhead ist bei C++ immer größer als bei C was bei einem guten PC> bedeutungslos ist!
Was für ein Unsinn. Ich habe schon Programme für Tiny-AVRs in C++
geschrieben (*). Man muß halt wissen, was man tut und genau wissen, zu
welchem Code die Nutzung der Sprachfeatures führt, aber das ist immer
so, wenn man extrem kompakten und/oder schnellen Code braucht und ihn
nicht gleich in Assembler implementieren will.
* Wenn man auf einem AVR Vererbung nutzen will, braucht man allerdings
tatsächlich mehr RAM, was aber nicht an C++ selbst, sondern an einer
Einschränkung von GCC liegt.
> Du kannst das auch daran erkennen, wenn Du komplexe C und C++ auf einem> minderwertigen PC ablaufen läßt. Mach den Vergleich.
Gnome ist mir bisher noch nie schneller vorgekommen als KDE. Bei
ersterem sind die ganzen Basisbibliotheken und auch manche Programme in
C geschrieben, bei KDE ist alles komplett C++.
> Oder denke an die Compiler-Programmierung.
Was ist damit? GCC als prominentes Beispiel ist inzwischen komplett in
C++ geschrieben:
http://www.heise.de/open/meldung/GCC-setzt-intern-verstaerkt-auf-C-1668224.html>> Gerade da wird's ohne solche Konzepte ziemlich schnell zur Hölle.> es gibt inzwischen genügend Alternativen, z.B. C# oder Java + etliche> andere unbekannte Programmiersprachen, die ein unbekanntes Dasein> fristen.
Das würde voraussetzen, daß man eine Alternative bräuchte. Ich brauche
sie nicht.
>> Für Mikrocontroller? Gibt es das?> für Mikrocontroller gibt es Bascom-Basic als Alternative, wie gut oder> schlecht das ist weiß ich allerdings nicht.
Das klingt für mich, als ob du zwanghaft versuchst, irgendwas zu finden,
das nicht C++ ist. Warum muß ich denn unbedingt was anderes benutzen,
wenn es mit C++ auch geht?
>> Andernfalls tönt man ständig von RIESIGEM Overhead.> wie gesagt, bei einer guten Hardware wirst Du gar nichts merken - erst> bei sehr komplexen Programmen schlägt das je nach Hardwareausstattung> eben doch geringfügig zu Buche, je nach Hardware und Komplexität des> Programms mehr oder weniger.
Ich habe den Eindruck, daß du nicht weißt, was ein C++-Compiler so aus
dem Code macht und daher auch nicht abschätzen kannst, welchen Overhead
es ergibt.
Wenn man objektorientiert programmiert, mit Interfaces, Vererbung,
strenger Kapselung u.s.w. ergibt sich durchaus ein gewisser Overhead,
aber der liegt nicht an C++, sondern am Konzept. Bei sehr großen und
komplexen Programmen braucht man das aber meistens auch, weil diese
sonst irgendwann nahezu unwartbar werden.
>> Wenn ich die Wahl habe und Objektorientierung wirklich brauche>> würde ich C++ lernen.> Schnee von gestern; Du übersiehst, was aktuell en vogue ist.
Irgendwelche schnell aus dem Boden schießenden Modesprachen können auch
genauso schnell wieder verschwinden. Und weder Java, noch C# kann ich
für den µC nutzen. Jetzt kann man natürlich für jede Plattform eine
eigene Sprache lernen, oder man kann einfach C++ nehmen und alle
Plattformen damit programmieren.
> So ein Gesülze. BASCOM ist doch Overhead pur. Auch wenn es vielen weiter> hilft
aha - diese Aussage sollte Dir eigentlich selbst zu denken geben.
Das Produkt BASCOM wird verkauft, obwohl es Overhead pur produziert und
in Deinen Augen Schwachsinn ist.
> ... kompletter Unsinn ist. 95% aller C Programme sind gleichzeitig auch> C++ Programme. Overhead == 0
siehe hier: http://de.wikipedia.org/wiki/Teilmenge
Was ist eine Teilmenge und was hat Mengenlehre mit C und C++ zu tun?
C ist eine Teilmenge von C++ und nicht umgekehrt - C++ ist die
Obermenge.
D.h. ich kann 100% der C-Programme mit C++ darstellen nicht aber
umgekehrt.
Ich kann bestimmte Konzepte wie Vererbung nicht in C umsetzen wie das in
C++ geht, da C dies nicht vorsieht - eben Teilmenge nicht Obermenge.
Overhead == 0 ... da hab ich meine berechtigten Zweifel und wenn Du des
Englischen mächtig bist, kannst Du es gerne nachvollziehen:
http://allmybrain.com/2008/08/09/how-much-overhead-does-c-bring-compared-to-straight-c/> Das Pendel schlägt zugunsten von C++ aus.> Schon alleine deswegen, weil man mit C++ bessere Möglichkeiten zur> wartbaren Codestrukturierung hat. Und wenn man OOP Konzepte richtig> einsetzt, dann sind sie schneller als funktions-äquivalenter C Code.
Es geht nicht um die Programmiermöglichkeiten, die sind in C++ natürlich
besser und in C# noch besser, sondern um die Laufzeiten.
Die Geschwindigkeitsunterschiede wirst Du nur bei schwacher Hardware
feststellen - nur dort!
Bei Linux und einem alten Rechner wirst Du sofort merken, daß KDE ein
C++ Produkt ist.
> Das man nicht alles von C++ in einem kleinen µC sinnvoll einsetzen kann> und wird, versteht sich auch von selbst. Aber einige Konzepte sind> sinnvoll anzuwenden. Und den Rest kann man exakt genau so machen, wie> man es auch in C gemacht hätte.
Wenn's Dich beruhigt, die Mikrocontroller wird man aufgrund der
zunehmenden Leistungsfähigkeit auch bald im geliebten C++ programmieren
können - Fakt ist aber derzeit noch C ... und das hat ja wohl Gründe ??!
Oder macht C soviel mehr Spaß als C++ trotz nicht vorhandener Konzepte?
> Ich habe den Eindruck, daß du nicht weißt, was ein C++-Compiler so aus> dem Code macht und daher auch nicht abschätzen kannst, welchen Overhead> es ergibt.
siehe mein nettes Beispiel aus dem anlgoamerikanischen Sprachraum:
http://allmybrain.com/2008/08/09/how-much-overhead...
Tja, da hat sich mal einer die Mühe gemacht.
> Wenn man objektorientiert programmiert, mit Interfaces, Vererbung,> strenger Kapselung u.s.w. ergibt sich durchaus ein gewisser Overhead,> aber der liegt nicht an C++, sondern am Konzept. Bei sehr großen und> komplexen Programmen braucht man das aber meistens auch, weil diese> sonst irgendwann nahezu unwartbar werden.
schon richtig, deshalb sagte ich ja auch, daß Laufzeiten und Overhead
bei leistungsfähiger Hardware keinerlei Rolle spielen - und deshalb
macht C++ ja auch einen gewissen Sinn.
Nur dessen sollte man sich bewußt sein und die tollen OOP Sprachen nicht
in den Himmel loben - es gibt Vorteile, aber eben nicht NUR Vorteile.
> Irgendwelche schnell aus dem Boden schießenden Modesprachen können auch> genauso schnell wieder verschwinden. Und weder Java, noch C# kann ich> für den µC nutzen.
dafür war C# und Java auch nie vorgesehen und C++ eigentlich auch nicht.
> Jetzt kann man natürlich für jede Plattform eine> eigene Sprache lernen, oder man kann einfach C++ nehmen und alle> Plattformen damit programmieren.
???
Java ist plattformunabhängig, C++ war es nie und kann es auch nie sein
ebenso wenig wie C#
> Irgendwelche schnell aus dem Boden schießenden Modesprachen können auch> genauso schnell wieder verschwinden.
das liegt auch ein gutes Stück an der mangelhaften Dokumentation, da ist
C++ klar im Vorteil.
C forever schrieb:>> Ich habe den Eindruck, daß du nicht weißt, was ein C++-Compiler so aus>> dem Code macht und daher auch nicht abschätzen kannst, welchen Overhead>> es ergibt.> siehe mein nettes Beispiel aus dem anlgoamerikanischen Sprachraum:> http://allmybrain.com/2008/08/09/how-much-overhead...> Tja, da hat sich mal einer die Mühe gemacht.
Naja, drei winzige Trivialprogrämmchen, für den Mac compiliert, deren
Haupt-Overhead vermutlich im Startup-Code, dem dynamischen Linker und
der einen Nutzung von cout liegen, halte ich nicht für sehr
repräsentativ.
Und gerade cout ist ein spannendes Thema, weil sich eine etwas
(insbesondere um das ganze Locale-Gedöns) reduzierte Version davon auf
einem kleinen µC sogar deutlich sparsamer und einfacher nutzbar
implementieren ließe als printf, und flexibler ist es auch noch.
C forever schrieb:>> Irgendwelche schnell aus dem Boden schießenden Modesprachen können auch>> genauso schnell wieder verschwinden. Und weder Java, noch C# kann ich>> für den µC nutzen.> dafür war C# und Java auch nie vorgesehen und C++ eigentlich auch nicht.>>> Jetzt kann man natürlich für jede Plattform eine>> eigene Sprache lernen, oder man kann einfach C++ nehmen und alle>> Plattformen damit programmieren.> ???> Java ist plattformunabhängig,
Außer halt für µCs. Unter Windows nimmt man dann C#, weil das da gerade
hipp ist, für den Mac darf's dann objective C sein, für den AVR
BASCOM...
> C++ war es nie und kann es auch nie sein
C++-Compiler gibt es mit Sicherheit für deutlich mehr Plattformen als
Java-VMs.
> ebenso wenig wie C#
Microsoft unterbindet (zumindest im Moment) zwar nicht die Entwicklung
auf anderen Plattformen, fördert sie aber auch nicht.
>> http://allmybrain.com/2008/08/09/how-much-overhead...
Ja, ich bin des englischen mächtig. Und froh, daß vieles auf dieser Welt
nicht von solchen Experten untersucht wird. Da hat einer hart geprüft.
Unterschiedliche Libs bringen unterschiedliche Filesize. Wahnsinn. Und
C++ schreibt mehr (unbenutzte) Labels ins ASM File. Haben wir's doch
gewußt: Overhead! Früher gab's PM, die Bild-Zeitung für die, die auch
mal Wissenschaftliches lesen wollten. Hab damals schon gelacht.
Ach bitte. Halt mir keine Lehrstunde in C++.
Ich programmiere länger in C und in C++ als du überhaupt auf der Welt
bist!
> http://allmybrain.com/2008/08/09/how-much-overhead...> Tja, da hat sich mal einer die Mühe gemacht.
Nö. Er zeigt nur, dass er wunderbar Äpfel mit Birnen vergleichen kann.
Ein const char* ist mit einem std::strin überhaupt nicht zu vergleichen.
Das eine ist ein Pickel am Ars... und das andere ist eine full-blown
String Klasse. stdout/printf ist mit std::cout überhaupt nicht zu
vergleichen. Wieder dasselbe: das eine öffnet potentielle Fehlerquellen,
das andere ist flexibel einsetzbar.
Aber wir können gerne mal ein nicht triviales Beispiel durchspielen. Du
schreibst die C-Version, ich schreibe die C++ Version. Jeder nimmt aus
dem ihm zur Verfügung stehenden Vorrat an Sprachmittel das Werkzeug,
welches ihm für den Einsatzzweck am geeignetsten erscheint. Und dann
vergleichen wir, welche Version den meisten Code braucht, die
Ausführungsgeschwindigkeit, die potentiellen Fehler im Programm und wie
das Programm mit fehlerhaften Benutzereingaben umgehen kann. Rechne
allerdings nicht damit, dass ich krampfhaft alles aus dem C++ Vorrat
auspacke, was es gibt, nur damit ich es verwende. Wenn ich einen
String-Literal brauche, dann werde ich auch weiterhin einfach ein
String-Literal benutzen und ihn nicht erst krampfhaft in einen
std::string einpacken, nur damit ich irgendwelche Byte-Zahlen in die
Höhe treibe ohne etwas davon zu haben.
> D.h. ich kann 100% der C-Programme mit C++ darstellen nicht> aber umgekehrt.
Psst. Einer der anerkannt besten C++ Compiler die es gibt, arbeitet auch
heute noch so, wie es CFront von Anfang an gemacht hat. Er hat ein C++
Programm erst mal in C übersetzt um es dann durch den auf einem System
bereits vorhandenen C Compiler jagen zu können.
Was sagt dir das in Bezug auf deine Aussage ".... nicht darstellbar"?
Um objektorientiert Programmieren zu lernen, würde ich Python verwenden.
Der Syntax ist viel einfacher und die Prinzipien schneller zu verstehen.
Danach würde ich eine kurze C-Phase einlegen und dann C++ machen.
>ansonsten spräche überhaupt nichts dagegen C++>auch für Microkontroller-Programmierung, etc. zu verwenden ... aber da>geht es aufgrund der bescheidenen Hardwarevorgaben eben nicht
es geht nicht?
arduinos kann man doch in C++ Programmieren..
(ohne jetzt die sinnhaftigkeit bewerten zu wollen..)
eigentlich ist es ja recht einfacht:
wer am µC in Java Programmieren will, ist wohl meist am holzweg
und wer eine GUI anwedugn in C schreiben will, auch..
die eizige Programmiersprache die immer und überall funktioniert ist
Pascal ;-) (vom AVR oder PIC bis hin zum Lazarus ..)
F. Fo schrieb:> Wenn ich das so sehe, dann frag ich mich wieder wieso ich nicht doch gleich C++
lernen soll?
Weil, vor Allem beim Einsatz auf Mikrocontrollern, dein C++ wesentlich
besser sein wird, wenn du C kennst. Man kann tatsaechlich C++ lernen,
ohne C zu lernen - aber es bedeutet einen wesentlichen Sprachbestandteil
von C++ weg zu lassen. Du kannst auch digitale Elektronik lernen, ohne
dir die analoge Elektronik anzusehen, aber du wirst es immer wieder zu
spueren bekommen, dass dir ein wesentlicher Teil fehlt.
Marwin schrieb:> Man kann tatsaechlich C++ lernen, ohne C zu lernen - aber es bedeutet> einen wesentlichen Sprachbestandteil von C++ weg zu lassen.
Ja, denn mit C++ ohne den C-Anteil könnte man nicht einmal zwei Zahlen
addieren :)
Im Ernst: Über 90% des Sprachumfangs von C wird auch in C++ regelmäßig
genutzt. Deswegen ist es überhaupt kein Fehler, mit C zu beginnen und
sich anschließend die C++-Addons anzueignen.
Yalu X. schrieb:> Ja, denn mit C++ ohne den C-Anteil könnte man nicht einmal zwei Zahlen> addieren :)
Seid doch mal ein wenig konstruktiver. Was ich von dir in letzter Zeit
lese, ist nur noch Korinthenkackerei.
Marwin schrieb:> Du kannst auch digitale Elektronik lernen, ohne> dir die analoge Elektronik anzusehen, aber du wirst es immer wieder zu> spueren bekommen, dass dir ein wesentlicher Teil fehlt.
Jau! Jeden Tag spüre ich das. Und je mehr ich lerne, desto mehr weiß ich
was ich alles noch nicht weiß. Ich komme mir von Tag zu Tag blöder vor
und wie blöd war ich erst davor?! Aber woher die Zeit nehmen? Wenn ich
auch immer bis in die Nacht lese und mich mit dem Thema beschäftige,
irgendwann muss ich auch mal schlafen. Der 'Morgen danach' wartet schon
mit neuer Arbeit. Kann ja auch nicht immer wie ein Schluck Wasser in der
Kurve aussehen, wenn ich zu den Kunden komme.
Nachdem ich meinen Bastelplatzausbau nun fertig habe, will ich auch
wieder mehr programmieren lernen und habe alle eure, vor allem deine,
lieber Karl-Heinz, Ratschläge beherzigt.
Das C-Buch fängt sehr gut an und steht dem C++ Buch in nichts nach, nur,
dass es viiiiiel weniger Umfang hat und man es noch gut in den Händen
halten kann.
So ein paar Zeilen hatte ich ja schon mit C in einem Tiny probiert, aber
auch hier folge ich eurem Rat und mache das jetzt erstmal am Computer.
Bis Ende des Jahres will ich vernünftig die Basissachen können und dann
das so langsam in die Controller schieben können. Wenn ich den Tiny13
und seine speicherstärkeren Brüder ausgereizt habe, dann kann ich weiter
sehen und werde dann sicher auch noch mal etwas Assembler probieren.
Erst dann werde ich mich ganz intensiv mit C++ beschäftigen und will das
in den folgenden vier Jahren richtig können.
In fünf Jahren will ich soweit sein, dass ich alles das bauen kann, was
mir an Ideen im Kopf ist.
Ist doch sehr vernuenftig - wesentlich vernuenftiger als viele
Anfaenger, die ein Riesenprojekt stemmen wollen und meinen, es gaebe
ganz viele Abkuerzungen zum Ziel. Mein aktuelles Projekt dauert auch
schon wieder 5 Jahre. Ist halt ein Feierabendprojekt. Hauptsache, es
macht Spass.
Hast Du keinen Hackerspace oder eine LUG in der Nähe? Dort befinden sich
meist immer ein paar Leute, die dir die Basics anschaulich erklären
können. In 2-3 Stunden lernt man da eine ganze Menge. Für eine kleine
Spende in die Kaffeekasse werden die noch williger. ;-)
Grüsse
Marwin schrieb:> Ist doch sehr vernuenftig - wesentlich vernuenftiger als viele> Anfaenger, die ein Riesenprojekt stemmen wollen und meinen, es gaebe> ganz viele Abkuerzungen zum Ziel. Mein aktuelles Projekt dauert auch> schon wieder 5 Jahre. Ist halt ein Feierabendprojekt. Hauptsache, es> macht Spass.
Ja, es macht mir einen irren Spaß. Aber ich verfolge auch noch ein
weiteres Ziel. Es soll ein zusätzliches Standbein werden und mir den
frühzeitigen Ausstieg aus meinem jetzigen Job erleichtern.
Meine Ideen haben (zumindest einem) andere schon zu einigem bis richtig
viel Geld verholfen. Leider partizipierte ich nie daran. Das soll sich
damit auch ändern.
Selten, sogar sehr selten habe ich ein richtiges Glücksgefühl, aber als
ich meine erste Steuerung so laufen hatte wie ich das wollte, das war
eines der größten Glücksgefühle in meinem Leben. Deshalb wäre es auch
nicht so wichtig und auch nicht enttäuschend, wenn ich das angepeilte
Ziel nicht so erreiche, wie ich mir das vorstelle.
Marwin schrieb:> Yalu X. schrieb:>> Ja, denn mit C++ ohne den C-Anteil könnte man nicht einmal zwei Zahlen>> addieren :)>> Seid doch mal ein wenig konstruktiver. Was ich von dir in letzter Zeit> lese, ist nur noch Korinthenkackerei.
Wieso so gereizt? Ich bin doch mit deiner Aussage völlig konform:
Marwin schrieb:> Weil, vor Allem beim Einsatz auf Mikrocontrollern, dein C++ wesentlich> besser sein wird, wenn du C kennst. Man kann tatsaechlich C++ lernen,> ohne C zu lernen - aber es bedeutet einen wesentlichen Sprachbestandteil> von C++ weg zu lassen. Du kannst auch digitale Elektronik lernen, ohne> dir die analoge Elektronik anzusehen, aber du wirst es immer wieder zu> spueren bekommen, dass dir ein wesentlicher Teil fehlt.
Und das ist jetzt nicht ironisch oder anderweitig unernst gemeint.
Zur Erläuterung habe ich ja oben auch noch geschrieben:
Yalu X. schrieb:> Im Ernst: Über 90% des Sprachumfangs von C wird auch in C++ regelmäßig> genutzt. Deswegen ist es überhaupt kein Fehler, mit C zu beginnen und> sich anschließend die C++-Addons anzueignen.
Das deckt sich doch mit deinem Beitrag, oder habe ich diesen vielleicht
falsch verstanden?
> Und gerade cout ist ein spannendes Thema, weil sich eine etwas> (insbesondere um das ganze Locale-Gedöns) reduzierte Version davon auf> einem kleinen µC sogar deutlich sparsamer und einfacher nutzbar> implementieren ließe als printf, und flexibler ist es auch noch.
Weil? Die Begründung fehlt noch, behaupten kann ich viel.
Gerade der Sinn von cout ist mir nie ganz klar geworden ... vielleicht
hatte ich auch das falsche Lehrbuch?
> Außer halt für µCs. Unter Windows nimmt man dann C#, weil das da gerade> hipp ist, für den Mac darf's dann objective C sein, für den AVR> BASCOM...
C# ist besser als C++ ansonsten würde es diesen Sprachdialekt gar nicht
mehr geben.
> C++-Compiler gibt es mit Sicherheit für deutlich mehr Plattformen als> Java-VMs.
das nützt Dir aber nichts, weil das C++ Programm auf das jeweilige
Betriebssystem angepaßt werden muß (wenn da eine Headerdatei, etc.
fehlt, dann viel Spaß). Selbst bei C hast Du dieses Problem und bei Java
eben nicht!
Insofern hat Java durchaus seine Berechtigung und wird zu Unrecht
gegenüber C++ runtergeredet.
> Und C++ schreibt mehr (unbenutzte) Labels ins ASM File. Haben wir's doch> gewußt: Overhead! Früher gab's PM, die Bild-Zeitung für die, die auch> mal Wissenschaftliches lesen wollten. Hab damals schon gelacht.
C++ ist bequemer zu programmieren als C quasi wie ein Automatikwagen,
insofern ok.
Aber geschwindigkeitsmäßig (ich meine komplexe Programme) hat mich C++
nie richtig überzeugt und ich behaupte auch mal bei C++ geht es nicht um
die Laufzeit. Deshalb hat es sich u.a. durchgesetzt so wie BASCOM in
seiner Nische.
Du kannst sagen was cout eigentlich soll, aber meinst die da
hinterlegende Sprache beurteilen zu können. Mach doch einfach wie Du's
willst, aber Müll hier nicht rum!
C forever schrieb:> Insofern hat Java durchaus seine Berechtigung und wird zu Unrecht> gegenüber C++ runtergeredet.
Natürlich hat Java seine Berechtigung. Aber Java hat seine Grenzen.
Für neue Hardware in Java einzubinden braucht du nativ Code und rate mal
in was der geschrieben wird. Und dast du das nächste Problem, weil dein
GargabeCollector überhaupt nicht daran denkt den Native Code zu
benachrichtigen wenn er das dazugehörige Java Objekt freigibt.
Das nächste Thema sind ist Signed/unsigned, du darfs dann alle binäre
Daten auf das doppelte aufblasen weil es kein unsigned gibt. Ich glaube
unsigned int hat man in der Zwischenzeit auch bei Java erfunden.
Weiter gehts mit den Synchronisation da meint jeder Java Programmierer,
da braucht er nicht darüber nachzudenken weil alle Objekte Threadsicher
sind.
Dann schreib mal ein grösseres Programm wo sehr viele Objekte dynamisch
angelegt und wieder gelöscht werden, und du wirst die Kehrseite der Java
Objekte kennen lernen. Oder schreib mal ein Programm indem du es mit
mehreren VM's gleichzeitig zu tun hast. Threadsicher sind Java Objekte
nur in ihrer eigenen VM.
Das waren jedenfalls meine Erfahrungen als ich vor über 10 Jahren
intensiv für einen Kunden in Java programmiert hatte. Mag sein das sich
Java in der Zwischenzeit auch ein bissel gebessert hat.
Und wenn ich nicht für einen Kunden was anderes muss ..
bleib ich bei C++ ;). Jedem das seine.
C forever schrieb:> C# ist besser als C++ ansonsten würde es diesen Sprachdialekt gar nicht> mehr geben.
Was ist das bitte für eine Aussage?
C forever schrieb:>> C++-Compiler gibt es mit Sicherheit für deutlich mehr Plattformen als>> Java-VMs.> das nützt Dir aber nichts, weil das C++ Programm auf das jeweilige> Betriebssystem angepaßt werden muß (wenn da eine Headerdatei, etc.> fehlt, dann viel Spaß). Selbst bei C hast Du dieses Problem und bei Java> eben nicht!> Insofern hat Java durchaus seine Berechtigung und wird zu Unrecht> gegenüber C++ runtergeredet.
Die Plattformunabhängigkeit wird dadurch erreicht, dass es jemand
anderes bereits für div. OSe programmiert hat. Es gibt div. Frameworks,
die auch Plattformunabhängig für C/C++ oder was weiß ich bereitstellt.
C forever schrieb:>> Und gerade cout ist ein spannendes Thema, weil sich eine etwas>> (insbesondere um das ganze Locale-Gedöns) reduzierte Version davon auf>> einem kleinen µC sogar deutlich sparsamer und einfacher nutzbar>> implementieren ließe als printf, und flexibler ist es auch noch.> Weil? Die Begründung fehlt noch, behaupten kann ich viel.> Gerade der Sinn von cout ist mir nie ganz klar geworden ... vielleicht> hatte ich auch das falsche Lehrbuch?
"printf()" ist eine Funktion. "cout" ist ein Objekt und stellt dir die
Möglichkeiten bereit, die C++ einem als OO-Sprache ermöglicht.
Naja, ein Lehrbuch oder Studium kann einem auch nicht alles
vorkauen/beibringen. Vieles lernt man erst beim Einsatz/durch Erfahrung
sammeln.
> Ach bitte. Halt mir keine Lehrstunde in C++.> Ich programmiere länger in C und in C++ als du überhaupt auf der Welt> bist!
das ist gut und es wär ja auch traurig schaurig, wenn es nicht so wäre
... deshalb bist Du auch zu Recht Moderator in diesem Forum.
Trotzdem muß man seine Behauptungen schon untermauern können, ansonsten
dürfen sie hinterfragt werden ?! Oder muß ich vom Meister alles blind
akzeptieren?
> http://allmybrain.com/2008/08/09/how-much-overhead...> Tja, da hat sich mal einer die Mühe gemacht.> Nö. Er zeigt nur, dass er wunderbar Äpfel mit Birnen vergleichen kann.> Ein const char* ist mit einem std::strin überhaupt nicht zu vergleichen.> Das eine ist ein Pickel am Ars... und das andere ist eine full-blown> String Klasse. stdout/printf ist mit std::cout überhaupt nicht zu> vergleichen. Wieder dasselbe: das eine öffnet potentielle Fehlerquellen,> das andere ist flexibel einsetzbar.
Gut, soviel Ahnung von C++ habe ich nicht - nenn mir doch mal bitte ein
gutes Buch, wo genau auf diese Genialität von cout intensiv eingegangen
wird - ich bin ja noch bildungswillig.
> Aber wir können gerne mal ein nicht triviales Beispiel durchspielen. Du> schreibst die C-Version, ich schreibe die C++ Version.
soviel Zeit habe ich leider gar nicht, mir reicht schon der tägliche
Stress im Job, danach bin ich fertig!
> Jeder nimmt aus dem ihm zur Verfügung stehenden Vorrat an Sprachmittel> das Werkzeug, welches ihm für den Einsatzzweck am geeignetsten> erscheint. Und dann vergleichen wir, welche Version den meisten Code> braucht, die Ausführungsgeschwindigkeit, die potentiellen Fehler im> Programm und wie> das Programm mit fehlerhaften Benutzereingaben umgehen kann.
da hätte ich als mittelprächtiger Hobbyprogrammierer schlechte Karten
und je nach Aufgabenstellung wird es dann ganz übel in C - das ist mir
schon klar.
Aber Gegenvorschlag:
Da Du ja absolut fit bist in C++, schreib die falsch programmierten C++
Trivialprogramme des von mir benannten Links um und führe den
Geschwindigkeitstest, Overheadtest, etc. durch. Sollte sich ja was
ändern.
Ansonsten ist leider Ebbe im WWW - Vergleichstests zwischen
Programmiersprachen findest Du selten bis gar nicht.
> D.h. ich kann 100% der C-Programme mit C++ darstellen nicht> aber umgekehrt.> Psst. Einer der anerkannt besten C++ Compiler die es gibt, arbeitet auch> heute noch so, wie es CFront von Anfang an gemacht hat. Er hat ein C++> Programm erst mal in C übersetzt um es dann durch den auf einem System> bereits vorhandenen C Compiler jagen zu können.>> Was sagt dir das in Bezug auf deine Aussage ".... nicht darstellbar"?
Dann verstehe ich Deine Aussage weiter oben nicht:
> "Und wenn man OOP Konzepte richtig einsetzt, dann sind sie schneller> als funktions-äquivalenter C Code."
wie geht das denn, wenn der Compiler erst nochmal in C
zwischen-übersetzt und dann C in Maschinencode?
Das ist ein Widerspruch in sich!
Dann ist miserabel in C programmiert worden, weiter nichts.
>"Und jetzt überleg mal, woraus deine µC-Programme in der großen Mehrheit>bestehen? Richtig: Die kleineren Programme sind alle mehr oder weniger>I/O lastig. D.h. der Löwenanteil beschäftigt sich mit Ein/Ausgabe."
Tja, auch da könnten wir alles durch den C++-Compiler jagen und alles
könnte in C++ programmiert werden?!
Also entweder ist der C++ Compiler dann doch nicht ganz so gut oder es
sind eben doch zeitkritische Laufzeit-Momente, die bei I/O eine Rolle
spielen.
C forever schrieb:> C++ ist bequemer zu programmieren als C quasi wie ein Automatikwagen,> insofern ok.
Das kann ich so nicht unterschreiben.
Wenn man in C++ nicht einfach darauf losprogrammiert wie in C und OOP
ein bissel Ernst nimmt macht es mehr Arbeit.
> Aber geschwindigkeitsmäßig (ich meine komplexe Programme) hat mich C++> nie richtig überzeugt und ich behaupte auch mal bei C++ geht es nicht um> die Laufzeit. Deshalb hat es sich u.a. durchgesetzt so wie BASCOM in> seiner Nische.
Das hat überhaupt nix mit Komplex zu tun. Sondern was man von C++
einsetzt und was nicht.
> Erst dann werde ich mich ganz intensiv mit C++ beschäftigen und will das> in den folgenden vier Jahren richtig können.
im Prinzip ist Dein Weg richtig und Du wirst merken, daß C für den
Hobbybereich völlig ausreicht - selbst bei Grafik gibt es mittlerweile
gute Lösungen.
Man hat auch nicht die Zeit im Alltag sich die tollen C++ Konzepte bis
zur tadellosen Beherrschung reinzuziehen, ich jedenfalls nicht ... und
die kommerziellen C++ Programme haben mich bisher nicht wirklich
überzeugt und sie sind nicht plattformunabhängig - das gilt für C, C++,
C#
Anstelle von C++ würde ich mir danach eher Java lernen oder eben C#,
Mono, Ruby oder eines der neuen Basic-Derivate, ggf. auch fasm,
http://flatassembler.net/download.php
wobei das sehr speziell und ziemlich schwierig ist ... aber die darin
programmierten Applikationen haben schon Ihren besonderen Charme :)
Na ja, alles Ansichtssache.
Hans-Georg Lehnard schrieb:> Das nächste Thema sind ist Signed/unsigned, du darfs dann alle binäre> Daten auf das doppelte aufblasen weil es kein unsigned gibt.
Das müssen nur Leute die nicht verstanden haben wie binäre Operationen
und zweierkomplement funktionieren ;-)
Hans-Georg Lehnard schrieb:> weil dein GargabeCollector überhaupt nicht daran denkt
Das sit auch nicht seine Aufgabe, native resourcen muss man selbst
verwalten, und selbst wenn man das nicht auf die Reihe kriegt kann man
noch mit einer ReferenceQue arbeiten...
Hans-Georg Lehnard schrieb:> Weiter gehts mit den Synchronisation da meint jeder Java> Programmierer, da braucht er nicht darüber nachzudenken> weil alle Objekte Threadsicher sind.
Hä? In welcher Java Version soll das sein, das ist so allgemein völlig
falsch.
Hans-Georg Lehnard schrieb:> Das waren jedenfalls meine Erfahrungen als ich vor über 10 Jahren> intensiv für einen Kunden in Java programmiert hatte
Kein Problem 10 Jahre sind gerade im PC bereich ja gerade mal ein
Wimpernschlag...
C forever schrieb:>> Und gerade cout ist ein spannendes Thema, weil sich eine etwas>> (insbesondere um das ganze Locale-Gedöns) reduzierte Version davon auf>> einem kleinen µC sogar deutlich sparsamer und einfacher nutzbar>> implementieren ließe als printf, und flexibler ist es auch noch.> Weil? Die Begründung fehlt noch, behaupten kann ich viel.> Gerade der Sinn von cout ist mir nie ganz klar geworden ... vielleicht> hatte ich auch das falsche Lehrbuch?
Das ist ganz einfach: Printf ist eine monolithische Funktion, die alles
abdeckt, was C an Basisdatentypen zu bieten hat. Da mit printf u.a. auch
Floats und Doubles ausgegeben werden können, hängt an der Funktion immer
auch ein Teil der FP-Bibliothek. Entsprechend fett ist diese Funktion.
Der <<-Operator von ostream hingegen ist nicht eine einzelne Methode,
sondern ist etwa 15fach überladen. Jeder Datentyp hat damit seine eigene
Methode. Bei einer für speicherarme Rechner geeigneten Implementierung
würde man die Bibliothek so organisieren, dass jede dieser 15 Methoden
eine einzelne Linker-Einheit bildet. Werden dann über cout nur Integer-
Zahlen ausgegeben, kommt man mit sehr wenig Programmspeicher aus, da die
Int->Dezimal-Umrechnung recht einfach ist. FP-Routinen werden nur dann
benötigt, wenn man auch tatsächlich Float- oder Double-Werte ausgeben
möchte.
Bei printf müssen die speicherfressenden FP-Routinen immer mit hinzuge-
linkt werden, da zur Compile-Zeit nicht ohne weiteres entschieden werden
kann, welche Datentypen in welchen Formaten tatsächlich ausgegeben
werden sollen.
Ein Work-Around wird in der AVR-Libc realisiert: Dort gibt es mehrere
unterschiedliche Ausbaustufen von printf (bspw. auch welche, die keine
FP-Zahlen unterstützen), zwischen denen mit geeigneten Linker-Optionen
ausgewählt werden kann. C++ braucht diesen Work-Around nicht.
Deswegen ist die modulare ostream-Ausgabe gerade für kleine Mikrocon-
troller viel besser geeignet als das monolithische printf. ostream ist
theoretisch sogar etwas schneller als printf, da das Parsen des Format-
strings entfällt.
Der <<-Ausgabeoperator in C++ kann auch leicht für neue Datentypen
erweitert werden, was bei printf ebenfalls nicht geht.
Das in meinen Augen einzige Manko von ostream liegt darin, dass jede
nicht ganz triviale Ausgabeanweisung (also bspw. mit Feldlängen- und
Radix-Spezifizierern für die einzelnen Variablen) im Quellcode zu einem
riesigen Rattenschwanz wird, der nicht nur viel Tipparbeit erfordert,
sondern auch schwer zu lesen ist. Im Vergleich dazu ist der Formatstring
von C++ nicht nur wesentlich kompakter, sondern fast schon WYSIWYG.
> Was ist das bitte für eine Aussage?
Offenbar waren die Konzepte von C++ nicht mehr ausreichend genug,
ansonsten hätte man sich C# getrost sparen können ... so einfach ist
das.
> Die Plattformunabhängigkeit wird dadurch erreicht, dass es jemand> anderes bereits für div. OSe programmiert hat. Es gibt div. Frameworks,> die auch Plattformunabhängig für C/C++ oder was weiß ich bereitstellt.
vergiß Deine Frameworks, das hört sich gut an bringt aber nicht so viel
- eine fehlende Headerdatei, dann nützt Dir auch Dein Framework herzlich
wenig.
Du mußt immer Anpassungen vornehmen und Dein Framework kostet auch jede
Menge Laufzeiteinbußen.
Und genau deshalb ist Java genial, da reicht ein Plugin im Browser
völlig aus.
> Naja, ein Lehrbuch oder Studium kann einem auch nicht alles> vorkauen/beibringen. Vieles lernt man erst beim Einsatz/durch Erfahrung> sammeln.
Was ist das denn für eine Aussage?
Ok, Fußball im Stadion ist auch immer besser für einen Fan.
Hachja die nutzlose Diskussion mal wieder :)
Yalu X. schrieb:> da das Parsen des Format-> strings entfällt.
Der Formatstring ansich gehört verboten. Ich meine mit Hilfe eines
c-Strings wird definiert, welche Typen der Funktionsaufruf hat. Bin ich
der einzige der das merkwürdig findet?
Weiter wie löst man sowas?:
1
structfoo{inta;intb;charc}bar={1,2,'a'};
2
inta=5;
3
4
printf("%i: ????",a,bar);// ??? Alle Komponenten angeben? Eine print_foo Funktion?
5
std::cout<<a<<": "<<bar;// So sieht das mit C++ streams aus
Und wenn wir schon beim Overhead sind: Vergleich mal std::sort mit
qsort.
> Bei printf müssen die speicherfressenden FP-Routinen immer mit hinzuge-> linkt werden, da zur Compile-Zeit nicht ohne weiteres entschieden werden> kann, welche Datentypen in welchen Formaten tatsächlich ausgegeben> werden sollen.
ok, leuchtet ein - Frage ist allerdings was Du programmieren willst?
in den meisten Fällen reichen einfache Programme aus und da spielt die
überfrachtete Printf-Funktion eigentlich keine Rolle.
> Ein Work-Around wird in der AVR-Libc realisiert: Dort gibt es mehrere> unterschiedliche Ausbaustufen von printf (bspw. auch welche, die keine> FP-Zahlen unterstützen), zwischen denen mit geeigneten Linker-Optionen> ausgewählt werden kann. C++ braucht diesen Work-Around nicht.
Stellt sich die Frage, weshalb AVR dann überhaupt noch in C programmiert
werden? Tradition?!
> Weiter wie löst man sowas?:> struct foo {int a; int b; char c} bar = {1, 2, 'a'};> int a = 5;> printf("%i: ????", a, bar); // ??? Alle Komponenten angeben? Eine> print_foo Funktion?> std::cout << a << ": " << bar; // So sieht das mit C++ streams aus
eigentlich ein genialer Test für diesen C++ Compiler, der erst den C
erzeugt
Schade, daß dieser C++ Compiler den C Code nicht anzeigt, dann hätten
wir das Ergebnis :-)
> Und wenn wir schon beim Overhead sind: Vergleich mal std::sort mit> qsort.
würde ich jetzt mal über copy and paste lösen:
Quellen:
http://www.tutorialspoint.com/c_standard_library/c_function_qsort.htmhttp://en.wikipedia.org/wiki/Sort_%28C%2B%2B%29
also z.B.:
#include <stdio.h>
#include <stdlib.h>
int values[] = { 99, 88, 14, 56, 6, 100, 2, 15, 23, 25 };
int cmpfunc (const void * a, const void * b)
{
return ( *(int*)a - *(int*)b );
}
int main()
{
int n;
printf("Before sorting the list is: \n");
for( n = 0 ; n < 10; n++ ) {
printf("%d ", values[n]);
}
qsort(values, 10, sizeof(int), cmpfunc);
printf("\nAfter sorting the list is: \n");
for( n = 0 ; n < 10; n++ ) {
printf("%d ", values[n]);
}
return(0);
}
#include <iostream>
#include <algorithm>
int main() {
int array[] = { 99, 88, 14, 56, 6, 100, 2, 15, 23, 25 };
int elements = sizeof(array) / sizeof(array[0]);
for (int i = 0; i < elements; ++i)
std::cout << array[i] << ' ';
std::sort(array, array + elements);
for (int i = 0; i < elements; ++i)
std::cout << array[i] << ' ';
}
Ist copy&paste und ungetestet ... kannst ja mal weiter machen, ich sag
good night für heute.
Statische Daten versus beliebig Erweiterbare.
Mit C++ hat das nur in soweit zu tun, wie es die dynamische Variante
verständlich ermöglicht.
Nachts ist es dunkler als draußen! Nix als Sülze.
C forever schrieb:> Schade, daß dieser C++ Compiler den C Code nicht anzeigt, dann hätten> wir das Ergebnis :-)
Anscheinend geht das mit Clang
http://llvm.org/releases/3.1/docs/FAQ.html#translatecxxC forever schrieb:>> Die Plattformunabhängigkeit wird dadurch erreicht, dass es jemand>> anderes bereits für div. OSe programmiert hat. Es gibt div. Frameworks,>> die auch Plattformunabhängig für C/C++ oder was weiß ich bereitstellt.> vergiß Deine Frameworks, das hört sich gut an bringt aber nicht so viel> - eine fehlende Headerdatei, dann nützt Dir auch Dein Framework herzlich> wenig.
Wieso sollte da was fehlen?
> Du mußt immer Anpassungen vornehmen und Dein Framework kostet auch jede> Menge Laufzeiteinbußen.
So ein Quatsch. Ein Framework hat jemand anderes programmiert und ich
muss nicht alles selber nach programmieren, sondern kann gleich weiter
programmieren. Wieso soll ich etwas programmieren, wenn es jemand
anderes schon programmiert hat? Laufzeit - ich glaub soviel Zeit hat
man...
> Und genau deshalb ist Java genial, da reicht ein Plugin im Browser> völlig aus.
Ob genial oder nicht, nicht die Lösung für alles.
C forever schrieb:>> Was ist das bitte für eine Aussage?> Offenbar waren die Konzepte von C++ nicht mehr ausreichend genug,> ansonsten hätte man sich C# getrost sparen können ... so einfach ist> das.
Da könnte man mehrere Prog.Sprachen aufführen, die man sich sparen kann.
Aber einerseits ist die Auswahl auch was herrliches für den einen - für
den anderen eine Qual.
C forever schrieb:>> Naja, ein Lehrbuch oder Studium kann einem auch nicht alles>> vorkauen/beibringen. Vieles lernt man erst beim Einsatz/durch Erfahrung>> sammeln.> Was ist das denn für eine Aussage?
Bezieht sich auf
> vielleicht> hatte ich auch das falsche Lehrbuch?
Alles steht halt nicht in einem Lehrbuch.
C forever schrieb:> Offenbar waren die Konzepte von C++ nicht mehr ausreichend genug,> ansonsten hätte man sich C# getrost sparen können ... so einfach ist> das.Man hätte sich C# tatsächlich sparen können, nur Microsoft nicht.
Nachdem die Firma aus der Java-Hersteller-Community hinausgeschmissen
worden war, musste etwas (zumindest dem Aussehen nach) Neues her, um der
bösen Konkurrenz die Java-Entwickler-Kundschaft abzugraben. Wenn dabei
zusätzlich noch ein paar C++-Entwickler übergelaufen war das ein für MS
angenehmer Nebeneffekt, aber nicht ganz so wichtig, da diese Entwickler
ja vorher schon ein MS-Produkt (nämlich Visual C++) benutzten.
Warum gibt es C#?
Es gab mal eine Computer-Firma, die hatte viele verschiedene CPU's, der
gleichen Architektur, die dann richtig gut liefen, wenn der Compiler für
jeden einzelnen Typ speziel optimierte. Und die hatten die geniale Idee:
Eine VM, die Bytecode ausführt. Um die Verbreitung zu fördern durften
auch andere diese Technik auf ihren Lieblings-CPU's nutzen.
Einer der anderen wollte aber sein eigenes Süppchen kochen und änderte
die VM. Das war nun aber wegen "Run everywhere" in der Lizenz an alle
ausdrücklich nicht erlaubt wurden und so mußte der Böse fortan sein Java
C# nennen. So war wieder alles im Lot. Es gab den einen und die andern
und manche glaubten, deshalb müßte alles andere obsolet sein.
Und wenn der c-forever nicht gestorben ist, dann glaubt er noch heute,
daß OO in C besser und schneller geht als in C++. Und er zählt und
vergleicht Takte in identischen Kompilaten.
printf("%i: ????",a,bar);// ??? Alle Komponenten angeben? Eine print_foo Funktion?
5
std::cout<<a<<": "<<bar;// So sieht das mit C++ streams aus
Die print_foo-Funktion musst du aber auch in C++ schreiben, nur heißt
sie dort anders, nämlich operator<<(...). Oder wurde etwa in C++11 die
Möglichkeit eingeführt, sich diese Funktion – ähnlich wie in Haskell –
automatisch generieren zu lassen? Das wäre cool.
Ich bin offen gestanden etwas überrascht, dass ausgerechnet die Syntax
von IOStreams hier als tolles Beispiel für C++ hergezeigt wird. Dabei
strotzen die doch nur vor konzeptionellen Problemen:
* Es wird der Shift-Operator überladen um diese "Datenpipeline"
darzustellen, mit dem Resultat, dass die Operator-Präzedenz komisch
wird:
/* oh, und anschließend den State wieder herstellen... */
* Zudem kann man bei Format-String-basierten Ansätzen bei der
Internationalisierung die Argumente in einer anderen Reihenfolge
interpretieren (siehe gettext). Mir ist total unklar, wie man mit der
festgeschriebenen Reihenfolge bei einem Stream funktionieren soll, wenn
man mal auf sprachliche Eigenschaften von verschiedene Sprachen
reagieren muss... (Ok, vielleicht für Mikrocontroller nicht so
unmittelbar relevant, aber trotzdem...)
Ich will nicht behaupten, dass printf mit seinem kruden varargs-Ansatz
hier das Maß aller Dinge ist, aber es steht echt nicht schlecht da...
Viele Grüße,
Simon
Simon Budig schrieb:> Ich bin offen gestanden etwas überrascht, dass ausgerechnet die Syntax> von IOStreams hier als tolles Beispiel für C++ hergezeigt wird.
Nicht die Syntax von cout wurde hier positiv hervorgehoben, sondern die
Möglichkeit, bei geeigneter Implementierung die Codegröße von
formatierten Ausgaben automatisch den tatsächlichen Erfordernissen
anzupassen.
Das hier war der Anlass dieser Diskussion:
Rolf Magnus schrieb:> Und gerade cout ist ein spannendes Thema, weil sich eine etwas> (insbesondere um das ganze Locale-Gedöns) reduzierte Version davon auf> einem kleinen µC sogar deutlich sparsamer und einfacher nutzbar> implementieren ließe als printf, und flexibler ist es auch noch.
Die Syntax der cout-Ausgaben habe ich weiter oben auch schon kritisiert:
Yalu X. schrieb:> Das in meinen Augen einzige Manko von ostream liegt darin, dass jede> nicht ganz triviale Ausgabeanweisung (also bspw. mit Feldlängen- und> Radix-Spezifizierern für die einzelnen Variablen) im Quellcode zu einem> riesigen Rattenschwanz wird, der nicht nur viel Tipparbeit erfordert,> sondern auch schwer zu lesen ist. Im Vergleich dazu ist der Formatstring> von C++ nicht nur wesentlich kompakter, sondern fast schon WYSIWYG.
> Da Du ja absolut fit bist in C++, schreib die falsch programmierten> C++ Trivialprogramme des von mir benannten Links um
Sie sind nicht falsch programmiert.
Sie sind so programmiert, dass sie nicht das aussagen, was du da drinnen
lesen willst.
Wenn du einen Trabbi und einen großen Volvo auf Tauglichkeit als
Familienkutsche für 5 Personen zur Fahrt in den Urlaub nach
Südfrankreich bewerten willst, dann reicht es eben nicht aus, wenn man
lediglich eine 100 Meter Teststrecke mit beiden abfährt, mit nichts
anderem im Kofferraum als 2 Badehosen.
Yalu X. schrieb:> Die Syntax der cout-Ausgaben habe ich weiter oben auch schon kritisiert:
:-)
Die mag wohl wirklich keiner. Damit bin ich auch nie warm geworden,
obwohl das Konzept ja an sich recht logisch ist (bis auf das Gewirx mit
den Formatierern)
Aber: Das ist ein Teilaspekt, der eben auch zu C++ gehört, aber noch
lange nicht das ist was C++ bzw. OOP überhaupt ausmacht. Deswegen
verteufelt man doch nicht den Rest. Und schon gar nicht mit so
blödsinnigen Argumenten, wie sie da gekommen sind, basierend auf Micky
Mouse Beispielprogrammen, die nur zeigen, dass der Basisunterbau bei C++
nun mal ein wenig fetter ist. Logisch - kann ja auch mehr. Bis ein
C-Programmierer seine String-Funktionen hat, dass sie genauso
zuverlässig und fehlersicher laufen wie std::string ist es nun mal ein
weiter Weg - der in Winzig-Testprogrammen wie den verlinkten nicht
gegangen wird.
Wer nicht versteh, wo der prinzipielle Unterschied zwischen
1
chartest1[10]="Juhu";
2
chartest2[10];
3
4
strcpy(test2,test1);
und
1
std::stringtest1="Juhu";
2
std::stringtest2;
3
4
test2=test1;
liegt, besser gesagt 'wer das gar nicht verstehen WILL', der soll sich
auch nicht zu dem Thema äussern. An einem Mikrotestprogramm seh ich nur,
dass erst mal die C++ Version deutlich größeren Code produziert. Was
sich aber ganz schnell relativiert, wenn die Textlänge nicht von vorne
herein bekannt ist, wie zb bei Benutzereingaben - und solche Dinge
dürften ja wohl der Normalfall in einem ernstzunehmenden Programm sein.
Nur, dann beginnt sich auch der C Code aufzublähen und was noch
schlimmer ist: er beginnt genau die Gestalt anzunehmen, die mir die C++
Version in Form von std::string schon abgenommen hat. Oder aber der C
Programmierer pfeift auf Fehlerbehandlung und dann haben wir genau den
Zustand, der 40 Jahre lang unbefriedigend war: Programme die man mit der
falschen Eingabe durch Bufferoverflows ganz leicht zum Absturz bringen
kann.
Und das ist jetzt auch wieder nur EIN Teilaspekt dessen, was C++ bzw.
OOP ausmacht.
C forever schrieb:>> Ein Work-Around wird in der AVR-Libc realisiert: Dort gibt es mehrere>> unterschiedliche Ausbaustufen von printf (bspw. auch welche, die keine>> FP-Zahlen unterstützen), zwischen denen mit geeigneten Linker-Optionen>> ausgewählt werden kann. C++ braucht diesen Work-Around nicht.> Stellt sich die Frage, weshalb AVR dann überhaupt noch in C programmiert> werden? Tradition?!
Bei Arduino wird immer C++ verwendet. Außerhalb der Arduino-Welt ist das
Problem, daß es keine richtige avr-Bibliothek für C++ gibt und daß auch
manche Sachen im avr-g++ verbesserungswürdig werden. Und es findet sich
eben keiner, dem die avr-Programmierung in C++ so wichtig wäre, daß er
sich diesen Zusatzaufwand antäte.
Yalu X. schrieb:> apr schrieb:>> Weiter wie löst man sowas?:struct foo {int a; int b; char c} bar = {1, 2, 'a'};> int a = 5;>> printf("%i: ????", a, bar); // ??? Alle Komponenten angeben? Eine print_foo
Funktion?
> std::cout << a << ": " << bar; // So sieht das mit C++ streams aus>> Die print_foo-Funktion musst du aber auch in C++ schreiben, nur heißt> sie dort anders, nämlich operator<<(...).
Ja, aber wie du ja schön gezeigt hast, sieht die Nutzung von cout ganz
genauso aus, wie ohne die Zusatzfunktion. Bei printf muß ich daran
denken, zumindest immer, wenn ich meinen Spezialtyp brauche, printf_foo
statt printf aufzurufen. Dazu muß ich mir dann eine Erweiterung für die
Formatstrings für den eigenen Typ überlegen und einen eigenen Parser um
den normalen Formatstring-Parser außenrum zu basteln. Und wenn mein
Datentyp sehr groß ist, empfielt sich auch, ihn nicht direkt, sondern
seine Adresse zu übergeben, da das Objekt sonst jedesmal beim Aufruf
komplett kopiert werden muß. Bei C++ hab ich dafür Referenzen, so daß
auch da die Übergabe der eigenen Typen nicht anders aussieht als die der
eingebauten Typen.
@c forever
schreib doch deine C-Version mal so um, dass sie ein beliebiges
Text-File mit einer beliebigen Zeilenlänge einlesen und sortieren kann.
Ok, beliebig - solange die Maschine noch mitspielt.
Ich rauch in der Zwischenzeit mal eine. Ich geb dir auch einen Tipp: der
Knackpunkt liegt in den beiden 'beliebig'.
Und dann vergleichen wir mal mit einer C++ Version. Sowohl was Eleganz,
Laufzeit, Entwicklungszeit (wird heutzutage immer wichtiger) und nicht
zu vergessen Fehlerfreiheit anbelangt.
Alleine bis du einen Ersatz für einen
std::vector<std::string>
fertig hast, der dann auch noch konkurenzfähig ist, dürfte die
Haupturlaubszeit schon vorbei sein.
(Ich kann das durchaus auch in C schreiben - so ist das wieder nicht.)
> Bis ein C-Programmierer seine String-Funktionen hat, dass sie genauso> zuverlässig und fehlersicher laufen wie std::string ist es nun mal ein> weiter Weg - der in Winzig-Testprogrammen wie den verlinkten nicht> gegangen wird.
und genau darum ging es dem TO, Plong A. (forentroll) in seiner
Fragenstellung, geht OOP in C überhaupt? Ja, es geht - ist aber
kompliziert und genau deshalb ist C++ aufgekommen, weil OOP nie der Sinn
von C war.
Das ist Dir als erfahrener C++ Programmierer bekannt und genau deshalb
ist Dir C zuwider, denn ein guter C++ Programmierer hat Schwierigkeiten
mit komplizierten C Sachverhalten. Ich kenn keinen, der alles kann -
irgendwo ist man ja auch Mensch - das kann man auch zugeben, ohne das
ein Zacken aus der Krone fällt.
Was C# anbelangt ist die Aussage von Microsoft interessant, die C# als
hervorrangend für kleine bis mittlere Programme einstuft, eben weil
vieles einfacher geht als bei C++
Genau das will ich doch als Hobbyprogrammierer. Andere Frage ist, ob die
neu aufgekommenen Basicdialekte dieses ebenfalls erfüllen können?
Die Industrie kann das aber nicht - dort ist Visual C++ Pflicht!
> schreib doch deine C-Version mal so um, dass sie ein beliebiges> Text-File mit einer beliebigen Zeilenlänge einlesen und sortieren kann.> Ok, beliebig - solange die Maschine noch mitspielt.> Ich rauch in der Zwischenzeit mal eine. Ich geb dir auch einen Tipp: der> Knackpunkt liegt in den beiden 'beliebig'.
so würde OOP in C laufen:
http://www.cs.rit.edu/~ats/books/ooc.pdf
und das mach mal Karl-Heinz nicht nur in Fragmenten so wie in dem
Skript, dabei wünsch ich Dir viel Spaß, denn als guter C++ Programmierer
wird Dich das nur noch nerven und Du würdest auch selbst Fehler machen
aufgrund Deines C++ Wissens, das dürfte auch klar sein ?! ... das heißt
aber nicht im Umkehrschluß, daß es nicht geht und die komplett andere
Frage lautet:
Was will ich denn überhaupt programmieren, brauche ich dafür OOP oder am
Ende doch nicht? Welchen Sinn macht im Zusammenhang mit OOP das
Ausweichen auf aktuelle Sprachen wie C#, Java, Ruby, usw.
Wie gesagt, viele Wege führen zum Ziel, aber zu meinen, daß nur das was
die Mehrheit nutzt automatisch immer das richtige Werkzeug ist - da bin
ich anderer Ansicht.
Aber ich kanns verstehen, wenn man perfekt in C++ ist, dann ist C++ die
Welt und sonst nichts.
Die Umkonvertierung eines komplexen C Programms in ein C++ Programm ist
noch ein ganz anderes Thema, aber darauf gehe ich jetzt mal nicht ein,
ich hab noch anderes zu tun.
C forever schrieb:> > Knackpunkt liegt in den beiden 'beliebig'.> so würde OOP in C laufen:
Du kannst dein ganz normales C benutzen. Du musst kein OOP verwenden,
sondern programmierst dein C so, wie du es immer programmierst.
> ich hab noch anderes zu tun.
Ah, ja.
Das heißt du hebst den Fehdehandschuh nicht auf.
Auch gut.
> Aber ich kanns verstehen, wenn man perfekt in C++ ist,> dann ist C++ die Welt und sonst nichts.
Nö. Hier im Forum und auch privat in meinen µC-Entwicklungen benutze ich
ganz banales C - weil mir C++ dort keine Vorteile bringt.
Aber ich stell mich nicht hier her und argumentiere mit 0-Argumenten,
warum C++ scheisse ist und das alles so langsam ist (ist es nicht) und
überhaupt. Kein einziges deiner Argumente war stichhaltig.
Diese Aussage
> weil C die Nachteile der OOP nicht hat, weil das gerade> in Bezug auf das Laufzeitverhalten relevant ist.
ist einfach nur gequirlte Schei..., geschrieben von einem der C++ nicht
kennt und als Beleg dafür Micky Mouse Programme anführt.
> Die Umkonvertierung eines komplexen C Programms in ein C++ Programm> ist noch ein ganz anderes Thema
Und? Was habe ich dem TO die ganze Zeit gepredigt? Dass das erst mal
überhaupt kein Thema ist, denn er braucht es erst mal nur durch den C++
Compiler jagen, die paar Syntax-Sachen anpassen, wenn er malloc
verwendet hat, einen Cast ergänzen (und später irgendwann mal auf
new/delete umstellen) und ... fertig ist sein erstes C++ Programm.
Und dann kann man sukzessive im Lauf der Zeit anfangen, die Dinge durch
Klassen/Methoden und OOP-Konzepte austauschen.
Hast du das schon mal gemacht? Ich hab es gemacht und ja, das
funktioniert ausgezeichnet.
haha
da gibts sogar bücher darüber
http://www.cs.rit.edu/~ats/books/ooc.pdf
bei so vielen Sternen wird einem als nur ab und zu C Programmierer aber
eher schlecht:
struct Class {
size_t size;
void * (* ctor) (void * self, va_list * app);
void * (* dtor) (void *
self);
void * (* clone) (const void *
self);
int (* differ) (const void * self, const void * b);
}
wie man da Vererbung und method overriding usw. macht, möcht ich jetzt
gar nicht wissen.. ;-)
> Ah, ja.> Das heißt du hebst den Fehdehandschuh nicht auf.> Auch gut.
tja, mein Job ist ätzend, Deiner nicht - und außerdem würde dabei nichts
rauskommen, da Du sowieso immer Recht hast, nicht wahr?
> Nö. Hier im Forum und auch privat in meinen µC-Entwicklungen benutze ich> ganz banales C - weil mir C++ dort keine Vorteile bringt.
Du sagst es, banales C, weil die restlichen Möglichkeiten von C nicht
weiter interessieren.
> Aber ich stell mich nicht hier her und argumentiere mit 0-Argumenten,> warum C++ scheisse ist und das alles so langsam ist (ist es nicht) und> überhaupt.
C++ ist in die Jahre gekommen genau wie C und es gibt genügend
Alternativen die besser als C++ sind, wenn es denn unbedingt OOP sein
muß.
In der Industrie geht das nicht, weil die ultrakomplexe Programme
schnell entwickeln müssen - deshalb nutzen die primär C++
Als Hobbyist habe ich ganz andere Vorgaben.
C++ ist langsamer insbesondere auf schlechter Hardware und bei komplexen
Programmen, diese Erfahrung hab ich zumindest gemacht.
C++ ist deshalb Scheisse, weil es genügend Leute gibt, die C++ als Stein
der Weisen propagieren ungeachtet der Schwächen dieser Sprache,
ungeachtet anderer Möglichkeiten, die schon im Vorfeld attackiert
werden, weil C++ das Beste ist und alles andere natürlich Scheisse ist.
Was sie verschweigen ist, daß man nicht jede Sprache gleichgut
beherrschen kann und das der Lernaufwand für C++ ernorm ist - so sichert
man sich den eigenen Vorteil ab, weil ein Newcomer nie das Niveau eines
erfahrenen Programmierers erreichen wird.
Als Hobbyprogrammierer (ich rede jetzt bewußt nicht von der Industrie)
würde ich nach einem kleinen Basic, Assembler, C-Exkurs mich auf die
Sprachen konzentrieren, die brandaktuell sind anstatt viel Energie im
veralteten C++ zu verpulvern, daß seine Vorteile in Großprojekten hat.
Ansonsten habe ich jede Menge bessere Alternativen je nach Anwendung
bzw. Programmidee! Das wird verschwiegen und genaud deshalb ist C++
Scheisse.
Ich persöhnlich habe einige Jahre C programmiert und war immer der
Meinung, dass man auf das objektorientierte Programmieren verzichten
kann.
Irgendwann habe ich mich dann doch intensiver damit befasst. Gedanklich
war die Umstellung mit einem gewissen Aufwand verbunden. Insbesondere
neigt man immer stark dazu, sich der alten Konzepte zu bedienen, die man
im Kopf hat und die einfach von der Hand laufen.
Meiner Meinung nach lernt man objekorientiert am besten, wenn man sich
mit den Konzepten der UML ( insbesondere Klassendiagramme ) beschäftigt.
Hier sollte man mal ein paar Tage inverstieren. Als Einführung empfehle
ich folgendes Buch:
http://www.uml.ac.at/
Ist einfach zu lesen und praxisorientiert.
Danach sollte man sich 1-2 Wochen mit einer einfache Programmiersprache
ohne komplizierten Syntax die OO-Konzepte üben. Dazu empfehle ich
Python.
Zum lernen lohnt es sich mittlerweile auch, ein paar passende Youtube
Videos anzuschauen.
Wenn das durch ist, könnte man 4 Wochen C auf dem PC lernen und dann 4
Wochen Portkonfigurationen auf einem echten Mikrocontroller testen.
Danach sollte man 8 Wochen C++ auf dem PC machen und dann auf den MC
umsteigen.
Diese Programm halte ich für einen sehr effizienten Einstieg.
c forever schrieb:> tja, mein Job ist ätzend, Deiner nicht - und außerdem würde dabei nichts> rauskommen, da Du sowieso immer Recht hast, nicht wahr?
Solange du als Blinder unbedingt ueber Farben diskutieren willst, wird
das immer darauf herauslaufen, dass andere Recht haben.
> Das wird verschwiegen und genaud deshalb ist C++ Scheisse.
Du bist einfach nur ein Troll.
chris schrieb:> Ich persöhnlich habe einige Jahre C programmiert und war immer der> Meinung, dass man auf das objektorientierte Programmieren verzichten> kann.
Ueber sowas wundere ich mich immer wieder. Ich habe einige Jahre C
programmiert und zwangslaeufig den Weg zu OO gefunden, ohne vorher davon
gehoert zu haben. Am Anfang waren meine Programme ein riesiges File mit
vielen Funktionen, spaeter habe ich den Code in separate Files
aufgeteilt, der Uebersichtlichkeit wegen, mit der steigenden Erfahrung
immer mehr auf Strukturierung und schliesslich auf Modularisierung
gesetzt. Irgendwann hat sich quasi eingeschlichen, dass ich Module um
Strukturen organisiert habe. Auch Dinge wie Vererbung gehoerten ganz
selbstverstaendlich dazu. Als ich dann zum ersten Mal von OO und C++
gehoert habe, dachte ich mir nur: Wozu, das mache ich doch jetzt schon?
Auf den zweiten Blick habe ich schnell gemerkt, dass ich in C++ das, was
ich schon mache einfach bequemer machen kann und ich mir so wieder neue
Moeglichkeiten auf dem Weg erschliessen kann, den ich sowieso schon
beschreite.
OO ist nicht, wenn man moeglichst viele abgefahrene Features einer
bestimmten Programmiersprache benutzt. Es ist eine Philosophie,
Loesungen zu strukturieren. *
Diesen Weg findet man natuerlich nicht, wenn man immer den einfachen Weg
geht und um so stolzer ist, um so komplexer der eigene Code ist.
* Dass man zum Beispiel mit Templates auch sehr effiziente und wartbare
Loesungen fuer Mikrocontroller produzieren kann, ist ein weiterer
Vorteil von C++ - der aber gar nicht zwingend etwas mit OO zu tun hat.
> (dank Apple)> hat ObjectiveC übrigens inzwischen C++ überholt..> http://www.tiobe.com/index.php/content/paperinfo/t...
guter Link, der zeigt was Sache ist - Danke dafür.
ggf. auch dank Android.
> http://www.uml.ac.at/
das ist der Vorteil von C++ und C, Du findest immer Dokumentationen zu
der jeweiligen Thematik im Netz, insofern werden diese Sprachen auch
nicht sterben, keine Sorge.
> Diesen Weg findet man natuerlich nicht, wenn man immer den einfachen Weg> geht und um so stolzer ist, um so komplexer der eigene Code ist.
hä? Dann kann ich ja auch OOP in C programmieren (siehe meinen Link
oben), auf GTK+ ausweichen, usw., oder am Ende am besten noch
Inline-Assembler, mach das mal :(
Es hängt einzig und allein von der Aufgabenstellung und den Vorgaben ab,
danach sollte die Programmiersprache gewählt werden!
Deine Denkweise, es geht nur mit C++ weil Du das beherrschst, das ist
der Denkfehler. Es gibt genügend Alternativen!
Die Auswirkungen siehst Du ja in dem Link
http://www.tiobe.com/index.php/content/paperinfo/t...
, es gibt sinnvolle Neuerungen wie ObjectiveC ... und selbst Java liegt
noch vor C++ ... warum wohl?
Ganz zu schweigen von einigen Basic-Dialekten, die eben schön einfach
zum Ziel führen ,,, ich will die Aufgabe als solche lösen, einfach ohne
viel Lernaufwand und wenn die Geschwindigkeit auch noch stimmt, umso
besser.
c forever schrieb:> es gibt sinnvolle Neuerungen wie ObjectiveC
Objective-C ist keine Neuerung. Es ist genauso alt wie C++, nur dass es
im Gegensatz zu diesem bis zur Einführung des iPhone ein absolutes
Schattendasein gefristet hat. Über die Gründe dafür darf sich jeder
selber Gedanken machen :)
>guter Link, der zeigt was Sache ist
nein (das war eher als Provokation gedacht :-))
http://www.tiobe.com/index.php/content/paperinfo/tpci/tpci_definition.htm
er zeigt "nur" wieviel über eine bestimmte Sprache
"diskudiert"/geschrieben wird..
das kann man jetzt interpretieren wie man will, ..
die einteilung Grouping: Delphi, Delphi.NET, Object Pascal
und eine eigene für Pascal
vorallem Delphi aufführen, und Lazarus ignorieren usw.
ist irgendwie fargwürdig
> er zeigt "nur" wieviel über eine bestimmte Sprache> "diskudiert"/geschrieben wird..
ok, wenn man dazugehörigen Text liest, wird es klar :)
> vorallem Delphi aufführen, und Lazarus ignorieren usw.> ist irgendwie fragwürdig
wahrscheinlich haben sie Lazarus in die Pascal Sparte gepackt, genauso
wie Assembler oder Basic, das nur als (Visual) auftaucht.
> Objective-C ist keine Neuerung. Es ist genauso alt wie C++, nur dass es> im Gegensatz zu diesem bis zur Einführung des iPhone ein absolutes> Schattendasein gefristet hat. Über die Gründe dafür darf sich jeder> selber Gedanken machen :)
ok, Denkfehler von mir - hätte ja auch eine Neuauflage mit ein paar mehr
Features sein können so wie bei Ada, etc.
c forever schrieb:> ok, Denkfehler von mir - hätte ja auch eine Neuauflage mit ein paar mehr> Features sein können so wie bei Ada, etc.
Du schreibst eben zu viel ueber Dinge, von denen du nichts verstehst.
Ich habe uebrigens auch schon einige Erfahrung mit objective-C gesammelt
- davon sollte sich C++ eine dicke Scheibe abschneiden. Oder vielleicht
auch nicht, wozu gibt es verschiedene Sprachen...
Abgesehen davon ging es hier um objektorientierte Programmierung in C.
Und da liegt die Migration nach C++ nahe, die nach objective-C, Basic
oder Java nicht.
Der Herr Schreiner schreibt 1993, wie man OO auch in C hinbekommt. Kann
ich verstehen. Damals hatte ich auch keinen G++. Nichtmal die Sprache
selber war damals mit dem heutigen Sprachstandard vergleichbar.
Objektive-C stammt von einem (inzwischen seligen) Egomanen, der, wenn er
C++ verstanden hat, dann doch nicht ertragen konnte, es nicht selbst
erfunden zu haben. Ok, etwas hart, den als Objective-C entstand, war ja
C++ (siehe oben) noch nicht ganz gebacken.
Mir persönlich liegen Methoden-Aufrufen, die wie Array-Zgriffe aussehen
nicht. Oder ich will mir einfach keinen Mac kaufen.
Aber es geht ja hier um OO in C:
Muß man ein passendes Werkzeug nicht benutzen, nur weil es mit
Verrenkungen auch mit einem unpassende geht?
C forever schrieb:>> Die Plattformunabhängigkeit wird dadurch erreicht, dass es jemand>> anderes bereits für div. OSe programmiert hat. Es gibt div. Frameworks,>> die auch Plattformunabhängig für C/C++ oder was weiß ich bereitstellt.> vergiß Deine Frameworks, das hört sich gut an bringt aber nicht so viel> - eine fehlende Headerdatei, dann nützt Dir auch Dein Framework herzlich> wenig.
Die meisten Java-Programme, die mir über den Weg gelaufen sind, lassen
sich nicht einfach so auf jeder Plattform starten. Es gibt oft genug für
jede Zielplattform eine eigene Version des Programms, die auch gleich
die ganze VM mitbringt, weil's mit anderen als genau dieser Version
nicht gescheit funktioniert. Hab auch schon genug Java-Programme
gesehen, die nur unter Windows gestartet werden können.
Als ich mitbekommen hab, daß die ganzen Android-Apps alle in Java
programmiert sind, dachte ich auch, endlich mal etwas gefunden zu haben,
wo sich der Vorteil von Java bemerkbar macht. Ich war so naiv zu glaube,
daß die ja bestimmt problemlos auch auf meinem Linux-PC laufen, weil's
ja Java ist, das überall geht. Pustekuchen!
Also soweit her kann's mit der Plattformunabhängigkeit auch nicht sein.
Mit ein bischen Mühe und den richtigen Bibliotheken bekommt man das
bestimmt hin, aber das gilt auch für C++. Bei letzterem muß man es
lediglich für die verschiedenen Zielplattformen jeweils nochmal
compilieren.
> Aber es geht ja hier um OO in C:> Muß man ein passendes Werkzeug nicht benutzen, nur weil es mit> Verrenkungen auch mit einem unpassende geht?
nein, es ging ursprünglich nicht um OO in C, sondern um die Erweiterung
eines vorhandenen C Programms um ein paar OO Features.
Das ist also etwas anderes und je nach Umfang des C Programms kann das
schon sehr schwierig werden, insbesondere dann wenn der TO nicht so fit
in C++ ist.
Deswegen kam ja die Frage auf, ob OO nicht auch in C geht - ja geht,
aber schön kompliziert, dafür war C nie erdacht worden.
> Die meisten Java-Programme, die mir über den Weg gelaufen sind, lassen> sich nicht einfach so auf jeder Plattform starten. Es gibt oft genug für> jede Zielplattform eine eigene Version des Programms, die auch gleich> die ganze VM mitbringt, weil's mit anderen als genau dieser Version> nicht gescheit funktioniert.
na toll bzw. nicht toll, wenn es so ist.
Bei C++ hast Du allerdings das gleiche Dilemma je nach Umfang und
benutzten Quellcode.
Wie gesagt, Programme mal eben umschreiben kann sehr schnell gehen oder
im Frust ausarten.
> Mit ein bischen Mühe und den richtigen Bibliotheken bekommt man das> bestimmt hin, aber das gilt auch für C++. Bei letzterem muß man es> lediglich für die verschiedenen Zielplattformen jeweils nochmal> compilieren.
ja nicht nur das, wenn eine Headerdatei, etc. fehlt, dann mußt Du das im
Quellcode anpassen, gleiches gilt für C, usw.
> Abgesehen davon ging es hier um objektorientierte Programmierung in C.> Und da liegt die Migration nach C++ nahe, die nach objective-C, Basic> oder Java nicht.
Wenn das ein sehr umfangreiches Programm ist, dann sollte man sich
überlegen ein paar Algorithmen zu übernehmen und nochmal neu anzufangen
- das geht in jeder Sprache.
Sobald man zu sehr am alten Programm klebt, übersieht man auch
Möglichkeiten von C++, etc.
Migration ist nur bei kleineren Programmen sinnvoll.
Frage: Warum migriert man nicht mal eben C++ Programme nach C#?
Alles klar, oder?
Rolf Magnus schrieb:> Die meisten Java-Programme
Die meisten Verallgemeinerungen sind falsch ;-)
Rolf Magnus schrieb:> Es gibt oft genug für jede Zielplattform eine> eigene Version des Programms
Da gibt es zwei Varianten:
- Es gibt pro "Zielplattform" einen nativen Launcher/Installer
(Hier würde das auch auf anderen Plattformen laufen wenn man es
korrekt aufruft)
- Es gibt pro "Zielplattform" eine spezielle DLL (z.B. für direkten HW
Zugriff), da ist wohl klar das diese (u.A. in C++ geschriebene) für
jedes Plattform anders ist, auch hier könnte man eine "Multiplattform"
Variante machen wo alles enthalten ist.
Beides sind aber eher Kompfortfunktionen und haben nichts mit der
Plattformunabhängigkeit von Java zu tun.
Rolf Magnus schrieb:> Als ich mitbekommen hab, daß die ganzen Android-Apps> alle in Java programmiert sind
Die Sprache ist Java, Compiliert wird in Java, dann wird aber in einen
"Nativen" Code übersetzt (siehe Dalvik VM).
Rolf Magnus schrieb:> aß die ja bestimmt problemlos auch auf meinem Linux-PC laufen
Tun sie auch wenn du Sie z.B. im Android Simulator startest, du könntest
Sie sogar auf einer "normalen" VM laufen lassen aber das bringt nicht so
viel, da ja gerade die Interaktion mit dem Gerät (Touch, GPS, Kamera,
...) im Vordergrund steht, das müsstest du halt erst mal nachbilden.
Rolf Magnus schrieb:> Bei letzterem muß man es lediglich für die verschiedenen> Zielplattformen jeweils nochmal compilieren.
Das ist jetzt aber auch stark vereinfacht... Solange du nur die STL
nutzt mag das ja noch stimmen, aber spätestens bei Threads, Sockets oder
gar GUI bist du darauf angewiesen, das es die Lib für deine
Zielplattform gibt.
Rolf Magnus schrieb:> Also soweit her kann's mit der Plattformunabhängigkeit auch nicht sein.
Ich entwickle alle meine Programme für Kunden in Java auf einem Linux
PC, laufen tun die hauptsächlich unter WinXP/Win7 und ein Mac ist auch
darunter, der Code ist immer der selbe, es gibt nur pro System einen
Launcher, was bedeutet das nach dem Compilieren noch 2-3 Dateien
dazukopiert werden (wie gesagt: Komfortfeature...), ansonsten gibt es im
Code keinerlei Spezifika.
Läubi .. schrieb:> Rolf Magnus schrieb:>> Die meisten Java-Programme, die mir über den Weg gelaufen sind>> Die meisten Verallgemeinerungen sind falsch ;-)
Das ist weder eine Verallgemeinerung, noch ist es falsch.
Läubi .. schrieb:> Beides sind aber eher Kompfortfunktionen und haben nichts mit der> Plattformunabhängigkeit von Java zu tun.
So komfortabel finde ich das irgendwie nicht, wenn ich erstmal schauen
muß, wie ich auf meinem ARM-Linux den Windows-Installer ausgeführt
bekomme, um dann danach das .exe-File, das das Java-Programm in der
mitgelieferten nur-Windows-VM startet, durch was zu ersetzen, das das
Programm mit der im System installieren VM ausführt. Und ob das dann
auch geht oder ob man da jetzt speziell irgendein Blackdown oder Sun
oder was auch immer braucht, steht wieder auf einem anderen Blatt.
Läubi .. schrieb:> Rolf Magnus schrieb:>> aß die ja bestimmt problemlos auch auf meinem Linux-PC laufen> Tun sie auch wenn du Sie z.B. im Android Simulator startest, du könntest> Sie sogar auf einer "normalen" VM laufen lassen
Ja, toll. Das ist elends langsam, frisst Ressourcen ohne Ende, und alle
Apps sind in einem gemeinsamen Emulator-Fenster eingepfercht. Das Ding
ist ganz nett, um Apps zu entwickeln und debuggen, aber nicht, um es als
normaler Anwender zu benutzen.
Ich kann auf meinem PC auch Playstation-Spiele laufen lassen, wenn ich
einen Emulator dafür habe, aber ich meinte natürlich schon eher mehr
oder weniger nativ (also die Java-VM nicht nochmal in einer
virtualsierten Umgebung laufen zu lassen).
> Rolf Magnus schrieb:>> Bei letzterem muß man es lediglich für die verschiedenen>> Zielplattformen jeweils nochmal compilieren.> Das ist jetzt aber auch stark vereinfacht... Solange du nur die STL> nutzt mag das ja noch stimmen, aber spätestens bei Threads, Sockets oder> gar GUI bist du darauf angewiesen, das es die Lib für deine> Zielplattform gibt.
Also so ähnlich, wie bei den Android-Apps, wenn man sie auf dem PC
laufen lassen will. Da fehlen halt auch die Libs dafür.
Mir ist schon klar, daß bei Java deutlich mehr an Funktionalität schon
in der Standard-Bibliothek enthalten ist. Da bin ich vielleicht auch
etwas durch Qt verwöhnt, das mir das auch für C++ alles bietet.
Threads sind in C++ übrigens inzwischen enthalten.
> Rolf Magnus schrieb:>> Also soweit her kann's mit der Plattformunabhängigkeit auch nicht sein.> Ich entwickle alle meine Programme für Kunden in Java auf einem Linux> PC, laufen tun die hauptsächlich unter WinXP/Win7 und ein Mac ist auch> darunter, der Code ist immer der selbe, es gibt nur pro System einen> Launcher, was bedeutet das nach dem Compilieren noch 2-3 Dateien> dazukopiert werden (wie gesagt: Kompfortfeature...), ansonsten gibt es> im Code keinerlei Spezifika.
Abgesehen davon, daß ich es für die Zielplattformen separat compilieren
muss, ist das bei meinen Qt-Programmen auch nicht anders.
Rolf Magnus schrieb:> So komfortabel finde ich das irgendwie nicht
Man kann es sich natürlich auch immer zurechtreden... es mag ja solche
Konfigurationen geben, genauso gibt es auch C++ Programme die nur für
Windows kompiliert vorliegen, Standard ist das bei Java nicht und zu
sagen alle Programme seien so ist schlich falsch.
Genauso könnte ich argumentieren, das ja alle Tools 'speziell' für
Debian, Redhat, ... gebaut werden müssen da die ja meist speziell für
einen Distributiom per Paketmanager verteilt werden.
Bei Eclipse z.B. gibt es auch verschiedene "Versionen" trotzdem kannst
du das Programm an sich auch von der Kommandozeile oder man könnte es
sogar per doppelklick auf ein Jar starten, trotzdem erwartet der
"normalo" nun mal eine Exe/Bin/...
Rolf Magnus schrieb:> Ja, toll
Ja was erwartest du denn? DIe Programme sind nunmal per default auf
dieser speziellen Plattform übersetzt und angepasst, da kann aber doch
nun Java nix für, technisch spricht nichts dagegen die auch auf einer
Standard VM laufen zu lassen, du darfst dann halt nicht der Runtime
(also Android Spezifisches) nutzen, genauso wie du unter Windows nicht
ohne weiteres eine speziell für Linux übersetze Lib 1:1 nutzen kannst.
Hier im Thread ging es aber ja nun auch um OO für C im Umfeld von
(kleinen) Mikrocontroller, da ist wohl weder Java noch Qt eine Option...
Läubi .. schrieb:> Rolf Magnus schrieb:>> So komfortabel finde ich das irgendwie nicht>> Man kann es sich natürlich auch immer zurechtreden... es mag ja solche> Konfigurationen geben, genauso gibt es auch C++ Programme die nur für> Windows kompiliert vorliegen, Standard ist das bei Java nicht und zu> sagen alle Programme seien so ist schlich falsch.
Ich sagte ja explizit, daß es die waren, mit denen ich bisher in Kontakt
gekommen bin. Ob diese zugegebenermaßen nicht sehr große Auswahl
repräsentativ ist, weiß ich nicht.
> Genauso könnte ich argumentieren, das ja alle Tools 'speziell' für> Debian, Redhat, ... gebaut werden müssen da die ja meist speziell für> einen Distributiom per Paketmanager verteilt werden.
Bei denen behauptet aber im Gegensatz zu Java auch keiner, daß das nicht
so sei.
> Rolf Magnus schrieb:>> Ja, toll>> Ja was erwartest du denn?
Wenn die Plattformunabhängigkeit von Java immer so hochgelobt und als
ganz tolles Feature angepriesen wird, dann erwarte ich .... naja,
Plattformunabhängigkeit halt. Ich hab sie aber noch nicht gesehen.
> Hier im Thread ging es aber ja nun auch um OO für C im Umfeld von> (kleinen) Mikrocontroller, da ist wohl weder Java noch Qt eine Option...
Richtig. Ich wollte eigentlich anfangs auch nur meinen Senf dazu geben
zum Vorschlag, doch Java zu nehmen statt C++, weil das so
plattformunabhängig ist.
Leute, ihr streitet um des Kaisers Bart.
C++, C#, Python, Java, was denn noch....
Fakt ist, daß es bei fast allen hier im Forum üblichen uC so ist, daß
sie nur recht wenig RAM haben und der auszuführende Maschinencode von
der CPU aus einem Flashrom geholt wird. Die meisten wurschteln mit AVR's
und PIC's und kleineren ARM's ohne rausgeführten Bus herum und nur
wenige haben sowas wie einen 16 MB SDRAM an ihrem uC dran.
Was lehrt uns dies?
Nun, daß die Softwareschreiberei für diese Sorte von Rechnern eben deren
Eigenschaften berücksichtigen sollte. Mit C kann man keine echte
objektorientierte Schreibweise verwenden, weil C das nicht kann.
Mit C++ kann man das hingegen, aber man rennt beim Speicher gegen die
Wand: Der verfügbare RAM ist eher klein und das fällt einem beim
Instantiieren der diversen Objekte ganz schnell auf die Füße.
Nun wäre es ja nett, mit konstanten Objekten arbeiten zu können, die
schlichtweg im reichlich vorhandenen Flashrom angesiedelt sind, aber das
ist in C++ nun überhaupt nicht so vorgesehen. Egal wie man's dreht und
wendet, mit C++ oder Java oder Python und Konsorten kommt man nicht
weit, weil diese Sprachen und ihre zugehöriges Laufzeit-Environment
nicht für nen AVR oder PIC vorgesehen sind.
Was bleibt? Nun, es bleibt immer noch C, wo man sich dann auf eine Art
Bonsai-OOP verlegen kann, die mal eben gerade so umfänglich ist, daß sie
die anstehenden Probleme löst. Ich kenn das, hab sowas selber in
Benutzung. Man kann damit tatsächlich das Zeugs im ROM halten und es
trägt auch nicht sehr auf. Aber von der "hohen Schule" der OOP ist sowas
natürlich weit entfernt.
W.S.
C++ hat sinnvolle Features jenseits dynamischer Objekte. Warum sollte
man auf diese verzichten? Und wieso sollte man klassische OO Features
mit C simulieren. Hat man dadurch mehr RAM, daß man jeder Struktur auch
noch ein Set Funktionszeiger mitgibt?
Sinnvoll eingesetzte Template aber können generischen Source-Code mit
kompaktem Binary Vereinen. Wenn man's drauf hat!
W.S. schrieb:> Was lehrt uns dies?
Es lehrt uns, dass es immer wieder Jemanden gibt, der nach einer
ellenlangen Diskussion in voelliger Ingoranz des bereits Diskutierten
grandiosen Unsinn verzapft.
> Es lehrt uns, dass es immer wieder Jemanden gibt, der nach einer> ellenlangen Diskussion in voelliger Ingoranz des bereits Diskutierten> grandiosen Unsinn verzapft.
es lehrt uns, daß hier jeder seine Lieblingssprache C++ bis aufs Blut
verteidigen muß ... der Kandidat hat dann 100 Gummi-Punkte erzielt.
> Ihr macht mich hier alle feddich. Bald lerne ich dann doch lieber> Assembler.
kann auch nicht schaden auch da mal einen Blick drauf zu werfen.
Alles mal ausprobieren.
Mach doch die Sprache, die Dir selbst am meisten Spaß macht statt Dich
hier wie ferngesteuert reglementieren zu lassen.
c forever schrieb:>> Es lehrt uns, dass es immer wieder Jemanden gibt, der nach einer>> ellenlangen Diskussion in voelliger Ingoranz des bereits Diskutierten>> grandiosen Unsinn verzapft.> es lehrt uns, daß hier jeder seine Lieblingssprache C++ bis aufs Blut> verteidigen muß ... der Kandidat hat dann 100 Gummi-Punkte erzielt.>>> Ihr macht mich hier alle feddich. Bald lerne ich dann doch lieber>> Assembler.> kann auch nicht schaden auch da mal einen Blick drauf zu werfen.> Alles mal ausprobieren.> Mach doch die Sprache, die Dir selbst am meisten Spaß macht statt Dich> hier wie ferngesteuert reglementieren zu lassen.
Das wäre ja C++ gewesen, aber es gab hier immer wieder gute Gründe C als
erstes zu lernen (läuft sehr zäh, weil wenig Zeit).
Da ich die Meinung von K.H. Buchegger sehr schätze und er mir eben diese
Gründe bestätigte, bleibe ich dabei. Danach kommt C++ dran. Dazwischen
werde ich immer mal einen Blick in Assembler werfen, aber die kommt erst
nach C++ (also dann in fünf Jahren) so richtig dran.
Ich habe auch den Rat befolgt das nicht mehr auf dem µC zu lernen,
sondern erstmal nur am PC.
Schon seit früher Jugend habe ich sehr oft den Rat von den "Alten"
befolgt, weil man das Rad nicht immer wieder neu erfinden muss. Manche
Erfahrungen muss man selbst machen und davon gibt es immer noch genug.
> Das wäre ja C++ gewesen, aber es gab hier immer wieder gute Gründe C als> erstes zu lernen (läuft sehr zäh, weil wenig Zeit).> Da ich die Meinung von K.H. Buchegger sehr schätze und er mir eben diese> Gründe bestätigte, bleibe ich dabei. Danach kommt C++ dran. Dazwischen> werde ich immer mal einen Blick in Assembler werfen, aber die kommt erst> nach C++ (also dann in fünf Jahren) so richtig dran.
puh, typisch deutsch, alles genau geplant 5 Jahre im voraus. Ziemlich
langweiliger Weg. Dir ist nicht zu helfen.
> Ich habe auch den Rat befolgt das nicht mehr auf dem µC zu lernen,> sondern erstmal nur am PC.
?! Das spielt doch keine Rolle außer daß dem geringfügigen Aufwand an
Hardwarekosten für uC natürlich.
Heute ist das kein Argument mehr, weil die Kosten für
Mikrocontroller,etc. nicht mehr so ins Gewicht fallen wie früher.
> Schon seit früher Jugend habe ich sehr oft den Rat von den "Alten"> befolgt, weil man das Rad nicht immer wieder neu erfinden muss. Manche> Erfahrungen muss man selbst machen und davon gibt es immer noch genug.
damit bleibst Du dann mit Sicherheit auch bei den Altsprachen hängen
statt den eigenen Weg zu gehen - mein Herzliches Beileid schon jetzt.
c forever schrieb:> damit bleibst Du dann mit Sicherheit auch bei den Altsprachen hängen> statt den eigenen Weg zu gehen - mein Herzliches Beileid schon jetzt.
Kann man so nicht sagen. Klar hab ich mir vorgenommen in 5 Jahren so
programmieren zu können, dass ich alles das was ich mir mit mit µC bauen
will, auch programmieren kann.
Ich gehe keines Wegs den sturen Weg des Nachahmens, aber mir leuchteten
die Gründe ein und deshalb mach ich das so.
Außerdem glaube ich, dass µC's in Zukunft viel mehr grafisch
programmiert werden und das dann nur noch sehr wenig eigener Code nötig
ist.
Der Weg, so scheint mir, geht da hin.
Weißt du, ich habe viele Fehler im Leben nicht gemacht (aber immer noch
genug), gerade weil ich bestimmte Sachen nicht nach meinem Gusto gemacht
habe, sondern aus Erfahrungen anderer gelernt habe.
Da braucht dir gar nichts leid zu tun. Denn am Ende war es immer meine
eigene Entscheidung.
Werde nun 50 und bin bisher für mich damit gut gefahren.
> Weißt du, ich habe viele Fehler im Leben nicht gemacht (aber immer noch> genug), gerade weil ich bestimmte Sachen nicht nach meinem Gusto gemacht> habe, sondern aus Erfahrungen anderer gelernt habe.
Empfehlungen kann man sich anhören und insbesondere sollte man die
Hintergründe nicht vergessen, warum der eine so, der andere so
argumentiert - das scheinst Du komplett ausgeblendet zu haben; den
Fehler hab ich mit 18 auch mal gemacht (ist schon lange her); daraus hab
ich wenigstens meine Lehre gezogen.
Im Grunde genommen weißt Du selbst nicht was Du eigentlich willst (siehe
oben) und machst das nur, weil Du denkst Karl-Heinz wird schon recht
haben ... mhm ): na dann mach das so.
> Da braucht dir gar nichts leid zu tun. Denn am Ende war es immer meine> eigene Entscheidung.> Werde nun 50 und bin bisher für mich damit gut gefahren.
tja, was soll ich dazu sagen.
Betreibst Du das hobbymäßig oder beruflich?
Wenn nur hobbymäßig, dann würde ich mir C++ nicht mehr antun (jedenfalls
nicht in dem Umfang, den Du anstrebst) - dann besser Lazarus oder
irgendwas anderes exotisches, gibt doch genug Auswahl; die sind nämlich
auch nicht schlechter im Ergebnis und am Ende einfacher in Bezug auf
das, was insbesondere Du programmieren willst!
Da hast Du mehr von, weil Du den C++ Zenit a la Karl-Heinz nicht mehr
erreichen kannst und es genügend gute und bessere Alternativen je nach
Anwendung gibt ... das nennt man Entwicklung der Programmsprachen, es
gibt keinen Stillstand ... aber ist nur meine bescheidene Meinung, mach
wie Du denkst.
Mein Tip wär Objectiv C wegen der Smartphones; das reicht für
Mikrocontroller sowieso.
c forever schrieb:> Mein Tip wär Objectiv C wegen der Smartphones; das reicht für> Mikrocontroller sowieso.
Für welche Mikrocontroller denn? Für das, was man so leichthin am PC
hinschreiben kann, braucht es RAM, RAM und (welch Wunder) nochmal RAM.
Heutige PC's haben davon bis zum Abwinken, aber selbst auf aktuellen
ARM-Prozessoren hast du oft genug mal eben nur 4..16 K davon - im
Gegensatz zum Flashrom, der oftmals bis zu 1 MB groß ist. Da ist einfach
ne andere Herangehensweise nötig, die die Hardware berücksichtigt - und
nicht eben nur "Icke nehm C++ weil icke da so schön und elegant dies und
das hinschreiben kann".
W.S.
c forever schrieb:> Im Grunde genommen weißt Du selbst nicht was Du eigentlich willst (siehe> oben) und machst das nur, weil Du denkst Karl-Heinz wird schon recht> haben ... mhm ): na dann mach das so.
Da irrst du dich gewaltig. Ich weiß ganz genau was ich will und das ist
Dinge bauen mit Mikrocontrollern. Angefangen habe ich mit Arduino und
schon nach kurzer Zeit ein Projekt fertig gestellt. Das reicht mir
nicht. Ich will mehr wissen. Außerdem "tue ich mir nicht C++ an",
sondern lerne das (nach dem C) ganz freiwillig und gern. Wollte ja sogar
zuerst mit C++ anfangen, weil mir das alles so verständlich schien,
quasi wie für mich gemacht. Aber der Rat von vielen hier und auch die
Argumente dagegen, habe ich für mich abgewogen und mich dann entschieden
erst C zu lernen.
Dass sich alles weiter entwickelt, auch die Programmiersprachen, das ist
mir bewusst. Ich lese sehr viel, lerne ständig neue Sachen, nicht weil
ich muss, sondern weil mir das viel Spaß macht und ich das auch brauche.
Die Elektronik, gerade die Mikrocontroller finde ich so faszinierend und
es ist ein fast unerschöpfliches Thema.
Also wenn ich in fünf Jahren C++ kann (wovon du ganz sicher ausgehen
kannst), alles das schon entwickeln kann, was mir so einfällt, dann ist
noch lange nicht Schluss, dann lerne ich weiter und weiter.
Ein weiterer Vorteil an diesem Gebiet, ich kann völlig vom Wetter
unabhängig und nahezu an jedem Ort und zu jeder Zeit mich mit diesen
Dingen beschäftigen. Bei meinen Sportarten bin ich immer sehr wetter-
und ortsabhängig.
Da ist jeder sicher unterschiedlich "gestrickt". Der eine sagt sich,
dass er mit der Rente nichts mehr machen muss und ist froh nicht mehr
lernen zu müssen. Der andere meldet sich für ein Studium an, weil er mit
der Rente endlich Zeit dafür hat. Ich gehöre da wohl eher zum letzteren
Typ.
Nichts, aber auch rein gar nichts was ich je lernte war vergebens. Ob es
die Berufe waren, die ich lernte oder die vielen zusätzlichen
Qualifikationen, ich hab aus allem was für mich mitgenommen.
> Also wenn ich in fünf Jahren C++ kann (wovon du ganz sicher ausgehen> kannst), alles das schon entwickeln kann, was mir so einfällt, dann ist> noch lange nicht Schluss, dann lerne ich weiter und weiter.> Ein weiterer Vorteil an diesem Gebiet, ich kann völlig vom Wetter> unabhängig und nahezu an jedem Ort und zu jeder Zeit mich mit diesen> Dingen beschäftigen. Bei meinen Sportarten bin ich immer sehr wetter-> und ortsabhängig.
Das heißt, Du bist in einer extrem komfortablen Lage, Glückwunsch.
Dein 5 Jahresplan Ansatz, da fällt mir nur die DDR zu ein ... okay,
anderes Thema, lassen wir das lieber.
Wenn ich an Deiner Stelle wäre, würde ich mehr aus der verbleibenden
Lebenszeit machen.
> Da ist jeder sicher unterschiedlich "gestrickt". Der eine sagt sich,> dass er mit der Rente nichts mehr machen muss und ist froh nicht mehr> lernen zu müssen. Der andere meldet sich für ein Studium an, weil er mit> der Rente endlich Zeit dafür hat. Ich gehöre da wohl eher zum letzteren> Typ.> Nichts, aber auch rein gar nichts was ich je lernte war vergebens. Ob es> die Berufe waren, die ich lernte oder die vielen zusätzlichen> Qualifikationen, ich hab aus allem was für mich mitgenommen.
dazu fällt mir nur dieser Bergsteiger ein, der mit 83 Jahren? zum
dritten Mal den Mount Everest "bezwungen" hat ... ja, solche Leute gibt
es - vom eigenen Ego zerfressen.
Tja, mittlerweile zweifele ich nicht mehr an Darwin Evolutionstheorie.
> Für welche Mikrocontroller denn? Für das, was man so leichthin am PC> hinschreiben kann, braucht es RAM, RAM und (welch Wunder) nochmal RAM.> Heutige PC's haben davon bis zum Abwinken, aber selbst auf aktuellen> ARM-Prozessoren hast du oft genug mal eben nur 4..16 K davon - im> Gegensatz zum Flashrom, der oftmals bis zu 1 MB groß ist. Da ist einfach> ne andere Herangehensweise nötig, die die Hardware berücksichtigt - und> nicht eben nur "Icke nehm C++ weil icke da so schön und elegant dies und> das hinschreiben kann".>> W.S.
siehe hier: http://de.wikipedia.org/wiki/Objective-C
Das heißt, ich kann den uC auch komplett in C programmieren.
Wenn ich dann merke es reicht nicht mehr, dann kann ich immer noch auf
Objektiv rüberschwenken - die vielleicht bessere Lösung für den TO
Plong A., der ja ein C Programm mit OOP erweitern will.
Ob das unbedingt sinnvoll ist und leichter ist als das Programm komplett
neu zu schreiben, ist eine ganz andere Frage - prinzipiell geht das aber
mit C.
Und ich nehme mal an, deshalb ist Objektiv C so beliebt - denn das hier:
http://www.cs.rit.edu/~ats/books/ooc.pdf
ist wohl etwas komplizierter ?!
In C++ müßte der TO die Unterschiede zwischen C und C++ kennen, um das
Programm dann komplett umzuschreiben. Das kostet Zeit, da man die
Möglichkeiten und Grenzen beider Sprachen kennen muß und das nicht immer
so glatt geht, wie es auf den ersten Blick scheint.
Ich geb Dir allerdings recht; knappe Speicherresourcen - da würde ich
versuchen auf OOP zu verzichten. Es geht ja auch ohne.
c forever schrieb:> Wenn ich an Deiner Stelle wäre, würde ich mehr aus der verbleibenden> Lebenszeit machen.
So nun will ich mal zurück schießen.
Sicher machst du das beruflich und es kotzt dich sicher an. Aber warum
gehst du nicht raus aus deinem Keller und sitzt statt dessen wieder am
Sonntag am Computer?
Ich sitze (oder liege:-)) hier, weil mir das Spaß macht.
Wenn meine Zeit das erlaubt und genügend Wind ist, dann gehe ich surfen.
Weißt du, vor Scheidung habe ich teilweise im Schnitt 15/7 gearbeitet.
Was du nicht zu verstehen scheinst, dass es mir -mir persönlich, keinem
anderen muss das so gehen- Spaß macht all diese Dinge noch zu lernen.
Wenn ich Lust dazu haben würde, noch fit genug sein werde, wer weiß,
vielleicht steige ich dann mit 93 noch den Berg rauf. Aber lieber fahre
ich ihn runter.
Wieso gibst du dir selbst diesen Namen. So richtig verstehe ich nicht
wie du tickst, aber im Gegensatz zu dir, ich lasse andere Menschen so
sein wie sie sind und blicke nicht herab auf sie, weil sie andere Sachen
machen und anders sind.
Du mit deinen Scheuklappen kannst ja leider nur den Blick nach unten
oder oben sehen. Leider schaust du, meiner Meinung nach, nur noch nach
unten. Dass dir der Blick für die Seiten fehlt, das ist sehr schade und
es tut mir wahnsinnig leid für dich.
Wenn du dann schon Darwin ran ziehst, dann ist ja klar, dass du keine
Chance auf diesem Planeten mehr hast.
Du bist sicher ein ganz schlaues Kerlchen und bestimmt gut im
Programmieren und allem was du so machst, aber das ist es dann wohl
schon.
Schau dir mal "Good Will Hunting" an und besonders die Stelle wo Robin
Williams den Unterschied zwischen dem angelesenem Wissen und dem
erlebten Erfahrungen erklärt.
Vielleicht verstehst du dann, warum einer mit 83 noch auf den Berg
steigt.
Obj-C auf einem µC => geht, aber... - Vor ein paar Jahren habe ich mal
für einen Cortex-M3 ein kleines Programm in Obj-C geschrieben. Hat alles
wunderbar gepasst (kompiliert mit GCC, Sprachunterstützung C, C++ u.
Obj-C), nur der Platz im µC nicht. Bei Obj-C hat man eine
Laufzeitumgebung und diese braucht Platz und bei der Ausführung Zeit.
Wer Teile der OOP auf einem µC nutzen will, der ist mit C++ ganz gut
beraten! Vor allem weil man auch C-Code ganz leicht wieder verwenden
kann.
> Obj-C auf einem µC => geht, aber... - Vor ein paar Jahren habe ich mal> für einen Cortex-M3 ein kleines Programm in Obj-C geschrieben. Hat alles> wunderbar gepasst (kompiliert mit GCC, Sprachunterstützung C, C++ u.> Obj-C), nur der Platz im µC nicht. Bei Obj-C hat man eine> Laufzeitumgebung und diese braucht Platz und bei der Ausführung Zeit
Das ist schon Jahre her wie Du sagst, heute kann das schon wieder anders
aussehen - und wenn Du weiter oben schaust
http://www.tiobe.com/index.php/content/paperinfo/t ... wird das ja
irgendwelche tiefergehenden Gründe haben ?!
Wenn alles so einfach ist, wieso wird dann nicht alles komplett auf C++
umgeschrieben, was vorher in C war, in Zeiten großer
Speicherkapazitäten, usw.
> Wer Teile der OOP auf einem µC nutzen will, der ist mit C++ ganz gut> beraten! Vor allem weil man auch C-Code ganz leicht wieder verwenden> kann.
bei einer Seite Quellcode, okay; mach Deine Wiederverwertbarkeit mal bei
30 oder mehr Seiten Quellcode - bestes Beispiel für Wiederverwertbarkeit
ist http://www.around.com/ariane.html
So ganz scheint das dann doch nicht zu funktionieren.
c forever schrieb:> Das ist schon Jahre her wie Du sagst, heute kann das schon wieder anders> aussehen - und wenn Du weiter oben schaust
Und zukünftig ist es schon vor der Ausführung fertig. Gewissen Dinge
brauchen Zeit/Platz und können nicht weiter vereinfacht/optimiert
werden.
Wow was für einen Sprint. Von Platz 24 auf 16! Die BASH ist ja
gewaltig am Aufholen!
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.htmlc forever schrieb:> bestes Beispiel für Wiederverwertbarkeit> ist http://www.around.com/ariane.html
Ohne nur eine Zeile von dem von dir geposteten Artikel zu lesen, es gibt
sicherlich zig Seiten die gegen/für sprechen...
> Aber warum> gehst du nicht raus aus deinem Keller und sitzt statt dessen wieder am> Sonntag am Computer?> Ich sitze (oder liege:-)) hier, weil mir das Spaß macht.
wo bist Du denn gerade? In Südfrankreich? Draußen regnet es und es ist
kalt!
> Weißt du, vor Scheidung habe ich teilweise im Schnitt 15/7 gearbeitet.> Was du nicht zu verstehen scheinst, dass es mir -mir persönlich, keinem> anderen muss das so gehen- Spaß macht all diese Dinge noch zu lernen.> Wenn ich Lust dazu haben würde, noch fit genug sein werde, wer weiß,> vielleicht steige ich dann mit 93 noch den Berg rauf. Aber lieber fahre> ich ihn runter.
mach, was Du willst, davon kann ich Dich nicht abhalten.
Hast Du schon mal was von Effizienz beim Lernen gehört ?
Darum ging es hier unter anderem!
> Wieso gibst du dir selbst diesen Namen. So richtig verstehe ich nicht> wie du tickst, aber im Gegensatz zu dir, ich lasse andere Menschen so> sein wie sie sind und blicke nicht herab auf sie, weil sie andere Sachen> machen und anders sind.
Namensgebung vielleicht aus Spaß oder aus anderen Gründen, letztendlich
völlig egal.
Nein, völlig falsche Analyse Deinerseits, von mir aus kannst Du und
jeder andere machen was er immer er will und sei es noch so bescheuert -
nur darfst Du dann auch nicht über meinen Sarkasmus aufregen.
Wenn ich Denkanstöße gebe und absolute Ignoranz die Antwort ist, dann
ist Sarkasmus eine natürliche Reaktion ... ändern oder verwerfen kann
und will ich nichts, ich bin ja kein Zyniker.
> Du mit deinen Scheuklappen kannst ja leider nur den Blick nach unten> oder oben sehen. Leider schaust du, meiner Meinung nach, nur noch nach> unten. Dass dir der Blick für die Seiten fehlt, das ist sehr schade und> es tut mir wahnsinnig leid für dich.
ich schau überall hin, vor allen nach oben, denn da gefällts mir am
besten - wieder also eine falsche Analyse Deinerseits.
> Wenn du dann schon Darwin ran ziehst, dann ist ja klar, dass du keine> Chance auf diesem Planeten mehr hast.
Dann wird es Zeit für den nächsten Planeten, zu schade, daß ich das
zeitlich wohl nicht mehr erleben werde - die technische Entwicklung
bremst sich leider von selbst aus, normal auf diesen Planeten.
> Schau dir mal "Good Will Hunting" an und besonders die Stelle wo Robin> Williams den Unterschied zwischen dem angelesenem Wissen und dem> erlebten Erfahrungen erklärt.
kenn ich nur vom Titel, danke für den Tip. Schaue ich mir mal an.
> Vielleicht verstehst du dann, warum einer mit 83 noch auf den Berg> steigt.
Muß man Wahnsinn und potentielle Selbstmörder verstehen?
Nur gut, daß dieser Mensch nicht in die Politik gegangen ist und
stattdessen auf einen trostlosen Berg.
PS: Mit einem Fallschirm oder abseilen am Hubschrauber wäre er schneller
oben gewesen :-)
> Und zukünftig ist es schon vor der Ausführung fertig. Gewissen Dinge> brauchen Zeit/Platz und können nicht weiter vereinfacht/optimiert> werden.
hat sich Microsoft auch gesagt und deshalb C# kreiert und laut Aussage
von Microsoft ist C# besser geeignet für kleinere und mittlere
Programme.
Die Entwicklung bleibt nicht stehen, auch wenn sich das viele
Informatiker aufgrund Ihres gewachsenen Wissens wünschen würden.
> Wow was für einen Sprint. Von Platz 24 auf 16! Die BASH ist ja> gewaltig am Aufholen!> http://www.tiobe.com/index.php/content/paperinfo/t...
das zeigt nur, daß totgesagte Sprachen ein Revival haben können, gleiche
Entwicklung übrigens auch bei Basic.
Es kommt immer darauf, was ich programmieren will und wie die Vorgaben
sind ... und die sind gerade im privaten Bereich weitaus freizügiger als
im Businessbereich.
Sich selbst Fußfesseln anzulegen ist schon reichlich dumm - okay,
Ansichtssache.
c forever schrieb:>> Und zukünftig ist es schon vor der Ausführung fertig. Gewissen Dinge>> brauchen Zeit/Platz und können nicht weiter vereinfacht/optimiert>> werden.> hat sich Microsoft auch gesagt und deshalb C# kreiert und laut Aussage> von Microsoft ist C# besser geeignet für kleinere und mittlere> Programme.> Die Entwicklung bleibt nicht stehen, auch wenn sich das viele> Informatiker aufgrund Ihres gewachsenen Wissens wünschen würden.
Und trotzdem passt des ned drauf. Da kann wer auch immer sagen was er
möchte, es wird sich demnächst nichts ändern. Mit der Zeit sicherlich
schon, aber das dauert...
c forever schrieb:>> Wow was für einen Sprint. Von Platz 24 auf 16! Die BASH ist ja>> gewaltig am Aufholen!>> http://www.tiobe.com/index.php/content/paperinfo/t...> das zeigt nur, daß totgesagte Sprachen ein Revival haben können, gleiche> Entwicklung übrigens auch bei Basic.
Ich weiß nicht wie der TIOBE Index erhoben wird und mir ist es auch
egal. Jedenfalls waren und sind Shell-Scripte nicht tot, sondern täglich
im Einsatz. Das nicht viel Leute ein Shell-Script schreiben, kann ich
sehr gut nachvollziehen.
Mein Haupteinsatz von Shell-Scripte wird von der Schreibfaulheit und der
Vergesslichkeit angetrieben. In seltenen Fällen für systemrelevante
Dinge.
c forever schrieb:>> Wer Teile der OOP auf einem µC nutzen will, der ist mit C++ ganz gut>> beraten! Vor allem weil man auch C-Code ganz leicht wieder verwenden>> kann.> bei einer Seite Quellcode, okay; mach Deine Wiederverwertbarkeit mal bei> 30 oder mehr Seiten Quellcode - bestes Beispiel für Wiederverwertbarkeit> ist http://www.around.com/ariane.html> So ganz scheint das dann doch nicht zu funktionieren.
Es gibt Situationen, wo man sein Programm von Grund auf neu
entwickelt/schreibt. Natürlich möchte man seinen alten Code gerne
weiterverwenden. Das funktioniert auch nicht immer so einfach wie man es
möchte...
Thread beobachten
Seitenaufteilung abschalten