home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.lang.c++.moderated      Moderated discussion of C++ superhackery      33,346 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 33,051 of 33,346   
   Joshua Maurice to Andy Lutomirski   
   Re: Vector sizes and other missed optimi   
   16 May 13 16:47:52   
   
   bc1ae883   
   From: joshuamaurice@googlemail.com   
      
   On May 16, 12:45 pm, Andy Lutomirski  wrote:   
   > This has been annoying me for a while:   
   >   
   > #include    
   >   
   > template   
   > class Vec   
   > {   
   > public:   
   >   Vec(size_t len) : len_(len) { data_ = new T[len]; }   
   >   ~Vec() { delete data_; }   
   >   Vec(const Vec &) = delete;   
   >   void operator = (const Vec &) = delete;   
   >   
   >   size_t size() const { return len_; }   
   >   T &operator [] (size_t pos) { return data_[pos]; }   
   > private:   
   >   size_t len_;   
   >   T * data_;   
   > };   
   [...]   
   > template   
   > void IncrementVec(Vec &v)   
   > {   
   >   for (size_t i = 0; i < v.size(); i++)   
   >     ++v[i];   
   >   
   > }   
   [...]   
   > Are there any ways, idiomatic or otherwise, to tell a compiler (even in   
   > theory) that data_ can't point to len_?  Adding a restrict qualifier to   
   > data_ has no effect in g++ (correctly AFAICT -- data_ isn't a function   
   > parameter).   
      
   An idiomatic solution to this particular problem? Call size() once   
   outside the loop, store the result in a local variable, and use the   
   local variable in the "for expression" instead of size().   
      
   Ex:   
     size_t n = v.size();   
     for (size_t i = 0; i < n; i++)   
       ++v[i];   
      
   I'd expect a good compiler to be able to optimize that as opposed to   
   the old code. In the old code, a compiler couldn't (easily) know if   
   they were aliasing, but as soon as you create a new local variable,   
   escape analysis should be able to kick in and show that nothing   
   aliases the local variable. At least, that's what I'd expect on a good   
   compiler. Test of course. Also, I don't think this is what you wanted,   
   but it is an "idiomatic" way of solving this very particular problem.   
      
   That would be an interesting language feature though. I wonder how you   
   might specify it correctly and in such a way that it's useful as a   
   general purpose thing. Perhaps that restrict on a member X of a class   
   Y means that the member X and any directly or indirectly pointed-to or   
   contained objects of X will not alias any other member of Y for the   
   same Y object. Maybe.   
      
      
   --   
         [ 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)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca