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. über Ratbacher GmbH, München
  2. Robert Bosch GmbH, Bühl
  3. QSC AG, Hamburg
  4. BAGHUS GmbH, München

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. 2,99€ (ohne Prime bzw. unter 29€ Einkauf zzgl. 3€ Versand)
  2. (u. a. Dark Souls III für 24,99€, Darkosuls II: Scholar of the First Sin für 8,99€, Bioshock...


Haben wir etwas übersehen?

E-Mail an news@golem.de


Limux: Die tragische Geschichte eines Leuchtturm-Projekts
Limux
Die tragische Geschichte eines Leuchtturm-Projekts
  1. Limux München prüft Rückkehr zu Windows
  2. Limux-Projekt Windows könnte München mehr als sechs Millionen Euro kosten
  3. Limux Münchner Stadtrat ignoriert selbst beauftragte Studie

Wacoms Intuos Pro Paper im Test: Weg mit digital, her mit Stift und Papier!
Wacoms Intuos Pro Paper im Test
Weg mit digital, her mit Stift und Papier!
  1. Wacom Brainwave Ein Graph sagt mehr als tausend Worte
  2. Canvas Dells Stift-Tablet bedient sich bei Microsoft und Wacom
  3. Intuos Pro Wacom verbindet Zeichentablet mit echtem Papier

Bundesnetzagentur: Puppenverbot gefährdet das Smart Home und Bastler
Bundesnetzagentur
Puppenverbot gefährdet das Smart Home und Bastler
  1. My Friend Cayla Eltern müssen Puppen ihrer Kinder zerstören
  2. Matoi Imagno Wenn die Holzklötzchen zu dir sprechen
  3. Smart Gurlz Programmieren lernen mit Puppen

  1. Hardlight VR Suit: Vibrations-Weste soll VR-Erlebnis realistischer machen
    Hardlight VR Suit
    Vibrations-Weste soll VR-Erlebnis realistischer machen

    Mit dem Hardlight VR Suit will das Start-Up Nullspace VR eine einfach anpassbare Weste auf den Markt bringen, deren zahlreiche kleine Vibrations-Pads Körpertreffer in virtuellen Welten simulieren sollen. Diese Motoren sollen so fein arbeiten können, dass auch Regen fühlbar wird.

  2. Autonomes Fahren: Der Truck lernt beim Fahren
    Autonomes Fahren
    Der Truck lernt beim Fahren

    Lass mal das neuronale Netzwerk steuern: Das US-Unternehmen Embark hat ein System für autonomes Fahren für einen Truck entwickelt. Das System basiert auf Deep Learning.

  3. Selektorenaffäre: BND soll ausländische Journalisten ausspioniert haben
    Selektorenaffäre
    BND soll ausländische Journalisten ausspioniert haben

    Reuters, BBC, New York Times: Wichtige ausländische Medien sollen vom Bundesnachrichtendienst bespitzelt worden sein. Journalistenvertreter und die Opposition sind empört.


  1. 18:02

  2. 17:43

  3. 16:49

  4. 16:21

  5. 16:02

  6. 15:00

  7. 14:41

  8. 14:06