PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Buchtipp für c-Programmierung


Flyinglosi
2016-05-14, 17:48:31
Hi Leute,

ich bin beruflich häufig mit c-Programmierung (hardwarnahe auf arm basierten embedded Systemen sowie unix/linux) beschäftigt. Ich habe Mechatronik studiert und bin somit inkl. ein paar Jahren Berufserfahrung kein Einsteiger mehr. Jedoch stört mich mein fehlendes Wissen über Standards bzw. ist mein Stil wohl eher mit Quick&Dirty zu beschreiben.

Deswegen suche ich nach einem Buch, welches nochmal sauber die relevanten Grundlagen, sowie Empfehlungen für moderne c-Programmierung zusammenfasst. Auch die die Thematik der automatisierten Testroutinen sollte darin behandelt werden. Da meine Literaturliste aktuell schon sehr lange ist, wäre eine kompakte Behandlung (kein 1000 Seiten Wälzer) von Vorteil.

Habt ihr da einen passenden Tipp parat?

Danke im Vorhinein

Mit freundlichen Grüßen

Stephan

Simon
2016-05-14, 19:39:35
21st Century C.

Behandelt C11. Braucht einen halbwegs aktuellen Compiler. Visual Studio taugt nicht, braucht entweder Cygwin oder ein Linux System/VM.
Der Autor kommt aus der Praxis und behandelt Grundlagen und viele Themen, die eher akademische Bücher außen vor lassen wie Makros und Speichermanagement.
Nach knapp 10 Jahren als C-Programmierer stimme ich mit vielen Sachen überein.

Flyinglosi
2016-05-14, 23:13:10
Danke für den Tipp, allerdings erschienen mir die Rezessionen zu dem Buch ein wenig zwiespältig.

Ich habe mich jetzt erstmal für "The C programing language" entschieden, da es ja scheinbar als Standard-Werk in diesem Bereich gilt.

Inwieweit hier alle für mich relevanten Bereiche behandelt werden, wird sich zeigen.

mfg

Stephan Lanser

Simon
2016-05-14, 23:34:39
zwiespältig??

4.5 Sterne:

http://www.amazon.com/21st-Century-Tips-New-School/dp/1491903899/ref=sr_1_1?ie=UTF8&qid=1463261483&sr=8-1&keywords=21st+century+c

Das kann ich genau so unterschreiben:

This is a book that gives a good refresher course in C. The author has a good knowledge of the history and structure of the language. He warns of the pitfalls and advantages throughout the book.

The book is not the average dry textbook. The style is light and readable, without being "jokey". I did not get bored with it, as I have with some other books.

The book not only covers C, but the tools needed to write good code. This includes Make, Git, GDB, autotools, and valgrind. (Among others.) It also covers a number of useful libraries that most C books ignore. (It does not suffer from the "here are the basics, fend for yourself" style of book.)

The OSes covered are Windows, Mac and Linux. It includes extra help for Windows and Mac, probably because if you are using those OSes, you will need it. (Linux has a much more complete toolchain for writing C code.) There is some mention of setting up a BSD environment, but much of that is covered in the Mac references. (OS X is BSD.)

The version I have is the 2nd edition. It covers C11 and some newer features of the OS and compilers that C programmers need to be aware of. It does not contain everything you need to know, but if it did it would be more than three times the length. The coding environment has been changing a great deal in the last 5-6 years, especially on Linux. This does not try to cover the OS interface issues such as UDEV or DBUS or the like. It is trying to show you more of the changes to the language, using the libraries as an example, not the changes to the overall libraries.

This is not the only book you need to become a good C programmer, but it is one that you will want to have in your library.


Ob da jetzt ein 16 Jahre altes Buch - was dann natuerlich kein aktuelles C11 kennt - besser ist, bezweifel ich.

Oid
2016-05-15, 04:03:16
Ich habe mich jetzt erstmal für "The C programing language" entschieden, da es ja scheinbar als Standard-Werk in diesem Bereich gilt.

Um Himmels Willen, bitte nicht.

