C or C++ ?
Moderator: Moderator Team
C or C++ ?
If you were to help with the development of this project, does it need to be in C, or is C++ also accepted?
I disagree, I think if your used to C++ and using the alternative power it gives via objects, different syntax, with a totaly different library than C uses, it's difficult to use C in an effective and safe manor.Administrator wrote:If you know C++ it isn't hard to program in C. If you want to contribute to the OS components you have to program in C, but you can help e.g. with the Explorer which is programmed in C++.
I deffiently want to get involved in this project I just need to free up some time. I only stumbled across it last week due to a review in Linux Format.
I have no doubt they will. After all, Linux and Windows are written in C.
I wasn't aware that C was faster than C++ though. As long as you don't delve into complex objects and code at the same level as you do in C, would they not be the same speed?
Anyway, I just meant a C++ programmer reverting to C may be more difficult than it sounds and could lead to some sloppy and insecure code.
Best to leave the OS components to the C experts. My question has been answered
I wasn't aware that C was faster than C++ though. As long as you don't delve into complex objects and code at the same level as you do in C, would they not be the same speed?
Anyway, I just meant a C++ programmer reverting to C may be more difficult than it sounds and could lead to some sloppy and insecure code.
Best to leave the OS components to the C experts. My question has been answered
I don't think newer compilers produce bigger executables. Maybe another linker is used with your new compiler? I made the experience that the size of your executable also depends on which linker you choose.bubach wrote:no, c++ produces bigger programs, the same way that newer c compilers produce bigger programs then older ones (even though it´s the same code).
this is my own expiriences, but i don´t know excatly why..
There are few things that influence the resulting code size - including debugging info, optimizing for speed rather than for size, linking type (compare Windows binaries created by GCC with the same program compiled with MSVC).
C++ programms are slower and bigger, but only because of the overhead of things that C doesn't have - support for object oriented and generic programming. If you don't use these techniques (which means no classes, ingeritance, polymorphism, strings, vectors, iostreams, etc.) the resulting code will be most probably as small and fast as if you'd compile it with a C compiler.
C++ programms are slower and bigger, but only because of the overhead of things that C doesn't have - support for object oriented and generic programming. If you don't use these techniques (which means no classes, ingeritance, polymorphism, strings, vectors, iostreams, etc.) the resulting code will be most probably as small and fast as if you'd compile it with a C compiler.
Just a word of warning about C++ from g++
gcc 3.4.2 is verry strict on types and other missmatches in g++. A common problem I have had building the explorer section.
Note microsoft complier and gcc 3.3.3 are less strict.
Just like some C code will not build on current gcc because it was not updated. This is normally missing ; that were not required by older versions.
If it can be done in C it would be a good idea. Note somethings are just to complex to work on build in C then use C++. Ie the more C++ used more trouble with compliers due to difference it what you can and cannot get away with.
C++ programms are slower and bigger. Watch you flags I really do mean read the flags that g++ has if you are not using polymorphism and some other sections like exceptions these can be removed improving size a lot.
Note microsoft complier and gcc 3.3.3 are less strict.
Just like some C code will not build on current gcc because it was not updated. This is normally missing ; that were not required by older versions.
If it can be done in C it would be a good idea. Note somethings are just to complex to work on build in C then use C++. Ie the more C++ used more trouble with compliers due to difference it what you can and cannot get away with.
C++ programms are slower and bigger. Watch you flags I really do mean read the flags that g++ has if you are not using polymorphism and some other sections like exceptions these can be removed improving size a lot.
C programs tend to be smaller and more efficient because you're writing code at a lower level. With C++, there's a lot more genericism (that's a word, ain't it? ) in common functions, plus there's the issue of breaking down OOP to procedural code...more genericism, thus more code, thus larger and slower executables. Core OS components and procedures should never be written in C++ unless you're targetting only mid- to high-end computers. Another issue is runtime scripting...keep this crap out of an OS. Look at the speed hit XP takes because of it.
If you really want to squeeze the last ounce of performance and size out of this, do things in assembly. There you have the potential for much smaller and faster components and applications.
If you really want to squeeze the last ounce of performance and size out of this, do things in assembly. There you have the potential for much smaller and faster components and applications.
Life is too short for bad pasta.
Do that an AI would shoot you dead. I think FreeLoader just got coverted to C code. The only one I really know who does ASM is Gibson, but his are all closed-src, so I don't know how maintainable they are.nodtveidt wrote:If you really want to squeeze the last ounce of performance and size out of this, do things in assembly. There you have the potential for much smaller and faster components and applications.
-uniQ
Coming on, coming up, let me help ROS and I'll be able to look @ a life well used.
If I remeber and got it right C++ progs are bigger and slower because of OO overhead for example:
-Every time you call non static object method, normally invsible pointer to object instance (self, this or what) is passed to method, so it knows where in memory it has to find current objects variables, making every call bigger for address size (DWORD) and thus slower. Bigger stack usage.
- Every time you create or destroy object, special rtlib functions responsible for object base memory allocation/deallocation and initialisation/deinitialization are called (they are responsible for calling your contsructors/destructors).
- If you use virtual classes there is one level of inderection in accesing anything in your class because of object's vtables.
From this it is visible that many objects methotds called one from inside another (standard c++ behavior) are filling up stack more quickly and communication overhead makes whole program slower.
I hope I'm not talking bullshit .
-Every time you call non static object method, normally invsible pointer to object instance (self, this or what) is passed to method, so it knows where in memory it has to find current objects variables, making every call bigger for address size (DWORD) and thus slower. Bigger stack usage.
- Every time you create or destroy object, special rtlib functions responsible for object base memory allocation/deallocation and initialisation/deinitialization are called (they are responsible for calling your contsructors/destructors).
- If you use virtual classes there is one level of inderection in accesing anything in your class because of object's vtables.
From this it is visible that many objects methotds called one from inside another (standard c++ behavior) are filling up stack more quickly and communication overhead makes whole program slower.
I hope I'm not talking bullshit .
Etko You are so close its not funny.
C++ program and a C program can have almost the same speed and size.
There is a catch.
Size of C++ programs under windows are bloated by G++. Linux G++ has a dynamic lib but the windows is using a static lib this effect peformance badly. Each program has to load its own runtime enviroment(Yes C++ has a runtime enviroment the rtti all the stuff in libstdc++). A dll of libstdc++ would improve the state of c++ inside reactos.
Disable the rtti lots of features of C++ disappear. Class remain but lots of the nice stuff is gone. Exception handling one of the best features of C++ is gone.
OO can be done in C this does come with a overhead but nowhere near as bad as double loading the rtti of C++.
The libstdc++ of C++ does a alot memory tracking exception handling... and so on this makes it a big over head when its not shared.
If we were using a microsoft complier on a microsoft plateform the over head would not be as bad. Lots of tricks are used by there complier to avoid this problem.
I am hoping that the versions after Gcc 4.0.0 and on will get the runtime problem of C++ and Gcc sorted out for on static platforms size problem.(strange as it seams but G++ on windows is a static lib version of libstdc++)
There is a catch.
Size of C++ programs under windows are bloated by G++. Linux G++ has a dynamic lib but the windows is using a static lib this effect peformance badly. Each program has to load its own runtime enviroment(Yes C++ has a runtime enviroment the rtti all the stuff in libstdc++). A dll of libstdc++ would improve the state of c++ inside reactos.
Disable the rtti lots of features of C++ disappear. Class remain but lots of the nice stuff is gone. Exception handling one of the best features of C++ is gone.
OO can be done in C this does come with a overhead but nowhere near as bad as double loading the rtti of C++.
The libstdc++ of C++ does a alot memory tracking exception handling... and so on this makes it a big over head when its not shared.
If we were using a microsoft complier on a microsoft plateform the over head would not be as bad. Lots of tricks are used by there complier to avoid this problem.
I am hoping that the versions after Gcc 4.0.0 and on will get the runtime problem of C++ and Gcc sorted out for on static platforms size problem.(strange as it seams but G++ on windows is a static lib version of libstdc++)
Who is online
Users browsing this forum: Ahrefs [Bot] and 11 guests