Betriebssystemprogrammierung

[Gascht (Gast)]

N'Abend die Nachtschwärmer. Ich habe Interesse an der 
Betriebssystemprogrammierung auf X86/X64-Systemen.

Meine erste Frage, macht es nicht eher Sinn sich mit X64-Systemen zu 
beschäftigen als X86 oder verstehe ich hier etwas total falsch? X64 = 
64Bit, X86 = 32Bit.

Meine zweite und WICHTIGERE Frage, macht es Sinn ein Betriebssystem mit 
C++ zu programmieren oder nicht? Ich kann ja alle Sprachmittel die es in 
C nicht gibt weglassen und nur mit denen programmieren die C auch hat. 
Mir gehts nur darum nicht C von der Pike auf lernen zu müssen. Wenn es 
mit C++ geht würde ich gerne auch damit arbeiten.

[lrep (Gast)]

Gascht schrieb:
> macht es Sinn ein Betriebssystem mit
> C++ zu programmieren

Du willst ein neues Betriebssystem programmieren und hast dafür schon 
den C++ Compiler?
Wie das?

[(prx) A. K. (prx)]

lrep schrieb:
> Du willst ein neues Betriebssystem programmieren und hast dafür schon
> den C++ Compiler?
> Wie das?

Wo siehst du da ein Problem? Das ist wie Controllerprogrammierung, 
zumindest anfangs, nur etwas mehr davon. Linus Torvalds hatte auch erst 
den Compiler und dann sein System.

[Flopsi (Gast)]

lrep schrieb:
> Du willst ein neues Betriebssystem programmieren und hast dafür schon
> den C++ Compiler?
> Wie das?

Warum nicht? Er sprach von einem neuen Betriebssystem, nicht von einer 
neuen Plattform. Es gab ja z.B. auch C Compiler für x86, bevor es Minix 
oder Linux gab.
Viel spannender ist aber die Frage:
Du beherrschst C++, schreckst aber davor zurück, C "von der Pike auf 
lernen zu müssen"? Wie das?

[2K (Gast)]

Flopsi schrieb:
> lrep schrieb:
>> Du willst ein neues Betriebssystem programmieren und hast dafür schon
>> den C++ Compiler?
>> Wie das?
>
> Warum nicht? Er sprach von einem neuen Betriebssystem, nicht von einer
> neuen Plattform. Es gab ja z.B. auch C Compiler für x86, bevor es Minix
> oder Linux gab.
> Viel spannender ist aber die Frage:
> Du beherrschst C++, schreckst aber davor zurück, C "von der Pike auf
> lernen zu müssen"? Wie das?

Egal warum , bei OS programmierung wird er auch um assembler kaum 
herumkommen

[Gascht (Gast)]

Ich schrecke nicht davor zurück C zu lernen, nur wenn es in C++ geht 
warum sollte ich mich mit Eigenheiten von C beschäftigen. Ich bin ein 
fortgeschrittener Anfänger in C++.

Zurück zur Betriebssystemprogrammierung, macht C++ dafür Sinn?

[Andreas R. (daybyter)]

https://en.m.wikipedia.org/wiki/Spring_(operating_system)

Da wurde mit OO OS experimentiert.

Aber ich würde erstmals viiiiel kleiner anfangen. Einen Treiber 
programmieren, oder so.

[(prx) A. K. (prx)]

Gascht schrieb:
> Zurück zur Betriebssystemprogrammierung, macht C++ dafür Sinn?

Eine Antwort von kompetenter Seite - wie so oft provokant und 
streitlustig formuliert: http://harmful.cat-v.org/software/c++/linus

[Gascht (Gast)]

> Linus schreibt:
> In other words, the only way to do good, efficient, and system-level and
> portable C++ ends up to limit yourself to all the things that are
> basically available in C

Da hätten wirs, ich muss also nur wissen was es in C nicht gibt. Und 
zusätzlich von der STL sollte ich vorerst keinen Gebrauch machen so wie 
ich das verstehe.

[nfet (Gast)]

Vielleicht solltest du dir auch einfach erst mal überlegen, was dein 
Betriebssystem so können soll. Wenn du das weißt, dann kannst du es 
natürlich auch in C++ programmieren.
Meines Erachtens nach rechtfertigt sich C++ schon allein, wenn man nur 
const und namespaces aus C++ benutzt.
Ansonsten guck dir vielleicht mal Rust an. Wärst dann wahrscheinlich der 
erste, der so etwas damit macht, aber für den Spaß kann man sichs ja mal 
geben. Weiß aber um ehrlich zu sein nicht, wie es mit der inline 
assembler fähigkeit aussieht.

Aber wie bereits gesagt, die Programmiersprache wird dir bei diesem 
Projekt wohl noch die allerwenigsten Stolpersteine in den Weg legen. 
Viel mehr wirst du dich über die Feinheiten der Prozessor Architektur 
ärgern, oder über dein an irgendeiner Stelle zu kurz gedachtes Design.
Aber lass dich davon nicht abhalten, es macht schon Spaß wenn man es 
geschafft hat ein kleines dummes Betriebssystem zu booten. Von daher 
keep going!

[Arc N. (arc)]

Gascht schrieb:
>> Linus schreibt:
>> In other words, the only way to do good, efficient, and system-level and
>> portable C++ ends up to limit yourself to all the things that are
>> basically available in C
>
> Da hätten wirs, ich muss also nur wissen was es in C nicht gibt. Und
> zusätzlich von der STL sollte ich vorerst keinen Gebrauch machen so wie
> ich das verstehe.

Ebenso würde ich die APIs, die die Anwendungsprogramme sehen, nicht 
ausschließlich in C++ ausführen also zumindest zusätzlich reine C-APIs 
dazu zur Verfügung stellen.

Choices wäre ein OS, das in C++ geschrieben wurde/wird und vielleicht 
einen Blick lohnt
http://choices.cs.illinois.edu/index.html
Die APIs, die Anwendungsprogramme zur Verfügung haben, würde ich nicht 
C++

[Karl Käfer (Gast)]

Hallo A.,

A. K. schrieb:
> Eine Antwort von kompetenter Seite - wie so oft provokant und
> streitlustig formuliert: http://harmful.cat-v.org/software/c++/linus

Hälst Du Linus' Behauptung, daß C++ schlecht sei, weil so viele 
schlechte Programmierer es benutzen, für eine kompetente Argumentation? 
Ich nicht.

Liebe Grüße,
Karl

[(prx) A. K. (prx)]

Karl Käfer schrieb:
> Hälst Du Linus' Behauptung, daß C++ schlecht sei, weil so viele
> schlechte Programmierer es benutzen, für eine kompetente Argumentation?

Nein. Aber bei Betriebssystemen ist er schon leidlich kompetent. Und 
darum gehr es hier ja. Man muss ihn freilich nicht immer allzu ernst 
nehmen, der haut in Diskussionen so einiges raus.

[Daniel A. (daniel-a)]

Diese Seite enthällt alle nötigen Informationen: 
http://wiki.osdev.org/Main_Page
Die Konsolenausgabe gelang mir bei meinem letzten versuch noch, und am 
wechsel in den protected mode bin ich gescheitert. Vileicht nächstes 
mal...

Ich rate davon ab, Platformabhängigen code in den C(++) code 
einzuschleusen. Statdessen sollten Interfaces entworfen werden und 
Platformabhängiges in asm Dateien geschrieben werden. Diese können zum 
C(++) code dazugelinkt werden.

Um mit einem eigenen OS auf amd64 anzufangen, muss es einem erst 
gelingen
 * Den Startupcode zu schreiben
 * Die Interrupts richtig zu behandeln
 * In den protected mode zu wechseln
 * Das Pageing zu meistern

All dies hat aber nur wenig mit der OS Entwicklung zutun. Dabei ist 
vorallem das Design, die verwendeten Designpattern und Algorithmen 
wichtig. Deine Architektur sollte wasserdicht sein, und du brauchst eine 
Philosophie, der du folgen kannst. Ich finde das in diesen Punkten Unix 
nicht übertroffen werden kann, und empfehle das Buch "The design of the 
UNIX® operating system" von Maurice J. Bach

Zu deiner x64 vs x86 frage, x86 ist in x64 enthalten, wenn du den 
Startupcode für x86 schreibst, sollte er auch für x64 gehen. Den C(++) 
code kann man für beide Architekturen übersetzen, wenn man es richtig 
macht.

[Moby (Gast)]

Gascht schrieb:
> Meine zweite und WICHTIGERE Frage, macht es Sinn ein Betriebssystem mit
> C++ zu programmieren oder nicht?

Nein, ein Betriebssystem zu programmieren macht keinen Sinn :-)
Jedenfalls in dieser Größenordnung.

Gascht schrieb:
> Mir gehts nur darum nicht C von der Pike auf lernen zu müssen.

Wenns da bereits mangelt wirst Du erst recht keine Dauermotivation 
entwickeln, eine komplette OS Entwicklung durchzuhalten.

[Nase (Gast)]

Gascht schrieb:
> Ich kann ja alle Sprachmittel die es in
> C nicht gibt weglassen und nur mit denen programmieren die C auch hat.
> Mir gehts nur darum nicht C von der Pike auf lernen zu müssen. Wenn es
> mit C++ geht würde ich gerne auch damit arbeiten.
Damit solltest du zuerst mal aufräumen.

[Rolf M. (rmagnus)]

Gascht schrieb:
> N'Abend die Nachtschwärmer. Ich habe Interesse an der
> Betriebssystemprogrammierung auf X86/X64-Systemen.
>
> Meine erste Frage, macht es nicht eher Sinn sich mit X64-Systemen zu
> beschäftigen als X86 oder verstehe ich hier etwas total falsch? X64 =
> 64Bit, X86 = 32Bit.

Wer auf die komische Idee gekommen ist, das "x64" zu nennen, würde mich 
mal interessieren. x86 ist ja nur verkürzt von 80x86, also die 
verschiedenen Generationen der Abkömmlinge des 8086. Ein 80x64 wäre mir 
aber nicht bekannt. Ich kenne eher die Bezeichnungen x86-64 und amd64.

Gascht schrieb:
> Meine zweite und WICHTIGERE Frage, macht es Sinn ein Betriebssystem mit
> C++ zu programmieren oder nicht?

Meines Erachtens spricht da nichts dagegen. Wie schon gezeigt wurde, 
gibt es aber auch andere Meinungen.

> Ich kann ja alle Sprachmittel die es in C nicht gibt weglassen und nur
> mit denen programmieren die C auch hat. Mir gehts nur darum nicht C von
> der Pike auf lernen zu müssen. Wenn es mit C++ geht würde ich gerne auch
> damit arbeiten.

Das verstehe ich nicht. Wenn du alles weglässt, was es in C nicht gibt, 
dann hast du doch C. Es gibt auf jeden Fall Features von C++, die in 
einem Kernel nichts zu suchen haben. Du mußt dir, bevor du anfängst, 
genau überlegen, welche das sind.

A. K. schrieb:
> Gascht schrieb:
>> Zurück zur Betriebssystemprogrammierung, macht C++ dafür Sinn?
>
> Eine Antwort von kompetenter Seite - wie so oft provokant und
> streitlustig formuliert: http://harmful.cat-v.org/software/c++/linus

Ich würde die Formulierung emotionsgeladen und uninformiert nennen. 
Kompetenz strahlt diese Abhandlung nicht gerade aus. Daß Linus sich mit 
Betriebssystemprogrammierung auskennt, bestreite ich nicht. Aber von C++ 
scheint er nicht viel Ahnung zu haben.

Daniel A. schrieb:
> Ich rate davon ab, Platformabhängigen code in den C(++) code
> einzuschleusen. Statdessen sollten Interfaces entworfen werden und
> Platformabhängiges in asm Dateien geschrieben werden.

Warum denn das? Ich würde alles, wofür man Assembler nicht braucht, auch 
nicht in Assembler schreiben, unabhängig davon, ob der Code 
plattformabhängig ist oder nicht.

[Eddy C. (chrisi)]

Karl Käfer schrieb:
> A. K. schrieb:
>> Eine Antwort von kompetenter Seite - wie so oft provokant und
>> streitlustig formuliert: http://harmful.cat-v.org/software/c++/linus
>
> Hälst Du Linus' Behauptung, daß C++ schlecht sei, weil so viele
> schlechte Programmierer es benutzen, für eine kompetente Argumentation?
> Ich nicht.

So wie Du es ausdrückst, hast Du natürlich recht.

Linus meint wohl eher, dass das Problem ist, dass Du eine Horde 
unerfahrener Programmierer hast, die alle meinen, objektorientiert 
programmieren zu können. Wenn Du diese Horde auf Linux loslässt, wäre 
das in der Tat der Untergang von Linux. Die Existenz dieses Threads und 
die Eingangsfragen des TO bestätigen Linus sogar!

Der Pfad, welchen sich der TO für den Einsatz von C++ zurechtbiegt, 
rechtfertigt jedenfalls noch nicht die Benutzung von C++, sondern ist 
eindeutig die Domäne von C.