Das Buch kann man sich mal geben, weil von den C-Schöpfern und voll nerdig und so, aber vor allem im embedded Bereich hat das "K&R-C" nicht viel Relevanz.

Zu embedded C kann ich dir den MISRA-2012 Standard empfehlen. Da lernt man echt viel über die dunklen Ecken von C. Und wenn du beruflich eh was mit embedded C machst, wirst du eh früher oder später mit MISRA zu tun haben. Der Titel hört sich auch trockener an als er ist, denn man findet darin viele Beispiele und gute Erklärungen.

Dann würde ich noch einschlägige Blogs empfehlen, in denen es speziell um embedded C geht, z. B. embeddedgurus.com.

Wirklich gute Literatur, im klassischen Sinn, ist mir zu embedded C nicht bekannt. Aber lieber sowas wie "21st Century C" als den alten K&R Schinken.

Ectoplasma
2016-05-15, 09:58:50
Mal eine Frage an euch embedded Spezies. Gibt es eigentlich immer noch so wenig C++ in diesem Bereich oder täusche ich mich? Und was sind die Gründe für C++ oder gegen C++? Sorry for OT.

Flyinglosi
2016-05-15, 11:39:38
zwiespältig??

4.5 Sterne:

http://www.amazon.com/21st-Century-Tips-New-School/dp/1491903899/ref=sr_1_1?ie=UTF8&qid=1463261483&sr=8-1&keywords=21st+century+c

Das kann ich genau so unterschreiben:


Ob da jetzt ein 16 Jahre altes Buch - was dann natuerlich kein aktuelles C11 kennt - besser ist, bezweifel ich.
Ich hab es jetzt ohnehin mitbestellt. Bei dem Preis ist wenig verloren bzw. waren die von mir gefundenen Rezessionen wohl extrem pessimistisch formuliert. Danke für deinen Tipp.

Oid
2016-05-15, 13:31:22
Mal eine Frage an euch embedded Spezies. Gibt es eigentlich immer noch so wenig C++ in diesem Bereich oder täusche ich mich? Und was sind die Gründe für C++ oder gegen C++? Sorry for OT.

C++ ist schon immernoch eher eine Randerscheinung. Klar hätte C++ auch für den embedded Bereich viele Vorteile. Wie oft ich z. B. alleine schon das Überladen von Operatoren vermisse. Performance-Gründe sprechen eigentlich auch nicht gegen C++.

Dass embedded code meistens noch in C geschrieben wird, ist wahrscheinlich eher Gewohnheit. Und über die Jahre ist C ja schon ziemlich gut gezähmt worden (Coding-Standards, statische Code-Analyse, ausgereifte Compiler, ...).
Embedded Systems Entwickler sind ja doch meistens Ingenieure und weniger Informatiker. Es bekommt wahrscheinlich wirklich jeder Ing. mal C beigebracht, C++ wird dann vielleicht nur noch bei den E-Technikern oder Technischen Informatikern gelehrt.

Ectoplasma
2016-05-15, 18:54:32
@Oid, danke für Erklärung. Das ist schade, das C++ wenig genutzt wird im embedded Bereich. Man hätte so viele Vorteile.

Simon
2016-05-15, 20:53:16
@Oid, danke für Erklärung. Das ist schade, das C++ wenig genutzt wird im embedded Bereich. Man hätte so viele Vorteile.
Und auch Nachteile, nicht vergessen.

Ectoplasma
2016-05-15, 23:13:06
Und auch Nachteile, nicht vergessen.

Danach fragte ich ja weiter oben. Welche gibt es denn? Mir fallen nur wenige Dinge ein, wie z.B. V-Tables und deren Speicherbedarf, oder z.B. die Standard-Libs, die releativ groß sind.

Foobar2001
2016-05-15, 23:35:43
Muss man alles nicht verwenden. C++ hat keine Nachteile wenn man nur ein Subset verwendet. Das ist alles FUD.

