C or C++ ?

All development related issues welcome

Moderator: Moderator Team

Gedi

C or C++ ?

Post by Gedi »

If you were to help with the development of this project, does it need to be in C, or is C++ also accepted?

terrance
Site Admin
Posts: 70
Joined: Mon Nov 22, 2004 9:52 pm
Location: Switzerland

Post by terrance »

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++.

w3seek
Developer
Posts: 144
Joined: Tue Nov 23, 2004 12:12 am

Post by w3seek »

we very much appreciate C code, c++ is currently used for explorer and one or two other very small things, but we prefer C a lot more (also because gcc is much faster than g++ :lol: )

Gedi

Post by Gedi »

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 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.


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.

Delfi
Posts: 76
Joined: Sat Nov 27, 2004 8:45 pm

Post by Delfi »

use C, it is faster and reactos needs to be faster than winnt 4.

seibertjd
Posts: 3
Joined: Thu Dec 02, 2004 8:05 pm

Post by seibertjd »

C++ is very powerful, but until the implementation of C++ is actually needed for some specific reason, C will do just fine. Besides, I'm sure that the ReactOS developers will be able to write all of the security libraries or function libraries they need to make it work how it needs to.

Gedi

Post by Gedi »

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 :)

bubach
Posts: 7
Joined: Wed Dec 01, 2004 3:34 pm

Post by bubach »

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..

NetSlayer
Posts: 36
Joined: Sun Dec 05, 2004 8:55 pm
Contact:

Post by NetSlayer »

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..
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.

stefan
Posts: 29
Joined: Sat Dec 04, 2004 12:22 am
Contact:

Post by stefan »

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.

oiaohm
Posts: 1322
Joined: Sun Dec 12, 2004 8:40 am

Just a word of warning about C++ from g++

Post by oiaohm »

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.

nodtveidt
Posts: 5
Joined: Thu Feb 10, 2005 12:36 am
Location: Isabela, PR
Contact:

Post by nodtveidt »

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? :D ) 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. :D
Life is too short for bad pasta.

uniQ
Posts: 246
Joined: Sat Dec 04, 2004 8:58 am

Post by uniQ »

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. :D
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.

-uniQ
Coming on, coming up, let me help ROS and I'll be able to look @ a life well used.

etko
Posts: 154
Joined: Thu May 26, 2005 3:43 am
Location: Slovakia
Contact:

Post by etko »

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 ;).

oiaohm
Posts: 1322
Joined: Sun Dec 12, 2004 8:40 am

Etko You are so close its not funny.

Post by oiaohm »

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++)

Post Reply

Who is online

Users browsing this forum: Semrush [Bot] and 0 guests