- Boost - lists.boost.org

Re: bjam header dependency check broken (and so are the regression test reports)
by David Abrahams 16 Jan '05

16 Jan '05

Rene Rivera wrote: > David Abrahams wrote: > I managed to reproduce the problem... And fixed it by reverting the code > for dealing with file vs. dir header names in BBv1. Hooray! Three cheers for Rene! -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

1 0

bjam header dependency check broken (and so are the regression test reports)
by John Maddock 15 Jan '05

15 Jan '05

I'm currently having a lot of problems with the regex regression test reports (http://www.meta-comm.com/engineering/boost-regression/developer/regex.html) that appear to be caused by bjam not noticing when a dependent header has changed (The problems do not appear if the tester does a clean rebuild each time). For example if I cd into libs/regex/example, and bjam credit_card_example to bring that target up to date, and then: touch ../../../boost/regex/v4/cpp*.hpp bjam credit_card_example then nothing gets rebuild (everything should be rebuilt!). However as soon as I touch a source file: touch ../src/cpp*.cpp bjam credit_card_example Then the touched source files do at least get rebuilt. It would really really help if this could get fixed: at present some of our regression test reports are basically worthless - they may be either failing or *passing* incorrectly for no reason except that bjam has just decided not to rebuild them! Many thanks, John.

1 0

Boost install, and test - a modest proposal
by Robert Ramey 15 Jan '05

15 Jan '05

Currently we have a couple of problems. Testing a) Testing is taking longer and longer. b) we do not test all variant combinations. We don't test release and we don't test different variants for runtime-link and other combinations that users mght use. c) Testers are making larger commitments. Many users download and install on variations of platforms we test on examples since last release of 1.32 a) versions of stlport other than 4.5.3 b) Mac OSX in release mode c) Metrowerks for MAC ? Basically, our process doesn't scale well. Each one of raises a couple of new issues. I would like to see the "Getting Started" section of the documentation somewhat re-organized in the following way: a) test the test subsystem - this results in a build of the test subsystem b) test each library - this results in a build by default c) generate compiler_status and link html file for the target environment c) stage- move libraries to final directory. That is, installing BOOST would by default include testing it. Any problems would be addressed by uploading test results to a known destination. I envision that the "test results" would be the compiler_status and links.html files. (Note I recently uploaded a version of compiler_status to the vault which builds tables of ALL the combinations tested) Hopefully all of the above could be accomplished from withing bjam rather then platform dependent shell or msdos scripts. This would have the following effects. a)Testing would automatically be performed on platforms that users actually use. b)Testing could be more exhaustive as its spread among a larger number of machines c)More combinations of variants could be tested. d)It would permit users with difficulties to be offered better help. Robert Ramey

1 0

[thread] thread member pointer & alert 2'nd attempt
by Roland Schwarz 14 Jan '05

14 Jan '05

A week ago I have tried to poll for interest of an extension to the threading library. 1) A thread member pointer 2) An alert mechanism Surprisingly (given the past discussions about related concepts) there have been almost no responses. So I am wondering whether this is because the possibly interested ones are still on vacation or the presented concept is deemed unusable. Also it might be the case that I have used the wrong buzzwords. Either way I would be glad to get your feedback on this. The files are in the vault: http://boost-sandbox.sourceforge.net/vault/index.php?action=downloadfile&di… Thank you for your attention. Roland

2 1

Re: Singleton
by Dave Handley 14 Jan '05

14 Jan '05

