C++14 Is Set In Stone

jones_supa (887896) writes "Apart from minor editorial tweaks, the ISO C++14 standard can be considered completed. Implementations are already shipping by major suppliers. C++14 is mostly an incremental update over C++11 with some new features like function return type deduction, variable templates, binary literals, generic lambdas, and so on. The official C++14 specification release will arrive later in the year, but for now Wikipedia serves as a good overview of the feature set."

Comments

Still...

[fyngyrz]

...using c. Although I do like to comment thusly, and so prefer a compiler that understands at least basic c++:

// comment

I like to stay as close to the metal as I can get. I'd use assembler, but many of my projects are cross platform, so c it is.

Re:Still...

[fyngyrz]

Have you ever written C code which uses a switch statement based on what type a struct/union is and calling the relevant code for it?

No. When I use structures as objects (which is often), they almost always contain a pointer to a block of general methods appropriate to that structure, as well as containing any methods unique to the object, all of which are called through the object/structure, so it would be unusual, at least, to be testing the object type in order to choose an object-specific procedure to call. However, I do mark each object type with a specific ID and serial as they are created, along with a tag indicating what procedure created them, as these things facilitate some very useful memory management and diagnostic mechanisms.

Have you ever used qsort?

I am aware of qsort. But I have my own multi-method sort library that I use. Most of them locate the comparison mechanisms they are to use through the procedures specified by the objects they are asked to sort. Likewise list management, memory management, certain types of drawing primitives and image processing primitives, image handling mechanisms, associative storage, basically anything I have run into that I thought likely I would need more than once. I am positively locked into the idea that if I write it, I can fix it, and the number of bugs and problems that fall into the "maybe they'll fix the library someday" class are greatly reduced. I'm a little less picky if I have the source code to a capability I didn't actually write and can supply my own version if and as needed. A good example of something like that is SQLite. Actually having the source code and compiling it in reduces my inherent paranoia to a somewhat duller roar.

Re:Why do we need Auto?

[Anonymous Coward]

I used to think that, until I realized:

auto handler = boost::bind(&Class::write_callback, this, boost::ref(timer), boost::asio::placeholders::error, boost::asio::placeholders::bytes_transferred);

/// what is the type of handler?
boost::asio::async_write(device, buffer, handler);

Iterators another good one:

typedef void (*FunctionPtr)();
std::map<std::string, FunctionPtr> knownCommands;

/// elsewhere:
std::string command = "example";

/// what do you like more?
std::map<std::string, FunctionPtr>::iterator it = knownCommands.find(command);

/// or
auto it = knownCommands.find(command);

if (it != knownCommands.end()) { /* do something useful */ }

Re:Oh god so what?

[ShanghaiBill]

But here's the catch: you're not supposed to know it all. C++ is like a large store where you go and "shop" just the features you need. You can keep it super simple and write C-style code and just use classes as the only C++ feature, if you want to.

That is fine if you are a team of one, and you never read code written by others.