gobuysoft.com

Michael Schade, Chief Executive and Co-founder of Fishlabs Entertainment in Hamburg, Germany talks to David Smith of Game Careers and Interactive Selection at GDC Europe. Michael has been deep into computer graphics and 3D animation and software development for more than 15 years. Since the very beginning of FISHLABS in 2004 Michael was at several international leading mobile and gaming industry events and is a well known evangelist for high-end gaming on mobile phones.

He has held several lectures, workshops and keynotes at Game Developer Conference (San Francisco), Annual Mobile Games Forum (London), Games Convention Developer Conference (Leipzig), Icon (South Korea) and other industry events. Before FISHLABS he founded one of the leading 3D animation studios in Germany in 1993 together with his former colleague from University, Christian Lohr. They have worked for major companies like Airbus, BMW, IBM, Panasonic, Renault and Siemens. His advice to those thinking of applying for job at Fishlabs:
“Obviously you need to be qualified enough. However, for us it is very important that someone fits into the team. We do have an open space situation so its very important that anyone can work with each other well and nicely. Of course passion is important. We like it if people bring ideas from different spaces, like from comics, from movies etc. So not really that focussed on games. For instance our Creative Director is an architect so no gaming background at all, and it shows. So if you have some extra talent, some extra qualifications let us know.”

See the full clip here:

Game Careers .BIZ – Video Games School, Jobs in Gaming.

Today marks another important day in my calendar as I’m proud to announce the general availability of cpp-netlib 0.9.1. You can now download the source packages from the Github download page. If you want to see what’s new you can head on to the online documentation page for what’s new in 0.9.1. This release fixes a number of issues with 0.9.0 so if you’re still using 0.9.0 you might want to upgrade to 0.9.1. That’s not the only reason 0.9.1 is good though, and the rest of this post is about giving a little bit more insight into what’s new and what’s coming in the coming months for the C++ Network Library project.

For all intents and purposes, 0.9.1 should really be version 1.0 — but there are a few things holding it back from becoming ready for prime-time as a 1.0 version. Here’s a list of things that are in there that makes the release extra special:

• Support for streaming body callback handler in HTTP client requests. This means you can perform HTTP client requests and pass a callback function that gets called every time a chunk of data is available from the connection. This allows you to handle larger response bodies without having to fit all the data in memory. This is important for implementing downloaders that need to save data straight to a file or in general when you just want to not have to wait for all the data to be put in memory before processing it. You can find out more about this by reading the updated HTTP Client reference documentation.
• Default HTTP client is now asynchronous. This release switches the default HTTP client implementation defined at boost::network::http::client to use the asynchronous features. There are no changes required to the original code that used the default HTTP client implementation, but linking to the new version may require you to link in Boost.Thread. You can easily change the default tag by overriding the BOOST_NETWORK_HTT_DEFAULT_TAG macro at compile time or before you include any cpp-netlib header.
• Tons of bug fixes from 0.9.0. You can find the list of issues that have been closed on the GitHub issues page. Needless to say the amount of changes that went into the library between 0.9.0 and 0.9.1 are pretty substantial that would have merited a major number advance, but there are more good things in store to wait for to get into 1.0.

The list above is pretty packed but I’d also like to update everyone on some good news regarding the cpp-netlib project. Needless to say they should be treated as great news but I’m not one for exaggeration. Here are a few updates:

• There’s now a git mirror up on Google Code Project Hosting. At some point in the future — depending on how large the community grows and/or whether there’s popular support for it — the Google Code Project Hosting site may just become the de-facto development repository of the project. You can find the Google Code Project here.
• I’m now officially working on cpp-netlib as my 20% project in Google! This means I can now devote a measurable amount of time and effort into making sure the project succeeds. This doesn’t change the project goals and ideals but hopefully it does change the pace of development as I get more effort into it.
• I’m looking to expand the developer pool by offering to mentor interested developers who want to learn the techniques and be part of the project. Since cpp-netlib is not my 100% time project in Google I’m not going to be able to do all the fun work that still needs to be done to make cpp-netlib better. Good news is that I’m making myself available to help mentor developers to get up to speed on the project and have more people eventually able to contribute to the effort.
• I’ve found a willing review manager for cpp-netlib’s eventual review for inclusion in the Boost C++ Library. It’s going to be just a matter of time now before the review is scheduled and I’m able to set time aside to get the review done and over with. The project will continue to evolve and develop even outside of Boost following the Boost.Spirit and Boost.Asio model and hopefully get more people contributing to Boost through the cpp-netlib project.

