www.mikrocontroller.net

Forum: Ausbildung, Studium & Beruf C++ oder die lukrativen Lügen der Softwareindustrie........


Autor: Theo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich lese grade weiter unten das ein frischer Absolvent,  wegen C++
Probleme hat. Mich wundert das nicht, denn ich hatte auch welche damit,
denn diese Terrorshow in Sachen C++ Werbung konnte ich nie
nachvollziehen, wo es hieß Wiederverwendbarkeit usw.

Als ob die Altprogrammierer alle blöd waren und ihre Programme und
Bibliotheken weggeworfen haben ?

Fakt ist, in vielen Compilern wurde bis tief in die 90er Jahre C++
direkt in Ansi-C umgewandelt also reine Textverarbeitung betrieben,
bevor dann der normale C-compiler drüber ging. der haken dabei ist, das
C++ doof ist, also nicht das an optimierunen bringen kann wie ein Mensch
der in C handverlesen programmiert und somit einen Molloch an Code
erzeugt. Man sieht das an der KDE unter Linux, wobei die Ladezeiten im
Regelfall beim Erststart oft doppelt so hoch sind wie bei einem reinen
C-Programm.

Beispiele:  (unter Linux)

KPDF und zum Vergleich das schnelle XPDF, beides PDF-Reader, wobei KPDF
auf dem SoureCode von XPDF basiert allerding nur den Oberflächen Molloch
des KDE-Styles drüberzieht wären XPDF die GTk+ als Grafikoberfläche
benutzt. Testet das mal auf nem älteren Rechner aus (PII - 400 MHz -
128 MB), da fällt das sehr dramatisch auf.

Ausserdem sind C++ - Klassen nix anderes als Strukturen in C , nur die
Reihenfolge in den Zugriffsrechten ist anders, Structs sind immer
public beim Erstellen und müssen abgedichtet werden, während Klassen
immer private sind und somit nach aussen gelockert werden müssen.

Durch Friendfunktionen wird das Konzept der Verkappselung ausgehöhlt,
was ein Wiederspruch der Objektorientierung in sich ist. Vererbung von
Klassen ist nix anderes als Copy+Paste von Strukturen in C.

Klassenfunktionen (Methoden) die ja eigendlich nur(!) in die Klasse
gehören sollten, sind ebenfalls Betrug! Diese Dinger werden einfach in
einem anderen (internen) Modul (im Compilerlauf) gespeichert und in
diesem Modul als static deklariert, was verhindert das der Linker diese
routinen den anderen Modulen bekannt macht und somit dieser private
Charakter nur vorgetäuscht wird, denn variablen und funktionen die
static deklariert werden gab es ja schon im guten alten C denn
ansonsten würde die umwandlung von C++ nach C wie bei vielen Compilern
die bis ende der 90er auf dem Marktwaren nicht funktionieren.

Was glaubt ihr wohl warum diese C++ Fetischisten empfehlen für jede
Klasse eine eigene Header-Datei anzulegen ?

Eben, weil genau das oben beschriebene Konzeppt dahinter steckt und auf
diese weise dem HyroglyphenCompiler (C++) die arbeit etwas leichter
gemacht wird......des weitren möchte ich hier mal kurz zeigen, wie man
Objektorientiert Klassen anlegt.  dazu bedarf es kein C++ !

Objektorientierte Sichtweise kann man besonders schnell lernen, wenn
man schon mal auf irgend einer Relationalen Datenbank mit SQL
gearbeitet hat

Jede Tabellendeklaration der Datenbank wäre in C++ ein Klasse.

Tabellen werden verknüpft um Speicherplatz aufgrund Redundanzen zu
sparen. Beispiel:

Person( personalnr. , name, vorname , alter);

Stadt( plz , name );

...ist sinniger als jedes mal "Dortmund" in einer anderen Tabelle
z.b.

Adresse( plz , strasse ) ;

....statt plz schreiben zu müssen, denn es reicht die plz vollkommen
aus.


Verknüpft man nun Tabellen miteinander aus logischen gründen gibt es 2
Fälle:

a)
Anhand der plz kann man beide Tabellen verknüpfen wenn nix weiter
benötigt wird.

Personaltab( personalnr , plz )

um alle daten (indirekt) zu adressieren.


b)
Will man zur adresse eine Eigenschaft hinzubasteln z.B

Tätigkeit( personalnr , "terrorist" )

würde man eine neue Tabelle Tätigkeit erstellen müssen, in C++ wäre das
eine neue Klasse die von 2 anderen Klassen erbt und dann um die
eigenschaft wie hier art der Tätigkeit -terrorist- erweitert wird.

Das ist eigendlich alles.

Diese OOP Geschichte ist das selbe in grün, nur es werden alte
Eigenschaften unter komplizierten Namen verkauft um die potentiellen
Anwender (Entwicker)
mit einer angeblich neuen Technik zu narren, die im Kern der Sache
alles andere als neu ist.

Was meine meinung betrifft, es geht nix über reines C !!!!!!
Ausnahme wäre vieleicht ADA, wegen der Strenge.

Kleine Objectcodes, praktisch und sehr sehr schnell.

Bis auf Windows kenne ich kein Betriebssysem was wesentlich in C++
gebaut ist ?

Alles was nicht in C++ gebaut ist, ist wesentlich schneller kleiner und
effektiver.

Ach so ich vergaß - Operatoren-Überladung:

Das ist ja an sich ne geile Sache, nur meine lieben
Informatikerkollegen haben es übertrieben. Alles was nicht niet- und
nagelfest war wurde addiert, subtrahiert, multibliziert und dividiert,
z.B. Bäume, Listen, Stacks, Arrays  usw.

Ob die artverwandten Mathematiker solche Operationen überhaupt
genehmigt haben, damit sie einen Sinn machen darauf wurde gepfiffen.
Als Java raus kam hat SUN wohl bewusst auf diese Überladung
verzichtet........

Soll heissen, wenn die Katze nicht im Hause ist, tanzen die Mäuse auf
dem Tisch. Und so war es auch als dieser Hype in sachen C++ in den
90ern gemacht wurde.

Was ich lustig finde ist, es gibt ja echte Experten in C++ so auch
welche aus meinem Studium. Nur ich weis acht nicht worauf man da stolz
sein kann ?

Darauf das man echte Textverarbeitung kann ?

Textverarbeitung die mittels PreProzesser-Programm Hyroglyphen in
Ansi-C umwandelt das dann compiliert wird ?

Ich sage nur, alles das kann man auch in C machen, nur wesendlich
effektiver und vor allem viel schneller in sachen speed beim
Programmlauf.

Übrigens ich möchte um Gottes willen nicht das mir einer das hier alles
glaubt.
Wer zweifelt, solle mal im Buch:

"Design and implementation of C++" nachsehen hier:

http://www.research.att.com/~bs/homepage.html

Theo

