Abo
  1. Foren
  2. Kommentare
  3. Software-Entwicklung
  4. Alle Kommentare zum Artikel
  5. › Entwicklungsumgebungen…

C wird auch in Zukunft viel genutzt

Anzeige
  1. Thema

Neues Thema Ansicht wechseln


  1. C wird auch in Zukunft viel genutzt

    Autor: emergency 23.03.13 - 10:52

    Viele meinen C wäre veraltet und würde sterben, aber das ist falsch. Zwar werden auf schnellen Embedded Systemen heute immer öfter Linuxderivate verwendet, aber es wird immer einen riesigen Stamm an kleinen Prozessoren geben, die besser nicht in C++ sondern in C programmiert werden sollten.
    Classische ITler mögen diesen Usecase nicht verstehen, aber es gibt wirklich noch viele Systeme, die sehr Hardwarenah arbeiten und als Realtime System kann man C++ auf einem 8-, 16-, 24- oder 32-Bit Automotiveprozessor (Beispiel) nicht wirklich effizient nutzen.
    Leider lernen immer weniger junge Leute ordentliches C zu schreiben. Das führt oft dazu, dass C++ mit C emuliert wird (Pointer Strukturen etc...) was weder leserlich noch effizient ist.
    Im Embedded Bereich arbeitet man sehr viel mit globalen Variablen um die Effizienz zu steigern (wenig Stack Operationen), auch das Konzept ist vielen unbekannt. Dynamische Speicherzuweisung wird dort nicht benutzt, Interrupts dagegen ohne Ende.
    Ich war etwas schockiert als ich mir die Arduino Bibliotheken angesehen habe, da ich feststellte, dass diese wie PC Code geschrieben sind... auf einem 8-bitter! Alles war C++ und es wurde fast keine Interrupts verwendet. Effizient kann das ja nicht sein. Man darf nicht vergessen, das C++ in den meisten Fällen durch die Klassenstrukturen mehr RAM braucht. Nur wenn man gerade mal 32kB davon hat, und in Echtzeit CAN Kommunikation machen soll und einen EC-Motor Steuern soll, dann sollte man doch sparsam damit umgehen.

  2. Es ist wie immer

    Autor: Anonymer Nutzer 23.03.13 - 11:06

    Es ist einfach wie immer im Leben: das passende Werkzeug für die passende Gelegenheit.

    Egal ob Java (ja, das habe ich wirklich gesagt), C, C++ oder sonstige Sprachen: sie alle können sinnvoll benutzt werden, wenn man sie in der richtigen Situation einsetzt. Ich würde ja auch keinen Nagel mit einer Säge ins Holz schlagen. Genau das passiert bei Programmiersprachen aber häufig: nimm genau X, alles andere ist Schrott. Ohne das überhaupt gefragt worden wäre, was eigentlich genau gemacht werden soll.

    Ich studiere nur Mathe, bin also meilenweit von der Erfahrung entfernt die Informatiker haben aber selbst uns wurde das schon im Studium eingebläut: ohne Scheuklappen und immer die richtige Programmiersprache verwenden. Wir haben C, C++ und Java im Studium gelernt. Privat habe ich mir dann auch Python und Perl angeschaut und es gibt noch eine Menge anderer Sprachen, die ich mir einmal ansehen sollte.



    1 mal bearbeitet, zuletzt am 23.03.13 11:07 durch Freakgs.

  3. Re: C wird auch in Zukunft viel genutzt

    Autor: QDOS 23.03.13 - 13:59

    emergency schrieb:
    --------------------------------------------------------------------------------
    > Man darf nicht vergessen, das C++ in den meisten Fällen durch die Klassenstrukturen mehr RAM braucht.
    Das sollte nur wegen der Vtables bei dynamisch gebundenen Memberfunktionen passieren, da statische gebundene Memberfunktionen in Assembler das selbe sind wie freistehende Funktionen...

    Auch dein Speicherargument finde ich mehr als fadenscheinig, da man in C++ nicht gezwungen wird auf globale Variablen zu verzichten, bzw. dynamische Speicherzugriffe durchführen muss (in meinen Programmen findet man Beispielsweise nicht ein malloc/new/etc.)...

  4. Re: C wird auch in Zukunft viel genutzt

    Autor: theonlyone 23.03.13 - 14:17

    QDOS schrieb:
    --------------------------------------------------------------------------------
    > emergency schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Man darf nicht vergessen, das C++ in den meisten Fällen durch die
    > Klassenstrukturen mehr RAM braucht.
    > Das sollte nur wegen der Vtables bei dynamisch gebundenen Memberfunktionen
    > passieren, da statische gebundene Memberfunktionen in Assembler das selbe
    > sind wie freistehende Funktionen...
    >
    > Auch dein Speicherargument finde ich mehr als fadenscheinig, da man in C++
    > nicht gezwungen wird auf globale Variablen zu verzichten, bzw. dynamische
    > Speicherzugriffe durchführen muss (in meinen Programmen findet man
    > Beispielsweise nicht ein malloc/new/etc.)...

    Es ist durchaus möglich "relativ" effektiv mit C++ zu arbeiten, du kannst schon etwas rausholen mit reinem C, frage die sich stellt ob das "wichtig" ist (wenn ja, nutze C).

    Die ganze idee von Hochsprachen und weiter abstrakten ist ja schlichtweg die Verständlichkeit und die möglichkeit einfachere Strukturen für komplexere Probleme nutzen zu können (Klassenstrukturen helfen der Übersicht, helfen der Sicherheit und verständlichkeit, "essentiell" wichtig sind sie aber nicht).

    Jeder Overhead ist eben overhead, wenn die Priorität Performance ist, verzichtet man lieber darauf, dadurch wird es u.U. natürlich ne ganze Ecke mehr Low-Level, auf der man als "gewöhnlicher" Entwickler garnicht mehr denken will, da nimmt man lieber existierende Frameworks die sich darum kümmern (was in aller regel auch besser ist).

    Entwickelt man aber wirklich etwas so spezielles für ein Steuergerät in einem Auto, das ganz besondere Ansprüche hat und die Performance absolut ausreizen will, dann bietet sich C einfach an, das gleiche mit C++ zu machen ist schlichtweg langsamer, auch wenn nicht "viel" langsamer ; manche Szenarien wird man so gut hinbekommen das "kaum" ein nennenswerter unterschied existert, aber selbst die 2% die man rausquätschen kann, "können" es wert sein (gerade wenn man X viele Steuerungen hat, und jede holt nur 2% raus, addiert sich das hoch).


    Das große Anwendungen in C ziemlicher blödsinn sind erklärt sich von selbst, das wird schlichtweg extrem unübersichtlich, weil absolut niemand die ganze Anwendung mehr überblickt, alles steht mehr oder weniger für sich selbst und wenn mal Teile verändert oder ausgetauscht werden sollen und dann plötzlich Probleme auftauchen sieht es Düster aus, das wird komplett unökonomisch.


    Aber klar ist, für spezielle Anwendungen muss auch das richtige Werkzeug her, was nicht heißt es geht nicht mit anderen Werkzeugen, es ist schlichtweg nur nicht sinnvoll.

    Das beispiel mit der Säge und dem Nagel gefällt mir da sehr gut, das verdeutlicht es eigentlich perfekt, so das es jeder verstehen sollte.

    Ist die Performance nicht wichtig in einem programm "kann" man tatsächlich pauschal einfach das Werkzeug nehmen das einem am besten gefällt, bzw. mit dem man selbst am besten umgehen kann ; das ist dann auch ökonomischer als sich für jedes Projekt in komplett andere Sprachen einzuarbeiten und dann wenns blöd läuft Fehler zu machen die man ansonsten vermeiden könnte (in der mathematik sind das eher Probleme die auf Performance setzen, also durchaus durch die bank "spezielle" Probleme).

  5. Re: C wird auch in Zukunft viel genutzt

    Autor: QDOS 23.03.13 - 14:52

    Erklär mir mal wo eine Klasse mit statisch gebundenen Memberfunktionen langsamer ist als freistehende Funktionen...

    Ich geh mal ob des Einsatzgebietes davon, dass wir hier von einer C/C++-Implementierung OHNE Standardbibliothek sprechen...

  6. Re: C wird auch in Zukunft viel genutzt

    Autor: schily 23.03.13 - 21:23

    QDOS schrieb:
    -------------------------------------------------------------------------------->
    > Auch dein Speicherargument finde ich mehr als fadenscheinig, da man in C++
    > nicht gezwungen wird auf globale Variablen zu verzichten, bzw. dynamische
    > Speicherzugriffe durchführen muss (in meinen Programmen findet man
    > Beispielsweise nicht ein malloc/new/etc.)...

    Nun, typischerweise ist erzeugt C++ Code bei gleicher menge an Quellcode und gleichen Funktionen dreimal soviel Binärcode als das äquivalente C-Programm.

    Der C++ Code ist darüberhinaus meist schlechter wartbar als C Code.

  7. Re: C wird auch in Zukunft viel genutzt

    Autor: emergency 23.03.13 - 23:56

    Prinzipiell müsste das zwar nicht sein, aber bei mir im Betrieb wurden mehrfach Vergleiche mit verschiedenen Compilern und Plattformen gefahren und für äquivalente Software Funktion war der Assembler aus dem C-Compiler immer um Längen besser als die statischen C++ compilierten binaries. Das schlägt sich dann auch schnell mal auf RAM und Last aus, nicht nur auf ROM.

  8. Re: C wird auch in Zukunft viel genutzt

    Autor: QDOS 24.03.13 - 03:10

    emergency schrieb:
    --------------------------------------------------------------------------------
    > Prinzipiell müsste das zwar nicht sein, aber bei mir im Betrieb wurden
    > mehrfach Vergleiche mit verschiedenen Compilern und Plattformen gefahren
    > und für äquivalente Software Funktion war der Assembler aus dem C-Compiler
    > immer um Längen besser als die statischen C++ compilierten binaries. Das
    > schlägt sich dann auch schnell mal auf RAM und Last aus, nicht nur auf ROM.
    Hört sich nach schlechtem C++ Compiler an...

  9. Re: C wird auch in Zukunft viel genutzt

    Autor: QDOS 24.03.13 - 03:12

    schily schrieb:
    --------------------------------------------------------------------------------
    > Nun, typischerweise ist erzeugt C++ Code bei gleicher menge an Quellcode
    > und gleichen Funktionen dreimal soviel Binärcode als das äquivalente
    > C-Programm.
    Quelle?

    Nach deiner Logik ist also:

    int main() { std::printf("Hello World!"); }

    3 mal so lange wenn ich es mit einem C++ Compiler übersetzte, als wenn ich einen C Compiler [ohne std::] verwende...

  10. Re: C wird auch in Zukunft viel genutzt

    Autor: schily 24.03.13 - 14:01

    QDOS schrieb:
    --------------------------------------------------------------------------------
    > schily schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Nun, typischerweise ist erzeugt C++ Code bei gleicher menge an Quellcode
    > > und gleichen Funktionen dreimal soviel Binärcode als das äquivalente
    > > C-Programm.
    > Quelle?
    >
    > Nach deiner Logik ist also:
    >
    > int main() { std::printf("Hello World!"); }
    >
    > 3 mal so lange wenn ich es mit einem C++ Compiler übersetzte, als wenn ich
    > einen C Compiler verwende...

    Wenn das für Dich typischer Code ist, dann träum weiter vom Programmieren....

  11. Re: C wird auch in Zukunft viel genutzt

    Autor: theonlyone 24.03.13 - 14:03

    QDOS schrieb:
    --------------------------------------------------------------------------------
    > emergency schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Prinzipiell müsste das zwar nicht sein, aber bei mir im Betrieb wurden
    > > mehrfach Vergleiche mit verschiedenen Compilern und Plattformen gefahren
    > > und für äquivalente Software Funktion war der Assembler aus dem
    > C-Compiler
    > > immer um Längen besser als die statischen C++ compilierten binaries. Das
    > > schlägt sich dann auch schnell mal auf RAM und Last aus, nicht nur auf
    > ROM.
    > Hört sich nach schlechtem C++ Compiler an...

    Es gibt Compiler die optimieren selbstständig den Code auf "C" wenn sie sehen das nichts aus C++ spezifisches verwendet werden muss.

    Das hat genau den Effekt das dein Ergebnis dann C ist.


    Wenn man Bibliotheken includiert, von denen man letztlich garnicht alles braucht, ist das schlichtweg unnötig.

  12. Re: C wird auch in Zukunft viel genutzt

    Autor: QDOS 24.03.13 - 16:45

    ?? Hab ich nicht behauptet. Deine Behauptung war: "Nun, typischerweise ist erzeugt C++ Code bei gleicher menge an Quellcode und gleichen Funktionen dreimal soviel Binärcode als das äquivalente C-Programm."

    Ich könnte noch gerne richtigen Code mit dir besprechen, aber vorher hätte ich gerne mal eine Beweis für deine All-Aussage... (Die wurde ja gerade durch ein einziges Gegenbeispiel Lügen gestraft...)

  13. Re: C wird auch in Zukunft viel genutzt

    Autor: QDOS 24.03.13 - 16:52

    theonlyone schrieb:
    --------------------------------------------------------------------------------
    > Es gibt Compiler die optimieren selbstständig den Code auf "C" wenn sie sehen das nichts aus C++ spezifisches verwendet werden muss.
    Das tritt dann also bei keinem typischen C++ Code ein, da schon Sachen wie Konstruktoren und Destruktoren in C nicht vorhanden sind...

    > Wenn man Bibliotheken includiert, von denen man letztlich garnicht alles
    > braucht, ist das schlichtweg unnötig.
    Die C++ Standardbibliothek ist in weiten Teilen mit Templates definiert. Aus Templates wird nur bei der Verwendung Code generiert. Du kannst daher beliebig viele Header inkludieren und die können beliebig viele Templates enthalten, das ist dem Compiler komplett egal bei der Codegeneration, da er einfach alles, was nicht verwendet wird, ignoriert.

    Nebenbei tritt bei Templates oft Inlining auf, da die Implementierung des Templates direkt anstelle des Aufrufs expandiert werden kann, somit entfällt dann der Funktionsaufruf - denn sogar der kann für bestimmte Anwendungsfälle zu teuer sein...

  14. Re: C wird auch in Zukunft viel genutzt

    Autor: bstea 24.03.13 - 16:54

    Probiers mal selbst aus:
    #include <stdio.h>
    int main() {printf("Hello");}

    Schon bei diesem simplen Beispiel ist die C++ Ausgabe ca. 500Bytes größer, warum auch immer(getestet mit mingw 4.6.2).

    --
    Erst wenn der letzte Baum gefällt, der letzte Fluss gestaut und der letzte Fisch gefangen ist, werdet ihr feststellen, dass man Biber nicht essen kann!

  15. Re: C wird auch in Zukunft viel genutzt

    Autor: QDOS 24.03.13 - 20:27

    Den Code kannst du in der Form sowohl durch einen C als auch einen C++ Compiler schießen, wenn da was unterschiedliches raus kommt ist einer der beiden Compiler eindeutig defekt...

    Außer du willst jetzt auf iostreams heraus, die eindeutig mehr machen als stdio und aufgrund einiger aus heutiger Sicht schlechter Designentscheidungen (virtuelle Funktionen) langsamer sind als stdio - wobei wir wieder bei der Bibliothek wären und nicht der Sprache an sich...

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Anzeige
Stellenmarkt
  1. nobilia-Werke J. Stickling GmbH & Co. KG, Verl
  2. ALPMA Alpenland Maschinenbau GmbH, Rott am Inn
  3. Empirius GmbH, Kirchheim bei München
  4. Haufe Gruppe, Freiburg im Breisgau

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. (u. a. Jurassic World, Creed, Die Unfassbaren, Kingsman, John Wick, Interstellar, Mad Max)
  2. 99,00€
  3. 189,00€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Forza Horizon 3 im Test: Autoparadies Australien
