Init-System in C oder C++

[alexander_ro]

Auf die zwei "++" zu verzichten ist ein Fehler wegen der generischen Programmierung. Ist mir immer noch ein Rätsel warum man die fähigkeiten moderner Compiler so wenig nutzt. Man kann den Eindruck gewinnen das Entwickler extrem Konservativ sind und einmal erlerntes nicht verändern. Für ein Init-System wäre das Ideal. Dann würde der Compiler die Abhängigkeiten bei der Reihenfolge der zu startenden Dienste und andere Abhängigkeiten (z.B Platform unterschiede) zur Übersetzungszeit auflösen. Was ein kompaktes Programm ergibt, weniger Fehler und den Entwicklern Pflege Aufwand erspart.

Irgendwann werden die Software Entwickler aber von ihren statischen Systemen Abschied nehmen müssen. Zumindest wenn man den derzeitigen Überschuß an Rechenleistung irgendwie sinnvoll Nutzen will. Sollte Software (besonders die Desktop Systeme) intelligenter werden und nicht nur ein mehr an meist überflüssigen Funktionen bekommen. Eine neue Form an Kacheln oder neue Randleisten machen es auch nicht besser.

[Edit]

Egal mit welchem Init-System gilt dies ganz sicher für die Verwendung von binären "Init-Scripten".

Die Shell-Scripte sind letzlich nichts anderes. Sie werden Transparenz in Binär-Code verwandelt was meine Lösung mit C++ auch tut. Nur das der C++ Compiler sehr viel mächtiger Möglichkeiten bietet um automatisiert Probleme zu lösen. Shell Scripte sind halt IT-Steinzeit vielleicht sollte man mal überlegen wie lange man in der Steinzeit verharren will. Ich glaube auch nicht das Shell-Scripte den meisten bekannt sind. Das gilt sicher auch für C++ also auch kein wirklicher Unterschied.
[/Edit]

[wanne]

Auf die zwei "++" zu verzichten ist ein Fehler wegen der generischen Programmierung

Die größe g++ und libs: ~60MiB => Mehr als der komplette Speicherplatz auf meinem router.
tcc: 120kiB + libc6-dev 10MiB
Zum Vergleich: bash+busybox 4MiB
Und mal ganz ehrlich um argumente zu vergleichen und dann ein Programm auszuführen braucht man kein c++.
Da reicht getopt und execve.

[alexander_ro]

Da reicht getopt und execve.

Stimmt aber um Abhängigkeiten zur Übersetzungszeit aufzulösen braucht man C++. Du hast ganz offensichtlich noch nie den Bootprozess eines leidlich komplexen Systems in augenschein genommen. Dein Router (singel Core?) der vermutlich nur irgendwo die Propritäre Anwendung des Herstellers startet und sonst nichts tut sowas nicht braucht ist anzunehmen. Die Anwendung kann der Kernel dirket starten und gut is es.

... und Bash und Busybox braucht keine Libs und externe Programme? Wird nix werden mit den 4MB

Das Init Binary braucht sehr viel weniger Platz und wird auch ganz erheblich die Rechnleistung Deines Routers schonen. Router sind recht statische Gebilde also nicht wirklich ein Problem wenn dort kein Compiler vorhanden ist. Es ist im Embedded Bereich gängige Praxis Programme auf dem PC per Cross-Compiler zu übersetzen warum also nicht auch den Init-Prozess. Oder schmeißt Du den Router jedesmal weg wenn im Kernel oder einem sonstigen Programm ein Bug gefunden wird.
Üblich Konfigurations Parameter sollten so nicht im Programm Codiert werden also auch kein Problem bei einfachen Anpassungen.