Autor: ---- (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Übrigens ich möchte um Gottes willen nicht das mir einer das hier
> alles glaubt.
Ich hatte anfangs noch gezweifelt, ob das jemand ernst meinen kann,
aber zum Glück kommt ja unten die Auflösung.

Ansonsten hast du es den C++-Programmierern aber gezeigt. Jetzt wissen
die endlich auch, dass am Ende nur Maschinencode rauskommt den man auch
mit C-Programmierung erreichen kann.

Aber ich persönlich bin ja der Meinung, dass alles was über Assembler
hinausgeht, nur für Warmduscher ist - schliesslich kann ich das Ganze
auch in Assembler realisieren.

----, (QuadDash).

Autor: Tobias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wobei reines Assembler nicht wirklich viel bringt, wenn man
ANwendungsprogramme erstellen möchte. Beispiel Texteditor: du wirst
kaum ein Unterschied merken zwischen der C-Version und der reinen
Assembler-Version.

Autor: Tobias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
<DELETE>
.
</DELETE>

merken.

Autor: Theoid (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Vererbung von Klassen ist nix anderes als Copy+Paste von Strukturen
> in C.

Du hast ja in vielerlei Themen die Weisheit mit Löffeln gefressen, aber
mit solchen bekloppten Statements zeigt sich wieder, was für ein Held du
bist.

An welcher Hochschule haben sie dich eigentlich bis zum Abschluss
studieren lassen?

Autor: Ralf Engels (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wow.

>Diese OOP Geschichte ist das selbe in grün, nur es werden alte
>Eigenschaften unter komplizierten Namen verkauft um die potentiellen
>Anwender (Entwicker)
>mit einer angeblich neuen Technik zu narren, die im Kern der Sache
>alles andere als neu ist.

Da hast Du sicher Recht. Allerdings werden bei OOP wenigstens die
Eigenschaften beim Namen genannt.
Brechen kann ich die aber überall. Ob ich jetzt eine C-header Datei
habe, die überall benutzt wird, oder eine Klasse mit Singleton-Pattern
implementiere und dann immer wieder ranziehe.
Eine Kapselung ist dann nicht mehr gegeben.

>Das ist ja an sich ne geile Sache, nur meine lieben
>Informatikerkollegen haben es übertrieben.

Das haben sie manchmal. Besonders den Shift-operator zur Ausgabe zu
misbrauchen STDOUT << "hallo" ist nicht nett.
An anderen Stellen fehlt es aber manchmal schon. Desshalb würde ich 3D
algorithmen doch lieber in C++ machen.

>Objektorientierte Sichtweise kann man besonders schnell lernen, wenn
>man schon mal auf irgend einer Relationalen Datenbank mit SQL
>gearbeitet hat

Hä? Was hat denn das damit zu tun?


Also ich schreibe gerne sowohl C, wie auch C++. Auf den Anwendungsfall
kommt es halt an.
Wer Objekte in C nachbaut, der macht es sich schwer (GTK). Es geht
aber. Wer das gleiche mit Tabellen probiert, der landet dann bei so
etwas: call_object( Object obj, int function, long p1, long p2, long
p3)
Hab ich schon gesehen. Ist Super zum debuggen.

Wer von C++ keine Ahnung hat, der verbricht so etwas wie z.B. Symbian,
wo es so etwa zehn verschiedene String Objekte gibt. Verwirrung ist
vorprogrammiert.

Wer es aber richtig macht, der hat an C++ seine echte Freude. Kurz,
prägnant und weniger Gefahren eine Memory Leak zu erzeugen.
Warum? Wegen Destruktoren und der Möglichkeit komplexe Strukturen
komplett über den Stack zu handlen.

Und hier noch mein Vergleich:
Qt und GTK
Eines davon ist in C++. Keines ist viel schneller, kleiner oder besser.

Autor: Theo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> Vererbung von Klassen ist nix anderes als Copy+Paste von Strukturen
>> in C.

>Du hast ja in vielerlei Themen die Weisheit mit Löffeln gefressen,
aber
>mit solchen bekloppten Statements zeigt sich wieder, was für ein Held
du
>bist.

Bevor du in dieser Hinsicht die Klappe öffnest, solltest du lieber mal

einen Blick hier rein werfen:

"Design and Implementation of C++"

http://www.research.att.com/~bs/homepage.html

Falls dir das nicht gefällt, dann kannst du auchmal hier nachsehen:

http://www.amazon.de/Objektorientiertes-Programmie...

Trotz der Lobeshymnen die da ein Kritiker auf C++ hält, gabs von
Josuttis um 3/1996 einen Artikel in der Zeitung -Objekt-Spektrum- der
so hieß wie:

"C ++ Die wahrheit über Vererbung" wo er nicht unbedingt ein all zu
gutes Haar an der Sprache lies.

Und was Vererbung betrifft, was ist daran falsch wenn ich sage ist nix
andertes als copy + paste ?

Das etwa ein Konstruktor da ist, der eigendlich nix anderes ist als
eine Init-Routine die ggf. die Klasseninstanz füllt und die man
letztlich auch ohne automatismus schreiben kann.......?

An welcher Hochschule haben sie dich eigentlich bis zum Abschluss
studieren lassen?

Dortmund

Interessant fand ich allerdings das es in Dortmund im Indupark (nähe
Uni) eine schon seit vielen Jahren erfolgreiche Firma gibt, deren Chef
mir mal sagte das es viele C++ Programierer gäbe, die kein C könnten un
beim Umstieg sehr große Probleme hätten, wenn z.B. ein C-projekt betreut
werden müsste. Na ja, iss ja auch was anderes wenn man von ner
Pre-Prozessor-Textverarbeitung auf ne eigendliche Programmiersprache
umsteigt.......:-)

Aber über Dogmatiken kann man bekanntlich streiten........

Theo

Autor: Theo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Da hast Du sicher Recht. Allerdings werden bei OOP wenigstens die
>Eigenschaften beim Namen genannt.
>Brechen kann ich die aber überall.

Aber ganau  das solle ja verhindert werden, zumindest wesentlich.
Ich denke aber mal das eine Sprache wie C++ wohl keinen Apell
an die vernunft eines programmieres setzen kann, was ja eigendlich
beabsichtigt war.

>Das ist ja an sich ne geile Sache, nur meine lieben
>Informatikerkollegen haben es übertrieben.
>Das haben sie manchmal. Besonders den Shift-operator zur Ausgabe zu
>misbrauchen STDOUT << "hallo" ist nicht nett.

Stimme ich dir zu.

>An anderen Stellen fehlt es aber manchmal schon. Desshalb würde ich
3D
>algorithmen doch lieber in C++ machen.


Weis nicht, seit C99 ist Operatorenüberladung auch in C drin, ebenso
dynamische Arrays.

Davon ab, macht C++ bei einer Methode ja nix anderes als heimlich
hinter Programmierers Rücken die Parameterliste der Methode zu öffnen
und dann an erster oder letzter stelle, den Selfpointer mit dem Typ der
Klasse einzufügen, wobei man im Programmcode natürlich nix davon sieht.

>>Objektorientierte Sichtweise kann man besonders schnell lernen, wenn
>>man schon mal auf irgend einer Relationalen Datenbank mit SQL
>>gearbeitet hat

>Hä? Was hat denn das damit zu tun?

Es kommt auf die Sichtweise an. Klassen ann man auch als Entitäten
sehen, so wie:

class Person
   {
    Eigenschaften
    .....
    Methoden(...)
   }

Genau so entwirft man ein betriebliches Informationssystem, durch
geeignet verknüpfung von Entitäten. Die Denke ist dabei die selbe, nur
das man nicht Tabelle sagt, sondern Klasse, statt Verknüpfung nennt man
das dann in C++ Vererbung. Natürlich ist die Denke nicht 100% kompatibel
aber 80-90% sind dabei allemal drin.


>Also ich schreibe gerne sowohl C, wie auch C++. Auf den
Anwendungsfall
>kommt es halt an. Wer Objekte in C nachbaut, der macht es sich schwer
>(GTK). Es geht aber.


Und der Betreffende weis was er tut !!!

Wer das gleiche mit Tabellen probiert, der landet dann bei so etwas:

call_object( Object obj, int function, long p1, long p2, long p3)
Hab ich schon gesehen. Ist Super zum debuggen.

Funktionen als Parameter zu übergeben kommt in C schon ewig vor.
und der Parameter "Object obj" ist genau das was der c++ compiler
hinter vorgehaltener Hand macht in dem er die parameterliste erst beim
Compilerlauf erweitert.


>Wer von C++ keine Ahnung hat, der verbricht so etwas wie z.B.
Symbian,
>wo es so etwa zehn verschiedene String Objekte gibt. Verwirrung ist
>vorprogrammiert.


>Wer es aber richtig macht, der hat an C++ seine echte Freude. Kurz,
>prägnant und weniger Gefahren eine Memory Leak zu erzeugen.


Ok, da gebe ich dir recht, aber da liegt aber auch der grund warum das
ding so einen fetten Overhead erzeugt.


>Warum?
>Wegen Destruktoren und der Möglichkeit komplexe Strukturen
>komplett über den Stack zu handlen.


Ja ja, bis das Ding platzt....den stack sollte man eigendlich sparsam
benutzen, aber vieleicht liegt das daran das ich noch aus der Gilde der
Speichersparer komme.


>Und hier noch mein Vergleich:  Qt und GTK
>Eines davon ist in C++. Keines ist viel schneller, kleiner oder
besser.


Von GTK hatte ich mir allerdings auch mehr Geschwindigkeit erhofft.
auch was Platzbedarf ausmacht, ist es nicht besser. da tun sich KDE
(Qt)
und Gnome relativ wenig, da muss ich dir recht geben.

Jedenfalls ist C++ nix für kleine Maschinen (Speicher). Wer allerdings
mit RAM im Gigabytebereich rumwerfen kann, der wird wirklich seinen
Spaß dran haben, dann ist das nämlich egal wie aufgeblasen so ein
Programm ist.


Theo

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, teilweise bin ich deiner Meinung. C++ ist halt etwas, was man auf
C aufgesetzt hat und irgendwie nichts halbes und nichts ganzes ist.
Trotzdem hat es auch gute Ansätze (STL Container, Templates z.B.). Und
mir ist es egal ob der Compiler dann das ganze in C-Code umwandelt, das
juckt mich absolut gar nicht. Kleine Sachen programmiere ich auch lieber
in C, größere Dinge sollten schon C++ sein.

Auf die Spitze hat es aber Microsoft mit C++ .NET getrieben, das ist
absolutes Chaos... da gibts plötzlich ne neue String-Klasse (natürlich
inkompatibel mit der alten) cout funktioniert nicht mehr (weil die neue
Stringklasse damit nicht zusammenarbeitet) etc. Da benutze ich dann
lieber C#, da weiß man wenigstens, dass es ne neue Programmiersprache
ist. Oder ich nehm halt gleich Java...

Autor: Fabian Scheler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ah, also Anfangs hielt ich den Anfangspost einfach nur für
Troll-Geschrei, der Autor scheint aber wirklich daran zu glauben, was
er da schreibt und das finde ich einfach ... eigentlich gibt man dazu
besser keinen Kommentar ab, aber beginnen wir doch mal mit ein paar
allgemeineren Dingen:

1. Alles, aber auch wirklich alles, was auf irgendeinem (heuete
grbäuchlichen) Rechner läuft  ist mit einer Turing-Maschine
implementierbar, also ist C++ natürlich auch in Maschinencode
implementierbar, alles andere wäre ja echt fatal. Das entscheidende
ist, welche Schnittstelle die C++ anbietet, und zu der gehören nunmal
Klassen, public, private, ..., die brint mir aber auch echt nur auf der
ebene des C++ Programms etwas, was darunter geschieht ist ein komplett
andere Welt!

2. "A poor programmer can produce bad code in any language!" - Das
gilt für C++, C, Java, Ada, Ada95 - eben einfach alle
Programmiersprachen

Nun ein paar speziellere Statements:

1. Die Übersetzung von C++ nach C als "Textverarbeitung" zu
bezeichnen, zeugt einfach von Unkenntnis, es handelt sich hierbei
keinesfalls um "Textverarbeitung". Vielmehr geht es darum ein
Programm vom abstrakten C++-Prozessor auf den abstrakten C-Prozessor zu
übersetzen (angenommen es gäbe Prozessoren, die C drekt ausführen
könnten, wäre es dann in deinen Augen immernoch "Textverarbeitung"?).
Hierbei müssen, wie bei der Übersezung zu Maschinencode, C++-Statements
in C-Statements mit identischer Semantik übersetzt werden, und das ist
bei den wenigen Abstraktionmechanismen, die C im vergleich zu C++
bietet alles andere als einfach.

2. Die Brücke von relationalem SQL und Objektorientierung ist mir
irgendwie schleierhaft, warum sprechen Datenbänkler sonst von
relationalen und objektorientierten Datenbanken???

3. Nur weil du ein paar Programme angesehen hast, die C++ verwenden und
die nicht so toll waren, heißt das nicht, dass man in C++ keine tollen
Programme schreiben kann (s. oben). Ich gebe es zu: C++ ist durchaus
schwer zu erlernen und zu beherschen, man muss sich halt einfach
überlegen, welche Eigenschaften der Sprache man in C++ wirklich
verwenden will: Verzichtest du z.B. auf virtuelle Methodden, RTTI,
Exceptions, ... ist es kein Problem Programme zu schreiben, die in
ihrem Ressourcenbedarf identisch zu C sind, man verliert aber
wesentlich Eigenschaften der Sprache. Mehr noch, oft implementiert man
solche Sachen in C teuer von Hand nach, spitze - das kann ein Compiler
mit Sicherheit besser als der Programmierer.Wer natürlich diese teuren
Konstrukte unbedacht einsetzt, wird schnell ein Programm erhalten, dass
aus allen Nähten platzt.

4. Mir fallen sofort zwei schöne Beispiele für effiziente C++-Programm
e aus dem Betriebssystembereich ein: PURE und eCos, alles
Betriebssysteme deren Kern oder die sogar komplett in C++ implementiert
wurden und ja - das erste läuft sogar wunderbar auf AVRs, übrigens
dürfte der Windows Kern in C geschrieben sein.

5. Sind dir in C++ eigentlich schonmal Templates aufgefallen, damit
kann man ganz wunderbar und effizient typsicher programmieren -
versuche das mal in C!

6. Für große Projekte ist C z.B. einfach komplett ungeeignet - warum?
Weil das Modulkomzept, das in C implementiert ist, einfach lächerlich
ist (nicht mal Namensräume gibt es in dieser Sprache) und den
Programmierer einfach dazu einläd Unfug zu machen, z.B. stark statt
lose gekoppelte Module zu entwickeln. Man muss sicherlich nicht gleich
eine objektorientierte Sprache nehmen, Modula macht das z.B. auch sehr
viel besser als C, aber C jetzt irgendwie als Programmiersprache für
große Projekte anzupreisen war nicht so geschickt.

Have a nice day, Fabian

Autor: Fabian Scheler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ja ja, bis das Ding platzt....den stack sollte man eigendlich sparsam
> benutzen, aber vieleicht liegt das daran das ich noch aus der Gilde
> der Speichersparer komme.

Ach ja, du behauptest aus der Gilde der Speicherspare zu kommen und
würdest dir immer eine dynamische Speicherverwaltung ans Bein binden,
abgesehen davon, dass die Laufzeit auch noch verbrät und man eben damit
Memory Leaks erzeugt. Versuche dann doch bitte mal ein vollkommen
statische Programm zu schreiben, ohne malloc-Zeug, wie weit kommst du
dann ohne Stack?

Ciao, Fabian

Autor: Theo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Templates sind eigendlich ne tolle Sache, aber nur oberflächlich!

Man baut eine TEXT-VERARBEITUNGS-Schablone (template) für einen
Algorithmus, z.B. einen binären Baum, eine verkettete Liste oder gar
eine Matrix, was auch immer.

Man  hat nun 5 verschiedene Datentypen "int" bis "double" zu
verarbeiten.

C++ templates machen nix anderes als 5 mal den selben Algorithmus
textuell zu codieren und dabei 5 mal einen anderen Datentyp
einzusetzen.

Man hat also nach der Compilation 5 mal den selben Algorithmus als
Objectcode im Speicher nur weil man 5 verschiedene Datentypen
verarbeiten will!

Auf die Idee zu kommen einmal einen Algorithmus zu schreiben der alles
an verschiedenen Datentypen verarbeiten kann, in dem er die Daten
mittels void-pointer adressiert als dynamischen Container der mittels
Vergleichsfunktion und der sizeof() funktion die offsets in der
Struktur oder Klasse errechnet, ist anscheinend noch niemand gekommen.
Aber im Gigabyte-RAM-Zeitalter ist das ja alles kein Problem mehr.

Man denke mal an den Quicksort in C,  qsort() da geht das offenbar
alles ohne Probleme.

Ausserdem, ein sauberer Programmierer weis, das man RAM-Speicher den
man anfordert auch wieder abgeben muß wenn er nicht mehr gebraucht
wird.

Hinter den Konstruktoren verbergen sich nämlich grade bei C++  new()
nichts anderes als  malloc()  und  calloc() aus dem guten alten C.

So jedenfalls im Buch von Nicolai Josuttis einem der C++ Päpste.

Wenn ich weis, das ich nicht an eine FILE-Struktur heran darf so greife
ich auch nicht intern mittels Tricks darauf zu, weil jede FILE-struktur
bei jedem C-compiler intern vom Hersteller anders aufgebaut ist.

Es ist also eine Frage der eigenen Disziplin und eben nicht der
Privatisierung (encapsulation) von Daten und Funktionen.

Was den Stack betrifft ist dieser im regelfall oft vom verwendeten
betriebssystem Begrenzt, und wächst im regelfall on oben nach unten.
das Heapsegment ist allerdings frei und kann bis speicherende wachsen.

Ausserdem fällt beim stackhandling viel Kopierarbeit an wenn man call
by value, statt call by reference benutzt und die kostet reichlich zeit
im gegensatz nur eine Adresse zu übergeben.

Last but not least:

Bei SUN Microsystems (bekannt durch Solaris-Unix und Sparc-CPUs) ist
derzeit ein Transpiler namens GCC2C in der Version 1.0 frei erhältlich,
 der C++ in reines C umwandelt, mit dem Ergebnis, das der so erzeugte
C-code nach der Compilation durch einen Ansi-C-compiler ohne Änderungen
schon 30% schneller läuft als das original unter einem C++
compiler..........Woran das wohl liegt ????


Theo

Autor: Fabian Scheler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Man baut eine TEXT-VERARBEITUNGS-Schablone (template) für einen
> Algorithmus, z.B. einen binären Baum, eine verkettete Liste oder gar
> eine Matrix, was auch immer.

Das ist völliger Blödsinn - Templates bieten eine vollständige
funktionale Programmierung zur Compilierzeit. Nur mal so als Hinweis:
der c't-Würfel ist noch ein Begriff - dort wurden Lösungen abgegeben,
die Templates benutzen und vollständig vom Compiler berechnet werden,
zur Lauzeit wird nur noch eine Konstante zurück gegeben.

> Man  hat nun 5 verschiedene Datentypen "int" bis "double" zu
>verarbeiten.

> C++ templates machen nix anderes als 5 mal den selben Algorithmus
> textuell zu codieren und dabei 5 mal einen anderen Datentyp
> einzusetzen.

> Man hat also nach der Compilation 5 mal den selben Algorithmus als
> Objectcode im Speicher nur weil man 5 verschiedene Datentypen
> verarbeiten will!

Hier kommt zum Zuge, dass man gewisse Features mit Hirn einsetzen
sollte - verwendest du Templates z.B. vor allem mit Pointern wird
überhaupt kein Code dupliziert - ansonsten ist der Compiler einfach
Müll.

> mittels void-pointer adressiert als dynamischen Container der
> mittels Vergleichsfunktion und der sizeof() funktion die offsets in
> der Struktur oder Klasse errechnet, ist anscheinend noch niemand
> gekommen.

das mit dem sizeof zeigst du mir, wenn der Compiler anfängt
Padding-Bytes einzufügen, das hier ist übriegns auch ein Musterbeispiel
für schlechte Programmierung - du verletzt hier eine Schnittstelle und
zwar die der Programmiersprache C!

> Ausserdem, ein sauberer Programmierer weis, das man RAM-Speicher den
> man anfordert auch wieder abgeben muß wenn er nicht mehr gebraucht
> wird.

> Hinter den Konstruktoren verbergen sich nämlich grade bei C++  new()

> nichts anderes als  malloc()  und  calloc() aus dem guten alten C.

Darum ging es in meinem Post auch nicht - ich habe den Fall
angesprochen, wenn man keine Speicherverwaltung hat, z.B. weil man von
den 16K Flash und den 2K RAM nix für eine Heap-Verwaltung verschleudern
will, dann ist der Stack neben statischen, globalen Variablen, nunmal
die einzige Möglichkeit. Um Klarheit zu schaffen: natürlich sollte man
z.B. greoße Arrays nicht unbedingt auf den Stack klatschen (es sei
denn, man braucht sie wirklich nur in diesem Kontrollfluss).

> Wenn ich weis, das ich nicht an eine FILE-Struktur heran darf so
> greife ich auch nicht intern mittels Tricks darauf zu, weil jede
> FILE-struktur bei jedem C-compiler intern vom Hersteller anders
> aufgebaut ist.

> Es ist also eine Frage der eigenen Disziplin und eben nicht der
> Privatisierung (encapsulation) von Daten und Funktionen.

Da gebe ich dir prinzipiell völlig Recht - der ideale Programmierer
bestitzt die perfekte Disziplin - aber wir sind keine idealen
Programmierer: wir machen Fehler! Solche Sachen wie Kapselung helfen
uns Fehler zu finden, z.B. wenn wir Schnittstellen verletzen, das
bietet dir C nicht in diesem Maße. Außerdem kostet
public/protected/private ja auch keine Ressource, das wird alles
komplett zur Übersetzungszeit gehandhabt.

> Bei SUN Microsystems (bekannt durch Solaris-Unix und Sparc-CPUs) ist

keine Sorge, ich kenne SUN, durfte mich auch schon bei SUN in Palo Alto
umsehen und in unserem Serverraum verrichten vornehmlich SUN-Server
ihren Dienst (zwar nicht die richtig dicken Eisen, dir brauchen wir
nicht, aber die SUN X4200 finde ich auch sehr schick ;-))

> derzeit ein Transpiler namens GCC2C in der Version 1.0 frei
> erhältlich, der C++ in reines C umwandelt, mit dem Ergebnis, das der
> so erzeugte C-code nach der Compilation durch einen Ansi-C-compiler
> ohne Änderungen schon 30% schneller läuft als das original unter
> einem C++ compiler..........Woran das wohl liegt ????

das Teil kenne ich, hast du mir mal angesehen, wie alt das Teil ist,
das ist von 2002 und ist ein Patch für den GCC 3.2 - abgesehen davon:
klar, es ist höllisch schwer einen echt guten Compiler für C++ zu
schreiben (GCC 2.95 war noch richtig grottenschlecht - polymorphe
Methodenaufrufe bei Mehrfachvererbung eine Katastrophe, 3.4.x
produziert schon recht annehmbaren Code und bei 4.x.x staunt man
teilweise wirklich, man ist aber - auch bei kommerziellen Compilern,
auch nicht beim Intel, am Ende der Fahnenstange angelangt -
vorkompilierte Template implementiert meines Wissens bisher immer noch
kein Compiler), aber nur weil es schwierig ist effiziente Übersetzer zu
schreiben (oder wir aber nicht wissen, wie man diese Sprache effizient
gebraucht) und es zu diesem Zeitpunkte noch keine gab, heißt das nicht,
dass die Sprache Mist ist. Der Erfolg dieses Tools ist vor allem darauf
begründet, dass der damalige Sparc-Compiler einfach Mist war, heute
kräht nach dem GCC2C eigentlich kein Mensch mehr. Abegsehen davon: wenn
du ein C++-Programm, dass RTTI, Polymorphismus, Exceptions, ... nach C
und dann in Maschinencode übersetzt, und wir davon ausgehen, dass der
Übersetzunsvorgang für C++-Code und C-Code nach Maschinencode jeweils
ideal sind, dann kann keines der beiden Programme schneller sein als
das andere - den idealen Übersetzer gibt es natürlich leider nicht
(kleiner Punkt für dich - der ideale C-Übersetzer existiert aber
natürlich auch nicht!).

Ciao, Fabian

Autor: Theoid (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich kenne solche Leute wie dich. Ihr haltet euch für kreative
Querdenker, seid schlussendlich aber nur bremsende Querköpfe.

Leute, die ein paar Prozent Laufzeitperformance gegen robuste
Programme, Effizienz und Produktivität bei der Programmierung und eine
ungemein höhere Wartbarkeit eintauschen wollen, haben essentielle
Punkte der professionellen Softwareentwicklung nicht begriffen. Und das
soll keine Lobpreisung für C++ werden, jeder weiß um die
Unzulänglichkeiten von C++, nicht wenige davon werden direkte von C
geerbt (in deiner Sprache "Copy&Paste"), weitere folgen aus der
rückwärts gerichteten Kompatibilität mit C. Soviel zu deinem geliebten
C.

Höhere Abstraktionsebenen und Automatisierung diverser Prozesse sind
Konzepte von Hochsprachen vor denen du dich scheinbar fürchtest, weil
der Compiler hier bessere Arbeit als du leisten könnte? Programmierer
sollen sich eben nicht mit malloc() rumärgern müssen, sondern viel
"weiter oben" ihr eigentliches Problem lösen. Ein Compiler ist dazu
da, dem Programmierer Arbeit abzunehmen (!), deswegen soll ein Compiler
und nicht die Disziplin des Programmieres die Einhaltung möglichst
strikter Regeln überwachen. Zugriffsverwaltung zum Beispiel bringt doch
absolut keinen Vorzug, wenn allein dem Programmierer überlassen.

Aber was schreib ich hier, Leute wie du hören nicht auf Leute wie mich.

Autor: Christoph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich befürchte von UML hältst du auch nicht viel...Da kann die einzelnen
Klassen und die Beziehungen zwischen diesen zeichnen.
Was für ein Programmieren...;)
Einer unserer Professoren hat mal was schlaues gesagt: "Programmieren
kann inzwischen jede Hausfrau. Das ist nichts schweres. Sie aber müssen
nach Ihrem Studium wissen wie man ein Programm entwickelt das auch
funktioniert..."
Und das geht bei den heutigen komplexen Programmen nicht mehr wenn man
in Assembler oder C schreibt. Man muss sich Hilfsmittel bedienen die
die Abstraktionslücke zwischen den Problem (z.B. Software für Hartz4
;)) und dem Lösungsraum (010001010-Folgen auf dem Rechner) verringert.
OOP ist eine, eine weitere wird in den nächsten Jahren UML sein.
Wär natürlich die Probleme der er mit Software lösen will, noch in C
lösen kann. Der kann bei C bleiben. Jede Programmiersprache hat seine
berechtigung....