Jason Hise wrote: > > I'm actually working on the longevity policy now. I'm trying to do it > without using atexit, and instead using a hidden internal singleton that > manages the lifetimes of the others. It should be interesting. > Good idea - I look forward to seeing the results. > > 3) Possibly include the ability to turn off phoenix singletons in > > the dependency lifetime policy. > >From what I remember, Loki throws an exception. > This leads to an interesting question: what should happen if a class > tries to get access to a destroyed singleton? I would personally think > that it would always be desirable to have it come back, but then this is > just my opinion and probably falls into the same category as me > preferring dependencies to longevities. Which leads me to wonder if > OnDeadReference should be an additional policy of the lifetime policy > itself. Let me give you an example where you may want a dead reference exception rather than a phoenix singleton. Let's say you have a singleton that performs a client access to a database. When the client is started up, it asks for a username and password, and logs the client access in the database. You definitely would not want this to go through a phoenix singleton because of the side-affects. Making OnDeadReference a policy of the lifetime policy probably makes a lot of sense, since you have essentially implemented the phoenix singleton as an extra to the lifetime policy in the dependency model. > > > 4) Threading. > > I'm going to need help with this one. My current thought is to provide > a lock policy. The lock would be required to provide locking upon > creation and unlocking upon destruction, and then all the other policies > of the singleton would inherit this policy and could simply insert lock > objects wherever they are needed. The default single threaded lock > would just be an empty class. Unfortunately I have no experience with > how threading actually works, and I am worried that the two threads > would just end up creating two different locks and neither would block > the other. If I am not on the right track, please point me in the right > direction. > The problem with threading is that it is up to the OS to define the threading system. This means that threading is usually non-portable. I would recommend therefore looking at boost.threads which provides a portable threading system. Loki uses a very simple system of policies. The 3 policies implemented are a SingleThreadPolicy, ObjectLevelLocking and ClassLevelLocking. The object level locking basically locks a mutex that is defined on an object level, whereas the class level locks a mutex for all objects of that class. The implementation is via CRTP again. There are some added bits in Loki like the volatile type is typedefed so you can get the volatile qualifier right (you shouldn't use volatile in single-threaded because it can disable compiler optimisations). It does this using template <class Host> class ObjectLevelLocking { typedef volatile Host VolatileType; }; whereas the SingleThreaded version just does: typedef Host VolatileType; The locking itself works with an inner class called Lock that you construct on the stack whenever you need to lock. On construction it locks the mutex and on destruction it frees it. I've not personally used the boost threads library so I can't help you on that one. Dave Handley

10 17

Re: Singleton
by Dave Handley 14 Jan '05

14 Jan '05

Jason Hise wrote: > I have a question about the longevity lifetime. Does such a lifetime > only manage destruction order, or should it also manage order of > creation? The way I'm currently implementing my longevity lifetime > policy, there would be a master function in the > LongevityManagerSingleton which would set the 'creation level'. This > would basically create singletons up to this level or destroy them down > to this level, so that all singletons at a given level could be assured > that singletons with a smaller longevity number existed for their entire > lifetime. Example: > > A has longevity 0, B = 1, C = 2, D = 3, E = 4 > > Upon setting the creation level to 3, A would be created, then B, then > C, then D. Subsequently setting the creation level to 1 would destroy > D, then destroy C. > > Is this anything like what the users of a longevity lifetime would like, > or am I completely off track here? > I would have normally expected singleton creation to be handled with a lazy creation policy. This means that they are not created until used, and if not used never created. Then destruction would take place with the standard destruction policy. If you want to force creation at an earlier stage in the program execution then just call GetInstance() and throw away the result. BTW, regarding your concerns on integrating with say boost.thread, why not place all dependencies under a pre-processor guard, that enables threading. Then if you want to enable threading, you would set the pre-processor guard (like the smart pointers implementations), but also include the correct policy in your template specification. This means that under those circumstances where you want both threaded and un-threaded singletons, you can achieve this by turning on the boost directive, and using the policies accordingly. Without the pre-processor directive you simply would not have access to the multi-threaded policies. Dave

2 1

boost::polynomial
by Loïc Joly 14 Jan '05

14 Jan '05

Hello all boosters, I was wondering if a polynomial class has ever been proposed for boost ? Greetings, -- Loïc

2 1

saturated casts..
by Kristian Dupont 14 Jan '05

14 Jan '05

Forgive me if this topic has been discussed before - searching for "casts" and the like in the archives bring out quite a lot of results :) Although numeric_cast allows you to safely cast between numeric types, I find that it can sometimes come in handy to just receive the saturated value in the case of an overflow. A simplified solution would look something like this: template<class Source, class Target> inline Target saturated_cast(Source val) { BOOST_STATIC_ASSERT(std::numeric_limits<Target>::is_specialized); if(val < (std::numeric_limits<Target>::min)()) return (std::numeric_limits<Target>::min)(); if(val > (std::numeric_limits<Target>::max)()) return (std::numeric_limits<Target>::max)(); return static_cast<Target>(val); } I think that this would fit nicely into cast.hpp. Any comments? Kristian Dupont

3 4

Re: Re: [boost] Help me! Where is thefile"libboost_regex-vc6-mt-sgd-1_32.lib"?
by 袁晓辉 14 Jan '05

14 Jan '05

I asked: >>I am using Windows XP + VC6. My compiler complained about "LINK : fatal >>error LNK1104: cannot open file "libboost_regex-vc6-mt-sgd-1_32.lib" when >>using "Debug Multithreaded" run-time library! I alos got a similar error >>with "Multithreaded" run-time library, but OK with other types of run-time >>librares. John Maddock wort: >That is one of several regex lib variants that get build when you build >Boost, so it should be in your boost-install-path/lib directory. > >John. > I built boost libs like this: jam.exe -sBOOST_ROOT=. -sTOOLS=msvc "-sBUILD=debug release <runtime-link>static/dynamic Here are what I go: (I only tree "regex" directory for simplicity) tree G:\boost_1_32_0\bin\boost\libs\regex\ ...... ├─build │ ├─boost_regex.dll │ │ └─msvc │ │ ├─debug │ │ │ └─threading-multi(boost_regex-vc6-mt-gd-1_32.dll & boost_regex-vc6-mt-gd-1_32.lib) │ │ └─release │ │ └─threading-multi(boost_regex-vc6-mt-1_32.dll & boost_regex-vc6-mt-1_32.lib) │ └─libboost_regex.lib │ └─msvc │ ├─debug │ │ ├─runtime-link-static(libboost_regex-vc6-sgd-1_32.lib) │ │ └─threading-multi(libboost_regex-vc6-mt-gd-1_32.lib) │ └─release │ ├─runtime-link-static(libboost_regex-vc6-s-1_32.lib) │ └─threading-multi(libboost_regex-vc6-mt-1_32.lib) └─Release No "libboost_regex-vc6-mt-sgd-1_32.lib"! How can I build out this file?

2 1

program_options lib patch
by François Dumont 14 Jan '05

14 Jan '05

According some boost library sources I have checked it looks like there is an implicit coding standard rule which is to always use C functions from their C++ std namespace import equivalent. Thanks to this, compilers like MSVC6 but also Commeau according what I have read in comments, do not give compilation errors because of ambiguity. The program_options library do not apply this rule, here are the patch to fix it. It, of course, use the BOOST_NO_STDC_NAMESPACE to force std import when missing. In cmdline.cpp, this modification made the Commeau workaround irrelevant, it has been removed. Bests

3 5