Als Einmannschmiede kann ich mir die Verwendung von C++ gut für ein 
Betriebssystem vorstellen ("Ich mache ein objektorientiertes 
Betriebssystem!"). Für ein weltumspannendes Netzwerk von Programmierern 
jedoch müsste man die Entwicklung in C++ viel hierarchischer und 
strukturierter organisieren. Genau das ist aber nicht die Domäne von 
Linux. Bei Linux kannst Du mit dem Programmieren quasi einfach loslegen. 
Genau aus diesem Grund aber kann Linux niemals über C hinauskommen.

Aber: Du wirst bei keinem Betriebssystem auf die Verwendung von 
maschinennahen Programmiersprachen ("C") bis runter zu Assembler 
verzichten können.

[db8fs (Gast)]

Hmm, war nicht BeOS (jetzt Haiku) nicht auch rein in C++ geschrieben?

Also unmöglich ist es mit Sicherheit nicht und mit Hartnäckigkeit auch 
realisierbar.

Allerdings enthält der O-Ton von Linus T. schon auch auch sehr viel 
Wahres. Fang mit 'nem QEmu und vielleicht mal einer Linux-Version oder 
'nem RTOS an - (oder doch mal Haiku probieren)? Wenn du das zum Laufen 
kriegst, lies dich ein. Oder renn dir die Birne ein.

[R. F. (rfr)]

Wäre es nicht sinnvoll, bestehende Betriebssysteme in Assembler zu 
untersuchen?
Dieses hier wäre m.E. ein  brauchbarer Start:

http://v2.nl/archive/works/v2_os

Gruss

Robert

[Wegstaben V. (wegstabenverbuchsler)]

Gascht schrieb:
> Ich habe Interesse an der
> Betriebssystemprogrammierung auf X86/X64-Systemen.
> Meine erste Frage, macht es nicht eher Sinn sich mit X64-Systemen zu
> beschäftigen als X86 oder verstehe ich hier etwas total falsch?

Die Frage klingt für mich wie:

"Ich möchte KFZ-Mechaniker werden. Meine erste Frage, macht es nicht 
eher Sinn sich mit Diesel-Motoren zu beschäftigen als Benzin-Motoren, 
oder verstehe ich hier etwas total falsch?"


Ich glaube, du fokussierst dich da an der "falschen" Baustelle.

Die "wesentliche Komponente" in einem Auto ist nicht ausschließlich der 
Motor. da gibt es unendlich viel "drumherum", so daß der Motor (bzw. 
dessen Technologie) zwar keine unwichtige, jedoch im gesamten 
technischen System "Auto" doch eher eine untergeordnete Rolle spielt.

Auch bei Betriebssystemen (bzw. deren Entwicklung) ins die 
Prozessor-Architektur nicht primär wichtig. [wenn man technische 
Größenbeschränkungen mal außen vor läßt - ein TinyLinux OS auf einem 
Tiny2313 wäre mal eine sportliche Aufgabe ;-)


Ein Betriebssystem kann man zu 90% oder mehr vollkommen 
Hardware-unabhängig in prozedurealen (C) oder objektorientierten 
Hochsprachen (C++) entwickeln.

Ob 32 oder 64 bit Architektur, das ist für die Algorithmen der 
wesentlichen Funktionsblöcke (z.B. Speicher-Verwaltung, 
Prozess-Verwaltung) erst mal total nebensächlich.

Ein Sortier(-unter)programm (welches z.B. die Größe von Speicherblöcken 
sortiert) muß natürlich immer "gleich richtig" funktionieren, egal wie 
die technische Plattform heißt, auf der es später zur Ausführung 
gebracht wird.

Welches Ziel-Hardware nachher tatsächlich genutzt wird, kannst du deinem 
Compiler und Linker (bzw. deiner Entwicklungs-Umgebung) beibringen

[Moby (Gast)]

Karl Käfer schrieb:
> Hälst Du Linus' Behauptung, daß C++ schlecht sei, weil so viele
> schlechte Programmierer es benutzen, für eine kompetente Argumentation?
> Ich nicht.

Ich schon. Da liegt der Torvalds nicht daneben.
Die Masse der Programmierkünste in C++ sagt eben auch etwas über die 
Qualität der Sprache an sich aus. Was sich zu kompliziert nutzen lässt 
kann eben kaum optimal genutzt werden.

[Eddy C. (chrisi)]

R. F. schrieb:
> Wäre es nicht sinnvoll, bestehende Betriebssysteme in Assembler zu
> untersuchen?

Es macht sicher Sinn, sich anzusehen, wie andere an das Problem 
herangehen. Dazu muss ich mir aber nicht ausgerechnet den Ansatz in 
reinem Assembler antun. "Mit meiner ultimativen Makrosammlung kann 
programmieren wie in einer Hochsprache!" Das ist was für Ein-Mann-Buden. 
So wie eigenartige Prozessorentwicklungen mit eigenem Hex-Zeichensatz.

[R. F. (rfr)]

Eddy C. schrieb:
> Es macht sicher Sinn, sich anzusehen, wie andere an das Problem
> herangehen. Dazu muss ich mir aber nicht ausgerechnet den Ansatz in
> reinem Assembler antun.

Es ist möglich, auf einen bestehenden Sockel aus ASM mit C-Funktionen 
aufzusetzen. Im Übrigem schlägt das auch das Manual von V2os vor.

Robert

[db8fs (Gast)]

Eddy C. schrieb:
> R. F. schrieb:
>> Wäre es nicht sinnvoll, bestehende Betriebssysteme in Assembler zu
>> untersuchen?
>
> Es macht sicher Sinn, sich anzusehen, wie andere an das Problem
> herangehen.

Nicht nur das, man kann durch geschicktes Hinsehen viele Fehler beim 
Selberprogrammieren vermeiden (die man aber vermutlich früher oder 
später trotzdem macht). Daher ist es u.U. ganz gut sich mal die Ideen 
anderer anzuschauen und sich gute Sachen zu merken.

Gerade beim Betriebssystem sind etliche Fragen, die wichtig sind:
Welche Schnittstellen bedient denn ein Betriebssystem aus 
Systemperspektive? Es muss eine stabile API bieten, je nach 
MultiTasking-Anforderungen eine einfache Prozessverwaltung bieten und 
eine gewisse Hardwareabstraktion zur Verfügung stellen. Ist schon eine 
ganz ordentliche Baustelle, wenn man sich vor Augen hält, dass es sich 
relativ schlecht debuggen lässt (ok, QEmu macht da das Leben viel 
leichter).

Also wenn's unbedingt x86 bzw. x86_64 sein muss - warum auch immer - 
vielleicht einfach mal dem Herrn Tanenbaum sein Betriebsssytem-Buch 
lesen und Minix abtippseln (oder heißt das 'des Tanenbaums Buch?', 
klingt blöd - Genitiv wird überbewertet ^^).

Ansonsten hätte ich für die AVRs als Buchempfehlung 
"Systemprogrammierung für AVR-Mikrocontroller" vom Herrn Schwabl-Schmidt 
im Elektorverlag.

> Dazu muss ich mir aber nicht ausgerechnet den Ansatz in
> reinem Assembler antun.

Na ja, macht es nicht Sinn, zumindest ein wenig die Befehlsarchitektur 
des Prozessors verstanden zu haben, für den man die wichtigste 
Softwarekomponente des Systems entwickelt?

[Eddy C. (chrisi)]

db8fs schrieb:
> Na ja, macht es nicht Sinn, zumindest ein wenig die Befehlsarchitektur
> des Prozessors verstanden zu haben, für den man die wichtigste
> Softwarekomponente des Systems?

Spar Dir Deine Rethorik. Wenn ich Assembler brauche, werde ich es 
bemerken und es gibt im Netz genügend passende Resourcen. Da brauche ich 
kein komplettes(!) Betriebssystem dazu.

[Eddy C. (chrisi)]

R. F. schrieb:
> Eddy C. schrieb:
>> Es macht sicher Sinn, sich anzusehen, wie andere an das Problem
>> herangehen. Dazu muss ich mir aber nicht ausgerechnet den Ansatz in
>> reinem Assembler antun.
>
> Es ist möglich, auf einen bestehenden Sockel aus ASM mit C-Funktionen
> aufzusetzen. Im Übrigem schlägt das auch das Manual von V2os vor.

...womit sich das System selber konterkariert.

Schlaue Systemarchitekten legen die Grenze Assembler/Hochsprache an eine 
sinnvolle Stelle, statt pauschal alles in Assembler zu machen.

[db8fs (Gast)]

Eddy C. schrieb:
> Spar Dir Deine Rethorik. Wenn ich Assembler brauche, werde ich es
> bemerken und es gibt im Netz genügend passende Resourcen. Da brauche ich
> kein komplettes(!) Betriebssystem dazu.

Halt, stopp - das habe ich nie gesagt, dass du dein komplettes OS nur 
mit in Asm schreiben sollst. Das wäre tatsächlich unverhältnismäßig und 
unvernünftig und ist nur da angemessen, wo die Performance essentiell 
ist.

Ist mir vollkommen klar, das kein vernunftbegabter Mensch außer durch 
äußerste Nöte gezwungen ein komplettes modernes Betriebssystem in ASM 
schreibt.

Worauf ich hinaus wollte: um eine Befehlsarchitektur zu verstehen, macht 
es Sinn, sich mal mit Asm beschäftigt zu haben und das auf 'ner 
RISC-Architektur (o.g. AVR Beispiel) zu tun.

Du hast aber recht: hab oben ungeschickt gequotet bzw. falsch auf den 
Quote Bezug genommen.

[Higg G. (Gast)]

Gascht schrieb:
> Meine erste Frage, macht es nicht eher Sinn sich mit X64-Systemen zu
> beschäftigen als X86 oder verstehe ich hier etwas total falsch? X64 =
> 64Bit, X86 = 32Bit.

> Meine zweite und WICHTIGERE Frage, macht es Sinn ein Betriebssystem mit
> C++ zu programmieren oder nicht?

Du kannst direkt mit der AMD64 Plattform beginnen, ob dies jedoch 
sinnvoll ist, steht auf einem anderen Blatt. Auch kannst du C++ 
einsetzten. Wenn du dich selbst jedoch als "forgeschrittener Anfänger" 
bezeichnest, und von C keine Ahnung hast würde ich dir davon abraten.

Der klassische Ansatz wäre erstmal im 32Bit Proteced Mode mit C und ein 
wenig Assembler zu starten. Ein guter Start hierfür wäre das Tutorial 
auf www.lowlevel.eu . Auch wiki.osdev.org wie weiter oben schon genannt 
ist ein guter Einstieg. Hier findest du auch Grundgerüste für die 
verschiedensten Sprachen.

Wenn du davor zurückschreckst C zu lernen dann sei dir versichert: Das 
wäre der absolut kleinste Teil. Da gibt es Tonnen an 
architekturspezifischen Sachen die du dir geben musst, und die solltest 
du in C und Assembler hinkriegen und verstehen. Wenn das klappt, kannst 
du auf die Sprache deiner Wahl umsteigen. Aber übernimm dich am Anfang 
nicht. Mach das tutorial von lowlevel.eu, nimm GRUB als Bootloader und 
du wirst selbst irgendwann ein Gefühl kriegen, in welche Richtung du 
gehen willst.

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

Wegstaben V. schrieb:
> Auch bei Betriebssystemen (bzw. deren Entwicklung) ins die
> Prozessor-Architektur nicht primär wichtig. [wenn man technische
> Größenbeschränkungen mal außen vor läßt - ein TinyLinux OS auf einem
> Tiny2313 wäre mal eine sportliche Aufgabe ;-)

Die wesentlichen Unterschiede zwischen Prozessorarchitekturen bzw. deren 
Implementierungen in reale Bausteine bestehen nicht (nur) in den Größen 
von Adressräumen und Registersätzen, sondern darin, welche besonderen 
Merkmale zur Betriebssystemunterstützung sie besitzen:

- geschützte/ungeschützte Betriebsarten (Modes, "Ringe")
- Speicherverwaltung (Speicherschutz, Zugriffsmodi, Paging)
- Caching (virtuell, physikalisch)
- Virtualisierungsunterstützung (CPU-Kerne, Speicher, I/O)
- Prozessoren, Prozessorkerne, Prozessorbuskopplung

Ab einem gewissen Abtraktionsgrad sollten diese grundlegenden 
Hardwareeigenschaften natürlich verborgen werden, spielen aber auf den 
unteren Schichten eine ganz erhebliche Rolle, gerade in Hinblick auf die 
einzusetzenden Synchronisationsmechanismen. Und will man ein 
Betriebssystem entwickeln, dass auf Rechnern mit unterschiedlicher 
Ausstattung dieser Ressourcen läuft, muss man schon erheblichen Aufwand 
in die entsprechenden Konzepte hineinstecken. Das ganze sprengt aber 
auch sehr schnell den Umfang, den man im Alleingang noch realisieren 
könnte. Jedoch muss man auch bedenken, dass Linus Torvalds sein Linux 
ursprünglich nicht in Hinblick auf möglichst viele unterstützte 
Plattformen und Architekturen geschrieben hat, sondern nur weil er ein 
kostenloses UNIX-artigen Betriebssystem für seinen 80386-basierten PC 
benötigte.

[Andreas R. (daybyter)]

Alleingang ist ein gutes Stichwort. Was sollte andere Leute motivieren, 
etwas zu dem System beizutragen? Also was soll das System besser machen, 
als aktuell verfügbare Systeme? Welche Fehler/Probleme willst Du 
beheben?

[Klaus (Gast)]

db8fs schrieb:
> ist nur da angemessen, wo die Performance essentiell
> ist.

Eigentlich auch da nicht. Es gibt eigentlich nur einen wirklichen Grund 
Assembler zu verwenden: es geht nicht anders. So z.B. Manipulationen am 
Stack im Scheduler, Bus locking, garantiert atomare Instruktionen oder 
die Implementation von Systemcalls.

MfG Klaus

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

Ich antworte einmal stellvertretend für jemanden, der sich in die 
Thematik einarbeiten möchte.

Andreas R. schrieb:
> Alleingang ist ein gutes Stichwort. Was sollte andere Leute motivieren,
> etwas zu dem System beizutragen?

Nichts.

> Also was soll das System besser machen, als aktuell verfügbare Systeme?

Man erlernt bestimmte Techniken durch eigene Erfahrung und versteht 
dadurch besser die Gründe, warum bestimmte Funktionalitäten anderer 
Betriebssysteme genau so gelöst sind und nicht anders.

Das Problem ist jedoch, dass man bei einem eigenen Mini-Betriebssystem 
nicht alle Aspekte des Betriebssystembaus kennenlernen wird, 
insbesondere was die Skalierung von Ressourcen angeht.

> Welche Fehler/Probleme willst Du beheben?

Den Mangel an eigenen Kenntnissen im Bereich Betriebssysteme.

[db8fs (Gast)]

Klaus schrieb:
> db8fs schrieb:
>> ist nur da angemessen, wo die Performance essentiell
>> ist.
> Eigentlich auch da nicht. Es gibt eigentlich nur einen wirklichen Grund
> Assembler zu verwenden: es geht nicht anders.

Das schließt aber obiges Argument nicht aus. :)
Und gerade wenn es Befehlssatzerweiterungen geben könnte, die u.U. von 
Vorteil sind, dann kommt's drauf an, wie gut dein C/C++-Compiler mit 
Intrinsics umgeht.

Beim Linux-Kern stolpert man beim Schnüffeln durch die Sourcen 
jedenfalls öfters mal über die ein oder andere .s Datei...

> So z.B. Manipulationen am
> Stack im Scheduler, Bus locking, garantiert atomare Instruktionen oder
> die Implementation von Systemcalls.

Jo, gute Beispiele.

[Karl Käfer (Gast)]

Hallo Eddy,

Eddy C. schrieb:
> Karl Käfer schrieb:
>> Hälst Du Linus' Behauptung, daß C++ schlecht sei, weil so viele
>> schlechte Programmierer es benutzen, für eine kompetente Argumentation?
>> Ich nicht.
>
> So wie Du es ausdrückst, hast Du natürlich recht.

Nicht ich drücke das so aus, sondern Linus, und ich möchte mir das gar 
nicht zu Eigen machen. Vor allem auch deswegen, weil ich diesbezüglich 
ausnahmsweise eine gegenteilige Ansicht vertrete als er.

> Linus meint wohl eher, dass das Problem ist, dass Du eine Horde
> unerfahrener Programmierer hast, die alle meinen, objektorientiert
> programmieren zu können.

Linus "Argumentation" zielt erstens nicht auf Objektorientierung, 
sondern nur auf C++ ab. OO kann man auch in C machen, damit hat Linus 
offenbar kein Problem, wie man im Code des Linux-Kernel an vielen 
Stellen sehen kann (siehe dazu [1] und [2]). Es geht ihm also 
offensichtlich nicht um das objektorientierte Paradigma an sich.

Zweitens können auch unerfahrene C-Programmierer enormes Unheil 
anrichten; gerade die Fragen hier in diesem Forum zeigen das jeden Tag. 
Linus beweist das selbst, indem er regelmäßig eingereichten Code 
zurückweist.

Insofern sagt Linus' Rant nicht viel über C++ oder über 
Objektorientierung in der Entwicklung von Betriebssystemkerneln aus, 
sondern nur über Linus' ganz persönliche Präferenzen -- nicht weniger, 
aber eben auch nicht mehr. Seine Ausführungen sollte man daher nicht 
überbewerten, sondern als genau das sehen, was sie sind: nämlich als den 
(nachgerade erfolglosen) Versuch, persönliche Präferenzen mit sachlich 
klingenden Argumenten zu belegen.

Angelegentlich würde ich zu gerne einmal einer Diskussion zwischen Linus 
und namhaften C++-Entwicklern wie Bjarne Stroustrup oder Herb Sutter 
beiwohnen. Vermutlich würde Linus dabei ganz schön alt aussehen.

Liebe Grüße,
Karl

[1] https://lwn.net/Articles/444910/
[2] https://lwn.net/Articles/446317/

[Karl Käfer (Gast)]

Hallo Moby,

Moby schrieb:
> Karl Käfer schrieb:
>> Hälst Du Linus' Behauptung, daß C++ schlecht sei, weil so viele
>> schlechte Programmierer es benutzen, für eine kompetente Argumentation?
>> Ich nicht.
>
> Ich schon. Da liegt der Torvalds nicht daneben.

Trotzdem hat er sein Betriebssystem nicht in Deinem geliebten Assembler, 
sondern in C geschrieben. Blutet Dir da nicht das Herz? ;-)

> Die Masse der Programmierkünste in C++ sagt eben auch etwas über die
> Qualität der Sprache an sich aus. Was sich zu kompliziert nutzen lässt
> kann eben kaum optimal genutzt werden.

Ach, weißt Du, ich hab' schon zu viel beschissenen C- und Assembler-Code 
gesehen, um über dieses Stöckchen zu springen. Programmierung ist und 
bleibt eben ein schwieriges, kompliziertes Handwerk, bei dem manche ihre 
Werkzeuge beherrschen, und andere eben nicht.

Liebe Grüße,
Karl

[Pandur S. (jetztnicht)]

> Ich bin ein fortgeschrittener Anfänger in C++.

Das ist etwas auf der mageren Seite. Kann aber trotzdem erleuchtend 
sein.

Allenfalls kann man sich da Gedanken ueber einen ARM machen, zB einen 
Raspi.
Und dabei maximal viel weglassen. zB
- Multiuser
- Video
- Netzwerk
- File system
- IO
dh sich konzentrieren auf
- Laufen ab Flash, oder nur RAM
- Startup Code
- Loader
- MMU
- Scheduler
- ein paar Systemcalls

[Moby (Gast)]

Karl Käfer schrieb:
> Programmierung ist und
> bleibt eben ein schwieriges, kompliziertes Handwerk,

Da ist wohl eher der Wunsch (die eigenen Investments in Wissen und 
Können wertgeschätzt zu wissen) Vater des Gedankens.
Nicht nur die Programmierer sind besser oder schlechter, auch die 
Werkzeuge und Sprachen sind es. Für den konkreten Zweck mehr oder 
weniger geeignet. Einfacher anwendbar oder eben unnötig kompliziert.

Karl Käfer schrieb:
> Trotzdem hat er sein Betriebssystem nicht in Deinem geliebten Assembler,
> sondern in C geschrieben. Blutet Dir da nicht das Herz? ;-)

Nein. So schön eine Asm-Lösung ist. Auf deren Vorteile zu verzichten 
bedeutet eben auch, mit einer Hochsprache schneller ans Ziel zu kommen. 
Die programmtechnische Softwarelandschaft ist im PC-Bereich darauf 
ausgerichtet. Und die zugrundeliegende PC Hardware über die Jahre aus 
Kompatibilitätsgründen so unnötig komplex und vermurkst, daß dem 
Asm-Programmierer unnötig viele Detailkenntnisse abverlangt würden.

[Karl Käfer (Gast)]

Hallo Moby,

Moby schrieb:
> Karl Käfer schrieb:
>> Programmierung ist und
>> bleibt eben ein schwieriges, kompliziertes Handwerk,
>
> Da ist wohl eher der Wunsch (die eigenen Investments in Wissen und
> Können wertgeschätzt zu wissen) Vater des Gedankens.

LOL! Ach, weißt Du, ich bin im Laufe von dreißig Jahren Karriere in der 
IT so viele Irrwege gegangen und wieder davon abgekommen... da machen 
mir ein paar Kerben mehr in meinem Schreibtisch schon lange nichts mehr 
aus. ;-)

> Nicht nur die Programmierer sind besser oder schlechter, auch die
> Werkzeuge und Sprachen sind es. Für den konkreten Zweck mehr oder
> weniger geeignet. Einfacher anwendbar oder eben unnötig kompliziert.

Daß Du mit C und C++ überfordert bist (oder sein willst), ist Dein 
eigenes Problem und gilt nur für Dich selbst. Daß Du Deine 
überschaubaren Skills deswegen als das Nonplusultra und "mehr braucht 
man eh nicht" darstellen mußt, gehört zum Dasein als typisches 
One-Trick-Pony. Mir sind im Laufe meines Lebens schon eine ganze Reihe 
solcher Leute untergekommen, für die die Erfahrung, ihre erste 
Programmiersprache zu lernen, so traumatisch und hart gewesen ist, daß 
sie sich danach mit allen Mitteln dagegen gewehrt haben, eine weitere 
Sprache oder ein neues Paradigma zu lernen. Meistens waren diese Leute 
aber auch in "ihrer" Sprache ziemlich schlecht, hatten dafür aber immer 
die größte Klappe, wenn es darum ging, andere Sprachen und Technologien 
zu bepöbeln.

> Nein. So schön eine Asm-Lösung ist. Auf deren Vorteile zu verzichten
> bedeutet eben auch, mit einer Hochsprache schneller ans Ziel zu kommen.
> Die programmtechnische Softwarelandschaft ist im PC-Bereich darauf
> ausgerichtet. Und die zugrundeliegende PC Hardware über die Jahre aus
> Kompatibilitätsgründen so unnötig komplex und vermurkst, daß dem
> Asm-Programmierer unnötig viele Detailkenntnisse abverlangt würden.

Ach, jetzt ist auf einmal die Hardware schuld? Nee, ist klar. Um 
Ausreden bist Du also wieder einmal nicht verlegen.

Liebe Grüße,
Karl

[Moby (Gast)]

Kritisches Hinterfragen des allzu offensichtlichen 
PC-Programmieraufwands muss man natürlich irgendwann

Karl Käfer schrieb:
> bepöbeln

nennen, wenn einem sonst dazu nichts mehr einfällt (und sich der Experte 
dieses Aufwands an irgendeinem empfindlichen Punkt getroffen sieht).
Gleiches gilt ebenso für

> Ausreden.

Immerhin, mit der GUI Erstellung gab es in den letzten Jahren bzgl. 
Vereinfachung einen signifikanten Fortschritt. Das habe ich auch 
ausdrücklich anerkannt.

[christian (Gast)]

Eigentlich alle mir bekannten Betriebssysteme sind zumindest zum größten 
Teil in C geschrieben:

- Linux: Der gesamte Kernel und die system calls sind in C geschrieben. 
Mit Ausnahme des boot-startup Codes, context switches oder interrupt 
routinen, die in Assembler implementiert sind. Natürlich gibt es noch 
einige script Sprachen(perl,shell,phyton), die schon zum Initialisieren 
der Prozesse beim Booten notwendig sind, aber auch deren Interpreter 
sind letzten Endes in C geschriebene Software.

- Windows: Der Windows Kernel ist mit ziemlicher Sicherheit in C 
geschrieben.Natürlich gibt es auch viel C++ beim Win OS, aber nicht wenn 
es um System-relevante Dinge wie Scheduler, Interrupts... geht. Auch die 
gesamte Windows API ist in C implementiert! Selbst in .net Zeiten hat 
sich Microsoft noch nicht gewagt diese auf eine andere Sprache zu 
implementieren.

