C or C++ ?

All development related issues welcome

Moderator: Moderator Team

Posts: 1
Joined: Wed Nov 02, 2005 2:46 am

Post by DamnedFreak »

So, if I, as a guy who is interested in coding some apps for reactOS, should write C code, right?

Posts: 499
Joined: Mon Nov 22, 2004 10:50 pm
Location: The Netherlands

Post by GvG »

C is the preferred language. If you have a strong argument to use C++, that's acceptable too.

Posts: 4
Joined: Sat Dec 10, 2005 8:34 pm

Post by Wiseman »

I'm not a ReactOS developer (will consider contributing to it in the future after I'm done with another project), but I want to drop a few lines. Assume IMO on everything.

Object-oriented programming is vastly overrated, it's like The Emperor's New Clothes, fueled by the "industry" (read: cheap PC magazine columnists and business managers who read these columns and have no idea of the real thing).

Applied to everything, OO only makes things worse. It tends to make things more complicated (and therefore slower to develop and harder to maintain), and, contrary to popular belief, it requires a better understanding of the existing interfaces for you to use them, as you have to deal with a class hierarchy and inheritance. Contrary to popular belief, it ends up taking more work and lines than proper structured programming. And contrary to popular belief, OO takes a step back towards spaghetti code, as not only you're calling functions (methods) here and there, but you don't even know where's the method you're calling and which class does it actually belong. It goes against the KISS principle. And once again contary to popular belief, it's significantly slower than traditional programming. Syntactically, I don't see any advantages of element.doMyStuff(lol) versus DoMyStuff(element, lol). And feature-wise, don't be fooled: function and operator overloading, garbage collection, namespaces, etc. are not features of OO programming. They are just features, and they may be and are available for other paradigms. Check lcc-win32 out, for example. It's a C++-- compiler, offering the subset of C++ many "C++ programmers" end up using.

I think different paradigms apply to different problems. Consider the following:

A) Calling a trigonometric function
B) Closing a window in a high-level toolkit
C) Comparing two items

A) Let's ignore the fact "trigonometric function" already suggests us what to do. Consider sin(x), Math.sin(x), and, uh, sin x. Obviously, the most elegant, straightforward, KISS approach is to make this a function.

B) Now we have a window wnd and we want to close it. We could either WindowClose(wnd), wnd.Close(), or uh... wnd << WND_CLOSE? Whatever. GUI elements tend to be easily identifiable as objects and they tend to follow a hierarchy. It makes sense to use OO here.

C) And finally, we'll compare two items, a and b. We could do ItemCompare(a, b), which is bearable, albeit impractical; a.CompareTo(b) is just plain ugly and makes no sense as comparison is a symmetric operation applied to two equal objects, not a method of only one; and a == b is just common sense.

I think it's a mistake to try to make everything OO as the "industry" is doing when many problems are inherently not object-oriented. It's a matter of the right tool for the right job. That's why C++, equipped with a garbage collector, seems to be a decent approach, offering you both paradigms and several interesting (albeit, admittedly dangerous) language features.

In the case of an operating system and its APIs, I see little to no reason to use OO, maybe except for the GUI (yet Windows' API is not OO so that's out of the question). Therefore, if I get involved with the ReactOS project in the future, I'll prefer using plain C, using as many language extensions as desired by the project leaders.

Posts: 1
Joined: Fri Jan 13, 2006 1:30 pm

Post by Badturnip »

First, sorry for my english.

I think it's OK to use a subset of C++ to write operating systems leaving alone the garbage collecting.The mechanism of virtual function and object heritage will make us much easier to program. I've being writing a kernel in C++(excluding exception) for a long time. I feel it's much more elegant then using C.

Yes, C++ is a complicated language that almost no one will use all of it's features.But using a subset of C++ including class, object heritage, virtual function and a little template will be much more easier to design and write code. Imagine that you havn't to deal with string buffer overflows and use ugly function pointers to implement virtual functions even you can use your own containers and powerful C++ libraries.

