just C++ - generic code: first episode
A new video series at Meeting C++: just C++
just C++ - generic code
by Jens Weller
the video:
basics
C++ Weekly Episode 65: C++11's std::fmin—Jason Turner
Episode 65 of C++ Weekly.
C++11's std::fmin
by Jason Turner
About the show:
Jason covers C++11's std::fmin function: why it exists and what it is good for. He then demonstrates how an efficient variadic version of it can be implemented.
Better C++ / Chicago July 12-14, 2017
Join us for a 3 day training event in Chicago, IL, USA July 12-14, 2017
Better C++ / Chicago
by Jason Turner
About the training:
Through this training you will gain a better understanding of how to write clean, maintainable, and well performing C++ code.
The topics covered apply to all types of C++ development: embedded, system or application development.
Jason's classes are highly interactive and have a limited class size to ensure that everyone has sufficient opportunity to participat
A la carte tickets are available for those wishing to attend only part of the training.
Wednesday: Demystifying C++11 and Beyond
C++11, 14, and 17 added many new features to C++ that have made many question the overhead of using these new features and the complexity they add to the language. We will make an in depth examination of these features to give you confidence in using and deploying modern C++ techniques in your organization.
Thursday: Understanding Object Lifetime in C++
C++ has what very few other languages have: a well defined object life cycle. Understanding this key aspect of the language is critical for writing high quality C++.
We will describe the lifecycle of an object in C++ and work through increasingly complex examples. There will be something for C++ developers of all skill levels to learn.Friday: C++ Best Practices
On the final day of the course we will cover a series of tangible best practice rules for how to write C++ code that is maintainable and efficient by default.
We will wrap up with a discussion of how to use the tools available to maintain code quality.
Important semantic effects of small syntax errors -- Matt Wilson
Every C++ programmer should see a bug like this, from Matthew Wilson's post. As a warning.
Important semantic effects of small syntax errors
by Matt Wilson
Reaching out for new speakers at Meeting C++ 2017
An update on the ongoing call for talks for Meeting C++ 2017:
Reaching out for new speakers at Meeting C++ 2017
by Jens Weller
From the article:
Maybe you can help in an ongoing effort for the C++ Community...
There is an ongoing effort, to ensure that everyone feels welcome at our C++ events...
Quick Q:Is there a way to mark a parent's virtual function final from a child class?
Quick A: No.
Recently on SO:
Is there a way to mark a parent's virtual function final from a child class without reimplementing it
No, you can't do it without reimplementing it. So just reimplement it:
struct Child : public Parent { virtual void fn() override final { Parent::fn(); } };N.B. saying
virtual ... override finalis entirely redundant,finalis an error on a non-virtual function, so you should just say:void fn() final { Parent::fn(); }See http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rh-override
Quick Q: shrink_to_fit() vs swap trick
Quick A: Are equivalent, but shrink_to_fit mark the intention.
Recently on SO:
shrink_to_fit() vs swap trick
The swap trick isn't actually constant-time. The cost of performing the actual swap is indeed O(1), but then there's the cost of the
std::vectordestructor firing and cleaning up all the allocated space. That can potentially have cost Ω(n) if the underlying objects have nontrivial destructors, since thestd::vectorneeds to go and invoke those destructors. There's also the cost of invoking the copy constructors for all the elements stored in the initial vector, which is similarly Ω(n).As a result, both approaches should have roughly the same complexity, except that
shrink_to_fitmore clearly telegraphs the intention and is probably more amenable to compiler optimizations.
Quick Q: Syntax of final, override, const with trailing return types
Quick A: The signature of the function is first.
Recently on SO:
Syntax of final, override, const with trailing return types
The correct syntax should be:
- override and final should appear after the member function declaration, which including the trailing return type specification, i.e.
auto debug(ostream& os=cout) const ->ostream& override final;
- override and final should not be used with the member function definition outside the class definition, so just remove them:
auto Derived::debug(ostream& os) const ->ostream& { os << "dval: " << dval << endl; return os; }
Exposing Containers of Unique Pointers -- Jonas Devlieghere
Storing unique pointers in containers is great, but how do you design an API around it?
Exposing Containers of Unique Pointers
by Jonas Devlieghere
From the article:
There's probably no reason to expose to the caller that objects are stored as unique pointers.
Quick Q: Are the experimental features of modern C++ reliable for long-term projects?
Quick A: No
Recently on SO:
Are the experimental features of modern C++ reliable for long-term projects?
Is it guaranteed that all compliant compilers have the same experimental features?No, experimental features are optional.Are experimental features prone to big changes that make them unreliable?Yes, the C++ committee might even decide to abandon a feature or in the process of standardization a defect might come up that would force a feature to change.Generally, it's not a good idea to depend on experimental features. Experimental features are exactly what the word says (i.e., to experiment with).