port of library to vacpp (item 2)
I stumble on another problem when trying to compile the test library with IBM/VisualAge (vacpp). Apparantly vacpp has a problem on lines 97,98 and 99 of boost/test/detail/basic_cstring/basic_cstring.hpp. Basically the problem is this: this file declares a class template < class CharT > class basic_string { public: typedef basic_string<CharT> self_type ; self_type& trim_left(self_type exclusions = self_type() ) ; // line 97 } ; If I now remove the default initializer, vacpp does not choke anymore (same situation on lines 98 and 99). I tried to isolate this problem in small test but in a small test vacpp seems to deal with the situation just fine. Thus AFAICT this is a compiler-bug but would anyone mind if I remove the default initializers or just remove them in the vacpp compilation to get one step closer to running the regression tests on vacpp again.
On Fri, May 28, 2004 at 12:57:56PM +0200, Toon Knapen wrote:
Apparantly vacpp has a problem on lines 97,98 and 99 of boost/test/detail/basic_cstring/basic_cstring.hpp.
Basically the problem is this: this file declares a class
template < class CharT > class basic_string { public: typedef basic_string<CharT> self_type ;
self_type& trim_left(self_type exclusions = self_type() ) ; // line 97 } ;
How about overloading the function to remove the default arg? self_type& trim_left(self_type exclusions); self_type& trim_left() { return trim_left(self_type()); } jon
Jonathan Wakely wrote:
On Fri, May 28, 2004 at 12:57:56PM +0200, Toon Knapen wrote:
Apparantly vacpp has a problem on lines 97,98 and 99 of boost/test/detail/basic_cstring/basic_cstring.hpp. self_type& trim_left(self_type exclusions = self_type() ) ; // line 97
How about overloading the function to remove the default arg?
self_type& trim_left(self_type exclusions);
self_type& trim_left() { return trim_left(self_type()); }
Even better and works fine too.
Hi, I haven't been following this thread, however I see, that you are proposing a functionality, that overlap with the string algorithm library. For instance, trim functionality is already there, and if basic_cstring can provide Collection/Range compatible interface, it will work straight away. Have a look into boost/algorithm/string Regards, Pavol On Fri, May 28, 2004 at 12:39:35PM +0100, Jonathan Wakely wrote:
On Fri, May 28, 2004 at 12:57:56PM +0200, Toon Knapen wrote:
Apparantly vacpp has a problem on lines 97,98 and 99 of boost/test/detail/basic_cstring/basic_cstring.hpp.
Basically the problem is this: this file declares a class
template < class CharT > class basic_string { public: typedef basic_string<CharT> self_type ;
self_type& trim_left(self_type exclusions = self_type() ) ; // line 97 } ;
How about overloading the function to remove the default arg?
self_type& trim_left(self_type exclusions);
self_type& trim_left() { return trim_left(self_type()); }
jon
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Pavol Droba wrote:
Hi,
I haven't been following this thread, however I see, that you are proposing a functionality, that overlap with the string algorithm library.
For instance, trim functionality is already there, and if basic_cstring can provide Collection/Range compatible interface, it will work straight away.
Have a look into boost/algorithm/string
First of all I agree that we should not implement overlapping functionality in different boost libraries but OTOH I don't know why the developer of the test library implements its own string class. I do would like to remark that we should minimise dependencies in the test-tools libraries and make them as lightweight as possible. Because if the test tools don't compile, they can't be used to verify if the rest compiles !?
Toon Knapen wrote:
I stumble on another problem when trying to compile the test library with IBM/VisualAge (vacpp).
Apparantly vacpp has a problem on lines 97,98 and 99 of boost/test/detail/basic_cstring/basic_cstring.hpp.
Basically the problem is this: this file declares a class
template < class CharT > class basic_string { public: typedef basic_string<CharT> self_type ;
self_type& trim_left(self_type exclusions = self_type() ) ; // line 97 } ;
On second thought, I would like to change the above signature into: self_type& trim_left(const self_type& exclusions = self_type() ); // line 97 Taking the argument by const-reference does not pose a problem for the vacpp compiler and AFAICT it's even better to take a const-reference as copying the argument by value. toon
On second thought, I would like to change the above signature into:
self_type& trim_left(const self_type& exclusions = self_type() ); // line 97
Taking the argument by const-reference does not pose a problem for the vacpp compiler and AFAICT it's even better to take a const-reference as copying the argument by value.
toon
No. sizeof(basic_cstring<>) is in most cases 8. I prefer to pass it by value. Gennadiy.
sizeof (blah) is only vaguely related to the length of time it takes a copy constructor to execute. At Tuesday 2004-06-01 05:31, you wrote:
On second thought, I would like to change the above signature into:
self_type& trim_left(const self_type& exclusions = self_type() ); // line 97
Taking the argument by const-reference does not pose a problem for the vacpp compiler and AFAICT it's even better to take a const-reference as copying the argument by value.
toon
No. sizeof(basic_cstring<>) is in most cases 8. I prefer to pass it by value.
Gennadiy.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
participants (5)
-
Gennadiy Rozental -
Jonathan Wakely -
Pavol Droba -
Toon Knapen -
Victor A. Wagner Jr.