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

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

[igodard at pacbell dot net]

library bits/basic_string:
As in all other C++ standard types that use dynamic allocation,all constructor
forms of the the class std::basic_string should take an allocator argument with
a default value; the default being the default-constructor of the allocator
type of the template.

However, the constructor:
      basic_string(const basic_string& __str);
has no allocator and:
      basic_string(const basic_string& __str, size_type __pos,
                 size_type __n, const _Alloc& __a);
has no default.


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());

-- 
           Summary: basic_string incorrectly handles allocator arguments
           Product: gcc
           Version: 3.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: libstdc++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: igodard at pacbell dot net
                CC: gcc-bugs at gcc dot gnu dot org


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

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

[pcarlini at suse dot de]

------- 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

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

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2004-06-18 12:41 -------
>> However, the constructor:
>>      basic_string(const basic_string& __str);
>> has no allocator
>
> this is clearly mandated by the Standard (21.3.1).

Forgot to add: 21.3.1, p5 says: "In the first form, the Allocator value used is
copied from str.get_allocator()". Actually we had a bug in the implementation
of this constructor (libstd++/14245), already fixed for 3.4.1.

-- 


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

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

[igodard at pacbell dot net]

------- Additional Comments From igodard at pacbell dot net  2004-06-18 19:26 -------
Should this be filed as a Defect Report to the Standard? It's clearly inconsistent with pretty mush everything else in the library.

Ivan

-- 


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