Archive for the ‘ANSI C & C99’ Category.

Quellcodeformatierung mit Artistic Style

Zu einem guten Codierstyleguide gehört immer auch eine Formatierungsansage. Es ist deutlich einfacher, fremde Quelltexte zu lesen, wenn diese gleichförmig formatiert sind. Unschön formatierte Sourcecodes gibt es zuhauf. Auch man selber ist nicht immer gefeit, die eigenen Stilvorgaben und Vorlieben auch einzuhalten. Auch wenn man in einem Team gemeinsam Sourcen bearbeitet, kann ein solcher Styleguide helfen. Beim Hatari Projekt ist das z.B. recht uneinheitlich.

Wie genau ein Quellcode nun einzurücken und zu formatieren ist, das bleibt immer eine persönliche Frage, z.B. wie geschweifte Klammern zu setzen sind. Hauptsache, der Stil ist einheitlich.

Dabei helfen natürlich kleine Tools, bessere IDEs wie Code::Blocks oder Eclipse bieten gleich entsprechende Plugins. Häufig rufen diese aber auch nur fertige Tools für die Kommandozeile auf.

Unter Linux kommen direkt 2 Kandidaten infrage:

Ich habe mich für Artistic Style entschieden, da es die von mir genutzten Optionen auf Anhieb anbietet. Ich habe nur ein wenig experimentiert und meine Vorlieben sehen wie folgt aus:


#
# astylerc for Matthias Arndt
#
# history:
# 2011-05-26 initial version
#

# main style:
style=bsd

# indentation with TABS (4 spaces per TAB):
indent=tab

# contents of switch case statements are indented, including the break:
indent-cases

# preprocessor statements that are split are indented:
indent-preprocessor

# loops and if statements are seperated by empty lines:
# (associated block comments are kept)
break-blocks

# parenthesis are padded with spaces:
pad-paren

# unnecessary empty lines are deleted:
delete-empty-lines

Das Ganze kann man nach $HOME/.astylerc speichern und schon braucht man das Tool nicht mehr mit Kommandozeilenparametern zu füttern.

DOs and DO NOTs for developing Embedded Systems software

Zum Thema “Was sollte man tun und was nicht, wenn man Software für Embedded Systems entwirft und usitzt?”habe ich mal einen Artikel zusammegestellt. Dieser Artikel ist natürlich subjektiv, ich bin gerne bereit zu diskutieren. Die meisten Aspekte habe ich aber derweil schon aus verschiedenen Onlinequellen bestätigt bekommen.

http://www.final-memory.org/?page_id=2113

Im Prinzip habe ich dort mal zusammengefasst, was ich alles seit der Universität gelernt habe. Teile davon praktisch im Job, viele andere aber auch fortbildungsmäßig aus dem Netz. Im Vordergrund steht vorallem, fiese Fallen von faul programmierten C zu umgehen. Viele der Regeln und Vorschläge sind auch sprachunabhängig und können natürlich auch auf andere Programmiersprachen angewendet werden.

Ich selber habe viele dieser Regeln früher zum Beispiel nicht beherzigt. Wenn ich die Sourcen zu meiner Diplomarbeit ansehe, dann habe ich viele davon eklatant verletzt. Aber irgendwo will man ja auch einen Lerneffekt erkennen.

Als weitergehende Lektüre kann ich auch das “Embedded C Coding Standard” von Michael Barr empfehlen.

Irgendwann schreibe ich vielleicht auch noch einengrößeren zusammenhängenden Artikel oder auch ein kleines Buch. Die Liste kann sicherlich noch erweitert werden.

Hatari auf dem GP2X Wiz – der erste Sonnenschein

Seit ein paar Tagen versuche ich den Atari ST(e) Emulator Hatari (http://hatari.berlios.de/) auf den GP2X Wiz zu portieren.

Nach viel Rumprobieren, Fluchen, Aufregen und bösen Postings in die Mailingliste habe ich zumindest einen ersten Ansatz, der Wiz zeigt den Atari Desktop, den man per Touchscreen bemausen kann ;)

Hatari auf dem GP2X Wiz (erstes Mal der grüne Desktop)

Hatari auf dem GP2X Wiz (erstes Mal der grüne Desktop)



Ich hoffe soweit zukommen, daß man wenigstens Demos schauen und Spiele spielen kann, denen ein Joystick reicht.

Gepatcht habe ich bisher nur die Datei  screen.c und eine spezielle Konfigurationsdatei erstellt.

