On 22/01/15 16:07 -0600, Joel Sherrill wrote:
On 1/22/2015 3:44 PM, Marc Glisse wrote:
On Thu, 22 Jan 2015, Joel Sherrill wrote:
I think this is a glibc issue but since this method is defined in the C++
standards, I thought there were plenty of language lawyers here. :)
s/glibc/libstdc++/ and they have their own ML.
Thank you.
<strstream>
That's deprecated, isn't it?
Yes. There is also a warning about that coming from the test code.
I don't know how long it has been deprecated since even with
-std=c++03, the warning is present.
Those types were deprecated even in the first C++ standard in 1998.
They were born deprecated, and have remained so ever since.
class strstreambuf : public basic_streambuf<char, char_traits<char> >
ISSUE ====> int pcount() const; <===== ISSUE
My reading of the C++03 and draft C++14 says that the int pcount() method
in this class is not const. glibc has it const in the glibc shipped with
Fedora 20
and CentOS 6.
This is a simple test case:
#include <strstream>
int main() {
int (std::strstreambuf::*dummy)() = &std::strstreambuf::pcount;
/*-- pcount is conformant --*/
return 0;
}
What's the consensus?
The exact signature of member functions is not mandated by the standard,
implementations are allowed to make the function const if that works (or
provide both a const and a non-const version). Your code is not guaranteed
to work. Lambdas usually provide a fine workaround.
This code is actually from the Open Group FACE Conformance Test Suite.
It uses code like this to check the presence of methods from the C Standard
Library, POSIX APIs, and the C++ Standard Library. It would be really
helpful
if you could cite the place in the C++ standard so I can provide that as
feedback
to the authors of the test suite.
17.6.5.5 [member.functions] gives implementors certain freedoms to
provide slightly different signatures to those described in the
standard, including this:
-2- It is unspecified whether any member functions in the C++ standard
library are defined as inline (7.1.2). An implementation may
declare additional non-virtual member function signatures within a
class:
— by adding arguments with default values to a member function
signature;(187)
— ...
187) Hence, the address of a member function of a class in the C++
standard library has an unspecified type.
The footnote makes it clear that we could declare strstreambuf::pcount
as a function with one or more parameters, as long as we give them
default values, meaning that the type of &std::strstreambuf::pcount is
not guaranteed to be int (strstreambuf::*)() in a conforming
implementation, so the conformance test could fail on an
implementation that conforms 100% to the standard.
I'm not sure if that gives us the liberty to add 'const' where the
standard doesn't have it, so this might be a real non-conformance
issue, but even if we fixed it their test is not guaranteed to work
for other reasons.
On a positive note, the test suite isn't flagging much using this
technique. This
may be the only method. But I would like to provide the correct feedback to
them so no one else deals with this.
IMHO the correct feedback for these deprecated types might be "Hmm,
you're right. Oh well, nevermind, we're not going to bother fixing it
now."
Any real program using the pcount() member will work correctly with
our implementation. In practice only conformance tests are likely to
notice the difference.
