OSDev and C++0x

[Creature]

Hello everyone

With the release of Visual Studio 2010 and GCC 4.5 becoming closer and closer (the compiler releases that are supposed to take a major step towards C++0x), I was wondering what you think of this new "improvement" upon the C++ language. Do you think the newly added features will be useful in general (was something added that you kind of missed in C++?)? Do you see C++0x being used in kernels or operating systems (I'm referring to the ones being made here, of course). Why so?

Sorry for my barrage of questions, I'm just curious what your opinions are on C++0x. Myself, I'm kind of waiting until I can properly toy around with it. It seems to be promising but if it will really be that big of a deal, I don't know.

[pcmattman]

I'm mainly excited about lambdas. Whilst they could easily be abused, they are also a feature I've been missing for quite some time.

As for C++0x in a kernel? I'd say not until it's been tried and tested in applications, and even then I'd only use the features which do not require a C++0x runtime.

[Owen]

auto! auto! auto!

[gravaera]

Hi, and @OP: nice topic;

I'm with pcmattman, and I'd like to add that I also like the enhanced unicode string support idea.

--All the best
gravaera

[Solar]

I actually haven't had a look at the C++0x features yet. Since most of my work is maintenance coding, the vast majority of code I am handling (and will be for the forseeable future) isn't even up to par with C++ 98...

[Creature]

Wikipedia has a pretty nice article on C++0x for those who don't know a lot about the features yet.

I'm mainly excited about lambdas. Whilst they could easily be abused, they are also a feature I've been missing for quite some time.

I'm with pcmattman, and I'd like to add that I also like the enhanced unicode string support idea.

Lambda expressions seem to be interesting to say the least. Seems like a good alternative for especially predicates which are a bit cumbersome to code if you have a lot of them.

auto! auto! auto!

Auto seems like a very useful construction, especially to replace constructions like this:

for (vector<int>::const_iterator itr = myvec.begin(); itr != myvec.end(); ++itr)

with this:

for (auto itr = myvec.begin(); itr != myvec.end(); ++itr)

I always found it kind of annoying to place the rather large type.

[Solar]

auto! auto! auto!

That's probably the one feature I feel most negatively about. It smells too much like VB's "variant", and IMHO goes against what C++ is all about. There's no simple way to find out what an "auto" variable can do...

[AndrewAPrice]

for (vector<int>::const_iterator itr = myvec.begin(); itr != myvec.end(); ++itr)

with this:

for (auto itr = myvec.begin(); itr != myvec.end(); ++itr)

I always found it kind of annoying to place the rather large type.

And most certainly beats:

Code: Select all

for(std::vector<std::vector<int>::const_iterator>::const_iterator it = myvec.begin(); it != myvec.end(); it++)

There have been circumstances where I've required that.

[gravaera]

But the auto thing can lead to some serious misuses that would be plain disatrous. Maybe they could insert some serious limitations on its use and where it can be placed. Otherwise I do see some potential for inexperienced coders to go do some murky things with it.

[JamesM]

for (vector<int>::const_iterator itr = myvec.begin(); itr != myvec.end(); ++itr)

with this:

for (auto itr = myvec.begin(); itr != myvec.end(); ++itr)

I always found it kind of annoying to place the rather large type.

And most certainly beats:

Code: Select all

for(std::vector<std::vector<int>::const_iterator>::const_iterator it = myvec.begin(); it != myvec.end(); it++)

There have been circumstances where I've required that.

Your typedef-fu is weak, old man.

[AJ]

Hi,

But the auto thing can lead to some serious misuses that would be plain disatrous. Maybe they could insert some serious limitations on its use and where it can be placed. Otherwise I do see some potential for inexperienced coders to go do some murky things with it.

I see what you mean and there's no need to introduce things which lend themselves to too much to abuse, but IMO any language which allows pointer maths and casting of pointers is a bit of a potential minefield for inexperienced programmers anyway. I think that comes with the territory of using a language designed for systems programming.

I can't wait for C++ 0x (or will it now end up being C++ 1x?), although I'm slightly disappointed that GC and Reflection don't feature (or have at least been postponed). Maybe I'm better off using D...

Cheers,
Adam

[Owen]

But the auto thing can lead to some serious misuses that would be plain disatrous. Maybe they could insert some serious limitations on its use and where it can be placed. Otherwise I do see some potential for inexperienced coders to go do some murky things with it.

Your saying this in a language which is descended from a language which "makes it easy to shoot yourself in the foot" and has been described as "making it easy to blow off your leg".

--

Actually, one other thing I like: std::vector<std::pair<int, int>> is now legal (Complaints that it messes up the lexer or parser are silly when you can generate me an error whining about it precisely anyway!).

And while I'll probably not be using concepts that much directly, when they get into the STL/Boost/OtherTemplateLibs, I will be so, so glad to see the end of 8 page template error messages!

(I think the running joke in the comitte has been, for a while now, that "the X is going to be in hexadecimal". I think they should go for "The x means it's in hexadecimal", and name it something like C++0xB:p)

[Thomas]

Hi ,
The auto keyword seems to be very similar to var keyword in C# ( 3.0 ) . Please note that introduction of the "var / auto " keyword does not make the language dynamically typed. I find it quite useful during prototyping (esp when iterating over a collection etc ) .

-- Thomas

[fronty]

I think auto can be acceptable when used with trivial for loops in place of ugly templates but should be avoided with everything else so it is easier to check what you can do with the object. But in this case I would still prefer typedefing.

[Creature]

I agree that what the auto actually does can be dubious. It'll probably all work out fine for C++ STD library container types, like std::vector and such, but what will happen when we make custom classes and iterators (for our kernels, for example)? I smell hours of debugging coming up to find out the auto keyword was compiling fine but taking some unexpected type.