Im übrigen steigt die Rechenleistung und der Speicherplatz bei Embedded System recht rasch das es auch bei neueren Geräten einen Compiler verträgt und Du keinen Cross Compiler benötigst. Demnächst wird noch einer die Forderung stellen das Debian auf einem 8KB AVR laufen muss. Man sollte nicht immer nur die Steinzeit im Auge behalten. Ich bin zwar auch der Meinung das man wenn mögllich alte Hardware unterstützt aber nicht um jeden Preis. Der Linux Kernel unterstützt ja auch keine Steinzeit Intel CPUs mehr obwohl die Unterstützung noch sehr weit zurück reicht. Um nochmal auf Deinen Fall zurück zu kommen würde er ja auch weiter unterstützt nur mit einer kleinen Komfort verlust.

[wanne]

Da reicht getopt und execve.

Stimmt aber um Abhängigkeiten zur Übersetzungszeit aufzulösen braucht man C++. Du hast ganz offensichtlich noch nie den Bootprozess eines leidlich komplexen Systems in augenschein genommen.

Da gibts im extremfall Mutexe. Die traditionelle Variante ist einfach Dateien anzulegen und dann zu warten bis die da sind. Alles kein Hexenwerk.
Aber mal ganz ehrlich. Geht alles bei weitem über das raus was meine heutigen init-Scripte machen. Die begnügen sich mehr oder weniger alle damit, beim argument start das richtige Programm mit den richtigen Parametern auszuführen, und das dann beim argument stop wieder zu beenden. und dann gibt's noch restart da werden die beiden Funktionen nacheinander aufgerufen....

... und Bash und Busybox braucht keine Libs und externe Programme? Wird nix werden mit den 4MB

Code: Alles auswählen

/dev/root                 2.0M      2.0M         0 100% /rom
/dev/mtdblock3            5.1M      1.6M      3.4M  32% /overlay

3.6M Und auf dem router läuft garantiert eher viel. (Wobei da noch ein paar zusätzliche Programme unter opt liegen.) Aber natürlich ligt da in den 2M eine Bash eine Busybox ein dhcp server, ein kastrierter hostapd ein Webserver, diverse kompressionstools, die paketverwaltng, vi, sshd, ein lua interpreter und was man halt sonst noch so an standardtools hat (ln, sed, mv, chown, ifconfig...). Das ist allerdings auch komprimiert.

Das Init Binary braucht sehr viel weniger Platz und wird auch ganz erheblich die Rechnleistung Deines Routers schonen. Router sind recht statische Gebilde also nicht wirklich ein Problem wenn dort kein Compiler vorhanden ist. Es ist im Embedded Bereich gängige Praxis Programme auf dem PC per Cross-Compiler zu übersetzen warum also nicht auch den Init-Prozess. Oder schmeißt Du den Router jedesmal weg wenn im Kernel oder einem sonstigen Programm ein Bug gefunden wird.

Ne, aber zum beispiel ist mein wlan etwas komplizierter aufgebaut und deswegen habe ich da etwas rumpfuschen müssen, dass zuerst die Verbindung ins internet da ist bevor hostaped startet und erst danach der dhcpd kommt. Hinzu kommt das ich zuerst mit iw die devices für hostapd vorbereite. Weger sowas will ich mir nicht erstmal nen crosscompiler auf meinem Rechner einrichten müssen. Und rechenleistung? Das ding startet alle paar jahre mal. Da ist mir sowas von egal ob das jetzt 10 oder 40 Sekunden geht.

Im übrigen steigt die Rechenleistung und der Speicherplatz bei Embedded System recht rasch das es auch bei neueren Geräten einen Compiler verträgt und Du keinen Cross Compiler benötigst.

Duie rechenleistung schon der Speicherplatz nicht. Die werden dafür alle paar Monate wieder um nen € billiger.

Man sollte nicht immer nur die Steinzeit im Auge behalten. Ich bin zwar auch der Meinung das man wenn mögllich alte Hardware unterstützt aber nicht um jeden Preis. Der Linux Kernel unterstützt ja auch keine Steinzeit Intel CPUs mehr obwohl die Unterstützung noch sehr weit zurück reicht.