Simon
2016-05-16, 05:40:20
Danach fragte ich ja weiter oben. Welche gibt es denn? Mir fallen nur wenige Dinge ein, wie z.B. V-Tables und deren Speicherbedarf, oder z.B. die Standard-Libs, die releativ groß sind.
Kleinere und einfach zu schreibende Compiler und Runtimes. Static initialization ist sicher in C, nicht in C++. Code von verschiedenen Compilern kann problemlos auf einem System kombiniert werden, da gleiches ABI. Es ist viel einfacher Bindings fuer andere Sprachen zu erstellen. C-Programme zu kompilieren und linken ist wesentlich schneller als C++. C hat mehr und bessere Tools. Compiler-Warnungen oder Fehler bei Templates sind einfach nur :freak:
Ich war bei etlichen grossen und kleinen Firmen bei denen Boost und teilweise STL verboten ist, unter anderem weil das Zeug nicht wartbar ist und Compile und Link Times massiv erhoeht. Dazu kommen Verbote von Exceptions, RTTI und die meisten Template-Implementierungen. Nennt dann auch keiner mehr "C++" sondern "C+" oder "C++ light" :freak:

Meine aktuelle Codebasis hat 150MiB Code, das meiste davon in C+. Inheritance an einigen Stellen und massive Header Files sind vom Framework leider vorgegeben. Die 80% C-like code compilieren in Sekunden, der C++-Code braucht das doppelte. Die Linker-Zeit is total dominiert vom C++-Code. Alles auf HP Z640, 64GB RAM, SSD.

Vieles davon hat nicht direkt mit C++ an sich zu tun, sondern mit dem Design und Implementierungen von der Standard Bibliothek und anderen Bibliotheken. Um gute und effiziente Libraries zu implementieren, braucht man jemanden, der sich sehr gut damit auskennt. Egal, ob in C oder C++. C macht es einfacher.


Linus Torvalds zu dem Thema:
http://thread.gmane.org/gmane.comp.version-control.git/57643/focus=57918


Muss man alles nicht verwenden. C++ hat keine Nachteile wenn man nur ein Subset verwendet. Das ist alles FUD.
Genau, C++ mit "nur einem Subset" ist zum Einen kein vollstaendiges C++ mehr und zum Anderen waere es die einzige Technologie dieser Welt ohne Nachteile ;D

Monger
2016-05-16, 07:31:55
Danach fragte ich ja weiter oben. Welche gibt es denn? Mir fallen nur wenige Dinge ein, wie z.B. V-Tables und deren Speicherbedarf, oder z.B. die Standard-Libs, die releativ groß sind.
Ich zitiere mal einen Kollegen, als wir gemeinsam über die kryptischen Name-Mangling Meldungen des C++ Compilers gerätselt haben:
"Ich habe zuhause den C Standard stehen. Das ist ein handliches Buch, lässt sich locker in einem Tag durchlesen."

Schau dir das selbe mal für C++ an. Der C++ Standard ist gemessen an JEDER aktuellen Sprache absurd umfangreich. Den sinnvoll auf ein Subset runterzubrechen der mit C vergleichbar ist, ist enorm aufwändig. Warum dann nicht gleich C nehmen?

Foobar2001
2016-05-16, 07:47:46
Genau, C++ mit "nur einem Subset" ist zum Einen kein vollstaendiges C++ mehr und zum Anderen waere es die einzige Technologie dieser Welt ohne Nachteile ;D
Selbst das Subset ist immer noch um Welten besser als pures C.

Schau dir das selbe mal für C++ an. Der C++ Standard ist gemessen an JEDER aktuellen Sprache absurd umfangreich. Den sinnvoll auf ein Subset runterzubrechen der mit C vergleichbar ist, ist enorm aufwändig. Warum dann nicht gleich C nehmen?
Weil reines C wesentlich unproduktiver und fehleranfaelliger ist.

RAII geht mit C nicht. Man hat keine STL. Referenzen gibt es nicht. Klassen fuer abstrakte Datentypen gibt es nicht. Mit C-Strings will ich erst gar nicht anfangen.

Ectoplasma
2016-05-16, 09:24:11
Danke für eure Antworten.

