[jira] [Commented] (STDCXX-1055) some of the localization class declarations do not follow the ISO/IEC:14882:2003 specification

2012-02-06 Thread Travis Vitek (Commented) (JIRA)

[ 
https://issues.apache.org/jira/browse/STDCXX-1055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13201523#comment-13201523
 ] 

Travis Vitek commented on STDCXX-1055:
--

I'm also unsure how (1) would be detectable and would be interested to see a 
testcase. That said, there seems to be a mix of class/struct among the locale 
and locale facet classes. I don't see any reason to not unconditionally fix 
this, provided it doesn't break due to name mangling on some platforms.

It appears that a conditional fix was put into place for (2) for STDCXX-469. It 
should be automatically enabled for all compilers non Microsoft compilers now, 
and will be automatically fixed for Microsoft if/when stdcxx has a major 
release.

Finally, it seems that (3) would be easy to detect, but I see nothing in the 
standard that requires the {{*_base}} classes to have virtual destructors. The 
derived classes must, but that virtual destructor for those classes should come 
from the base {{std::locale::facet}}.

 some of the localization class declarations do not follow the 
 ISO/IEC:14882:2003 specification
 --

 Key: STDCXX-1055
 URL: https://issues.apache.org/jira/browse/STDCXX-1055
 Project: C++ Standard Library
  Issue Type: Bug
  Components: 22. Localization
Affects Versions: 4.2.1, 4.2.2, 4.2.x, 4.3.x, 5.0.0
 Environment: Solaris 10 and 11, Linux (RedHat and OpenSUSE), Sun C++ 
 Compiler 12.1, 12.2, 12.3, GCC4.
 The defect is independent of platform or compiler.
Reporter: Stefan Teleman
  Labels: conformance, standards
 Fix For: 4.2.x, 4.3.x, 5.0.0

 Attachments: stdcxx-1055.patch


 For the following classes:
 std::codecvt and its specializations
 std::collate and its specializations
 std::ctype and its specializations
 std::ctype_byname and its specializations
 std::messages and its specializations
 std::messages_byname and its specializations
 std::money_get and its specializations
 std::moneypunct and is specializations
 std::moneypunct_byname and its specializations
 std::money_put and its specializations
 std::num_get and its specializations
 std::numpunct and its specializations
 std::numpunct_byname and its specializations
 std::num_put and its specializations
 std::time_get and its specializations
 std::time_get_byname and its specializations
 std::time_put and its specializations
 1. all these type declarations must be of class type (and not of struct type)
 2. all these classes must have protected virtual destructors
 3. all the corresponding *_base (time_base, money_base, etc), must have 
 virtual destructors
 The current implementation of these types as structs (with default public 
 access
 specifier on their non-virtual destructors) causes failures in Perennial 
 CPPVS V8.1.
 Changing the access specifier for these destructors requires some changes in 
 the
 stdcxx tests for localization.
 Patch based on 4.2.1 to follow shortly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (STDCXX-1055) some of the localization class declarations do not follow the ISO/IEC:14882:2003 specification

2012-02-06 Thread Martin Sebor (Commented) (JIRA)

[ 
https://issues.apache.org/jira/browse/STDCXX-1055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13201573#comment-13201573
 ] 

Martin Sebor commented on STDCXX-1055:
--

Changing {{struct}} to {{class}} sounds fine. You're right that the 
{{money_base}} and {{time_base}} classes aren't specified to have virtual 
destructors (and so aren't allowed to have them). It's been too long since I 
looked at the code and I forgot that these weren't facets. For (2) unless we 
can come up with a _strictly conforming_ test case that detects when a dtor is 
protected I'm not convinced we should change it (except under a strict 
conformance macro like {{\_RWSTD_STRICT_ANSI}}).

 some of the localization class declarations do not follow the 
 ISO/IEC:14882:2003 specification
 --

 Key: STDCXX-1055
 URL: https://issues.apache.org/jira/browse/STDCXX-1055
 Project: C++ Standard Library
  Issue Type: Bug
  Components: 22. Localization
Affects Versions: 4.2.1, 4.2.2, 4.2.x, 4.3.x, 5.0.0
 Environment: Solaris 10 and 11, Linux (RedHat and OpenSUSE), Sun C++ 
 Compiler 12.1, 12.2, 12.3, GCC4.
 The defect is independent of platform or compiler.
