- Boost-users - lists.preview.boost.org

boost::thread warnings?
by olexander_shyrokov 21 Apr '03

21 Apr '03

I got some warnings when compiling my program (see below). I am using Visual Studio C++ 6 and STLport 4.5.3 I've seen some questions about this issue in the mailing list, but did not get the feeling that I understand what is going on and when I can safly ignore them? Thanks a lot. c:\src\boost\boost\thread\exceptions.hpp(29) : warning C4275: non dll-interface class '_STL::logic_error' used as base for dll-interface class 'boost::lock_error' c:\progra~1\micros~3\vc98\include\stlport\stdexcept(72) : see declaration of 'logic_error' c:\src\boost\boost\thread\exceptions.hpp(35) : warning C4275: non dll-interface class '_STL::runtime_error' used as base for dll-interface class 'boost::thread_resource_error' c:\progra~1\micros~3\vc98\include\stlport\stdexcept(80) : see declaration of 'runtime_error' c:\src\boost\boost\thread\mutex.hpp(37) : warning C4275: non dll-interface class 'boost::noncopyable' used as base for dll-interface class 'boost::mutex' c:\src\boost\boost\noncopyable.hpp(22) : see declaration of 'noncopyable' c:\src\boost\boost\thread\mutex.hpp(75) : warning C4275: non dll-interface class 'boost::noncopyable' used as base for dll-interface class 'boost::try_mutex' c:\src\boost\boost\noncopyable.hpp(22) : see declaration of 'noncopyable' c:\src\boost\boost\thread\mutex.hpp(115) : warning C4275: non dll-interface class 'boost::noncopyable' used as base for dll-interface class 'boost::timed_mutex' c:\src\boost\boost\noncopyable.hpp(22) : see declaration of 'noncopyable' c:\src\boost\boost\thread\thread.hpp(39) : warning C4275: non dll-interface class 'boost::noncopyable' used as base for dll-interface class 'boost::thread' c:\src\boost\boost\noncopyable.hpp(22) : see declaration of 'noncopyable' c:\src\boost\boost\thread\thread.hpp(68) : warning C4275: non dll-interface class 'boost::noncopyable' used as base for dll-interface class 'boost::thread_group' c:\src\boost\boost\noncopyable.hpp(22) : see declaration of 'noncopyable' c:\src\boost\boost\thread\thread.hpp(79) : warning C4251: 'm_threads' : class '_STL::list<class boost::thread *,class _STL::allocator<class boost::thread *> >' needs to have dll-interface to be used by clients of class 'boost::thread_group'

1 0

Problems linking with Boost 1.29.0 thread lib, Linux/g++ 3.2.2 -r2
by subsample 21 Apr '03

21 Apr '03

Failing to link a program with libboost_thread, even though I supply the -lboost_thread directive in the makefile. I'm kind of new to makefiles, having only used Visual C++ in Windows untill recently. I 've tried changing things around a bit, doesn't help. A minimal test program I wrote links fine with boost_thread though. My makefile looks like this: CC=g++ CFLAGS=-g LDFLAGS=-L/home/sub/Libs/alsa/lib -lasound -lboost_thread -lpthread alsatest: alsatest.o $(CC) $(LDFLAGS) -o alsatest SmallObj.o alsatest.o alsatest.o: smallobj.o $(CC) $(CFLAGS) alsatest.cpp -c smallobj.o: $(CC) $(CFLAGS) /usr/include/loki/SmallObj.cpp -c clean: rm -f *.o alsatest g++ complains about the same missing references no matter if I include the -lboost_thread or not. If someone could point out what I'm doing wrong I'd be grateful : )

1 1

Typo in boost/config/compiler/visualc.hpp
by Vaclav Vesely 19 Apr '03

19 Apr '03

line 26: #if (_MSC_VER <= 1300) // 1200 == VC++ 7.0 The comment is inconsistent with the code. Regards, w

2 1

RE: [Boost-Users] lexical_cast regression
by Tom Matelich 18 Apr '03

18 Apr '03

> From: Terje Slettebø [mailto:tslettebo@chello.no] > > >From: "Tom Matelich" <tmatelich(a)zetec.com> > > > I haven't gone and looked at the boost ml archives to track > > the reason for > > this down, but the addition of stream.unsetf(std::ios::skipws) in > > lexical_cast caused some of our code to fail. I've commented it out > > locally, and was wondering why it was decided this is more > > appropriate default behavior. > > It was done to avoid the problems with throwing exceptions on > whitespace. > For example, without it, the following would throw a bad_lexical_cast: > > lexical_cast<std::string>(' '); // A space character > > What kind of code is the current version failing at? > We have some legacy files that are converted to xml through some process (I didn't write it) and it ends up with space-padded strings for ints. So the test case was dying converting " 86" to an int. I can see its purpose, except that example wouldn't happen because of the std::string overload, right? Tom ----------------------------------------------------------------------- DISCLAIMER: Information contained in this message and/or attachment(s) may contain confidential information of Zetec, Inc. If you have received this transmission in error, please notify the sender by return email. -----------------------------------------------------------------------

2 1

Re: [boost] lexical_cast problem
by Terje Slettebø 18 Apr '03

18 Apr '03

>From: "Terje Slettebø" <tslettebo(a)chello.no> > Hm, just now, I sent a reply to a similar problem report at Boost-Users > list, about why whitespace skipping is turned off in the new lexical_cast > version. It was to avoid having things like "lexical_cast<std::string>(' '); > // Space character" work, which used to throw an exception. I meant it was to avoid having it throw an exception, in other words, to _have_ it work. Terje