If you’re interested in the mentoring, please join the cpp-netlib Google group and introduce yourself. Let everyone on the list know what you want to learn and what part of the library or project you want to be involved in. We’re currently looking for people who are willing to:

• Test the library on the major development platforms. Right now we’re only concentrating on Linux and Mac with GCC and Clang, and we’re looking for people willing to test on Windows and/or other platforms.
• Update the look and layout of the website. This doesn’t require much C++ knowledge but should be proficient with HTML, CSS, and has better design aesthetics than I do.
• Read/update the documentation. Feedback on the documentation and what’s lacking are very important.
• Implement new features and/or refactor the internals of the library. This part will be involved and is where I would be doing most of the mentoring and hand-holding as much as necessary.

Thanks for reading so far down and I do hope you’ll help spread the word about the new release.

Cheers from down under!

Filed under: announcement, boost, cpp-netlib, updates
C++ Soup!

Sebastian Enrique, Software Engineer at Electronics Arts in Vancouver, Canada talks to David Smith of Interactive Selection and Game Careers at Gamescom in Germany. It’s been 5+ years since Sebastian started working on the EA Sports FIFA football franchise as a software engineer and game designer. In all that time, he has introduced new concepts and innovative features in the franchise like the Emotional Engine, Player Reactions, Be A Pro, Be A Goalkeeper, and Creation Centre.  His advice for people thinking of applying for a job at EA Canada:

“I’ll give one piece of advice in general, not just for EA but for several. You will get “walled” over and over and over, but eventually you will have the opportunity. Never give up, that’s the fist thing I will tell you. Second for EA Sports, go to www.easports.com/jobs – there are the job listings there. We will take those and read them seriously.”

See the full clip here:

Game Careers .BIZ – Video Games School, Jobs in Gaming.

The Concurrency Runtime team is working on the next generation of the Parallel Patterns Library (PPL) that will help you consume asynchronous operations in your apps using a simpler development model than the one Windows 8 has built-in as part of its Windows Runtime.

In that sense, they recently published a blog post explaining the rationale behind their abstraction library, and not less importantly, a set of samples showing these in action.

Visual C++ Team Blog

Programming large projects can be a quite tedious projects that needs lots of code refactoring again and again, if the code is not well written from the beginning. A very efficient way to make sure that your code is of the highest standards, is by utilizing design patterns if applicable. A design pattern is actually a way of organizing your code so that it is well written, maintainable and extensible. There are various design patterns fitting lots of different situations. One of my favorites is the Strategy design pattern.

What is the Strategy design pattern ?

In the formal sense, the Strategy pattern is one that defines a family of algorithms, encapsulated each one of them and makes it so that they can be interchanged. In a more informal and more understandable definition, it’s a neat way to dynamically assign behaviour to a particular client object (class object). Let’s think of an example. Illustrate that we are creating a new game where there is a user that has a first class attribute, which can either be a Ranger, a Fighter, or a Magician. Each class has different skills and, say, different cost to research.

Now, this already creates some questions for us to solve. How will we handle the situation ? Let’s see how one could do it :

1. We could start by having a User class. This class has an attribute named first_class that can be either set as one of the three types (Ranger, Fighter, Magician). Thus, we would see this :

user = User.new
user.first_class = 'Ranger'
puts user.cost

Now, you may already see the problem in this. The cost function implemented by the User class has serious design flaws. Let’s see its possible implementation :

def cost
  if self.first_class == 'Ranger'
    100
  elsif self.first_class == 'Fighter'
    200
  elsif self.first_class == 'Magician'
    130
  end
end

An important design principle of good code is the OPEN/CLOSED principle. That code must be open for extension, but closed for modification. Think what will happen if we ever need to add a new first_class, say ‘Knight’. We would need to change the cost function and every other function that operates in the same IF-ELSE way. That would be a big nightmare and a big design problem. Moreover, user.cost does not actually mean anything. Even if we create the method so that it’s something like user.first_class_cost, we are actually passing first class behavior to the User class. Not a good thing, this class is probably doing too much in terms of responsibilities. We should really make sure that every class only does as much as needed and nothing more. So, how can we make this code better and more extensible ?

Enter The Strategy Design Pattern 

Let’s start by seeing how this code changes when transformed to utilize the Strategy Pattern :

class User
  attr_accessor :name, :first_class

  def first_class= klass
    @first_class = klass.new
  end

  def first_class_description
    @first_class_description = @first_class.description
  end