- Android: Ein Linux Fork, dessen Kernel daher nach wie vor in C 
geschrieben ist. Die Java Komponenten betreffen ja nicht das eigentliche 
OS und sind durch die VM vom Kernel abgekapselt.

- Mac: Kernel ist in C geschrieben.

Der Grund ist bestechend einfach. C wurde gerade dafür und für 
eingebette Systeme entwickelt. Z.b. die interne Speicherorganisation 
lässt sich in C durch struct-Typen eins zu eins nachbilden. Das geht 
halt nicht mit Klassen.

Gruß
Christian

[Karl H. (kbuchegg)]

christian schrieb:

> Der Grund ist bestechend einfach. C wurde gerade dafür und für
> eingebette Systeme entwickelt. Z.b. die interne Speicherorganisation
> lässt sich in C durch struct-Typen eins zu eins nachbilden. Das geht
> halt nicht mit Klassen.



Was für ein Blödsinn.

Sorry. Aber das musste mal gesagt werden.
Karl Käfer hat vollkommen recht.

Und wenn ich den Quatsch schon höre: C++ sei so wahnsinnig kompliziert 
in der Anwendung. Das würde ich gerne mal sehen, was den an zb den STL 
Container Klassen kompliziert in der Verwendung wäre. ein std::vector 
ist simpler zu benutzen und vor allen Dingen fehlerfreier zu benutzen 
als es ein in C dynamisch allokiertes Array je sein könnte. Selbiges für 
String-Verarbeitung und noch mindestens 150 andere Dinge.

>  Ich kann ja alle Sprachmittel die es in C nicht gibt weglassen und
> nur mit denen programmieren die C auch hat. Mir gehts nur darum
> nicht C von der Pike auf lernen zu müssen.

Da frage ich mich doch glatt, woher du wissen willst, das es in C nicht 
gibt, wenn du C gar nicht kannst. Wie willst du wissen, wie du Dinge in 
C++ kastrieren musst, damit du eine C-taugliche Implementierung kriegst?
Wasch mir den Pelz aber mach mich nicht nass.

[christian (Gast)]

Karl H. schrieb:
> christian schrieb:
>
>> Der Grund ist bestechend einfach. C wurde gerade dafür und für
>> eingebette Systeme entwickelt. Z.b. die interne Speicherorganisation
>> lässt sich in C durch struct-Typen eins zu eins nachbilden. Das geht
>> halt nicht mit Klassen.
>
> Was für ein Blödsinn.

Warum ist das Blödsinn? In der Hardware-nahen Programmierung, also 
µC,embedded, Kernel-Entwicklung..., ist man daran interessiert z.b. 
Speicherlayouts entsprechend ihren realen Adressen in der HW, 
nachzubilden. Mit C++ Klassen ist das nun einmal nicht immer möglich, 
wenn z.b. virtuelle Funktionen im Spiel sind.

Will man einen zusammenhängenden sequentiellen Speicherbereich in SW 
nachbilden, kommt niemand mit Verstand auf die Idee das mit Klassen zu 
machen.(Außer vielleicht Karl Heinz).

Wer garantiert mir denn, das meine Klassen-Member in C++ wirklich 
sequentiell aufeinander folgen. Oder das die Adresse meiner Klasse auch 
gleich der Adresse des ersten Klassen Members ist. Eben sequentiell wie 
im Speicher.

Natürlich hat C++ seine Daseinsberechtigung. Ganz klar. Aber nicht in 
allen Bereichen.

Allein aufgrund der Mächtigkeit der Sprache ist man manchmal mehr damit 
beschäftigt, z.b. OOP auch wirklich konsequent umzusetzten, als mit dem 
SW-Algorithmus selber.

Gruß
Christian

[TriHexagon (Gast)]

christian schrieb:
> Natürlich hat C++ seine Daseinsberechtigung. Ganz klar. Aber nicht in
> allen Bereichen.

Und das spricht wie jetzt gegen C++ auf Embedded? Dann lass die Klassen 
halt weg. Dann hast du immer noch Strukturen, Array, etc. also 99.99% 
was C kann.
Hast aber dagegen ein paar Sachen die C nicht beherrscht wie z.B. 
Templates.

christian schrieb:
> Wer garantiert mir denn, das meine Klassen-Member in C++ wirklich
> sequentiell aufeinander folgen. Oder das die Adresse meiner Klasse auch
> gleich der Adresse des ersten Klassen Members ist. Eben sequentiell wie
> im Speicher.

Ich verrate dir ein Geheimnis: das garantieren Strukturen auch nicht. 
Und packed structs gibts auch nicht im Standard, sondern nur als 
Compilerspezifisches Attribut.

[christian (Gast)]

TriHexagon schrieb:
> Ich verrate dir ein Geheimnis: das garantieren Strukturen auch nicht.

Doch, genau das ist der Fall. Mit Ausnahme von Speicherausrichtung, wenn 
Datentypen z.b. auf einer ungeraden Adresse folgen. Aber auch das ist 
hier Compiler-und Prozessor abhängig und hat nichts mit der Sprache C zu 
tun.

Aber C++ garantiert mir per default nicht, das die Adresse der Klasse 
mit dem ersten Dateneintrag übereinstimmt!

TriHexagon schrieb:
> Dann lass die Klassen
> halt weg. Dann hast du immer noch Strukturen, Array, etc. also 99.99%
> was C kann.

Also letzten Endes wird doch wieder auf das gute alte C zugegriffen. Ihr 
widersprecht euch doch selber ;-)

[Rolf Magnus (Gast)]

christian schrieb:
> Wer garantiert mir denn, das meine Klassen-Member in C++ wirklich
> sequentiell aufeinander folgen.

Es gibt zwar ein paar Voraussetzungen, aber wenn man die einhält, 
garantiert C++ genauso viel wie C.

> Oder das die Adresse meiner Klasse auch gleich der Adresse des ersten
> Klassen Members ist. Eben sequentiell wie im Speicher.

Ich verrate dir ein Geheimnis: In C++ sind Klassen und Strukturen genau 
das gleiche. Du kannst mit einer Klasse alles machen, was du in C++ 
(oder in C) mit einer Struktur könntest. Und 
Betriebssystemprogrammierung besteht abgesehen davon nicht nur aus dem 
Low-Level-Zugriff auf Hardware-Register. Der Linux-Kernel bildet 
übrigens auch an verschiedneen Stellen teilweise OOP-Konzepte nach, aber 
eben nicht so schön, wie man es in C++ nativ ausdrücken könnte. Allein 
das zeigt, daß OOP im Kernel durchaus sinnvoll sein kann.

> Natürlich hat C++ seine Daseinsberechtigung. Ganz klar. Aber nicht in
> allen Bereichen.

Zumindest in praktisch allen Bereichen, in denen auch C seine 
Daseinsberechtigung hat.

> Allein aufgrund der Mächtigkeit der Sprache ist man manchmal mehr damit
> beschäftigt, z.b. OOP auch wirklich konsequent umzusetzten, als mit dem
> SW-Algorithmus selber.

Das schöne an C++ ist, daß man OOP auch gezielt nur dort einsetzen kann, 
wo es sinnvoll ist und nicht gezwungen ist, alles komplett ins 
OOP-Korsett zu zwängen wie z.B. bei Java.

[Borislav B. (boris_b)]

Rolf Magnus schrieb:
> Das schöne an C++ ist, daß man OOP auch gezielt nur dort einsetzen kann,
> wo es sinnvoll ist und nicht gezwungen ist, alles komplett ins
> OOP-Korsett zu zwängen wie z.B. bei Java.

Das ist doch bei jeder Sprache so. Sei es C++, Java oder sonst was.
Nur weil man mit Objekten hantiert, ist es noch lange nicht OOP.

Beispiel:

public class MainClass {
  public static void main(String[] args) throws IOException {
    BufferedReader in = new BufferedReader(new InputStreamReader(System.in));
    String s;
    while ((s = in.readLine()) != null && s.length() != 0)
      System.out.println(s);
  }
}

Das ist zwar Java, aber definitiv nach dem prozeduralen 
Programmier-Paradigma geschrieben.
In C sähe das auch nicht viel anders aus.

OOP fängt eigentlich erst da an, wo fortgeschrittene Konzepte wie 
Vererbung usw. ins Spiel kommen. Und die kann man nutzen, muss man aber 
nicht. In c++ genauso wie in Java.

[christian (Gast)]

Rolf Magnus schrieb:
> Ich verrate dir ein Geheimnis: In C++ sind Klassen und Strukturen genau
> das gleiche.

Das ist wirklich ein Geheimnis. Funktionell sind sie gleich. Aber per 
default sind struct Daten public, bei einer Klasse privat.

Aber nochmal zum Verständnis:
Es gibt in C++ Mechanismen, die bestimmte Regeln aufbrechen, das Daten 
einer Klasse sequentiell aufeinander folgen(abgesehen vom Compiler 
Padding). Z.b. eine Klasse mit virtuellen Funktionen. Eine solche Klasse 
und alle davon geerbten Klassen besitzen bestimmte Einträge in ihrer 
Klasse als Zeiger auf eine virtuelle Tabelle. Damit ist die sequentielle 
Ausrichtung dahin. Und die ist nun einmal notwendig um Hardware nah zu 
programmieren!!!

Rolf Magnus schrieb:
> Der Linux-Kernel bildet
> übrigens auch an verschiedneen Stellen teilweise OOP-Konzepte nach

Falsch. Er bildet sie nicht nach. Es werden nur die gleichen Konzepte 
wie bei OOP genutzt, da ja nicht grundsätzlich alles bei OOP unnütz ist.

Aber Gegenfrage:
Warum ist die gesamte Windows API in C implementiert?

Warum schleppen alle VM basierten OOP Sprachen(C#,Java...) umständliche 
C-Schnittstellen mit sich herum, um auf die APIs zuzugreifen?

Warum hat sich selbst Microsoft noch nicht getraut die Win Api auf eine 
OOP Sprache umzusetzten?

Gruß
Christian

[Borislav B. (boris_b)]

christian schrieb:
> Warum hat sich selbst Microsoft noch nicht getraut die Win Api auf eine
> OOP Sprache umzusetzten?

Genau das haben sie doch gemacht. nennt sich WinRT API"
-> https://de.wikipedia.org/wiki/Windows_Runtime

[christian (Gast)]

Boris P. schrieb:
> christian schrieb:
>> Warum hat sich selbst Microsoft noch nicht getraut die Win Api auf eine
>> OOP Sprache umzusetzten?
>
> Genau das haben sie doch gemacht. nennt sich WinRT API"
> -> https://de.wikipedia.org/wiki/Windows_Runtime

Die WinRT ist kein Ersatz für die Win32-Api.Es stellt nur gewisse 
Hilfsfunktionen(Steuerelemente usw) für die Programmierung von Apps 
unter Win8 und Windows Phone bereit.

[Borislav B. (boris_b)]

christian schrieb:
> Die WinRT ist kein Ersatz für die Win32-Api.Es stellt nur gewisse
> Hilfsfunktionen(Steuerelemente usw) für die Programmierung von Apps
> unter Win8 und Windows Phone bereit.

Doch. Sie hat den gleichen Zweck und in etwa den gleichen 
Funktionsumfang (Devices, File System, Grafik etc.) wie die Win32 API.

Gedacht ist sie, wie du richtig erkannt hast, für "Modern UI" 
Anwendungen.

[christian (Gast)]

Mag sein das sie als Ersatz zur Win Api gedacht ist. Aber sie bildet 
(noch) nicht alle Funktionen ab und ist sehr beschränkt in der 
Anwendungsebene und OS-Auswahl(Win8,Phone)

Gruß
Christian

[Borislav B. (boris_b)]

christian schrieb:
> Mag sein das sie als Ersatz zur Win Api gedacht ist. Aber sie bildet
> (noch) nicht alle Funktionen ab und ist sehr beschränkt in der
> Anwendungsebene und OS-Auswahl(Win8,Phone)

Richtig, aber darum ging es ja auch garnicht. Deine ursprüngliche 
Aussage war:

> Warum hat sich selbst Microsoft noch nicht getraut die Win Api auf eine
> OOP Sprache umzusetzten?

Und ich denke, die ist hiermit wiederlegt ;-)

Microsoft entwickelt seit geraumer Zeit ausschließlich OOP, und die 
alten Krücken (Win32, MFC, ...) sterben allmählich aus...
Die Zukunft heißt wohl "UWP".

[christian (Gast)]

Boris P. schrieb:
> und die
> alten Krücken (Win32, MFC, ...) sterben allmälich aus...

Wir sprechen uns in 10 Jahren wieder ;-)

Gruß
Christian

[Karl H. (kbuchegg)]

christian schrieb:
> Rolf Magnus schrieb:
>> Ich verrate dir ein Geheimnis: In C++ sind Klassen und Strukturen genau
>> das gleiche.
>
> Das ist wirklich ein Geheimnis. Funktionell sind sie gleich. Aber per
> default sind struct Daten public, bei einer Klasse privat.

Dann schreibst du eben an den Anfang der Klasse public und gut ists, 
wenn du nicht 'struct' schreiben willst.

Und nein: auch funktional sind sie nicht gleich. Die Aussage: In C++ 
sind Klassen und Strukturen genau das gleiche, muss man ernst nehmen. 
Auch Strukturen können Memberfunktionen enthalten. Alleine die Tatsache, 
dass man Konstruktoren schreiben kann, die dann auch zuverlässig 
aufgerufen werden, mindert schon mal haufenweise Fehler. Alleine nur 
dafür, für Konstruktoren und Destruktoren, lohnt sich C++.
Vom Rest der dann noch übrig bleibt hat man mit einer String Klasse dann 
schon wieder geschätzte 90% aller lästigen Fehler weg. Ob das dann die 
std::string Klasse ist, oder eine eigene String Klasse ist 
nebensächlich. Der springende Punkt ist, dass mir C++ Möglichkeiten in 
die Hand gibt, wie ich die Dinge sicher machen kann - und zwar ohne 
dass ich auf die Selbstdisziplin von einer Horde Programmierer bauen 
muss. Wenn es nur dieser eine Punkt wäre, würde sich der Einsatz von C++ 
schon lohnen.

> Padding). Z.b. eine Klasse mit virtuellen Funktionen. Eine solche Klasse
> und alle davon geerbten Klassen besitzen bestimmte Einträge in ihrer
> Klasse als Zeiger auf eine virtuelle Tabelle.

Schön.
Und wenn du den Mechanismus von virtuellen Funktionen haben willst, dann 
musst du das in C nachprogrammieren. Letzten Endes landest du entweder
* bei Typ Membern in allen Strukturen (mit allen Problemen bei 
Erweiterungen)
* oder eben dabei, dass du genau den Mechanismus nachprogrammierst, den 
dir der C++ Compiler für polymorphe Funktionsaufrufe sowieso baut.
Brauchst du einen polymorphen Mechanismus, dann benutzt du in C++ 
virtuelle Funktionen oder du programmierst dir etwas vergleichbares in C 
nach. Brauchst du keine polymorphes Verhalten, dann benutzt du in C++ 
auch keine virtuellen Funktionen. Es ist ganz einfach. Auch in C++ gilt: 
du zahlst nicht für etwas, was du gar nicht benutzt.

Im übrigen schmeisst auch ein C++ Compiler nicht einfach die Member 
durcheinander, sondern voneinander abgeleitete Klassen sind wie 
Zwiebelschalen ineinander gelegt. Anders geht es gar nicht, sonst wäre 
ein gewolltes slicing von Objekten überhaupt nicht möglich.
Was anderes machst du auch nicht, wenn du innerhalb einer Struktur einen 
anderen Strukturmember am Anfang oder am Ende der Struktur hast. Nur 
dass dir der C++ Compiler die ganze Verwaltungsarbeit abnimmt.

Daher: so ein Blödsinn.
Du zeigst eigentlich nur, dass du nicht viel Ahnung davon hast, wie C++ 
im inneren funktioniert und nur das nachplapperst, was dir dein 'Guru' 
Linus Torvalds vorplappert.

[Gascht (Gast)]

Jetzt N. schrieb:
> Allenfalls kann man sich da Gedanken ueber einen ARM machen, zB einen
> Raspi.
> Und dabei maximal viel weglassen. zB
> - Multiuser
> - Video
> - Netzwerk
> - File system
> - IO
> dh sich konzentrieren auf
> - Laufen ab Flash, oder nur RAM
> - Startup Code
> - Loader
> - MMU
> - Scheduler
> - ein paar Systemcalls

Wenn das für den Einstieg einfacher ist und es eine gute Doku gibt, 
hätte ich nichts dagegen an einem ARM oder Raspberry zu experimentieren. 
Ich werde auch selber im Netz danach suchen, würde mich aber über Links 
freuen.

[Karl H. (kbuchegg)]

Wenn du nach einem gut dokumentierten BS suchst, in dessen Beschreibung 
auch auf Prinzipien und Techiken eingegengen wird, dann hab ich vor 
Jahrzehnten mit Minix gute Erfahrungen gemacht

https://de.wikipedia.org/wiki/Minix_(Betriebssystem)
(Im Link die schliessende Klammer ergänzen - Forumsfehler)

Ob es das zugehörige Buch von Andrew Tannenbaum noch gibt, kann ich 
nicht sagen. Das weiss sicher Amazon.

Minix ist in seiner Urversion klein und modular, es ist gut (mit dem 
Buch) dokumentiert und die Ideen bzw. Strukturierung sind 
nachvollziehbar.
Hier würdeich sogar soweit gehen, dass ich sage: je älter die Version 
ist, die du auftreiben kannst, umso besser. Denn ansonsten wirst du vom 
Umfang erschlagen.

[christian (Gast)]

Ja genau. Kernel Entwickler auf der ganzen Welt irren hier und 
programmieren nur aus Unkenntnis heraus in C. Aber egal.

Anwenderentwickler sehen das anscheinend anders als z.b. Entwickler im 
embedded respektive µC-Bereich. Ich hab noch keine Entwicklungsabteilung 
gesehen, die auf die Idee kommen würde C++ als Standard im HW nahen 
Bereich einzusetzen. Eben auch aufgrund meiner oben genannten Gründe.

Gruß
Christian

[Karl H. (kbuchegg)]

christian schrieb:
> Ja genau. Kernel Entwickler auf der ganzen Welt irren hier und
> programmieren nur aus Unkenntnis heraus in C. Aber egal.

Kernel Entwickler (ich denke du meinst Linux Kernel Entwickler, kleiner 
Unterschied) entwickeln in C, weil das die Vorgabe von Linus ist und 
nicht weil es einen triftigen Grund gibt, nicht C++ zu benutzen. Letzten 
Endes ist es ein wenig witzlos, seine Zeit zu investieren, nur damit 
Linus dann den Code zurückweisst, weil er C++ Elemente verwendet, die 
man dann in reinem C erst recht wieder völlig sinnloserweise 
nachprogrammieren muss.
Du verkennst da ein wenig die Gründe und Ursachen. Das ganze hat nichts 
mit irgendwelchen technischen Gründen zu tun (ausser vielleicht, dass 
damals in den Urzeiten von Linux die C++ Compiler noch nicht so wei 
waren), sondern beruht einzig und alleine auf den Vorurteilen eines 
einzelnen.

