Programming: C

[turb_]

The OSDev Wiki has an interesting article on using C++ in your kernel:

[url]http://wiki.osdev.org/C%2B%2B[/url]

[nullsquared]

[QUOTE=blankthemuffin;22875687]I understand that, but it's another of the 'features' of C++ that especially don't play nice with kernel development. Undefined execution order before the so called entry point? Awesome.
[/quote]
You shouldn't even be using globals in the first place, so it's a very moot point.
[quote]
Once you cut out all these things that you mention, it kinda makes me wonder why you even bother writing your kernel in C++ anyway.[/QUOTE]
OO: classes, RAII, encapsulation, polymorphism, etc.

[gparent]

[QUOTE=nullsquared;22876370]OO: classes, RAII, encapsulation, polymorphism, etc.[/QUOTE]
Which, according to a very popular Kernel writer, doesn't really help when it comes down to device drivers, memory management facilities and things like that.

You should be using C++ when it actually matters, not when you just feel like it. C is very appropriate for the kernel.

[nullsquared]

[QUOTE=gparent;22881206]Kernel writer[/QUOTE]

Oh yeah? Who?

This isn't about "X thinks that C++ isn't useful for kernels," it's about "Y is wrong that C++ can't be used for kernels."

[gparent]

[QUOTE=nullsquared;22882036]Oh yeah? Who?

This isn't about "X thinks that C++ isn't useful for kernels," it's about "Y is wrong that C++ can't be used for kernels."[/QUOTE]
Well I'm aware that everyone will be wrong because you said so, but that really doesn't change my argument.

The Windows, Linux, Solaris, etc. dev teams out there aren't all using C because they feel like it. There are very valid reasons for it.

EDIT: Just noticed the "can't" in your post. It can be used, it's just more of a pain in the ass, and there are no real benefits.

[nullsquared]

[QUOTE=gparent;22882408]The Windows, Linux, Solaris, etc. dev teams out there aren't all using C because they feel like it. There are very valid reasons for it.[/QUOTE]

Of course not; they're using C because they already have extensive codebases using C and they've started many, many years ago.

It's certainly not because C++ features are useless for kernels as you're trying to imply.

[efeX]

[QUOTE=nullsquared;22882036]Oh yeah? Who?

This isn't about "X thinks that C++ isn't useful for kernels," it's about "Y is wrong that C++ can't be used for kernels."[/QUOTE]

Linus, who else? :v:

[st0rmforce]

[QUOTE=nullsquared;22883016]Of course not; they're using C because they already have extensive codebases using C and they've started many, many years ago.

It's certainly not because C++ features are useless for kernels as you're trying to imply.[/QUOTE]
And so if they were to switch to C++ it would seriously piss off thousands of developers, who would also have to switch.

Of course C++ features aren't useless for kernels, I'm sure you could write a very interesting paper about the advantages.

[nullsquared]

[QUOTE=st0rmforce;22883756]And so if they were to switch to C++ it would seriously piss off thousands of developers, who would also have to switch.

Of course C++ features aren't useless for kernels, I'm sure you could write a very interesting paper about the advantages.[/QUOTE]

Well, yeah, that's pretty much what I said :downs:

I was replying to this:

[QUOTE=gparent;22881206]Which, according to a very popular Kernel writer, doesn't really help when it comes down to device drivers, memory management facilities and things like that.

You should be using C++ when it actually matters, not when you just feel like it. C is very appropriate for the kernel.[/QUOTE]

[gparent]

[QUOTE=nullsquared;22883016]It's certainly not because C++ features are useless for kernels as you're trying to imply.[/QUOTE]

I'm not saying they're useless, I'm saying they aren't beneficial. Now maybe that's just me having bad grammar, so sorry if that is the case, but I see a difference between the two.

I'm sure C++ features would have a use, but I don't think it would be worth it to have to deal with C++ to reap those little benefits there and there. Function overloading isn't that big of a deal, classes aren't that big of a deal (especially in a kernel), and polymorphism, while nice, isn't really something I see as a big plus in a kernel either. Not to mention you'd have to profile the possibly performance trade off as well.

But sure. You could have nice looking function names and maybe slightly simpler code as a plus. Whoopy!

[Wyzard]

[QUOTE=gparent;22885450]I'm sure C++ features would have a use, but I don't think it would be worth it to have to deal with C++ to reap those little benefits there and there. Function overloading isn't that big of a deal, classes aren't that big of a deal (especially in a kernel), and polymorphism, while nice, isn't really something I see as a big plus in a kernel either. Not to mention you'd have to profile the possibly performance trade off as well.

But sure. You could have nice looking function names and maybe slightly simpler code as a plus. Whoopy![/QUOTE]
You overlooked RAII, which is a pretty good way to avoid leaking resources -- not just memory, but also things like mutex locks that need to be unlocked at the end of a critical section. Having it done automatically by destructors, rather than having to write cleanup code in every exit path, can help to avoid bugs and also keep the code more readable. If I were writing a kernel in C++, I'd consider that the biggest benefit.

[Jawalt]

