Thema: C vs. C++ bzw. wo ist was sinnvoll?

[joachim_neu]

Also ich persönlich bin ja für puren ASM, das is doch einfach spannender als müslifresserC

[maumo]

oder gleich die opcodes alle per hexeditor eintippen ^^

ich denke C ist die beste wahl, ist einfach, gut verständlich
und nicht grad langsam

[Svenska]

ASM hat Vorteile, aber man muss 100% selbst optimieren.
Aber der Lerneffekt geht dabei verloren.

[DDR-RAM]

der Vorteil von asm geht aber auch gegen 0,
die einzigen somd Wirklich die volle Kontrolle und die maximal mögliche Optimierung, allerdings werden nicht viele besseren Asm-Code bauen als nen C/C++-Compiler.

MfG
DDR-RAM

[Jidder]

naja exceptions in einem kernel machen den kernel nur inkonsistent, weil man nie sicher sein kann wann eine geworfen wird und wann nicht. wenn wir new aber richtig verwenden wollen, dann brauchen wir exceptions, weil das "standard konforme" new eine exception (bad_alloc) wirft.

da fallen mir die casts ein, die in C++ schreibarbeit (static_cast<...>) sind und gerne mal exceptions werfen. (naja wobei ich mir selbst nicht vorstellen kann wo da exceptions auftreffen sollten ...). in einem kernel gibts es sicherlich auch tausende casts und ich hoffe doch ihr wollt in einem C++-Kernel nicht mit C-Style casts ankommen, oder?

Verstehe ich nicht recht, die Treiber gehören doch nicht zum Mircokernel?

Treiber müssen aber irgendwie mit dem Kernel kommunizieren. Dazu müssen sie sich einigen ob C++-Objekte oder einfache C-Structs transportiert werden. Das gibt für einen C++-Kernel sehr viel Konvertier-Arbeit.

Aber festgenagelt werden sie aber auf jedenfall nicht, wenn sie kein C verwenden, denn das C-Interface wird mit extern "C" deklariert.

ja klar geht das so, aber was ist daran dann noch C++? Da kann ich mich doch gleich auf C beschränken.

Der Kernel selber, befasst sich gar nicht so viel mit Hardware, das machen doch eher die Treiber, der Kernel befasst sich mit Abstrakten Typen, wie Prozessen, die sehr wohl als Objekt darstellbar sind.

Was wenn ein C/Assembler/Pascal-Programm Informationen über einen Prozess haben will? Dann muss diese C++ Prozessinformation von Kernel erst umständlich in ein c-struct verpackt werden. Mit allen anderen Informationen, die in (Instanzen von) Klassen gespeichert sind, ist es genauso. es müssen also alle strukturen, die für andere programme/treiber von belang sind in 2 formen (c-struct und c++-objekt) vorhanden sein und es muss möglichkeiten geben, sie in einander umzuwandeln.

Zeige mir ne Hardware die man mit C ansteuert, rofl.

Mikrocontroller werden zu Tausenden in (fast) reinem C Programmiert.
Außerdem meinte ich dass Hardware nicht besonders darauf ausgelegt ist, als ein "Objekt" im Sinn von C++ behandelt zu werden.

Bereits geregelt... zum größten Teil.

gut

[joachim_neu]

Zeige mir ne Hardware die man mit C ansteuert, rofl.

Mikrocontroller werden zu Tausenden in (fast) reinem C Programmiert.

streng genommen nein. weil "in()" und "out()" nicht zu C gehören, sondern zu der lib

[DDR-RAM]

Also new muss keine exception werfen können, der Standard sieht auch ein new vor, welches keine exception wirft. Bei Treibern kann es schon wieder anders sein, wenn wir kompatibel, dynamisch usw. sein wollen, dann müssen wir sowieso C++-Treiber mit Exception-Handling zulassen.
Die new/delete-Methoden des Treibers könnten z.B. auf eine malloc/free-Version des Kernel zugreifen, aber Back to Topic.

static_cast wirft niemals eine exception, reinterpret_cast wirft niemals eine, const_cast ist Blödsinn -> verboten im Kernel und dynamic_cast, welches eine exception werfen kann verwendet RTTI, würde ich auch weglassen im Kernel, außerdem vorallem bei Mehrfachvererbung in Verbindung mit virtuellen Funktionenen verwendet.
reinterpret_cast und static_cast funktionieren eh wie C-Cast, also mir wäre es egal ob C-Casts oder C++-Casts

Mal nen beispiel:

Code: [Auswählen]


//ckernel.h

struct PROCESS
{
DWORD dwID;
//[...]
};

#ifdef __cplusplus
extern "C" {
#endif

void MacheEtwasMitPROCESS(const PROCESS* pProcess);
//[...]

#ifdef __cplusplus
};
#endif

//cppkernel.h

#include "kernel.h"

class CProcess : protected PROCESS
{
public:
DWORD GetId();
//[...]

public:
void MacheEtwas() const;
//[...]
};

//kernel.cpp

#include "ckernel.h"
#include "cppkernel.h"


void MacheEtwasMitPROCESS(const PROCESS* pProcess)
{
static_cast<const CProcess*>(pProcess)->MacheEtwas();
}

void CProcess::MacheEtwas() const
{
//[...]
}


So ungefähr halt.
Wo ist da Arbeitsaufwand?
oder man nimm reinterpret_cast und leitet die Klasse nicht ab, gefällt mir fast noch besser, denn:

Code: [Auswählen]


// x86.h

class CTSSegment
{
public:
//[...]
protected:
DWORD m_wBackLink; // only low 16-bit are used
DWORD m_dwESP0;
};

// cppkernel.h

#include "x86.h"

class CThread : public CTSSegment
{
public:
void MacheEtwas();
//[...]

protected:
CProcess* m_pProcess;
//[...]
};

// ckernel.h

struct THREAD
{
DWORD dwBackLink; // only low 16-bit are used
DWORD dwESP0;
//[...]
PROCESS* pProcess;
};

// ich spar mir den #ifdef __cplusplus quatsch

extern "C" void MacheEtwasMitTHREAD(THREAD* pThread);

// kernel.cpp

void MacheEtwasMitTHREAD(THREAD* pThread)
{
reinterpret_cast<CThread*>(pThread)->MacheEtwas();
}

void CThread::MacheEtwas()
{
}



Zu dem Problem mit dem Name-mangling oder wie das heißt,
es muss doch möglich sein für jeden Compiler ne .LIB-Datei zu bauen, damit die die C++-Klassen verwenden können. Kann mir mal bitte wer verraten, wie das funktioniert, sonst krieg ich nen Fön  
Für Windows gibts doch auch nen DDK, keine Ahnung wie das funktioniert, weiß wer was darüber?

Das umständliche packen in eine c-struct sieht man oben in meinen 2-Code Beispielen

Also, klärt mich mal bitte auf, wie die Treiber unabhängig kompiliert werden. Dazu müssen sie ja wissen, wo die Prozeduren des Kernels liegen.

MfG
DDR-RAM

[Jidder]

Mikrocontroller werden zu Tausenden in (fast) reinem C Programmiert.

streng genommen nein. weil "in()" und "out()" nicht zu C gehören, sondern zu der lib

nein so mein ich das nicht. bei bestimmten plattformen gibt es keine ports, die man per in und out ansteuert, sondern die sind direkt in den speicher gemappt. also wenn man an ein bestimmtes offset im RAM was schreibt landet es bei irgendeiner hardware.

DDR-RAM: hmm ... das erste Beispiel hat mich irgendwie überzeugt. da kann ich nix mehr gegen C++ sagen. wobei ich nicht dafür bin, alles zwanghaft abzuleiten, sondern ab und zu auch einfach mal ein struct als eigenschaft eines objekts zu machen.

<-- widerstand gegen c++ aufgeb

[joachim_neu]

Ich bin ja immernoch für ASM

[matthieuriolo]

du hardcore progger  

[Another Stupid Coder]

Wie wäre es mit Fortran? Oder Ada? >D

[maumo]

nein JAVASCRIPT .NET^^

[The-Programmerfish]

Brainfuck

[Svenska]

Basic.

Aber mal ehrlich - wollt ihr den Lerneffekt bei dem Lern-OS
vernachlässigen? Die Mehrzahl kann C und kein C++ und wer C++ kann,
kann in der Regel auch C.

Eine Mischung in einem Kernel(!) fuehrt bestimmt zu Instabilität. Einigt
euch auf C oder C++ - nicht beides.

Wenn ich es mir recht ueberlege, so gedenke ich, viel (später) mit
Anwendungen in Assembler zu arbeiten und weniger mit C selbst.
Und da kommen mir gewissen Ansätze in C++ als schwierig in Assembler
zu behandeln vor. Wenn ich ueberlege, wie ich in Asm irgendwelche
vererbte Fensterklassenfunktionen auf meine Anwendung portieren muss,
krieg ich schon das Grauen Ne einfache Funktion
"Interrupt xy, AX = height, BX = width, CX = typ" wäre da schon viel
einfacher zu handhaben, aber ich glaube, das wird eh nicht passieren.

Ihr schreibt, dass man C++ als "extern C" deklarieren kann und das
damit also wieder auf C beschränkt...kA wie das is, macht auf mich einen
weniger vertrauenswuerdigen Eindruck.

Bereits geregelt... zum größten Teil.

Hm. Gut.

[DDR-RAM]

Also die meisten, also eigentlich fast alle, können beides, jedenfalls geben die meisten das in dem "Lagebesprechung"-Thread an.

Softwareinterrupts sind ja in den meisten Fällen eh Funktionsaufrufen ähnlich.
Da der Kernel sehr micro sein wird, kann jeder der Lust hat, ein Modul bauen, um Unix/Windows-interrupts zu mappen, evtl. wird es auch noch ein weiteres geben, welches unseren kernel nativer unterstützt, dann wären sachen wie

Code: [Auswählen]


mov eax, funktionsnummer
mov ecx, fensterpointer
mov ebx, höhe
mov edx, breite
int 0XYh


extern "C" kann nur für Funktionen und Variablen verwendet werden, die keine Memberfunktionen sind und auch nicht für Klassen.
Es geht dabei nur darum, das für C++ jeder Compiler ein anderes Namensdekorationsschema verwendet, für C hingegen ist es einheitlich, es wird immer ein Unterstrich hinzugefügt, Beispiel:

Code: [Auswählen]

void foo(); // ?foo@@YAXXZ

Code: [Auswählen]

extern "C" void foo(); // _foo

foo wird also vom MS VC++ 2003 so dekoriert, bei einem anderen Compilier wird es wahrscheinlich anders sein. mit C-Linkage haben alle Funktionen den gleichen namen. Für mit extern "C" deklarierte Funktionen gilt allerdings das man sie nicht überladen kann.

aber ich bin recht optimistisch, wenn mir endlich mal einer erklärt, wie die Treiber die Funktionen finden sollen.

MfG
DDR-RAM

[Another Stupid Coder]

GCC unter Linux fügt in der Regel keinen Unterstrich vorne hinzu...

[DDR-RAM]

Bist du dir sicher?
Du weißt, wie du dir die dekorierten Namen angucken kannst?
Also, wenn du mich eines besseren belehrst ok, ich hab mit Linux nicht so viel am Hut.

[Another Stupid Coder]

Ich weiß es...von dem extern zeugs und so mit asm und so...ach glaubs mir einfach

[Legend]

GCC unter Linux fügt in der Regel keinen Unterstrich vorne hinzu...

Jop, aber unter Windows tut er es, zur Info, falls es wichtig werden sollte! Gibt aber nen Kommandozeilenparameter das zu ändern.

[Svenska]

Ich halt mich also zurueck, bis mir jemand von euch dann ein Interface
gibt, in dem ich mit Asm oder so rumpfuschen kann
(Ich werde eh alles in (V)Basic prggen und dann portieren...)

Svenska