C++ wird nicht umsonst das bessere C genannt.

[Gascht (Gast)]

Also jetzt habe ich schon zwei interessante Empfehlungen gelesen.

Zum einen das Minix OS, zum anderen der Raspberry PI mit 
ARM-Architektur.

So wie ich das sehe, kann man mit dem Raspberry wie mit einem PC 
arbeiten und hat gleichzeitig I/O Pins wie bei einem Mikrocontroller für 
Sensoren, LEDs, Taster, Motoren, (auch kleine Displays?). Das sieht 
wirklich sehr interessant für mich aus. Jetzt muss ich hierfür nur noch 
eine gute Doku finden.

In Minix muss ich mich noch einlesen, ist sicher auch was für mich, wie 
gesagt muss erstmal im Detail die Homepage studieren u. dann ggf. auch 
das Buch kaufen.

[(prx) A. K. (prx)]

christian schrieb:
> Es gibt in C++ Mechanismen, die bestimmte Regeln aufbrechen, das Daten
> einer Klasse sequentiell aufeinander folgen

Zentrale Datenstrukturen, deren Layout derart festgelegt ist, dass jede 
vom Compiler erwirkte Änderung das System umwirft, lassen sich mit 
solchen Klassen nicht unmittelbar vereinbaren.

Das muss einen jedoch nicht daran hindern, C++ zusammen mit solchen 
Objekten zu verwenden. Mann kann sie in C Manier deklarieren und 
beispielsweise als Basisklasse oder Unterstruktur einer normalen C++ 
Klasse verwenden. Damit verbinden sich die Möglichkeiten von C++ mit der 
exakten Struktur von C.

Bei Mikrocontrollern sieht das auch nicht viel anders aus. Man kann zwar 
den I/O-Bereich einer UART nicht direkt als Klasse darstellen, aber man 
kann einen UART Kanal als Klassenobjekt definieren, in dem dann ein 
Zeiger auf den in C Manier definierten IO-Bereich liegt.

[Günter Lenz (Gast)]

Gascht schrieb:
>Jetzt muss ich hierfür nur noch
>eine gute Doku finden.

http://www.netzmafia.de/skripten/hardware/RasPi/index.html

[Karl Käfer (Gast)]

Hallo christian,

christian schrieb:
> Ja genau. Kernel Entwickler auf der ganzen Welt irren hier und
> programmieren nur aus Unkenntnis heraus in C.

...und wenn einem sogar Falsches oder Dummes mehr einfällt, nimmt man 
ein Argumentum ad populum und polemisiert ein wenig drumherum.

Belustigt,
Karl

[Karl Käfer (Gast)]

Hi,

Gascht schrieb:
> So wie ich das sehe, kann man mit dem Raspberry wie mit einem PC
> arbeiten und hat gleichzeitig I/O Pins wie bei einem Mikrocontroller für
> Sensoren, LEDs, Taster, Motoren, (auch kleine Displays?). Das sieht
> wirklich sehr interessant für mich aus. Jetzt muss ich hierfür nur noch
> eine gute Doku finden.

Um die Hardware besser zu verstehen, ist der Assembler-Kurs der 
Universität von Cambridge vielleicht hilfreich: [1].

Liebe Grüße,
Karl


[1] 
https://www.cl.cam.ac.uk/projects/raspberrypi/tutorials/os/index.html

[Karl Käfer (Gast)]

Ach,

Karl Käfer schrieb:
> ...und wenn einem sogar Falsches oder Dummes mehr einfällt, nimmt man
> ein Argumentum ad populum und polemisiert ein wenig drumherum.

Da fehlt ein "nichts" vor "Falsches", tut der Belustigung aber keinen 
Abbruch.

;-),
Karl

[Gascht (Gast)]

Super, vielen Dank für die Links zur Uniseite und Netzmafia, damit werde 
ich vermutlich glücklich :-)

Die Uniseite habe ich auch gefunden, ja ich habe google bemüht :-P

[Gascht (Gast)]

Noch ne Frage, es gibt den "Raspberry PI 2 Model B" und Raspberry PI 2 
Model B SBC". Gibts da nen Unterschied der wichtig wäre? Was bedeutet 
das SBC?

[christian (Gast)]

Man gelangt in C++ sehr schnell an eine Stelle wo man vom eigentlichen 
Problem zu stark abstrahiert. Die Folge ist toter oder unnützer Code, 
oder noch schlimmer Ineffizienz. Da ist noch nicht einmal die Rede von 
dem Overhead den OOP mitbringt oder das Laufzeitverhalten auf 
Echtzeitsystemen.
Man muss da höllisch aufpassen wie nahe man noch die Realität noch 
abbildet.

Aber einige C++ Gurus sind hier eh von allen Zweifeln erhaben. Zu gerne 
würde ich diese Gurus mal über einen Projekt mit ARM Cortex und 
Echtzeitanwendung mit ihrem C++ Konzept schwitzen sehen ;-)

Gruß
Christian

[Gascht (Gast)]

Ach habs schon SBC = Single Board Computer

[Karl H. (kbuchegg)]

christian schrieb:
> Man gelangt in C++ sehr schnell an eine Stelle wo man vom eigentlichen
> Problem zu stark abstrahiert. Die Folge ist toter oder unnützer Code,
> oder noch schlimmer Ineffizienz.

Bla bla bla.

Wie oft ich das schon gehört habe, das kann ich nicht mehr zählen.

Selbstverständlich muss man was können, wenn man programmiert! Das ist 
in C++ auch nicht anders als in C. Aber C++ gibt mir Sprachmittel in die 
Hand, wie ich mich von der eingeforderten Selbstdisziplin der 
Programmierer lösen kann und ich von der Sprache her schon gewissen 
Dingen einen Riegel vorschieben kann. Die Alternative lautet in C: Code 
Review
Sorry. Aber da verlass ich mich lieber auf den Compiler, dass der auf 
die Einhaltung von Regeln pocht. Hab ich eine struct mit einem protected 
member, dann gibt es eben ausser der Zugriffsfunktion keine Möglichkeit 
von aussen am Prüfcode vorbei an diesen Member zu gelangen. Das ist mir 
100  mal lieber, als mich darauf zu verlassen, dass der Code Reviewer 
alle Variablen im Gedächtnis hat und auf welche Member einfach so 
zugegriffen werden kann und bei welchen man über eine Setzfunktion gehen 
muss. Oder welche Strukturmember initialisiert werden müssen und welche 
nicht. Oder ...

> Da ist noch nicht einmal die Rede von
> dem Overhead den OOP mitbringt

Erstens ist dieser Overhead nicht existent, zweitens hast du genau den 
gleichen Overhead wenn du ein OOP Designmittel in deinem C Programm 
nicht brauchst, es aber trotzdem implementierst. Brauchst du dieses 
Designmittel in C nicht, dann benutz es auch in C++ ganz einfach nicht.
Die Welt kann so einfach sein.
Brauchst du in einem System polymorphes Verhalten, dann kostet dir das 
auch in C Implementierungsresourcen. Brauchst du kein plymorphes 
Verhalten, dann gibt es auch in C++ keinen Grund virtuelle Funktionen 
vorzusehen. Keine virtuellen Funktionen -> keine vtable -> kein 
zusätzlicher Speicherverbauch -> kein Overhead. Bei allen Compilern, die 
ich bisher in den Fingern hatte, lässt sich auch die RTTI abschalten 
bzw. es wird bei Klassen ohne virtuelle Funktionen erst gar keine 
erzeugt. D.h. eine derartige Klasse kostet dir 0 Bytes (in Worten: null) 
mehr als die gleichwertige C-struct, bringt aber durch die Möglichkeit 
von public/protected/private samt inline-Zugriffsfunktionen einen 
Mehrwert. Von Konstruktor, Destruktor und dem einen oder anderen 
operator rede ich erst mal gar nicht.


> Aber einige C++ Gurus sind hier eh von allen Zweifeln erhaben. Zu gerne
> würde ich diese Gurus mal über einen Projekt mit ARM Cortex und
> Echtzeitanwendung mit ihrem C++ Konzept schwitzen sehen ;-)

Schmeiss deine C Anwendung rüber, dann unterhalten wir uns mal, wo man 
sinnvoll OOP Methoden einsetzen könnte, dann implementieren wir das und 
dann sehen wir nach was
a) schneller läuft
b) stabiler läuft
c) wartungsfreundlicher ist

Noch praktisch immer hatte dabei (speziell bei hinreichend komplexen 
Systemen) die C++ Variante die Nase vorn.
(Und bei der Gelegenheit einer derartigen Umstellung werden des öfteren 
auch schon mal Fehler gefunden)

[Karl H. (kbuchegg)]

Nur weil man in C++ OOP benutzen kann, heisst das ja nicht, dass man OOP 
immer und überall zwanghaft drüber stülpen muss.
Es macht wenig Sinn eine Sortierfunktion auf Biegen und Brechen in ein 
Klassenkorsett zu zwängen. Es macht aber allen Sinn, eine 
Sortierfunktion zb als Template auszuführen, so dass der Compiler
* dafür eine Typsichere Variante erzeugen kann
* er die Vergleichsfunktion direkt inline in den Sortiercode einbetten 
kann.
Ist die Vergleichsfunktion im Sortiercode direkt enthalten entfallen 
logischerweise auch die entsprechenden Funktionsaufrufe ( - der 
Callbackfunktkion vom C-qsort()). Keine Funktionsaufrufe -> Zeit 
gespart.
Soviel zum Thema: C++ ist langsamer.
Benötige ich aber unterschiedliche Datenstrukturen sortiert und möchte 
ich nicht, dass mir der Compiler dazu den Sortiercode dupliziert, weil 
geringer Speicherverbrauch höhere Priorität hat, dann kann ich auch das 
machen.
Genauso wie ich das auch in C machen kann.
Der Unterschied: Hier macht es mir der Compiler, dort ist der 
Programmierer gefragt (der bei jeder neuen Implementierung Gefahr läuft, 
Fehler zu machen). Im Zweifel delegiere ich lieber an den Compiler als 
an einen Programmierer.

[Daniel A. (daniel-a)]

A. K. schrieb:
> Bei Mikrocontrollern sieht das auch nicht viel anders aus. Man kann zwar
> den I/O-Bereich einer UART nicht direkt als Klasse darstellen, aber man
> kann einen UART Kanal als Klassenobjekt definieren, in dem dann ein
> Zeiger auf den in C Manier definierten IO-Bereich liegt.

Das stimmt so nicht. Man kann das Speicherlayout des IO Bereichs als 
templateklasse abbilden und eine Referenz des Templateklassentyps als 
constexpr auf den IO bereich zeigen lassen. Es lohnt sich aber nicht.

[(prx) A. K. (prx)]

Daniel A. schrieb:
> Es lohnt sich aber nicht.

Ich sehe keinen Zusammenhang zwischen meinem Text und deiner Antwort.

[nixuser (Gast)]

Lustiger Threat äh Thread oder so :-P
Man sollte sich aber eher mal um Betriebssystem relevante Dinge wie z.B. 
den Leerlaufprozeß, Zombies&Co. kümmern bevor man sich um C oder C++ 
oder oder oder streitet.
Wichtiger wäre wie implementiere ich einen Scheduler, wie baue ich eine 
Treiberschnittstelle, wie funktioniert ein Filesystem usw. usf.

[Karl H. (kbuchegg)]

nixuser schrieb:

> Wichtiger wäre wie implementiere ich einen Scheduler, wie baue ich eine
> Treiberschnittstelle, wie funktioniert ein Filesystem usw. usf.

... Memory Mangement, wie kommunizieren die Teile intern, was sind 
Basisfunktionalitäten, .... das volle Programm.

Absolut richtig.
Die Sprache ist nur ein Werkzeug. Sie entbindet einen nicht von 
Designentscheidungen.

[Hans (Gast)]

Eben...

Ein kleines Argument möchte ich noch einwerfen...

Die Leute die glauben C sei sooo viel übersichtlicher als C++ mögen mal 
bitte ISO/IEC 9899 (das ist C - nicht das was im K&R steht! Der Link zum 
letzten Draft findet sich auf der wikipedia-page von C) durchschaun und 
überlegen ob sie so nette dinge wie "generic expressions" oder den 
"_Atomic" qualifier verwendet...
Nein? Dann regt euch nicht über C++ auf. Wenn man genügend Übung hat, 
dann kommen dabei richtig schnelle Konstrukte raus mit wesentlich 
niedrigeren Arbeitsaufwand...

Habe das (mit verdammt viel Gegenwind) durchexerziert und schlussendlich 
war mein C++ Konstrukt um Größenordnungen schneller als meine C 
gegenstelle am CAN-Bus.
Wieso? Weil ich schlau verwerben konnte und damit mein Stack implizit 
multitasking fähig war.

Ich verstehe echt nicht wieso alle sich streuben C++ im embedded Bereich 
einzusetzen. Eigentlich überwiegen (jetzt wo die Compiler entsprechend 
gut sind) die Vorteile immens.

Immer wird auf den Libraries herumgehakt die an C++ dranhängen aber 
irgendwie vergisst jeder, dass auch an C auch eine Library dranhangt... 
die ist nichtmal klein! Einfach mal den Standard anschaun und staunen!

Naja,
73

[(prx) A. K. (prx)]

nixuser schrieb:
> Man sollte sich aber eher mal um Betriebssystem relevante Dinge wie z.B.
> den Leerlaufprozeß, Zombies&Co. kümmern bevor man sich um C oder C++
> oder oder oder streitet.

Ach wo. Bücher dazu gibts meterweise und jenseits der Frage von kleinen 
oder grossen Kernels wenig Grund, sich sinnlos zu fetzen. Aber hast du 
schon mal Bücher zur C vs C++ im OS-Kernel gesehen? ;-)

Ausserdem ist es weitaus einfacher, sich über C/C++ auszulassen als über 
die Vorzüge verschiedener Scheduler-Verfahren. C kennt hier jeder 
irgenwie. Von C++ hat man mindestens mal was gehört, kann also mitreden. 
Aber bei Schedulern?

[Daniel A. (daniel-a)]

A. K. schrieb:
> Daniel A. schrieb:
>> Es lohnt sich aber nicht.
>
> Ich sehe keinen Zusammenhang zwischen meinem Text und deiner Antwort.

Mir ging es darum, dass es sehr wohl möglich ist IO bereiche direkt mit 
Klassen abzubilden, und dies auch bei einer UART gehen müsste, entgegen 
deiner Aussage dass:

Daniel A. schrieb:
> A. K. schrieb:
>> Man kann zwar den I/O-Bereich einer UART nicht direkt als Klasse darstellen

Dies ist der Zusammenhang zwischen den Texten. Meine aussage, dass es 
sich nicht lohne, bezog sich auf die Möglichkeit IO bereiche direkt mit 
Klassen abzubilden.

Dazu habe ich ein Beispiel (dass man besser nicht so verwenden sollte) 
erstellt, es ist im Anhang zu finden und kann folgendermassen Kompiliert 
werden:

avr-g++ main.cpp -mmcu=atmega16 -std=c++11 -Wall -Wextra -pedantic -Werror -O1 -o main

[MaWin (Gast)]

Hans schrieb:
> Ich verstehe echt nicht wieso alle sich streuben C++ im embedded Bereich
> einzusetzen.

Man hat dort halt deutlich höhere Ansprüche an die Produktqualität wie 
im reinen Softwarebereich, wo die Bananensoftware beim Kunden reift.

Die Leute wollen nicht dieselbe miese Programmqualität wie im PC Bereich 
haben, wo Software im wesentlichen nur aus Zufall funktioniert. Solchem 
Kram vertraut man nicht das Leben der Kunden an.

Zumal sie einen gigantischen Verschleiss an Rechenleistung nach sich 
trägt.

Während bei PC Software bei Problemen jeder fragt, ob man auch die 
allerneueste Software von gestern installiert hätte, wird im embedded 
Bereich erwartet, daß Programme in jeder Version immer zuverlässig 
funktionieren und funktional vollständig sind.

So ein Zustand wie auf dem Desktop-PC, wo jede Woche neue grosse 
Sicherheitslöcher gestopft werden müssen, sind im embedded Bereich 
eigentlich untragbar, aber wenn man Kinder wie dich an die 
Sofwtareentwicklung in dem Bereich ranlässt...

http://www.autobild.de/artikel/hacker-steuern-jeep-cherokee-fern-5875286.html

[leser (Gast)]

MaWin schrieb:
> Die Leute wollen nicht dieselbe miese Programmqualität wie im PC Bereich
> haben, wo Software im wesentlichen nur aus Zufall funktioniert. Solchem
> Kram vertraut man nicht das Leben der Kunden an.

^^ YMMD

Sehr geil, MaWin! Komplett schwachsinnig, aber zutiefst unterhaltsam.
Mehr davon!

[nixuser (Gast)]

A. K. schrieb:
> nixuser schrieb:
>> Man sollte sich aber eher mal um Betriebssystem relevante Dinge wie z.B.
>> den Leerlaufprozeß, Zombies&Co. kümmern bevor man sich um C oder C++
>> oder oder oder streitet.
>
> Ach wo. Bücher dazu gibts meterweise und jenseits der Frage von kleinen
> oder grossen Kernels wenig Grund, sich sinnlos zu fetzen. Aber hast du
> schon mal Bücher zur C vs C++ im OS-Kernel gesehen? ;-)
>
> Ausserdem ist es weitaus einfacher, sich über C/C++ auszulassen als über
> die Vorzüge verschiedener Scheduler-Verfahren. C kennt hier jeder
> irgenwie. Von C++ hat man mindestens mal was gehört, kann also mitreden.
> Aber bei Schedulern?

Nein in Büchern zu OS steht halt drin wie man was macht um ein 
Betriebssystem zum laufen zu bringen.
Das sind Grundlagen im Design wie KarlHeinz ja schon treffend erwähnt 
hat.
Ob ich nun einen Mikrokernel mit RoundRobin und drei Prioritäten baue 
und dann darauf je nach Priorität den Treiber für XYZ implementiere oder 
alles in einen dicken Kernel packe bleibt mir überlassen.
Genauso wie die Programmiersprache, ob ich das direkt als Opcode 
schreibe, oder B oder C oder D oder Eiffel oder Z## bleibt sich gleich.
Man könnte jetzt mal einfach hingehen und eine OS-Sprache entwickeln mit 
Ruby hat's ja beim Web auch geklappt.
Also ran :-P

[Rolf Magnus (Gast)]

leser schrieb:
> Komplett schwachsinnig, aber zutiefst unterhaltsam.

Da muß ich leider recht geben. Das trifft's.

[Karl Käfer (Gast)]

Hallo christian,

christian schrieb:
> Man gelangt in C++ sehr schnell an eine Stelle wo man vom eigentlichen
> Problem zu stark abstrahiert. Die Folge ist toter oder unnützer Code,
> oder noch schlimmer Ineffizienz.