Reporter: Stefan Teleman
  Labels: conformance, standards
 Fix For: 4.2.x, 4.3.x, 5.0.0

 Attachments: stdcxx-1055.patch


 For the following classes:
 std::codecvt and its specializations
 std::collate and its specializations
 std::ctype and its specializations
 std::ctype_byname and its specializations
 std::messages and its specializations
 std::messages_byname and its specializations
 std::money_get and its specializations
 std::moneypunct and is specializations
 std::moneypunct_byname and its specializations
 std::money_put and its specializations
 std::num_get and its specializations
 std::numpunct and its specializations
 std::numpunct_byname and its specializations
 std::num_put and its specializations
 std::time_get and its specializations
 std::time_get_byname and its specializations
 std::time_put and its specializations
 1. all these type declarations must be of class type (and not of struct type)
 2. all these classes must have protected virtual destructors
 3. all the corresponding *_base (time_base, money_base, etc), must have 
 virtual destructors
 The current implementation of these types as structs (with default public 
 access
 specifier on their non-virtual destructors) causes failures in Perennial 
 CPPVS V8.1.
 Changing the access specifier for these destructors requires some changes in 
 the
 stdcxx tests for localization.
 Patch based on 4.2.1 to follow shortly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (STDCXX-1055) some of the localization class declarations do not follow the ISO/IEC:14882:2003 specification

2012-02-06 Thread Stefan Teleman (Commented) (JIRA)

[ 
https://issues.apache.org/jira/browse/STDCXX-1055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13201735#comment-13201735
 ] 

Stefan Teleman commented on STDCXX-1055:


You aren't verifying that the destructor is virtual or not, because you can't 
really do that without looking inside the __vtbl. You are testing for the value 
of bool virtual_destructor. This variable has nothing to do with the interface 
specification of your class. It isn't even a member of the class. I am not sure 
what this proves.

You are correct: the Standard doesn't require virtual destructors. It doesn't 
*forbid* them, either.

Is there such a variable (bool virtual_destructor) in money_base or time_base 
which would allow for this test?

Also, I am a bit confused at the assertion that destructors cannot be virtual 
(in spite of the fact that there is no way of testing for them), but breaking 
the interface specification of all the localization classes by making their 
destructors public, and therefore allowing direct instantiation, is somehow OK. 
I will submit that one of the purposes of making all these destructors 
protected *was* to make direct instantiation impossible.





 some of the localization class declarations do not follow the 
 ISO/IEC:14882:2003 specification
 --

 Key: STDCXX-1055
 URL: https://issues.apache.org/jira/browse/STDCXX-1055
 Project: C++ Standard Library
  Issue Type: Bug
  Components: 22. Localization
Affects Versions: 4.2.1, 4.2.2, 4.2.x, 4.3.x, 5.0.0
 Environment: Solaris 10 and 11, Linux (RedHat and OpenSUSE), Sun C++ 
 Compiler 12.1, 12.2, 12.3, GCC4.
 The defect is independent of platform or compiler.
Reporter: Stefan Teleman
  Labels: conformance, standards
 Fix For: 4.2.x, 4.3.x, 5.0.0

 Attachments: stdcxx-1055.patch


 For the following classes:
 std::codecvt and its specializations
 std::collate and its specializations
 std::ctype and its specializations
 std::ctype_byname and its specializations
 std::messages and its specializations
 std::messages_byname and its specializations
 std::money_get and its specializations
 std::moneypunct and is specializations
 std::moneypunct_byname and its specializations
 std::money_put and its specializations
 std::num_get and its specializations
 std::numpunct and its specializations
 std::numpunct_byname and its specializations
 std::num_put and its specializations
 std::time_get and its specializations
 std::time_get_byname and its specializations
 std::time_put and its specializations
 1. all these type declarations must be of class type (and not of struct type)
 2. all these classes must have protected virtual destructors
 3. all the corresponding *_base (time_base, money_base, etc), must have 
 virtual destructors
 The current implementation of these types as structs (with default public 
 access
 specifier on their non-virtual destructors) causes failures in Perennial 
 CPPVS V8.1.
 Changing the access specifier for these destructors requires some changes in 
 the
 stdcxx tests for localization.
 Patch based on 4.2.1 to follow shortly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (STDCXX-1055) some of the localization class declarations do not follow the ISO/IEC:14882:2003 specification

2012-02-06 Thread Travis Vitek (Commented) (JIRA)

[ 
https://issues.apache.org/jira/browse/STDCXX-1055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13201788#comment-13201788
 ] 

Travis Vitek commented on STDCXX-1055:
--

Stefan,

I can most definitely tell if the base class destructor is virtual or not. 
Invoking a function (including the destructor) via base class pointer or 
reference will invoke the derived class version of that function if it is 
virtual. This is the basis for polymorphism in C++, and that is exactly what my 
testcase does.

