 |
BorlandTalk.com
Borland discussion newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
George
Guest
|
 Posted: Fri Apr 02, 2004 8:05 am Post subject: Re: boost 1.31.0 |
 |
|
Duane Hebert" <spoo (AT) zowie_flarn (DOT) com> wrote
| Quote: | Has anybody updated boost to the latest build? I've tried it and
|
Haven't tried 1.31.0, but it's an interesting problem.
| Quote: |
void stringToLower(std::string &str) {
std::transform(
str.begin(),
str.end(),
str.begin(),
std::tolower); // this is line 433
}
I get compile error:
[C++ Error] stringfunctions.cpp(433): E2285 Could not find a match for
'_STL::transform<_InputIter1,_InputIter2,_OutputIter,_BinaryOperation>(char |
*,char *,char *,int
First of all, compiler gives suspicious error message; because 4 operand
transform looks like this:
template<class InputIterator, class OutputIterator, class UnaryFunction>
OutputIterator transform(
InputIterator _First1,
InputIterator _Last1,
OutputIterator _Result,
UnaryFunction _Func
);
it requires UnaryFunction (e.g. regular "ret (*)(arg)" function), not
_BinaryOperation. Though the template parameter names ain't necessary
meaningful, it seems to me STLPort has some problems here.
According to the error message compiler found int std::tolower(int) function
from <cctype> (probably included by one of other headers), which is what you
obviously wanted. Everything is fine with code, except string interators do
not have to be pointers, though it's obviously the case with STLPort. So
there is no reason why would compiler fail in this place.
Try more general solution from <locale>:
#include <locale>
#include <string>
template<typename charT>
void stringToLower(std::basic_string<charT> &str, const std::string&
locale_name)
{
std::locale loc( "German_Germany" );
std::use_facet<std::ctype( loc).tolower( &(*str.begin()),
&(*(str.end()-1)) );
}
// e.g. default for German
void stringToLower(std::string& str) {
stringToLower(str,"German_Germany"); }
|
|
| Back to top |
|
 |
Duane Hebert
Guest
|
| Posted: Fri Apr 02, 2004 12:01 pm Post subject: Re: boost 1.31.0 |
|
|
"George" <George@localhost> wrote
| Quote: | it requires UnaryFunction (e.g. regular "ret (*)(arg)" function), not
_BinaryOperation. Though the template parameter names ain't necessary
meaningful, it seems to me STLPort has some problems here.
According to the error message compiler found int std::tolower(int) function
from <cctype> (probably included by one of other headers), which is what you
obviously wanted. Everything is fine with code, except string interators do
not have to be pointers, though it's obviously the case with STLPort. So
there is no reason why would compiler fail in this place.
|
Thanks. I ended up replacing std::transform with
for (size_t i = 0, len = str.size(); i < len; ++i)
str[i] = std::tolower(str[i]);
This doesn't seem to be a problem. Boost seemed fine but
then I had problems building boost threads that I haven't resolved
yet. I need to have a static version of the thread libs. In the last
version I just created my own lib file with the boost obj files and
it worked fine. This one has some sort of auto_link thing that
requires specific lib names.
It doesn't seem that I can get bjam to make them.
It only wants to make the dll.
At any rate, thanks for the tips.
|
|
| Back to top |
|
|
Russell Hind
Guest
|
| Posted: Fri Apr 02, 2004 2:18 pm Post subject: Re: boost 1.31.0 |
|
|
Duane Hebert wrote:
| Quote: | "George" <George@localhost> wrote
Thanks. I ended up replacing std::transform with
for (size_t i = 0, len = str.size(); i < len; ++i)
str[i] = std::tolower(str[i]);
|
I think it is an STLPort/RogueWave problem. Even though STLPort is the
default STL, it still relies on RogueWave for certain features.
STLPort stuff is all in _STL namespace and RogueWave is in std
namespace. I think the tolower stuff works fine if you use
_USE_OLD_RW_STL
Cheers
Russell
|
|
| Back to top |
|
|
Duane Hebert
Guest
|
| Posted: Fri Apr 02, 2004 2:41 pm Post subject: Re: boost 1.31.0 |
|
|
"Russell Hind" <rhind (AT) mac (DOT) com> wrote
| Quote: | I think it is an STLPort/RogueWave problem. Even though STLPort is the
default STL, it still relies on RogueWave for certain features.
STLPort stuff is all in _STL namespace and RogueWave is in std
namespace. I think the tolower stuff works fine if you use
_USE_OLD_RW_STL
|
I've had some other problems with stlPort that ended up
dumping me in RW code so you may be correct. One
of the main reasons that we upgraded to BCB6 was
the problems that we had with RW. I prefer to replace
the function with the for loop that I've shown over returning
to RW.
It looks like with the new version of boost, the date_time libs
use something that causes a conflict with std::toupper. It may
be including ctype and the compiler is getting confused between
int toupper(int) and ELEM toupper(ELEM, localte) since
transform is taking a function pointer for the last arg and
it can't see the arg list to determine the difference between
ints and chars. Thomas pointed this out and I think that's
probably what is happening.
At any rate, until I can figure out how to get the boost::thread
stuff working I won't be upgrading. I've changed this function
any way as it doesn't seem any less efficient to use a for
loop.
|
|
| Back to top |
|
|
Nicola Musatti
Guest
|
| Posted: Mon Apr 05, 2004 6:36 am Post subject: Re: boost 1.31.0 |
|
|
Hallo, Duane.
Duane Hebert wrote:
[...]
| Quote: | This doesn't seem to be a problem. Boost seemed fine but
then I had problems building boost threads that I haven't resolved
yet. I need to have a static version of the thread libs. In the last
version I just created my own lib file with the boost obj files and
it worked fine. This one has some sort of auto_link thing that
requires specific lib names.
It doesn't seem that I can get bjam to make them.
It only wants to make the dll.
|
If I remember correctly it isn't possible to build a static version of
the Boost.Threads library. However, you should still be able to put
together your own lib. It should be possible to disable the auto_link
feature by defining a macro, something like BOOST_NO_LIB, I'm not sure
about the name. There is a paper by John Maddock in the Boost docs about
building libraries: http://www.boost.org/more/separate_compilation.html
Cheers,
--
Nicola Musatti
Team Thai Kingdom
|
|
| Back to top |
|
|
Duane Hebert
Guest
|
| Posted: Mon Apr 05, 2004 1:11 pm Post subject: Re: boost 1.31.0 |
|
|
"Nicola Musatti" <Nicola.Musatti (AT) ObjectWay (DOT) it> wrote
| Quote: | Hallo, Duane.
Duane Hebert wrote:
[...]
This doesn't seem to be a problem. Boost seemed fine but
then I had problems building boost threads that I haven't resolved
yet. I need to have a static version of the thread libs. In the last
version I just created my own lib file with the boost obj files and
it worked fine. This one has some sort of auto_link thing that
requires specific lib names.
It doesn't seem that I can get bjam to make them.
It only wants to make the dll.
If I remember correctly it isn't possible to build a static version of
the Boost.Threads library. However, you should still be able to put
together your own lib. It should be possible to disable the auto_link
feature by defining a macro, something like BOOST_NO_LIB, I'm not sure
about the name. There is a paper by John Maddock in the Boost docs about
building libraries: http://www.boost.org/more/separate_compilation.html
|
Thanks. That's the approach that we took (building our own static thread lib)
and it was working fine until I tried the update. I think I just need to disable
the auto_link. Thanks for the link, I'll look into it.
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
