From: alf.p.steinbach+usenet@googlemail.com   
      
   On 04.12.2013 19:59, Cassio Neri wrote:   
   >   
   > As far as I understand (someone will correct me if I'm wrong) the Standard   
   > doesn't support containers of const types because 17.6.3.5   
   > [allocator.requirements] only specifies the requirements for allocators   
   > of non-const types.   
      
   Facts OK AFAICS, but that conclusion appears to be too general.   
      
   Because   
      
   * the allocator can be specified explicitly, and   
      
   * AFAICS the only /general/ requirement on container item type in C++11,   
   is that it be Destructible (specified by first row of table 96 in   
   §23.2.1/4), and   
      
   * for some containers, e.g. std::list, and in particular for std::set,   
   const items make sense.   
      
      
   [code]   
   #include    
   #include    
   #include    
   using namespace std;   
      
   auto main() -> int   
   {   
       set, allocator> labels;   
      
       for( auto s : {"B", "A", "B", "E", "L"})   
       { labels.insert( s ); }   
      
       for( auto s : labels )   
       { cout << s << endl; }   
   }   
   [/code]   
      
      
   This compiles nicely with Visual C++ 12.0 (2013), and fails with MinGW   
   g++ 4.7.2, which reports the same overload problem for   
   std::allocator::address as shown by the OP.   
      
   For the OP's vector problem g++ is evidently within its rights (the   
   standard requires the default allocator to be std::allocate where T   
   is the vector item type, and further requires that the allocator value   
   type be non-const and non-reference), and it's not unreasonable either:   
   I'm baffled as to how Visual C++ manages to compile that code!   
      
   But for the above set example, I'd say that there's a bug in the MinGW   
   g++ 4.7.2 standard library implementation.   
      
   Also, if the following statement is inserted before the output loop,   
      
       *labels.begin() = "L";   
      
   then this compiles with Visual C++, which is also clearly a bug[1] (by   
   the 4th row of table 96 in C++11 §23.2.1/4 the `iterator` type should be   
   an "iterator type whose value type is T", with T the container item   
   type, which in this case would be non-assignable `string const`).   
      
   Summing up: Bugs in both g++ and Visual C++, not exactly the same but in   
   the same area of functionality.   
      
   It's not as in the old days :-) when, as I recall it, the probability of   
   a Pascal compiler bug was negligible, when you could trust the tools.   
      
      
   Cheers,   
      
   - Alf   
      
   Notes:   
   [1]   
   https://connect.microsoft.com/VisualStudio/feedback/details/8107   
   6/incorrrect-cv-qualification-of-std-set-t-value-type   
      
      
   --   
         [ 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)