Meanwhile, using a subset of C++ will not cut down the performance if you do not use exception handing. It's just like plain C plus classing and virtual function.

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

Post by oiaohm »

Their is a Critical Reason why C++ is normal not allowed in kernels.

Its called mangling. Most C++ compliers have different mangling. Ie GCC, Watcom, MSVC and Borland have different mangling. Even some GCC has different mangling between versions. No simple mixing.

With C code mixing between compliers is simpler. Function calls are the same. Ie C has a written standard for function calls C++ does not.

If you want C++ like features you are better to learn how to use C.

C is a extreamly powerful lang the argument over the same thing happened in the Linux kernel forum. It turned out that the C++ solutions were messy and slower than the C solutions. It was solved by a solution vs solution fight.

Don't forget GCC version of C allows functions inside functions. This opens up even more C doors in c.

Posts: 18
Joined: Thu Jun 16, 2005 8:58 pm
Location: Johannesburg, South Africa

Post by grigi »

C++ only makes sense for app types where oo fits, and to my expierience it is for GUI Widgets , and mathematical applications (using overloaded class types).

Also if you code in C++ templates make the code extremely difficult to read.

Another thing of C++ that I like is that you could use a class for a mutex, which then allocates the mutex on constructor and releases on destructor, therefore to get a mutex safley and release you need to do the following:

Code: Select all

// MT code
    // Subscope for mutex
    mutex lock(IO_LOCK_3);

    // Insert mutex requiring code here
// MT code
This is a very neat way of writing code that require mutexes and difficult to forget something as the destructor and the scope ensures.

Andother thing to code in C++ is to remember to add the word const to everything you can.

This allows the compiler to optimize considerably more, In one case using vector maths for a ray-tracer, but just using const averywhere it ran about two-and-a-half times faster!!!
The executable was also notably smaller

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

Post by oiaohm »

C++ can get Mulex safley. Due to destructor.

If that is all you want C++ for you are better to go ObjC under gcc.

Reason no runtime and no risk of a runtime being linked in.

All so it lets programmer forget to unallocate Mulex. This is a problem
MT {
mulex lock(whatever);
code requiring mulex
code not requiring mulex
} Released here.

Better would be if some one added a tool to C to track mulex allocations and deallocation in source and worked out if they were un even. Ie a unrequired release or a never released lock.

Ie Each mulex lock should have a mulex release.

Programmer inserting the release normally get it better placed.

Now depending on the C++ complier. A mulex done threw class more often than not is slower than a direct C call. If luckly the same speed as a C call. The overhead of the release check at end of code takes away the advantage.

const has a very big effect on the size of C and C++. Note it depends on the complier. Some compilers you can make the code slower and larger by over using const. Defect const int c = 0 somewhere else in code const int b =0. Some compliers will not merge them due to be const. Ie each const has to have a const pointer as well that only own it. How some C and C++ compliers take the rules.

It a defect you have to be aware of. Does not always cause problems.

Depending on the compiler it will either make it smaller and faster or larger and slower.

Some of the tools that defect buffer overflow can be altered to detect mulex not being released.

C++ advantages can be killed by speed loss.

Posts: 18
Joined: Thu Jun 16, 2005 8:58 pm
Location: Johannesburg, South Africa

Post by grigi »

For C++:

The issue isn't the speed of C/C++ , and trust me, good C++ code is probably at most 2% slower in extreme situations.
And for user-space apps it is fine.

I agree C++ should be kept out of the kernel.