Das kann schlechten Programmierern immer passieren. Nicht nur in C++, 
sondern auch in C, Python, Perl, Java und allen anderen Sprachen, von 
denen ich etwas verstehe.

Allerdings sind "Effizienz" und "Ineffizienz" letztlich nur ökonomische 
Begriffe. In der Praxis geht es dabei gar nicht darum, eine bestimmte 
Funktion mit möglichst wenig Speicher und Instruktionen umzusetzen. Es 
nutzt Dir nämlich gar nichts, wenn Ressourcen ungenutzt bleiben, und es 
ist ökonomisch betrachtet völliger Unsinn, zehn Cent Ersparnins beim 
Kauf eines Mikrocontrollers gegen eine Verdoppelung des 
Entwicklungsaufwandes einzutauschen. Dabei spielen die geplante 
Seriengröße und natürlich auch der geplante Lebenszyklus die maßgebliche 
Rolle -- Faustregel: je weniger Stückzahl geplant sind, desto wichtiger 
wird es, den Entwicklungsaufwand zu minimieren.

Genau da kommt dann die Objektorientierung ins Spiel -- und zwar ganz 
egal, ob in C oder in C++. Es ist ja nicht so, als könne man in C nicht 
auch objektorientierte Features nutzen. Und die meisten Möglichkeiten 
der Objektorientierung sind letztlich nichts anderes als das, was schon 
unter prozeduralen Sprachen als gutes Softwaredesign und guter 
Programmierstil galt und gilt, mit neuen Sprachmitteln zu unterstützen.

Es gibt da ein schönes Buch für fortgeschrittene C-Embedded-Entwickler 
von Elecia White namens "Making Embedded Systems". Die Autorin 
beschreibt dort in einem großen Teil des Buches vor allem Techniken, die 
nur dazu dienen, bewährte OO-Features mit den Mitteln von C abzubilden. 
;-)

> Da ist noch nicht einmal die Rede von dem Overhead den OOP mitbringt
> oder das Laufzeitverhalten auf Echtzeitsystemen.

Sauber designte OOP bringt keinen Overhead mit. Ich habe diese 
Behauptung anhand realen C- und C++-Codes für AVRs in einem anderen 
Thread überprüft und bin dabei zu dem Ergebnis gekommen, daß funktional 
äquivalenter Code in C und C++ am Ende meistens haargenau gleich große 
(und meistens auch funktional gleiche) Kompilate erzeugt. Es gibt nur 
eine einzige Ausnahme, die aber offenbar am Optimizer des verwendeten 
GCC-Compilers liegt -- und die mit den in [1] beschriebenen Techniken 
leicht zu umgehen gewesen wäre. Tatsächlich war der mit C und C++ 
erzeugte Code oft sogar genau dasselbe, den auch ein erfahrener 
Assembler-Entwickler geschrieben hätte.

> Man muss da höllisch aufpassen wie nahe man noch die Realität noch
> abbildet.

Natürlich muß man sein Werkzeug beherrschen. Das ist auch in C, 
Assembler und allen mir bekannten Sprachen und Paradigmen nicht anders.

> Aber einige C++ Gurus sind hier eh von allen Zweifeln erhaben. Zu gerne
> würde ich diese Gurus mal über einen Projekt mit ARM Cortex und
> Echtzeitanwendung mit ihrem C++ Konzept schwitzen sehen ;-)

Dank OOP schwitzen die dabei vermutlich weniger als Du. ;-)

Liebe Grüße,
Karl

[MaWin (Gast)]

Karl H. schrieb:
> dann unterhalten wir uns mal, wo man sinnvoll OOP Methoden einsetzen
> könnte, dann implementieren wir das und dann sehen wir nach was
> a) schneller läuft
> b) stabiler läuft
> c) wartungsfreundlicher ist
>
> Noch praktisch immer hatte dabei (speziell bei hinreichend komplexen
> Systemen) die C++ Variante die Nase vorn.

Gelogen.

Ich weiss das, weil gerade eine Firma an genau dem (ein existierendes 
100000-Zeilen C Programm funktionsidentisch in C++ umzusetzen) zu Grunde 
geht.

Versprochen wurde 20-fache Performance, man ist nach 2 gescheiterten 
Anläufen gerade seit 5 Jahren beim dritten und hat 0.5 erreicht.

Das ist ja schon gut, das EXE und der Speicherbedarf ist 10 mal so 
gross.

Aktuell scheitert gerade ein lower_bound welches ein Element in 
std:vector nach einem std:sort nicht findet. Scheiss boost template.

Also erzähl nicht so einen vom Himmel heruntergelogenen Quatsch, ich 
WEISS das er falsch ist (deine Ausrede kenne ich auch schon: Man 
behauptet dann es läge am schlechten Programmierer. Ich bin's nicht, 
insofern trifft es mich nicht, er wird so gut wie du sein.)

[Karl Käfer (Gast)]

Karl H. schrieb:
> Sorry. Aber da verlass ich mich lieber auf den Compiler, dass der auf
> die Einhaltung von Regeln pocht. Hab ich eine struct mit einem protected
> member, dann gibt es eben ausser der Zugriffsfunktion keine Möglichkeit
> von aussen am Prüfcode vorbei an diesen Member zu gelangen.

Du kannst Dir sicher nicht vorstellen, wie ungerne ich Dir widerspreche, 
aber leider gibt es diese Möglichkeit. Private und Protected werden nur 
vom Compiler durchgesetzt und betreffen nur den Namen der betreffenden 
Member-Variablen oder -Methode; mit Zeigern und etwas bösem Willen kann 
man aber auch zur Laufzeit an diese herankommen:

#include <iostream>
using namespace std;

class Dings {
private:
    int d_;
public:
    Dings() { d_ = 0; }
    int get() { return d_; }
};

int main() {
    Dings t;
    int* ptr = (int*)&t;
    *ptr = 10;
    cout << t.get() << endl;
    return 0;
}

Dieser Code kompiliert mit g++/4.9.1 und clang++/3.5.0 mit "-Wall", 
"-Wextra" und "-Wpedantic" ohne Fehler und Warnungen...

> Schmeiss deine C Anwendung rüber, dann unterhalten wir uns mal, wo man
> sinnvoll OOP Methoden einsetzen könnte, dann implementieren wir das und
> dann sehen wir nach was
> a) schneller läuft
> b) stabiler läuft
> c) wartungsfreundlicher ist

Das wollte ich auch gerade vorschlagen, wenn ich nicht morgen für eine 
Woche in meinen verdienten Segelurlaub fahren würde. Viel Vergnügen!

Liebe Grüße,
Karl

[Rolf M. (rmagnus)]

Ich weiß ja nicht, ob ich lachen oder heulen soll, wenn ich mir hier so 
anschaue, was sich die Leute alles zusammenphantasieren, warum C++ 
angeblich nicht für Kernel-Programmierung geeignet sein soll.
Wenn ich mir die Argumente (mit meinen Worten nachformuliert) so 
anhöhre:

"Register lassen sich nicht polymorph memory-mappen, also nehm ich 
lieber eine Sprache, bei der ich gar nicht erst auf die blöde Idee 
kommen kann."

"Ich hab schon mal irgendwo ein instabiles GUI-Programm gesehen, und das 
war bestimmt C++, also kann man in C++ nicht wie in C stabilen Code 
schreiben."

"Es gibt schlechte Programmierer, die C++ nutzen, also muß die Sprache 
schlecht sein. In C gibt es nur gute Programmierer, also muß die Sprache 
gut sein."

"C++ hat <obskures Feature X>, und da man ja in C++ im Gegensatz zu C 
sämtliche Features der Sprache zwingend an jeder Stelle im Programm 
nutzen muss, lass ich's lieber, da mir <obskures Feature X> nicht 
gefällt."

[Stefan R. (srand)]

christian schrieb:
>> Ich verrate dir ein Geheimnis: das garantieren Strukturen auch nicht.
>
> Doch, genau das ist der Fall. Mit Ausnahme von Speicherausrichtung, wenn
> Datentypen z.b. auf einer ungeraden Adresse folgen. Aber auch das ist
> hier Compiler-und Prozessor abhängig und hat nichts mit der Sprache C zu
> tun.

Dummfug.

Abgesehen davon, daß du einfach mal so Speicherausrichtung ausklammerst, 
garantiert dir die C-Struktur zwar die Reihenfolge der Elemente, aber da 
kann beliebig Padding dazwischen liegen.

Du kannst in C Hardwareregister etc. gar nicht standardkonform und 
portabel beschreiben. Das geht nur durch Annahmen über den Compiler oder 
halt durch compilerspezifische Erweiterungen.

Andere Sprachen können das. Ada zum Beispiel erlaubt dir, einen Record 
(Struktur) überall bitgenau richtig zu deklarieren.

[Rolf M. (rmagnus)]

Karl Käfer schrieb:
> Private und Protected werden nur vom Compiler durchgesetzt und betreffen
> nur den Namen der betreffenden Member-Variablen oder -Methode; mit Zeigern
> und etwas bösem Willen kann man aber auch zur Laufzeit an diese
> herankommen:

Das ist auch so ein Irrglaube, der sich hartnäckig hält: Die Features 
von C++ dienen dazu, daß man so progrmamieren kann, daß man sich nicht 
versehentlich in den Fuß schießt. Sie sind nicht dafür gedacht, 
gezielte Sabotage zu verhindern. Wer sich unbedingt in den Fuß schießen 
will, kann das auch in C++ tun.

[Stefan R. (srand)]

Karl H. schrieb:
> Du zeigst eigentlich nur, dass du nicht viel Ahnung davon hast, wie C++
> im inneren funktioniert und nur das nachplapperst, was dir dein 'Guru'
> Linus Torvalds vorplappert.

Jetzt wirst du unsachlich!

Torvalds hat im wesentlichen ein Argument für C und gegen C++, das sehr 
gut nachvollziehbar ist: in C ist (abgesehen von wilden 
Pointer-Cast-Orgien) der relevante Kontext stets sehr lokal zu 
überschauen.

In umfangreichen Klassenhierarchien, mit Exceptions, Operatorüberladung 
und gar noch mit RTTI mußt du potentiell den gesamten Sourcecode 
überschauen, um zu wissen, was die eine Zeile auf deinem Monitor gerade 
wirklich bedeutet.

[Stefan R. (srand)]

christian schrieb:
> Ja genau. Kernel Entwickler auf der ganzen Welt irren hier und
> programmieren nur aus Unkenntnis heraus in C. Aber egal.

Nein, das tun sie, weil sie an Kerneln arbeiten, deren Ursprung im 
Urschleim der Computergeschichte liegt, wo C++ nicht oder nicht 
brauchbar verfügbar war.

Linux, BSD, Mac OS, Solaris, alle setzen im Prinzip auf dem alten 
UNIX-COde auf. Natürlich macht man den nicht einfach neu.

Windows NT hat Anleihen von VMS gehabt.

Undsoweiter undsofort.

Einige moderne Kernel (die aber halt Forschungsprojekte sind) werden 
auch durchaus in modernenen Sprachen entwickelt.

[Rolf M. (rmagnus)]

Stefan R. schrieb:
> In umfangreichen Klassenhierarchien, mit Exceptions, Operatorüberladung
> und gar noch mit RTTI mußt du potentiell den gesamten Sourcecode
> überschauen, um zu wissen, was die eine Zeile auf deinem Monitor gerade
> wirklich bedeutet.

Wo ist denn der Unterschied, ob ich in C++ einen irgendwo anders 
definierten Operator oder in C eine irgendwo anders definierte Funktion 
aufrufe? Wo ist der Unterschied, ob ich eine virtuelle Memberfunktion 
eines per Factory erzeugten Objekts über die Basisklasse oder eine 
C-Funktion, die irgendwann mal als Callback registriert wurde über einen 
Zeiger aufrufe?

[Stefan R. (srand)]

christian schrieb:
> Mit C++ Klassen ist das nun einmal nicht immer möglich,
> wenn z.b. virtuelle Funktionen im Spiel sind.

Dann laß sie doch weg!

Du kannst C++-Klassen wie structs verwenden. Nur mit paar mehr Features. 
Konstruktoren, Vererbung etc. pp.
Alles möglich!

Und bis dorthin hast du im Speicherlayout genau null Unterschied zur C 
struct.

Wenn du dann virtuelle Vererbung oder virtuelle Funktionen einsetzst, 
dann doch nicht zum Spaß, sondern weil sie dir helfen. Und wenn sie dich 
mehr stören, als sie dir helfen, z.B. wegen des Speicherlayouts, super, 
keiner zwingt dich!

[nixuser (Gast)]

Hmmm,
welcher Name hat nochmal der Fischhändler bei Asterix&Obelix ?
Die ham sich ja immer einfach gekloppt ohne Sinn ...
Aber gut troll ich noch 'ne Runde mit:
1. Geht es bei Betriebssystemen eben um den "Betrieb" der einfacher als 
direktes Hacken, da genormt, sein soll(muß)
2. Der Overhead bei OOP hängt vom Compiler ab, da gibt's auch welche die 
aus Z## erstmal C machen was keiner lesen kann bevor dann über Assembler 
der Opcode generiert wird
3. Ist OOP wegen der Vererbung zukunftssicherer als irgendein Indi-Code 
der nicht kommentiert ist
4. Jeder der Klassennamen und Setter/Getter bzw. extra Methoden mit i1, 
i2, i3 benennt gehört XYZ ...
5. Kapselung hat den Vorteil das man keine wichtigen privaten Variablen 
einfach so zerschießen kann
6. Nehmt JAVA da kommen NULLPOINTEREXEPTIONS auf der Console und crashen 
nicht den Rechner
7. Exceptions sind mächtiger als die C-Variante(n)
So und nun könnt Ihr weitertrollen, ich mach mir 'nen Fisch :-P

[Hans-Georg L. (h-g-l)]

Mal wieder alle Labertanten gemeinsam in einem Thread versammelt.
Da darf ich natürlich nicht fehlen ;)

C++ wird schon seit längerer Zeit in Maschinensteuerungen, 
Prüfeinrichtungen, Produktionssteuerungen usw. eingestetzt. Und da sind 
auf der obersten Ebene meist PCs im Einsatz und da tut sich kein Mensch 
mehr Assembler an.

Aber zurück zur ursprünglichen Frage OS auf einem X86/64 System in C++.

Wenn du nur die oberste Schicht als OS verstehst kannst du es problemlos 
in C++ entwickeln. Ansonsten wirst du sinnvoller Weise auch C und noch 
weiter unten auch Assembler benutzen.

[Kenner (Gast)]

Ich habe hier https://de.wikipedia.org/wiki/Lines_of_Code gelesen, dass 
ein Betriebssystem Millionen Zeilen von Programmcode hat. Deswegen 
glaube ich alleine kann man das nich schreiben.

[Hans-Georg L. (h-g-l)]

MaWin schrieb:
> Karl H. schrieb:
>> dann unterhalten wir uns mal, wo man sinnvoll OOP Methoden einsetzen
>> könnte, dann implementieren wir das und dann sehen wir nach was
>> a) schneller läuft
>> b) stabiler läuft
>> c) wartungsfreundlicher ist
>>
>> Noch praktisch immer hatte dabei (speziell bei hinreichend komplexen
>> Systemen) die C++ Variante die Nase vorn.
>
> Gelogen.
>
> Ich weiss das, weil gerade eine Firma an genau dem (ein existierendes
> 100000-Zeilen C Programm funktionsidentisch in C++ umzusetzen) zu Grunde
> geht.
>

das liegt aber nich an C++ sonderm am Einkauf !

Entweder der hat den billigsten Abieter oder SAP,IBM,Telekom genommen ;)

[(prx) A. K. (prx)]

Stefan R. schrieb:
> Linux, BSD, Mac OS, Solaris, alle setzen im Prinzip auf dem alten
> UNIX-COde auf. Natürlich macht man den nicht einfach neu.

Linux nutzt den gleichen API, aber der Code stammt nicht von Unix.

> Windows NT hat Anleihen von VMS gehabt.

Im Konzept, nicht im Code. Ich weiss nicht worin VMS ursprünglich 
geschrieben wurde, aber es war garantiert kein C. Möglicherweise BLISS.

[Frank K. (fchk)]

christian schrieb:
> Ja genau. Kernel Entwickler auf der ganzen Welt irren hier und
> programmieren nur aus Unkenntnis heraus in C. Aber egal.

Nicht alle. Schau mal her...

https://developer.apple.com/library/mac/documentation/Darwin/Conceptual/KEXTConcept/KEXTConceptIOKit/iokit_tutorial.html

Dieses Zeugs ist millionenfach im Einsatz. Und es funktioniert ganz 
passabel.

Es geht also, wenn man will.

fchk

[Karl Käfer (Gast)]

Hallo MaWin,

MaWin schrieb:
> Aktuell scheitert gerade ein lower_bound welches ein Element in
> std:vector nach einem std:sort nicht findet. Scheiss boost template.

Tja, leider gehören std::lower_bound, std::vector und std::sort allesamt 
nicht zu Boost, sondern zur STL. Nice try, though.

Liebe Grüße,
Karl

[Karl Käfer (Gast)]

Hallo Rolf,

Rolf M. schrieb:
> Das ist auch so ein Irrglaube, der sich hartnäckig hält: Die Features
> von C++ dienen dazu, daß man so progrmamieren kann, daß man sich nicht
> versehentlich in den Fuß schießt. Sie sind nicht dafür gedacht,
> gezielte Sabotage zu verhindern.


> Wer sich unbedingt in den Fuß schießen will, kann das auch in C++ tun.

...und in jeder anderen Sprache auch. Zu dieser Diskussion hier trägt 
[1] dann auch das Folgende bei:

C:
- You shoot yourself in the foot.

C++:
- You accidently create a dozen instances of yourself and shoot them all 
in the foot. Providing emergency medical assistance is impossible since 
you can't tell which are bitwise copies and which are just pointing at 
others and saying "That's me, over there."

Assembly Language:
- You crash the OS and overwrite the root disk. The system administrator
  arrives and shoots you in the foot. After a moment of contemplation,
  the administrator shoots himself in the foot and then hops around the
  room rabidly shooting at everyone in sight.
or
- You try to shoot yourself in the foot only to discover you must first
  reinvent the gun, the bullet, and your foot.
or
- The bullet travels to your foot instantly, but it took you three weeks
  to load the round and aim the gun.

Da ich mir mit jeder dieser Sprachen schon mehrmals in den Fuß und 
andere mehr oder weniger wertvolle Körperteile geschossen habe, weiß 
ich: da ist durchaus was Wahres dran.

Liebe Grüße,
Karl

[1] http://www-users.cs.york.ac.uk/susan/joke/foot.htm

[Karl Käfer (Gast)]

Hallo Stefan,

Stefan R. schrieb:
> In umfangreichen Klassenhierarchien, mit Exceptions, Operatorüberladung
> und gar noch mit RTTI mußt du potentiell den gesamten Sourcecode
> überschauen, um zu wissen, was die eine Zeile auf deinem Monitor gerade
> wirklich bedeutet.