end

class FirstClass

  def vehicle
    'car'
  end

end

class Ranger < FirstClass

  def cost
    30
  end

end

class Fighter < FirstClass

  def cost
    20
  end

end

See the difference now ? The idea is that we still have a User model, but now we act smarter on defining its first_class. Instead of making it a nightmare String based value, we are actually making it a new model. A new User object now expects a new first_class object in order to operate correctly (we can add it to the constructor as well, if needed). Now, in this example, every first_class gets a new vehicle automatically, so that each new first class character gets a ‘car’. Of course, this can be extended as well, using the same pattern, but it just serves as an example in showing how static things can just stay in the main class. Now, a Ranger, Fighter or anything else, inherits FirstClass and defines a new set of algorithms that operate on the base class. Pretty straight forward i guess.

The best thing about this pattern now is that our object does not need to know what it is, in order to present the description or the cost of its class. The behavior is dynamically set. Let’s see the example execution :

user = User.new

user.first_class = Ranger
puts user.first_class.description
puts user.first_class.cost

user.first_class = Fighter
puts user.first_class_description
puts user.first_class.cost

And when we execute the program we get :

A Ranger here
30
A Fighter here
20

As a side note, see that i also define a first_class_description method, which delegates responsibility directly to the first_class model. This is actually what Rails does with the delegate_to method. It’s a good practice and a fully encapsulated way to do things. That’s it with the Strategy Pattern in Ruby, hope that it will help you in designing your implementation.

Programming Tips For Versatile Coders

Benedikt Grindel, Head of Live Operations at Ubisoft Blue Byte talks to David Smith of Interactive Selection and Game Careers at Gamescom in Cologne, Germany. After acquiring a masters degree in mathematics with business as a minor and starting his job career at a carpet manufacturer, Benedikt Grindel found out that you cannot just play computer and video games, you can even earn a living with them.

In 1998 he joined the German subsidiary of French-based publisher Ubisoft Entertainment. After two years in marketing and one year in business development, Benedikt decided in 2001 to change from selling games to making them: He moved to the creative development force as producer of the most prestigious German interactive entertainment brand, “The Settlers” (more than six million units sold) at Ubisoft’s daughter company Blue Byte. Under his responsibility, nine titles have been produced and released worldwide. In 2010, his team has released the critically acclaimed “The Settlers 7 – Paths to a Kingdom”. Today, he is both responsible for the Live Operation of Ubisoft Blue Byte’s online games and for the development of an unannounced title. His advice for those thinking of getting into the games industry:

“Tell us why you want to do games…to do games has to have some passion. Bring that across a lot in your application. What we see a lot is people saying they want to do games, but then they don’t show it in their writing. Send us a game that you have done, do a game. And then of course be very complete in your application, don’t make any grammatical mistakes, its standard stuff, not that difficult.” See the full clip here:

Game Careers .BIZ – Video Games School, Jobs in Gaming.

It’s been a long time since I’ve blogged. I’ve been working on several secret projects, and getting ready to launch them in the Fall.

But for the next month, I’m moving into a desert. What? That’s right…for 28 days, I’ll be doing the Boulder Outdoor Survival School.

I’ll be living in the desert with 11 other students and 3 teachers. We will be hiking 20 miles a day, only eating what we find, hiking with no backpack, and just trying to survive. The average person loses 20-30 pounds.

The video below shows the majority of the things I’m bringing with me—1 jacket, one sweater, a hat, 2 shirts, a pair of zip off pants, and a hat. I’ll also have my Vibram Five Fingers KSO Trek shoes, a pair of running shoes, a Nalgene, and a few other tiny items. After a week, I’ll get to carry a Poncho and a Knife as well.

So, for the next month, I will be journaling my experiences in the wilderness, and when I get back I’ll blog about them. I have a camera, so I’ll be taking photo and video of living in the wilderness.

Until then, I’m going to quietly let you guys take a sneak peak at my secret project, the 90 Days Project, which I’ll be launching in November.

I’m leaving tomorrow morning, and I’ll return back October 22, 2011. Until then, stay fly.

ManeeshSethi.com – Lifestyle Design, SEO, and Living the Digital Nomad Life

Nicolas Gaume, President of Mimesis Republic in Paris, France, talks to David Smith of Interactive Selection and Game Careers at GDC Europe in Cologne, Germany.

