Re: c++/3795: The "bitset" template from the STL doesn't work properly

Re: c++/3795: The "bitset" template from the STL doesn't work properly

[pme]

Synopsis: The "bitset" template from the STL doesn't work properly

State-Changed-From-To: analyzed->closed
State-Changed-By: pme
State-Changed-When: Wed Jul 25 13:45:12 2001
State-Changed-Why:
    
    I mentioned that (1) was not a bug, and showed
    a workaround for (2).  Turns out that it isn't
    just a workaround; you have to do it that way.
    (Blech.)  My passing thought for improvement was
    
      [one must write]
      bs.to_string<char,char_traits<char>,allocator<char> >()
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      to instantiate the member template function.
      Although I would argue that the signature
      preceeding [23.3.5.2]/33 should allow the second
      and third template arguments to have default
      values, like basic_string<char> does, so that
    
      bs.to_string<char>()
    
      could work.
    
    Useful, but alas, invalid.  [14.1]/9 forbids
    exactly that, but I didn't think of it until
    today.  So, no bugs all around.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=3795&database=gcc

Re: c++/3795: The "bitset" template from the STL doesn't work properly

[pme]

Synopsis: The "bitset" template from the STL doesn't work properly

Responsible-Changed-From-To: unassigned->pme
Responsible-Changed-By: pme
Responsible-Changed-When: Tue Jul 24 12:05:33 2001
Responsible-Changed-Why:
    Priority changed to low because there is a workaround.
State-Changed-From-To: open->analyzed
State-Changed-By: pme
State-Changed-When: Tue Jul 24 12:05:33 2001
State-Changed-Why:
    Thank you for your bug report.
    
    As far as (1) goes, this is not a bug.  In fact,
    this has already been reported to the ISO C++
    committee with the note, "...the user cannot
    pass this template constructor a const char* and
    expect a conversion to basic_string.  The reason
    is "When you have a template constructor, it can
    get used in contexts where type deduction can
    be done. Type deduction basically comes up with
    exact matches, not ones involving conversions.""
    
    The LWG's response is, "Although the problem
    is real, the standard is designed that way
    so it is not a defect.  Education is the
    immediate workaround. A future standard may
    wish to consider the Proposed Resolution as
    an extension."  The proposed resolution was to
    add another constructor taking a const char*.
    
    
    Okay, problem (2)... yeah, that does seem kinda
    stupid, but I can understand the reasoning.
    (This may not even be a defect in the standard,
    in which case one of the people on the LWG can
    close this PR.)  The tricky part is that string
    is a templated type, and bitset<> doesn't know
    what parameters to use when instantiating the
    string returned from to_string().  You need
    to write
    
    bs.to_string<char,char_traits<char>,allocator<char> >()
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    
    to instantiate the member template function.
    Although I would argue that the signature
    preceeding [23.3.5.2]/33 should allow the second
    and third template arguments to have default
    values, like basic_string<char> does, so that
    
    bs.to_string<char>()
    
    could work.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=3795&database=gcc