[QUOTE=nullsquared;22874706]No where did I say C++ is a superset of C. And 99% is just about right - there are very few things in modern C that a modern C++ compiler cannot compile.[/QUOTE]
Did you miss the part where I said C compiler can only compile ~90% of C on average? I'd bet there are some conflicts between the C and C++ standards as well. I'd say a more accurate estimate or be in the low 80 percentile.

[esalaka]

[QUOTE=Jawalt;22892373]Did you miss the part where I said C compiler can only compile ~90% of C on average? I'd bet there are some conflicts between the C and C++ standards as well. I'd say a more accurate estimate or be in the low 80 percentile.[/QUOTE]

The current C++ standard has some conflicts with C99, but IIRC it's fully C89-compatible.

[nullsquared]

[QUOTE=Jawalt;22892373]Did you miss the part where I said C compiler can only compile ~90% of C on average? I'd bet there are some conflicts between the C and C++ standards as well. I'd say a more accurate estimate or be in the low 80 percentile.[/QUOTE]

Your percentages come from missing arbitrary headers that no one really uses anyway, among other minor issues that one wouldn't ever notice.

[Jawalt]

[QUOTE=nullsquared;22898381]Your percentages come from missing arbitrary headers that no one really uses anyway, among other minor issues that one wouldn't ever notice.[/QUOTE] GCC is one of the best examples of compatibility. There are many other compiler that don't implement NEARLY as much of it.

[editline]02:43PM[/editline]

And really you might as well write C code at the point of having lost some of the most used features of C++ for kernel writing. And there's the chance that some might just not want to use C++.

[nullsquared]

[QUOTE=Jawalt;22904793]
having lost some of the most used features of C++ for kernel writing[/QUOTE]

Like what, having to initialize globals manually? You shouldn't be initializing globals manually anyway. Most of the prominent features are intact and still useful.

Or are you implying that you can't use the SC++L (as-is, at least)? This argument doesn't apply; you can't use the SCL, either.

[gparent]

[QUOTE=Wyzard;22887702]You overlooked RAII, which is a pretty good way to avoid leaking resources -- not just memory, but also things like mutex locks that need to be unlocked at the end of a critical section. Having it done automatically by destructors, rather than having to write cleanup code in every exit path, can help to avoid bugs and also keep the code more readable. If I were writing a kernel in C++, I'd consider that the biggest benefit.[/QUOTE]
True.

[Jawalt]

[QUOTE=nullsquared;22906638]Like what, having to initialize globals manually? You shouldn't be initializing globals manually anyway. Most of the prominent features are intact and still useful.

Or are you implying that you can't use the SC++L (as-is, at least)? This argument doesn't apply; you can't use the SCL, either.[/QUOTE]
I don't know, I just don't see a class-based object orientation model working very well with that kind of thing even. It's probably better to use something procedural and some form of loose oo or something, but I guess that's personal opinion. Point is, I think if you're working like that the difference between using C, and C++ isn't anywhere near as large as it is otherwise. It's basically class-based OO versus a purely procedural model. And that's a matter of taste/opinion.

[Pretiacruento]

[QUOTE=st0rmforce;22844113]Oh and try this: [URL]http://www.computer-books.us/c.php[/URL][/QUOTE]

Thanks for the link! I really want to be a decent programmer (although I recognize I don't really like programming) but I want to give C a shot. I'm going to read 'em up :D

[st0rmforce]

[QUOTE=Pretiacruento;23035146]Thanks for the link! I really want to be a decent programmer (although I recognize I don't really like programming) but I want to give C a shot. I'm going to read 'em up :D[/QUOTE]

If you don't like programming I probably wouldn't recommend C
I'd go for something that you can get results quicker

[Pretiacruento]

[QUOTE=st0rmforce;23035459]If you don't like programming I probably wouldn't recommend C
I'd go for something that you can get results quicker[/QUOTE]

Well, it's not that I don't like programming, I've never had the real desire to learn -up until now- so all I did was half-assed attempts of programming, which of course sucked. OTOH, I found out I really like DBs, for instance (learning a lot of MySQL and MS-SQL right now).

Luckily I can get Turbo C at work (along with MS Visual Studio C++, etc)... that should be more than enough to get me started, right??

[yngndrw]

To be honest, for most of the uses that the majority of users on here will be doing, performance is not (Should not be) an issue and hence optimisation is a moot point. For the small percentage of people who actually need to optimise their work for valid reasons, they will decide the language themselves, most probably picking what they are most comfortable with anyway.

Both C and C++ are old and rather tired languages these days anyway. I see C# as being the way forward for 99% of applications these days as small language-related performance optimisations are simply not important on current equipment. (Even microcontrollers are getting more than powerful enough to ignore optimisations a lot of the time.)

Someone wise once said something along the lines of:
[quote=Wise Person]Guide to optimisation: Don't do it.
Guide to optimisation (Advanced users): Don't do it, [i]yet[/i].[/quote]

Don't get me wrong, I think that every programmer should have an understanding of optimisation. However I think rather than looking up how to write better optimised code, you should instead be looking up how to exploit your compiler's build-in optimisations. Also optimisation should never sacrifice readability.

[turb_]

[QUOTE=Pretiacruento;23036255]I can get Turbo C at work[/QUOTE]

Hand in your two weeks notice now.