This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libstdc++/16054] basic_string incorrectly handles allocator arguments
- From: "pcarlini at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 18 Jun 2004 12:07:10 -0000
- Subject: [Bug libstdc++/16054] basic_string incorrectly handles allocator arguments
- References: <20040618112601.16054.igodard@pacbell.net>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- 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