Zitat von Dijkstra
"Als es noch keine Computer gab, war das Programmieren noch relativ
einfach. Als es dann ein paar leistungsschwache Computer gab, war das
Programmieren ein kleines Problem und nun, wo wir gigantische Computer
haben, ist auch das Programmieren zu einem gigantischen Problem
geworden. In diesem Sinne hat die elektronische Industrie kein einziges
Problem gelöst, sondern nur neue geschaffen. Sie hat das Problem
geschaffen, ihre Produkte zu benutzen."

Autor: Smörre (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Wär natürlich die Probleme der er mit Software lösen will, noch in C
lösen kann. Der kann bei C bleiben. Jede Programmiersprache hat seine
berechtigung...."

Ha,ha,ha - dann schau Dir mal den Arbeitsmarkt an, nichts mehr mit C,
nur noch C++, C# bzw. Java Programmierer gesucht.
Irgendwann gibt's dann die nächste noch "bessere"
Programmiersprache, ich denke da nur zurück an Pascal, das damals daa
Maß der Dinge war.
Fakt ist nun mal, daß C Programme ein besseres Laufzeitverhalten als
C++ Programme haben.

Das Ganze kommt mir vor wie bei der Markteinführung bei den
Videorecordern (damals gabs 3 unterschiedliche Systeme, das
schlechteste hatte sich damals durchgesetzt.
Ergebnis heute: DVD Recorder sind auf dem Markt, Video ist tot;
genauso wird das mit C++ enden, auch im Bereich der Mikrocontroller.

Heute ist keine Effizienz mehr gefragt, da die Hardware immer besser
wird; stattdessen aufgeblähte Programme mit Popup-Menüs und allerlei
unsinnigen Funktionen aktivierbar per Untermenü - nein, Danke!

Da es heute aber auf Klingeltöne, etc. mit allerlei bunten Menüs
ankommt, werden sich die Klickibunti Experten schon durchsetzen - ob
das jedem gefällt bzw. das Programm aufgrund seiner Komplexität zu
kompliziert wird, ist eine andere Frage.

Autor: Ralf Engels (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Cool,
das driftet hier ja immer mehr ab.

Windows wird halt in C++ oder C# programmiert. Da werden die Jungs
gesucht. Persönliche Vorlieben lasse ich hier lieber weg.
Deshalb finde ich auch die Aussage: "Fakt ist nun mal, daß C Programme
ein besseres Laufzeitverhalten als C++ Programme haben." sehr
plakativ.

Hast Du da wirklich Fakten? Welche, und wer hat die programmiert?
Hier ein kleiner Fakt von mir:
Local ACM programming contest:
http://www.informatik.uni-ulm.de/acm/Locals/2006/s...

Die meisten accepted Lösungen sind in C++ oder Java. Hier geht es sehr
wohl um zeitkritische Probleme (zu sehen an Time-Limit exceeded). Bei C
sieht man da oft den Wald wegen den Bäumen nicht. Ist eben schön, wenn
ich eine Hashtable oder eine Priority Queue schon in der
Standart-Library habe.
Und es spart Speicherplatz wenn die nicht jedes Programm neu
implementieren muss. Bei C gibt es eben nur eine Liste mit Q-sort und
selbst das wissen viele nicht.

Und von wegen Effizienz. Vier Mb mehr mehr Speicher kosten zwar nur ein
paar Cent mehr, aber multipliziere das mal mit 10 Millionen! Desshalb
muss selbst bei Klickibunti Handys ein Java-programm so klein wie
möglich sein.

Ach, und apropos unsinnige Funktionen: Wenn Du mit ein paar Wochen
Arbeit 1% mehr (also so etwa 100000) verkaufst, dann gibt es eben noch
mal ein Untermenü wo Du den Klingelton für jeden Anrufer extra
einstellen kannst.

Autor: Smörre (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"das driftet hier ja immer mehr ab."
-> kann ich nicht ganz erkennen

"Windows wird halt in C++ oder C# programmiert. Da werden die Jungs
gesucht."
-> das Schlechteste System setzt sich eben immer durch, weil sich die
Leute vom Marketing blenden lassen ... womit wir wieder beim Thema
sind: C++ oder die lukrativen Lügen der Softwareindustrie

"Hast Du da wirklich Fakten? Welche, und wer hat die programmiert?"
Aber sicher doch!
1.
http://www.c-plusplus.de/cms/modules.php?op=modloa...
Kauf Dir die C und die C++ Version des Buches und mach selbst den Test.
Mein Tip: Spar die Mühe und schau Dir 4. an!

2. C++ ist eine Obermenge von C; wie sollen die Instruktionen einer
Obermenge gleich schnell oder gar schneller umgesetzt werden?
Kannst Du mir diese Paradox mal erklären?!

3.
Hier hat sich einer mal die Mühe gemacht:
http://www.blindschleiche.de/shownews.php3/120

3.
komplexere Programme in reinem C:
http://www.dillo.org/
mach mal den Browser-test in Bezug auf Schnelligkeit!
Funktionsumfang ist eine andere Sache, schon klar.

3.
Hier hat sich einer mal die Mühe gemacht:
http://www.blindschleiche.de/shownews.php3/120

Lad Dir die PDF Datei herunter und schau Dir die Performance-Vergleiche
der Diagramme ab Seite 14 folgende genau an.
C schneidet gegenüber C++ bis auf eine Ausnahme in den Laufzeiten
besser ab.
Schlimmer aber noch (für Euch als C++ Anhänger), es gibt inzwischen
Skriptsprachen, die bei vereinfachter Programmierung um Faktor 2 die
gleiche Arbeit tun - damit wird das Argument der Einfachheit gegenüber
C über Board geworfen; wenn Laufzeiten für Euch keine Rolle spielen und
sich ein Programm mittels Skriptsprache um den Faktor 2 schneller
entwickeln läßt, wählt man doch den Zeitvorteil - das nennt man
Fortschritt.


Jetzt Dein supertolles Beipiel:

Local ACM programming contest:
http://www.informatik.uni-ulm.de/acm/Locals/2006/s...

contest heißt Wettbewerb und den Rest kann man sich wohl denken ???!!!
Je nach Tagesverfassung und Können des jeweiligen Programmierers
entsteht da (womöglich auch noch unter Zeitdruck) ein Programm.
Klar, daß da C++ als Sieger abschneidet.
Daß C schwieriger zu programmieren ist als C++ mag ja sein,
nur dann die Schlußfolgerung zu ziehen, sich nicht mehr mit C befassen
zu müssen, sondern gleich auf c++ zu gehen nur weil das einfacher in
der Programmierung sein soll, hinkt doch gewaltig.
Welche grandiosen Vorteile gibt es nun, außer das man diese Sprache
eben "noch" für Windows braucht und diese Sprache in einigen
Nischenbereichen noch führend ist ?!
Ich stufe c++ eher als eine Übergangssprache ein, die ähnlich wie
Pascal mittelfristig verschwinden wird - man sollte sich überlegen, ob
es dann Sinn macht, sich damit überhaupt eingehend zu beschäftigen.

"Und von wegen Effizienz. Vier Mb mehr mehr Speicher kosten zwar nur
ein paar Cent mehr, aber multipliziere das mal mit 10 Millionen!
Desshalb muss selbst bei Klickibunti Handys ein Java-programm so klein
wie möglich sein."
->Schlag mal bei ein paar alten c't Zeitschriften nach und schau Dir
die Rechnerentwicklung an oder schauh Dir nur mal die rasente
Entwicklung im Bereich der Speicherchips an im letzten halben Jahr an,
das Problem speicherminimaler Programme wird sich sehr schnell von
selbst erledigen.

"Ach, und apropos unsinnige Funktionen: Wenn Du mit ein paar Wochen
Arbeit 1% mehr (also so etwa 100000) verkaufst, dann gibt es eben noch
mal ein Untermenü wo Du den Klingelton für jeden Anrufer extra
einstellen kannst"
Das wär ja noch eine halbwegs vernünfigtes Programm :-)
Nur das ganze Programmkonzept ist doch der Wahnsinn - durchhangeln
durch etliche Untermenüs, um endlich mal etwas richtig einstellen zu
können - den Kiddies macht das vielleicht Spaß (das sind ja auch die
Endkonsumenten) ich sag nur: ätzend programmiert.

Autor: Smörre (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
kleiner Fehler, 3. ist mehrfach vorhanden, da ich noch was reingepostet
und nicht gelöscht habe und nicht umbenannt habe in 4.

Autor: arc (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Damits auch richtig OT wird
Java vs. Net vs C/C++ bei numerischen Problemen
http://www.shudo.net/jit/perf/
SciMark:
Visual C 329 MFlops
Sun JDK 1.4.2 Server VM 324 MFlops
icc 306 MFlops
C#, Net 1.1 240MFlops
Sun JDK 1.5.0 Client VM 199 MFlops
Unterschied bester Compiler/bester JIT ~1%

Linpack:
icc 402 MFlops
Visual C 399 MFlops
C#, Net 1.1 382 MFlops
Sun JDK 1.4.2 Server 379 MFlops.
Sun JDK 1.5.0 Client VM 339 MFlops
Differenz "" ~5%

Zur Effizenz bei der Programmierung mal ein paar
SLOCS/Function Point-Werte (die Datenbasis umfasst über
7000 Projekte, wobei der größte Teil zw. 10T und 300T ESLOCs
liegt, etliche auch über 1000T ESLOCs)
          Avg    Median
Ada       154
C         148       104
C++        60        53
C#         59        59
Java       60        59
Smalltalk  35        32
http://www.qsm.com/FPGearing.html

Autor: Ralf Engels (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also gut.
Ihr habt mich überzeugt. Hier meine persönliche Wahl der
Programmiersprachen:

Assembler: Wenn möglich nie
C: Für Programme unter 1000 Zeilen ohne viel Algorithmen
C++: Für alles, für das ich kein Perl nehmen kann
Perl: Nur mit strict und -W, dann aber für soviel wie möglich.
Java: Wenn es GUI haben muss, und Platform kompatibel.
Python: Sobald sie sinnvolle Syntax checks bauen probiere ich es
nochmal

Alles andere nur in Ausnahmefällen.

Und nochmal was: Ich suche mir lieber einen guten Programmierer aus,
als eine gute Programmiersprache.

Autor: Christoph __ (chris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nur dazu:

> 2. C++ ist eine Obermenge von C; wie sollen die Instruktionen
> einer Obermenge gleich schnell oder gar schneller umgesetzt
> werden?

Erstens ist C++ keine Obermenge von C, da die meisten C-Programme von
einem heutigen C++-Compiler zurückgewiesen werden. Aber das weißt du
bestimmt.

Bei C++ ist das Schöne, dass du die ganzen Features, die es im
Vergleich zu C mehr bietet, nicht nutzen musst. Solange du die nicht
nutzt, hast du genau 0,0% Overhead im Vergleich zu C. Soviel also zu
dem vermeintlichen "Paradoxon".

Wenn du die C++-Features allerdings nutzt, sieht es anders aus: Dann
gewinnt häufig C++.
Denn zu z.B. Polymorphie oder Exceptions äquivalente Funktionalitäten
müsste man in C eben "per Hand" implementieren, was man
höchstwahrscheinlich nicht so gut hinbekommt wie ein heutiger
C++-Compiler. Außerdem wird ein Compiler besser werden, deinen C-Code
wirst du jedoch erstmal nicht so gerne verbessern wollen, wenn er
"akzeptabel läuft".

Meine Erfahrung ist, dass sogar schon bei 20-Zeilern C++ schneller als
C ist, sowohl in der Entwicklung als auch in der Ausführung. Denn die
C++-Features kosten nichts, solang du sie nicht nutzt. Du kannst dir
also gezielt die raussuchen, die dir etwas nutzen, ohne teuer zu sein.

Autor: Tobi H. (tobi-) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"3.
Hier hat sich einer mal die Mühe gemacht:
http://www.blindschleiche.de/shownews.php3/120

Lad Dir die PDF Datei herunter und schau Dir die
Performance-Vergleiche
der Diagramme ab Seite 14 folgende genau an.
C schneidet gegenüber C++ bis auf eine Ausnahme in den Laufzeiten
besser ab.
(...)
contest heißt Wettbewerb und den Rest kann man sich wohl denken
???!!!"

Dein angegebener Link scheint dem Text im pdf nach auch 'nur' ein
Wettbewerb zu sein, denn der Autor hat auch Programme von mehreren
anderen Leute die sich dort beteiligt haben herangezogen. Damit
erklärst du diesen Vergleich selbst für nichtig.

Autor: Smörre (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Erstens ist C++ keine Obermenge von C da die meisten C-Programme von
einem heutigen C++-Compiler zurückgewiesen werden. Aber das weißt du
bestimmt."
-> Nein, ist mir neu, da ich mich nicht so eingehend mit C++
beschäftigt habe - danke für die Aufklärung - im Web wird das zumindest
verschiedentlich so behauptet, aber es sind dann wohl ältere
Compiler-Versionen gemeint ?!
Sind diese neueren Compiler eigentlich noch ANSI compatibel?

Bei C++ ist das Schöne, dass du die ganzen Features, die es im
Vergleich zu C mehr bietet, nicht nutzen musst. Solange du die nicht
nutzt, hast du genau 0,0% Overhead im Vergleich zu C. Soviel also zu
dem vermeintlichen "Paradoxon".
-> das mag natürlich stimmen (insbesondere bei kleineren Programmen),
nur dann kann ich ja auch bei C bleiben, oder aber C# verwenden, daß ja
möglicherweise noch mehr Features aufweist, die ich nicht nutzen muß und
ich bin auf dem neuesten Stand.
(Ich kenne die Möglichkeiten von c# nicht, wer weiß mehr?)

Wenn du die C++-Features allerdings nutzt, sieht es anders aus: Dann
gewinnt häufig C++.
Denn zu z.B. Polymorphie oder Exceptions äquivalente Funktionalitäten
müsste man in C eben "per Hand" implementieren, was man
höchstwahrscheinlich nicht so gut hinbekommt wie ein heutiger
C++-Compiler.
-> okay, 1:0 für Dich; schwieriger wird das mit Sicherheit, nur dann
kann man auch überlegen z.B. auf das plattformunabhängige Java
auszuweichen.

Außerdem wird ein Compiler besser werden, deinen C-Code
wirst du jedoch erstmal nicht so gerne verbessern wollen, wenn er
"akzeptabel läuft".
->
es sollte dann ja auch normalerweise reichen, wenn man sein
Zielvorstellungen erreicht hat
Im übrigen müssen die Compiler-Entwickler ja den vorgegebenen ANSI
Standard für C++ nach Möglichkeit noch einhalten, irgendwo wird sicher
auch da mal das Ende der Optimierung eines Compilers erreicht sein.
Dann gibt es auch immer wieder mal überraschende Neuauflagen alter
Programmiersprachen mit verbesserten Compiler, siehe http://www.m3.org/
 (Danke Theo für den Link)
Insofern wär ich da vorsichtig C++ als das NonplusUltra darzustellen.

"Meine Erfahrung ist, dass sogar schon bei 20-Zeilern C++ schneller
als C ist, sowohl in der Entwicklung als auch in der Ausführung. Denn
die C++-Features kosten nichts, solang du sie nicht nutzt. Du kannst
dir also gezielt die raussuchen, die dir etwas nutzen, ohne teuer zu
sein."
-> Wenn man Erfahrung hat kein Problem; aber auch hier stellt sich mir
die Frage, ob es dann nicht sinnvoll ist gleich auf die
Nachfolgesprache C# überzuspringen, das wär ja dann die logische
Konsequenz.


Dein angegebener Link scheint dem Text im pdf nach auch 'nur' ein
Wettbewerb zu sein, denn der Autor hat auch Programme von mehreren
anderen Leute die sich dort beteiligt haben herangezogen. Damit
erklärst du diesen Vergleich selbst für nichtig.
-> wenn es so, ja; ich hab die Datei nur schnell überflogen, werd aber
noch mal nachschauen.
Es ist leider schwer was zu finden.

Dann müßtest Du nur noch das Beispiel von arc wiederlegen und ich gebe
mich geschlagen, was nachweisbare Beweise angeht:

Avg    Median
Ada       154
C         148       104
C++        60        53
C#         59        59
Java       60        59
Smalltalk  35        32
http://www.qsm.com/FPGearing.html

Vielen Dank übrigens für diesen OT Vergleich, war ganz aufschlußreich
in Bezug auf neuere Programmiersprachen.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Dann müßtest Du nur noch das Beispiel von arc wiederlegen und ich
> gebe mich geschlagen, was nachweisbare Beweise angeht:
>
>           Avg    Median
> Ada       154
> C         148       104
> C++        60        53
> C#         59        59
> Java       60        59
> Smalltalk  35        32

Da ich nicht weiss was ein 'Function Point' ist, ist es schwer
zu erkennen was diese Tabelle exakt aussagt. Aus dem Text auf
der Seite ist das auch nicht so klar erkennbar. Ich denke allerdings
dass es sich hier um sowas wie 'Wieviele Lines of Code braucht man
für eine Funktionseinheit' handelt. Mit anderen Worten: je kleiner,
desto besser.
Diese Interpretation wird auch dadurch unterstützt, dass der
bei weitem höchste Wert von Assembler erreicht wird. Und wir
alle wissen, dass Assembler am geschwätzigsten ist. Interessant
sind allerdings die extrem hohen Werte für ADA und C. Wobei
die Min und Max Werte für C einen wesentlich grossen Bereich
abdecken als bei allen anderen. Ich würde das mal so interpretieren:
In C gibt es einen grossen Spielraum zwischen guten und schlechten
Programmierern: Die guten sind extrem gut und die schlechten sind
extrem schlecht. Bei C++ ist der Bereich wesentlich kleiner.
Mit anderen Worten: Die schlechten Programmierer schaffen es in
C++ wesentlich bessere Programme zu schreiben als die schlechten
Programmierer in C. Der Unterschied auf der 'guten' Seite ist
hingegen bei weitem nicht so gravierend: Ein guter C Programmierer
braucht auch nicht wesentlich weniger Code als ein guter C++
Programmierer. Und im Mittel sind C++ Programme kürzer als C
Programme.

Das deckt sich im übrigen mit der Erfahrung die die meisten C++
Programmierer gemacht haben. Ein guter C++ Programmierer erzeugt
Code, der:
kürzer ist als ein funktional äquivalenter C Code.
meist schneller ist als ein funktional äquivalenter C Code.

Warum betone ich: funktional äquivalent dermassen stark?
Weil in den meisten Vergleichen es eben nicht so ist, dass
funktional äquivalenter Code verlgichen wird. Die Grundfunktionalität
ist bei solchen Vergleichen meist tatsächlich entsprechend. Wenn es
aber dann darum geht, dass das Programm auch mit Fehlersituationen
umgehen können muss, dann sieht es bei den meisten C Programmen
mehr als düster aus.

Autor: Theo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Das deckt sich im übrigen mit der Erfahrung die die meisten C++
>Programmierer gemacht haben. Ein guter C++ Programmierer erzeugt
>Code, der:

>kürzer ist als ein funktional äquivalenter C Code.

Optisch vieleicht, aber sicher nicht im Compilat!
Allein schon die C++ header sind schon ein Molloch für sich.
Die Zweifel steigen, weil ich den vergleich C - Modula3 gelesen habe,
wo der Autor mit "hello world" auf 335 kb Code kam, wärend er einen
Amigasystem samt grafischer Oberfläche 250 kb hatte.


>meist schneller ist als ein funktional äquivalenter C Code.


Ebenfalls zweifelhaft, vieleicht wenn man nur C in C++ benutzt,
aber nicht den anderen Firlefanz. Aber nehmen wir das mal als richtig
an, was kostet das dann an Speicher ?


>Warum betone ich: funktional äquivalent dermassen stark?
>Weil in den meisten Vergleichen es eben nicht so ist, dass
>funktional äquivalenter Code verlgichen wird. Die
>Grundfunktionalität ist bei solchen Vergleichen meist tatsächlich
>entsprechend. Wenn es aber dann darum geht, dass das Programm auch
>mit Fehlersituationen umgehen können muss, dann sieht es bei den
>meisten C Programmen mehr als düster aus.


Ist dir schonmal aufgefallen das viele HochsprachenCompiler oftmals
weit grösser sind als reine C-Compiler ?

Das liegt daran das man viel bzgl. der Sprachsicherheit in diese
Compiler seitens der Konzeption gesteckt hat, was bei C meist wegfällt.


Wer das in C auch haben will, kann den Syntax-Checker "lint" nehmen
(standart unter Unix), der nörgelt fast alles an und lässt schnell
Erinnerungen an Pascal hochkommen, nur das das Ding nicht die
Programmausführung verweigert oder unterbindet, bis der letzte
unsaubere Trick beseitigt ist.

Oder mit anderen Worten, diese verschärfte Prüfung hat man auf kosten
der Unsicherheit bei dem einfachen C-Check weggelassen. Man kann es
ggf. auch mit CINT programmieren, einem C/C++ Interpreter, der sich lt.
aussage der Ersteller auch gut zum lernen eigne.

http://root.cern.ch/root/Cint.html

Was mir allerdings bei C++ auffiel ist das diese Syntaxprüfung weit
schärfer ist als bei C. Selbst Kleinigkeiten nörgelte der Compiler an,
was man aber je nach Hersteller abschalten kann. Man könnte also sagen
das die nix anderes gemacht haben, als wegen C++ nen erweiterten
"lint" in den Präprozessor eingebaut zu haben.

Meine Meinung zum Thema ist, das es besser ist viele kleine bis
mittlere Module sauber zu entwickeln, das kann man ruhig in C machen,
diese gründlich zu testen und dann zu linken mit passende *.h Dateien.
Das wird mit Sicherheit viel kleiner als alles Marke STL.

Jedenfalls finde ich das besser als hinter dem Rücken des
Programmierers eine heimliche Textersetzung weit über das Maß von
Makros hinaus zu betreiben und das dann als Innovation zu verkaufen.

Ich mag grundsätzlich nicht bezweifeln das ein moderner C++ Compiler
weit mehr Sicherheiten bietet, als ein gewöhnlicher C-Compiler ohne
"lint", allerdings werde ich das Gefühl dabei nicht los, das das am
Ende auf Kosten des Laufzeitsystems geht (Speicherverbrauch),
eigentlich das, was andere Sprachen schon bei der Entwicklung abfangen,
wie die beispiele C/C++ versus Modula-3 zeigen.

Ergänzend kann ich nur sagen, das ich C mangels Geld für edlere
Maschinen noch in der späten MSDOS-Ära (win3.11/win95) auf ebensolcher
Kiste im Dos-Mode gelernt habe (TurboC 2.0) wobei ich die Kiste öfter
mal abgeschossen habe (Lehrgeld). Mit TurboPascal ist mir das beim
Lernen der Sprache Vers.5.0, als auch bei deren Anwendung fast nie
passiert. Meist war meine Unachtsamkeit schuld, weil Pascal einem
Trivialfehler meist meckernd vor die Nase gehalten hat und nicht eher
lief bis das Bemeckerte korrigiert war und vieleicht ist diese Strenge
sogar auch für erfahrene Programmierer immer noch gut, gerade bei sehr
großen Projekten mit vielen Teilnehmern

Was Geschwindigkeiten betrifft:

QuickSort auf 30.000 Random-Integer's unter MSDOS,
1 MB RAM, 286-Prozessor, 10 MHz Takt:

Getestet die rekursive Variante, (es gibt auch eine iterative)

TPascal 5.0  ~ 5,5 sec.

TC 2.0 OHNE Registervariablen (Laufindex) ~ 5,5 sec
TC 2.0 MIT Registervariablen (Laufindex) ~ 4,5 sec
TC-2.0 mit BuildIn qsort() ~ 4 sec.

...and the winner's are:

Stony Brook Pascal-Compiler ~ 3,1 sec.
Borlands-X86 TurboAssembler ~ 3,0 sec.

Stony Brook Homepage (Übergangsweise weiter unten):
Bei Pascal schienen die wohl bei bei Win95 vers.7.0 Schluss gemacht zu
haben.ggf kann man bei denen auch Ada bekommen. Wie die Daten oben
zeigen war der Code den der Stony PascalCompiler damals erzeugte extrem
schnell (fast wie Assembler). Dann bieten die hier bei Modula gezeigt,
auch portable GUI's für Windows, Unix, MacOS an.

http://www.modula2.org/sb/websitearchive/productinfo.htm

Noch Wünsche in Sachen Sprachen ?
Es muss also nicht immer Borland, GCC, oder Microsoft sein....

Und außerdem muss schon garnicht das Bekannteste das Beste sein!!!

Man sieht also, das es nicht an einer Sprache als solcher liegt, wie
schnell was läuft, sondern eher wie sauber und effizient der Compiler
ist. Eindrucksvoll hat das ja auch die Liste mit den C/C++ und
JAVA-Compilern gezeigt wo grade mal ~5% Unterschiede zu verzeichnen
waren. Und 5% merkt man nicht mal auf meiner jetzt wieder uralten
PII-Kiste.

Vorteilhaft finde ich bei der Java, das es plattform-portabel ist,
wärend C/C++ immer wieder etliche Hilfsbibliotheken brauchen,
insbesondere was die Menüerstellung betrifft, denn man möge mir mal
zeigen, wie man Visual-C++.Net Quellcode ohne Änderungen direkt auf
einer Solaris-Maschine via Rekompilation mit dem C++SUN-Compiler zum
laufen bekommt ?

Wer das drauf hat, dürfte als bald sehr reich werden...

Alternative wären unter vielen anderen die Stony-Brook Compiler:

Was mich allerdings bei den Marktanteilen wundert ist, weil Microsoft
immer noch gut ~80% der reinen PC-Clientsysteme bestückt, (Linux ~
10-15% / Rest andere wie Solaris, MacOS-X), das noch niemand auf den
Trichter kam, den Microsoft C/C++ Dialekt auf andere Zielmaschinen zu
portieren, was eine 1:1 Übersetzung zumindest bei den grafischen Menüs
ermöglicht, sozusagen ein Nachbau der MFC - Befehle auf Unix. Umgekehrt
von Linux Richtung Microsoft findet man allerdings einiges davon, z.B.
minGW für gtk2 auf Windows oder die Qt von trolltech usw.

Alternativ und kostenfrei bietet sich:

www.japi.de

an, nicht zuletzt weil Java in den vergleichen recht gut abgeschnitten
hat. langsam kann das nicht sein, denn wenn die JVM als Interpreter im
Hintergrund nur die grafischen Maschinenroutinen aufruft, und das alles
unter einem Pentium-1 mit 90 MHz und 32 MB RAM ordentlich läuft, so der
Autor. Außerdem gibt's heute kaum einen DesktopRechner bei dem keine
JVM läuft, weshalb man sich deren Dienste eigentlich nutztbar machen
sollte, auch dann wenn mit anderen Sprachen als Java programmiert wird,
so das Ziel von JAPI, denn so bleiben unter MS entwickelte Programme
auch unter Solaris oder Linux 1:1 übersetzbar.

Und was das Einspielen von UNIX-Systemen betrifft, ist grafische
Installation keinesfalls 'ne Erfindung von Microsoft oder später
Linux, sondern sowas gabs schon zumindest meiner Erfahrung nach 1994-95
bei Solaris 2.6 auf Sparc-Maschinen samt sofortiger voller Auflösung im
InstallationsModus, direkt beim reinpfeffern der CD.

Nur das gab's bei der Solaris-Intelvariante damals natürlich nicht!

Das selbe bei optischen Mäusen bei Sparc's absoluter Standart samt
SCSI-Platten. Optische Mäuse kamen bei Microsoftmaschinen so ab Jahr
2000 mit ins Paket.

Woher ich wissen ?

Ich hatte seinerzeit das Glück Mitte der 90er für eine kurze zeit
während eines 1,5 Jährigen Studentenjobs an der Fern-Uni Hagen so wie
mir die Mitarbeiter sagten, die schnellste SUN der ganzen Uni zu haben.
Das Ding wurde geliefert und ich sollte Solaris installieren als totaler
Unix-Novize!.....holla!

Dual-Sparc CPU mit 128 MB Ram, die anderen hatten nur eine CPU mit 64
MB, aber alles an sehr anspruchsvollen Anwendungen lief auf den
Dingern, was heute überhaupt nicht mehr denkbar ist. Selbst grafisch
recht anspruchsvolle WySiWyG-Textsysteme wie FrameMaker unter Unix, wo
die Doc's und Prof's ihre Proceedings samt Grafiken schrieben, zu
einer Zeit wo Microsoft-Word, grade mal für nen Bewerbungsschreiben
oder ne Einkaufsliste taugte.

Einziger Wehmutstropfen bei den Sparc's damals:

Man musste noch mit einem normalen Editor meistens Xedit arbeiten (zum
Glück kein vi) und dann von Hand via Konsolefenster per
Kommandozeilen-Befehl Modula-2 compilieren, da die Uni derzeit noch
keine IDE-Systeme angeschafft hatte. Da war dann in Sachen
Bequemlichkeit T-Pascal besser, wenn auch nur im TextMode unter DOS. So
programmierte man dann zu hause vor, in T-Pascal bis alles lief und
änderte nur an der Sparc auf Modula ab, weil beides sehr ähnlich ist,
und dann passte das meistens um sich nicht mit Xedit und Konsole herum
schlagen zu müssen.

Und da kam doch immer, so alle paar Tage ein mit mir angestellter
Uni-DO-Student in meine BüroBude und fragte ob ich ihm ne verkette
Liste programmieren könnte, er wüsste das nicht, obwohl in Semester 10!
Aber von abstrakten theoretischen Papier-Automaten Marke Turing hatte
der Gute ne Menge Plan....:-)


Theo

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"eine CPU mit 64 MB"

da musste ich erstmal lachen...

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Das liegt daran das man viel bzgl. der Sprachsicherheit in diese
> Compiler seitens der Konzeption gesteckt hat, was bei C meist
> wegfällt.

Unsinn.
Ich rede nicht vom Compiler sondern von den fertigen Endprogrammen.
Das liegt einzig und alleine daran, dass C Programmierer faule
Hunde sind (wie alle Programmierer). Fehlerwerten nicht abzufragen
und entsprechend zu reagieren ist bei denen sehr oft einfach nur
ein Kavaliersdelikt.

> Meine Meinung zum Thema ist, das es besser ist viele kleine bis
> mittlere Module sauber zu entwickeln,

Da stimme ich absolut zu

> das kann man ruhig in C machen,

Du hast offensichtlich noch nie ein Industrieprojekt gemacht.
Sonst wüsstest du, dass bei einige zig-tausend LOC das Ganze in
C einfach nur noch der Horror wird, egal wie sauber du arbeitest.
Tut mir leid, aber dein Micky Mouse Program zur Diplomarbeit zählt
noch nicht als mittleres Program. Für die meisten Industrie-
programmierer ist das immer noch ein Winzig-Programm. Der grosse
Vorteil von C++ ist nicht die Code-Size oder die Dinge auf die
du da rum reitest, sondern dass dir C++ Möglichkeiten in die
Hand gibt, grosse Projekte im Griff zu behalten.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Jedenfalls finde ich das besser als hinter dem Rücken des
> Programmierers eine heimliche Textersetzung weit über das Maß von
> Makros hinaus zu betreiben und das dann als Innovation zu verkaufen.

Sag mal. Was lernt mein eigentlich im Studium heutzutage.
Jeder Compiler (mit Ausnhame vielleicht von Prolog) ist
letztendlich nur ein Textersetzer: Er ersetzt den Quelltext durch
funktionsgleichen Maschinencode.
Das ist aber auch nicht der springende Punkt. Der springende
Punkt ist: Welche Möglichkeiten ich mit dieser 'Textersetzung'
kriege und welche Abstraktionsebenen sich eröffnen.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Und außerdem muss schon garnicht das Bekannteste das Beste sein!!!

Wer bitte sagte, dass C++ das Beste seit geschnittenem Brot ist?
Niemand, das sagst nur Du. Selbst die C++-Gurus wissen, und
diskutieren offen darüber, dass es in der Sprache mehr als eine
einzige Problemstelle gibt.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> das noch niemand auf den Trichter kam, den Microsoft C/C++ Dialekt
> auf andere Zielmaschinen zu portieren,

Aehm.
C++ ist seit 1998 genormt. Es gibt einen ISO/ANSI Standard der
genau (na ja) beschreibt, was C++ ist und was nicht. Und jetzt
wirst du lachen: Microsoft hat in den letzten Jahren enorme
Anstrengungen unternommen seinen Compiler ISO/ANSI konform
zu machen. Die Ergebnisse sind sehr gut.

> was eine 1:1 Übersetzung zumindest bei den grafischen Menüs
> ermöglicht, sozusagen ein Nachbau der MFC - Befehle auf Unix

Jetzt disqualifizierst du dich selbst. Es ist sinnlos mit dir
zu diskutieren da du von C++ keine Ahnung hast. Du hälts eine
herstellerspezifische Bibliothek für C++ selbt. Wenn du von
C++ nur ein bischen Ahnung hättest (und zb. mal für 2 Wochen
in comp.lang.c++ mitgelesen hättest) dann wüsstest du, dass in
C++ nichts, aber auch gar nichts, was auch nur irgendwie
hardwareabhängig sein könnte oder in die Kategorie 'Benutzer-
schnittstelle' fällt, in der Sprache selbst definiert ist.
C++ hat für I/O streams und das wars dann auch schon. Alles
weitergehende wird über herstellerspezifische Libraries geregelt.


Und tschüss.

Autor: Bri (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und wieder mal bewahrheitet sich der Spruch:

"Software ist komplizierter als Wurst"

Ja Theo, es reicht eben bei C++ nicht aus, einfach irgendwo drauf zu
drücken, damit was raus kommt.

Autor: Tobi H. (tobi-) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
" Ich denke allerdings dass es sich hier um sowas wie 'Wieviele Lines
of Code braucht man für eine Funktionseinheit' handelt. Mit anderen
Worten: je kleiner, desto besser."

Hört sich stark danach an. Bloss wie ermittelt man soetwas bei HTML??

Ausserdem, was ist es für ein Schwachfug seine Software nach einer
möglichst gleichmäßigen Funktionslänge zu optimieren, wie auf der Seite
empfohlen.

Scheint eher, dass ein paar Esoterik-Freaks sich von den
Atomstromfiltern zur Programmierung gewandt haben um dort ihren Unfug
zu treiben.


"Ebenfalls zweifelhaft, vieleicht wenn man nur C in C++ benutzt,
aber nicht den anderen Firlefanz. Aber nehmen wir das mal als richtig
an, was kostet das dann an Speicher ?"

C++ läßt sich durch reine Textersetzung zu C umwandeln (+ ein bisschen
zur Compilezeit prüfen obs erlaubt ist). Warum sollte C++ langsamer
sein, als ein C Code, der die gleiche Mächtigkeit hat?


">kürzer ist als ein funktional äquivalenter C Code.

Optisch vieleicht, aber sicher nicht im Compilat!
Allein schon die C++ header sind schon ein Molloch für sich."

Un noch einmal disqualifiziert... Wo vergrößern C++-Header denn das
Compilat?

@Theo
Verrat uns mal, was du denn studiert hast..

Autor: Feldpost (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Programmiersprachen sind nur Werkzeuge für Programmierer. Man muss halt
wissen für welche Projekte oder Projektteile welches Werkzeug am
geeignesten ist.

Für eine kleine 'Hello World' Konsolenapplication würde ich Pascal
oder C nehmen, klar. Vielleicht zusammen mit einer MatLab
Visualisierung und Datenerfassung mit LabView etc...

Warum soll ich mich abrackern mit TCP/IP oder anderen tausendmal
geschriebenen Sachen die im Betriebssystem stecken wo es ein .NET etc.
Framework gibt? Stellt euch die APIs von Betriebssystemen mit einem
'flachen' (ohne Klassen und/oder Namespaces) -Framework vor?

Bei grösseren Projekten mit mehreren Entwicklern ist C++ eine feine
Sache, grade weil man die Anderen nicht nur Module (bzw. Funktionen)
schreiben lassen kann, sondern Aufgaben: Projektteile (Objekte) mit
einem schmalen Interface.

Beim µC programmiere ich einzelne Funktionen gerne Assembler, dann
eventuell einen schönes C-Outfit drumherum... Kommunikationspartner zum
Debuggen ein PC mit einem schnell zusammengeklickten Delphi-Programm
(mit Object-Pascal ;) )

Alle Sprachen machen nur einen Compilierten Datenbrei, in manchen
Sprachen bekommt man das halt schneller hin, andere sind länger, andere
langsamer etc...
Wichtig sind halt auch die Quelltexte: Übersichtlichkeit,
Funktionalität, Design erkennber (falls man für ISO zertifizierte
Unternehmen programmiert nicht zu unterschätzen), erweiterbar, evtl.
portierbar...

Autor: Christoph __ (chris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> [C++ ist nicht Obermenge von C]
> -> Nein, ist mir neu, da ich mich nicht so eingehend mit C++
> beschäftigt habe - danke für die Aufklärung - im Web wird das
> zumindest verschiedentlich so behauptet, aber es sind dann
> wohl ältere Compiler-Versionen gemeint ?!

Der folgende Link zeigt z.B. auf eine ganz gute Seite, die die
Unterschiede zwischen aktuellem C und aktuellem C++ erklärt:
http://david.tribble.com/text/cdiffs.htm
Es gibt inzwischen so viele Unterschiede, dass C und C++ IMHO sehr
berechtigt als zwei nebeneinander existierende, unabhängige Sprachen zu
betrachten sind.

Die Seite vergleicht das "neueste" C (C99) mit dem aktuellen C++
(C++98). Bei früheren C-Versionen waren die Unterschiede zu C++ zwar
etwas geringer, z.B. gab es keine variablen Arrays auf dem Stack, aber
sie waren dennoch zahlreich vorhanden. Eines der einfachsten Beispiele
ist wie immer malloc. In C würde man schreiben:
char* bytes = malloc(1024);
In C++ dagegen benötigt man dort zwingend einen reinterpret_cast, weil
malloc einen void-Pointer liefert:
char* bytes = reinterpret_cast<char*>(malloc(1024));
Ein C-Style-Cast ginge für C++ hier natürlich auch, aber in C wird eben
gar kein Cast benötigt. Daher wird dieser häufig weggelassen, was den
Code aber für einen C++-Compiler ungültig werden lässt.

Ein anderer, vielleicht noch offensichtlicherer Punkt sind die neuen
Keywords, die C++ im Vergleich zu C besitzt. In C darf man eine
Funktion problemlos "export()" oder eine Variable "new" nennen, was
in C++ nicht mehr funktioniert.

Autor: arc (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein paar Dinge zu den Function-Points:
- sind eine Software-Metrik die ursprünglich Ende der 70er bei IBM
  entwickelt wurden
- sind mittlerweile ein ISO-Standard (ISO/IEC 20926)
- haben nichts mit Esoterik zu tun (ausser man vergleicht Software aus

  völlig unterschiedlichen Bereichen)
- Function-Points sind nicht Funktionen oder Methoden
- auch HTML bzw. GUIs allgemein lassen so bewerten
http://www.ifpug.com/fpafund.htm
http://www.ifpug.com/Function%20Point%20Training%2...

Autor: Theo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier lesen:

http://de.wikipedia.org/wiki/Standard_Template_Library

Da steht wörtlich:
{
Die bei HP entwickelte STL geht auf sehr alte Wurzeln zurück. Schon
1971 gab es erste Entwürfe generischer Bibliotheken von Dave Musser.
1979 begann Alexander Stepanov mit der Entwicklung seiner Ideen auf
diesem Gebiet. Die Umsetzung in einer großen Programmiersprache
erfolgte jedoch erst 1987 mit der Programmiersprache Ada.

# Und das 7 Jahre vor C++!

Stepanov und Meng Lee, damals Mitarbeiter bei Hewlett-Packard, nannten
die von ihnen entwickelte Programmbibliothek STL. Später wurde diese
Bibliothek gemeinfrei. Danach, im Jahr 1993, also zu einer Zeit als
sich C++ noch in einem frühen Entwicklungsstadium befand, stellten sie
die Bibliothek dem C++-Standardisierungskomitee vor, das daraus im
Laufe der Zeit einen konkreten Vorschlag zur Aufnahme in die
Programmiersprache C++ ausarbeitete, was schließlich zur Integration
führte.
}

ADA kennt generische Datentypen und zwar schon seit 1987. Ergo kann man
davon ausgehen das ADA-95 diese sauber verinnerlicht hat und dies bei
ADA-2005 noch weiter ausgebaut wurde.

Der zu lesende Negativartikel das es nur wenige Entwicklungswerkzeuge
für ADA gibt ist eher darauf zurück zu führen, das ADA nicht so stark
auf kleinen Signalprozessoren gerade in der Haushaltselektronik
vorhanden ist. Schliesslich kann nen Handy nicht alleine aus 10.000
Metern höhe abstürzen oder ne Waschmaschine an irgend ne Raumstation
andocken..:-)

Wenn ich also mal sporadisch kombiniere, frage ich mich wenn es das die
STL 1987 unter ADA schon gab, mit einem Sicherheitstandart an den C/C++
nicht ran kommen, warum ist die Situation heute dann so wie sie ist ?

Die Ada-Entwickler können in dieser Richtung keinesfalls geschlafen
haben, denn die haben ach die Weiterentwicklung der Bibliothek unter
C++ beobachtet um evt. neue features gleich in die generische
Bibliothek von Ada zu übernehmen.

Das ADA diese generischen Möglichkeiten eingebaut hat, weit und lange
vor C++, erklärt auch die hohe Effizienz der Sprache gegenüber C
geschweigedenn C++ und Java, über die sich Karl Heinz wunderte. Die
diskussion wäre kürzer gewesen wenn man sofort in der Wikipedia
nachgesehen hätte!

http://de.wikipedia.org/wiki/Ada_(Programmiersprache)

Und was ADA und ARIANE-5 betrifft steht da wörtlich
Meine Kommentare hinter #

{
Doch solche Spracheigenschaften alleine können offensichtlich Fehler
nicht verhindern: Eine Ariane 5 der ESA ging durch einen arithmetischen
Überlauf verloren, weil der entsprechende Test ausgeschaltet worden war.


Allerdings war das nicht die Schuld der Programmiersprache:

Das Management des Programms hatte verlangt, Code, der für Ariane 4
geschrieben worden war (und dort auch korrekt war), ohne weitere
Überprüfung der Voraussetzungen zu übernehmen.

# Klingt wie bei Eschede mit ~101 Toten bei dem Bahnunfall nicht ?

Da Ariane 5 ein anderes Flugprofil besaß als Ariane 4, musste dieses
Vorgehen scheitern.

# Da fragt sich nur wer dafür die Birne hinhalten mußte,
# diese MammaNager sicherlich nicht...
# Also iss wohl nix mit 1:1 Wiederverwendung,
# egal welche Sprache man nimmt!
}

Außerdem meckern die im nächten Link ebenfalls diese dauernde
Duplizierung von Code bei C++ an, obwohl es bessere ansätze gibt!

http://de.wikipedia.org/wiki/Generische_Programmierung

Zum Vergleich:

http://de.wikipedia.org/wiki/Generische_Programmie...


Last but not least, finde ich diese aufgewühlte Diskussion was auch
beabsichtigt war recht nett, obgleich einige Leute ihre in Richtung
Diskreditierung sprich Beleidigung grenzenden Kommentare nicht für sich
behalten konnten. Aber offensichtlich gilt das, was in anderen Bereichen
auch so ist, wo sich die "Wissenschaft" über Konzepte und Theorien
streitet. Na ja, möge am ende die Vernunft siegen.....

Es gibt zu dieser Diskussion schöne Analogien z.B. aus der Medizin mit
sogar großem historischen Hintergrund hier z.B.

http://www.melhorn.de/Herzinfarkt/index.htm


Theo

Autor: Christoph __ (chris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Außerdem meckern die im nächten Link ebenfalls diese
> dauernde Duplizierung von Code bei C++ an, obwohl es bessere
> ansätze gibt!
Der Java-Ansatz ist nicht "besser" als der von C++, es ist eine
grundlegend andere Herangehensweise. Die Funktionalitäten von
C++-Templates lassen sich nicht im geringsten mit denen der
Java-Generics vergleichen. Der gravierendste Unterschied ist, dass
C++-Templates turing-komplett und nicht auf nicht-eingebaute Typen
beschränkt sind.

AFAIK bieten Java-Generics auch keine teilweise Spezialisierung, d.h.
man kann nicht für bestimmte Typparameter gezielt ohne if-Abfrage
anderes Verhalten festlegen.

C++-Templates und Java-Generics sind einfach zwei unterschiedliche
Konzepte, auch wenn sie auf den ersten Blick ähnlich aussehen und
ähnlich heißen.
Dass beide Konzepte beim ersten Ansehen ähnlich erscheinen, ist IMHO
nicht dem Zufall zuzuschreiben.

Autor: Μαtthias W. (matthias) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

C++ ist mit Sicherheit nicht der Weisheit letzter Schluß aber
eigentliche die einzige objektorientierte Programmiersprache die es auf
beinahe jedem System gibt. C# (bzw. die .NET Laufzeitumgebung) gibt es
eben nur auf x86. Mono läuft zwar auch auf mehr Architekturen aber der
JIT ist außerhalb von x86 wohl alles andere als toll. Ähnliches gilt
für Java. Scriptsprachen (perl, phython, shell usw.) sind zwar auch
beinahe überall verfügbar (der Interpreter ist ja meist in C/C++
geschrieben) aber die Auslieferung des Quelltexts einer Anwendung ist
nicht das Ziel jedes Anwendungsentwicklers.

Ein Großteil der heutzutage erstellten Software läuft auf völlig
anderen Architekturen als x86. Und da die erste verfügbare Hochsprache
für eine Architektur fast immer C ist folgt darauf dann alsbald ein C++
Compiler da sich das Backend (also die eigentliche Generierung von Code
aus dem Syntaxbaum) nicht so sehr von dem des C Compiler unterscheidet.
Das Frontend eines C++ Compilers ist natürlich weit komplexer läßt sich
aber für alle Architekturen verwenden.

Niemand hindert einen aber in C++ darin böse Dinge zu tun:
char a[10];
a[-2] = a[14];
ist auch in C++ gültiger Code.

Zum Thema Templates:
Eigentlich eine schöne "Erfindung" und enorm mächtig. Templates gehen
weit über std::vector<foo> hinaus. Wer mal den richtigen Einsatz von
C++ Templates sehen will sollte sich mal http://www.antigrain.com/
anschauen :-)

Matthias

Autor: einsteiger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sagt mal Leute,
 kennt einer diesen C++? So sauer wie der Thread-opener auf den ist hat
er ihm wohl die Freundin ausgespannt.

Autor: Theo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Sagt mal Leute,
>kennt einer diesen C++? So sauer wie der Thread-opener auf den ist
>hat er ihm wohl die Freundin ausgespannt.

Also die scheinbare Geschichte wie bei alfred Nobel ist es keinesfalls,
denn a.Noble solte angeblichein Mathematiker die tusse ausgespannt haben
(gilt aber als umstritten) weshalb er angeblich für Mathematik keinen
Nobelpreis ausgesetzt hat.

was mich bei dieser Sprache so ankotzt ist das sie so irrsinnig
kryptisch ist und extrem speicher verbraucht. Wollte mir letztens
VisualC++ von MikroMurks runterladen aber als ich las Minimum 192 MB
um es überhaupt starten kann hab ichs gleich wieder gelassen......

Was mich wundert ist das es so lange gedauert hat, fast 20 Jahre bis
endlich c++ in der EmbeddetElektronik gelandet ist. 20 Jahre war C gut
genug für die "Waschmaschinen"........:-) eben klein schlank schnell.
wobei ich allerdings letztens bemerkte das bei ADA auch
Qperatoren-Überladung möglich ist.

Das heist dann so ähnlich wie:

  function +( links :Integer ; rechts Integer ) :Integer


Und es gibt wohl dabei weit mehr Compilerware als zu erst angenommen.

Theo

Autor: Theoid (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> ... Nobel ...

Was dich jetzt auf eine Stufe mit ihm stellt?


Geh weg, bitte!

Autor: Christoph __ (chris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> was mich bei dieser Sprache so ankotzt ist das sie so
> irrsinnig kryptisch ist und extrem speicher verbraucht.

Ersetze "kryptisch" durch "komplex" und ich stimme dir im ersten
Punkt zu. Der zweite ist an den Haaren herbeigezogen; du setzt den
Downloadumfang einer sehr umfangreichen IDE mit dem Speicherverbrauch
der Sprache gleich.
Selbst wenn du diesen Vergleich nicht so meinen solltest: C++
verbraucht nicht mehr Speicher als C, wenn es um äquivalente
Funktionalitäten geht. Wo soll der zusätzliche Speicherverbrauch auch
herkommen?

Autor: Theoid (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vergiss es, da ist Hopfen und Malz verloren. Da kannst du dir den Mund
fusselig reden oder die Finger krumm schreiben, du änderst nichts.

Im Endeffekt darf der OP sich ja auch von C++ angekotzt fühlen, aber
deswegen muss er doch nicht uns allen auf'n Sack gehen.

Vielleicht mal weniger Silber nehmen, evtl. hilft es ja.

Autor: Smörre (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Im Endeffekt darf der OP sich ja auch von C++ angekotzt fühlen, aber
deswegen muss er doch nicht uns allen auf'n Sack gehen."
-> super Lebenseinstellung!
Das ist ungefähr so:
"Ich programmiere in xy, weil da jeder mit programmiert.
Womit die Mehrheit programmiert ist natürlich automatisch besser als
der Rest, das war und ist immer so.
Diesen dummen Kritikern alles erklären zu müssen geht mir auf die
Nerven; ich weiß sowieso, daß das, was ich verwende besser ist und die
Mehrheit weiß das auch, das muß Dir als dummer Kritiker schon als
Begründung reichen - geh mir deshalb nicht auf den Sack"

Tja, ich kenne solche Leute ...




Spezielle Frage an Christoph (Chris), der ja sachlich Unterschiede
zwischen c und c++ aufgezeit hat.
Welchen c++ Compiler würdest Du denn verwenden bzw. empfehlen unten dem
Aspekten Downloadumfang, Funktionalität und eventuell Kompatibilität zu
c (falls das überhaupt Sinn macht), sowie kommerzielle Anwendung, falls
ich mich doch noch mit c++ auseinandersetze?
Reicht ein Gnu c++ Compiler aus oder am Ende doch Visual C++, weil das
jeder hat und in Bezug auf berufliche Aspekte das beste ist.

Autor: Krisu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das mit dem falsch verwerteten Code bei Ariane 5 kenne ich irgendwoher:
Für ne Motorsteuerung hammse bei Bosch auch schon mehrfach alte
Software ausgeliefert, wenn die neue nicht fertig geworden ist. Geht
der Motor halt nicht so optimal. Da arbeiten auch viele noch mit C,
waehrend moderne Abteilungen dieselbe Hardware schon in C++
programmieren.

Autor: Μαtthias W. (matthias) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

auch wenn ich nicht Christoph heiße:
Grundsätzlich ist es IMHO keine schlechte Idee wenn man mit der GCC und
den zugehörigen Tools (make, cvs, ...) umgehen kann oder sie mal
bediehnt hat. Die Chance das man außerhalb der Windowswelt auf diese
Tools trifft ist nicht gerade klein.

Der Visual-C++ Compiler ist in Versionen > 6 eigentlich garnicht so
schlecht. Eher sogar sehr gut im Vergleich zu <= 6 der dann doch so
seine Probleme hatte. Und mit der M$-IDE umgehen zu können ist auch
kein Fehler.

Was die reine Umsetzung der Sprache C++ angeht schenken sich VC++ und
ein aktueller GCC nicht viel und es ist von diesem Standpunkt aus
betrachtet egal welchen man zum Erlernen von C++ verwendet.

Was Performance angeht ist aber wohl der Intel-Compiler (auf x86!)
allen anderen überlegen.

Matthias

Autor: Michael Borrmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
habe jetzt nur einen Teil gelesen.

Programmiere selber seit 11 Jahren in C/C++, und habe mich ehrlich
gesagt nie mit beiderlei Sprachen anfreunden können.

Bevor ich C programmiere, benutze ich lieber Assembler, und bevor ich
was mit C++ anfange aufzubauen nehme ich lieber Java oder C# her.

Die Sprachen C und C++ taugen meiner Meinung nach beide nichts.

Autor: Christoph __ (chris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Smörre:
Ich kann Matthias nur zustimmen. Es schadet nicht den g++ zu kennen.
Visual-C++ bringt eine IDE mit, die den Einstieg vereinfacht. g++ hat
eine offenere Lizenz, aber beide Compiler sind inzwischen kostenlos
erhältlich (VC++ in der "Express Version") [1].

In der Umsetzung des C++-Standards sind mittlerweile beide Compiler
ziemlich ausgereift. Wenn du denen eine Datei mit Endung .c gibst oder
das manuell einstellst, können beide Compiler problemlos C-Code
kompilieren. Der g++ kann soweit ich weiß den neuesten C-Standard, der
Visual C++ hängt da noch ein wenig hinterher.

Solange du keine hersteller-spezifischen Bibliotheken wie MFC (für
VC++) verwendest, sollte sich ein Programm auch mit geringem
Portier-Aufwand auf beiden Compilern kompilieren lassen. Allzu
entscheidend ist die Wahl zwischen g++ und VC++ also nicht.

Ich würde für den Einstieg aufgrund der gut zu bedienenden IDE eher zu
Visual C++ raten, muss aber dazu sagen, dass ich die Express Version
nie selbst eingesetzt habe. Außerdem gibt es inzwischen mit
Code::Blocks[2] auch für Windows eine ziemlich gute g++-IDE.

Was man auf keinen Fall machen sollte, was Matthias aber auch schon
erwähnt hat, ist Visual C++ 6 einzusetzen. Die IDE ist zwar nicht
schlecht, aber der Compiler ist aus heutiger Sicht eine mittlere
Katastrophe. Immer mehr moderne C++-Bibliotheken stellen deswegen
übrigens nach und nach die Unterstützung von VC6 ein. Leider war dieser
Compiler früher sehr verbreitet und auf vielen Heft-CDs zu finden.

[1] http://msdn.microsoft.com/vstudio/express/support/install/
[2] http://www.codeblocks.org/

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.