- Boost - lists.boost.org

[Boost-bugs] [ boost-Bugs-951106 ] bjam install does not copy .inc files
by SourceForge.net 10 May '04

10 May '04

Bugs item #951106, was opened at 2004-05-10 08:05 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=951106&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Pere Mato (pmato) Assigned to: Nobody/Anonymous (nobody) Summary: bjam install does not copy .inc files Initial Comment: On trying to compile we got the follwing error: afs/cern.ch/cms/external/lcg/external/Boost/1.31.0/rh73_ gcc32/include/boost- 1_31/boost/pool/object_pool.hpp:83:51: boost/pool/detail/pool_construct.inc: No such file or directory The problem has been traced to the fact that the .inc files in boost/pool/detail were not copied to the installation area by "bjam install". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=951106&group_i… ------------------------------------------------------- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Regression testing -- some new testing options?
by Jeff Garland 09 May '04

09 May '04

Robert Ramey & I have been having a discussion offline about the impact of new boost libraries on the time it takes to run the regression tests. Serialization has a particularly time consuming test -- the so called 'torture test' suite. The problem is, that once serialization is in the tree it will be important to run that full test from time to time (like right before release), but it would probably be overkill to run everyday. And from past dicussion it is clear that running the regression test is already becoming very time consuming. Of course this isn't a serialization specific issue. With more and more libraries added the time to do any sort of regression test is continuing to grow. In addition, there is now the 'dll' versus 'static' library dimension for those of us with compiled libraries. It might be nice to sometimes run one or the other to speed things up. Also, Robert would like to be able to run 'debug' versus 'release' tests from time to time. So here's a suggestion. Perhaps it be possible to create a standard way we could set up the regression test targets so that library authors could: 1) define a couple standard test levels - say 'basic' and 'torture' 2) DLL versus static tests would be an option on the regression suite -- so you could run only one or both. Of course this isn't an issue for header libraries. 3) debug versus release is an option 4) define specific compiler/platform exclusions I believe such a design could increase the regression test effectiveness by allowing some contributors and users to run only one set of options (eg: 'basic-dll-release') tests. This option would be much-much faster than 'torture-all-all' -- which for a compiled library needs to compile and excute 4 versions of the tests (dll-release, dll-debug, static-release, static-debug). The compiler/platform exclusions would save time by just skipping over stuff that is going to fail and will never be fixed. There may be some way of doing this now, but ideally we would have some way of specifying this in the bjam file for the tests. Thoughts? Jeff

1 0

Re: Request for small test in VC7.1
by Arkadiy Vertleyb 09 May '04

09 May '04

Hi Joaquin, Your example compiles with no problem in VC7.1 (.NET 2003) in both debug and release mode. Regards, Arkadiy

1 0

Re: [boost] Request for small test in VC7.1
by JOAQUIN LOPEZ MU?Z 09 May '04

09 May '04

----- Mensaje original ----- De: brok(a)spamcop.net Fecha: Domingo, Mayo 9, 2004 10:52 pm Asunto: Re: [boost] Request for small test in VC7.1 > Quoting JOAQUIN LOPEZ MU?Z <joaquin(a)tid.es>: > [snippet deleted] > Compiled successfully (tried with and without /Za, ie "disable > languageextensions"). > > > B. > Hi Bronek, thanks for trying the test. Obviously, I failed to capture the problem in the snippet, the actual error that's troubling me can be consulted at: http://tinyurl.com/ysmxq The diagnostic seems to be related with the fact that composite_key_result_less privately inherits from composite_key_compare while allowing public access to the base's operator() with a using declaration. Any idea about this? I'll be more than happy to provide further info to anyone who has a clue about the problem, or whishes to try the test in VC 7.1. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Re: Re: [boost] Re: [serialization] pointers to built-in types
by Robert Ramey 09 May '04

09 May '04

Dave Harris wrote: > I'd rather tell the library exactly which ints can be serialised via > pointers and which not, and the current solution seems a reasonable way of > doing that. At least, I can't think of a better one. To me the cental issue is one of side-effects. I have a header file which implements serialization for pointers to longs - and it works great. Now I forget about the implementation of that header - after all, it works great - and include it in some other header files for some other project. Now I have a big mess. Whereever it's been included, pointers to ALL longs are tracked. Whereever its non included, pointer to longs are flagged at compiler time. Now the behavior of unrelated code is significantly altered just be the inclusion/exclusion of a seemingly unrelated component. The alteration effects even the compilation as well as the execution. Its worse than a global variable in a global namespace. That's why pointers to primitive types have been made non-serializable by default. And there is a very simple solution - use a wrapper to make the long its own type. Probably the only thing missing is to specify serialization for strong_typedef. Robert Ramey

2 1

Possible bug in mpl::push_front for vectorN
by Hamish Mackenzie 09 May '04

09 May '04

#define BOOST_MPL_LIMIT_VECTOR_SIZE 20 #include "boost/mpl/vector.hpp" #include "boost/mpl/push_front.hpp" class X { }; typedef boost::mpl::vector20< X, X, X, X, X, X, X, X, X, X, X, X, X, X, X, X, X, X, X, X > test; typedef boost::mpl::push_front< test, X >::type test2; int main() { return 0; } GCC Version 3.4.0 gives /usr/include/boost/mpl/push_front.hpp: In instantiation of `boost::mpl::push_front<test, X>': push_front.cpp:10: instantiated from here /usr/include/boost/mpl/push_front.hpp:36: error: invalid use of undefined type `struct boost::mpl::push_front_traits<boost::mpl::aux::vector_tag<20l> >::algorithm<test, X>' /usr/include/boost/mpl/aux_/push_front_impl.hpp:31: error: declaration of `struct boost::mpl::push_front_traits<boost::mpl::aux::vector_tag<20l> >::algorithm<test, X>' push_front.cpp:10: error: expected init-declarator before "test2" push_front.cpp:10: error: expected `,' or `;' before "test2"

2 1

Re: [boost] boost/bind.hpp and boost/mpl/less.hpp conflict
by Aleksey Gurtovoy 09 May '04

09 May '04

Lijun Qin writes: > It seems these two files can not be both included, > > just two line file: > > #include <boost/bind.hpp> > #include <boost/mpl/less.hpp> > > will fail to compile on vc 7.1 > > change value to value_t in bind.hpp can resolve the problem. Lijun, It's a known problem that has been fixed in the CVS. The fix will appear in the next release. Thanks for the report, -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

Re: [boost] Re: [serialization] pointers to built-in types
by brangdon＠cix.compulink.co.uk 09 May '04

09 May '04

In-Reply-To: <c7etkk$e3d$1(a)sea.gmane.org> lirong(a)hotpop.com (Li Lirong) wrote (abridged): > > This well mean that all serialized longs have to be tracked. > > I think the lib should only track it when it is serialized through > pointer. And most of the time, primitives are not serialized through > pointers. So there should be any overhead. It's easy to construct cases where that goes wrong. Like: struct S { int x; int *px; S() : x(0), px(&x) {} }; And such cases aren't that unlikely in real code, either. For example, x might be a default, with px being settable to some other location. It's true that such cases are rare... however, that just makes it all the more important that when they happen, they either work correctly or are diagnosed as errors, preferably at compile time. Disallowing serialisation of int pointers altogether may be restrictive, but it gives a safe compile-time check. I suppose it might be OK to have an option where ints are tracked only when serialised through pointers, provided there was also an option which detected any mistakes at run-time. In other words, did the tracking for all ints but without outputting it. The two options would let you trade performance for safety, eg switched with #ifdef _NDEBUG. However, this seems like a lot of development work. In practice I expect serialisation of int pointers is pretty rare. If we have them, then sooner or later we may get cases like S, and then we have to move to some other solution anyway. Handling the special case in the middle doesn't seem worth it to me. Especially if error detection only happens at run-time, and perhaps only in debug builds. I'd rather tell the library exactly which ints can be serialised via pointers and which not, and the current solution seems a reasonable way of doing that. At least, I can't think of a better one. -- Dave Harris, Nottingham, UK

1 0

boost/bind.hpp and boost/mpl/less.hpp conflict
by Lijun Qin 09 May '04

09 May '04

Hi, It seems these two files can not be both included, just two line file: #include <boost/bind.hpp> #include <boost/mpl/less.hpp> will fail to compile on vc 7.1 change value to value_t in bind.hpp can resolve the problem. Regards Lijun Qin

1 0

RE: [boost] Writing fully custom containers for the bgl
by Roman Yakovenko 09 May '04

09 May '04

> -----Original Message----- > From: Pierre DOUCY [mailto:pdoucyml@free.fr] > Sent: Friday, May 07, 2004 1:47 AM > To: Boost General General > Subject: [boost] Writing fully custom containers for the bgl > > > I have written a custom container for the bgl's adjacency_list which > was based on a subclass of a stl container (namely, std:list). > Everything seemed to work just fine (if not by itself) as I followed > the bgl book indications. > > Now, I'm working on a non stl-based container (a wrapper > around the bdb > API), and facing a lot of compile-time problems. I know my > bdb wrapper > is not fully stl-compliant. > > So my question is : if I make this wrapper fully standard-compliant > (for instance by using boost::iterator and by implementing everything > the stl tells me to implement in a AssociativeContainer or a > MultipleAssociativeContainer), will the bgl play nicely with > it (i.e. > as if it was a std::map, for instance) ? I think even if you do this you will not get standard-compliant AssociativeContainer The reason is simple: bdb cursor does not have all functionality of std iterator. > > If not, what should I do to be able to use my containers with > the bgl. > I haven't found any examples out there, and wondered if anyone tried > (and succeded) in this task. > > My second question is : how and when does the adjacency_list > instantiates its containers, and is there any way to mess with it, by > passing special arguments to the containers when instatiating > my graph > ? Reading the code and following the process in a debugger doesn't > really make my ideas clearer. > > Thanks in advance for any help and/or ideas > > Pierre > > -- > Written slowly for people who can't read fast. > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

1 0