My test shows two things.

# Other implementations of the C++ Standard Library don't have virtual 
destructors for these classes.
# If someone were to write a class deriving from {{time_base}}, and their code 
relied on {{time_base}} having a virtual destructor, the destructor for their 
derived class may not get called (if it is deleted via a base class pointer).

As for making the destructors protected, I think Martin will agree (eventually) 
that they should be (he did supply the testcase and fix for STDCXX-469 for a 
similar issue in {{std::locale::facet}}). The issues that we are currently 
quibbling over is where in the inheritance tree the destructor is supposed to 
be virtual and how to create a testcase that is well-formed and can verify that 
the destructors in the derived classes are protected and not public or private.

 some of the localization class declarations do not follow the 
 ISO/IEC:14882:2003 specification
 --

 Key: STDCXX-1055
 URL: https://issues.apache.org/jira/browse/STDCXX-1055
 Project: C++ Standard Library
  Issue Type: Bug
  Components: 22. Localization
Affects Versions: 4.2.1, 4.2.2, 4.2.x, 4.3.x, 5.0.0
 Environment: Solaris 10 and 11, Linux (RedHat and OpenSUSE), Sun C++ 
 Compiler 12.1, 12.2, 12.3, GCC4.
 The defect is independent of platform or compiler.
Reporter: Stefan Teleman
  Labels: conformance, standards
 Fix For: 4.2.x, 4.3.x, 5.0.0

 Attachments: stdcxx-1055.patch


 For the following classes:
 std::codecvt and its specializations
 std::collate and its specializations
 std::ctype and its specializations
 std::ctype_byname and its specializations
 std::messages and its specializations
 std::messages_byname and its specializations
 std::money_get and its specializations
 std::moneypunct and is specializations
 std::moneypunct_byname and its specializations
 std::money_put and its specializations
 std::num_get and its specializations
 std::numpunct and its specializations
 std::numpunct_byname and its specializations
 std::num_put and its specializations
 std::time_get and its specializations
 std::time_get_byname and its specializations
 std::time_put and its specializations
 1. all these type declarations must be of class type (and not of struct type)
 2. all these classes must have protected virtual destructors
 3. all the corresponding *_base (time_base, money_base, etc), must have 
 virtual destructors
 The current implementation of these types as structs (with default public 
 access
 specifier on their non-virtual destructors) causes failures in Perennial 
 CPPVS V8.1.
 Changing the access specifier for these destructors requires some changes in 
 the
 stdcxx tests for localization.
 Patch based on 4.2.1 to follow shortly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (STDCXX-1055) some of the localization class declarations do not follow the ISO/IEC:14882:2003 specification

2012-02-06 Thread Stefan Teleman (Commented) (JIRA)

[ 
https://issues.apache.org/jira/browse/STDCXX-1055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13201837#comment-13201837
 ] 

Stefan Teleman commented on STDCXX-1055:


{code:title=test_non_virtual.cc|borderStyle=solid}
#include iostream

class foo_base
{
public:
enum { one, two, three, four, five };

foo_base() { }
~foo_base() { std::cerr  foo_base::~foo_base()  std::endl; }
virtual void print() = 0; // because I don't like casting
};

class bar
{
public:
bar() { }
virtual ~bar() { std::cerr  virtual bar::~bar()  std::endl; }
};

class foobar : public foo_base, public bar
{
public:
foobar() { }
virtual ~foobar() { std::cerr  virtual foobar::~foobar()  std::endl; }

virtual void print()
{
std::cerr  one:   one   two:   two   three: 
   three   four:   four   five:   five
   std::endl;
}
};

int main()
{
foo_base* fb = new foobar();

fb-print();
delete fb;

std::cerr.flush();

return 0;
}
{code}

{code:title=test_virtual.cc|borderStyle=solid}
#include iostream

class foo_base
{
public:
enum { one, two, three, four, five };

foo_base() { }
virtual ~foo_base()
{ std::cerr  virtual foo_base::~foo_base()  std::endl; }
virtual void print() = 0; // I don't like casting here either
};

class bar
{
public:
bar() { }
virtual ~bar() { std::cerr  virtual bar::~bar()  std::endl; }
};

class foobar : public foo_base, public bar
{
public:
foobar() { }
virtual ~foobar() { std::cerr  virtual foobar::~foobar()  std::endl; }

virtual void print()
{
std::cerr  one:   one   two:   two   three: 
   three   four:   four   five:   five
   std::endl;
}
};