Meine Frage weiter oben war wohl nicht so genau gestellt. Ich zitiere mich mal selbst:
Mal eine Frage an euch embedded Spezies. Gibt es eigentlich immer noch so wenig C++ in diesem Bereich oder täusche ich mich? Und was sind die Gründe für C++ oder gegen C++? Sorry for OT.
Ich stelle die Frage mal um.

Welche Nachteile von C++ gibt es speziell im embedded Bereich?

Static initialization ist sicher in C, nicht in C++.
Die statische Scoped Initialisierung ist nicht Thread Safe. Wo noch?

Code von verschiedenen Compilern kann problemlos auf einem System kombiniert werden, da gleiches ABI. Es ist viel einfacher Bindings fuer andere Sprachen zu erstellen.
Das ist ein guter Punkt. Diese Tatsache stört mich seit Jahren. Leider wird das Problem der ABI Unverträglichkeit wohl nie verschwinden.

C-Programme zu kompilieren und linken ist wesentlich schneller als C++.
Wenn man mehr Features nutzt, darf eine Kompilierung auch mal länger dauern. Mal clang benutzt? Das Teil rennt.

C hat mehr und bessere Tools. Compiler-Warnungen oder Fehler bei Templates sind einfach nur :freak:
Bessere Tools? Mit den Compiler-Warnungen von C++ Templates habe ich keine so großen Probleme mehr, aber es stimmt, sie sind oft sehr kryptisch.

Dazu kommen Verbote von Exceptions, RTTI und die meisten Template-Implementierungen.
Ok, RTTI und Exceptions verbraten auch ein wenig Resourcen. Aber gerade mit C++ Exceptions kann eine Software massiv sicherer und wartbarer gemacht werden. Es gibt Compiler, die Zero Overhead bei Exceptions haben.

Um gute und effiziente Libraries zu implementieren, braucht man jemanden, der sich sehr gut damit auskennt. Egal, ob in C oder C++. C macht es einfacher.
Da stimme ich dir voll und ganz zu. Eine gute objektorientierte API zu schreiben, ist eine sehr schwierige Aufgabe, die gerne unterschätzt wird.


Ich zitiere mal einen Kollegen, als wir gemeinsam über die kryptischen Name-Mangling Meldungen des C++ Compilers gerätselt haben:
"Ich habe zuhause den C Standard stehen. Das ist ein handliches Buch, lässt sich locker in einem Tag durchlesen."

Schau dir das selbe mal für C++ an. Der C++ Standard ist gemessen an JEDER aktuellen Sprache absurd umfangreich. Den sinnvoll auf ein Subset runterzubrechen der mit C vergleichbar ist, ist enorm aufwändig. Warum dann nicht gleich C nehmen?

Die kryptischen Name-Mangling Meldungen können eigentlich nur beim Linken enstehen. Man kann sie demanglen, das nervt, aber eigentlich kommen diese Art von Meldungen nur selten vor. Das ist kein Argument gegen C++ nach meiner Meinung.

Simon
2016-05-16, 18:45:13
Wenn man mehr Features nutzt, darf eine Kompilierung auch mal länger dauern. Mal clang benutzt? Das Teil rennt.
clang nutzt ld in der Standardeinstellung. Den benutzt g++ auch. gold ist etwas schneller.
Und wir haben leider nur gcc 4.1 auf unserer Plattform :(


Ok, RTTI und Exceptions verbraten auch ein wenig Resourcen. Aber gerade mit C++ Exceptions kann eine Software massiv sicherer und wartbarer gemacht werden. Es gibt Compiler, die Zero Overhead bei Exceptions haben.
In der Theorie und bei kleinen Programmen stimmt das. Bei grossen Programmen sehen wir immer und immer wieder Exceptions, die aus irgendeinem unteren Layer in der Software kommen und nirgends gefangen werden, dann die gesamte Software mit runter reissen.
Korrekten Exception Handling Code der in allen Faellen alle Resourcen in der richtigen Reihenfolge deinitialisiert und freigibt ist nicht einfach zu schreiben. Gerade bei unseren Zulieferern aus Indien und China ist das ein massives Problem.
Von 5-10% Performance Overhead mit RTTI und Exceptions mal noch ganz zu schweigen.


Die kryptischen Name-Mangling Meldungen können eigentlich nur beim Linken enstehen. Man kann sie demanglen, das nervt, aber eigentlich kommen diese Art von Meldungen nur selten vor. Das ist kein Argument gegen C++ nach meiner Meinung.
Dann hast du noch nie drei Level tief in Templates in einem Debugger gehangen :freak:



Selbst das Subset ist immer noch um Welten besser als pures C.
Vielen Dank dass du so ausfuehrlich dein Wissen und deine Erfahrung mit uns teilst :rolleyes:


RAII geht mit C nicht. Man hat keine STL. Referenzen gibt es nicht. Klassen fuer abstrakte Datentypen gibt es nicht. Mit C-Strings will ich erst gar nicht anfangen.
RAII ist nett, hauptsaechlich fuer stack objects. Fuer Heap objects muss man wieder extra Sachen machen. STL wird gerade in High Performance-Sachen kaum benutzt, da eher EASTL oder eigene Implementierungen.

Standard C-Strings sind in der Tat schlecht. C++ Strings sind auch nicht besser: https://groups.google.com/a/chromium.org/forum/#!msg/chromium-dev/EUqoIz2iFU4/kPZ5ZK0K3gEJ

Ectoplasma
2016-05-17, 07:25:07
In der Theorie und bei kleinen Programmen stimmt das. Bei grossen Programmen sehen wir immer und immer wieder Exceptions, die aus irgendeinem unteren Layer in der Software kommen und nirgends gefangen werden, dann die gesamte Software mit runter reissen.
Korrekten Exception Handling Code der in allen Faellen alle Resourcen in der richtigen Reihenfolge deinitialisiert und freigibt ist nicht einfach zu schreiben. Gerade bei unseren Zulieferern aus Indien und China ist das ein massives Problem.
Von 5-10% Performance Overhead mit RTTI und Exceptions mal noch ganz zu schweigen.

Die Exceptions können nichts dafür, wenn die Entwickler Mist bauen :wink:. Exceptions haben je nach Compiler und Platform gar keinen Overhead. Der Overhead für RTTI kann in der Tat sehr heftig sein. Man sollte RTTI wenn es geht vermeiden. Dennoch bin ich der Meinung, dass die Vorteile überwiegen können.

Dann hast du noch nie drei Level tief in Templates in einem Debugger gehangen :freak:

Aber ja doch werter Herr, ich mach das doch nun schon ewig. Man gewöhnt sich an allem :)

Exxtreme
2016-05-17, 08:34:25
Ok, RTTI und Exceptions verbraten auch ein wenig Resourcen. Aber gerade mit C++ Exceptions kann eine Software massiv sicherer und wartbarer gemacht werden. Es gibt Compiler, die Zero Overhead bei Exceptions haben.

Exceptions verbraten idR. nur dann Ressourcen wenn sie geworfen werden. Deshalb sollte man Exceptions auch als das behandeln was sie sind und nicht zur normalen Programmflusskontrolle nutzen.

Ectoplasma
2016-05-17, 09:22:28
Exceptions verbraten idR. nur dann Ressourcen wenn sie geworfen werden. Deshalb sollte man Exceptions auch als das behandeln was sie sind und nicht zur normalen Programmflusskontrolle nutzen.

Ich habe weder mit RTTI noch Exceptions irgendein Verständnisproblem und ich nutze beides, danke. Im Übrigen stimmt deine Aussage nicht ganz, denn wie ich bereits mehrfach wiederholte, gibt es Unterschiede in der Art des Exception-Handlings. SJLJ Exception Handling beispielsweise macht das Programm größer und sogar langsamer selbst wenn keine Exception geworfen wird. SEH (Windows) beispielsweise hat zero Overhed. Aber um mich noch einmal zu wiederholen. Meine Fragen bzgl. C++ bezogen sich auf den embedded Bereich (siehe weiter oben). Die Frage habe ich jetzt schon zweimal gestellt. Meine Frage war, ob es dort immer noch sehr wenig genutzt wird und wenn ja, was sind die Gründe. Ich habe die Frage auch ausdrücklich als OT gekennzeichnet. Ich wollte das hier nicht Ausufern lassen und eigentlich keine Diskussion C vs C++ anzetteln, sondern hatte auf eine kurze Antwort gehofft.