1 0

Re: [boost] lexical_cast problem
by Terje Slettebø 18 Apr '03

18 Apr '03

>From: "Vladimir Prus" <ghost(a)cs.msu.su> >Subject: [boost] lexical_cast problem Not again. :) > I've just updated my project to use boost 1.30 and also gcc 3.2 and see > exception which reads: > > bad lexical cast: source type value could not be interpreted as target, > Target=i, Source=Ss Ah, yes, good ol' g++ with its wonderfully descriptive type_info names... ;) > The simple reproduction recipe is: > > #include <boost/lexical_cast.hpp> > #include <string> > > int main() > { > boost::lexical_cast<int>(std::string(" 0")); > } "Houston, we have a problem..." Hm, just now, I sent a reply to a similar problem report at Boost-Users list, about why whitespace skipping is turned off in the new lexical_cast version. It was to avoid having things like "lexical_cast<std::string>(' '); // Space character" work, which used to throw an exception. However, it seems this change has had undesired side-effects, in that code like the above now fails to work. Frankly, I don't know what to do with this... > Note the space in string. The exception does not occur with gcc 2.95, but only > with 3.2. I wonder if this should/can be fixed? Personally, I'd expect this > code to work. > > And a related note: the exception's what() above is not quite helpfull. The current version in the CVS has got a changed exception handling, where bad_lexical_cast now looks like this: class bad_lexical_cast : public std::bad_cast { public: // ... const std::type_info &source_type() const const std::type_info &target_type() const virtual const char *what() const throw() { return "bad lexical cast: " "source type value could not be interpreted as target"; } }; In other words, what() now returns the original text, and the type_info objects for the types used is now returned by member functions. > Is it > possible to output the stringstream content (if source -> stringstream > conversion was successfull?) Yes, that's possible. I guess I'll leave it to Kevlin to comment on this. Thanks for the report, to both you and Tom Matelich at Boost-Users list. Regards, Terje

1 0

lexical_cast regression
by Tom Matelich 18 Apr '03

18 Apr '03

I haven't gone and looked at the boost ml archives to track the reason for this down, but the addition of stream.unsetf(std::ios::skipws) in lexical_cast caused some of our code to fail. I've commented it out locally, and was wondering why it was decided this is more appropriate default behavior. Thanks, Tom ----------------------------------------------------------------------- DISCLAIMER: Information contained in this message and/or attachment(s) may contain confidential information of Zetec, Inc. If you have received this transmission in error, please notify the sender by return email. -----------------------------------------------------------------------

2 1

kinda, sorta, like an iterator for dynamic_bitset, but not really.
by Andy Klapper 18 Apr '03

18 Apr '03

I'm currently writing some code for a client where I make extensive use of dynamic_bitsets to determine very quickly which options are appropriate based on a number of criteria. I set up before hand dynamic_bitset for each person, place, and thing which are then bitwise AND'd together to determine where the points of intersection are. What I need is something with an iterator syntax that returns the indexes whose values are set. I could of course just loop through looking for set values, but that seems silly when you think that entire blocks of bits can be skipped if the block has a value of zero. So my questions is, before I set out to write some code, has somebody already done this? It seems like a logical use of dynamic_bit set so it does not seem implausible. If not, any suggestions or warnings? Thanks, Andy

2 1

Understanding MPL
by Edward Diener 18 Apr '03

18 Apr '03

I am trying to understand how the MPL library works. I first read "The Boost C++ Metaprogramming Library" by Aleksey Gurtovoy and David Abrahams. When I get to Basic Usage I see this: template< typename Condition , typename T1 , typename T2 > struct if_ { typedef /*unspecified*/ type; }; I am really having trouble understanding the next to last line. How can "typedef type;" be a valid C++ construct and, if it is, what does it mean ? I always though that a typedef must specify an actual type but I don't see any in the expression above.

7 27

RE: [Boost-Users] Re: command line parsing
by Ben Hutchings 17 Apr '03

17 Apr '03

E. Scott Larsen wrote: > Just FYI to this thread in general. It's been a while since I've messed > with WinMain and command lines, but if my memory serves me right (it was > at a different place, so I don't have the code here), there's some > additional whacky issues here. WinMain recieves the first arguments > differently depending on how it is run: > *) from MSVC debugger > *) from a commandline > *) by clicking on an shortcut icon > *) by clicking in an explorer window I find this hard to believe, as WinMain is just given a pointer into the command line returned by GetCommandLine(), incremented past the program name and any following space. > don't remember which is which, but one gives just the executable name, > one gives the full path to the executable (seems like there's two > variations on this, like one is quoted and one is not, don't remember > the details), and it seems like there's one that doesn't give the > executable at all. I can imagine there's some variation in program name; it's normal for programs to be started with short names rather than their full filenames. The quoting is weird though; that should be removed before you see it. > Also, I _distinctly_ remember something very whacky when I used unicode, > I don't remember the details, but the commandline arguments were a > significant pain for a program built with unicode support using the > unicode windows entry function. That still tastes bad in my mouth. According to the docs, this ought to work: wchar_t ** argv; int argc; argv = CommandLineToArgvW(GetCommandLineW(), &argc); but I've never tried it; maybe it doesn't. If you were using WinCE then I feel your pain and hope you've recovered.

3 2