Es geht hier nicht um Steinalt hardware wie irgend welche x86-CPUs sondern um nagelneue Hardware, die halt so leicht sein soll, dass sie auch ein Quadkopter noch tragen kann. Oder ohne Probleme in den stecker von meiner Weihnachtskette passt. – Und dabei nicht mehr als ein paar € kosten soll.
16Bit u.ä. ist noch lange nicht tot. Man spart dann halt an Größe Gewicht und preis. Und 90% der Hardware sind eben kein 50kG 4m³ PCs sondern Handys Router oder Taschenrechner.
Nur rechenleistung ist mittlerweile eigentlich überall genug da. RAM, ROM, IO ist überall immer gut, wenn man sich was sparen kann.

[alexander_ro]

Da gibts im extremfall Mutexe.

Nein mit denen trift man Entscheidungen zur Laufzeit. Generische Programme tun das zu Compilezeit. Ein Mutex ist eigentlich nur ein Merker zur Laufzeit den man zur Syncronisierung von gleichzeitigen Abläufen zur Laufzeit benutzt. Das ist ein grundlegender Unterschied. Da man Teile der Entscheidungen schon vor dem Programmlauft treffen kann spart das Rechenleistung und dann zum Bleistift Strom vom Handy. Da im Falle init das von der jeweiligen Hardware und Debian installation abhängt macht es den init schlanker und schneller wenn der Compiler alles weg läßt das nicht gebraucht wird für Deine spezielle installation.

Aha, ich dachte die brauchen wenigstens die libc. Sind dann aber wahrscheinlich statisch gelinkt das ist natürlich möglich.
Aber wie gesagt den Compiler musst Du nur installiert haben wenn Du Grundlegendes am Init-Prozess ändern willst und statisch linken kann man auch C++ Programm die dann auch keine lib mehr brauchen und nur um die wirklich benötigten funktionen aus der lib größer werden. Bleibt also sehr weit unter den genannten 60MB.

Das ding startet alle paar jahre mal.

Du siehst das vielleicht ein bisschen zu eng. Handy, Tablet und PC werden sehr viel öfter gestartet da kann man es schon mal eilig haben. Mein Note oder Netbook auch nicht weil ich nur suspend to Disk benutze und das viel schneller als booten geht. Aber die meisten machen das nicht so. Auch bei den doofen vergleichen der Bootzeit bis zum Login kann es nicht schaden wenn man besser wird. Die vergleichen zwar Äpfel mit Birnen weil Windows erst nacht dem Login anfängt zu booten und Linux da schon fertig ist. Aber die Presse läst sich von solchen kleinen Unterschieden nicht vom Obstsalatvergleich abhalten. Ich hatte auch weiter oben geschrieben das die Software inteligenter werden sollte. Deshalb würde ich auch Teile der gesparten Zeit in gute Fehlertolleranz und Fehlerdiagnose investieren davon hätten vor allem die nicht Systemexperten sehr viel. Anwenderfreundlicher zu werden sollte immer als wichtiger Punkt Beachtung finden. Die Masse der Anwender ist weder selbst noch Inhaber einer IT-Abteilung und das was die Hardware Hersteller Service nennen verdient die Bezeichnung nicht und daher auf sich alleine gestellt. Kompetete Hilfe durch die Software daher unumgänglich und gut investierte Rechenzeit. Wird so ein init sauber daher Modular aufgebaut kann man die Dignose und andere Dinge dank generischer Programmierung einfach abschalten um Leistungsschwache System nicht zu belasten.

Nur rechenleistung ist mittlerweile eigentlich überall genug da. RAM, ROM, IO ist überall immer gut, wenn man sich was sparen kann.

Diese Beere lasse ich mal weg die ist mehr PC als Embedded System. Aber ein Gnublin zum Beispiel kommt mit einem C++ Compiler gut zurecht. Das der Compiler ein bisschen langsam ist liegt daran das er ein bisschen zu wenig Arbeitsspeicher hat (ca. 50MB fehlen). Also durchaus was das man mit fliegen kann. Eine Debian installation auf einem Rechner der in einen Stecker passt glaube ich wirst Du nicht finden. Das sind normal AVR oder ähnliche Kontroller die aber kein Debian verkraften. Hat halt irgendwo grenzen nach unten. Ich geb Dir da schon recht wenn es geht auch schwache Systeme zu unterstützen. Aber da ist die C++ Lösung abgesehen vom Umstand das man nicht auch noch einen Compilier braucht bei Umfangreichen Änderungen eher besser als die Shell Scripte geeignet. Weil man dann mit wenig Aufwand durch die generische Programmierung Komplexität auch ausbauen kann gleiches gilt für die Unterstützung der vielen Plattformen bei Debian und alles automatisch. Es ist aber auf keinen Fall erstrebenswert die Software für Leistungsstarke Systeme Primitiv und Dumm zu halten nur um irgend ein Embedded System mit geringer Verbreitung noch zu unterstützen. Das ist dann ganz klar Sache der Hersteller für Anpassung zu sorgen oder der jenigen die es unbeding da drauf haben wollen. Es wird immer Systeme geben für die ein Standard Debian nur bedingt geeignet ist.

Die Bastler die ich kenne und kleine Embedded Systeme benutzen Compilieren alle Cross oder mit KVM auf einer Debian ARM installation (meist sind es ja ARMs) und installieren das fertige Programm auch dem Embedded System. Wobei ich die KVM Variante sehr viel einfacher finden als die Cross Version. Zumindest wenn man so wie ich auch dafür ein Debian benutzen will.

[wanne]

Nein mit denen trift man Entscheidungen zur Laufzeit. Generische Programme tun das zu Compilezeit.

Dann bist du wieder genau bei dem haupt gegenargument von SystemV.
Der Vorteil von SystemD war eben, dass man eben erst zur laufzeit entscheidet was wann läuft. Man startet eben mal X und das Netzwerk parallel und je nach dem was da zuerst fertig ist, macht man dann zuerst fertig ist, fängt man an zuerst KDE oder NFS zu starten.
Wenn alles zu kompilzeit vorhersagbar ist, kann man einfach sequnzielle Programme schreiben. Da braucht man dan gleich zweil mal kein C++ dafür.

statisch linken kann man auch C++ Programme

Code: Alles auswählen

$ cat cpp.cpp 
#include <sstream>
#include <iostream>

class Output{
        int a;
public:
        Output(int a)
        {
                this->a=a;
        }
        void printit()
        {
                std::cout << a << "\n";
        }
};

int main()
{
        Output* o=new Output(123);
        o->printit();
}

Code: Alles auswählen

$ cat c.c
#include <stdio.h>

int main(){
        int a=123;
        printf("%d\n",a);
}

Code: Alles auswählen

$ gcc -Os -o c c.c
$ ls -lh c
-rwxr-xr-x 1 wanne wanne 6,6K Dez 11 18:15 c
$ g++ --static -Os -o cpp cpp.cpp
$ ls -lh cpp
-rwxr-xr-x 1 wanne wanne 1,5M Dez 11 18:15 cpp

Kein Kommentar, zum statischen Linken von C++ Programmen....

Aha, ich dachte die brauchen wenigstens die libc. Sind dann aber wahrscheinlich statisch gelinkt das ist natürlich möglich.

Nein statisch linken braucht unnötig Platz:

Code: Alles auswählen

# ldd /bin/busybox 
        libcrypt.so.0 => /lib/libcrypt.so.0 (0x77ddb000)
        libm.so.0 => /lib/libm.so.0 (0x77db6000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x77d93000)
        libc.so.0 => /lib/libc.so.0 (0x77d27000)
        ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x77e02000)

Code: Alles auswählen

# ls -lh /lib/libuClibc-0.9.33.2.so
-rwxr-xr-x    1 root     root      347.2K Nov 18  2012 /lib/libuClibc-0.9.33.2.so
# ls -l /lib/libc.so.0
lrwxrwxrwx    1 root     root            21 Nov 18  2012 /lib/libc.so.0 -> libuClibc-0.9.33.2.so

Du siehst das vielleicht ein bisschen zu eng. Handy, Tablet und PC werden sehr viel öfter gestartet da kann man es schon mal eilig haben.

Ja, aber die CPU ist beim start die wenigste Zeit ausgelastet. Und C++ Programme sind generell garnatiert nicht schneller als welche in C. Im übrigen auch mein Handy schafft ein paar Millionen mutex_lock befehle in der Sekunde....

Die vergleichen zwar Äpfel mit Birnen weil Windows erst nacht dem Login anfängt zu booten und Linux da schon fertig ist.

Das stimmt nicht. Windows hat nur keinen Runterfahren button mehr. Nur noch suspend to disk.

s ist aber auf keinen Fall erstrebenswert die Software für Leistungsstarke Systeme Primitiv und Dumm zu halten nur um irgend ein Embedded System mit geringer Verbreitung noch zu unterstützen

Du verwechselst da was ganz massiv: Debian auf dem Dektop ist absolut unverbreitet.

Eine Debian installation auf einem Rechner der in einen Stecker passt glaube ich wirst Du nicht finden.

http://neuerdings.com/2011/03/12/torade ... -der-welt/
Und da gibt's noch viele in der Kategorie. Und jetzt gibst du nochmal 18 Monate dann sind die, die jetzt doppelt so groß sind auch so klein (Und das ist toll) und da soll dann auch Debian drauf laufen.

[schorsch_76]

Wanne: Du vergleichst hier printf mit stream output. std::cout kann aber "minimal" mehr als printf. Das konzept nennt sich eben "generische Programmierung".

Das ist der gleiche Vergleich wenn man sagt: "Schau der Lada ist viel leichter und braucht weniger Sprit als der Merzedes S Klasse!" Dass sie S Klasse "minimal" mehr Features hat bezweifelt ja auch keiner. Klar ist die S Klasse schwerer, aber dafür hat man halt auch Klima und was weis ich noch. Das liegt merkt dann am "Gewicht" .. bzw am Speicher

Da C nahezu eine Untermenge von C++ ist braucht man hier nicht zu "streiten" [1]

In the strict mathematical sense, C isn't a subset of C++. There are programs that are valid C but not valid C++ and even a few ways of writing code that has a different meaning in C and C++. However, C++ supports every programming technique supported by C. Every C program can be written in essentially the same way in C++ with the same run-time and space efficiency. It is not uncommon to be able to convert tens of thousands of lines of ANSI C to C-style C++ in a few hours. Thus, C++ is as much a superset of ANSI C as ANSI C is a superset of K&R C and much as ISO C++ is a superset of C++ as it existed in 1985.

Why is the code generated for the "Hello world" program ten times larger for C++ than for C?
It isn't on my machine, and it shouldn't be on yours. I have even seen the C++ version of the "hello world" program smaller than the C version. In 2004, I tested using gcc -O2 on a Unix and the two versions (iostreams and stdio) yielded identical sizes. There is no language reason why the one version should be larger than the other. It is all an issue on how an implementor organizes the standard libraries (e.g. static linking vs. dynamic linking, locale support by default vs. locale support enabled through and option, etc.). If one version is significantly larger than the other, report the problem to the implementor of the larger.

[1] http://www.stroustrup.com/bs_faq.html

Edit: Name korrigiert

[wanne]

Wanne: Du vergleichst hier printf mit stream output. std::cout kann aber "minimal" mehr als printf. Das konzept nennt sich eben "generische Programmierung".

Ja, ich habe hier absichtlich ein C++-feature genommen um zu zeigen, was das für ein Gewicht hat.

Das ist der gleiche Vergleich wenn man sagt: "Schau der Lada ist viel leichter und braucht weniger Sprit als der Merzedes S Klasse!"

Und ich sage man sollte keine Autobahnen bauen auf denen nur Trabbis fahren können. Natürlich mag das in vielen fällen bequemer sein. Und wenn man einenen Browser baut, braucht man nicht zu gucken, das der noch auf meinem 4MiB router läuft. In den seltenen fällen wo die kombination vorkommt, kann man andere Lösungen suchen. Aber was grundsätlich wie das init system sollte halt überall laufen. Und nicht 90% der Geräte erstmal nicht oder nur mit verbiegungen.

Why is the code generated for the "Hello world" program ten times larger for C++ than for C?
It isn't on my machine, and it shouldn't be on yours. I have even seen the C++ version of the "hello world" program smaller than the C version. In 2004, I tested using gcc -O2 on a Unix and the two versions (iostreams and stdio) yielded identical sizes. There is no language reason why the one version should be larger than the other. It is all an issue on how an implementor organizes the standard libraries (e.g. static linking vs. dynamic linking, locale support by default vs. locale support enabled through and option, etc.). If one version is significantly larger than the other, report the problem to the implementor of the larger.

[1] http://www.stroustrup.com/bs_faq.html[/quote]
Statisch linken macht programme groß.
Beim dynamischen Linken hat man den vorteil, dass die libs einen Bruchteil so groß sind, weil man eben auf alle komplizierten Funktionen verzichtet hat.
Im Prinzip ist C eben genau das der Primitive Teil von C++ und der ist eben kleiner. Das heißt nicht dass der Primitive teil in C++ größer ist, aber er ist eben nur ein kleiner Teil von C++.

[schorsch_76]

Ich nutze aber auch C++ (gcc-4.7.3) auf dem Atmega 168 mit 16k Flash und 1k Ram. Was groß ist, ist nicht die Sprache, es ist die STL. Die Sprache sind templates, Klassen und Co.

EDIT: Um es genauer zusagen, die Implementierung des gcc der STL ist nicht optimal. Unter Windows mit MSVC2010 sind die ausgaben praktisch gleich gross (Exe).

[wanne]

Propo: hallow world -O2 statisch gelinkt mit hallo world:

Code: Alles auswählen

-rwxr-xr-x 1 wanne wanne 1,5M Dez 11 20:08 cpp2
-rwxr-xr-x 1 wanne wanne 767K Dez 11 20:09 c2

Nicht statisch gelinkt (Wobei sich da die Komplexität halt inder libstd++ versteckt):

Code: Alles auswählen

-rwxr-xr-x 1 wanne wanne 6,6K Dez 11 20:10 c2
-rwxr-xr-x 1 wanne wanne 8,0K Dez 11 20:10 cpp2

[wanne]

EDIT: Um es genauer zusagen, die Implementierung des gcc der STL ist nicht optimal. Unter Windows mit MSVC2010 sind die ausgaben praktisch gleich gross (Exe).

A: Sind die statisch gelinkt oder linken die halt gegen die windws libstdc++ ?
Dann ist das logisch. Wenn du den Code in denen 40GiB Windows versteckst fällt nichst mehr auf und in denem Progrmm sind nur Funktionsaufrufe?
B: Kannst du mal die Ausgabe posten?
Im übrigen giengs eigentlich um den Compiler und die dev-Pakete nicht um den output.

[schorsch_76]

Womit wir wieder beim Funktionsumfang sind. Die "Komplexität" sind eben die Features der STL. Die S-Klasse muss ja auch die Klima irgendwo mitschleppen auch wenn ich se gerade jetzt nicht brauche

clang-3.3: mit deinen Programmen:

dynamisch:

Code: Alles auswählen

clang++ wanne-cpp.cpp -Os -o cpp
georg@machariel ~ $ ls -la cpp
-rwxr-xr-x 1 georg users 8501 11. Dez 20:26 cpp

