Init-System in C oder C++

[wanne]

C++ als Sprache ist _nicht_ an die STL gebunden, genausowenig wie C als Sprache an die libc gebunden ist.

Falsch. Sowohl die glibc wie auch die STL sind teile des jeweiligen Standards.
Sie machen im übrigen einen großen Teil der eigenschaften der sprachen aus (Portierbarkeit...).

Ja, ich habe Klassen und Templates genutzt, das _sind Kernfunktionen_

Du hast in erster Linie Klassen genutzt. Und die gibts (wie die große Teile rest syntax) eben zu 90% schon in C. Die wirkliche Mehrfunktionalität (Vererbung mit überschreeiben, Destruktoren, und der aufruf von überladenen Funktionen...) blieben in erster Linie ungenutzt.

placement new

Das bei dir in erster Linie wie malloc genutzt wurde.

amit das ganze C++

Natürlich ab der ersten Zeile die exklussiv C++ ist ist es ken C mehr trotzdem kann ich getrost von leicht abgewandelte C sprechen.

C in C++ zu konvertieren

Das ist primitiv. Im normalfall reicht es zu sagen, dass das jetzt C++ Code ist.
Aber in die andere richtung eben nicht, wenn man viele der erweiterungen genutzt hat muss man die eben alle nachprogrammieren. (Was im übrigen in teilen sogar gar nicht geht in reinem Standad-C (allocation auf dem Stack...))

Warum hast Du das Template nicht in C konvertiert ... ich geb Dir gerne die Antwort weil es schlicht nicht möglich ist.

Doch wird in dem Fall sogar wesentlich kürzer. Ich habe es aber absichtlich weggelassen, weil Templets eben wirklich eine reines C++ feature sind das der strikteren Typisierung geschuldet ist und das eben kein wirkliches equivalent in C hat.
Damit sind diese 4 Zeilen mehr oder weniger die einzigen die wirklich aktiv von der mehrfunktionalität von C++ gebrauch machen.
Aber für dich:

Code: Alles auswählen

#define abs(a) (a > 0 ? a : -a)

[schorsch_76]

Darf ich dich hierrauf hinweisen?
http://www.avr-cpp.de/doku.php
http://www.mikrocontroller.net/articles ... it_C%2B%2B

Edit: Das ist natürlich kein gutes Argument von dir, wenn du sagst: "Hey! das nutzt keine STL, also ist es kein C++!" das ist nur BS!

[wanne]

Um es mal etwas übertrieben zu sagen: myAVR C++ hat mit C++ ( https://de.wikipedia.org/wiki/C++ ) so viel zu tun wie Javascript mit Java. etwas Syntax.
Gerade das geht in C++ so wenig wie in C. Einzelne Bits lassen sich nunmal nicht ansprechen.

Code: Alles auswählen

// das Gleiche mit myAVR C++ ////////////////////////////////////////
if ( pinD.bit2 == 0 )
     portB.bit7 = 0;

Das geht eben nur weil die ihre eigene Library drüber gelegt haben. Haben die da im übrigen mehr oder weniger genau gleich gemacht nur, dass die's C nennen:
http://arduino.cc/en/Tutorial/HomePage
http://arduino.cc/en/Reference/DigitalWrite

[schorsch_76]

Diese Lib nutzt den "Sprachkern" wie auf deiner verlinkten Wikipedia Seite beschrieben. Es ist halt an das Ziel angepasst ... den Avr. Ich kann C++ halt wirklich an jedes Ziel anpassen, ähnlich wie C.

[wanne]

Ja ich zitiere mal den ganzen Satz:

Die Sprache C++ besteht aus sehr wenigen Schlüsselworten („Sprachkern“); ihre eigentliche Funktionalität erhält sie - ähnlich wie auch die Sprache C - durch die C++-Standardbibliothek

Und wo wir gerade beim Zitieren sind:

Die Implementierung eines C++-Compilers gilt als aufwändig.

Taht's it. genau deswegen läuft auf deinem AVR kein C++ Compiler.

[bmario]

Die Implementierung eines C++-Compilers gilt als aufwändig.

Das Beste an dem Quote ist, dass das immer alle Leute sagen, außer jenen, die tatsächlich Compiler schreiben.

[schorsch_76]

Auf einem AVR Atmega 168 mit 16k Flash und 1k SRAM wird sicher kein Kompiler laufen (auch nicht dein tcc), das sagte ich doch auch nicht. Ich sagte dass auch auf solchen kleinen Geräten mit C++ (wenn auch ohne STL, aber mit Templates und Klassen) Anwendungen laufen. Dazu kabe ich gezeigt, wie so ein kleines Progrämmchen aufgebaut sein kann. Das war das Ziel, um das es mir ging, zu belegen, dass eben nicht alle C++ Programme dick und fett sind, wie hier wohl das Vorurteil ist.

C++ als Sprache ist _nicht_ an die STL gebunden, genausowenig wie C als Sprache an die libc gebunden ist.

Falsch. Sowohl die glibc wie auch die STL sind teile des jeweiligen Standards.

Ab hier brauche ich wohl nicht mehr zu diskutieren. STL (Standard Template Library) mag Teil des Standards sein, aber nicht Teil der Sprache. Ich arbeite seit fast 15 Jahren fast ausschliesslich mit C++, und kann mittlereile etwas zwischen Bibliothek und Sprache unterscheiden.

[wanne]

Das Beste an dem Quote ist, dass das immer alle Leute sagen, außer jenen, die tatsächlich Compiler schreiben.

Da ich's nicht geschrieben habe kann ich dem nicht wiedersprechen.

Das war das Ziel, um das es mir ging, zu belegen, dass eben nicht alle C++ Programme dick und fett sind

Klar man kann einfach C schreiben. Solange du nur sructs mit Funktionen/Klassen. (Sind das selbe.) nutzt hast du im endcode typishcerweise ein paar mehr pointerdereferenzierungen das merkt kein Mensch.
Das heißt aber eben auch das du 99% der Sprache nicht nutzt.

aber nicht Teil der Sprache

Der standard beschreibt die Sprache:
Steht da fett drauf.:

Standard for Programming Language C ++

Man kann die libraries rauswerfen aber man erhällt dann nurnoch ein Teil der sprache. Der dann im übrigen absolut unbenutzbar ist (Was micht heißt das man doch irgend ein Programm schreiben kann das keine Librarys benutzt). Nur schon das man ausschließlich über die rückgabewerte mit der außenwelt kommunizieren kann ist eher unschön. Der heap fällt auch flach...

Ist aber nicht das thema. Die bash hat an performance auch gereicht und die ziechnet sich eben auch nicht dadurch aus, dass sie bei typischen Programmen besonders performant ist.
Das Problem war nunmal dass ein entsprechender Compiler zu fett ist weil der eben alles mitschleppen muss.

PS: Du nutzt in deimem Programm ausschließlich C libraries. Überlegedir mal warum... (Und wenn du jetzt zu dem Ergebnis kommst: Weil es keine anderen für den AVR gab, dann würde ich mal darüber nachdenken.)

[schorsch_76]

Der AVR hat einfach keine dynamische Speicherverwaltung. Da geht auch keine libc wie du sie kennst [1]. Kein open()/close(), ist das ganze dann doch kein C oder etwas anderes? Es nutzt ja nicht die voll standardisierte libc wie du sie kennst. Na klar, es ist ein embedded Microcontroller ohne Betriebssystem.

[1] http://www.nongnu.org/avr-libc/user-manual/index.html

The AVR Libc package provides a subset of the standard C library for Atmel AVR 8-bit RISC microcontrollers. In addition, the library provides the basic startup code needed by most applications.

Genauso verhält es sich mit C++ auf dem AVR [2]. Man kann die Sprache nutzen, aber halt nicht die Geschichten welche vom Zielsystem nicht unterstützt werden. Ich kann mich auf den Kopf stellen so viel ich will, ich werde nie die Grenzen meines Zielsystems sprengen können. Egal ob C/C++ oder Assembler. Egal welche Sprache ich nutze, ich muss Abstriche machen im Funktionsumfang wenn das Ziel es nicht hergibt, auch wenn der Kompiler es könnte. Für ihn (den Kompiler) sind bsp. malloc/free/new/delete einfach einfach Funktion welche in irgendeiner lib sitzen (sei eis die libc oder STL) und er eben verlinkt. Mehr nicht. Kannst du jetzt die Trennlinie zwischen Sprache und der Standard Library erkennen?

[2] http://www.nongnu.org/avr-libc/user-man ... _cplusplus

EDIT: Als Beispiel: In meinem Programm nutze ich noch etwas aus dem Kern. Data encapsulation. (class RC5) Das kann kein C. Das kann die Klasse aus C++.

EDIT2:

Man kann die libraries rauswerfen aber man erhällt dann nurnoch ein Teil der sprache.

Falsch. Mann erhält die komplette Sprache, aber nicht die Libraries. Die Sprache _sind_ die Schlüsselwörter mit der "Gramatik" (EBNF) . Das komplette Packet aus Sprache (Schlüsselwörtern) und der Library ist dann der komplette Standard.

[wanne]

ist das ganze dann doch kein C oder etwas anderes? Es nutzt ja nicht die voll standardisierte libc wie du sie kennst. Na klar, es ist ein embedded Microcontroller ohne Betriebssystem.

Für sowas gibt es eigentlich den "freestanding" teil im C standard, der eben solche sachen noicht fordert. Sollte er auch den nicht erfüllen (tut er nicht) ist es kein vollständiges C.
Ist im übrigen aber nicht unbedingt der Hardware geschuldet. Dass sollte auch auf der durchaus machbar sein.

Für ihn (den Kompiler) sind bsp. malloc/free/new/delete einfach einfach Funktion welche in irgendeiner lib sitzen

Für malloc und free stimmt das new und delete sind Schlüsselworte.
Aber die Sprache besteht eben aus mehr als ihren Schlüsselworten.
Neben den Schlüsselworten, gibt's da in C(++) z.B noch den Preprozessor und eben die library.
Im übrigen können auch viele compiler ganze schlüsselworte nicht (Wie das avr-c++). Sie implementieren halt nur ein Teil der Sprache.

Und um mal aus deiner Quelle zu zitieren:

Can I use C++ on the AVR?
Basically yes
[..]
currently no support for libstdc++, the standard support library needed for a complete C++ implementation.

When programming C++ [..] could easily add up into a considerable amount of time and program memory wasted.

[bmario]

Für ihn (den Kompiler) sind bsp. malloc/free/new/delete einfach einfach Funktion welche in irgendeiner lib sitzen

Für malloc und free stimmt das new und delete sind Schlüsselworte.
Aber die Sprache besteht eben aus mehr als ihren Schlüsselworten.
Neben den Schlüsselworten, gibt's da in C(++) z.B noch den Preprozessor und eben die library.
Im übrigen können auch viele compiler ganze schlüsselworte nicht (Wie das avr-c++). Sie implementieren halt nur ein Teil der Sprache.

Das ist schlicht falsch. new und delete sind Operatoren. Man kann diese sogar überladen und sich so seine eigene Speicherverwaltung schreiben.

*edit: Es ist nicht ganz falsch. Der C++ Standard listet unter 2.12 tatsächlich new und delete in der Liste aller Wörter auf, die "in phase 7" als Keywords behandelt werden. Er schweigt sich allerdings dazu aus, welche dieser Wörter nun wirklich Keywords sind und welche nicht. In 2.13 wird allerdings new und delete als Operator genannt.

*edit2: Unter "13.5 Overloaded operators" ist dann wiederum new, delete, new[] und delete[] gennant.

*edit3: Unter "3.7.4 Dynamic storage duration" stehendann noch weitere Details dazu.

[schorsch_76]

@wanne: Da hast du schön den Teil mit den Temporären Objekten und den Copy Konstruktoren weg gelassen. Klar muss der Programmierer die Sprache kennen. Das ist aber bei C auch nicht anderst.

Wenn du eben in einem System debuggst in dem für praktisch alles Debugsysmbole vorhanden sind, und es wird new()/malloc() oder was anderes aufgerufen, siehst du dass es nur Funktionen sind die aus dem Schlüsselwort "new/delete" werden.

Auch mit dem avr-g++-4.7.3 kann ich C++11 Features nutzen. auto, variadic templates, etc. aber eben nicht die STL.

Gegen deine Vorurteile kann man nicht argumentieren....

[wanne]

Auch mit dem avr-g++-4.7.3 kann ich C++11 Features nutzen. auto, variadic templates, etc. aber eben nicht die STL.

Ja und in Java auch da kannst du den ++ Operator benutzen => eindeutig C++ !!!!!!!!!!!!

*edit2: Unter "13.5 Overloaded operators" ist dann wiederum new, delete, new[] und delete[] gennant.

Was nicht heißt, dass sie eine funktion sind und schon gar nicht, dass sie in der STL sind. (Das sind sie nämlich nicht.)
Hir mal die Liste die MS für keywörter hällt:
http://msdn.microsoft.com/en-us/library/2e6a4at9.aspx
IBM sieht das genauso: http://publib.boulder.ibm.com/infocente ... 2Fkeyw.htm
http://www.mpgh.net/forum/31-c-c-progra ... words.html

Gegen deine Vorurteile kann man nicht argumentieren....

Ich finde ich habe die Argumente deutlich auf meiner seite
Die kleinste C++ Toolchain die wir gefunden haben ist etwa 100Mal so groß wie die kleinste für C.
Das irgenwelche anderen Sprachen sachen C++ im Naman haben und einen Teil der Syntax übernommen haben tut da nichts zur Sache. Und du kannst nochmal 5 jahre rumheulen es gibt eben gute Gründe warum man auch 2011 nochmal nen neuen C (ohne ++) standard raugegeben hat. In manchen Anwendungen ist es eben sinnvoll kein C++ zu nutzen. C++ War nie dafür desight möglichst leichtgewichtig zu sein.
Genauso wie es nciht sinnvoll ist Applets in x86-Assembler zu programmieren...

[alexander_ro]

Ja und in Java auch da kannst du den ++ Operator benutzen => eindeutig C++ !!!!!!!!!!!!

Ja da hast Du föllig recht Java ist nur ein billiger Abklatsch von C++ das hat sogar der Erfinder zugegeben. Er wollte ein C++ ohne die Technischen Rafinessen über die die ganzen Noops an untalentierten Programmierern ständig fallen.

Ich finde es lustig wenn man hier liest (weiß nicht mehr genau wo) das C++ ohne STL unbenutzbar ist. Ich möchte mal darauf hinweisen das die STL angewanntes C++ ist sonst nichts. Die STL ist auch kein Teil der Sprache. Der Standard definiert auch Hilfsmittel was einen einfachen Grund hat das man für Standard Aufgabe nicht jedesmal alles neu erfinden muss und diese Betriebsystem und Compiler Hersteller übergreifend kompatibel verwenden kann. Der Standard definiert übrigens auch die möglichkeiten Assembler Code einzubetten nur ist deshalb noch lange nicht Assembler bestandteil der C++ Spreche.

Es ist auch verschärfter Unfug zu sagen nur weil nicht jedes bekannte Schlüsselwort oder jeder bekannte Operator in einem Programm vorkommt ist es kein C++ Programm. Ein Compiler der nur einen Teil von C oder C++ umsetzt ist vom Standard her unvollständig aber wenn mir die verfügbaren Teile reichen kann ich damit ebenso C++ Programme schreiben. Das Schorsch Beispiel ist ohne den geringsten Zweifel ein C++ Programm.

... und was man nie vergessen sollte es ist praktisch der gesamte C Teil bestandteil von C++ und somit gibt es genau genommen keine C Programme mehr. Man verwendet diese Unterscheidung eigentlich nur um bekannt zu geben das die Entwickler des Progamms noch eng in der IT Steinzeit verhaftet sind.

Interessant ist auch das zum Beispiel die Auto Hersteller und deren Zulieferer einen enormen Bedarf an C++ Entwickler haben und das liegt nicht daran das die Performence von C++ so schlecht ist. Ein Auto Hersteller will Systembedingt kein Quentchen mehr Rechenleistung einbauen als nötig weil jedes MIPS mehr teuer Euro kostet.

Ich bleibe dabei eine generische Implemntierung des Init wäre eine Ansage an eine Fortschritliche IT Zukunft aber die wird in der Software Welt wohl noch ein paar Generationen auf sich warten lassen. Schade drum mit der heutigen Rechenleistung kann man sehr viel mehr erreichen als Bunte Bildchen mit der Maus schubsen ... traurig sniff ;(

Grüße und schöne Weihnachten falls man sich nicht mehr hört oder liest bis da hin ...
Alexander

[dufty2]

Etwas, was mit C++ nicht geht, wenn ich Andreas am CCC richtig verstanden haben, ist OO und Korrektheitsbeweise. Hierfür habe ich bislang nur (abgespecktes) C gesehen.
Mal sehen, wie sich das noch so entwickelt ...

[alexander_ro]

Das diese Korrektheitsbeweise keine Korrektheit beweisen ist Dir vermutlich bekannt. Das ist eine Mogelpackung um sicherheit vorzugaukeln. Daher sehe ich das nicht als großes Problem an. Zumal bei erreichen einer Mäßig hohen Komplexität es belanglos ist welche Programmiersprache man benutzt da der Beweiß Jahre in Anspruch nehmen würde.

Ich habe mir mal gedanken gemacht wie man ein init baut der flexibel genug ist um auf den für Debian nötigen Architekturen zu laufen und auch Embedded System wie Gnublin und Co. gut startet ohne knappe Resorcen zu verschwenden. Nur bin ich jetzt nicht direkt ein init Experte kann mir vielleicht jemand ein paar Tipps noch geben was der alles können muss.

Das ist mir dazu eingefallen:
1. Die definition bestimmter Runlevel zulassen

2. Den Default Runlevel starten. Beim starten des Runlevel muss man die diversen Dienste möglichst Parallel starten aber die die von anderen abhängen erst nachdem diese laufen. Also zum Beispiel Netzwerkdienste: Mail, DNS usw. erst wenn das Netzwerk konfiguriert ist.

3. Die in der inittab genannten Konsolen starten.

4. Interessant wäre auch das er die bisherigen Init-Scripte weiter verwenden kann. Dann wäre ein fließender Übergang möglich.

Was machen eigentlich die Scripte in /etc/init/ ?
Die in /etc/init.d/ kenne ich und die /etc/rc* definieren was in welchem Runlevel gestartet wird.
Wer kümmert sich um das laden der Kernelmodule und wo wird das gestartet?

Grüße
Alexander