[Bug libstdc++/16054] basic_string incorrectly handles allocator arguments

pcarlini at suse dot de gcc-bugzilla@gcc.gnu.org
Fri Jun 18 12:07:00 GMT 2004


------- Additional Comments From pcarlini at suse dot de  2004-06-18 12:07 -------
Hi,

> However, the constructor:
>      basic_string(const basic_string& __str);
> has no allocator

this is clearly mandated by the Standard (21.3.1).

> Also, the constructors:
>      basic_string(const basic_string& __str, size_type __pos,
>                   size_type __n = npos);
> and
>      basic_string(const basic_string& __str, size_type __pos,
>                   size_type __n, const _Alloc& __a);
>
> can be merged to:
>      basic_string(const basic_string& __str, size_type __pos,
>                   size_type __n = npos, const _Alloc& __a = _Alloc());

Indeed, the Standard mandates a behavior equivalent to the availability
of the latter. However, it's well known that an implementation is
allowed to deal with default arguments in the way it prefers, for
performance sake or whatelse, f.i., "splitting" a constructor in two 
or more separate constructors: libstdc++-v3 is indeed exploiting
this degree of freedom in many other places (and more will come!)

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16054



More information about the Gcc-bugs mailing list