title: Could multiple proxy classes make up a STL-proof bitvector?
body: <p>It's <a href="http://www.gotw.ca/publications/mill09.htm" rel="noreferrer">well known</a> that <code>std::vector&lt;bool&gt;</code> does not satisfy the Standard's container requirements, mainly because the packed representation prevents <code>T* x = &amp;v[i]</code> from returning a pointer to a bool. </p>
  
  <p>My question is: <strong>can this be remedied/mitigated when the reference_proxy overloads the address-of <code>operator&amp;</code> to return a pointer_proxy?</strong> </p>
  
  <p>The pointer-proxy could contain the same data as the reference_proxy in most implementations, namely a pointer into the packed data and a mask to isolate the particular bit inside the block pointed to. Indirection of the pointer_proxy would then yield the reference_proxy. Essentially both proxies are "fat" pointers, which are, however, still rather light-weight compared to disk-based proxy containers.</p>
  
  <p>Instead of <code>T* x = &amp;v[0]</code> one could then do <code>auto x = &amp;v[0]</code>, and use <code>x</code> like <code>if(*x)</code> without problems. I would also like to be able to write <code>for(auto b: v) { /* ... */ }</code></p>
  
  <p><strong>Questions</strong>: would such a multi-proxy approach work with the STL's algorithms? Or do some algorithms really rely on the requirement that <code>x</code> needs to be a real <code>bool*</code>? Or are there too many consecutive user-defined conversions required that prevent this to work? I'd like to know any of such obstructions before trying to fully complete the above implementation sketch.</p>
  
  <hr>
  
  <p><strong>UPDATE</strong> (based on @HowardHinnant 's answer and this <a href="https://groups.google.com/forum/#!search/vector$20bool$20C$2B$2B$20Kanze/comp.std.c++/lPF9pX1kS1Y/qKYwSrdMUeoJ" rel="noreferrer">ancient discussion</a> on comp.std.c++)</p>
  
  <p>You can come a long way to almost mimic the builtin types: for any given type T, a pair of proxies (e.g. reference_proxy and iterator_proxy) can be made mutually consistent in the sense that reference_proxy::operator&amp;() and iterator_proxy::operator*() are each other's inverse.</p>
  
  <p>However, at some point one needs to map the proxy objects back to behave like T* or T&amp;. For iterator proxies, one can overload operator->() and access the template T's interface without reimplementing all the functionality. However, for reference proxies, you would need to overload operator.(), and that is not allowed in current C++ (although <a href="https://github.com/boostcon/cppnow_presentations_2013/blob/master/thu/overloading_dot.pdf?raw=true" rel="noreferrer">Sebastian Redl presented such a proposal on BoostCon 2013</a>). You can make a verbose work-around like a .get() member inside the reference proxy, or implement all of T's interface inside the reference (this is what is done for vector::bit_reference), but this will either lose the builtin syntax or introduce user-defined conversions that do not have builtin semantics for type conversions (you can have at most one user-defined conversion per argument).</p>