Lowlevel
Lowlevel => tyndur => Thema gestartet von: DDR-RAM am 08. May 2005, 13:09
-
Hi,
damit ihr gleich meine Meinung kennt, ich wäre dafür alles in C++ zu machen. Es gibt nur sehr wenige Funktionen, die C kann, aber C++ nicht.
C++ verfügt aber über Sprachmittel, die C nicht kennt, wichtigste ist wohl Klassen und das diese Funktionen usw. haben, na ihr kannt das ja ;)
MfG
DDR-RAM
-
C++ wird zu fett und gibt durch die abstrakten teile zu wenig Kontrolle über den eigentlich produzierten Code, zudem ist es umständlicher C++ mit ASM zu mixen als C mit ASM...
ich bin eindeutig für C im Kernel. Über eine C++-API für Userland-Programme lässt sich aber reden ;)
-
der kernel an sich sollte wirklich C sein, C++ würd ich aber (vorallem wegen der Klassen) durchaus für die GUI verwenden, da is das ganze sinnvoll
-
Nya, so wie die Pläne jetzt stehen, kommt die GUI doch in den Kernel.
-
Arrrgh, welche Diskusion hab ich verpasst? Grafik im Kernel ist ok, aber die GUI sollte ganz klar extra sein (wer will schon wegen nem kleinen bugfix den ganzen Kernel neu compilieren?)
-
Ganz meine Meinung...aber ich wüsste nicht, warum VESA sonst fix im Kernel sein sollte ;D
-
Also ich bin dafür, dass der grobe Kernel in C++ ist.
Die anderen sollen den Code ja auch verstehen können.
Ansonsten würde ich nur Assembler nehmen, aber C auf keinen Fall.
-
O_O Was ist an C unverständlich? :D
-
C finde ich beste Wahl.
Um C++ komplett nutzen zu können ist einiges an Vorarbeit notwendig was unnötig wäre das extra in den Kernel zu packen.
C alleine produziert zudem auch kleineren und schnelleren Code was für den Kernel ja sehr sinnvoll ist.
-
C finde ich beste Wahl.
Um C++ komplett nutzen zu können ist einiges an Vorarbeit notwendig was unnötig wäre das extra in den Kernel zu packen.
C alleine produziert zudem auch kleineren und schnelleren Code was für den Kernel ja sehr sinnvoll ist.
new/delete ist schnell gebastelt ;-), ist ja nicht viel anders, wie malloc/free, wenn es ans exception-handling geht, dann ist tatsächlich Vorarbeit nötig. Man könnte es aber weglassen, wenn man es nicht will, allerdings hab ich es bis jetzt immer mit reingenommen, da damit leicht Möglichkeit, Fehler zu korrigieren oder Fehlermeldungen auszugeben.
RTTI würde ich im Kernel nicht verwenden, weil ich den Code net kenne. Mehrfachvererbung auch nicht, vor allem nicht von Interfaces.
Templates sind wahrscheinlich auch unnütz.
Operatorüberladung auch, aber ich würde sie nicht ausschließen wollen,
z.B. new/delete-Opeartor, evtl. Vergleichsoperatoren.
Wenn man auch Exception-Handling rauslässt,
hat man nen recht schlankes C++, das mit nem gutem Compiler garantiert nicht langsamer bzw. größer als entsprechendes C ist!
virtuelle Memberfunktionen würde ich Übrigens auch nicht ausschließen,
sie können enorm zur Abstraktion beitragen, was für den Kernel ja sehr sinnvoll ist ;-)
Wie berät sich eigentlich das Coreteam? Über PN's oder wohnt ihr zusammen? :D
MfG
DDR-RAM
-
Also Operatorüberladung kann ziemlich nützlich sein, speziell bei String. Schnell ne Klasse String erstellt die nur einen char* enthält und dann paar Operatoren überladen schon kann man bequemer Vergleiche machen und braucht das olle strcmp nicht und strcat mit += ist auch recht praktisch.
Du hast Exceptionhandling für den kernel? kannste mir per PN mal verraten wie das funzt habe da keine Idee zu thx^^
Man kann mit C++ sogar kleineren Code erzeugen^^ ich habs jez so^^ Mischung aus C/C++ Code ist kleiner geworden um ca 2kb nur durchs umsetzten. Und Geschwindigkeitsmässig hat sich meiner Meinung nach wenig verändert
Naja und beraten tun wir uns über ICQ ganz einfach^^
-
Bloß mit C++ arbeiten zu _wollen_ reicht auch nicht. Wer traut sich es zu durchzuplanen welche Klassen es gibt, welche Hierarchien es geben soll, etc.? Wenn man ein richtiges C++-Projekt nicht durchplant, kann man die Möglichkeiten von C++ gar nicht ausschöpfen, sondern hat nur Flickwerk. Ist da ein relativ offenes Modell in C nicht sinnvoller und einfacher?
Ein Projekt mit einem gewissen Einsatz von C++ wird zwangläufig abstrakt. Wenn aber der Kernel zu abstrakt wird, wird alles extrem unübersichtlich und dann kann davon auch keiner mehr was lernen. (Es soll doch noch eine art "Lern-OS" werden, oder?)
Also eine String Klasse gehört auf keinen Fall in einen Kernel. Vor allem nicht in einen Mikrokernel. Im Kernel muss außer für Fehlermeldungen fast gar nicht mit Zeichenketten gearbeitet werden. Und Fehlermeldungen sind const char*'s ...
-
Der Kernel wird in C geschrieben werden. Die Leute, mit denen ich gesprochen habe, waren alle dafür, einen Microkernel zu schreiben. C++ im Microkernel ist IMHO Unsinn.
Die GUI (die übrigens NICHT Teil des Kernels wird) oder auch andere Teile des OSes können, wenn der Wunsch besteht, in C++ geschrieben werden.
-
Exakt meine Meinung, mastermesh :)
-
Der Kernel wird in C geschrieben werden. Die Leute, mit denen ich gesprochen habe, waren alle dafür, einen Microkernel zu schreiben. C++ im Microkernel ist IMHO Unsinn.
Meines Erachtens ist C++ im Microkernel überhaupt kein Unsinn.
Eventuell könnte man sich in der Mitte treffen und einige Sprachmittel von C++ nicht im Microkernel verwenden.
Ich sehe keine Vorteile von C gegenüber C++ (bin ich blind?).
MfG
DDR-RAM
-
C++ hat auf jedenfall einige Nachteile:
- Overhead mit new/delete, Exceptions, etc ... (ok ist relativ gering)
- Treiberprogrammierer werden dann auch dazu gezwungen ihre Treiber in C++ zu schreiben. Ein Interface von C++ nach C ist wesentlich komplizierter als von C nach C++.
- Bei der Treiberprogrammierung kommen dazu noch üble Probleme bei der Kompatibilität (C-Funktionen können einheitlich exportiert/importiert werden, bei Klassen kocht hingegen jeder Compiler sein eigenes Süppchen). Die Treiberprogrammierer werden also auf den GCC festgenagelt.
- C++ bringt keinen Vorteil bei der Programmierung von Hardware. Hardware ist darauf ausgelegt von einem Assembler- oder C-Programm (oder einer anderen Prozeduralen Programmiersprache) bearbeitet zu werden. Also nicht Objektorientiert oder ähnliches. Große Teile der Kernels werden einfach aussehen wie C-Code.
-
Was ich finde ist folgendes: C++ war immer nur als ERWEITERUNG zu C gedacht und so sollte es auch verwendet werden.
new und delete bringen GARKEINEN overhead wenn mans richtig macht.
Exceptions sind im Kernel ja an sich auch garnicht nötig.(Wenn der Kernel schon Fehlerstrotzend angelegt ist kann ja auch nix werden)
Andere Entwickler werden zu nichts gezwungen, die Treiber werden ja extra compiliert und dazugelinkt. Und man kann dem C++ Compiler auch sagen die Namen (in Klassen und vor Überladenes gehts natürlich nicht) nicht zu verunstalten indem man -extern "C"- davorsetzt
Die Hardware ist auf nichts anderes ausgelegt als vom Prozessor angesteuert zu werden und das geht nur über Maschinencode, ergo Assembler. Zeige mir ne Hardware die man mit C ansteuert, rofl.
Keine der beiden Sprachen hat vor oder Nachteile gegenüber der anderen. Mit entsprechender Arbeit kann jede die andere ersetzten. Man kann auch OOP mit C machen auch wenn das umständlich und komisch wird. Aber andersrum gibts genauso Dinge.
es ist absolut geschmackssache
BTW: informiert euch mal was ne Programmiersprache eigentlich ist;)
-
C++ hat auf jedenfall einige Nachteile:
- Overhead mit new/delete, Exceptions, etc ... (ok ist relativ gering)
der Overhead von new/delete geht ganz stark gegen 0.
EH hingegen ist zugegebener Maßen groß, ich würde auch nicht drauf bestehen. Aber was passiert eigentlich, wenn ein Treiber (also anderes Modul) eine Zugriffsverletzung "macht" ?
- Treiberprogrammierer werden dann auch dazu gezwungen ihre Treiber in C++ zu schreiben. Ein Interface von C++ nach C ist wesentlich komplizierter als von C nach C++.
Es ist schon klar, das man nem C++-Treiber ein C-Interface anbieten kann, aber nicht umgekehrt. Aber das es sehr kompliziert ist, ein C-Interface zu bauen, das intern auf C++ setzt, halte ich für naja sehr übertrieben. ;-)
- Bei der Treiberprogrammierung kommen dazu noch üble Probleme bei der Kompatibilität (C-Funktionen können einheitlich exportiert/importiert werden, bei Klassen kocht hingegen jeder Compiler sein eigenes Süppchen). Die Treiberprogrammierer werden also auf den GCC festgenagelt.
Verstehe ich nicht recht, die Treiber gehören doch nicht zum Mircokernel?
Werden also auch nicht mit denen zusammen kompiliert, bzw. gelinkt.
Wie wird überhaupt realisiert, das andere Module/Treiber auf den Microkernel zugreifen können? Sie müssen ja die Adressen kennen, also braucht man ne Art .LIB-Datei? Vielleicht hast du ja recht, aber ich will es erstnoch mal genau wissen. :roll:
Aber festgenagelt werden sie aber auf jedenfall nicht, wenn sie kein C verwenden, denn das C-Interface wird mit extern "C" deklariert.
- C++ bringt keinen Vorteil bei der Programmierung von Hardware. Hardware ist darauf ausgelegt von einem Assembler- oder C-Programm (oder einer anderen Prozeduralen Programmiersprache) bearbeitet zu werden. Also nicht Objektorientiert oder ähnliches. Große Teile der Kernels werden einfach aussehen wie C-Code.
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.
MfG
DDR-RAM
edit:
da war einer bisschen schneller als ich :oops:
-
Wenn ihr euch jetzt ne hitzige Diskussion liefert, was denn nun besser
sein soll, fällt das ganze Projekt mehr oder weniger ins Wasser.
Besinnt euch mal aufs Magazin zurueck...
Ich kann keine der beiden Sprachen, also auch nicht recht mitreden. Vom
Beginn war C geplant, jetzt soll es Cpp werden, mir ist es recht egal. Ich
komme dann später, wenn der Kernel eine Art Anwendungsumgebung
liefert. Und wie es scheint, kann das noch dauern...
C kam als Kernelsprache ins Gerede, weil es ein Lern-OS werden sollte,
kein grosses Etwas. Assembler war in dem Moment nämlich einfach zu
kompliziert. Besinnt euch mal ein bisschen auf die Urspruenge zurueck.
Es wird nämlich ganz sicher nichts, wenn jedes bisschen Planung wieder
umgeworfen wird. Aber das ist ein Nachteil der Demokratie, da irgendwie
keiner die Krone auf und das Zepter in der Hand hat.
Mein Machtwort und den Rest regelt ihr.
Svenska
-
Mein Machtwort und den Rest regelt ihr.
Bereits geregelt... zum größten Teil.
-
Also ich persönlich bin ja für puren ASM, das is doch einfach spannender als müslifresserC ;)
-
oder gleich die opcodes alle per hexeditor eintippen ^^
ich denke C ist die beste wahl, ist einfach, gut verständlich
und nicht grad langsam
-
ASM hat Vorteile, aber man muss 100% selbst optimieren.
Aber der Lerneffekt geht dabei verloren.
-
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
-
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 ;)
-
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 :D
-
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 :D 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:
//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:
// 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 :oops:
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
-
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 :D
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 ;)
-
Ich bin ja immernoch für ASM :D
-
du hardcore progger :lol:
-
Wie wäre es mit Fortran? Oder Ada? >D
-
nein JAVASCRIPT .NET^^
-
Brainfuck
-
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.
-
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
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:
void foo(); // ?foo@@YAXXZextern "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
-
GCC unter Linux fügt in der Regel keinen Unterstrich vorne hinzu...
-
Bist du dir sicher?
Du weißt, wie du dir die dekorierten Namen angucken kannst? :roll:
Also, wenn du mich eines besseren belehrst ok, ich hab mit Linux nicht so viel am Hut.
-
Ich weiß es...von dem extern zeugs und so mit asm und so...ach glaubs mir einfach ;D
-
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. ;)
-
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
-
Also ich weiß bicht warum ihr euch alle darüber streitet.
C und C++ sind einander sehr ähnlich und wenn man eine Programmiersprache kann, versteht man die andere z. T. auch.
Nur bei den Spezialdingen können dann Probleme auftreten, aber das ist ja nicht wichtig.
-
Diese "Spezialdinger" nennt man C++.
-
Wenn man C++ richtig verwenden will, muss sich schon eine andere Denkweise angewöhnen. Denn das Objektorientierte Programmieren unterscheidet sich doch sehr vom Prozeduralen. Auch OOP ist zwar im Letzten prozedural, aber die vorhergehenden Schritte sind anders.
Z.B. ist new kein reiner Ersatz zu malloc() denn new ruft die eventuellen Konstruktoren mit auf was malloc() nicht tut. Gleiches gilt für delete.
Wer C kann wird von C++ erstmal verwirrt werden. Und wer erst C++ gelernt hat wird sich in C kaum zurechtfinden, schlicht weil ihm einige Sprachmittel fehlen.
-
Also ich hab C++ gelernt, und ich glaub schon, dass ich auch C verstehen könnte.
Aber wenns du aus Erfahrung weisst...
Naja, wenn das so ist, sollten wir eine Umfrage dazu machen, was die Mehrheit kann.
-
Verstehen sicher aber wer NUR C++ gelernt hat und dann auf einmal plain C machen soll kommt kaum zurecht, ohne Klassen, Konstruktoren und das ganze^^ Die Arbeit die die einem abnehmen ist schon nicht grade wenig. Man kann schliesslich mit einer Zeile im Desktruktor eine ganzen Klassenverkettung auflösen.
-
Verstehen sicher aber wer NUR C++ gelernt hat und dann auf einmal plain C machen soll kommt kaum zurecht, ohne Klassen, Konstruktoren und das ganze^^ Die Arbeit die die einem abnehmen ist schon nicht grade wenig. Man kann schliesslich mit einer Zeile im Desktruktor eine ganzen Klassenverkettung auflösen.
ich komme von "basic" kann trotzdem c++, aber wie du weisst bin ich mir oft nicht ganz sicher ob das c++ is ;)
Aber ich kann mir gut vorstellen das es eine weile dauert bis man unterscheiden kann was was is... ich hab manchmal immer noch mühe! Basic ifs und c++ sind vollkommend andes :( und diese {} verwirrend mich manchmal auch...
-
Ich meins aber gerade andersrum von einer OOP language auf eine Prozedurale sprache;)