cxx: Error: /net/redbelly/scratch1/rwgk/boost_regression/boost/boost/test/detail/basic_c string/compare.hpp, line 42: #40 expected an identifier static bool eq( CharT c1, CharT c2 ) { return std::toupper( c1 ) == std::toupper( c2 ); } ---------------------------------------------------------------^ How should deal with this one? Any pointers? Gennadiy.
"Gennadiy Rozental" <gennadiy.rozental@thomson.com> wrote in message news:cf9hu4$rkm$1@sea.gmane.org...
cxx: Error:
/net/redbelly/scratch1/rwgk/boost_regression/boost/boost/test/detail/basic_c
string/compare.hpp, line 42: #40 expected an identifier static bool eq( CharT c1, CharT c2 ) { return std::toupper( c1 ) == std::toupper( c2 ); } ---------------------------------------------------------------^
How should deal with this one?
I don't know if this might be of help. I'm using cxx 6.5 under OpenVMS and have had some (perhaps) related problems; not sure about Tru64 though: - The <cxxx> headers are missing so I included <boost/compatibility/cpp_c_headers> in the include path. I guess you've already done that (or the Tru64 version include them) as you don't get compilation warnings from the #include statement. - I also found the switch "/standard=strict_ansi" useful to get ansi violation warnings. Don't know the name under Tru64 though. - I also seem to remember that I had to use the switch "/using_std" to resolve some compilation problems when using the above switch. Looking at the documentation I think it should really neither be necessary nor desired, but ... perhaps just as a troubleshooter. // Johan
--- Gennadiy Rozental <gennadiy.rozental@thomson.com> wrote:
cxx: Error: /net/redbelly/scratch1/rwgk/boost_regression/boost/boost/test/detail/basic_c string/compare.hpp, line 42: #40 expected an identifier static bool eq( CharT c1, CharT c2 ) { return std::toupper( c1 ) == std::toupper( c2 ); } ---------------------------------------------------------------^
How should deal with this one?
This output is from our machine. I could try to fix it if someone gives me a little assistance. My first guess is that #include <ctypes> has to be added somewhere. Could someone give me the bjam command to reproduce the error above without having to wait for everything else to build? Ralf __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail
"Ralf W. Grosse-Kunstleve" <rwgk@yahoo.com> writes:
--- Gennadiy Rozental <gennadiy.rozental@thomson.com> wrote:
cxx: Error: /net/redbelly/scratch1/rwgk/boost_regression/boost/boost/test/detail/basic_c string/compare.hpp, line 42: #40 expected an identifier static bool eq( CharT c1, CharT c2 ) { return std::toupper( c1 ) == std::toupper( c2 ); } ---------------------------------------------------------------^
How should deal with this one?
This output is from our machine. I could try to fix it if someone gives me a little assistance.
My first guess is that #include <ctypes> has to be added somewhere.
Could someone give me the bjam command to reproduce the error above without having to wait for everything else to build?
My guess is that types.h is included somewhere, or ctypes nonconformingly #defines toupper to be a macro. Why don't you preprocess it and find out? The bjam command is bjam ... name_of_source_file.o where ... are whatever options you happen to need to set up toolsets and environment. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
"Ralf W. Grosse-Kunstleve" <rwgk@yahoo.com> writes:
--- Gennadiy Rozental <gennadiy.rozental@thomson.com> wrote:
cxx: Error: /net/redbelly/scratch1/rwgk/boost_regression/boost/boost/test/detail/basic_c string/compare.hpp, line 42: #40 expected an identifier static bool eq( CharT c1, CharT c2 ) { return std::toupper( c1 ) == std::toupper( c2 ); } ---------------------------------------------------------------^
How should deal with this one?
This output is from our machine. I could try to fix it if someone gives me a little assistance.
My first guess is that #include <ctypes> has to be added somewhere.
Is it possible that <cctype> has been included, but that unless "-std strict_ansi" switch is given then the toupper/tolower functions are not in the std namespace? I've had problems porting to Tru64's cxx compiler because with strict_ansi it's very strict about what's in std (no ::size_t for instance) and IIRC without strict_ansi it's quite sloppy (so entirely possible that toupper/tolower are only in global, not std namespace) As I understand it, "cxx" and "cxx -std strict_ansi" are effectively two different compilers, with differing effects from including the standard headers, and entirely different IOStream implementations for instance. N.B. this is all based on bug reports I've received from cxx users, not first-hand experience. jon -- "The easy confidence with which I know another man's religion is Folly leads me to suspect that my own is also." - Mark Twain
--- David Abrahams <dave@boost-consulting.com> wrote:
"Ralf W. Grosse-Kunstleve" <rwgk@yahoo.com> writes:
--- Gennadiy Rozental <gennadiy.rozental@thomson.com> wrote:
cxx: Error:
/net/redbelly/scratch1/rwgk/boost_regression/boost/boost/test/detail/basic_c
string/compare.hpp, line 42: #40 expected an identifier static bool eq( CharT c1, CharT c2 ) { return std::toupper( c1 ) == std::toupper( c2 ); } ---------------------------------------------------------------^
How should deal with this one?
This output is from our machine. I could try to fix it if someone gives me a little assistance.
My first guess is that #include <ctypes> has to be added somewhere.
Could someone give me the bjam command to reproduce the error above without having to wait for everything else to build?
My guess is that types.h is included somewhere, or ctypes nonconformingly #defines toupper to be a macro. Why don't you preprocess it and find out?
The bjam command is
bjam ... name_of_source_file.o
where ... are whatever options you happen to need to set up toolsets and environment.
I looked around a bit and I see that the toolset was modified in May: -std strict_ansi was removed. IMO this is not the best idea. All of Boost.Python compiles and works with -std strict_ansi. And this works as well: % cat test.cpp #include <cctype> int main() { std::toupper('c'); return 0; } cxx -std strict_ansi -tlocal test.cpp I am afraid I don't have time to fix the toolset. What I can offer is ssh access to our machine and the compiler/linker commands that work for Boost.Python (I am using SCons). Ralf __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail
Ralf W. Grosse-Kunstleve wrote:
I looked around a bit and I see that the toolset was modified in May: -std strict_ansi was removed. IMO this is not the best idea. All of Boost.Python compiles and works with -std strict_ansi. And this works as well:
% cat test.cpp #include <cctype>
int main() { std::toupper('c'); return 0; }
cxx -std strict_ansi -tlocal test.cpp
I am afraid I don't have time to fix the toolset. What I can offer is ssh access to our machine and the compiler/linker commands that work for Boost.Python (I am using SCons).
The toolset was modified on my behalf. Below is an excert of the mail I sent to justify the changes.
You might want to try the appended tools file for true64cxx65. I recently started to use boost on this platform and this is what I have come up with so far.
These were the major issues with the toolset description:
- The "flags tru64cxx65 CFLAGS <inlining>full : -inline all ;" hangs the compiler when compiling with full inlining. Leaving this at the default value solves the problem.
- The command line for the archive action exceeds its maximum length when used with certain libs. On recommendation from Ralf Grosse-Kunstleve I removed the whole cxx repository stuff and added "-tlocal" to the C++ compiler options. This avoids the need for repositories completely.
- The Cc-action was refering to a non existant cxx-Cc-action.
- The use of "-std strict_ansi -nopure_cname" was causing all kinds of troubles for me. I replaced that with "-D__USE_STD_IOSTREAM -nousing_std" which seems to work far better.
Maybe the maintainers should consider to replace the current toolset with the one attached.
There are other issues to be aware of:
- When compiling boost you will see several warnings (and one error!) about the use of assert on pointer types. These are caused by a bug in the system header files which force the argument for assert() to int. This can be fixed by editing the header file "/usr/include/assert.h".
- When the macro _XOPEN_SOURCE is defined to something greater or equal to 500, you will encounter errors when compiling code which involes iostreams because of a bug in the iotraits header file. This happended to me when compiling boost.python because python forces the _XOPEN_SOURCE to 600. You need to fix the iotraits header file for this.
- There are several statements in the form of
# if (defined(__DECCXX_VER) && __DECCXX_VER <= 60590031)
sprincled through boost to work around compiler deficencies. As we are using 60590040 I patched these to the new revision number. I didn't check if the bugs were fixed in the compiler but you might want to do the same.
Thats all I can remember off the top of my head. I did some tweaking to the boost.python source but that might not be necessary for you.
With the current toolset I am able to compile the whole boost libraries (v 1.31.0) on my platform (OSF1, V5.1, alpha) and compiler (Compaq C++ V6.5-033 for Compaq Tru64 UNIX V5.1B (Rev. 2650)). I just started downloading the current CVS snapshot to have a look at this problem. Markus
On Wed, Aug 11, 2004 at 12:43:37PM +0200, Markus Sch?pflin wrote:
The toolset was modified on my behalf. Below is an excert of the mail I sent to justify the changes. [snip]
- The use of "-std strict_ansi -nopure_cname" was causing all kinds of troubles for me. I replaced that with "-D__USE_STD_IOSTREAM -nousing_std" which seems to work far better.
This seems a bit hasty IMHO. Surely it would be better to make Boost work with the compiler in strict_ansi mode than just force the compiler to act in a non-standard way? I'd have thought that simply "-std strict_ansi" would be ok, as Boost has plenty of its own mechanisms for working around any remaining quirks of the compiler, without resorting to the compiler's own large array of compatibility switches. Do the config settings for that compiler match the new switches used, or are they still the settings determined when "-std strict_ansi -nopure_cname" was used? jon -- "Everybody understands Mickey Mouse. Few understand Herman Hesse. Only a handful understood Albert Einstein. And nobody understood Emperor Norton." - Slogan of NORTON CABAL - S.F.
Jonathan Wakely <cow@compsoc.man.ac.uk> writes:
On Wed, Aug 11, 2004 at 12:43:37PM +0200, Markus Sch?pflin wrote:
The toolset was modified on my behalf. Below is an excert of the mail I sent to justify the changes. [snip]
- The use of "-std strict_ansi -nopure_cname" was causing all kinds of troubles for me. I replaced that with "-D__USE_STD_IOSTREAM -nousing_std" which seems to work far better.
This seems a bit hasty IMHO. Surely it would be better to make Boost work with the compiler in strict_ansi mode than just force the compiler to act in a non-standard way?
Totally agreed. "was causing all kinds of troubles... seems to work far better" seems like a very weak justification for that change. The right thing to do is to determine specifically where the problems are coming from and why. It's very possible the problems were caused by bugs in some Boost libraries that should have been fixed but that are being masked by the change of options. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
Jonathan Wakely wrote:
On Wed, Aug 11, 2004 at 12:43:37PM +0200, Markus Sch?pflin wrote:
- The use of "-std strict_ansi -nopure_cname" was causing all kinds of troubles for me. I replaced that with "-D__USE_STD_IOSTREAM -nousing_std" which seems to work far better.
This seems a bit hasty IMHO. Surely it would be better to make Boost work with the compiler in strict_ansi mode than just force the compiler to act in a non-standard way?
What would you consider the correct way then? IMO we have three options. 1. Only use "-std strict_ansi". This means that the C header files (#include <c...>) included by boost libraries only define exactly those names specified in the C++ standard and nothing else. This would means changes to at least test, fs, regex and probably more libs. OTOH, this would mean that those libs are more conforming afterwards. Here is the output of a configure run with the options "-pthread -tlocal -std strict_ansi": #define BOOST_MSVC6_MEMBER_TEMPLATES #define BOOST_HAS_UNISTD_H #define BOOST_HAS_SCHED_YIELD #define BOOST_HAS_PTHREADS #define BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE #define BOOST_HAS_PTHREAD_DELAY_NP #define BOOST_HAS_PARTIAL_STD_ALLOCATOR #define BOOST_HAS_NRVO #define BOOST_HAS_NL_TYPES_H #define BOOST_HAS_LONG_LONG #define BOOST_HAS_GETTIMEOFDAY #define BOOST_HAS_DIRENT_H (No sigaction (XSH4.0), no nanosleep (P1003.1b), and no clock_gettime(P1003.1b), to get those you have to define _XOPEN_SOURCE or _POSIX_SOURCE or some such.) 2. Revert to "-std strict_ansi -nopure_cname". These were the flags that came with 1.30.0 but didn't work for me. Did those really work for you? If yes, which platform and which version of the compiler did you use? Here is the output of a configure run with the options "-pthread -tlocal -std strict_ansi -nopure_cname": #define BOOST_MSVC6_MEMBER_TEMPLATES #define BOOST_HAS_UNISTD_H #define BOOST_HAS_SIGACTION #define BOOST_HAS_SCHED_YIELD #define BOOST_HAS_PTHREADS #define BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE #define BOOST_HAS_PTHREAD_DELAY_NP #define BOOST_HAS_PARTIAL_STD_ALLOCATOR #define BOOST_HAS_NRVO #define BOOST_HAS_NL_TYPES_H #define BOOST_HAS_NANOSLEEP #define BOOST_HAS_LONG_LONG #define BOOST_HAS_GETTIMEOFDAY #define BOOST_HAS_DIRENT_H #define BOOST_HAS_CLOCK_GETTIME 3. Leave them at "-D__USE_STD_IOSTREAM -nousing_std". Those flags worked for me for boost 1.30.0. Note that this uses the default C++ mode for the compiler. This means: "The default ANSI mode permits some common extensions and provides less strict error checking than the STRICT_ANSI mode." (excerpt from manpage) The "-D__USE_STD_IOSTREAM" part is the offical documented way to enable standard iostreams and "-nousing_std" turns of the implicit using namespace std. Here is the output of a configure run with the options "-pthread -tlocal -D__USE_STD_IOSTREAM -nousing_std": #define BOOST_MSVC6_MEMBER_TEMPLATES #define BOOST_HAS_UNISTD_H #define BOOST_HAS_SIGACTION #define BOOST_HAS_SCHED_YIELD #define BOOST_HAS_PTHREADS #define BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE #define BOOST_HAS_PTHREAD_DELAY_NP #define BOOST_HAS_PARTIAL_STD_ALLOCATOR #define BOOST_HAS_NRVO #define BOOST_HAS_NL_TYPES_H #define BOOST_HAS_NANOSLEEP #define BOOST_HAS_LONG_LONG #define BOOST_HAS_GETTIMEOFDAY #define BOOST_HAS_DIRENT_H #define BOOST_HAS_CLOCK_GETTIME #define BOOST_FUNCTION_SCOPE_USING_DECLARATION_BREAKS_ADL There is one compiler failure which doesn't happen in strict ansi mode.
I'd have thought that simply "-std strict_ansi" would be ok, as Boost has plenty of its own mechanisms for working around any remaining quirks of the compiler, without resorting to the compiler's own large array of compatibility switches.
Do the config settings for that compiler match the new switches used, or are they still the settings determined when "-std strict_ansi -nopure_cname" was used?
Those are still the old settings, AFAICT. But the only difference is BOOST_FUNCTION_SCOPE_USING_DECLARATION_BREAKS_ADL. Markus
On Thu, Aug 12, 2004 at 11:13:32AM +0200, Markus Sch?pflin wrote:
Jonathan Wakely wrote:
On Wed, Aug 11, 2004 at 12:43:37PM +0200, Markus Sch?pflin wrote:
- The use of "-std strict_ansi -nopure_cname" was causing all kinds of troubles for me. I replaced that with "-D__USE_STD_IOSTREAM -nousing_std" which seems to work far better.
This seems a bit hasty IMHO. Surely it would be better to make Boost work with the compiler in strict_ansi mode than just force the compiler to act in a non-standard way?
What would you consider the correct way then? IMO we have three options.
1. Only use "-std strict_ansi". This means that the C header files (#include <c...>) included by boost libraries only define exactly those names specified in the C++ standard and nothing else. This would means changes to at least test, fs, regex and probably more libs. OTOH, this would mean that those libs are more conforming afterwards.
Seems the best option to me. If a compiler is capable of conforming then why tell it not to and require boost hacks to make it behave as though it conforms? Would you break a healthy person's legs and then give them crutches? :)
Here is the output of a configure run with the options "-pthread -tlocal -std strict_ansi":
#define BOOST_MSVC6_MEMBER_TEMPLATES #define BOOST_HAS_UNISTD_H #define BOOST_HAS_SCHED_YIELD #define BOOST_HAS_PTHREADS #define BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE #define BOOST_HAS_PTHREAD_DELAY_NP #define BOOST_HAS_PARTIAL_STD_ALLOCATOR #define BOOST_HAS_NRVO #define BOOST_HAS_NL_TYPES_H #define BOOST_HAS_LONG_LONG #define BOOST_HAS_GETTIMEOFDAY #define BOOST_HAS_DIRENT_H
(No sigaction (XSH4.0), no nanosleep (P1003.1b), and no clock_gettime(P1003.1b), to get those you have to define _XOPEN_SOURCE or _POSIX_SOURCE or some such.)
Yes, adding those is probably a good idea if Boost needs to use any non-std features.
2. Revert to "-std strict_ansi -nopure_cname". These were the flags that came with 1.30.0 but didn't work for me. Did those really work for you? If yes, which platform and which version of the compiler did you use?
I don't have access to cxx, I've only been able to port my code to it with the help of bug reports from other cxx users, so I can't comment on whether those flags worked. The -nopure_cname looks out of place to me. If Boost doesn't work with pure <cxxx> headers then Boost is broken.
3. Leave them at "-D__USE_STD_IOSTREAM -nousing_std". Those flags worked for me for boost 1.30.0. Note that this uses the default C++ mode for the compiler. This means: "The default ANSI mode permits some common extensions and provides less strict error checking than the STRICT_ANSI mode." (excerpt from manpage) The "-D__USE_STD_IOSTREAM" part is the offical documented way to enable standard iostreams and "-nousing_std" turns of the implicit using namespace std.
This isn't terrible, but is less strict than the standard requires, and my personal preference would be to conform as much as possible. On reflection, the main argument I can see against using strict_ansi is that it requires users of Boost to compile with that flag. This might be too restrictive for some users as it would prevent their code from compiling. On the other hand, requiring users to compile in less-than-conforming mode would mean that some people using strict_ansi mode and writing perfectly conforming code cannot use Boost. As I understand it, whatever flags are used by Boost must match the flags a user uses (maybe this only applies to compiled libs, not header-only ones), so one view would be that Boost should use the most commonly used set of flags. This might be the default - but then that uses nonstandard streams and implicit using directive for namespace std - eurgh! And in any case, "noone knows what most C++ programmers do". yours, not knowing the right answer, jon -- Rules of Optimization: Rule 1: Don't do it. Rule 2 (for experts only): Don't do it yet. - M.A. Jackson
Jonathan Wakely wrote:
On Thu, Aug 12, 2004 at 11:13:32AM +0200, Markus Sch?pflin wrote:
Jonathan Wakely wrote:
On Wed, Aug 11, 2004 at 12:43:37PM +0200, Markus Sch?pflin wrote:
- The use of "-std strict_ansi -nopure_cname" was causing all kinds of troubles for me. I replaced that with "-D__USE_STD_IOSTREAM -nousing_std" which seems to work far better.
This seems a bit hasty IMHO. Surely it would be better to make Boost work with the compiler in strict_ansi mode than just force the compiler to act in a non-standard way?
What would you consider the correct way then? IMO we have three options.
1. Only use "-std strict_ansi". This means that the C header files (#include <c...>) included by boost libraries only define exactly those names specified in the C++ standard and nothing else. This would means changes to at least test, fs, regex and probably more libs. OTOH, this would mean that those libs are more conforming afterwards.
Seems the best option to me.
If a compiler is capable of conforming then why tell it not to and require boost hacks to make it behave as though it conforms?
Would you break a healthy person's legs and then give them crutches? :)
In theory I agree with you, in practice I'm not sure. Maybe we should get more opinions on this from other users of this platform.
Here is the output of a configure run with the options "-pthread -tlocal -std strict_ansi":
#define BOOST_MSVC6_MEMBER_TEMPLATES #define BOOST_HAS_UNISTD_H #define BOOST_HAS_SCHED_YIELD #define BOOST_HAS_PTHREADS #define BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE #define BOOST_HAS_PTHREAD_DELAY_NP #define BOOST_HAS_PARTIAL_STD_ALLOCATOR #define BOOST_HAS_NRVO #define BOOST_HAS_NL_TYPES_H #define BOOST_HAS_LONG_LONG #define BOOST_HAS_GETTIMEOFDAY #define BOOST_HAS_DIRENT_H
(No sigaction (XSH4.0), no nanosleep (P1003.1b), and no clock_gettime(P1003.1b), to get those you have to define _XOPEN_SOURCE or _POSIX_SOURCE or some such.)
Yes, adding those is probably a good idea if Boost needs to use any non-std features.
Agreed. But what is the best way to do that? Define those macros to some value and you will get conflicts with users of boost. So you have to leave that decision to the user and let boost make the best of it, whatever environment it finds. I think that is already done by "boost/config/posix_features.hpp".
2. Revert to "-std strict_ansi -nopure_cname". These were the flags that came with 1.30.0 but didn't work for me. Did those really work for you? If yes, which platform and which version of the compiler did you use?
I don't have access to cxx, I've only been able to port my code to it with the help of bug reports from other cxx users, so I can't comment on whether those flags worked. The -nopure_cname looks out of place to me. If Boost doesn't work with pure <cxxx> headers then Boost is broken.
But it would require much effort to fix it. I know this is a pragmatic point of view, but I'm not sure if it's really worth the effort.
3. Leave them at "-D__USE_STD_IOSTREAM -nousing_std". Those flags worked for me for boost 1.30.0. Note that this uses the default C++ mode for the compiler. This means: "The default ANSI mode permits some common extensions and provides less strict error checking than the STRICT_ANSI mode." (excerpt from manpage) The "-D__USE_STD_IOSTREAM" part is the offical documented way to enable standard iostreams and "-nousing_std" turns of the implicit using namespace std.
This isn't terrible, but is less strict than the standard requires, and my personal preference would be to conform as much as possible.
On reflection, the main argument I can see against using strict_ansi is that it requires users of Boost to compile with that flag. This might be too restrictive for some users as it would prevent their code from compiling.
On the other hand, requiring users to compile in less-than-conforming mode would mean that some people using strict_ansi mode and writing perfectly conforming code cannot use Boost.
Ideally, boost should adapt to whatever mode the compiler is in. In theory, this should be possible as every switch defines some compiler macro: -pthread => _REENTRANT -pure_cname => __PURE_CNAME -using_std => __IMPLICIT_USING_STD -std ansi => __STD_ANSI -std strict_ansi => __STD_STRICT_ANSI, also sets __PURE_CNAME For thread support this is already done by boost.
As I understand it, whatever flags are used by Boost must match the flags a user uses (maybe this only applies to compiled libs, not header-only ones), so one view would be that Boost should use the most commonly used set of flags. This might be the default - but then that uses nonstandard streams and implicit using directive for namespace std - eurgh! And in any case, "noone knows what most C++ programmers do".
Compiled libs would end up with yet more build variants. Header only libs could be made to adapt automatically, if one is willing to put enough effort into it. Which returns us to the question if it's really worth it. Markus
On Thu, Aug 12, 2004 at 01:12:34PM +0200, Markus Sch?pflin wrote:
If Boost doesn't work with pure <cxxx> headers then Boost is broken.
But it would require much effort to fix it. I know this is a pragmatic point of view, but I'm not sure if it's really worth the effort.
Since it would be effort to make Boost work for a highly-conforming compiler I'd say this particular work would be well worth it. The effort would pay off for other compilers in the future if they cleaned up their C headers. Easy for me to say though, I wouldn't be doing the work.
On the other hand, requiring users to compile in less-than-conforming mode would mean that some people using strict_ansi mode and writing perfectly conforming code cannot use Boost.
Ideally, boost should adapt to whatever mode the compiler is in. In theory, this should be possible as every switch defines some compiler macro:
-pthread => _REENTRANT -pure_cname => __PURE_CNAME -using_std => __IMPLICIT_USING_STD -std ansi => __STD_ANSI -std strict_ansi => __STD_STRICT_ANSI, also sets __PURE_CNAME
For thread support this is already done by boost.
Nice - it would be relatively* easy to use those macros to define/undefine the corresponding Boost macros. * relative to a very hard thing ;)
As I understand it, whatever flags are used by Boost must match the flags a user uses (maybe this only applies to compiled libs, not header-only ones), so one view would be that Boost should use the most commonly used set of flags. This might be the default - but then that uses nonstandard streams and implicit using directive for namespace std - eurgh! And in any case, "noone knows what most C++ programmers do".
Compiled libs would end up with yet more build variants. Header only libs could be made to adapt automatically, if one is willing to put enough effort into it. Which returns us to the question if it's really worth it.
Agreed, but that would mean users who don't use BJam would have to know which compiled lib corresponds to their set of flags - eurgh again. jon -- "Democracy is the theory that the common people know what they want, and deserve to get it good and hard." - H.L. Mencken
Markus Schöpflin <markus.schoepflin@comsoft.de> writes:
Jonathan Wakely wrote:
On Wed, Aug 11, 2004 at 12:43:37PM +0200, Markus Sch?pflin wrote:
- The use of "-std strict_ansi -nopure_cname" was causing all kinds of troubles for me. I replaced that with "-D__USE_STD_IOSTREAM -nousing_std" which seems to work far better. This seems a bit hasty IMHO. Surely it would be better to make Boost work with the compiler in strict_ansi mode than just force the compiler to act in a non-standard way?
What would you consider the correct way then? IMO we have three options.
1. Only use "-std strict_ansi". This means that the C header files (#include <c...>) included by boost libraries only define exactly those names specified in the C++ standard and nothing else. This would means changes to at least test, fs, regex and probably more libs. OTOH, this would mean that those libs are more conforming afterwards.
Here is the output of a configure run with the options "-pthread -tlocal -std strict_ansi":
#define BOOST_MSVC6_MEMBER_TEMPLATES #define BOOST_HAS_UNISTD_H #define BOOST_HAS_SCHED_YIELD #define BOOST_HAS_PTHREADS #define BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE #define BOOST_HAS_PTHREAD_DELAY_NP #define BOOST_HAS_PARTIAL_STD_ALLOCATOR #define BOOST_HAS_NRVO #define BOOST_HAS_NL_TYPES_H #define BOOST_HAS_LONG_LONG #define BOOST_HAS_GETTIMEOFDAY #define BOOST_HAS_DIRENT_H
(No sigaction (XSH4.0), no nanosleep (P1003.1b), and no clock_gettime(P1003.1b), to get those you have to define _XOPEN_SOURCE or _POSIX_SOURCE or some such.)
IMO this is the right thing to do, including making those #defines as neccessary. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
Markus Schöpflin <markus.schoepflin@comsoft.de> writes:
What would you consider the correct way then? IMO we have three options.
1. Only use "-std strict_ansi". This means that the C header files (#include <c...>) included by boost libraries only define exactly those names specified in the C++ standard and nothing else. This would means changes to at least test, fs, regex and probably more libs. OTOH, this would mean that those libs are more conforming afterwards.
Here is the output of a configure run with the options "-pthread -tlocal -std strict_ansi":
#define BOOST_MSVC6_MEMBER_TEMPLATES #define BOOST_HAS_UNISTD_H #define BOOST_HAS_SCHED_YIELD #define BOOST_HAS_PTHREADS #define BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE #define BOOST_HAS_PTHREAD_DELAY_NP #define BOOST_HAS_PARTIAL_STD_ALLOCATOR #define BOOST_HAS_NRVO #define BOOST_HAS_NL_TYPES_H #define BOOST_HAS_LONG_LONG #define BOOST_HAS_GETTIMEOFDAY #define BOOST_HAS_DIRENT_H
(No sigaction (XSH4.0), no nanosleep (P1003.1b), and no clock_gettime(P1003.1b), to get those you have to define _XOPEN_SOURCE or _POSIX_SOURCE or some such.)
IMO this is the right thing to do, including making those #defines as neccessary.
Should these defines be done by the user when compiling boost or by boost itself, therefore enforcing a particular value for them? Markus
Markus Schöpflin <markus.schoepflin@comsoft.de> writes:
David Abrahams wrote:
Markus Schöpflin <markus.schoepflin@comsoft.de> writes:
What would you consider the correct way then? IMO we have three options.
1. Only use "-std strict_ansi". This means that the C header files (#include <c...>) included by boost libraries only define exactly those names specified in the C++ standard and nothing else. This would means changes to at least test, fs, regex and probably more libs. OTOH, this would mean that those libs are more conforming afterwards.
Here is the output of a configure run with the options "-pthread -tlocal -std strict_ansi":
#define BOOST_MSVC6_MEMBER_TEMPLATES #define BOOST_HAS_UNISTD_H #define BOOST_HAS_SCHED_YIELD #define BOOST_HAS_PTHREADS #define BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE #define BOOST_HAS_PTHREAD_DELAY_NP #define BOOST_HAS_PARTIAL_STD_ALLOCATOR #define BOOST_HAS_NRVO #define BOOST_HAS_NL_TYPES_H #define BOOST_HAS_LONG_LONG #define BOOST_HAS_GETTIMEOFDAY #define BOOST_HAS_DIRENT_H
(No sigaction (XSH4.0), no nanosleep (P1003.1b), and no clock_gettime(P1003.1b), to get those you have to define _XOPEN_SOURCE or _POSIX_SOURCE or some such.) IMO this is the right thing to do, including making those #defines as neccessary.
Should these defines be done by the user when compiling boost or by boost itself, therefore enforcing a particular value for them?
Boost should detect the compiler settings as far as possible. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
Markus Schöpflin wrote:
Jonathan Wakely wrote:
On Wed, Aug 11, 2004 at 12:43:37PM +0200, Markus Sch?pflin wrote:
- The use of "-std strict_ansi -nopure_cname" was causing all kinds of troubles for me. I replaced that with "-D__USE_STD_IOSTREAM -nousing_std" which seems to work far better.
This seems a bit hasty IMHO. Surely it would be better to make Boost work with the compiler in strict_ansi mode than just force the compiler to act in a non-standard way?
What would you consider the correct way then? IMO we have three options.
1. Only use "-std strict_ansi". This means that the C header files (#include <c...>) included by boost libraries only define exactly those names specified in the C++ standard and nothing else. This would means changes to at least test, fs, regex and probably more libs. OTOH, this would mean that those libs are more conforming afterwards.
Here is the output of a configure run with the options "-pthread -tlocal -std strict_ansi":
#define BOOST_MSVC6_MEMBER_TEMPLATES #define BOOST_HAS_UNISTD_H #define BOOST_HAS_SCHED_YIELD #define BOOST_HAS_PTHREADS #define BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE #define BOOST_HAS_PTHREAD_DELAY_NP #define BOOST_HAS_PARTIAL_STD_ALLOCATOR #define BOOST_HAS_NRVO #define BOOST_HAS_NL_TYPES_H #define BOOST_HAS_LONG_LONG #define BOOST_HAS_GETTIMEOFDAY #define BOOST_HAS_DIRENT_H
(No sigaction (XSH4.0), no nanosleep (P1003.1b), and no clock_gettime(P1003.1b), to get those you have to define _XOPEN_SOURCE or _POSIX_SOURCE or some such.)
[snip] I have been doing some more research on this. When _PURE_CNAME is in effect (which it is when using "-std strict_ansi") there is no way (read as: I didn't find one) to get at those functions, no matter how you define _XOPEN_SOURCE or _POSIX_SOURCE because the C++ compiler brings its own set of C header files which don't include the system header files in that case. Therefore this option is out of question, I think. Markus
On Thu, Aug 12, 2004 at 05:15:41PM +0200, Markus Sch?pflin wrote:
(No sigaction (XSH4.0), no nanosleep (P1003.1b), and no clock_gettime(P1003.1b), to get those you have to define _XOPEN_SOURCE or _POSIX_SOURCE or some such.)
[snip]
I have been doing some more research on this. When _PURE_CNAME is in effect (which it is when using "-std strict_ansi") there is no way (read as: I didn't find one) to get at those functions, no matter how you define _XOPEN_SOURCE or _POSIX_SOURCE because the C++ compiler brings its own set of C header files which don't include the system header files in that case.
Ouch! so strict_ansi means "strict ANSI and nothing else, if it wasn't listed in ISO 14882 it doesn't exist and you're not allowed to use it, in fact, you shouldn't even know about it. Who told you there was a function called nanosleep?" I suppose it means you can write a program that includes names such as nanosleep in the global namespace without getting unintened clashes from the standard headers. But it would be nice if there was an alternative way of getting at the POSIX etc. names.
Therefore this option is out of question, I think.
You've convinced me, I'll shut up :) jon
Jonathan Wakely <cow@compsoc.man.ac.uk> writes:
On Thu, Aug 12, 2004 at 05:15:41PM +0200, Markus Sch?pflin wrote:
(No sigaction (XSH4.0), no nanosleep (P1003.1b), and no clock_gettime(P1003.1b), to get those you have to define _XOPEN_SOURCE or _POSIX_SOURCE or some such.)
[snip]
I have been doing some more research on this. When _PURE_CNAME is in effect (which it is when using "-std strict_ansi") there is no way (read as: I didn't find one) to get at those functions, no matter how you define _XOPEN_SOURCE or _POSIX_SOURCE because the C++ compiler brings its own set of C header files which don't include the system header files in that case.
Ouch! so strict_ansi means "strict ANSI and nothing else, if it wasn't listed in ISO 14882 it doesn't exist and you're not allowed to use it, in fact, you shouldn't even know about it. Who told you there was a function called nanosleep?"
I suppose it means you can write a program that includes names such as nanosleep in the global namespace without getting unintened clashes from the standard headers. But it would be nice if there was an alternative way of getting at the POSIX etc. names.
Therefore this option is out of question, I think.
You've convinced me, I'll shut up :)
Should we consider a setup where the default for user code is strict ansi, but libraries are compiled with whatever options are needed to make those declarations available when needed? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
Markus Schöpflin wrote:
I just started downloading the current CVS snapshot to have a look at this problem.
bjam -sTOOLS=tru64cxx65 unit_test_result.o ...found 404 targets... ...updating 8 targets...
bjam -sTOOLS=tru64cxx65 unit_test_suite.o ...found 390 targets... ...updating 8 targets...
Here are the results from the CVS snapshot 04-08-11-0300. I used Compaq C++ V6.5-041 for Compaq Tru64 UNIX V5.1B (Rev. 2650), which is the latest compiler available, as far as I can tell. The compiler was installed on OSF1/V5.1/alpha. ~/net/src/boost-04-08-11-0300/libs/test/build tru64cxx65-C++-action ../../../bin/boost/libs/test/build/libboost_test_exec_monitor.a/tru64cxx65/debug/unit_test_result.o tru64cxx65-C++-action ../../../bin/boost/libs/test/build/libboost_test_exec_monitor.a/tru64cxx65/debug/threading-multi/unit_test_result.o tru64cxx65-C++-action ../../../bin/boost/libs/test/build/libboost_unit_test_framework.a/tru64cxx65/debug/unit_test_result.o tru64cxx65-C++-action ../../../bin/boost/libs/test/build/libboost_unit_test_framework.a/tru64cxx65/debug/threading-multi/unit_test_result.o tru64cxx65-C++-action ../../../bin/boost/libs/test/build/libboost_test_exec_monitor.so/tru64cxx65/debug/unit_test_result.o tru64cxx65-C++-action ../../../bin/boost/libs/test/build/libboost_test_exec_monitor.so/tru64cxx65/debug/threading-multi/unit_test_result.o tru64cxx65-C++-action ../../../bin/boost/libs/test/build/libboost_unit_test_framework.so/tru64cxx65/debug/unit_test_result.o tru64cxx65-C++-action ../../../bin/boost/libs/test/build/libboost_unit_test_framework.so/tru64cxx65/debug/threading-multi/unit_test_result.o ...updated 8 targets... BUT on the other hand: ~/net/src/boost-04-08-11-0300/libs/test/build tru64cxx65-C++-action ../../../bin/boost/libs/test/build/libboost_test_exec_monitor.a/tru64cxx65/debug/unit_test_suite.o cxx: Fatal: A memory access violation (bus error or segmentation fault) has occurred. Please submit a problem report. cxx -c -tlocal -noimplicit_include -D__USE_STD_IOSTREAM -nousing_std -msg_display_number -msg_disable 186,450,1115 -DBOOST_TEST_NO_AUTO_LINK=1 -g -O0 -inline none -I"../../../bin/boost/libs/test/build" -I"/net/users/schoepflin/src/boost-04-08-11-0300" -o "../../../bin/boost/libs/test/build/libboost_test_exec_monitor.a/tru64cxx65/debug/unit_test_suite.o" "/net/users/schoepflin/src/boost-04-08-11-0300/libs/test/build/../src/unit_test_suite.cpp" There must be some difference between my test platform and the one used to run the regression tests but I have no idea where to start looking. Just to be sure I checked with boost 1.30.0 and the test library compiles ok with the current toolset. Markus
--- Markus_Sch�pflin <markus.schoepflin@comsoft.de> wrote:
C++ V6.5-041 for Compaq Tru64 UNIX V5.1B (Rev. 2650), which is the latest compiler available, as far as I can tell. The compiler was installed on OSF1/V5.1/alpha.
The tests were run with this compiler: Compaq C++ V6.5-031 for Compaq Tru64 UNIX V5.1 (Rev. 732)
cxx: Fatal: A memory access violation (bus error or segmentation fault) has occurred. Please submit a problem report. ... There must be some difference between my test platform and the one used to run the regression tests but I have no idea where to start looking.
With the latest cvs I am getting the exact same results as Markus even though my compiler is a slightly older version. Gennadiy's fixes appear to have done something good. The internal compiler error is triggered by this construct in unit_test_suite.cpp: BOOST_UT_LOG_BEGIN( BOOST_TEST_STRING_LITERAL( __FILE__ ), __LINE__, log_fatal_errors ) "Test case initialization has failed" BOOST_UT_LOG_END; Using the preprocessed file, this doesn't compile: boost::unit_test::unit_test_log::instance() << boost::unit_test::begin() << boost::unit_test::level( log_fatal_errors ) << boost::unit_test::file((boost::unit_test::literal_string( "junk.c pp", sizeof( "junk.cpp" ) - 1))) << boost::unit_test::line( 127 ) << "Test case initialization has failed" << boost::unit_test::end();; But this does: boost::unit_test::literal_string lit_str( "junk.cpp", sizeof( "junk.cpp" )-1); boost::unit_test::unit_test_log::instance() << boost::unit_test::begin() << boost::unit_test::level( log_fatal_errors ) << boost::unit_test::file(lit_str) //<< boost::unit_test::file((boost::unit_test::literal_string( "junk.c pp", sizeof( "junk.cpp" ) - 1))) << boost::unit_test::line( 127 ) << "Test case initialization has failed" << boost::unit_test::end();; I.e. the ICE could be avoided by changing the BOOST_UT_LOG_BEGIN macro. Gennadiy, email me if you are interested in getting access to our machine in order to fix this problem. Ralf __________________________________ Do you Yahoo!? Yahoo! Mail is new and improved - Check it out! http://promotions.yahoo.com/new_mail
participants (7)
-
David Abrahams -
Gennadiy Rozental -
Johan Nilsson -
John Maddock -
Jonathan Wakely -
Markus Schöpflin -
Ralf W. Grosse-Kunstleve