int main()
{
foo_base* fb = new foobar();

fb-print();
delete fb;

std::cerr.flush();

return 0;
}
{code}

Output from GCC 4.5.0, SunPro C++ 12.2 with the default libCstd, SunPro C++ 
12.2 with stlport, Pathscale 4.0.12.1:

{noformat}
[steleman@darthvader][/src/steleman/programming/stdcxx-upstream-patches/jira-patches][02/06/2012
 18:48:56][2229] ./test_non_virtual_gcc 
one: 0 two: 1 three: 2 four: 3 five: 4
foo_base::~foo_base()
[steleman@darthvader][/src/steleman/programming/stdcxx-upstream-patches/jira-patches][02/06/2012
 18:50:46][2230] ./test_non_virtual_cstd
one: 0 two: 1 three: 2 four: 3 five: 4
foo_base::~foo_base()
[steleman@darthvader][/src/steleman/programming/stdcxx-upstream-patches/jira-patches][02/06/2012
 18:50:56][2231] ./test_non_virtual_stlport
one: 0 two: 1 three: 2 four: 3 five: 4
foo_base::~foo_base()
[steleman@darthvader][/src/steleman/programming/stdcxx-upstream-patches/jira-patches][02/06/2012
 18:51:00][2232] ./test_non_virtual_pathscale
one: 0 two: 1 three: 2 four: 3 five: 4
foo_base::~foo_base()
{noformat}

Do we leak? Yes, we do.

{noformat}
[steleman@darthvader][/src/steleman/programming/stdcxx-upstream-patches/jira-patches][02/06/2012
 18:51:05][2233] ./test_virtual_gcc
one: 0 two: 1 three: 2 four: 3 five: 4
virtual foobar::~foobar()
virtual bar::~bar()
virtual foo_base::~foo_base()
[steleman@darthvader][/src/steleman/programming/stdcxx-upstream-patches/jira-patches][02/06/2012
 18:51:10][2234] ./test_virtual_cstd
one: 0 two: 1 three: 2 four: 3 five: 4
virtual foobar::~foobar()
virtual bar::~bar()
virtual foo_base::~foo_base()
[steleman@darthvader][/src/steleman/programming/stdcxx-upstream-patches/jira-patches][02/06/2012
 18:51:14][2235] ./test_virtual_stlport
one: 0 two: 1 three: 2 four: 3 five: 4
virtual foobar::~foobar()
virtual bar::~bar()
virtual foo_base::~foo_base()
[steleman@darthvader][/src/steleman/programming/stdcxx-upstream-patches/jira-patches][02/06/2012
 18:51:18][2236] ./test_virtual_pathscale
one: 0 two: 1 three: 2 four: 3 five: 4
virtual foobar::~foobar()
virtual bar::~bar()
virtual foo_base::~foo_base()
{noformat}

Do we leak? No, we don't.



 some of the localization class declarations do not follow the 
 ISO/IEC:14882:2003 specification
 --

 Key: STDCXX-1055
 URL: https://issues.apache.org/jira/browse/STDCXX-1055
 Project: C++ Standard Library
  Issue Type: Bug
  Components: 22. Localization
Affects Versions: 4.2.1, 4.2.2, 4.2.x, 4.3.x, 5.0.0
 Environment: Solaris 10 and 11, Linux (RedHat and OpenSUSE), Sun C++ 
 Compiler 12.1, 12.2, 12.3, GCC4.
 The defect is independent of platform or compiler.
Reporter: Stefan Teleman
  Labels: conformance, standards
 Fix For: 4.2.x, 4.3.x, 5.0.0

 Attachments: stdcxx-1055.patch


 For the following classes:
 std::codecvt and its specializations
 std::collate and its specializations
 std::ctype and its specializations
 std::ctype_byname and its specializations
 

[jira] [Commented] (STDCXX-1055) some of the localization class declarations do not follow the ISO/IEC:14882:2003 specification

2012-02-06 Thread Martin Sebor (Commented) (JIRA)

[ 
https://issues.apache.org/jira/browse/STDCXX-1055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13201864#comment-13201864
 ] 

Martin Sebor commented on STDCXX-1055:
--

For (3), the standard allows implementations to add non-virtual member 
functions to library classes (see 17.4.4.4 Member functions), but not virtual 
ones.

For (2), only declarations that are detectable by a conforming program matter 
for conformance. I agree that exposing additional declarations is detrimental 
to portability but it isn't a conformance defect.

The facet dtors were declared protected because facets weren't intended or 
envisioned to be used on their own. They were intended to be used only with the 
locale class they are installed in. Having a public dtor makes it possible to 
easily define an automatic object of the class without having to derive from 
it. Some of the stdcxx faces can be used on their own as an extension. I think 
there may be tests and perhaps even examples that take advantage of this 
feature. 

If we don't think the feature is useful I'm not opposed to declaring the 
derived facet dtors protected, but it has to be done without breaking 
compatibility. It can be done in 4.3 provided it was protected by a macro. It 
can be made the default (without a macro) in 5.0 which is expected to break 
compatibility.

 some of the localization class declarations do not follow the 
 ISO/IEC:14882:2003 specification
 --

 Key: STDCXX-1055
 URL: https://issues.apache.org/jira/browse/STDCXX-1055
 Project: C++ Standard Library
  Issue Type: Bug
  Components: 22. Localization
Affects Versions: 4.2.1, 4.2.2, 4.2.x, 4.3.x, 5.0.0
 Environment: Solaris 10 and 11, Linux (RedHat and OpenSUSE), Sun C++ 
 Compiler 12.1, 12.2, 12.3, GCC4.
 The defect is independent of platform or compiler.
Reporter: Stefan Teleman
  Labels: conformance, standards
 Fix For: 4.2.x, 4.3.x, 5.0.0

 Attachments: stdcxx-1055.patch


 For the following classes:
 std::codecvt and its specializations
 std::collate and its specializations
 std::ctype and its specializations
 std::ctype_byname and its specializations
 std::messages and its specializations
 std::messages_byname and its specializations
 std::money_get and its specializations
 std::moneypunct and is specializations
 std::moneypunct_byname and its specializations
 std::money_put and its specializations
 std::num_get and its specializations
 std::numpunct and its specializations
 std::numpunct_byname and its specializations
 std::num_put and its specializations
 std::time_get and its specializations
 std::time_get_byname and its specializations
 std::time_put and its specializations
 1. all these type declarations must be of class type (and not of struct type)
 2. all these classes must have protected virtual destructors
 3. all the corresponding *_base (time_base, money_base, etc), must have 
 virtual destructors
 The current implementation of these types as structs (with default public 
 access
 specifier on their non-virtual destructors) causes failures in Perennial 
 CPPVS V8.1.
 Changing the access specifier for these destructors requires some changes in 
 the
 stdcxx tests for localization.
 Patch based on 4.2.1 to follow shortly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (STDCXX-1055) some of the localization class declarations do not follow the ISO/IEC:14882:2003 specification

2012-02-06 Thread Stefan Teleman (Commented) (JIRA)

[ 
https://issues.apache.org/jira/browse/STDCXX-1055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13201893#comment-13201893
 ] 

Stefan Teleman commented on STDCXX-1055:


We could #ifdef _RWSTD_STRICT_ANSI guard it in 4.3.x.


 some of the localization class declarations do not follow the 
 ISO/IEC:14882:2003 specification
 --

 Key: STDCXX-1055
 URL: https://issues.apache.org/jira/browse/STDCXX-1055
 Project: C++ Standard Library
  Issue Type: Bug
  Components: 22. Localization
Affects Versions: 4.2.1, 4.2.2, 4.2.x, 4.3.x, 5.0.0
 Environment: Solaris 10 and 11, Linux (RedHat and OpenSUSE), Sun C++ 
 Compiler 12.1, 12.2, 12.3, GCC4.
 The defect is independent of platform or compiler.
Reporter: Stefan Teleman
  Labels: conformance, standards
 Fix For: 4.2.x, 4.3.x, 5.0.0

 Attachments: stdcxx-1055.patch


 For the following classes:
 std::codecvt and its specializations
 std::collate and its specializations
 std::ctype and its specializations
 std::ctype_byname and its specializations
 std::messages and its specializations
 std::messages_byname and its specializations
 std::money_get and its specializations
 std::moneypunct and is specializations
 std::moneypunct_byname and its specializations
 std::money_put and its specializations
 std::num_get and its specializations
 std::numpunct and its specializations
 std::numpunct_byname and its specializations
 std::num_put and its specializations
 std::time_get and its specializations
 std::time_get_byname and its specializations
 std::time_put and its specializations
 1. all these type declarations must be of class type (and not of struct type)
 2. all these classes must have protected virtual destructors
 3. all the corresponding *_base (time_base, money_base, etc), must have 
 virtual destructors
 The current implementation of these types as structs (with default public 
 access
 specifier on their non-virtual destructors) causes failures in Perennial 
 CPPVS V8.1.
 Changing the access specifier for these destructors requires some changes in 
 the
 stdcxx tests for localization.
 Patch based on 4.2.1 to follow shortly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira