static templates in BOOST
We recently corrected the way our compiler (Sun C++) handles static templates, and ran into a problem with some BOOST code. More than 100 tests in the suite depend on code like this: template <typename T> struct S { void foo(int); }; template<class T , class U> static // static template ... void smart_cast_reference(U& u) {} template <typename T> void S<T>::foo(int c) { smart_cast_reference< T& >(c); // used in global function } int main() { S<int> s; s.foo(1); } You can't use a static template in a global template function because it violates the One-Definition Rule, among possibly other rules. I have found that other compilers accept this code, but reject it when you put them in standard-conformning mode. (To see the rejection with some compilers, you need to build the executable.) How critical to BOOST is this style of coding? Could the static templates be made global? --- Steve Clamage, stephen.clamage@sun.com
Steve Clamage wrote:
We recently corrected the way our compiler (Sun C++) handles static templates, and ran into a problem with some BOOST code. More than 100 tests in the suite depend on code like this:
template <typename T> struct S { void foo(int); };
template<class T , class U> static // static template ... void smart_cast_reference(U& u) {}
template <typename T> void S<T>::foo(int c) { smart_cast_reference< T& >(c); // used in global function }
int main() { S<int> s; s.foo(1); }
You can't use a static template in a global template function because it violates the One-Definition Rule, among possibly other rules. I have found that other compilers accept this code, but reject it when you put them in standard-conformning mode. (To see the rejection with some compilers, you need to build the executable.)
How critical to BOOST is this style of coding? Could the static templates be made global?
--- Steve Clamage, stephen.clamage@sun.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I have a sneaking feeling I might be a priniciple culprit here. Steve Clamage wrote:
You can't use a static template in a global template function because it violates the One-Definition Rule, among possibly other rules.
Could you expand upon this a little more? I don't see the ODR violation or other rule violation.
I have found that other compilers accept this code, but reject it when you put them in standard-conformning mode. (To see the rejection with some compilers, you need to build the executable.)
How critical to BOOST is this style of coding? Could the static templates be made global?
Generally we aspire to make our code conform to the standard. If its not, then we're interested in changing it so it is. Having said that, It's often very difficult to figure out what the standard means. Of course the fact that different compilers behave differently also makes it hard. Of course if you want to make your compiler available to library writers at a reasonable cost (i.e. free) you might manage to shift some work on to us. Robert Ramey
Slightly different and simplified example: template<class U> static void smart_cast_reference(U& u) {} template <typename T> void foo(int c) { smart_cast_reference<int>(c); } Suppose (global) template foo is instantiated in more than one translation unit. Since smart_cast_reference does not have external linkage, not all instances of foo can refer to the same instance of smart_cast_reference<int>, and the ODR is violated. I'm pretty sure there is a name-lookup rule that makes this test case invalid, but I haven't found it yet. (Still looking.) --- Steve Clamage, stephen.clamage@sun.com Robert Ramey wrote:
I have a sneaking feeling I might be a priniciple culprit here.
Steve Clamage wrote:
You can't use a static template in a global template function because it violates the One-Definition Rule, among possibly other rules.
Could you expand upon this a little more? I don't see the ODR violation or other rule violation.
I have found that other compilers accept this code, but reject it when you put them in standard-conformning mode. (To see the rejection with some compilers, you need to build the executable.)
How critical to BOOST is this style of coding? Could the static templates be made global?
Generally we aspire to make our code conform to the standard. If its not, then we're interested in changing it so it is. Having said that, It's often very difficult to figure out what the standard means. Of course the fact that different compilers behave differently also makes it hard.
Of course if you want to make your compiler available to library writers at a reasonable cost (i.e. free) you might manage to shift some work on to us.
Robert Ramey
OK I see this now. I was confused as I never noticed I did this. I have used static member functions a lot so that confused me also. Now I have a question. I noticed I used something like the following a few times (access.hpp) template<class U> static inline void smart_cast_reference(U& u) {} template <typename T> void foo(int c) { smart_cast_reference<int>(c); } I wouldn't expect that to cause any linking problems (note the "inline") which is perhaps why no other compilers complain. What SHOULD I be doing here? Robert Ramey
Robert Ramey wrote:
OK I see this now. I was confused as I never noticed I did this. I have used static member functions a lot so that confused me also. Now I have a question.
I noticed I used something like the following a few times (access.hpp)
template<class U> static inline void smart_cast_reference(U& u) {}
template <typename T> void foo(int c) { smart_cast_reference<int>(c); }
I wouldn't expect that to cause any linking problems (note the "inline") which is perhaps why no other compilers complain. What SHOULD I be doing here?
Robert Ramey
This example is OK because the instance of smart_cast_reference that is called does not depend on foo's template parameter. --- Steve Clamage, stephen.clamage@sun.com
Upon reflection, I'm going to retract my guilty plea. I am only using static inside of class definition. I presume this doesn't violate any rules. Your original example used smart_cast which is used only by me as far as I know. So I presumed I was the culprit. So now the question is: Where in the code do you find the static free functions? Since you guys are using boost to test your compiler, maybe you could become an official boost tester and and share your results? Robert Ramey
I found the relevent citation, with a little help from my friends. 14.6.4.2 "Candidate functions" says that for an unqualified function call that depends on a template parameter, only functions with external linkage are considered. --- Steve Clamage, stephen.clamage@sun.com Robert Ramey wrote:
I have a sneaking feeling I might be a priniciple culprit here.
Steve Clamage wrote:
You can't use a static template in a global template function because it violates the One-Definition Rule, among possibly other rules.
Could you expand upon this a little more? I don't see the ODR violation or other rule violation.
I have found that other compilers accept this code, but reject it when you put them in standard-conformning mode. (To see the rejection with some compilers, you need to build the executable.)
How critical to BOOST is this style of coding? Could the static templates be made global?
Generally we aspire to make our code conform to the standard. If its not, then we're interested in changing it so it is. Having said that, It's often very difficult to figure out what the standard means. Of course the fact that different compilers behave differently also makes it hard.
Of course if you want to make your compiler available to library writers at a reasonable cost (i.e. free) you might manage to shift some work on to us.
Robert Ramey
"Robert Ramey" <ramey@rrsd.com> writes:
Of course if you want to make your compiler available to library writers at a reasonable cost (i.e. free) you might manage to shift some work on to us.
Robert, Steve has already very generously provided OSL with copies of the Sun compiler that are being used in regular regression tests. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote in message news:u7jg3357t.fsf@boost-consulting.com...
"Robert Ramey" <ramey@rrsd.com> writes:
Of course if you want to make your compiler available to library writers at a reasonable cost (i.e. free) you might manage to shift some work on to us.
Robert, Steve has already very generously provided OSL with copies of the Sun compiler that are being used in regular regression tests.
Hum... I've not seen any SUN regression tests from OSL. Are they posted at a different location? --Beman
"Beman Dawes" <bdawes@acm.org> writes:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:u7jg3357t.fsf@boost-consulting.com...
"Robert Ramey" <ramey@rrsd.com> writes:
Of course if you want to make your compiler available to library writers at a reasonable cost (i.e. free) you might manage to shift some work on to us.
Robert, Steve has already very generously provided OSL with copies of the Sun compiler that are being used in regular regression tests.
Hum... I've not seen any SUN regression tests from OSL. Are they posted at a different location?
Not sure what the story is; maybe they haven't got them set up yet, or maybe they decided that http://engineering.meta-comm.com/boost-regression/CVS-HEAD/CalebEpstein.html was a redundant duplicate so why bother? Doug? -- Dave Abrahams Boost Consulting www.boost-consulting.com
On Jul 7, 2005, at 8:28 AM, David Abrahams wrote:
"Beman Dawes" <bdawes@acm.org> writes:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:u7jg3357t.fsf@boost-consulting.com...
"Robert Ramey" <ramey@rrsd.com> writes:
Of course if you want to make your compiler available to library writers at a reasonable cost (i.e. free) you might manage to shift some work on to us.
Robert, Steve has already very generously provided OSL with copies of the Sun compiler that are being used in regular regression tests.
Hum... I've not seen any SUN regression tests from OSL. Are they posted at a different location?
Not sure what the story is; maybe they haven't got them set up yet, or maybe they decided that http://engineering.meta-comm.com/boost-regression/CVS-HEAD/ CalebEpstein.html was a redundant duplicate so why bother? Doug?
We do have the compiler (for the upcoming release of Sun Studio), but do not yet have it installed and configured to run Boost regressions. Doug
Beman Dawes wrote:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:u7jg3357t.fsf@boost-consulting.com...
"Robert Ramey" <ramey@rrsd.com> writes:
Of course if you want to make your compiler available to library writers at a reasonable cost (i.e. free) you might manage to shift some work on to us.
Robert, Steve has already very generously provided OSL with copies of the Sun compiler that are being used in regular regression tests.
Hum... I've not seen any SUN regression tests from OSL. Are they posted at a different location?
--Beman
OSL is currently getting the beta versions of our next compiler release (Sun Studio 10 update 1, C++ 5.8). Sun C++ still has many BOOST test failures. We found the problem with static templates in an internal compiler update that we won't distribute until we resolve which failures are errors in BOOST, and which are compiler bugs. --- Steve Clamage, stephen.clamage@sun.com
On Jul 7, 2005, at 8:55 AM, Steve Clamage wrote:
OSL is currently getting the beta versions of our next compiler release (Sun Studio 10 update 1, C++ 5.8). Sun C++ still has many BOOST test failures. We found the problem with static templates in an internal compiler update that we won't distribute until we resolve which failures are errors in BOOST, and which are compiler bugs.
Just a follow-up: I've installed the Sun compilers on one of our OSL systems. It shows up as "OSL4" (sunpro-5_8u1-sunos) on the regression tests. It's far too late in the Boost release cycle to consider it a release platform, but we'll be running the tests nightly regardless. Doug
On Thu, 7 Jul 2005 21:29:09 -0500, Douglas Gregor wrote
Just a follow-up: I've installed the Sun compilers on one of our OSL systems. It shows up as "OSL4" (sunpro-5_8u1-sunos) on the regression tests. It's far too late in the Boost release cycle to consider it a release platform, but we'll be running the tests nightly regardless.
This is interesting. Looks like Sun has made some serious forward progress. By my eye it looks like about 1/2 of the date-time tests now pass. And that's a bit deceiving as it looks like a handful of problems are preventing most of the rest from compiling. As usual, it's I/O that's at the root of a big chunk of the problems. As I recall when Caleb was running SunPro almost none of date-time would compile... Jeff
Jeff Garland wrote:
On Thu, 7 Jul 2005 21:29:09 -0500, Douglas Gregor wrote
Just a follow-up: I've installed the Sun compilers on one of our OSL systems. It shows up as "OSL4" (sunpro-5_8u1-sunos) on the regression tests. It's far too late in the Boost release cycle to consider it a release platform, but we'll be running the tests nightly regardless.
This is interesting. Looks like Sun has made some serious forward progress. By my eye it looks like about 1/2 of the date-time tests now pass. And that's a bit deceiving as it looks like a handful of problems are preventing most of the rest from compiling. As usual, it's I/O that's at the root of a big chunk of the problems. As I recall when Caleb was running SunPro almost none of date-time would compile...
Only one Iiostreams tests passes. All the errors I've checked are either internal errors or problems with is_abstract. is_abstract_test, from type traits, is also failing. Config defines BOOST_NO_IS_ABSTRACT for __SUNPRO_CC < 0x570; I wonder if this needs to be defined for 0x580? Jonathan
The macro BOOST_NO_IS_ABSTRACT should be defined. Also, be sure you are using the option -library=stlport4 on every CC command line. The configuration files for Sun should set up that option already. --- Steve Clamage, stephen.clamage@sun.com Jonathan Turkanis wrote:
Jeff Garland wrote:
On Thu, 7 Jul 2005 21:29:09 -0500, Douglas Gregor wrote
Just a follow-up: I've installed the Sun compilers on one of our OSL systems. It shows up as "OSL4" (sunpro-5_8u1-sunos) on the regression tests. It's far too late in the Boost release cycle to consider it a release platform, but we'll be running the tests nightly regardless.
This is interesting. Looks like Sun has made some serious forward progress. By my eye it looks like about 1/2 of the date-time tests now pass. And that's a bit deceiving as it looks like a handful of problems are preventing most of the rest from compiling. As usual, it's I/O that's at the root of a big chunk of the problems. As I recall when Caleb was running SunPro almost none of date-time would compile...
Only one Iiostreams tests passes. All the errors I've checked are either internal errors or problems with is_abstract. is_abstract_test, from type traits, is also failing.
Config defines BOOST_NO_IS_ABSTRACT for __SUNPRO_CC < 0x570; I wonder if this needs to be defined for 0x580? Jonathan
"Steve Clamage" <Stephen.Clamage@Sun.COM> wrote in message news:42CF3A0A.5020702@sun.com...
The macro BOOST_NO_IS_ABSTRACT should be defined.
Also, be sure you are using the option -library=stlport4 on every CC command line. The configuration files for Sun should set up that option already.
Hum... The command line for a failing filesystem compile was: /opt/sunstudio10u1/SUNWspro/bin/CC -c -g -xtarget=generic +d -features=rtti -features=except -I"/tmp/dgregor/BoostRegressionTesting/results/bin/boost/libs/filesystem/build" -I"/tmp/dgregor/BoostRegressionTesting/boost" -I"/usr/include" -I"/tmp/dgregor/BoostRegressionTesting/boost" -o "/tmp/dgregor/BoostRegressionTesting/results/bin/boost/libs/filesystem/build/libboost_filesystem.a/sunpro-5_8u1-sunos/debug/exception.o" "/tmp/dgregor/BoostRegressionTesting/boost/libs/filesystem/build/../src/exception.cpp" So it looks like we need to add -library=stlport4 to the jamfile. Doug? Thanks, --Beman
Beman Dawes wrote:
"Steve Clamage" <Stephen.Clamage@Sun.COM> wrote in message news:42CF3A0A.5020702@sun.com...
The macro BOOST_NO_IS_ABSTRACT should be defined.
Also, be sure you are using the option -library=stlport4 on every CC command line. The configuration files for Sun should set up that option already.
Hum... The command line for a failing filesystem compile was:
/opt/sunstudio10u1/SUNWspro/bin/CC -c -g -xtarget=generic +d -features=rtti -features=except -I"/tmp/dgregor/BoostRegressionTesting/results/bin/boost/libs/filesystem/build" -I"/tmp/dgregor/BoostRegressionTesting/boost" -I"/usr/include" -I"/tmp/dgregor/BoostRegressionTesting/boost" -o "/tmp/dgregor/BoostRegressionTesting/results/bin/boost/libs/filesystem/build/libboost_filesystem.a/sunpro-5_8u1-sunos/debug/exception.o" "/tmp/dgregor/BoostRegressionTesting/boost/libs/filesystem/build/../src/exception.cpp"
So it looks like we need to add -library=stlport4 to the jamfile.
Yes. And other things are wrong with the command line. You should remove all of the following: +d -features=rtti -features=except -I"/usr/include" The two -features options are the defaults, and have no effect. The +d disables function inlining, which -g already does. (The -g compiles the program for debugging.) The -I/usr/include can prevent programs from compiling or working as intended. --- Steve Clamage, stephen.clamage@sun.com
"Steve Clamage" <Stephen.Clamage@Sun.COM> wrote in message news:42D12DF3.2040302@sun.com...
Yes. And other things are wrong with the command line. You should remove all of the following: +d -features=rtti -features=except -I"/usr/include" The two -features options are the defaults, and have no effect. The +d disables function inlining, which -g already does. (The -g compiles the program for debugging.) The -I/usr/include can prevent programs from compiling or working as intended.
Doug, It looks as if these changes have not been made to the toolset. Are you its maintainer:-? Thanks, --Beman
"Douglas Gregor" <doug.gregor@gmail.com> wrote in message news:47733b158c95de61a4e902c705d17da4@cs.indiana.edu...
On Jul 7, 2005, at 8:55 AM, Steve Clamage wrote:
OSL is currently getting the beta versions of our next compiler release (Sun Studio 10 update 1, C++ 5.8). Sun C++ still has many BOOST test failures. We found the problem with static templates in an internal compiler update that we won't distribute until we resolve which failures are errors in BOOST, and which are compiler bugs.
Just a follow-up: I've installed the Sun compilers on one of our OSL systems. It shows up as "OSL4" (sunpro-5_8u1-sunos) on the regression tests. It's far too late in the Boost release cycle to consider it a release platform, but we'll be running the tests nightly regardless.
Assertion: (../lnk/init.cc, line 1032) while processing /tmp/dgregor/BoostRegressionTesting/boost/boost/filesystem/path.hpp at line
Good. That will help the Sun folks get their compiler into better shape, which helps Boost too in the long run. I see Boost.Filesystem is causing an assert in Sun code: 66. Line 66 is just a simple member declaration: std::string leaf() const; Hum... That same assert is firing for some other libraries. Type traits tricky_function_type_test for example. Do you happen to know where we file bug reports for sunpro-5_8u1? --Beman
You can send bug reports to me. --- Steve Clamage, stephen.clamage@sun.com Beman Dawes wrote: > "Douglas Gregor" <doug.gregor@gmail.com> wrote in message > news:47733b158c95de61a4e902c705d17da4@cs.indiana.edu... > >>On Jul 7, 2005, at 8:55 AM, Steve Clamage wrote: >> >>>OSL is currently getting the beta versions of our next compiler >>>release (Sun >>>Studio 10 update 1, C++ 5.8). Sun C++ still has many BOOST test >>>failures. We >>>found the problem with static templates in an internal compiler update >>>that we >>>won't distribute until we resolve which failures are errors in BOOST, >>>and which >>>are compiler bugs. >> >>Just a follow-up: I've installed the Sun compilers on one of our OSL >>systems. It shows up as "OSL4" (sunpro-5_8u1-sunos) on the regression >>tests. It's far too late in the Boost release cycle to consider it a >>release platform, but we'll be running the tests nightly regardless. > > > Good. That will help the Sun folks get their compiler into better shape, > which helps Boost too in the long run. > > I see Boost.Filesystem is causing an assert in Sun code: > > >> Assertion: (../lnk/init.cc, line 1032) > while processing > /tmp/dgregor/BoostRegressionTesting/boost/boost/filesystem/path.hpp at line > 66. > > Line 66 is just a simple member declaration: > > std::string leaf() const; > > Hum... That same assert is firing for some other libraries. Type traits > tricky_function_type_test for example. > > Do you happen to know where we file bug reports for sunpro-5_8u1? > > --Beman >
Steve Clamage <Stephen.Clamage@Sun.COM> writes:
We recently corrected the way our compiler (Sun C++) handles static templates, and ran into a problem with some BOOST code. More than 100 tests in the suite depend on code like this:
template <typename T> struct S { void foo(int); };
template<class T , class U> static // static template ... void smart_cast_reference(U& u) {}
template <typename T> void S<T>::foo(int c) { smart_cast_reference< T& >(c); // used in global function }
int main() { S<int> s; s.foo(1); }
You can't use a static template in a global template function because it violates the One-Definition Rule, among possibly other rules. I have found that other compilers accept this code, but reject it when you put them in standard-conformning mode. (To see the rejection with some compilers, you need to build the executable.)
How critical to BOOST is this style of coding? Could the static templates be made global?
Steve, It really surprises me to hear that we have lots of this; it isn't a common idiom in Boost. Could you point us to some of the files where it's used? -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams <dave <at> boost-consulting.com> writes:
It really surprises me to hear that we have lots of this; it isn't a common idiom in Boost.
Right. It seems like such a poorly understood "idiom", that it would be in code because of coincidenses more than because of deliberate actions. It's the first time I have ever seen "static" on a free-standing function template. -Thorsten
participants (4)
-
Beman Dawes -
David Abrahams -
Doug Gregor -
Douglas Gregor -
Jeff Garland -
Jonathan Turkanis -
Robert Ramey -
Steve Clamage -
Thorsten Ottosen