Nicolas Gaume founded Kalisto Entertainment, a video game development studio, in 1990, at the age of 19. Over its 12 years of life, Kalisto produced more than 50 titles for PC and consoles. Kalisto also worked with Orange to launch their mobile games efforts. The company employed a staff of over 350 people in the USA, Japan and France. Besides his Kalisto venture, Nicolas Gaume founded NGM Productions in 1994, a children book publishing company in China. NGM published popular French series such as “Père Castor” (Flammarion) or “Les Incollables/Brain Quest” (Play Bac) between 1994 and 1999, when the company was sold. He was also board member of the French media group Sud-Ouest, of the TV animation production company, Xilam,  and the German data management software publisher, NXN, sold in 2004 to Avid. Nicolas has also worked as a consultant advising media groups, primarily on their development & partnerships strategies, and for three years, Nicolas was Senior VP & GM of the mobile games & applications division of Cellfish Media.

In Early 2008, he founded Mimesis Republic, focusing on the design, development and operation of virtual worlds and social networks. He also currently serves as chairman of the French national video game development school -ENJMIN- and president of the French game developers association, SNJV.

His advice to people thinking of applying for a job with Mimesis Republic:

“For Mimesis, besides the usual standard of quality, expertise, demanding, passion, a demonstration of all these skills that we require for any games studio. I think its also eagerness to understand the new digital lives of teenagers and adults and how people will actually go to on social networks and mobile phones and try see how the game expertise that we have can apply to these new fields. So particularly we are interested beyond the expertise, in the eagerness to learn the new behaviours of the new gamers and games to come.” See the full clip here:

Game Careers .BIZ – Video Games School, Jobs in Gaming.

Jasmin Orthbandt talks to David Smith of Game Careers and Interactive Selection at GDC Europe in Cologne. Jasmin is the Founder & CTO of ChawaChawa.org, and Founder and CEO of Pixeltamer.net. She is in charge of Communication, Management & New Business Development for Pixeltamer.net in Berlin. Here she gives advice for women looking to start a career in the games industry.

“You absolutely have to love your work, because lots face it, working in a production is not a 9 to 5, Monday to Friday job. We do have crunch time sometimes and you can’t just take off. And you really have to have a heart for gaming. You have to love gaming, you have to love programming, and you just got to love working. Just stick to it, if you really really want it then its an awesome place because you are not judged on how you look. Often is other jobs with females, here is where you work counts. What I like very much is that my code lines are pounding and not whether I have a nice dress or not, its definitely not the market for fashion orientated females.” See the full clip here:

Game Careers .BIZ – Video Games School, Jobs in Gaming.

There’s a new C++ Standard and a new version of Visual C++, and it’s time to reveal what features from the former we’re implementing in the latter!

Terminology notes: During its development, the new C++ Standard was (optimistically) referred to as C++0x.  It’s finally being published in 2011, and it’s now referred to as C++11.  (Even International Standards slip their release dates.)  The Final Draft International Standard is no longer publicly available.  It was immediately preceded by Working Paper N3242, which is fairly close in content.  (Most of the people who care about the differences are compiler/Standard Library devs who already have access to the FDIS.)  Eventually, I expect that the C++11 Standard will be available from ANSI, like C++03 is.

As for Visual C++, it has three different version numbers, for maximum fun.  There’s the branded version (printed on the box), the internal version (displayed in Help About), and the compiler version (displayed by cl.exe and the _MSC_VER macro – this one is different because our C++ compiler predates the “Visual” in Visual C++).  For example:

VS 2005 == VC8 == _MSC_VER 1400
VS 2008 == VC9 == _MSC_VER 1500
VS 2010 == VC10 == _MSC_VER 1600

The final branding for the new version hasn’t been announced yet; for now, I’m supposed to say “Visual C++ in Visual Studio 11 Developer Preview”.  Internally, it’s just VC11, and its _MSC_VER macro is 1700.  (That macro is of interest to people who want to target different major versions of VC and emit different code for them.)  I say VC10 and VC11 because they’re nice and simple – the 11 in VC11 does not refer to a year.  (VS 2010 == VC10 was a confusing coincidence.)

If you read C++0x Core Language Features In VC10: The Table last year, the following table will look familiar to you.  This time, I started with GCC’s table again, but I reorganized it more extensively for increased accuracy and clarity (as many features went through significant revisions):

 

