0f9cf28a   
   From: alf.p.steinbach+usenet@gmail.com   
      
   On 12.04.2012 12:05, rossmpublic@gmail.com wrote:   
   > On Tuesday, April 10, 2012 11:14:08 AM UTC-7, Alf P. Steinbach wrote:   
   >> The compiler is able to do it within the current language, but it's   
   >> constrained by   
   >>   
   >>    * the problem of aliasing, i.e. correctness violation, and   
   >>   
   >>    * depending on the solution, a combinatorial explosion, and that   
   >>   
   >>    * depending on the solution, the linker must support the scheme.   
   >   
   > Thanks for the analysis Alf. On the surface it looks like the   
   > separate compilation model sinks attempts to provide input value   
   > optimization as Dave Abrahams mentioned. But perhaps a really robust   
   > compiler/linker would be able to do it?   
      
   With the flags approach that I described you don't need additional   
   linker support.   
      
   But it might be premature optimization.   
      
   It could be that at least for some programs it would, in total, slow   
   things down to pass those flags everywhere, e.g. because one less   
   register was available, or whatever.   
      
   > Here's what I've been thinking. Let's start with something simple:   
   >   
   >    - Only apply optimization to classes with non trivial constructors   
   >      or POD classes of a certain size. To avoid pessimizations.   
   >   
   >    - Restrict candidates for this optimization to parameters   
   >      that are only copied inside the function.   
   >   
   >    - If the parameter is passed by reference to any function (including   
   >      constructors) it cannot be optimized. Perhaps we may want to   
   >      allow const references for an aggressive optimization strategy but   
   >      this would not be strictly correct/conforming.   
      
   Wrt. passing further to some reference to const formal argument, the   
   main solution to the problem that the compiler can't guarantee the one   
   in a trillion trillion'th case in Very Bad Code, is to let the   
   programmer take responsibility. Leave the programmer in control. Much   
   is impossible if the compiler must do it all alone, because, well, if   
   it was outfitted with the necessary smarts then it would be very much   
   too slow! But with a little help from the programmer, which is what   
   many of the keywords in C++ are about, very little remains as   
   impossible. E.g.  in this case the help could take the form of some   
   attribute which, if present, prevents the optimization, e.g. because   
   there's a call to a function that modifies in spite of promising not   
   to.   
      
   Of course, it would then be a kind of absurd situation where one   
   programmer is adding an attribute saying that another programmer (or   
   possibly him/her self) incorrectly added "const" to some formal arg.   
      
   Anyway, with such a more practical solution (programmer decides in   
   dubious case) the "cannot be optimized" is happily not correct. And   
   likewise, "would not be correct" is then happily not correct. It can   
   be optimized, and it will be correct, just not wrt. the current   
   language.   
      
   With the absence of an attribute taken as general leave to optimize,   
   an argument of type "cv T" is a candidate for optimization if, say,   
   the Boost function that produces good argument types changes the   
   type. Then furthermore there must be no potential modification of that   
   argument, under the assumption (provided by absence of attribute) that   
   "const" really means "not modified". Under these conditions the   
   optimization is permitted for that argument. Whether copying will   
   actually be done in any particular call, then depends on the   
   corresponding flag passed by the caller. If the call site promises via   
   this argument's flag that there is no possible aliasing, then copying   
   will be avoided. And what's nice about that is that the caller can   
   pass those flags also to a non-optimized function, which then will   
   copy regardless of the flags.  I.e. each call site does not need to   
   know whether the function implementation supports the optimization or   
   not -- each call site's responsibility is just to decide whether it   
   can guarantee non-aliasing.   
      
      
   >    - The goal is to guarantee that when the function exits that the   
   >      parameter will not be modified if it is passed by reference.   
   >      Therefore we can create a single optimized version of the function   
   >      call and avoid the combinatorial explosion. Alf?   
      
   Oh yes, that's simple, as I wrote.   
      
   Instead of different variants of function, just a single function with   
   a hidden flags argument.   
      
   Where the flags carry each call site's knowledge of aliasing, into the   
   function.   
      
      
   >    - Now the hand-waving part! Somehow when the linker mashes the   
   >      entire executable together it needs to substitute the non-optimized   
   >      calls to the optimized ones. I need some help on this part.   
      
   Huh.   
      
      
   > I'll add an additional observation at this point:   
   >   
   > This optimization will never work for virtual function calls,   
   > so the pass by reference hand optimization may never be completely   
   > eliminated from the language.   
      
   As an exercise, imagine the optimization is done, with the flags   
   approach.   
      
   Then it just works.   
      
      
   >> A partial solution, to avoid all three of those problems, is to use   
   >> immutable types with reference semantics.   
   >   
   > Can you elaborate a little more on this point? Do you mean that if we   
   > had a concept of an immutable class that the compiler could recognize   
   > then we could more easily apply copy optimizations?   
      
   With immutable types with reference semantics there is no copying   
   (except of small pointer). Think Java strings. You can reassign a Java   
   string variable, but that doesn't copy the string value.   
      
   Neither is there any modification of the string value.   
      
   So, the problem is then just not relevant.   
      
      
   >> Also, for the particular case of `std::string` another partial   
   >> solution is to use a COW (Copy On Write) implementation, which I   
   >> believe is still how the implementation for g++ works.   
   >   
   > Maybe we just need copy on write objects? This may solve some copying   
   > issues.   
      
   Scott Meyers, I think it was, recently remarked that COW is not   
   permitted for std::string under C++11 rules.   
      
   I'm not sure if that's correct, but with threading in the picture it   
   sounds quite plausible.   
      
   The nice thing about one's own types is that they can be more   
   practical wrt. safety, at least with 20-20 hindsight. Where   
   std::string is needlessly unsafe (e.g. construction from 0), one's own   
   type can be safe, and where std::string (reportedly) has to support   
   safe operations in some kind of multi-thread scenario, I don't know   
   exactly what but something that affects COW, one's own type can just   
   happily and more practically pass the problem on to the   
   programmer. Don't use me that way, or else add synchronization!   
      
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)