Dhruv Matani wrote:
http://groups.google.co.in/groups?q=vector+constructor+author:
gabriel...
Ok. We should thank Gaby for this explanation.
Anyway, the basic example, not involving user allocators, still works.
On the other hand:
/usr/local/gcc-exp/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../
include/c++/4.0.0/bits/stl_uninitialized.h:294: error: no matching
function for call to '__gnu_cxx::__mt_alloc<dvector_t,
__gnu_cxx::__common_pool_policy<true> >::construct(dvector_t*, const
int&)'
/usr/local/gcc-exp/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../
include/c++/4.0.0/ext/mt_allocator.h:613: note: candidates are: void
__gnu_cxx::__mt_alloc_base<_Tp>::construct(_Tp*, const _Tp&) [with _Tp
= dvector_t]
This is, actually, *another* issue and indeed happens because now
(after Matt's changes
this summer) the user-provided allocator is used throughout.
I'm not at all convinced that in _M_initialize_dispatch(__true_type)
we should always
cast __value (an integer) to value_type (that is, in the example, a
dvector_t). Honestly,
I'm under the impression that we are slightly abusing those
overloads...
I think we should ask Matt, in the first place: he is """guilty""" of
this """regression"""...
Matt, should this testcase compile:
#include <vector>
#include <ext/pool_allocator.h>
using __gnu_cxx::__pool_alloc;
typedef std::vector<double, __pool_alloc<double> > dvector_t;
typedef std::vector<dvector_t, __pool_alloc<dvector_t> > matrix_t;
matrix_t m = matrix_t(1, 1);