C++11 Core Language Features	VC10	VC11
Rvalue references v0.1, v1.0, v2.0, v2.1, v3.0	v2.0	v2.1*
ref-qualifiers	No	No
Non-static data member initializers	No	No
Variadic templates v0.9, v1.0	No	No
Initializer lists	No	No
static_assert	Yes	Yes
auto v0.9, v1.0	v1.0	v1.0
Trailing return types	Yes	Yes
Lambdas v0.9, v1.0, v1.1	v1.0	v1.1
decltype v1.0, v1.1	v1.0	v1.1**
Right angle brackets	Yes	Yes
Default template arguments for function templates	No	No
Expression SFINAE	No	No
Alias templates	No	No
Extern templates	Yes	Yes
nullptr	Yes	Yes
Strongly typed enums	Partial	Yes
Forward declared enums	No	Yes
Attributes	No	No
constexpr	No	No
Alignment	TR1	Partial
Delegating constructors	No	No
Inheriting constructors	No	No
Explicit conversion operators	No	No
char16_t and char32_t	No	No
Unicode string literals	No	No
Raw string literals	No	No
Universal character names in literals	No	No
User-defined literals	No	No
Standard-layout and trivial types	No	Yes
Defaulted and deleted functions	No	No
Extended friend declarations	Yes	Yes
Extended sizeof	No	No
Inline namespaces	No	No
Unrestricted unions	No	No
Local and unnamed types as template arguments	Yes	Yes
Range-based for-loop	No	No
override and final v0.8, v0.9, v1.0	Partial	Partial
Minimal GC support	Yes	Yes
noexcept	No	No

 

C++11 Core Language Features: Concurrency	VC10	VC11
Reworded sequence points	N/A	N/A
Atomics	No	Yes
Strong compare and exchange	No	Yes
Bidirectional fences	No	Yes
Memory model	N/A	N/A
Data-dependency ordering	No	Yes
Data-dependency ordering: function annotation	No	No
exception_ptr	Yes	Yes
quick_exit and at_quick_exit	No	No
Atomics in signal handlers	No	No
Thread-local storage	Partial	Partial
Magic statics	No	No

 

C++11 Core Language Features: C99	VC10	VC11
__func__	Partial	Partial
C99 preprocessor	Partial	Partial
long long	Yes	Yes
Extended integer types	N/A	N/A

 

Here’s a quick guide to this table, but note that I can’t explain everything from scratch without writing a whole book, so this assumes moderate familiarity with what’s in C++11:

Rvalue references: N1610 “Clarification of Initialization of Class Objects by rvalues” was an early attempt to enable move semantics without rvalue references.  I’m calling it “rvalue references v0.1″, as it’s of historical interest only.  It was superseded by rvalue references v1.0, the original wording.  Rvalue references v2.0, which is what we shipped in VC10 RTM/SP1, prohibits rvalue references from binding to lvalues, fixing a major safety problem.  Rvalue references v2.1 refines this rule.  Consider vector<string>::push_back(), which has the overloads push_back(const string&) and push_back(string&&), and the call v.push_back(“meow”).  The expression “meow” is a string literal, and it is an lvalue.  (All other literals like 1729 are rvalues, but string literals are special because they’re arrays.)  The rvalue references v2.0 rules looked at this and said, string&& can’t bind to “meow” because “meow” is an lvalue, so push_back(const string&) is the only viable overload.  This would create a temporary std::string, copy it into the vector, then destroy the temporary std::string.  Yuck!  The rvalue references v2.1 rules recognize that binding string&& to “meow” would create a temporary std::string, and that temporary is an rvalue.  Therefore, both push_back(const string&) and push_back(string&&) are viable, and push_back(string&&) is preferred.  A temporary std::string is constructed, then moved into the vector.  This is more efficient, which is good!  (Yes, I’m ignoring the Small String Optimization here.)

The table says “v2.1*” because these new rules haven’t been completely implemented in the VC11 Developer Preview.  This is being tracked by an active bug.  (Indeed, this is a Standard bugfix.)

Rvalue references v3.0 adds new rules to automatically generate move constructors and move assignment operators under certain conditions.  This will not be implemented in VC11, which will continue to follow VC10′s behavior of never automatically generating move constructors/move assignment operators.  (As with all of the not-yet-implemented features here, this is due to time and resource constraints, and not due to dislike of the features themselves!)

(By the way, all of this v0.1, v1.0, v2.0, v2.1, v3.0 stuff is my own terminology, which I think adds clarity to C++11′s evolution.)