Mehr Richtung Wochenende! *Freude Freude Freude*

STay cool, STay Atari /|\

Code::Blocks als IDE Alternative?

Code::Blocks

Code::Blocks

In den vergangenen Monaten und fast Jahren habe ich eigentlich Eclipse als IDE verwendet. Allerdings hatte ich schon öfters von der Alternative Code::Blocks gelesen und so habe ich diese IDE auch mal ausprobiert. Sie bietet eigentlich nur Vorteile, hat allerdings auch deutliche Einschränkungen. In Summe hat es mich aber schon überzeugt und fürs private Programmieren werde ich in Zukunft für C Projekte auf jeden Fall mit Code::Blocks arbeiten.

Vorteile nach erstem Ausprobieren der Version 8.02

  • in C++ geschrieben und damit deutlich flotter als Eclipse
  • Gute Unterstützung für C und C++
  • eigenes Buildsystem, d.h. Makefiles von Hand schreiben ist nicht mehr immer nötig
  • eingebaute Konfiguration für AVR und SDCC, inklusive Compilersettings
  • konfigurierbare Compiler, insbesonders GCC Derivate
  • schneller Editor
  • Crossplattform, Code::Blocks gibt es auch für Windows

Erkannte Nachteile

  • Vala wird nur über Custom makefiles unterstützt und kein Syntaxhighlighting dafür
  • Editorkomponente ist Scintilla und damit nicht direkt erweiterbar
  • naturgemäß kein so guter Support für Java wie etwa Eclipse
  • keine direkte SVN Integration (jedenfalls nicht unter Linux, für Windows gibt es wohl ein Plugin für TortoiseSVN)

Ich glaub in Summe muss jeder selber entscheiden, ich selbst bin so gut wie überzeugt, allein schon weil ich ja selber bevorzugt mit ANSI C arbeite und zumindest privat nicht alles über SVN ein- und auschecke.

Vala: eine weitere objektorientierte Programmiersprache?

Vor einigen Tagen stolperte ich über einen Artikel bei Pro-Linux, in dem die mir bis dato unbekannte Programmiersprache Vala vorgestellt wurde. Zunächst dachte ich mir in etwa “Was soll dieser Unsinn? Es gibt doch Java, C# oder C++.” Dann habe ich mich ein wenig in die Dokumentation eingelesen.

Die Sprache entstand, um für den GNOME Desktop performant, aber objektorientiert entworfene Software programmieren zu können, ohne alle die nötigen Features von Hand in C realisieren zu müssen. GLib und GTK setzen schließlich zum Leidwesen einiger Leute auf C und nicht C++ auf. Vala soll diese Lücke füllen. Die Sprache fühlt sich auf den ersten Blick an wie C# oder Java, aber der erzeugte Code ist kein Bytecode oder dgl. Intern erzeugt Vala reinen ANSI C Code, der lediglich die Glib verwendet, um die objektorientierten Features zu realisieren.

Vala bietet die folgende Features:

  • Übersetzung nach C Code (daher ist das Ergebnis portabel und auf Wunsch auch ohne Vala Compiler übersetzbar, denn die C Files können erzeugt werden)
  • Zugriff auf viele wichtige APIs, unteranderem ALSA, GTK und SDL (vgl auch http://live.gnome.org/Vala/BindingsStatus)
  • C# ähnliche Syntax
  • ordentliche String Klasse und Verkettung
  • freie Software

Mich hat das soweit überzeugt, daß ich auch gleich ein paar Testprogramme ausprobiert habe. Ich muss sagen, sowohl der Ansatz, als auch die Sprache selbst gefallen mir sehr gut. Die Nachteile von C# und Java werden ausgeglichen und man gewinnt den Vorteil, theoretisch mit Vala entwickelte Software auch auf Targets zu bringen, die nur einen C Compiler bieten, etwa Embedded Systems auf ARM Basis (Wiz, Caanoo und Dingoo lassen grüßen)

Natürlich wäre ich auch neugierig, ob man damit sogar Code für kleine 8Biter erzeugen kann. Für AVR müsste es möglich sein, wenn man eine möglichst abgespeckte GLib bereitstellt (API-kompatibel) und nicht sämtliche Sprachfeatures ausreizt.

Ich werde mich jedenfalls, wenn auch nicht im riesigen Umfang, zukünftig ein wenig mit Vala befassen.

Linksammlung