C++14 Is Set In Stone 193
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."
Still... (Score:4, Interesting)
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... (Score:5, Interesting)
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.
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? (Score:3, Interesting)
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);
boost::asio::async_write(device, buffer, handler);
Iterators another good one:
typedef void (*FunctionPtr)();
std::map<std::string, FunctionPtr> knownCommands;
std::string command = "example";
std::map<std::string, FunctionPtr>::iterator it = knownCommands.find(command);
/// or
auto it = knownCommands.find(command);
if (it != knownCommands.end()) {
Re:Oh god so what? (Score:5, Interesting)
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.