Das stimmt. Aber wer so etwas in Kernelcode einsetzt, muß mit dem 
Klammerbeutel gepudert sein -- außer beim Überladen von Operatoren 
vielleicht, aber da ist der Kontext ja auch eher übersichtlich.

Liebe Grüße,
Karl

[Karl H. (kbuchegg)]

MaWin schrieb:

> Also erzähl nicht so einen vom Himmel heruntergelogenen Quatsch, ich
> WEISS das er falsch ist


MaWin
Mit Verlaub. In Sachen Hardware bist du für mich eine unumstrittene 
Autorität.
Aber in Sachen Software nehm ich dich nicht ernst.

[Karl H. (kbuchegg)]

Karl Käfer schrieb:

> Du kannst Dir sicher nicht vorstellen, wie ungerne ich Dir widerspreche,
> aber leider gibt es diese Möglichkeit. Private und Protected werden nur
> vom Compiler durchgesetzt und betreffen nur den Namen der betreffenden
> Member-Variablen oder -Methode; mit Zeigern und etwas bösem Willen kann
> man aber auch zur Laufzeit an diese herankommen:

So kompliziert brauchst du gar nicht vorgehen :-)
Mit etwas Präprozessor Magie ist es kein Problem das alles auszuhebeln

#define protected public
#define private public

#include "myClass.h"
...

Klar kann ich das aushebeln, aber ich muss dafür Aufwand treiben. 
Jedenfalls mehr Aufwand, als in C ganz einfach auf den Member 
zuzugreifen. Jede Sicherung kann man irgendwie umgehen. Aber es gibt 
zumindest eine Sicherung.

Und das fällt beim Code Review (den es selbstverständlich auch weiter 
gibt) auf.

> Woche in meinen verdienten Segelurlaub fahren würde. Viel Vergnügen!

Mast und Schotbruch

[Karl H. (kbuchegg)]

Stefan R. schrieb:
> Karl H. schrieb:
>> Du zeigst eigentlich nur, dass du nicht viel Ahnung davon hast, wie C++
>> im inneren funktioniert und nur das nachplapperst, was dir dein 'Guru'
>> Linus Torvalds vorplappert.
>
> Jetzt wirst du unsachlich!
>
> Torvalds hat im wesentlichen ein Argument für C und gegen C++, das sehr
> gut nachvollziehbar ist: in C ist (abgesehen von wilden
> Pointer-Cast-Orgien) der relevante Kontext stets sehr lokal zu
> überschauen.
>
> In umfangreichen Klassenhierarchien, mit Exceptions, Operatorüberladung
> und gar noch mit RTTI mußt du potentiell den gesamten Sourcecode
> überschauen, um zu wissen, was die eine Zeile auf deinem Monitor gerade
> wirklich bedeutet.

Ich denke, die wenigsten C++ Programmierer hätten ein Problem damit, 
wenn Linus genau diese Sprach Features in der Kernel-Entwicklung 
verbieten würde. Eventuell mit Ausnahmen für Operatoren in Container 
Klassen.

Die C++ Community ist sich mehrheitlich sowieso darüber einig, dass man 
sich zb mit Operator-Overloading ganz schnell selbst Fallen bauen kann. 
Speziell mit Cast-Operatoren ermöglicht man recht schnell dem Compiler 
Möglichkeiten, wie er eigentlich unsinnigen Code doch noch hindrehen 
kann.
Exceptions sind auch so ein 2-schneidiges Schwert, weil sie des öfteren 
nicht im Sinne des Erfinders benutzt werden. RTTI auszunutzen: ok, 
manchmal ist ein dynamic_cast eine feine Sache, aber in den meisten 
Fällen zeigt er schlechtes Design an - wie man in C++ überhaupt sagen 
muss, dass ein Cast meistens eine Problemstelle anzeigt. Natürlich alles 
mit Ausnahmen.

Alles in allem ist Torvalds Argumentation für die meisten, die C++ gut 
beherrschen nicht wirklich nachvollziehbar. Denn in einem gut designten 
System ist es genau so, dass es in C++ viel simpler ist, den Kontext 
lokal zu halten.

[Hans (Gast)]

MaWin schrieb:
> Hans schrieb:
>> Ich verstehe echt nicht wieso alle sich streuben C++ im embedded Bereich
>> einzusetzen.
>
> Man hat dort halt deutlich höhere Ansprüche an die Produktqualität wie
> im reinen Softwarebereich, wo die Bananensoftware beim Kunden reift.
>
> Die Leute wollen nicht dieselbe miese Programmqualität wie im PC Bereich
> haben, wo Software im wesentlichen nur aus Zufall funktioniert. Solchem
> Kram vertraut man nicht das Leben der Kunden an.
>
> Zumal sie einen gigantischen Verschleiss an Rechenleistung nach sich
> trägt.
>
> Während bei PC Software bei Problemen jeder fragt, ob man auch die
> allerneueste Software von gestern installiert hätte, wird im embedded
> Bereich erwartet, daß Programme in jeder Version immer zuverlässig
> funktionieren und funktional vollständig sind.
>
> So ein Zustand wie auf dem Desktop-PC, wo jede Woche neue grosse
> Sicherheitslöcher gestopft werden müssen, sind im embedded Bereich
> eigentlich untragbar, aber wenn man Kinder wie dich an die
> Sofwtareentwicklung in dem Bereich ranlässt...
>
> http://www.autobild.de/artikel/hacker-steuern-jeep-cherokee-fern-5875286.html


Ähm.... und du glaubst tatsächlich, dass außschließlich OOP oder C++ 
schuld daran sind???

Wenn C soviel besser für embedded/automotiv/... ist, warum gibt's dann 
sowas wie MISRA?

Lücken im embedded Bereich sind IMHO wesentlich weiter verbreitet als im 
PC Bereich... der Unterschied ist einfach, dass es am PC Leute gibt die 
sie suchen und die Anzahl der Systeme gewaltig größer ist.

Alleine zu sagen irgendwelche string-klassen seien so langsam..... dafür 
machen sie bounds-checks udgl. implizit mit!!!

Solche impliziten checks machen so sachen wie Hearbleed (im übrigen 
weder oop noch C++) einfach wesentlich unwarscheinlicher!

Meiner Einschätzung nach ist JEDES System das man irgendwie erreichen 
kann grundsätzlich missbrauchbar.

Sei es die Insulinpume auf der Backhat, der Jeep jetzt oder auch das 
Handy irgendwelcher Politiker.

Je komplexer das System wird, desto eher ist was faul.

OOP ist einfach ein wunderbares Mittel hier etwas mehr Übersicht zu 
schaffen.

C++ dagegen ein gutes Werkzeug wenn man neben OOP auch hardware-nahe 
Prozeduralen Code benötigt (jaja, man kann ja auch eine Memberfunktion 
als Handler verwenden... aber die <10 Zeilen Code habe ich doch noch 
lieber prozedural und in einer eigenen file...).

Das Problem ist einfach, dass 99.9% der Leute die motzen weder C (2011) 
noch C++(2014) richtig beherrschen geschweige denn den Funktionsumfang 
auch kennen.

Ich mein wieso schreiben die Meisten in C brav Module und haben ALLE 
Prototypen im Header-File... Das wiederspricht total dem modularen 
Gedanken! Vergleichbar wäre in C++ alle Member public zu definieren... 
tut keiner weils offensichtlich ist was daran nicht optimial ist. In C 
... naja ... es lebe der ungewollte side-effect weil mal wieder wer eine 
"interne" funktion verwendet!

Das void-ptr herumgewerfe weil es keine vererbbare interfaces gibt ist 
übrigends auch nicht besser!


73

[Karl H. (kbuchegg)]

Karl Käfer schrieb:
> Hallo MaWin,
>
> MaWin schrieb:
>> Aktuell scheitert gerade ein lower_bound welches ein Element in
>> std:vector nach einem std:sort nicht findet. Scheiss boost template.
>
> Tja, leider gehören std::lower_bound, std::vector und std::sort allesamt
> nicht zu Boost, sondern zur STL.

Abgesehen davon kann ich mir nicht vorstellen, dass es irgendeine STL 
gibt, bei der ein std::lower_bound nicht funktioniert. Das Zeug ist 
Millionenfach getestet.

Erinnert mich an einen meiner Vorgänger im aktuellen Job. Der meinte 
auch, er müsse die halbe Runtime und das Betriebssystem umschreiben 
(CMX) weil das alles fehlerhaft wäre. Wenn man dann in seinen Code 
reinschaut (C-Code) finden sich haarsträubende Fehler auf C 
Basis-Niveau.

Du hast es schon schön ausgedrückt.
C++ ist nicht dafür gedacht, das sich in den Fuss zu schiessen komplett 
zu verhindern. Aber es erschwert das unabsichtliche in den Fuss 
schiessen.

[Klaus W. (mfgkw)]

Rolf M. schrieb:
> Wo ist der Unterschied, ob ich eine virtuelle Memberfunktion
> eines per Factory erzeugten Objekts über die Basisklasse oder eine
> C-Funktion, die irgendwann mal als Callback registriert wurde über einen
> Zeiger aufrufe?

In C wirst du dabei bei vielen Programierern früher oder später irgendwo 
einen cast nach void* sehen. Der ist natürlich sehr übersichtlich :-)

nixuser schrieb:
> welcher Name hat nochmal der Fischhändler bei Asterix&Obelix ?

War das nicht Verleihnix?

[Klaus W. (mfgkw)]

Karl H. schrieb:
> C++ ist nicht dafür gedacht, das sich in den Fuss zu schiessen komplett
> zu verhindern. Aber es erschwert das unabsichtliche in den Fuss
> schiessen.

Bietet aber auch neue, elegante Möglichkeiten dafür!

[(prx) A. K. (prx)]

Karl H. schrieb:
> Erinnert mich an einen meiner Vorgänger im aktuellen Job.

Wenn man auf Arbeit anderer Leute aufsetzt, dann ärgern einen die Fehler 
darin viel mehr, als die "völlig natürlichen" eigenen Fehler. Der "alles 
muss man selber machen" Effekt. Ist bekanntlich nicht auf Software 
beschränkt, aber warum sollte es bei Software anders sein.

[Hans-Georg L. (h-g-l)]

Karl H. schrieb:
> MaWin
> Mit Verlaub. In Sachen Hardware bist du für mich eine unumstrittene
> Autorität.
> Aber in Sachen Software nehm ich dich nicht ernst.

Dem kann ich nur zustimmen.

Karl H. schrieb:
> Karl Käfer schrieb:
>> Hallo MaWin,
>>
>> MaWin schrieb:
>>> Aktuell scheitert gerade ein lower_bound welches ein Element in
>>> std:vector nach einem std:sort nicht findet. Scheiss boost template.
>>
>> Tja, leider gehören std::lower_bound, std::vector und std::sort allesamt
>> nicht zu Boost, sondern zur STL.
>
> Abgesehen davon kann ich mir nicht vorstellen, dass es irgendeine STL
> gibt, bei der ein std::lower_bound nicht funktioniert. Das Zeug ist
> Millionenfach getestet.
>

Du kannst den Vergleichsoperator überladen und dabei Mist bauen, dafür 
kann aber die STL nichts.

Zitat aus cppreference.com:
bool cmp(const Type1 &a, const Type2 &b);
The signature does not need to have const &, but the function object 
must not modify the objects passed to it.

[Karl H. (kbuchegg)]

A. K. schrieb:
> Karl H. schrieb:
>> Erinnert mich an einen meiner Vorgänger im aktuellen Job.
>
> Wenn man auf Arbeit anderer Leute aufsetzt, dann ärgern einen die Fehler
> darin viel mehr, als die "völlig natürlichen" eigenen Fehler. Der "alles
> muss man selber machen" Effekt. Ist bekanntlich nicht auf Software
> beschränkt, aber warum sollte es bei Software anders sein.

Das ist schon viel Wahres dabei.
Allerdings hab ich in diesem Projekt (noch) das Glück, dass ich keine 
Erweiterungen machen muss, sondern das Ding einfach nur lauffähig 
gemacht werden soll :-)
Der bewusste Vorgänger hat das Handtuch geschmissen.
Man könnte auch sagen: Er hat sich selbst so lange bewusst in die Ecke 
gestellt (programmiert), bis er den Ausgang nicht mehr gefunden hat.
Kommt bei 'Neulingen' (er hat pikanterweise Informatik an einer HTL 
unterrichtet) gar nicht so selten vor, dass sie sich komplett verlaufen 
ohne es zu merken. Dafür hat jede Funktion einen schönen 7-zeiligen 
Kommentar-Header. Der ist zwar nicht ausgefüllt und im wesentlichen 
steht da nur der Name der Funktion drinn - aber keiner kann sagen, da 
wäre ja nichts dokumentiert :-)
Und ehe das kommt: Nein, ich schreib das Teil nicht in C++ um. Würde 
nichts bringen, der ganze Ansatz ist ein wenig verkorkst. Wenn schon, 
dann schreib ich das neu. Aber diese Entscheidung fällt erst nächstes 
Jahr. Bis dahin werden Bugs gefixt und das Teil am laufen gehalten.

[MaWin (Gast)]

Karl H. schrieb:
> Aber in Sachen Software nehm ich dich nicht ernst.

Du möchtest also weiter lieber "deine Wahrheit" hier behaupten in dem du 
dir nicht genehme Fakten "nicht ernst" nimmst.

Klar, so sind die Überheblichen in der betroffenen Firma auch. Man hat 
aber inzwischen von Auftraggebers Seiten die Zahlungen eingestellt. 
Sollten die noch mal was funktionierendes liefern, dann ist der Weg 
dahin auf eigene Kosten.


Karl H. schrieb:
> Abgesehen davon kann ich mir nicht vorstellen, dass es irgendeine STL
> gibt, bei der ein std::lower_bound nicht funktioniert. Das Zeug ist
> Millionenfach getestet.

lower_boudn funktioniert auch wohl, aber sort sortiert so, daß 
lower_bound nicht findet, an derselben Stelle steht ein anderer Eintrag 
(als auf dem funktionierenden System) obwohl es insgesamt gleich viele 
Einträge sind und das Ergebnis von sort in beiden Fällen sortiert ist.
Bleibt eigentlich nur die Möglichkeit, daß ein Eintrag fehlt und einer 
verdoppelt wurde, aber das ist noch zu ergründen.


Hans-Georg L. schrieb:
> das liegt aber nich an C++ sonderm am Einkauf !
> Entweder der hat den billigsten Abieter oder SAP,IBM,Telekom genommen ;)

War klar, daß so ein Idiotenspruch kommt. Denn es darf nicht sein, was 
man nicht wahrhaben will, und Hans-Georg ist sowieso viel klüger als der 
Rest der Welt.


Karl Käfer schrieb:
> Tja, leider gehören std::lower_bound, std::vector und std::sort allesamt
> nicht zu Boost

Steht ja auch std davor und es sind keine templates. Aber das template 
der zu sortierenden Daten kam von boost. Ob Karl Heiz oder Karl Käfer, 
so sind sie, die Überheblichen Softwerker, glauben nur an ihre 
Scheuklappensicht und ignorieren die Wahrheit. Leider zieht diese 
Überheblichkeit eine ganze Branche in den Abgrund. Es werden Versprechen 
gemacht "geht viel schneller, ist damit billiger als früher" und die 
Realität ist, daß Softwareerstellung viel langsamer geht und viel teurer 
wird. Und wenn nicht schneller und billiger, so soll das Ergebnis besser 
sein, scrum sei Dank. Das Ergebnis sieht man allerorten, z.B. bei eBay, 
jede Woche anders, jede Woche andere Fehler, vorne hübsch (oder auch 
nicht, jedenfalls optisch anders), hinten nicht angefasst und nicht 
zusammenpassend. Noch immer (seit Jahren) kann die App nicht dasselbe 
wie das Web-Frontend, weil die Kinder der Softwareprogrammierung sich 
lieber woanders vergnügen. Und sage keiner, eBay würde nicht genug Geld 
in die Entwicklung stecken oder hätte halt nur dumme Softwerker. Nein, 
bei eBay sieht man klar sie schlimmen Folgen von scrum. Und wenn ich 
heute ein Lastenheft einer (GUI-) Software von vor 20 Jahren auf den 
Tisch lege, kommen Angebote die 25 mal teurer sein sollen und 25 mal 
länger in der Implementierung brauchen. Ja, die Softwarebranche, 
"verbraucht" Jahr für Jahr mehr Rechenleistung und Speicher, so daß der 
Schrott genau so schnell läuft wie früher, nur fehlerhafter ist.

[Kaj (Gast)]

Klaus W. schrieb:
> nixuser schrieb:
>> welcher Name hat nochmal der Fischhändler bei Asterix&Obelix ?
>
> War das nicht Verleihnix?
Ja, Verleihnix. Ist lustig wie der in anderen sprachen heisst :D
Im englischen heisst der: Unhygienix und seine Frau: Bacteria
https://en.wikipedia.org/wiki/List_of_Asterix_characters#Unhygienix

[Klaus W. (mfgkw)]

Danke.

@MaWin:
willst du ernsthaft ein vergeigtes Projekt, das von unfähigen Leuten 
geplant und von anderen unfähigen Leuten in den Sand gesetzt wurde, als 
Argument gegen eine Sprache bringen?

Für welche viel bessere Sprache möchtest du wieviele solche Argumente 
gegen die Sprache haben?

[MaWin (Gast)]

Hans-Georg L. schrieb:
> The signature does not need to have const &, but the function object
> must not modify the objects passed to it.

Es wird der Operator < verwendet.

Du darfst beruhigt davon ausgehen, daß die dortigen Softwerker sich für 
genau so fähig halten wie du dich.

[Hans-Georg L. (h-g-l)]

MaWin schrieb:
> Hans-Georg L. schrieb:
>> The signature does not need to have const &, but the function object
>> must not modify the objects passed to it.
>
> Es wird der Operator < verwendet.
>
> Du darfst beruhigt davon ausgehen, daß die dortigen Softwerker sich für
> genau so fähig halten wie du dich.

Du bist mal wieder richtig gut drauf ...
Und wer sich hier für den Supermann hält lass ich mal dahin gestellt.

Aber wenn du schon zitierst dann bitte alles.

Die Antwort bezog sich auf :

Karl H. schrieb:
> Abgesehen davon kann ich mir nicht vorstellen, dass es irgendeine STL
> gibt, bei der ein std::lower_bound nicht funktioniert. Das Zeug ist
> Millionenfach getestet.

[Frank M. (ukw) (Moderator)]

A. K. schrieb:

>> Windows NT hat Anleihen von VMS gehabt.
>
> Im Konzept, nicht im Code.

Wer weiß, was Dave Cutler alles von DEC damals mitgenommen hat... ;-)

> Ich weiss nicht worin VMS ursprünglich  geschrieben wurde, aber es war
> garantiert kein C. Möglicherweise BLISS.

