[boost] Re: Using variant library with Boost 1.30.0
Allen Bierbaum wrote: > I have been very impressed with the Variant library and started using it > with Boost 1.29. Good to hear. I'd be interested in your experience using the library in a real-world (?) application. > I now need to start to using Boost 1.30.0 though and I don't think the > variant library distributed for the review will work with the 1.30.0 > release. > > Does anyone have any suggestions how I can use the variant library with > Boost 1.30.0? Anyone have an updated distribution of the Variant library? I plan to ready the code for release with 1.31. Until then, you can try using the code in the sandbox, which I have recently updated to work with 1.30. Note, however, that the code in the sandbox will change -- sometimes significantly -- and integrates variant with other libraries I am developing, such as Boost.Visitor and Boost.Move. If this is a problem for you, you may want to update the variant submission code yourself. Most of the required changes are to accomodate class and header name-changes in MPL between 1.29 and 1.30 -- nothing terribly significant. Thanks, Eric ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Threads Lib and DLL Issues
MSCV70P.DLL is a redistributable file - it is the application writer's responsibility to install this file along with their application. Ditto MSVCRT.dll and several others - do a search for "redist.txt". If you are worried about incompatibilities between versions, you can install copies of these files into your application directory rather than the windows system directory. Regards, Dave > -Original Message- > From: David Brownell [mailto:[EMAIL PROTECTED] > Sent: Monday, March 31, 2003 5:22 PM > To: [EMAIL PROTECTED] > Subject: [boost] Threads Lib and DLL Issues > > > When using the current version of the boost threads DLL, the > thread DLL > appears to link with the DLL version of the RTLs. While this > works on the > machine that compiled the exe, it does not work when moving > the exe to a > different version of Windows. For example, I am developing > on a Win XP > machine, and when I build an exe it works fine. When I move > that exe and > the threads DLL to a Win2K machine, the thread DLL is trying > to link with > MSVCP70.DLL (and others), which aren't available on Win2K. > So, I would like > the threads DLL to link with the standard RTL libs rather than the DLL > versions. Any ideas on how I can do that through the jamfiles? > > In killing two birds with one stone, I would also like to > know how to change > the name of the threads DLL. I tried to modify line 48 in > thread's jamfile, > but that didn't seem to work. > > TIA, > David Brownell > > > > ___ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] bad_lexical_cast
>From: "Alisdair Meredith" <[EMAIL PROTECTED]> > I see that this has been the topic of much discussion lately, but just > confirming this little warning from the regressions has not snuck by > unnoticed: > > # 'boost::bad_lexical_cast::what()' hides inherited virtual function > 'std::exception::what() const' > > [const missing, to state the obvious] > > This apparently only affects 3 compilers on Windows, haven't > cross-checked the other platforms. Thanks for pointing this out. It's fixed now. Yeah, oddly enough, this gave no warning, even when running on the highest warning level, and strict mode, on Intel C++ 7, and MSVC 6/7. Also, the tests only checks that the exception is thrown when it's supposed to, it doesn't check what(). Regards, Terje ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Threads Lib and DLL Issues
When using the current version of the boost threads DLL, the thread DLL appears to link with the DLL version of the RTLs. While this works on the machine that compiled the exe, it does not work when moving the exe to a different version of Windows. For example, I am developing on a Win XP machine, and when I build an exe it works fine. When I move that exe and the threads DLL to a Win2K machine, the thread DLL is trying to link with MSVCP70.DLL (and others), which aren't available on Win2K. So, I would like the threads DLL to link with the standard RTL libs rather than the DLL versions. Any ideas on how I can do that through the jamfiles? In killing two birds with one stone, I would also like to know how to change the name of the threads DLL. I tried to modify line 48 in thread's jamfile, but that didn't seem to work. TIA, David Brownell ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] indentation algorithm for stream objects
Reece Dunn wrote: This utility class provides a mechanism for adding indentation to an I/O stream. I was wondering who would be interested in it, or if anyone has anything similar. This sounds like marg_ostream. See: http://aspn.activestate.com/ASPN/Mail/Message/1526216 ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] indentation algorithm for stream objects
Reece Dunn wrote: > This utility class provides a mechanism for adding > indentation to an I/O > stream. I was wondering who would be interested in it, or if > anyone has > anything similar. [snip] I'm very interested in such a functionality, but your attachment seems to be broken. Could you please re-send it (maybe directly to me)? Thanks and regards Hartmut ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: When to use which ETI workaround?
> Sorry for the late reply, got too many things on my plate. No problem, I happen to have abandoned development on MSVC7.0 temporarily, for other reasons. > Yep, in most cases that's enough. It's _always_ enough with MSVC 6.0, but > 7.0 sometimes uses another, unknown, type for the instantiation's > placeholder argument, so you cannot simply specialize the template anymore, Interesting, I wonder why they changed this :-(. I guess I'll drop 7.0 as soon as 7.1 is officially released what would obviously save quite a bit of trouble. > The VC 7.0-specific case is rare enough to always try the 'int' > specialization first (which is obviously less painful than the other), and > then switch to the 'is_msvc_eti_arg'-based workaround if that doesn't help. > VC 7.0 is not our production environment here at work, so I didn't have > enough experience with it to be able to figure out when exactly these cases > occur. Good to know, I feared that there are a few more incompatible ways to circumvent ETI. Thanks a lot! Regards, Andreas ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] bad_lexical_cast
I see that this has been the topic of much discussion lately, but just confirming this little warning from the regressions has not snuck by unnoticed: # 'boost::bad_lexical_cast::what()' hides inherited virtual function 'std::exception::what() const' [const missing, to state the obvious] This apparently only affects 3 compilers on Windows, haven't cross-checked the other platforms. -- AlisdairM ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] linux regression box upgrade
FYI: the linux box running the daily regression tests has been upgraded to Mandrake Linux 9.2 (gcc 3.2.2 / glibc 2.3.1). -- Alkis ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] (no subject)
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Reece Dunn > Sent: Sunday, March 30, 2003 12:18 PM > To: [EMAIL PROTECTED] > Subject: [boost] (no subject) Thanks for repackaging the code inside zip, and for mor examples, and making it work 'strictly' MXVC 7.0 Level 4 & NO language extensions with > template< typename CharT, class TraitsT, typename ForwardIterator > > inline std::basic_ostream< CharT, TraitsT > & operator<< > ( >std::basic_ostream< CharT, TraitsT > & os, >formatlist_t< ForwardIterator > const & fi > ); > I shall look at adding support for 2D or nD output, however, this was not in > the initial design plans. As the name formatlist suggests, this was intended > for list outputting (1D) only. For array and matrix, you might of course like to see the Boost contributions in array and UBLAS. But handling at least 2D and 3D C arrays is still acommon requirement. > I was gauging interest before I worked on more complicated examples. As for > documentation, I was looking at getting the design stabilized first, > otherwise there may be problems synchronizing the documentation with the > code. > > I have produced a more complicated set of examples that demonstrate the > applicability of my formatlist manipulator. > > I have a few ideas on where I would like to take this: > [1] I would like to parametize the seperator and open/close list types to a > template type. This will allow the character type used by my current > implementation, as well as a character array, std::string and possibly other > types like wide characters. Some people are turned on by wide characters. > [2] I have recently had a look at the "I/O operationd for STL containers" > thread. Is there a way we can merge these two threads, or should they be > kept seperate? There are similarities and differences to both approaches. > Both are an attempt to solve a similar problem from different angles. > > The io_format approach is very nice - I like the way it hooks into the I/O > stream state mechanism to make the usage for a type intuative; it does, > however have a complex setup for each type on each output stream that uses > that type. Also, what are the run-time overheads for the use of the xalloc > mechanism, especially if a lot of different containers need to be outputted? > > My approach does not handle std::pair or nD object output, nor does it > support seperators or list brackets that are wide characters or strings > (although I am looking at generalizing this). The point of my version was to > allow the output of a list specified between two iterators with a > specialization for containers to save writing: >std::formatlist( c.begin(), c.end()) > every time you needed to output the entire container. I also wanted an > implementation that has a small run-time overhead. I also note the complexity of the xalloc with some concern. The simplicity of formatlist is appealing. > [3] Would it be possible to combine both approaches into a single library, > where the user can choose which version to use: state objects (io_format); > or manipulators (formatlist)? Sounds interesting. > [4] I am intending on changing the stl namespace to something more > appropriate. Any suggestions are welcome. Doubt that you should worry at present - boost\io\ may be suitable? Your new examples show how easy it is to use. Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Problems compiling microsec_time_clock with cygwin/gcc
Thnx! Will you please keep me posted/updated? Regards /Michel Jeff Garland wrote: >> I get the following error when trying to compile >> date_time/microsec_time_clock.hpp from the current CVS with >> cygwin/gcc. >> >> C:/Packages/boost/work/boost/date_time/microsec_time_clock.hpp:44: >> parse >> error >>before `;' token > > I believe there are issues supporting the C interface used by the > microsec_time_clock on windows. We probably need some macros to fix > this... > > Jeff > ___ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] indentation algorithm for stream objects
This utility class provides a mechanism for adding indentation to an I/O stream. I was wondering who would be interested in it, or if anyone has anything similar. This utility could have many applications, some of which include: * integration into a tracing library, allowing function calls to be indented, making it easier to see code execution flow -- I have used this technique to track an infinite recursion; * integration into a code beautifier for C/C++ (indenting on braces) or XML/HTML (indenting on tags with child nodes); * tree output helper -- will indent a tree structure, removing the indentation code from the output algorithm. It has been designed to be as flexible as possible, allowing both the fill character and the fill length to be customized. The indentation mechanism (in the indent() function) is optimized to perform as few output operations as possible. There are presently two ways that you can add an indentation level. The first is explicitly via a beginIndent() call, requiring a call to endIndent(); the second is to use the indentor::block class (this calls beginIndent() on construction and endIndent() on deconstruction). There are several ways that I am looking at extending this: [1] Parametizing the fill type from char to a template type CharT, allowing it to be either char or wchar_t. [2] Making use of a character traits type to abstract from explicit use of std::memset. [3] Adding safety checking on the endIndent() call to ensure that: m_indent.level >= 0 [4] Allowing the indent() function to optionally output a newline character before it performs the indenting. The example in the zip file provides a demonstration of how to use this class. If anyone is interested in having a more complicated example of its usage, or has any suggestions on how to improve it, comments on the utility, all are welcome. -rhd- mailto:[EMAIL PROTECTED] _ Worried what your kids see online? Protect them better with MSN 8 http://join.msn.com/?page=features/parental&pgmarket=en-gb&XAPID=186&DI=1059 indentor.zip Description: Zip compressed data ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Problems compiling microsec_time_clock with cygwin/gcc
> I get the following error when trying to compile > date_time/microsec_time_clock.hpp from the current CVS with cygwin/gcc. > > C:/Packages/boost/work/boost/date_time/microsec_time_clock.hpp:44: parse > error >before `;' token I believe there are issues supporting the C interface used by the microsec_time_clock on windows. We probably need some macros to fix this... Jeff ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] adding a generic list manipulator
My post dated March 30 2003 11:17AM should have had this heading, but I forgot to add a subject so it got named (no subject). You can find the details of that post at: http://aspn.activestate.com/ASPN/Mail/Message/boost/1587184 -rhd- mailto:[EMAIL PROTECTED] _ Overloaded with spam? With MSN 8, you can filter it out http://join.msn.com/?page=features/junkmail&pgmarket=en-gb&XAPID=32&DI=1059 indentor.zip Description: Zip compressed data ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Threading, boost_1_30_0, Linux, glibc-2.3.2
Here is some more on this problem. Perhaps someone on this list has some ideas where to look? Defining BOOST_NO_THREAD (or whatever it was) will "fix" the problem, but I suspect it's not the correct fix. The code will link OK dynamically, but not statically. That's strange. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=87491 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |NEEDINFO --- Additional Comments From [EMAIL PROTECTED] 2003-03-28 13:26 --- That looks like boost is broken (or whatever uses pthread_* functions without making them #pragma weak and using only conditionally (as does e.g. libstdc++). Can you find out what exactly uses them without making them weak? On Friday 28 March 2003 08:09 am, Neal D. Becker wrote: > I just installed boost_1_30_0 and updated to glibc-2.3.2 on my RH8.0 Linux > box. Now I have problems to create a static link of my executable. > > I'm wondering what is the correct link procedure. > > g++ -Wall -I ../../src/fixed -I ../../src/float -O3 -ffast-math > -fstrict-aliasing -m3dnow -ggdb -march=athlon-xp -mcpu=athlon-xp > -fprofile-arcs -D_GNU_SOURCE -Wp,-MMD,.d/Test34.d -o Test34 Test34.o -L. > -liTest -lpopt -lcephes -lfftw -static > Test34.o: In function > `boost::detail::shared_count::shared_count[in-charge]har, std::char_traits >*, > boost::checked_deleter > > > >(std::basic_ofstream > > >*, boost::checked_deleter > > > )': > > /usr/include/c++/3.2/iostream:62: undefined reference to > `pthread_mutex_init' Test34.o: In function > `boost::detail::sp_counted_base_impl std::char_traits >*, boost::checked_deleter std::char_traits > > >::~sp_counted_base_impl [in-charge]()': > /usr/include/c++/3.2/iostream:62: undefined reference to > `pthread_mutex_destroy' > Test34.o: In function > `boost::detail::sp_counted_base_impl std::char_traits >*, boost::checked_deleter std::char_traits > > >::~sp_counted_base_impl [in-charge > deleting]()': /usr/include/c++/3.2/iostream:62: undefined reference to > `pthread_mutex_destroy' > Test34.o: In function `boost::detail::sp_counted_base::~sp_counted_base > [in-charge]()': > /usr/include/c++/3.2/iostream:62: undefined reference to > `pthread_mutex_destroy' > Test34.o: In function `boost::detail::sp_counted_base::~sp_counted_base > [in-charge deleting]()': > /usr/include/c++/3.2/iostream:62: undefined reference to > `pthread_mutex_destroy' > collect2: ld returned 1 exit status > > It seems adding -lpthread fixes this, but 1) I don't use thread 2) it isn't > needed for normal (nonstatic) link, and wasn't needed before the updates. > > Now I see I have /usr/lib/libboost_thread.so.xxx > > What is it for? > > nm /usr/lib/libboost_thread.so.1.30.0 > nm: /usr/lib/libboost_thread.so.1.30.0: no symbols > > Is it just used to pull in -lpthread? > > Apparantly, the pthread is needed because I used a boost shared pointer. > ___ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] shared_ptr rebind
Hi,
I was wondering whether anyone had thought about adding a rebind nested
template class to the boost ptrs, similar to those used by allocators.
A situation has recently occurred where I need to get a ptr to a derived
class from a pre to a base class, where the ptr to the base class is used
a typedef e.g
struct Base {};
typedef boost::shared_ptr BasePtr;
void func(const BasePtr& base)
{
}
struct Derived : public Base {};
typedef boost::shared_ptr DerivedPtr;
^^
Don't want to have to do this
func(DerivedPtr(new Derived)) ... etc
The reason I dont want to have to do the second typedef is that we have a
number of smart pointer classes of our own, and the type of the BasePtr
should be an implementation detail. If boost::shared_ptr had a rebind,
then we could add it to our own classes as well, and the actual wrapper
used would become an implementation detail
Cheers
Ben Young
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
