Re: [boost] RC_1_30_0 compile error with SGI MIPSpro Compilers
Aleksey Gurtovoy wrote: If one of the developers could at least comment on this I might give it another try. Otherwise I estimate it would take me weeks to reverse-engineer what is happening here. Ralf, I will definitely look into it tonight and get back to you. OK, I've checked in a fix into the main trunk (see boost/mpl/aux_/lambda_support.hpp). If you could check if it makes the problem go away, I'll integrate the new version into the release branch. Aleksey ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RC_1_30_0 compile error with SGI MIPSpro Compilers
--- Aleksey Gurtovoy [EMAIL PROTECTED] wrote: OK, I've checked in a fix into the main trunk (see boost/mpl/aux_/lambda_support.hpp). If you could check if it makes the problem go away, I'll integrate the new version into the release branch. Thank you very much Aleksey! The error posted before is gone. This is very helpful and highly appreciated. I spent the better part of today figuring out the six additional patches shown below. I believe all Boost.Python tests build as expected with these patches using the mipspro toolset, but the final re-compilation from scratch is still going. David and Aleksey, could you please review the patches and tell me which are OK to check in? -- I am a bit worried about the two patches in the mpl/aux_/preprocessed directory. Are these files auto-generated? Are there master files that should be patched instead? Thank you in advance! Ralf Index: mpl/protect.hpp === RCS file: /cvsroot/boost/boost/boost/mpl/protect.hpp,v retrieving revision 1.5 diff -r1.5 protect.hpp 32c32 typedef protect type; --- typedef struct protect type; Index: mpl/aux_/integral_wrapper.hpp === RCS file: /cvsroot/boost/boost/boost/mpl/aux_/integral_wrapper.hpp,v retrieving revision 1.1 diff -r1.1 integral_wrapper.hpp 30c30 # define AUX_WRAPPER_INST(value) AUX_WRAPPER_NAME value --- # define AUX_WRAPPER_INST(value) mpl::AUX_WRAPPER_NAME value 39c39 typedef AUX_WRAPPER_NAME type; --- typedef struct AUX_WRAPPER_NAME type; Index: mpl/aux_/preprocessed/no_ttp/iter_fold_if_impl.hpp === RCS file: /cvsroot/boost/boost/boost/mpl/aux_/preprocessed/no_ttp/iter_fold_if_impl.hpp,v retrieving revision 1.1 diff -r1.1 iter_fold_if_impl.hpp 58c58 ::template result_ Iterator,State,ForwardOp,nextIterator impl_; --- ::template result_ Iterator,State,ForwardOp,mpl::nextIterator impl_; Index: mpl/aux_/preprocessed/no_ttp/lambda_no_ctps.hpp === RCS file: /cvsroot/boost/boost/boost/mpl/aux_/preprocessed/no_ttp/lambda_no_ctps.hpp,v retrieving revision 1.1 diff -r1.1 lambda_no_ctps.hpp 34c34 typedef protect bind1 --- typedef mpl::protect bind1 59c59 typedef protect bind2 --- typedef mpl::protect bind2 85c85 typedef protect bind3 --- typedef mpl::protect bind3 111c111 typedef protect bind4 --- typedef mpl::protect bind4 137c137 typedef protect bind5 --- typedef mpl::protect bind5 Index: python/enum.hpp === RCS file: /cvsroot/boost/boost/boost/python/enum.hpp,v retrieving revision 1.6 diff -r1.6 enum.hpp 95c95 this-enum_base::export_values(); --- this-base::export_values(); Index: type_traits/is_base_and_derived.hpp === RCS file: /cvsroot/boost/boost/boost/type_traits/is_base_and_derived.hpp,v retrieving revision 1.4 diff -r1.4 is_base_and_derived.hpp 27c27,28 #if !defined(__BORLANDC__) --- #if !defined(__BORLANDC__) \ !(defined(__sgi) defined(_COMPILER_VERSION) _COMPILER_VERSION = 730) __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RC_1_30_0 compile error with SGI MIPSpro Compilers
Ralf W. Grosse-Kunstleve [EMAIL PROTECTED] writes: David and Aleksey, could you please review the patches and tell me which are OK to check in? -- I am a bit worried about the two patches in the mpl/aux_/preprocessed directory. Are these files auto-generated? Are there master files that should be patched instead? Well, in addition, I believe: /boost/boost/mpl/aux_/lambda_no_ctps.hpp. The patch that worries me the most is the one in is_base_and_derived.hpp, but not seriously: it's just that it should probably be checking __EDG_VERSION instead of looking for the sgi compiler. Otherwise, they all look fine to me. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RC_1_30_0 compile error with SGI MIPSpro Compilers
--- David Abrahams [EMAIL PROTECTED] wrote: Ralf W. Grosse-Kunstleve [EMAIL PROTECTED] writes: David and Aleksey, could you please review the patches and tell me which are OK to check in? -- I am a bit worried about the two patches in the mpl/aux_/preprocessed directory. Are these files auto-generated? Are there master files that should be patched instead? Well, in addition, I believe: /boost/boost/mpl/aux_/lambda_no_ctps.hpp. OK, here are the two additional patches: Index: lambda_no_ctps.hpp === RCS file: /cvsroot/boost/boost/boost/mpl/aux_/lambda_no_ctps.hpp,v retrieving revision 1.7 diff -r1.7 lambda_no_ctps.hpp 127c127 typedef protect BOOST_PP_CAT(bind,i) --- typedef mpl::protect BOOST_PP_CAT(bind,i) Index: iter_fold_if_impl.hpp === RCS file: /cvsroot/boost/boost/boost/mpl/aux_/iter_fold_if_impl.hpp,v retrieving revision 1.5 diff -r1.5 iter_fold_if_impl.hpp 104c104 ::template result_ Iterator,State,ForwardOp,nextIterator impl_; --- ::template result_ Iterator,State,ForwardOp,mpl::nextIterator impl_; The patch that worries me the most is the one in is_base_and_derived.hpp, but not seriously: it's just that it should probably be checking __EDG_VERSION instead of looking for the sgi compiler. I don't know what EDG version to use in the #ifdef. I'll leave this as is for now. If someone else has the same problem on a different platform we can generalize. Otherwise, they all look fine to me. OK, I'll wait for a word from Aleksey. If he is happy I'll check in the eight patches, both into the trunk and the RC_1_30_0 branch. BTW: David, compilation of as_to_python_function.cpp fails on all platforms. hopefully_illegal suggests that this is expected, but then again the test is not called xxx_fail.cpp like the other tests that are expected to fail. Is everything all right here? Don't you want to rename the test? Ralf __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RC_1_30_0 compile error with SGI MIPSpro Compilers
Ralf W. Grosse-Kunstleve [EMAIL PROTECTED] writes: --- David Abrahams [EMAIL PROTECTED] wrote: Ralf W. Grosse-Kunstleve [EMAIL PROTECTED] writes: David and Aleksey, could you please review the patches and tell me which are OK to check in? -- I am a bit worried about the two patches in the mpl/aux_/preprocessed directory. Are these files auto-generated? Are there master files that should be patched instead? Well, in addition, I believe: /boost/boost/mpl/aux_/lambda_no_ctps.hpp. OK, here are the two additional patches: Index: lambda_no_ctps.hpp === RCS file: /cvsroot/boost/boost/boost/mpl/aux_/lambda_no_ctps.hpp,v retrieving revision 1.7 diff -r1.7 lambda_no_ctps.hpp 127c127 typedef protect BOOST_PP_CAT(bind,i) --- typedef mpl::protect BOOST_PP_CAT(bind,i) Index: iter_fold_if_impl.hpp === RCS file: /cvsroot/boost/boost/boost/mpl/aux_/iter_fold_if_impl.hpp,v retrieving revision 1.5 diff -r1.5 iter_fold_if_impl.hpp 104c104 ::template result_ Iterator,State,ForwardOp,nextIterator impl_; --- ::template result_ Iterator,State,ForwardOp,mpl::nextIterator impl_; The patch that worries me the most is the one in is_base_and_derived.hpp, but not seriously: it's just that it should probably be checking __EDG_VERSION instead of looking for the sgi compiler. I don't know what EDG version to use in the #ifdef. It's easy enough to test it with a little program that prints the value you have. I'll leave this as is for now. If someone else has the same problem on a different platform we can generalize. Doesn't worry me too much, but it's surely not SGI-specific. Otherwise, they all look fine to me. OK, I'll wait for a word from Aleksey. If he is happy I'll check in the eight patches, both into the trunk and the RC_1_30_0 branch. That looks good. BTW: David, compilation of as_to_python_function.cpp fails on all platforms. Intended. The Jamfile says: compile-fail ./as_to_python_function.cpp : $(PYTHON_PROPERTIES) ; and the Jam output should say (failed-as-expected) ... **passed** ... unless -d0 caused that to be suppressed, in which case we should remove the -d0 I guess. hopefully_illegal suggests that this is expected, but then again the test is not called xxx_fail.cpp like the other tests that are expected to fail. Is everything all right here? Yes. Don't you want to rename the test? Not really ;-) -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] RC_1_30_0 compile error with SGI MIPSpro Compilers
Ralf W. Grosse-Kunstleve wrote: OK, I'll wait for a word from Aleksey. If he is happy I'll heck in the eight patches, both into the trunk and the RC_1_30_0 branch. Yep, they all look good to me. Aleksey ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RC_1_30_0 compile error with SGI MIPSpro Compilers
--- David Abrahams [EMAIL PROTECTED] wrote: It's easy enough to test it with a little program that prints the value you have. OK, OK, OK, David. I know that MIPSpro == EDG 238, what I don't know is which EDG version fixes the problem. Is this better? Index: is_base_and_derived.hpp === RCS file: /cvsroot/boost/boost/boost/type_traits/is_base_and_derived.hpp,v retrieving revision 1.4 diff -r1.4 is_base_and_derived.hpp 27c27,31 #if !defined(__BORLANDC__) --- #if !defined(__BORLANDC__) \ !(defined(__EDG_VERSION__) __EDG_VERSION__ = 238) // The EDG version number is a lower estimate. // It is not currently known which EDG version // exactly fixes the problem. (failed-as-expected) ... **passed** ... unless -d0 caused that to be suppressed, in which case we should remove the -d0 I guess. I don't use -d0, but I don't see that **passed** message anywhere. Something else is not right: The other fail tests are only built once, but the as_to_python_function.cpp test is built each time I enter bjam again. That's why you see the failure on our auto-built test pages. Ralf __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RC_1_30_0 compile error with SGI MIPSpro Compilers
Ralf W. Grosse-Kunstleve [EMAIL PROTECTED] writes: --- David Abrahams [EMAIL PROTECTED] wrote: It's easy enough to test it with a little program that prints the value you have. OK, OK, OK, David. I know that MIPSpro == EDG 238, what I don't know is which EDG version fixes the problem. Is this better? Index: is_base_and_derived.hpp === RCS file: /cvsroot/boost/boost/boost/type_traits/is_base_and_derived.hpp,v retrieving revision 1.4 diff -r1.4 is_base_and_derived.hpp 27c27,31 #if !defined(__BORLANDC__) --- #if !defined(__BORLANDC__) \ !(defined(__EDG_VERSION__) __EDG_VERSION__ = 238) // The EDG version number is a lower estimate. // It is not currently known which EDG version // exactly fixes the problem. Should be: #if !BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x570)) \ !BOOST_WORKAROUND(__EDG_VERSION__, = 238) // The EDG version number is a lower estimate. // It is not currently known which EDG version // exactly fixes the problem. (failed-as-expected) ... **passed** ... unless -d0 caused that to be suppressed, in which case we should remove the -d0 I guess. I don't use -d0, but I don't see that **passed** message anywhere. -d0 is being used by the nightly builds, which I suggested for the build runs but not the test runs. Something else is not right: The other fail tests are only built once, but the as_to_python_function.cpp test is built each time I enter bjam again. That's why you see the failure on our auto-built test pages. what command-line are you using? Can you show me the output? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RC_1_30_0 compile error with SGI MIPSpro Compilers
--- Ralf W. Grosse-Kunstleve [EMAIL PROTECTED] wrote: I don't use -d0, but I don't see that **passed** message anywhere. Something else is not right: The other fail tests are only built once, but the as_to_python_function.cpp test is built each time I enter bjam again. That's why you see the failure on our auto-built test pages. I take all that back. The messages are printed if I don't specify -d0. And the as_to_python_function.cpp test behaves just like the others. Sorry for the confusion. Ralf __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RC_1_30_0 compile error with SGI MIPSpro Compilers
--- David Abrahams [EMAIL PROTECTED] wrote: Should be: #if !BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x570)) \ !BOOST_WORKAROUND(__EDG_VERSION__, = 238) // The EDG version number is a lower estimate. // It is not currently known which EDG version // exactly fixes the problem. Sigh. Trying this out right now. If only compilation wouldn't take so long... Ralf __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RC_1_30_0 compile error with SGI MIPSpro Compilers
Beman Dawes [EMAIL PROTECTED] writes: At 05:38 PM 3/7/2003, Ralf W. Grosse-Kunstleve wrote: ... I'll check in the eight patches, both into the trunk and the RC_1_30_0 branch. Ralf, Thanks for being alert to that. Please post a brief note once you have finished all commits. I haven't really figured out when we will close off RC_1_30_0, but it won't be until Tuesday at the very earliest. I have some Boost.Python things I want to merge into the release. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RC_1_30_0 compile error with SGI MIPSpro Compilers
--- David Abrahams [EMAIL PROTECTED] wrote:
There are any number of ways you could try reformulating this to make
the error go away. At worst you could try the __BORLANDC__ branch in
is_base_and_derived.hpp.
Another approach:
template typename B, typename D, typename T
static type_traits::yes_type bd_helper(D const volatile *, T);
template typename B, typename D
static type_traits::no_type bd_helper(B const volatile *, int);
That doesn't work because older EDG's don't support the bd_helperB,D syntax.
To be sure I just tried it again and it failed.
Using the __BORLANDC__ branch got me a little further. Some Boost.Python tests
compile and run.
Is the __BORLANDC__ branch different from (not as good as) the
is_base_and_derived implementation in 1.29.0?
There are many new errors when compiling the Boost.Python tests, but most of
them are identical:
mipspro-C++-action
/var/tmp/rwgk/bjam/libs/python/test/bin/embedding.test/mipspro/debug/embedding.o
cc-3192 CC: ERROR File =
/u1/rwgrosse/rc_1_30_0/boost/boost/mpl/fold_backward.hpp, Line = 47
The nontype boost::mpl::fold_backwardT1, T2, T3,
boost::mpl::arg1::rebind
is not a class template.
BOOST_MPL_AUX_LAMBDA_SUPPORT(3,fold_backward,(Sequence,State,BackwardOp))
^
I've preprocessed the source of test/embedding.cpp and stripped out all #line
directives. The error message then becomes:
cc-3192 CC: ERROR File = zzstrip.cpp, Line = 71667
The nontype boost::mpl::fold_backwardT1, T2, T3,
boost::mpl::arg1::rebind
is not a class template.
static const int arity = 3; typedef Sequence arg1; typedef State arg2;
typedef BackwardOp arg3; struct rebind; }; template typename T1,typename
T2,typename T3 struct fold_backwardT1,T2,T3 ::rebind { template typename
U1,typename U2,typename U3 struct apply : fold_backward U1,U2,U3 { };
^
With the ^ pointing to the beginning of ::rebind.
The full prepocessed, stripped file is here:
http://cci.lbl.gov/~rwgk/tmp/zzstrip.cpp
Are there any insights what the compiler is choking on here?
Thanks,
Ralf
__
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RC_1_30_0 compile error with SGI MIPSpro Compilers
Ralf W. Grosse-Kunstleve [EMAIL PROTECTED] writes: Is the __BORLANDC__ branch different from (not as good as) the is_base_and_derived implementation in 1.29.0? cvs diff knows for sure. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RC_1_30_0 compile error with SGI MIPSpro Compilers
--- David Abrahams [EMAIL PROTECTED] wrote: Ralf W. Grosse-Kunstleve [EMAIL PROTECTED] writes: Is the __BORLANDC__ branch different from (not as good as) the is_base_and_derived implementation in 1.29.0? cvs diff knows for sure. Sure, but this chasing tails game is impractical. If nobody else cares about MIPSpro compatibility we will just keep using 1.29.0. I'd like to suggest opening a 1.29 maintenance branch. I've accumulated a few minor patches that make Boost.Python 1.29.0 compatible with Python 2.3. If I could check these patches in they would be available to everybody. Ralf __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] RC_1_30_0 compile error with SGI MIPSpro Compilers
Ralf W. Grosse-Kunstleve wrote:
This requires active participation by the developers. We've spent a
lot of time setting up the auto-builds to enable developers to see
immediately when their changes break portability. We've also made a
major effort cleaning up 1.29.0. That seemed like a good start to me,
but it didn't work out for lack of participation from the developer's
side. So now I am stuck with messages like the one posted before:
cc-3192 CC: ERROR File = zzstrip.cpp, Line = 71667
The nontype boost::mpl::fold_backwardT1, T2, T3,
boost::mpl::arg1::rebind
is not a class template.
static const int arity = 3; typedef Sequence arg1;
typedef State arg2;
typedef BackwardOp arg3; struct rebind; }; template
typename T1,typename
T2,typename T3 struct fold_backwardT1,T2,T3 ::rebind {
template typename
U1,typename U2,typename U3 struct apply : fold_backward
U1,U2,U3 { };
^
If one of the developers could at least comment on this I might give it
another try. Otherwise I estimate it would take me weeks to
reverse-engineer what is happening here.
Ralf, I will definitely look into it tonight and get back to you.
Aleksey
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RC_1_30_0 compile error with SGI MIPSpro Compilers
The MIPSpro problems are due to a hickup in is_base_and_derived.hpp.
Here is the relevant *preprocessed* piece of code:
template typename B, typename D
struct bd_helper
{
template typename T
static type_traits::yes_type check(D const volatile *, T);
static type_traits::no_type check(B const volatile *, int);
};
templatetypename B, typename D
struct is_base_and_derived_impl2
{
struct Host
{
operator B const volatile *() const;
operator D const volatile *();
};
static const bool value = sizeof(bd_helperB,D:: check(Host(), 0)) ==
sizeof(type_traits::yes_type);
};
And here is the error:
cc-1108 CC: ERROR File =
/u1/rwgrosse/rc_1_30_0/boost/boost/type_traits/is_base_and_derived.hpp, Line =
106
The indicated expression must have pointer-to-function type.
static const bool value = sizeof(bd_helperB,D ::check(Host(), 0)) ==
sizeof(type_traits::yes_type);
^
Findings:
- Replacing sizeof(bd_helperB,D ::check(Host(), 0)) by sizeof(int)
leads to successful compilation.
- Removing the space before ::check doesn't make a difference.
MIPSpro is based on EDG 238. Are there known issues with operator T?
Ideas for a workaround are highly appreciated.
Thanks,
Ralf
__
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RC_1_30_0 compile error with SGI MIPSpro Compilers
Below is a stand-alone minimal test that still produces the same error message
with MIPSpro:
% CC -LANG:std zminmin.cpp
cc-1108 CC: ERROR File = zminmin.cpp, Line = 13
The indicated expression must have pointer-to-function type.
static const unsigned long value = sizeof(bdhelper_t::check());
^
1 error detected in the compilation of zminmin.cpp.
The same code works correctly with gcc 2.96 and an EDG245-based compiler
(Compaq cxx). However, here is an interesting observation:
% cxx -std strict_ansi zminmin.cpp
% a.out
4
No problem with strict_ansi. But:
% cxx -std ansi -D__USE_STD_IOSTREAM zminmin.cpp
cxx: Error: zminmin.cpp, line 13: operand of sizeof may not be a function
static const unsigned long value = sizeof(bdhelper_t::check());
--^
cxx: Info: 1 error detected in the compilation of zminmin.cpp.
I am jumping to the conclusion that older EDG's don't support
sizeof(some_function()). Does that sound plausible? What could be done to make
the is_base_and_derived test work with MIPSpro?
Is the test actually used in Boost.Python? -- I noticed that MIPSpro chokes
even if is_base_and_derived_impl2 is not instantiated.
Thanks!
Ralf
#include iostream
template typename B, typename D
struct bd_helper
{
static int check();
};
templatetypename B, typename D
struct is_base_and_derived_impl2
{
typedef bd_helperB,D bdhelper_t;
static const unsigned long value = sizeof(bdhelper_t::check());
};
int main()
{
unsigned long n = is_base_and_derived_impl2int, float::value;
std::cout n std::endl;
}
__
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RC_1_30_0 compile error with SGI MIPSpro Compilers
Ralf W. Grosse-Kunstleve [EMAIL PROTECTED] writes:
Below is a stand-alone minimal test that still produces the same error message
with MIPSpro:
% CC -LANG:std zminmin.cpp
cc-1108 CC: ERROR File = zminmin.cpp, Line = 13
The indicated expression must have pointer-to-function type.
static const unsigned long value = sizeof(bdhelper_t::check());
^
1 error detected in the compilation of zminmin.cpp.
The same code works correctly with gcc 2.96 and an EDG245-based compiler
(Compaq cxx). However, here is an interesting observation:
% cxx -std strict_ansi zminmin.cpp
% a.out
4
No problem with strict_ansi. But:
% cxx -std ansi -D__USE_STD_IOSTREAM zminmin.cpp
cxx: Error: zminmin.cpp, line 13: operand of sizeof may not be a function
static const unsigned long value = sizeof(bdhelper_t::check());
--^
cxx: Info: 1 error detected in the compilation of zminmin.cpp.
I am jumping to the conclusion that older EDG's don't support
sizeof(some_function()). Does that sound plausible?
Not to me; this technique is used all over the Boost type traits.
Nothing would've ever worked with this compiler if that were true,
pretty much.
What could be done to make the is_base_and_derived test work with
MIPSpro? Is the test actually used in Boost.Python?
Yes.
-- I noticed that MIPSpro chokes even if is_base_and_derived_impl2
is not instantiated.
Thanks!
Ralf
There are any number of ways you could try reformulating this to make
the error go away. At worst you could try the __BORLANDC__ branch in
is_base_and_derived.hpp.
Another approach:
template typename B, typename D, typename T
static type_traits::yes_type bd_helper(D const volatile *, T);
template typename B, typename D
static type_traits::no_type bd_helper(B const volatile *, int);
templatetypename B, typename D
struct is_base_and_derived_impl2
{
struct Host
{
operator B const volatile *() const;
operator D const volatile *();
};
BOOST_STATIC_CONSTANT(bool, value =
sizeof(bd_helperB,D(Host(), 0)) == sizeof(type_traits::yes_type));
};
#include iostream
template typename B, typename D
struct bd_helper
{
static int check();
};
templatetypename B, typename D
struct is_base_and_derived_impl2
{
typedef bd_helperB,D bdhelper_t;
static const unsigned long value = sizeof(bdhelper_t::check());
};
int main()
{
unsigned long n = is_base_and_derived_impl2int, float::value;
std::cout n std::endl;
}
__
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RC_1_30_0 compile error with SGI MIPSpro Compilers
The regression tests (version 3) are running, and it may be a while
before they are done. In the meantime, the results of preprocessing the
file give more details of the error:
cc-1108 CC: ERROR File =
/mnt/vracs001/home9/users/patrick/src/Boost/boost-1.30.0-cvs/boost/type_traits/is_base_and_derived.hpp,
Line = 106
The indicated expression must have pointer-to-function type.
static const bool value = sizeof(bd_helperB,D ::check(Host(),
0)) == sizeof(type_traits::yes_type);
^
The code in question comes from the following:
template typename B, typename D
struct bd_helper
{
template typename T
static type_traits::yes_type check(D const volatile *, T);
static type_traits::no_type check(B const volatile *, int);
};
templatetypename B, typename D
struct is_base_and_derived_impl2
{
struct Host
{
operator B const volatile *() const;
operator D const volatile *();
};
static const bool value = sizeof(bd_helperB,D ::check(Host(), 0))
== sizeof(type_traits::yes_type);
};
This looks okay to me (though I am not familiar with the Boost
internals), but I think I have seen a similar error with this compiler.
A cast might have been necessary to coerce the compiler into dealing with
the code, but I'm guessing that is not appropriate in this case.
-Patrick
David Abrahams wrote:
Patrick Hartling [EMAIL PROTECTED] writes:
Is there a recommended procedure I can follow for tracking this down
and submitting a patch?
I would start by preprocessing the file to see what's going on behind
that macro, then tweaking it until it works.
For example, I was considering running the regression tests for the
MIPSpro Compilers. Would that be helpful,
Very much so
or is someone on the Boost team on top of this already?
Not that I know of.
--
Patrick L. Hartling | Research Assistant, VRAC
[EMAIL PROTECTED]| 2624 Howe Hall: 1.515.294.4916
http://www.137.org/patrick/ | http://www.vrac.iastate.edu/
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
