I think the solution is building applications in layers of abstraction. This can permit all/most of the issues related to low level optimization to be addressed in lower layers while upper layers and ignore most of this. This is why I’m a fan of C++. Unfortunately, I think a lot of programing shops miss and just start coding rather than building applications layer by layer. Using C++ in this way causes lots of frustration and confusion.

C++ is a toolbox for making other toolboxes.

Robert Ramey

1. It leaves the impression that one should always write your assignment operator like so:

   T& operator=(T x)    // x is a copy of the source; hard work already done
   {
       swap(*this, x);  // trade our resources for x's
       return *this;    // our (old) resources get destroyed with x
   }
   

   But in some important cases, this is a large performance penalty. Vector-like classes where heap memory can be reused during the copy assignment is a classic example. I’ve just written a short example showing as high as a 7X performance penalty.

2. In C++11 the correct way to write sorted is:

   std::vector<std::string>
   sorted(std::vector<std::string> names)
   {
       std::sort(names.begin(), names.end());
       return names;
   }
   

   Implicit return-by-move from by-value parameters is now required.

The basic point of the article is sound: Passing by value is an important tool in the tool box. But I’ve seen too many references to this article that mistakenly throw design and testing out the window on this issue, and translate this article into “always pass by value”.

format( “There are…”, map(“place”, “heaven “, “and “, “earth”) (“thing”, “philosophy”) );

and you want to implement fill_map so that it maps the first string to the concatenation of the rest.

Is that possible? I am trying to do something similar with proto_arity, but not sure how.

Thank you.

I wish this were crisper, but I would say:

• operator= is unconditionally noexcept
• assignment from an lvalue is noexcept if T’s copy constructor is noexcept
• assignment from an rvalue is noexcept if move-constructing a T is noexcept

So my understanding seems correct: modules could help with organising binaries/libraries/dependencies loaded on the executable beginning. However for plugins/extensions/modules-loaded-on-the-fly you still need something like boost::extension.

Right, also

it’s too easy for people to write code which is inconsistent with the abstractions and the error messages don’t help much.

I did make concepts as I described above. They seemed to work as I hoped – though I certainly had concerns about how much compile time might be affected. And I had a lot of reservations as to whether I was doing it right. I uploaded the code to a trac item as a suggested enhancement to the mpl library. I’ll leave to the others to determine whether this has any value beyond my ?narrow? application.

I did conclude that it was doable – but that it would be better if the concepts built into the library at the start rather than trying to add them on afterwards. That is, I felt that I could have made it work better if I had been willing to stick my fingers into the mpl library which is not ever going to happen. Actually this exercise has led me to a few conclusions.

1. the statement “concepts can be applied to all template arguments” is mostly true
2. but making it mostly true requires more work in many cases than first meets the eye.
3. it doesn’t look to me that an enhancement to C++, e.g. conceptGCC, would change this situation much.
4. the best way to write a library is to develop the documentation, concepts, tests, and code simultaneously so that they are always consistent. I would contrast this with the normal method:
   1. write the library code
   2. write the tests
   3. generate the documentation (with some tool)
   4. insert concepts for templates into the documentation
   5. graft on a tutorial to the documentation
   6. spend the next couple of years fixing up stuff.