From: francis.glassborow@btinternet.com   
      
   On 19/04/2013 13:04, Ulrich Eckhardt wrote:   
   >   
   > Am 19.04.2013 05:45, schrieb Jonathan Thornburg:   
   >> void print_vector_of_intervals(const std::vector interval*>& vci)   
   > [...]   
   >> However, as written there's a design weakness in the program:   
   >> print_vector_of_intervals() promises in its header comment not to   
   >> change the pointed-to intervals, but its prototype doesn't reflect   
   >> that promise.  So, the "obvious" solution is to uncomment the   
   >> commented-out "const" in print_vector_of_intervals()'s prototype and   
   >> its declaration, so that the prototype looks like this:   
   >>   
   >> void print_vector_of_intervals(const std::vector& vci);   
   >>   
   >> Now the prototype makes explicit the semantics which were previous   
   >> only described in the comments, namely that   
   >> print_vector_of_intervals() won't modify the pointed-to intervals.   
   >> (More precisely, that it won't call any non-const interval:: member   
   >> functions (such as interval::make_empty()) on the pointed-to   
   >> intervals.)   
   >>   
   >> Alas, now main isn't allowed to pass a std::vector to   
   >> print_vector_of_intervals(): Both g++ and clang++ agree that the   
   >> modified code is invalid, because there's no known conversion from   
   >   
   >>   std::vector   
   >> to   
   >>   std::vector   
   >   
   > A vector is not a baseclass or implicitly convertible from a   
   > vector. The const of the passed vector is only applied to its   
   > members, but not to the objects that these members point to. The   
   > compilers are right, and this is a known issue.   
   >   
   >> My basic question is, what to do about this?  That is, what   
   >> design(s) can/should be used (in any/all of C++98, 03, or 11) so   
   >> that client code which has a std::vector can pass (a   
   >> reference to) that vector to a function which promises not to change   
   >> either the vector-of-pointers or the pointed-to objects?   
   >> I can think of two obvious solutions...  each with fairly obvious   
   >> drawbacks:   
   >> (a) omit the "const" in the prototype & declaration of   
   >>     print_vector_of_intervals()   
   >> (b) have client code copy the pointers to a temporary   
   >>     vector-of-pointers-to-const-intervals, and then call   
   >>     print_vector_of_intervals()  on that temporary   
   >>   
   >> Is there an elegant solution that I've overlooked?   
   >   
   > Well, the first solution is not to store unsafe raw pointers in the   
   > first place. If you stored plain objects, the const would propagate   
   > from the container to its elements.   
   >   
      
      
   There is a very real hidden cost in using indirection for placing objects in a   
   container (i.e. using pointers of some form rather than the actual objects);   
   the loss of locality.  In a world of multi-level caches, cache thrashing can   
   very seriously    
   degrade performance.  This can be so serious that copying becomes a viable   
   alternative.   
      
   Of course, sometimes the programmer has no choice but designs that result in   
   vectors of pointers (raw, dumb or smart) need to be viewed with suspicion if   
   the application is in any way sensitive to performance.   
      
   Francis   
      
      
   --   
         [ See http://www.gotw.ca/resources/clcm.htm for info about ]   
         [ comp.lang.c++.moderated.    First time posters: Do this! ]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)