[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