I merely state that C++ has ONLY 2 strong points, and that is math readability (written properly the asm it generates is EXTREMELY good, gcc 3.4 specifically) and widgets (GUI's).

The reason I would rather code in C++ for user space apps, is because it has some features to cut development time a little, and cut debugging time quite a lot, therefore less buggy apps. I would gladly sacrifice 2% performance for 40% faster development time, for non-critical & common userspace apps.

And the executable size is not that much bigger, MinGW specifically only seems to parse C files faster than C++, but if rename a C file to a C++ file, the generated code is IDENTICAL.

For C:

As I said, the biggest problem with C++ is that it compiles ~4 times slower than C.

C is MUCH better for IO & logging.

Most of my C/C++ applications is written in C-style, as C++ templates are unreadable, and the ONLY time I would use templates, is when there is a defnite speed advantage of explointg the macro-like abilities of templates.

C++ STL library is completely overkill, it is too powerfull, leading to some really unreadable and mystic code.

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

Post by oiaohm »

Mingws complier is a little smart but can be completly dumb as well.

#include <iostream>
At the start of a C file. It will then attach the runtime. Unless you flag it not to. Ie it get smart. File does not have C++ code its a C file with the wrong tail. This also makes C processing in g++ complier slow. It gets processed twice. 4.0.2 fixs this it only gets processed one. Mingw does not support this yet.

Mingw libstdc++ Needs work. Really needs work.

Many size reductions and improvements in memory overhead could be cause if it became a dll.

Also it currently contatians 32 bit code what I don't completely understand why.

Ok I can understand C++ need in places. As you say coding in C style. I will ask one thing. Make sure that files that should have a .c tail do.

I have done this one applicaiton All cpp files only 2 files contained any CPP code all it was doing is double processing all the way. Simple way to half at least the build time.

The wstring activation is done wrong will submit patch to fix.

Basicly I would like to see the dll address before to much code is C++.

Add a libstdc++ to Reactos that produces a dll reduce side of all C++ files when building with mingw. Also reduce overall memory usage. Speed up loading of C++ programs. Explorer would load libstdc++ into memory.

gcc 4.1 parse C files a lot faster great when it gets out. g++ about 8 times slower in compile in the test version even so the g++ is still faster than the current.

C++ STL in the right hands is a great tool. In the wrong hands a nightmare.

Posts: 18
Joined: Thu Jun 16, 2005 8:58 pm
Location: Johannesburg, South Africa

Post by grigi »

Yes, I agree, more dll-ing of core functionality would be cool.

I don;t quite understand why you need to link in libstdc++ if you disable exceptions and RTTI?

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

Post by oiaohm »

Disable RTTI and exceptions will stop it linking in most cases on a pure C display and own internal classes application.

Reason why libstdc++ would be linked are many. wstring,string, cout and cin also comes form libstdc++ ie basicly use any C++ standard classes or functions it will be linked. These class used right make things alot simpler.

Ok only way so it does not link in is to use all C code with own classes. Then it so close to C that it might as well be done in C. There are ways of doing oop programming in C that provide almost equal function to classes. Gtk widgets for a example.

libstdc++ contains alot more than RTTI and exceptions.

You start using nice C++ features verry quickly you need alot of libstdc++.

Note I am a C programmer at heart. Currently altering the libstdc++ of mingw so the wide char supporting features all work. This makes cross portings a little simpler.

Current overheads of mingw G++ is that each program contains its own version of libstdc++ or parts of libstdc++ depending on what it uses so it slower to load bigger file more it has it load into memory. Bigger memory foot print ie less programs before running out of ram. More memory used slow machine runs. Ie slower a lot slower. It's a effect of the current mingw that needs to be fixed.

Speed difference between c programs and c++ programs on linux is no where near as great. Main cause no libstdc++ dll on windows when linux has a so file(linux equal to a dll). Guess what on the people who like msvs it has a dll for the core of its std c++ due to difference between gcc and msvs it cannot use that dll. It makes a big difference.

First target fix the problems. Secound target think about applications.
Third target look at C OOP and work out if C++ or C OOP fits better. ObjC was invented to make C OOP programming simpler. C++ gives you Namespaces.

It all depends on what you are doing. In alot of cases C OOP programming beats C++ if you are not using the libstdc++.

http://extc.sourceforge.net/ Is a short cut to C OOP. Direct C OOP is more complex not normally ready for a new person to handle. extc will allow you to see basicly what it can do. Even that it still need work to trustable and clean.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest