January 2005 - Boost - lists.preview.boost.org

[Boost-bugs] [ boost-Support Requests-1106566 ] Boost 1.31.0: Compiler erros for msvc-stlport toolset
by SourceForge.net 25 Jan '05

25 Jan '05

Support Requests item #1106566, was opened at 2005-01-21 09:34 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1106566&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: meroth (meroth) Assigned to: Nobody/Anonymous (nobody) Summary: Boost 1.31.0: Compiler erros for msvc-stlport toolset Initial Comment: I try to build boost libraries v1.32.0 on VC++ 6.0 using toolset msvc-stlport. INTERNAL COMPILER ERROR when trying to build greg_month.obj in boost_date_time.dll. Obviously more errors after that (see attached file for complete output of command line session). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1106566&group_… ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

4 3

[python] type_id
by Jody Hagins 25 Jan '05

25 Jan '05

I see that the implementation of type_id is chock full of special code. There appears to be so much difference between how compilers handle stuff (the shared lib problem documented in the header is especially disturbing). However, this does not seem to be isolated just to using Boost.Python, so is it possible to have it moved somewhere else more common, like boost/type_id.hpp or something similar which makes it more widely available? Thanks!

2 8

Boost.TR1: A first cut.
by John Maddock 24 Jan '05

24 Jan '05

I've just uploaded to the new sandbox-vault a first cut of a Boost.TR1 library, currently it only handles chapter 2 of the TR - so basically only shared_ptr is usable at present, but now that I've got the basic framework sorted I should be able to wiz through the rest of the TR in fairly short order. The zip is at: http://boost-sandbox.sourceforge.net/vault/index.php?&direction=0&order=&di… And the docs are online at: http://freespace.virgin.net/boost.regex/tr1/tr1.html At this stage I'm just trying to get some feedback on: 1) Is this worth doing? 2) Are there any problems with the implementation method used (using declarations to import boost code into std::tr1) that I haven't spotted? Anyone have any "over-my-dead-body" moments? 3) How should this be tested? At present I'm using cutdown concept-checks only (on the basis that the Boost code is tested by each libraries test suite already). 4) Anything else I've missed. Thanks in advance for any feedback you may have, John Maddock.

3 6

Linking against Boost
by Dave 24 Jan '05

24 Jan '05

Hello Boost, Under VC++ 7.1, what is the proper way for me to configure my compiler so that the boost libraries (literally, the .lib files) are available? I had no problem pointing to the headers, but I'm having a heck of a time linking... Specifically, I'm interested in the Filesystem library at the moment, but my question really is general... Thanks, Dave

4 5

Re: Boost Digest, Vol 982, Issue 1
by Dave Handley 24 Jan '05

24 Jan '05

Jason Hise wrote: > > Pavel and I have been discussing a sibling class to the singleton, > namely a multiton. Such a class would manage a unique object instance > for each key provided to GetInst. It should be able to use many of the > same policies that the singleton uses. > > Pavel thinks that it could be useful to allow GetInst to take any number > of parameters. Would this actually be useful, and if so, how could such > a design be achieved? > I think that "multitons" are very useful - but I'm not sure that a Singleton class should necessarily be bloated out to support them. The way I have normally implemented this type of structure is to have a class that is itself a singleton, but is responsible for generating and returning one of a fixed (or variable) number of classes. If you implement the interface through a static function that delegates through the singleton GetInst function, you get a very simple interface which doesn't detract from a nice simple singleton interface - eg: class Multiton : public Singleton<Multiton> { public: class Child; static Child *GetInst( int number ) { return GetInst()->GetChild( number ); } private: Child *GetChild( int number ) { // TODO: check for and return the correct instance of Child } }; Is this pretty much what you were thinking? Dave

2 1

Multiton
by Jason Hise 24 Jan '05

24 Jan '05

Pavel and I have been discussing a sibling class to the singleton, namely a multiton. Such a class would manage a unique object instance for each key provided to GetInst. It should be able to use many of the same policies that the singleton uses. Pavel thinks that it could be useful to allow GetInst to take any number of parameters. Would this actually be useful, and if so, how could such a design be achieved? -Jason

3 3

[multi-index] partial_std_allocator_wrapper constructor
by Daniel James 24 Jan '05

24 Jan '05

Hi, I'm using the multi-index allocator utilities for the unordered associative containers implementation. Because partial_std_allocator_wrapper can't be constructed from the standard allocator, I get an error when I use a standard allocator as a constructor parameter. I believe it also prevents this with the multi-index library. Would it be possible to apply the attached patch to fix this? (Or is there another way?) I added an implicit constructor, although an explicit one would be fine for my use. thanks, Daniel Index: allocator_utilities.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/detail/allocator_utilities.hpp,v retrieving revision 1.5 diff -u -r1.5 allocator_utilities.hpp --- allocator_utilities.hpp 13 Dec 2004 07:17:17 -0000 1.5 +++ allocator_utilities.hpp 22 Jan 2005 18:03:44 -0000 @@ -42,6 +42,11 @@ template<typename Other> partial_std_allocator_wrapper(const partial_std_allocator_wrapper<Other>&){} + partial_std_allocator_wrapper(std::allocator<Type> const& x) + : std::allocator<Type>(x) + { + }; + #if defined(BOOST_DINKUMWARE_STDLIB) /* Dinkumware guys didn't provide a means to call allocate() without * supplying a hint, in disagreement with the standard.

2 1

regression results, darwin: broken link
by Vladimir Prus 24 Jan '05

24 Jan '05

Hi, I see that program_options turned yellow on Darwin, but when I go to: http://www.meta-comm.com/engineering/boost-regression/developer/output/Dirx… and then try to follow the http://www.meta-comm.com/engineering/boost-regression/output/Dirxion-bin-bo… link on that page, I get error that the page is not found. Could anybody fix this? Thanks, Volodya

2 2

[mpl] weird crash on MSVC 6.5
by Joaquín Mª López Muñoz 24 Jan '05

24 Jan '05

The following simple snippet ICEs in MSVC 6.5: #include <boost/mpl/vector_c.hpp> #include <boost/mpl/assert.hpp> template<int N> struct foo:boost::mpl::vector_c<int,N> { }; Yet, this version (where assert.hpp is included first) compiles fine: #include <boost/mpl/assert.hpp> #include <boost/mpl/vector_c.hpp> template<int N> struct foo:boost::mpl::vector_c<int,N> { }; The situation is the same if I change vector_c for list_c. With plain vectors and lists, however, everytihng's fine. ????? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 3

boost::result_of
by John Maddock 24 Jan '05

24 Jan '05

I can't seem to get the result_of template to function, I've tried: #include <boost/utility/result_of.hpp> typedef boost::result_of<F>::type t; with F= int (double) int (*)(double) int (&)(double) std::unary_function<double,int> and all give a long list of errors. I believe that all of these should be OK? So am I doing something obvious wrong (I'm using VC7.1 BTW in case that makes a difference)? Thanks, John.

3 4