OSDev.org

I'm really not up to scratch with C++, but I'm writing my kernel using a small subset of the language. As of yet, I have not really used C++, it's just getting compiled with g++ as opposed to gcc heh. I taught myself C several years ago, but have only recently looked into C++ (and I keep forgetting simple things because I've not been using it much, just looking into it).

I chose to go with C++ because I like the idea of objects and I like the idea of namespaces and templates. Templates are just damned sexy.

I'd always been scared of object-orientated languages, but I've had to do a couple of Java units for uni (don't mock me, they're core units, and I'll be doing C++ as an elective later--why Java is core and C++ is elective is beyond me though) and I'm starting to like the object-orientated approach, if not Java itself.

One question I have after this is, since exceptions are out, what do you developers use to signal errors inside a constructor? Seems to me the only option would be to pass a pointer to the constructor, which the constructor would store the success or failure of initialization in. After the constructor has been called, you would then have to check the value stored at specified location for an error. Seems a bit tedious (and unsightly) to me.

Cheers,
Lee

zerosum wrote:One question I have after this is, since exceptions are out, what do you developers use to signal errors inside a constructor? Seems to me the only option would be to pass a pointer to the constructor, which the constructor would store the success or failure of initialization in. After the constructor has been called, you would then have to check the value stored at specified location for an error. Seems a bit tedious (and unsightly) to me.

I think the most common way to avoid this is to use two-phase initialization. The constructor does very little, but you have to call an "init" function on your object before you can use it. It's ugly.

Sorry, that was obvious and I should have mentioned that option too.

It is definitely ugly. I remember doing that when I discovered you can't return a value as such [edit: from a constructor I mean, of course] in c++, and I hadn't yet touched exceptions, and was using dynamic memory allocation during initialization. Ugly.

zerosum wrote:Sorry, that was obvious and I should have mentioned that option too.

It is definitely ugly. I remember doing that when I discovered you can't return a value as such [edit: from a constructor I mean, of course] in c++, and I hadn't yet touched exceptions, and was using dynamic memory allocation during initialization. Ugly.

In a kernel I opt for the opposite way. You use a static function that checks it would be going OK and then you construct the object, not caring about whether it succeeds (so you'll never throw an exception). Only make the function for the parts where it depends on hardware. Software state has to be assumed (imo) as you're making all of it.

Device drivers might be a minor exception, but the kernel telling me that it can't load a certain device driver is still bad.

Good article on the subject of the object that never was.

I would think about lazy initialization, i.e. keep stuff that could fail out of constructors.