Elements of Modern C++ Style (i.e. C++11)

[Peter Bloomfield]

Here's a very helpful and informative blog post by Herb Sutter about some of the key new language features of C++11. I really recommend it to current CGT students, as there's a good chance it will start seeing adoption in the field in the next few years (i.e. by the time you graduate and get a job). If you know it in advance then I reckon you'll have better employability potential:

 

http://herbsutter.com/elements-of-modern-c-style/

 

In case you're wondering what parts of C++11 will be available in which compilers, Scott Meyers has a handy collection of references (see below). The link to Stephan T. Lavavej's summary of Visual Studio implementation will obviously be particularly relevant.

 

http://www.aristeia.com/C++11/C++11FeatureAvailability.htm

 

 

A quick note on the people I've mentioned above, in case you're not familiar with them: Sutter and Meyers are among the major C++ gurus, and are very influential in the language's evolution; Lavavej is a library developer for MS Visual C++.

[Christoffer Pettersson]

Yea I've only tried winapi so far but I found it very messy. So was planning on looking into Boost or SDL. the thing with SDL though, is it used for anything other than games? If the principles of concurrent programming are common though like you said I could probably just pick one of them and then learn to use the other one as well.

 

Thanks :)

[Kalakian]

I would suggest looking at the SDL multithreading as an alternative, since you're using SDL for AGP anyway.  I don't have much experience with threading in C++, so I couldn't honestly say which one is "best".

[Peter Bloomfield]

I'm afraid I'm not sure off-hand. I know Boost in general is highly regarded by many professionals, and parts of it are certainly used in several commercial products. I couldn't tell you how much the threading components are used in industry though.

 

The principles of concurrent programming are very common, so it's fairly straightforward to adapt to different libraries. If you want to learn about threading then I'd say Boost is a very good way to go, as it's cross-platform and open source.

[Christoffer Pettersson]

I was gonna send this in a private message Peter because it might be a bit off topic but it wouldn't let me send a message that was greater than 200 characters. I see you wrote "I expect we'll see basic threading reasonably quickly as well, since that's been around for ages in Boost, and the C++11 spec is based on it." Do you know if boost's multithreading is commonly used in the industry?

[Kalakian]

Yeah, it will have its uses, like the example you gave, but I would probably avoid it as much as possible.

[Peter Bloomfield]

That's probably how it will be viewed by lots of programmers. :) It's supposed to improve readability and reduce typing errors though, e.g.:

 

auto iter = myMap.begin();

 

...is much simpler than:

 

std::map<int, std::string>::iterator iter = myMap.begin();

 

[Kalakian]

So it's essentially a helper for people that can't code properly? ;)

[Peter Bloomfield]

Yeah, I can imagine running into difficulties sometimes, particular when refactoring code. It would probably be quite easy to change the type accidentally, but then that's why explicit casts are often a good idea (even for up-casts).

 

You're right about auto not working for normal member variables, because any given class needs to have a fixed size determined by declaration alone. (Same goes for function parameters.) However, there are a couple of other ways auto can be used. One is for const static members of a class declaration, e.g.:

 

class SomeClass

{

 const static auto MY_VALUE = 15;

};

 

The other use of auto is for trailing return types from functions. It's pretty obscure and I imagine it will almost never be needed by most programmers. Afaik, it exists so that some types of complex template functions can be resolved correctly by the compiler.

[Kalakian]

That's what I thought, so still have to be careful not to do something like:

auto myVar = new SomeClass();

Member variables can't use auto though, can they?  I just had a brief read through the article, and it seemed that auto only works if you make an assignment during declaration, so auto is just for local variables then?

[Peter Bloomfield]

An auto variable is still statically typed, so polymorphism isn't affected at all. All that happens is that on initialisation of the variable the compiler effectively changes the "auto" declaration into the right-hand type (the one being assigned). You can re-assign the value of the auto variable during its lifetime, but it retains the same type. E.g.:

 

class BaseClass {...};

class SomeClass : public BaseClass {...};

class OtherClass {...};

 

auto myVar = new BaseClass(); // myVar has type: BaseClass*

myVar = new BaseClass(); // reassigning value of same type is OK

 

// Implicit up-cast is OK.

// Note that myVar is still type BaseClass*, so this is polymorphic:

myVar = new SomeClass(foo);

 

// Reassigning a totally different type is not OK:

myVar = new OtherClass(); // error!