Code: Alles auswählen

clang c.c -Os -o c 
georg@machariel ~ $ ls -la c
-rwxr-xr-x 1 georg users 8044 11. Dez 20:26 c

statisch:

Code: Alles auswählen

clang c.c --static -Os -o c 
georg@machariel ~ $ ls -la c
-rwxr-xr-x 1 georg users 839051 11. Dez 20:27 c

Code: Alles auswählen

clang++ wanne-cpp.cpp --static -Os -o cpp
georg@machariel ~ $ ls -la cpp
-rwxr-xr-x 1 georg users 1574039 11. Dez 20:28 cpp

Wie man sieht ist hier auch "etwas koplexität" (aka Funktionalität) im c binary

Aber: Wir sind jetzt "minimal Offtopic"

[wanne]

Womit wir wieder beim Funktionsumfang sind. Die "Komplexität" sind eben die Features der STL. Die S-Klasse muss ja auch die Klima irgendwo mitschleppen auch wenn ich se gerade jetzt nicht brauche :

That's the Problem!

Aber: Wir sind jetzt "minimal Offtopic"

War das die Erinnerung das ich Mod bin?

[wanne]

Wie man sieht ist hier auch "etwas koplexität" (aka Funktionalität) im c binary

hier scheint sich clang mal dümmer als gcc anzustellen. Trotz allem ist das gleiche Programm eben wesentlich kleier. Vor allem wenn man die Libs der dynamsich gelinkten Version mitzählt.

[wanne]

Shell Scripte sind halt IT-Steinzeit

Eben nicht. man hat sich eben geraden den Luxus geleistet eine sehr mächtige Scriptsprache nutzen zu können. Den hat man vorher nicht gehabt.

[schorsch_76]

Ich juckel grad clang nochmal durch mit dem Gold plugin, das unerreichbaren Code entfernt. Dann bin ich mal gespannt

[schorsch_76]

Damnit: In dem FAll bringt das nichts. SIehe http://llvm.org/docs/GoldPlugin.html

[alexander_ro]

Das hat nun aber auch nicht wirklich mit dem Thema zu tun oder seh ich da was falsch ...
Mir ging es nie um C oder C++ sondern darum das man einen Modernen Compiler im Altag benutzen kann generische Probleme zu lösen. Also in dem Fall z.B. das ein C++ init System sich automatisch an eine andere Platform anpasst.

Man kann immer ein Totschlag Argument finden um jede Neuerung zu verhindern und die ITler scheinen extrem Veränderungsfeidlich zu sein. Mit genauso vielen Argumenten wie Du unbedingt C als schneller darstellen willst was es nicht ist kann man das mit C und Assembler tun. Ich muss mich jetzt schon sehr wundern warum Du mit so einer langsamen Sprache wie C zufrieden bist.

Bei gleicher funktionalität ist C++ und C gleich schnell. Das was Du machst sind die gleichen Obstsalat vergleiche wie sie die Fachpresse liebt.

Vor den gefühlten 1000 Jahren mögen Deine geliebten Shell-Scripte Luxus gewesen sein. Aber Menschen leben heute auch nicht mehr in Höhlen nur weil die mal Luxus waren.

Ausserdem wer sagt das man die libstd++ für ein init System überhaupt braucht. Ich sehe da nicht so viel das man unbedingt für den Zweck haben muss. Als es für die AVR die noch nicht gab habe ich da auch C++ Programme geschrieben ohne STD.

[wanne]

Es geht nicht darum das ich C++ verabscheue. Gerade wenn man anfängt GUIs zu programmieren ist das ein Segen, und gerade die neueren Funktionen der STL sind toll. Aber an manchenstellen ist es einfach überdimensioniert.
Genau wie ich nicht mit der S-Klasse vom Schlaf ins Wohnzimmer fahre. Obwohl das viel moderner ist als zu laufen. Und ich fange das auch nicht an, wenn ich gerade in nem Schloss zu besuch bin, wo die S-Klasse sogar durch die Türen passen würde.