Foobar2001
2016-05-18, 08:16:26
Die Gruende im Embedded-Bereich gegen C++ sind groesstenteils FUD und Hoehrensagen.

Man muss halt wissen was man macht. STL oder noch schlimmer Boost (:ulol:) koennen zu extremem code bloat fuehren. Das muss man aber alles nicht benutzen und es ist dann immer noch tausend mal bequemer als Steinzeit-C.

RAII ist nett, hauptsaechlich fuer stack objects. Fuer Heap objects muss man wieder extra Sachen machen.
Muss man nicht. Dafuer gibt's std::unique_ptr. Zero Overhead, weder Speicher noch Performance und garantiert keine Leaks.

Ectoplasma
2016-05-18, 15:12:00
Muss man nicht. Dafuer gibt's std::unique_ptr. Zero Overhead, weder Speicher noch Performance und garantiert keine Leaks.

Sehe ich das eigentlich richtig, dass man in C++11 das Schlüsselwort 'new' theoretisch gar nicht mehr bräuchte, da man auto Variablen auch aus einem Scope moven kann?

Timbaloo
2016-05-18, 15:27:02
Muss man nicht. Dafuer gibt's std::unique_ptr. Zero Overhead, weder Speicher noch Performance und garantiert keine Leaks.
Schau dir mal an was die gängigen (oder nicht so gängigen) Compiler die so verwendet werden davon überhaupt unterstützen. Danke für das Gespräch, bitte, danke, tschüss.

Oder anders ausgedrückt: Wenn C++ ein fast 100%iges Superset von C ist, aber im Bereich bestenfalls ein kleines Subset von C verwendet wird, dann rechne dir doch mal aus wie das sinnvoll verwendbare Subset von C++ aussehen könnte.

shared_ptr my ass, in dem Bereich ist noch nichtmal C99 wirklich angekommen...

Vor einer Weile dachte ich auch mal, dass Templates für eine Entwicklung toll wären, aber der Compiler wollte irgendwelche Template-Parameter nicht unterstützen, aus die Maus.

Von C-Compilern für Architekturen die noch nichtmal den Mindestumfang eines freestanding environments unterstützen weil zu speziell, davon wollen wir noch nichtmal anfangen.

Aber gut, in einer Welt in der jeder denkt embedded = Superdupersmartphone-mit-Arm-drin mag C++ die total geile Scheisse sein... :rolleyes:

Ectoplasma
2016-05-18, 15:55:06
shared_ptr my ass, in dem Bereich ist noch nichtmal C99 wirklich angekommen...

Eher my ass, aber was für Steinzeitcompiler nutzt du? VC6.0 kennt das natürlich nicht. Ist auch egal, soetwas kann man sich schnell nachbauen und ist extrem nützlich.


Aber gut, in einer Welt in der jeder denkt embedded = Superdupersmartphone-mit-Arm-drin mag C++ die total geile Scheisse sein... :rolleyes:

Denkt das wirklich jeder? Wobei man bei Smartphones doch eher Java oder Objective-C nutzt. Vielleicht noch irgendwo .NET. Ich dachte eher an Devices wie Adruino oder ähnliches.

Foobar2001
2016-05-19, 06:48:34
Schau dir mal an was die gängigen (oder nicht so gängigen) Compiler die so verwendet werden davon überhaupt unterstützen. Danke für das Gespräch, bitte, danke, tschüss.
Fuer welchen Microcontroller gibt es denn bitte kein GCC oder Clang? :confused:

Flyinglosi
2016-05-19, 09:57:08
Darf ich (als Threadstarter) kurz meinen Senf dazu abgeben:

Ich habe selbst auch C++ an der Uni gelernt, aber wenn man das Programmieren als Mittel zum Zweck verwendet (eben als Ingenieur) erscheint einem C weit meist beherrschbarer. Man hat dort nach kurzer Zeit das Gefühl einigermaßen zu verstehen, was denn nun wirklich passiert und selbst wenn C++ sich hier ähnlich verhalten würde: Wozu ein zweites Tool erlernen, wenn man die Zeit nutzen kann um den Umgang mit dem ersten zu verbessern?

Umgekehrt kann ich aber auch sagen, dass viele Hardware-Komponenten (z.B. Servomotoren, Lagesensoren etc.) oft nur noch eine C++ Library zur Verfügung stellen. Bis jetzt musste ich dann stets selbst bei Null anfangen und mir dann eben was mit C zurecht basteln.

mfg

Stephan

Timbaloo
2016-05-19, 11:34:34
Fuer welchen Microcontroller gibt es denn bitte kein GCC oder Clang? :confused:
Es gibt genügend Architekturen für welche es keinen gcc gibt. Clang dürfte noch wesentlich trauriger sein. Selbst wenn es einen gcc-port gibt, folgende Fragen:

- auf welcher Version basiert dieser?
- welcher Versionen davon sind entsprechend zertifiziert? (ISO 26262, etc.)

Ganz konkret hängt man z.B. bei einem auf Tricore basierten µC auf einem gcc 3.3 fest. Und das nur wenn das Projekt sich überhaupt für die gcc-Lösung entschieden hat!

Und selbst wenn der eingesetzte Compiler alles mögliche tolles kann, was bringt es wenn viele neuen Features (z.B. restrict) durch Richtlinien (MISRA, etc.) verboten werden?

Sprich die Hürden sind in der Regel höher als nur "dann lade ich mir halt mal gcc 4.x runter".

Wozu ein zweites Tool erlernen, wenn man die Zeit nutzen kann um den Umgang mit dem ersten zu verbessern?
Das finde ich ist die falsche Fragestellung. Die richtigere ist imho:

"Welche tatsächlichen Probleme habe ich mit meiner aktuellen Toolkette, welche Probleme davon würde ein Wechsel von C auf C++ lösen und welche Probleme würde ich dadurch schaffen."

Und eine weiterführende Frage wäre:

"Würde ein anderes Werkzeug nicht mehr Probleme lösen und weniger neue Probleme schaffen?"

In der Fixkomma-Welt (die halt in der µC-Welt recht groß ist) könnte C++ vieles Vereinfachen, aber gleichzeitig gibt es Codegeneratoren (Targetlink, Simulink-Coder, ...) die das Problem umfassender angehen als es eine reine Programmiersprache je könnte. Nur mal als Beispiel.

Und spätestens wenn man Codegeneratoren einsetzt, wird die Frage ob nun C oder C++ praktisch hinfällig.

Ectoplasma
2016-05-19, 11:55:43
Es gibt genügend Architekturen für welche es keinen gcc gibt. Clang dürfte noch wesentlich trauriger sein. Selbst wenn es einen gcc-port gibt, folgende Fragen:

- auf welcher Version basiert dieser?
- welcher Versionen davon sind entsprechend zertifiziert? (ISO 26262, etc.)

Ganz konkret hängt man z.B. bei einem auf Tricore basierten µC auf einem gcc 3.3 fest. Und das nur wenn das Projekt sich überhaupt für die gcc-Lösung entschieden hat!

Und selbst wenn der eingesetzte Compiler alles mögliche tolles kann, was bringt es wenn viele neuen Features (z.B. restrict) durch Richtlinien (MISRA, etc.) verboten werden?

...



Genau danach hatte ich doch gefragt. Danke, dass jemand die Frage verstanden hat. :)

Simon
2016-05-19, 16:57:54
Fuer welchen Microcontroller gibt es denn bitte kein GCC oder Clang? :confused:
Unter anderem unsere MIPSe.