Ja, BLISS und VAX Macro. Später, zu Open-VMS-Zeiten, wo dann auch auf 
andere Architekuren wie Alpha and Itanium portiert wurde, kam auch noch 
C dazu.

Aber ich kann mich noch an den ersten C-Compiler unter VAX/VMS erinnern. 
Grottenlahme Compiler und Compilate.

[(prx) A. K. (prx)]

Frank M. schrieb:
> Aber ich kann mich noch an den ersten C-Compiler unter VAX/VMS erinnern.

Der erste, der mir unterkam, lief im PDP-11 Modus der VAX-11 und 
produzierte Code ebendafür. Jemand hatte die nicht beneidenswerte 
Aufgabe, ebendiesen C Compiler an eine 68000 anzupassen, was ihm eine 
grässliche Overlay-Mechanik einbrachte. Auf einer 32-Bit Maschine recht 
bizarr.

Ein weiterer C Compiler kam etwas später als Teil von Eunice. Das war 
sowas wie Cygwin, also unixoide Nutzung unter VMS mit fork() und allem 
Gedöns. Nur dass sich VMS herzlich schlecht für die Emulation von fork() 
eignete. Für die Verhältnisse der Maschine grässlich langsam.

Nö, VMS und C, das war keine passende Paarung. Wer VAX und C wollte, der 
war mit BSD besser bedient.

[Frank M. (ukw) (Moderator)]

A. K. schrieb:
> Ein weiterer C Compiler kam etwas später als Teil von Eunice.

Jo, das war er.

> Nur dass sich VMS herzlich schlecht für die Emulation von fork()
> eignet. Grässlich langsam.

Daran erinnere ich mich nur allzu gut. Genau zu dieser Zeit fand ich 
meinen  Geschmack an Unix System V/68K auf VME-Bussystemen... wo 
fork/exec und Co. zum täglichen Leben eines Programmierers gehört und 
richtig Spaß machen kann.

> Wer VAX und C wollte, der war mit BSD besser bedient.

Jepp. Ich war damals im kernphysikalischen Institut in Köln. Dort war 
alles ziemlich DEC-lastig - sprich VMS auf Vaxen bzw. auf RSX auf PDP11. 
Im benachtbarten theoretischen Institut standen dieselben Vaxen, aber 
mit BSD ausgestattet.

Es hat dann noch viele Jahre gedauert, bis wir auch die VMS-Rechner 
abschafften und auf unixoide Systeme gewechselt haben. Musste natürlich 
auch Ultrix dabei sein ;-)

[Carl D. (jcw2)]

Wenn wir schon bei VMS++ (WNT) sind:
Win32 ist gar keine C-Schnittstelle, den alle Funktionen haben 
PASCAL-CallingConvention. Das bedeutet, die gerufene Funktion räumt die 
Parameter vom Stack, bei C-CallingConvetion macht dies der Aufrufer. 
Sonnst hätte C nämlich keine Funktionen mit variabler Parameter-Anzahl. 
Auch die Reihenfolge der Parameter auf dem Stack ist unterschiedlich. 
PASCAL-like pushed den ersten Parameter zuerst (da die Anzahl fix ist, 
ist das OK), C-like pushed den ersten Parameter zuletzt (nur so ist 
variable Anzahl simple implementierbar).
Die Pascal-like Variante existiert wohl auch deshalb, weil Intel beim 
Aufruf über ein CALL-Gate (damit kann man eine Funktion in einem höher 
priorisierten "Ring" aufrufen) diese Methode per Hardware unterstützt. 
Es findet dabei ein Stack-Wechsel statt und der CALL kopiert eine fixe, 
im CALL-Gate angegebene Anzahl Parameter auf den neuen Stack. Und bei 
Rücksprung räumt die Hardware den ursprünglichen Stack entsprechend ab.
Win32 ist also eher eine API, die von einem C-Compiler, der die 
entsprechende CallingConvention unterstützt, angesprochen werden kann.
Win32 benutzt sogar OOP in Form von Handles, die im Prinzip die Adresse 
von opaken Strukturen im Kernel-Adressraum sind. Zugreifen kann man auf 
die natürlich nicht direkt, sondern über entsprechende "Methoden" der 
Win32-API. Was dabei natürlich fehlt, ist die Zugehörigkeit einer 
solchen Methode zu einer Klasse. Übergebe ich allerdings eine falsche 
Objekt-Referenz (Handle), sprich eine Event-Handle an die 
"Write-Methode", die eigentlich eine File-Handle erwartet, dann meckert 
Windows.

[(prx) A. K. (prx)]

Carl D. schrieb:
> Die Pascal-like Variante existiert wohl auch deshalb, weil Intel beim
> Aufruf über ein CALL-Gate

Da der Win32 API im Ring 3 bleibt, und nur ein Wrapper um einen nicht 
dokumentierten Kernel API ist, darf dieser Zusammenhang als 
unwahrscheinlich gelten.

[Frank M. (ukw) (Moderator)]

Carl D. schrieb:
> Win32 benutzt sogar OOP in Form von Handles, die im Prinzip die Adresse
> von opaken Strukturen im Kernel-Adressraum sind.

Hm, ist das schon OOP? Handles könnten auch als Indices für Arrays, 
welche die Strukturen beinhalten implementiert sein. So macht es 
jedenfalls Unix und nennt sie Filedescriptoren, welche den Zugriff auf 
beliebige Geräte (Platten, serielle Schnittstellen, Dateien, Sockets) 
usw. regeln. Sie sind einfach von 0, 1, 2, 3, aufsteigend 
durchnumeriert.

Ob das jetzt Pointer oder Indices sind, ist doch gehopst wie 
gesprungen...

Oder übersehe ich da was?

[MaWin (Gast)]

Carl D. schrieb:
> Was dabei natürlich fehlt, ist die Zugehörigkeit einer
> solchen Methode zu einer Klasse

Nö, selbst das gibt es.

Du kannst eine Handle A haben auf Objekte einer Klasse B, die 
Funktionsaufrufe/Methoden C, D und E kennt.

Dann kannst du eine Handle F haben auf Objekte einer Klasse G, die 
Funktionsaufrufe/Methoden H und I kennt.

Und wenn man Methoden C, D oder E mit einer Handle A von Klasse B 
aufruft klappt das ebenfalls.

Klasse G enthält also Klasse B, ist von ihr abgeleitet und enthält ein 
paar Zusatzmethoden.

In Windows beispielsweise HMODULE und HINSTANCE.

Und Subclassing etc. ist unter Windows ja ebenfalls möglich, 
handprogrammiert, macht man ja schon beim Hauptfenster der Applikation.

[MaWin (Gast)]

A. K. schrieb:
>> Die Pascal-like Variante existiert wohl auch deshalb, weil Intel beim
>> Aufruf über ein CALL-Gate
>
> Da der Win32

Windows begannt nicht mit den defekten Win32, sondern auf 80x86 mit 
vorgesehener Unterstützung der segmentierten Adressierung des 80286, 
eben mit Win 1.0 bis 3.11.

Der Wechsel zum Win32 API, das weder in der Lage war, eine DLL in 
mehrere Prozessräume mit unterschiedlichen Daten zu laden (sondern da 
wurde der DLL Code mehrfach geladen und gepatcht), noch in der Lage war, 
von einem Aufruf zum nächsten die Zugriffsrechte zu ändern (das konnte 
der 286, siehe call gate), war ja eine Fehlentscheidung um die damaligen 
alten DEC Alpha Prozessoren unterstützen zu wollen, der das alles 
hardwaretechnisch nicht konnte.

Alles zurückzuführen auf den unsäglichen David Cutler, der schon bei DEC 
das unsägliche VMS Betriebssystem vergeigt hat, und dann bei Microsoft 
die Super Grundlage Windows 3.1 von Mark Zbikowski verunstalten durfte. 
Die Fehleranzahl explodierte von (nachträglich nachgewiesenen in Kernel 
von 3.1) 27 auf über 65000.

Wenn man den Source von Windows 3.1 liest, ist das ein Quell der Freude, 
so elegant und effizient, liest man Windows NT, blickt man in einen 
Haufen Scheisse, die Hälfte der neuen Parameter wurde nicht verwendet 
oder hatte nur eine Standardwert, das zeigt schon damals daß da jemand 
dran arbeitet der keinen Überblick hatte.

[Frank M. (ukw) (Moderator)]

MaWin schrieb:
> Die Fehleranzahl explodierte von (nachträglich nachgewiesenen in Kernel
> von 3.1) 27 auf über 65000.

Mehr als 65535 Fehler ging wohl technisch schon nicht, wegen unsigned 
int16 overflow ;-)

> Wenn man den Source von Windows 3.1 liest, ist das ein Quell der Freude,
> so elegant und effizient, liest man Windows NT, blickt man in einen
> Haufen Scheisse, die Hälfte der neuen Parameter wurde nicht verwendet
> oder hatte nur eine Standardwert, das zeigt schon damals daß da jemand
> dran arbeitet der keinen Überblick hatte.

Naja, Windows NT lief jedenfalls wesentlich stabiler als Windows 3.1, 
was schon bei einem Segmentation Fault eines simplen Programms komplett 
mit abschmierte. NT konnte Fehler von Anwenderprogrammen in der Regel 
locker verkraften.

[(prx) A. K. (prx)]

MaWin schrieb:
> Alles zurückzuführen auf den unsäglichen David Cutler, der schon bei DEC
> das unsägliche VMS Betriebssystem vergeigt hat,

Sehe ich anders. Das Problem von DEC war nicht das damals ausgesprochen 
moderne und leistungsfähige VMS, sondern die Hardware. Die VAX war nach 
wenigen Hardware-Generationen nicht mehr steigerungsfähig. Der Versuch 
brachte DEC an den Rand des Konkurses.

> Die Fehleranzahl explodierte von (nachträglich nachgewiesenen in Kernel
> von 3.1) 27 auf über 65000.

Das Vehältnis von Fehlern zu Zeilen fände ich interessanter. Dass 
komplexe Systeme mehr Fehler enthalten als einfache kann kaum 
verwundern.

> oder hatte nur eine Standardwert, das zeigt schon damals daß da jemand
> dran arbeitet der keinen Überblick hatte.

Dem fehlte nicht der Überblick, sondern er hatte bloss eine andere 
Vorstellung von einem Kernel-API als du.

NT war in Tradition von VMS mit asynchronen APIs definiert worden. Also 
mit APIs, die eine Operation mit nichttrivialer Laufzeit nur starten, 
aber nicht implzit auf deren Ende warten. Das ist die Grundoperation des 
Systems. Allerdings wird wohl in 99% der Fälle die synchrone Variante 
mit Default-Parameter verwendet. Das ist erheblich bequemer. Nicht aber 
schneller.

Demgegenüber arbeiten Unix/Linux weitgehend synchron, was zwar den API 
erheblich vereinfacht, aber ohne die circa zusammen mit NT erst 
aufkommenden Threads die I/O-Performance aus Sicht der Anwendungen 
erheblich begrenzt.

Dazu kommt die aus VMS übernommene Sicherheitsphilosophie. Unix/Linux 
sind demgegenüber steinzeitlich, mit allmächtigem "root" User. Auch das 
verkompliziert den API.

Nö, als Produkt eines Deppen sehe ich das nicht. Die Welt hat sich nur 
seitens der Anwendungen in eine etwas andere Richtung entwickelt als 
ursprünglich projektiert. VMS verlor gegen die Unix-Konkurrenz und 
Windows auf Servern würde ich nicht direkt als Fehlschlag betrachten.

[MaWin (Gast)]

A. K. schrieb:
> Sehe ich anders.

Das war klar :-)

> Das Problem von DEC war nicht das damals ausgesprochen
> moderne und leistungsfähige VMS, sondern die Hardware.

Nun ja, auf meiner (nun gut, der mir damals zugewiesenen)
VAX habe ich mir VMS genau 2 Tage angeguckt und dann durch
Unix ersetzt.
Das Geschwätz von "Leistungsfähigkeit (schneller)" gab es
auch damals schon, entsprach aber nicht der Realität. Es
war wie bei Benchmarks nur eine theoretische Leistung, die
in der Praxis nicht abrufbar/konfigurierbar war, weil die
zur optimalen Konfiguration notwendigen Rahmenbedingungen
in der Realität nicht konstant waren.

> Die VAX war nach
> wenigen Hardware-Generationen nicht mehr steigerungsfähig.

Tja, so ist das, wenn man den Falschen die Entwicklung
überlässt, dann wird früh in falsche Richtungen abgebogen,
die sich dann als Sackgasse herausstellen.

[(prx) A. K. (prx)]

MaWin schrieb:
> Tja, so ist das, wenn man den Falschen die Entwicklung
> überlässt, dann wird früh in falsche Richtungen abgebogen,
> die sich dann als Sackgasse herausstellen.

An dir ist offensichtlich ein John Cocke verloren gegangen, der in den 
70ern merkte, dass Maschinen mit steigender Komplexität des 
Befehlssatzes ein Irrweg waren und wurden. Die meisten anderen Designer 
von Rechnerarchitekturen liefen zusammen im Rudel in genau diese 
Richtung. Die VAX darf man getrost als einen Kulminationspunkt der 
Komplexität betrachten - und das erwies sich bald als Problem.

Warum hast du damals bloss nicht den Mund aufgemacht? Der Welt wären 
manche Irrwege erspart geblieben, hätte man damals auf dich gehört. John 
Cocke durfte das nicht preisgeben, dem hatte das sein Arbeitgeber 
verboten. Asche auf mein Haupt - ich habe bis zur den ersten ARMs in den 
80ern gebraucht, bis mir das klar wurde.

[Frank M. (ukw) (Moderator)]

A. K. schrieb:
> Sehe ich anders. Das Problem von DEC war nicht das damals ausgesprochen
> moderne und leistungsfähige VMS, sondern die Hardware.

Angelehnt an den Dativ:

Extreme CISC ist dem Prozessor sein Tod :-)

> Dazu kommt die aus VMS übernommene Sicherheitsphilosophie.

Wir dachten uns damals schon, wenn wir länger auf die Antwort eines 
unter VMS laufenden Programms warten mussten:

"Die CPU muss bestimmt bei jedem Maschinen-Befehl erstmal das VMS 
fragen, ob sie diesen Befehl überhaupt in diesem Kontext ausführen darf" 
;-)

Aber von der Administration fand ich VMS damals unschlagbar.

Bugs gub es damals aber auch. Der netteste war der PURGE-Befehl, welcher 
unter ganz bestimmten Umständen ganze Laufwerke leerputzte.

[(prx) A. K. (prx)]

Frank M. schrieb:
> "Die CPU muss bestimmt bei jedem Maschinen-Befehl erstmal das VMS
> fragen, ob sie diesen Befehl überhaupt ausführen darf" ;-)

So ganz falsch ist der Witz nicht. Denn die Komplexität des API 
spiegelte sich in der Komplexität mancher Maschinenbefehle wieder, die 
ebenfalls über den einen oder anderen Parameter verfügten, der nur 
selten einen anderen als den Default-Wert hatte. Der Microcode dazu muss 
aber jedes verdammte Mal nachsehen, ob das auch wirklich so ist.

Selten genutzte x86-Befehle wie ENTER erinnern heute noch an solche 
Ideen.

> Wir dachten uns damals schon, wenn wir länger auf die Antwort eines
> unter VMS laufenden Programms warten mussten:

Mich beeindruckte eher, wieviele Anwender gleichzeitig mit der Kiste 
arbeiten konnten, ohne unangenehm lange warten zu müssen. Ausser 
natürlich, wenn die nichts Anderes im Sinn hatten als Space Invaders - 
das war der Killer.

[Karl H. (kbuchegg)]

Frank M. schrieb:

> Aber von der Administration fand ich VMS damals unschlagbar.

fand ich auch und finde ich auch heute noch.

Man darf nicht übersehen, dass die VAX Vorreiter für vieles war. Meines 
Wissens sah die Welt auch Clustering das erste mal auf einer VAX.

> Bugs gub es damals aber auch. Der netteste war der PURGE-Befehl, welcher
> unter ganz bestimmten Umständen ganze Laufwerke leerputzte.

So richtig viele Bugs sind mir auf VMS eigentlich nicht untergekommen. 
Das war schon ein richtig stabiles System. Wir hatten mal den Fall, dass 
sich das System mit einer defekten Systemplatte 2 Tage lang über die 
Runden schleppte. (Das war VMS 4.7 wenn ich mich recht erinnere. Keine 
Ahnung bei welcher Zahl Open-VMS jetzt steht)

[Karl H. (kbuchegg)]

A. K. schrieb:

> Der Welt wären
> manche Irrwege erspart geblieben

Aus heutiger Sicht: ja

Aber so der grosse Wurf war der IBM RT dann auch wieder nicht.

[Frank M. (ukw) (Moderator)]

Karl H. schrieb:
> fand ich auch und finde ich auch heute noch.

Die Versionierung von Dateien direkt im Dateisystem vermisse ich heute 
noch bei anderen Systemen. Das ist echt schade, dass mit VMS auch dieses 
einfache, aber sehr wirksame Konzept untergegangen ist.

Okay, heutzutage gibt es die Schattenkopien (Snapshots) unter Windows, 
die man automatisch erstellen lassen kann. Aber sie helfen einem 
Administrator nur bedingt, wenn sich $USER mal wieder eine Datei 
gelöscht hat, da die Schattenkopien nicht jede gewünschte Version, 
sondern nur Zustände zu ganz bestimmten Zeiten festhalten.

[Frank M. (ukw) (Moderator)]

A. K. schrieb:
> Ausser
> natürlich, wenn die nichts Anderes im Sinn hatten als Space Invaders -
> das war der Killer.

Waren die ganzen Spiele für VAX/VMS (wie Space Invaders, Snake und Co) 
nicht Portierungen von irgendwelchen Unix/BSD/Ultrix-Programmen? Habs 
nicht mehr im Kopf...

[(prx) A. K. (prx)]

Karl H. schrieb:
> Aber so der grosse Wurf war der IBM RT dann auch wieder nicht.

Musst in der Geschichte etwas zurück gehen. In die 70er, in denen diese 
Idee von Cocke untersucht wurde. Der verglich die Effektivität seiner 
Ideen mit deren Mainframes und das Ergebnis war eindeutig. Was als RT 
ein Jahrzehnt später auf den Markt kam war eher von IBMs kaufmännischen 
Vorgaben geprägt als von technischen.

Mit dem Mitteln von IBMs Technik der 70er entwickelt hätten solche 
Maschinen den ungemein lukrativen Markt sauteurer Maschinen kaputt 
gemacht, also am eigenen Ast gesägt. So zumindest sah IBM das und liess 
das deshalb garnicht erst zu. Wie auch beim PC, auch der war aus dem 
gleichen Grund vorsätzlich auf "zu klein für ernsthafte Arbeit" 
optimiert worden.

Ein Jahrzehnt später merkten sie dann, dass der Unix-Markt ohne sie 
stattzufinden drohte und holten zwischenzeitlich den RT aus der Kiste, 
während sie das eigentliche POWER-Design entwickelten.