Und auf ein 2 MiB System einen 50MiB C++ Compiuler zu bauen damit man das 5Zeilige Startscript auführen kann, ist eben genau so inteligent wie ine ein 20g Handy ein 5kg Akku einzubauen. Obwohl man natürlich auch 5kg tragen könnte und der viel länger halten würde.
Oder tag und nacht mit Helm rumzulaufen.

[wanne]

Also in dem Fall z.B. das ein C++ init System sich automatisch an eine andere Platform anpasst.

Das mach C halt wesentlich besser. Weil einen C-Compiler gibt's für alles. Und er läuft auch überall.

[schorsch_76]

Beim gcc ist auch der g++ immer dabei. Auch habe ich auf AVR Atmega 168 mit 16k Flash und 1k SRAM C++ Anwendungen laufen. Ja, der ist noch kleiner als dein Router mit 4 MiB. Ja auch dort ist C und C++ möglich.

[wanne]

Beim gcc ist auch der g++ immer dabei.

Nein, gcc und g++ unterscheiden sich in einem byte.
Aber wie gesagt ich würde für sowas kein gcc nehmen.
Man nimmt da ein tcc und schreibt in die erste Zeile von seinem Code
#!/usr/local/bin/tcc -run
Und schon hat man was, dass sich wieder wie ne Scriptsprache anfühlt.

Auch habe ich auf AVR Atmega 168 mit 16k Flash und 1k SRAM C++ Anwendungen laufen

Ja klar. Aber keinen C++ Compiler.
Im übrigen wirst du dan ganz massiv Probleme bekommen, wenn du da wirklich größere C++ Programme laufen lässt und nicht einfach leicht abgewandelte C Programme durch nen C++ Compiler Jagst.

[schorsch_76]

37513
37514
37515
37516

Das ist sicher kein leicht abgewandelter C Code.

[alexander_ro]

Man nimmt da ein tcc und schreibt in die erste Zeile von seinem Code

Nur das der für Debian ungeignet ist was machst Du z.B. bei einer ARM CPU mit dem?
Du denkst da nur an die System die bei Dir laufen. Das ist aber halt vielleicht zu eng gefasst.

Deine Behauptung ist halt nicht richtig Du brauchst den C++ Compiler ja nur wenn Du grundlegende Dinge verändern willst. Wenn Du andauernd die Scripte umschreibst die Deine Systeme booten solltest Du mal Grundsätzlich die Architektur Deiner Anwendungen überdenken. In dem Bereich kommen Änderungen eher selten vor.

Soweit mir bekannt ist systemd (upstart weiß ich nicht) ja auch eine Binär Lösung für desen Änderung ein Compiler gebraucht wird. Nur das meine Lösung wenn man die Scripte mit installiert Transparent Änderungen beim booten einbaut. Separates Compilieren und Installieren entfällt und wird automatisch erledigt. Ausserdem frägt man sich schon ob systemd oder upstart weniger Speicher brauchen ich weiß es nicht habe aber gewisse Zweifel. Die müssen alles mögliche an Funktionen im Programm haben weil es eine statische Lösung ist.

[wanne]

Das ist sicher kein leicht abgewandelter C Code.

Abgesehen davon, dass deine structs funktionen haben und so ihre datenstruktur implizit statt als Argument bekommen, sehe ich da absolut kein C++ feature. Das ist raz fatz in C Code umgebaut.
Keine Container keine Streams, keine Smart pointers, keine Function objects.
Im Gegenteil nutzt du exzessiv den C-Präprozessor, bit operatoren, static und volatile. Alles features, die man in erster Linie aus älterm C-Code kennt.
Das einzige was wirklich ein C++-Feature ist ist das template:

Code: Alles auswählen

template<class T>
T abs(T a)
{
    return a > 0 ? a : -a;
}

Und das hättest du auch leicht als Macro schreiben können.