Page 1 of 4

learning c/c++

Posted: Wed Apr 03, 2013 7:23 am
by Mikemk
Until now, I've been writing my os in assembly simply because I don't know c or c++, but I'm tired of scrolling through multi-thousand line files
If I won't be using the standard libraries, what do I need to learn to rewrite the kernel in c++?

PS, I already know java and C#, so...

Re: learning c/c++

Posted: Wed Apr 03, 2013 7:52 am
by HugeCode
m12 wrote:.... but I'm tired of scrolling through multi-thousand line files
Use IDE supporting collapsing code (for eaxmple WinAsm) :wink:

There are many tutorials on the web.... cprogramming.com or Wikibooks

Re: learning c/c++

Posted: Wed Apr 03, 2013 7:55 am
by iansjack
At the risk of giving the obvious answer - you need to learn C. If you don't know C or C++ I'd give the idea of writing an OS in C++ miss - it's perfectly possible, but has complications that you probably don't want to get into at this stage.

Re: learning c/c++

Posted: Wed Apr 03, 2013 8:01 am
by Griwes
If you know C# and Java and want to write something in proper C++, unlearn everything you've learned. Same holds for C.

C and C++, when used without standard libraries, are pretty similar. The main differences are:
1) You have real constructors and destructors, so RAII is possible.
2) You have templates (never underestimate a compile time Turing-complete language!).
3) You have easy to use polymorphism.
4) You have namespaces.
5) You have overloads.

So, basically, to write a *kernel* in C++ (as opposed to writing it in C), you'd have to learn at least those things *and* C. Of course, knowing more things in detail can be really helpful, so I would advise also writing some userspace applications in modern C++; also, there should be some serious style differences between code written in C and in C++.

Re: learning c/c++

Posted: Wed Apr 03, 2013 8:08 am
by AJ
Hi,
iansjack wrote:If you don't know C or C++ I'd give the idea of writing an OS in C++ miss - it's perfectly possible, but has complications that you probably don't want to get into at this stage.
It very much depends on how C or C++ fit in with your design and existing programming style. Also, would you find one or other of these languages more useful that the other outside the OSDev world?

No point using C++ if you're just going to treat it as a superset of C. No point going with C if you're just going to end up implementing the equivalent of C++ design time / runtime support.

Cheers,
Adam

Re: learning c/c++

Posted: Wed Apr 03, 2013 8:22 am
by Griwes
Actually, all the features I listed in my post are reasons why C++ is nicer to work with, even when used *mainly* (not totally, of course) as superset of C.

Re: learning c/c++

Posted: Wed Apr 03, 2013 8:55 am
by Kevin
I'd rather use C11 than the superset of C89 implemented by C++. </flamebait> ;)

(Yes, templates could be really useful at times. But giving up designated initialisers...?)

Re: learning c/c++

Posted: Wed Apr 03, 2013 9:10 am
by Brendan
Hi,
AJ wrote:It very much depends on how C or C++ fit in with your design and existing programming style. Also, would you find one or other of these languages more useful that the other outside the OSDev world?
Agreed; but if m12 is used to using assembly then I think it's very unlikely that m12's design and existing programming style are going to suit C++.

I'm NOT saying that C++ is bad (it is, but I'm not saying it ;) ). What I am saying is that C is a lot closer to assembly and a lot easier for an assembly language programmer to get used to.


Cheers,

Brendan

Re: learning c/c++

Posted: Wed Apr 03, 2013 9:11 am
by Griwes
C11 is "how to go The Wrong Way". Designated initializers looks nice, but I still prefer more obvious code (and constructors) ;)

(I mean, "_Bool", "thrd_t" and countless others - seriously...?)

Re: learning c/c++

Posted: Wed Apr 03, 2013 9:26 am
by Mikemk
It doesn't need to be in c++ if c is easier - I already have a specialized language thought out for applications - it's just not suitable for the kernel without pointers, and I'd rather leave pointers out of it for security purposes.

Also, I have no need for any standard libraries since everything but the kernel will be in the other language.

Mainly, I'm asking about syntax. Would something along these lines be valid (in C)?:

Code: Select all

#define SCREEN 0xb8000
void main(){
char* screen = SCREEN;
screen* = 0x53;
screen++;
screen* = 7;
}

Re: learning c/c++

Posted: Wed Apr 03, 2013 12:21 pm
by Griwes
Obviously not. Get a book.

Re: learning c/c++

Posted: Wed Apr 03, 2013 12:27 pm
by XanClic
Kevin wrote:I'd rather use C11 than the superset of C89 implemented by C++. </flamebait> ;)

(Yes, templates could be really useful at times. But giving up designated initialisers...?)
I'd like to add anonymous structs and unions, since we're talking about C11.

Re: learning c/c++

Posted: Wed Apr 03, 2013 12:51 pm
by VolTeK
I guess we can't just toss out the famous

http://wiki.osdev.org/Required_Knowledge

Re: learning c/c++

Posted: Wed Apr 03, 2013 1:53 pm
by Griwes
Not really, since OP is asking how to *fulfil* it.

Re: learning c/c++

Posted: Thu Apr 04, 2013 3:05 am
by Kevin
Griwes wrote:C11 is "how to go The Wrong Way". Designated initializers looks nice, but I still prefer more obvious code (and constructors) ;)
Same result: This is the domain of plain C, the control flow won't become more obvious than there. C++ isn't about obvious code, but about convenient magic.

And I think "looks nice" gives designated initialisers and compound literals too little credit. They turn potentially long sequences of assignment statements into one declarative block, which again makes the code much more obvious. You can of course have an old-style initialiser or constructors with umpteen arguments and have the same degree of declarativeness, but this becomes quickly quite non-obvious because nobody can remember what the seventh parameter was meant to be without looking it up.
(I mean, "_Bool", "thrd_t" and countless others - seriously...?)
Yeah, names of built-in types are the most important criterion to choose a programming language, I agree.