[Karl H. (kbuchegg)]

Frank M. schrieb:

> Waren die ganzen Spiele für VAX/VMS (wie Space Invaders, Snake und Co)
> nicht Portierungen von irgendwelchen Unix/BSD/Ultrix-Programmen? Habs
> nicht mehr im Kopf...

Keine Ahnung.
Hab damals wie ein Wilder "Moria" gespielt :-)
Ultrix denke ich aber nicht. Das führte damals noch ein Schattendasein.

[Karl H. (kbuchegg)]

Frank M. schrieb:
> Karl H. schrieb:
>> fand ich auch und finde ich auch heute noch.
>
> Die Versionierung von Dateien direkt im Dateisystem vermisse ich heute
> noch bei anderen Systemen.

Ditto


Ich werd verrückt
https://www.raspberrypi.org/forums/viewtopic.php?t=7552&p=93217
https://www.youtube.com/watch?v=O1577ss-3qM

Ja, die Welt hat sich schon enorm weiter gedreht, seit 'damals'

[Moby (Gast)]

MaWin schrieb:
> so sind sie, die Überheblichen Softwerker glauben nur an ihre
> Scheuklappensicht und ignorieren die Wahrheit. Leider zieht diese
> Überheblichkeit eine ganze Branche in den Abgrund. Es werden Versprechen
> gemacht "geht viel schneller, ist damit billiger als früher" und die
> Realität ist, daß Softwareerstellung viel langsamer geht und viel teurer
> wird. Und wenn nicht schneller und billiger, so soll das Ergebnis besser
> sein, scrum sei Dank. Das Ergebnis sieht man allerorten, z.B. bei eBay,
> jede Woche anders, jede Woche andere Fehler, vorne hübsch (oder auch
> nicht, jedenfalls optisch anders), hinten nicht angefasst und nicht
> zusammenpassend. Noch immer (seit Jahren) kann die App nicht dasselbe
> wie das Web-Frontend, weil die Kinder der Softwareprogrammierung sich
> lieber woanders vergnügen. Und sage keiner, eBay würde nicht genug Geld
> in die Entwicklung stecken oder hätte halt nur dumme Softwerker. Nein,
> bei eBay sieht man klar sie schlimmen Folgen von scrum. Und wenn ich
> heute ein Lastenheft einer (GUI-) Software von vor 20 Jahren auf den
> Tisch lege, kommen Angebote die 25 mal teurer sein sollen und 25 mal
> länger in der Implementierung brauchen.

> Ja, die Softwarebranche,
> "verbraucht" Jahr für Jahr mehr Rechenleistung und Speicher, so daß der
> Schrott genau so schnell läuft wie früher, nur fehlerhafter ist.

Ja bravo MaWin. Zu den gleichen Schlüssen kann sogar schon der kleine 
Asm-Bastler kommen ;-) Und auch jeder einfache Anwender von 
Windows-Software, der ein paar Inkarnationen dieses OS und dessen 
Anwendungen krebsartig wuchernd, lahm und lahmer über die Jahre auf 
seiner Platte erlebt hat.

[Bastler (Gast)]

Lass mich raten, deine AVR-ASM Programm entstehen mit Atmel-Studio unter 
Windows. Wenn man manche Dinge so haßt, Windows und in OOP geschriebene 
IDEs, dann sollte man aktiv werden. Linux und Eclipse benutze ich. Gut 
Eclipse ist im noch böseren Java geschrieben, aber das stört mich nicht. 
Beide Software "Produkte" haben ein ausgezeichnetes 
Preis-/Leistungsverhältnis und werden von mir soweit beherrscht, daß ich 
mich nicht darüber ärgern muß. Und bei Programmiersprachen ist es genau 
so. C++ erlaubt nicht jede Konstruktion, die in C geht, aber zu Fehlern 
führen kann. C wiederum befreit mich von dem Problem Variablen 
"überschneidungsfrei" auf Register zuzuordnen. Mir geht nämlich die 
Genialität ab, bei Änderungen mal schnell in 100ms ein neues 
Registermapping aufzusetzen.

[Moby (Gast)]

Bastler schrieb:
> Wenn man manche Dinge so haßt, Windows und in OOP geschriebene
> IDEs,

Falsch. Ich kritisiere die zu komplexe Programmierform.
Nicht das Resultat bei der Anwendung. Obwohl gerade Atmel Studio 6 die 
Nachteile seiner Programmierform kaum verbergen kann...

> C wiederum befreit mich von dem Problem Variablen
> "überschneidungsfrei" auf Register zuzuordnen. Mir geht nämlich die
> Genialität ab, bei Änderungen mal schnell in 100ms ein neues
> Registermapping aufzusetzen.

Klar. C vereinfacht einerseits. Andererseits hat das seinen Preis, der 
sich im Aufblasen der Sprachmittel und der nicht optimal erreichbaren 
Umsetzung äußert.

Bitte unterstelle aber nicht wieder insgeheim, ich hielte die 
Voraussetzungen für Assembler in der heutige Windows-Programmierung für 
gegeben...

Für uC schaut das ganz anders aus. Nicht zuletzt wegen einheitlicher, 
überschaubarer Hardware!

[Inschenör (Gast)]

Moby schrieb:
> Falsch. Ich kritisiere die zu komplexe Programmierform.

Was wieder die Frage aufwirfst: Wieso? Wer zwingt dich, OOP zu 
programmieren? Du musst es doch nicht tun. Es sei denn, dein 
Auftraggeber verlangt das von dir. Selbst Java kann man im Prinzip rein 
prozedural entwickeln.

Bastler schrieb:
> Lass mich raten, deine AVR-ASM Programm entstehen mit Atmel-Studio unter
> Windows. Wenn man manche Dinge so haßt, Windows und in OOP geschriebene
> IDEs, dann sollte man aktiv werden. Linux und Eclipse benutze ich. Gut
> Eclipse ist im noch böseren Java geschrieben, aber das stört mich nicht.

Also ich finde sowohl das Atmel-Studio als auch Eclipse sind üble 
Ressourcenfresser, lahm und überladen. Ich nutze CodeBlocks/EmBlocks, 
das gefühlt den gleichen Funktionsumfang bietet und sich tausendmal 
schneller anfühlt. Allerdings ist das auch in C++ entwickelt ;-)

[Moby (Gast)]

Inschenör schrieb:
> Moby schrieb:
>> Falsch. Ich kritisiere die zu komplexe Programmierform.
>
> Was wieder die Frage aufwirfst: Wieso? Wer zwingt dich, OOP zu
> programmieren? Du musst es doch nicht tun. Es sei denn, dein
> Auftraggeber verlangt das von dir. Selbst Java kann man im Prinzip rein
> prozedural entwickeln.

Na mich als Bastler und im Mikrocontrollerbereich sicher niemand ;-)
Muß man OOP aber unbedingt selbst verwenden um es kritisieren zu dürfen?
Langt nicht schon die Kenntnis der Codelitanei für jeden beliebigen 
Windows-Pieps?

> Allerdings ist das auch in C++ entwickelt ;-)

Womöglich von fähigeren Programmierern mit größerem Zeitbudget und mehr 
zugelassenem Freiraum bei der Wahl der Mittel... Alles drei sensible 
Punkte bei komplexen Sprachen ;-)

[Inschenör (Gast)]

Moby schrieb:
> Muß man OOP aber unbedingt selbst verwenden um es kritisieren zu dürfen?

Nicht unbedingt.

Moby schrieb:
> Langt nicht schon die Kenntnis

Das wäre das Problem bei dir, wenn du echt wärst. Aber ich weiß ja auch, 
dass du nur ein Troll bist, der ein bisschen Spaß hier haben möchte, 
indem er Unsinn verbreitet ;-)

Moby schrieb:
> Womöglich von fähigeren Programmierern mit größerem Zeitbudget und mehr
> zugelassenem Freiraum bei der Wahl der Mittel... Alles drei sensible
> Punkte bei komplexen Sprachen ;-)

Unsinn wie diesen hier ;-)

[TriHexagon (Gast)]

Moby schrieb:
> Falsch. Ich kritisiere die zu komplexe Programmierform.
> Nicht das Resultat bei der Anwendung. Obwohl gerade Atmel Studio 6 die
> Nachteile seiner Programmierform kaum verbergen kann...

Ich fasse es nicht, bitte schreib mal eine IDE die vergleichbar mit 
Atmel Studio 6 ist. Dann wirst du endlich mal merken wie unfassbar naiv 
du bist und all den Aufwand immer wieder unterschätzt. Am besten noch in 
Assembler damit du gar nicht fertig wirst.

Moby schrieb:
> Bitte unterstelle aber nicht wieder insgeheim, ich hielte die
> Voraussetzungen für Assembler in der heutige Windows-Programmierung für
> gegeben...

Natürlich, das ist der Grund weshalb sich die Assemblerprogrammierung in 
der Anwendungsentwicklung nicht durchsetzen konnte. Ausflüchte und 
Realitätsverzerrung...

[(prx) A. K. (prx)]

TriHexagon schrieb:
> Ich fasse es nicht, bitte schreib mal eine IDE die vergleichbar mit
> Atmel Studio 6 ist.

Die Frage ist, wieviel er davon verwendet und verlangt. Beim Umstieg der 
weit kompakteren IDE V4 auf V5 hat es einige Tränen gegeben.

[TriHexagon (Gast)]

A. K. schrieb:
> TriHexagon schrieb:
>> Ich fasse es nicht, bitte schreib mal eine IDE die vergleichbar mit
>> Atmel Studio 6 ist.
>
> Die Frage ist, wieviel er davon verwendet und verlangt. Beim Umstieg der
> weit kompakteren IDE V4 auf V5 hat es einige Tränen gegeben.

Mhm stimmt auch wieder, dann lieber V4 mit vollem Umfang.

[Inschenör (Gast)]

A. K. schrieb:
> Die Frage ist, wieviel er davon verwendet und verlangt. Beim Umstieg der
> weit kompakteren IDE V4 auf V5 hat es einige Tränen gegeben.

Deswegen mag ich Codeblocks/Emblocks so sehr. Wobei das schon noch 
einiges moderner ist als das AVR Studio 4. Der Editor war ja nicht so 
toll, wenn ich mich recht erinnere.

[MaWin (Gast)]

Inschenör schrieb:
> Deswegen mag ich Codeblocks/Emblocks so sehr.

Weil's nicht mehr weiterentwickelt wird ?
Gutes Argument, muss man sich nie mehr an Neues gewöhnen.

[Kenner (Gast)]

> Ja, die Softwarebranche,
> "verbraucht" Jahr für Jahr mehr Rechenleistung und Speicher, so daß der
> Schrott genau so schnell läuft wie früher, nur fehlerhafter ist.

Das ist mir auch aufgefallen, ich meine früher war ein Spiel 600Mb groß 
und heute 6Gb groß, also 10-fache Steigerung. Aber der Spielumfang ist 
meistens der selbe geblieben, nur die Grafik ist besser, und die sind 
langsam.Ich glaube das ist so weil immer mehr automatisierte 
Entwicklungstools benutzt werden, und die produzieren nicht effizienten 
code.

[TriHexagon (Gast)]

Kenner schrieb:
>> Ja, die Softwarebranche,
>> "verbraucht" Jahr für Jahr mehr Rechenleistung und Speicher, so daß der
>> Schrott genau so schnell läuft wie früher, nur fehlerhafter ist.
>
> Das ist mir auch aufgefallen, ich meine früher war ein Spiel 600Mb groß
> und heute 6Gb groß, also 10-fache Steigerung. Aber der Spielumfang ist
> meistens der selbe geblieben, nur die Grafik ist besser, und die sind
> langsam.Ich glaube das ist so weil immer mehr automatisierte
> Entwicklungstools benutzt werden, und die produzieren nicht effizienten
> code.

~99,99% davon sind Assets. Natürlich werden die Spiele größer. Größere 
Texturen (sogar mehr Texturen, damals gabs kein Normalmapping etc.), 
mehr Polygone. Der Verglich hinkt von vorn bis hinten.

[Bastler (Gast)]

Oder vielleicht weil die Phantasie heutiger Spieler nur noch mit 
4k-aufgelösten Spielscenen funktioniert. Es gab auch Zeiten, da hat ein 
Hundertstel dieser Auflösung reichen müssen. Warum werden Spiele also 
immer grösser? Und wer ist nicht in der Lage das zu verstehen?
Es gab auch mal Zeiten, da war eine elektronische Uhr ein Zähler mit 
7-Segment-Anzeigen. Heute braucht sowas die Leistung eines 
Rechenzentrums von vor 20 Jahren, damit man auf dem 200dpi Display 
nostalgische Zifferblätter anzeigen kann. Und nach 10 Stunden ist die 
Batterie alle.

[Inschenör (Gast)]

MaWin schrieb:
> Weil's nicht mehr weiterentwickelt wird ?
> Gutes Argument, muss man sich nie mehr an Neues gewöhnen.

Emblocks wird kräftig weiterentwickelt. CodeBlocks eigentlich auch. Nur 
weil es seit 2 Jahren kein neues Release gab, heißt das doch nicht, dass 
das Projekt tot ist.

Aber ich gebe ja auch zu, dass ich relativ selten C-Anwendungen für den 
PC entwickle. Von daher spielt es für mich keine so große Rolle, das 
neueste Tool zu haben.

[MaWin (Gast)]

Inschenör schrieb:
> Emblocks wird kräftig weiterentwickelt. CodeBlocks eigentlich auch. Nur
> weil es seit 2 Jahren kein neues Release gab, heißt das doch nicht, dass
> das Projekt tot ist.

Das sehen die "Macher" aber anders.

[TriHexagon (Gast)]

Bastler schrieb:
> Oder vielleicht weil die Phantasie heutiger Spieler nur noch mit
> 4k-aufgelösten Spielscenen funktioniert. Es gab auch Zeiten, da hat ein
> Hundertstel dieser Auflösung reichen müssen. Warum werden Spiele also
> immer grösser?

Die Indieszene ist heute größer denn je und produziert jede Menge 
Spiele, welche sich auf das Gameplay konzentrieren und nicht auf die 
Grafik. Siehe die ganzen 8-Bit Retro Spiele.
Und wo ist das Problem, dass AAA Titel den PC auch mal auslasten und 
zeigen dürfen was heute möglich ist? Ok das Gameplay sollte auch nicht 
zu kurz kommen.

Inschenör schrieb:
> MaWin schrieb:
>> Weil's nicht mehr weiterentwickelt wird ?
>> Gutes Argument, muss man sich nie mehr an Neues gewöhnen.
>
> Emblocks wird kräftig weiterentwickelt. CodeBlocks eigentlich auch. Nur
> weil es seit 2 Jahren kein neues Release gab, heißt das doch nicht, dass
> das Projekt tot ist.

Jap siehe Nightly builds: 
http://forums.codeblocks.org/index.php/board,20.0.html

[Inschenör (Gast)]

MaWin schrieb:
> Das sehen die "Macher" aber anders.

Ganz im Gegenteil. Das Projekt wird so gut angenommen, dass der Macher 
auf die Idee gekommen ist, dass man damit Geld verdienen könnte. Es gibt 
also einen Nachfolger. Der bekommt dann nur ein kommerzielles 
Lizenzmodell, wobei die Basisfunktionalität immer noch kostenlos sein 
wird.

[Bastler (Gast)]

@trihexagon:
Nirgends ist ein Problem. Das war die Antwort auf: "ich will alles, aber 
billig". Als ich vor kurzem mal beim MM die UHD-Fernseher anschaute, da 
liefen darauf Spiele-Demos, deren Bildqualität auch mich Mid-50er 
beeindruckte. Nur darf man sich, wenn man das will, nicht über Hunderte 
Gigabyte beklagen. Und die braucht man nicht, weil heute Compiler viel 
schlechter wären als früher, wie hier suggeriert wird.
Du schreibst übrigen nichts anderes, nur in der Sprache einer anderen 
Generation. Ich versteh das trotzdem ;-)

[Daniel A. (daniel-a)]

Kenner schrieb:
> Das ist mir auch aufgefallen, ich meine früher war ein Spiel 600Mb groß
> und heute 6Gb groß, also 10-fache Steigerung

Wenn man dann beim Compilieren die nicht verwendeten Symbole noch 
entfernt, bleiben sicher nurnoch wenige MB zurück. Bei folgendem 
Projekt:
https://github.com/Daniel-Abrecht/DPA-UCS
hat dass die grösse des Binaries für Linux von 680KB auf 24KB reduziert. 
Das sind 96%! Nur lohnt sich der Mehraufwand für Spielentwickler nicht, 
da es das Spiel nicht schneller macht und es auch sonst niemandem 
auffallen würde.

[Georg (Gast)]

Daniel A. schrieb:
> da es das Spiel nicht schneller macht und es auch sonst niemandem
> auffallen würde.

Die Wirkung wäre eher kontraproduktiv - ich habe schon genug hämische 
Kommentare in der "Fach"-Presse gelesen, dass das Programm XY nur 
soundsoviel MB auf die Platte bringt und damit nicht mit "richtiger" 
Software vergleichbar ist. Als Programmierer muss man sich schon Mühe 
geben, seine Software auf den üblichen Umfang künstlich aufzublasen. 
User die z.B. Irfanview schätzen trotz der extrem geringen 
Programmgrösse sterben einfach aus, die meisten fühlen sich beschissen, 
weil sie so wenig GB für ihr Geld kriegen (selbst wenn es umsonst ist).

Georg

[Benjamin K. (benjamin92)]

Sowas hab ich noch nie gehört, dass jemand Software nur gut findet, wenn 
sie viel Speicher verbraucht, bei mir und vielen anderen ist eher der 
Gegenteil der Fall...

[Rabenhorst (Gast)]

> Das glaubst Du doch selbst nicht...

> Sowas hab ich noch nie gehört

Ich bin zwar nicht Georg und halte das Ganze heute auch nicht mehr für 
relevant, aber bei einem Projekt irgendwann achtzehnhundertschlagmichtot 
war ich ganz stolz darauf, das recht komplexe Programm auf eine binäre 
Größe von ein paar Dutzend kB gebracht zu haben. Das Ende der 
Geschichte: Der Auftraggeber verlangte, dass die exe auf die x-fache 
Größe kommen soll, so dass der Endanwender gefühlt "mehr bekommt". 
Nachdem ich ihn überzeugen konnte, dass die Auslieferung des 
Debug-Builds keine gute Idee wäre, habe ich dann entsprechend Müll 
hineingepackt (zu meiner Ehrenrettung: so, dass der Endanwender keinen 
Nachteil davon hatte, außer dass auf seiner Festplatte ~200kB mehr 
lagerten).

[Kenner (Gast)]

Das war ein ziemlich dummer Auftraggeber.

[Rolf M. (rmagnus)]

Kenner schrieb:
> Das war ein ziemlich dummer Auftraggeber.

Nein, es war ein Auftraggeber, der sich auf ziemlich dumme Endanwender 
eingestellt hat.