Lambdas: After lambdas were voted into the Working Paper (v0.9) and mutable lambdas were added (v1.0), the Standardization Committee overhauled the wording, producing lambdas v1.1.  This happened too late for us to implement in VC10, but we’ve already implemented it in VC11.  The lambdas v1.1 wording clarifies what should happen in corner cases like referring to static members, or nested lambdas.  This fixes a bunch of bugs triggered by complicated lambdas.  Additionally, stateless lambdas are now convertible to function pointers in VC11.  This isn’t in N2927′s wording, but I count it as part of lambdas v1.1 anyways.  It’s FDIS 5.1.2 [expr.prim.lambda]/6: “The closure type for a lambda-expression with no lambda-capture has a public non-virtual non-explicit const conversion function to pointer to function having the same parameter and return types as the closure type’s function call operator. The value returned by this conversion function shall be the address of a function that, when invoked, has the same effect as invoking the closure type’s function call operator.”  (It’s even better than that, since we’ve made stateless lambdas convertible to function pointers with arbitrary calling conventions.  This is important when dealing with APIs that expect __stdcall function pointers and so forth.)

decltype: After decltype was voted into the Working Paper (v1.0), it received a small but important bugfix at the very last minute (v1.1).  This isn’t interesting to most programmers, but it’s of great interest to programmers who work on the STL and Boost.  The table says “v1.1**” because this isn’t implemented in the VC11 Developer Preview, but the changes to implement it have already been checked in.

Strongly typed/forward declared enums: Strongly typed enums were partially supported in VC10 (specifically, the part about explicitly specified underlying types), and C++11′s semantics for forward declared enums weren’t supported at all in VC10.  Both have been completely implemented in VC11.

Alignment: Neither VC10 nor VC11 implement the Core Language keywords alignas/alignof from the alignment proposal that was voted into the Working Paper.  VC10 had aligned_storage from TR1.  VC11 adds aligned_union and std::align() to the Standard Library.

Standard-layout and trivial types: As far as I can tell, the user-visible changes from N2342 “POD’s Revisited; Resolving Core Issue 568 (Revision 5)” are the addition of is_trivial and is_standard_layout to <type_traits>.  (N2342 performed a lot of surgery to Core Language wording, but it just makes stuff well-defined that users could have gotten away with anyways, hence no compiler changes are necessary.)  We had these type traits in VC10, but they just duplicated is_pod, so I’m calling that “No” support.  In VC11, they’re powered by compiler hooks that should give accurate answers.

Extended friend declarations: Last year, I said that VC10 partially supported this.  Upon closer inspection of N1791, I’ve determined that VC’s support for this is essentially complete (it doesn’t even emit “non-Standard extension” warnings, unlike some of the other Ascended Extensions in this table).  So I’ve marked both VC10 and VC11 as “Yes”.

override and final: This went through a short but complicated evolution.   Originally (v0.8) there were [[override]], [[hiding]], and [[base_check]] attributes.  Then (v0.9) the attributes were eliminated and replaced with contextual keywords.  Finally (v1.0), they were reduced to “final” on classes, and “override” and “final” on functions.  This makes it an Ascended Extension, as VC already supports this “override” syntax on functions, with semantics reasonably close to C++11′s.  “final” is also supported, but under the different spelling “sealed“.  This qualifies for “Partial” support in my table.

Minimal GC support: As it turns out, N2670‘s only user-visible changes are a bunch of no-op Standard Library functions, which we already picked up in VC10.

Reworded sequence points: After staring at N2239‘s changes, replacing C++98/03′s “sequence point” wording with C++11′s “sequenced before” wording (which is more useful, and more friendly to multithreading), there appears to be nothing for a compiler or Standard Library implementation to do.  So I’ve marked this as N/A.

Atomics, etc.: Atomics, strong compare and exchange, bidirectional fences, and data-dependency ordering specify Standard Library machinery, which we’re implementing in VC11.

Memory model: N2429 made the Core Language recognize the existence of multithreading, but there appears to be nothing for a compiler implementation to do (at least, one that already supported multithreading).  So it’s N/A in the table.

Extended integer types: N1988 itself says: “A final point on implementation cost: this extension will probably cause no changes in most compilers. Any compiler that has no integer types other than those mandated by the standard (and some version of long long, which is mandated by the N1811 change) will likely conform already.”  Another N/A feature!

That covers the Core Language.  As for the Standard Library, I don’t have a pretty table of features, but I do have good news:

In VC11, we intend to completely support the C++11 Standard Library, modulo not-yet-implemented compiler features.  (Additionally, VC11 won’t completely implement the C99 Standard Library, which has been incorporated by reference into the C++11 Standard Library.  Note that VC10 and VC11 already have <stdint.h>.)  Here’s a non-exhaustive list of the changes we’re making:

New headers: <atomic>, <chrono>, <condition_variable>, <future>, <mutex>, <ratio>, <scoped_allocator>, and <thread>.  (And I’ve removed the broken <initializer_list> header that I accidentally left in VC10.)

Emplacement: As required by C++11, we’ve implemented emplace()/emplace_front()/emplace_back()/emplace_hint()/emplace_after() in all containers for “arbitrary” numbers of arguments (see below).  For example, vector<T> has “template <typename… Args> void emplace_back(Args&&… args)” which directly constructs an element of type T at the back of the vector from an arbitrary number of arbitrary arguments, perfectly forwarded.  This can be more efficient than push_back(T&&), which would involve an extra move construction and destruction.  (VC10 supported emplacement from 1 argument, which was not especially useful.)

Faux variadics: We’ve developed a new scheme for simulating variadic templates.  Previously in VC9 SP1 and VC10, we repeatedly included subheaders with macros defined differently each time, in order to stamp out overloads for 0, 1, 2, 3, etc. arguments.  (For example, <memory> included the internal subheader <xxshared> repeatedly, in order to stamp out make_shared<T>(args, args, args).)  In VC11, the subheaders are gone.  Now we define variadic templates themselves as macros (with lots of backslash-continuations), then expand them with master macros.  This internal implementation change has some user-visible effects.  First, the code is more maintainable, easier to use (adding subheaders was a fair amount of work), and slightly less hideously unreadable.  This is what allowed us to easily implement variadic emplacement, and should make it easier to squash bugs in the future.  Second, it’s harder to step into with the debugger (sorry!).  Third, pair’s pair(piecewise_construct_t, tuple<Args1…>, tuple<Args2…>) constructor had “interesting” effects.  This requires N^2 overloads (if we support up to 10-tuples, that means 121 overloads, since empty tuples count here too).  We initially observed that this (spamming out so many pair-tuple overloads, plus all of the emplacement overloads) consumed a massive amount of memory during compilation, so as a workaround we reduced infinity.  In VC9 SP1 and VC10, infinity was 10 (i.e. “variadic” templates supported 0 to 10 arguments inclusive).  In the VC11 Developer Preview, infinity is 5 by default.  This got our compiler memory consumption back to what it was in VC10.  If you need more arguments (e.g. you had code compiling with VC9 SP1 or VC10 that used 6-tuples), there’s an escape hatch.  You can define _VARIADIC_MAX project-wide between 5 and 10 inclusive (it defaults to 5).  Increasing it will make the compiler consume more memory, and may require you to use the /Zm option to reserve more space for PCHes.

This story has a happy ending, though!  Jonathan Caves, our compiler front-end lord, investigated this and found that something our tuple implementation was doing (specifically, lots of default template arguments), multiplied by pair’s N^2 overloads, multiplied by how much pair tends to get used by STL programs (e.g. every map), was responsible for the increased memory consumption.  He fixed that, and the fix is making its way over to our STL branch.  At that point, we’ll see if we can raise the _VARIADIC_MAX default to 10 again (as I would prefer not to break existing code unnecessarily).

Randomness: uniform_int_distribution is now perfectly unbiased, and we’ve implemented shuffle() in <algorithm>, which directly accepts Uniform Random Number Generators like mersenne_twister.

Resistance to overloaded address-of operators: C++98/03 prohibited elements of STL containers from overloading their address-of operator.  This is what classes like CComPtr do, so helper classes like CAdapt were required to shield the STL from such overloads.  During VC10′s development, while massively rewriting the STL (for rvalue references, among other things), our changes made the STL hate overloaded address-of operators even more in some situations.  (You might remember one of my VCBlog posts about this.)  Then C++11 changed its requirements, making overloaded address-of operators acceptable.  (C++11, and VC10, provide the helper function std::addressof(), which is capable of getting the true address of an object regardless of operator overloading.)  Before VC10 shipped, we attempted to audit all STL containers for occurrences of “&elem“, replacing them with “std::addressof(elem)” which is appropriately resistant.  In VC11, we’ve gone further.  Now we’ve audited all containers and all iterators, so classes that overload their address-of operator should be usable throughout the STL.  Any remaining problems are bugs that should be reported to us through Microsoft Connect.  (As you might imagine, grepping for “&elem” is rather difficult!)  I haven’t audited the algorithms yet, but a casual glance indicated to me that they aren’t especially fond of taking the addresses of elements.

We’re also going beyond C++11 in a couple of ways:

SCARY iterators: As permitted but not required by the C++11 Standard, SCARY iterators have been implemented, as described by N2911 “Minimizing Dependencies within Generic Classes for Faster and Smaller Programs” and N2980 “SCARY Iterator Assignment and Initialization, Revision 1″.

Filesystem: We’ve added the <filesystem> header from the TR2 proposal, featuring super-cool machinery like recursive_directory_iterator.  Note that the 2006 proposal (before work on TR2 was frozen due to C++0x running extremely late and turning into C++11) was derived from Boost.Filesystem V2.  It later evolved into Boost.Filesystem V3, but that will not be implemented in VC11.

Finally, in addition to numerous bugfixes, we’ve performed a major optimization!  All of our containers (loosely speaking) are now optimally small given their current representations.  This is referring to the container objects themselves, not their pointed-to guts.  For example, vector contains three raw pointers.  In VC10, x86 release mode, vector was 16 bytes.  In VC11, it’s 12 bytes, which is optimally small.  This is a big deal if you have 100,000 vectors in your program – VC11 will save you 400,000 bytes.  Decreased memory usage saves both space and time.

This was achieved by avoiding the storage of empty allocators and comparators, as std::allocator and std::less are stateless.  (We’ll activate these optimizations for custom allocators/comparators too, as long as they’re stateless.  Obviously, we can’t avoid storing stateful allocators/comparators, but those are quite rare.)

Here are all of the sizes for x86 and x64.  (32-bit ARM is equivalent to x86 for these purposes).  Naturally, these tables cover release mode, as debug mode contains checking machinery that consumes space and time.  I have separate columns for VC9 SP1, where _SECURE_SCL defaulted to 1, and for VC9 SP1 with _SECURE_SCL manually set to 0 for maximum speed.  VC10 and VC11 default _SECURE_SCL to 0 (now known as _ITERATOR_DEBUG_LEVEL).

 

x86 Container Sizes (Bytes)	VC9 SP1	VC9 SP1 SCL=0	VC10	VC11
vector<int>	24	16	16	12
array<int, 5>	20	20	20	20
deque<int>	32	32	32	20
forward_list<int> N/A	N/A	N/A	8	4
list<int>	28	12	12	8
priority_queue<int>	28	20	20	16
queue<int>	32	32	24	20
stack<int>	32	32	24	20
pair<int, int>	8	8	8	8
tuple<int, int, int>	16	16	16	12
map<int, int>	32	12	16	8
multimap<int, int>	32	12	16	8
set<int>	32	12	16	8
multiset<int>	32	12	16	8
hash_map<int, int>	72	44	44	32
hash_multimap<int, int>	72	44	44	32
hash_set<int>	72	44	44	32
hash_multiset<int>	72	44	44	32
unordered_map<int, int>	72	44	44	32
unordered_multimap<int, int>	72	44	44	32
unordered_set<int>	72	44	44	32
unordered_multiset<int>	72	44	44	32
string	28	28	28	24
wstring	28	28	28	24

 

x64 Container Sizes (Bytes)	VC9 SP1	VC9 SP1 SCL=0	VC10	VC11
vector<int>	48	32	32	24
array<int, 5>	20	20	20	20
deque<int>	64	64	48	40
forward_list<int>	N/A	N/A	16	8
list<int>	56	24	24	16
priority_queue<int>	56	40	40	32
queue<int>	64	64	48	40
stack<int>	64	64	48	40
pair<int, int>	8	8	8	8
tuple<int, int, int>	16	16	16	12
map<int, int>	64	24	32	16
multimap<int, int>	64	24	32	16
set<int>	64	24	32	16
multiset<int>	64	24	32	16
hash_map<int, int>	144	88	88	64
hash_multimap<int, int>	144	88	88	64
hash_set<int>	144	88	88	64
hash_multiset<int>	144	88	88	64
unordered_map<int, int>	144	88	88	64
unordered_multimap<int, int>	144	88	88	64
unordered_set<int>	144	88	88	64
unordered_multiset<int>	144	88	88	64
string	40	40	40	32
wstring	40	40	40	32

 

Stephan T. Lavavej
Visual C++ Libraries Developer

Visual C++ Team Blog