Forza Horizon 3 im Test
Autoparadies Australien
  1. Die Woche im Video Schneewittchen und das iPhone 7
  2. Forza Motorsport 6 PC-Rennspiel Apex fährt aus der Beta
  3. Microsoft Play Anywhere gilt für alle Spiele der Microsoft Studios

Interview mit Insider: Facebook hackt Staat und Gemeinschaft
Interview mit Insider
Facebook hackt Staat und Gemeinschaft
  1. Facebook 100.000 Hassinhalte in einem Monat gelöscht
  2. Nach Whatsapp-Datentausch Facebook und Oculus werden enger zusammengeführt
  3. Facebook 64 Die iOS-App wird über 150 MByte groß

Starship Technologies: Es wird immer nach Diebstahl und Vandalismus gefragt
Starship Technologies
Es wird immer nach Diebstahl und Vandalismus gefragt
  1. Recore Mein Buddy, der Roboter
  2. Weltraumforschung DFKI-Roboter soll auf dem Jupitermond Europa abtauchen
  3. Softrobotik Oktopus-Roboter wird mit Gas angetrieben

  1. Dice: Kampagne von Battlefield 1 spielt an vielen Fronten
    Dice
    Kampagne von Battlefield 1 spielt an vielen Fronten

    Bislang hat sich Electronic Arts bei der Marketingkampagne für Battlefield 1 auf den Multiplayermodus konzentriert - aber es gibt auch eine Kampagne. Der offizielle Trailer zeigt, wie Helden an mehreren Fronten im Ersten Weltkrieg kämpfen.

  2. NBase-T alias 802.3bz: 2.5GbE und 5GbE sind offizieller IEEE-Standard
    NBase-T alias 802.3bz
    2.5GbE und 5GbE sind offizieller IEEE-Standard

    Der Prozess ist abgeschlossen: Die beiden Stufen zwischen 1- und 10-Gigabit-Ethernet sind nicht mehr proprietär, sondern ein Standard. Die NBase-T-Alliance ist vor allem froh darüber, dass alles so schnell ging.

  3. Samsung-Rückrufaktion: Bereits 60 Prozent der Note-7-Geräte in Europa ausgetauscht
    Samsung-Rückrufaktion
    Bereits 60 Prozent der Note-7-Geräte in Europa ausgetauscht

    Die europäischen Besitzer des Galaxy Note 7 tauschen ihre Geräte offenbar deutlich schneller aus, als die US-Amerikaner. Schon Anfang Oktober könnte der Prozess abgeschlossen sein.


  1. 20:57

  2. 18:35

  3. 18:03

  4. 17:50

  5. 17:41

  6. 15:51

  7. 15:35

  8. 15:00