- Boost - lists.boost.org

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

14 Jan '05

isomorphism.cpp: Fix the use of the BOOST_NO_STDC_NAMESPACE subgraph.cpp: Change vector iterator i into it to avoid conflict with the i unsigned value defined later.

2 1

Boost Sandbox Files Registration...
by Rene Rivera 14 Jan '05

14 Jan '05

Just saw this from SF... ( 2005-01-13 10:12:24 - Project Web Service ) As of 2005-01-13 we have disabled the ability for project web content to send out e-mail. This action was taken to resolve a problem caused by spam generated from the project web services. We hope to restore this as soon as possible. So if you have problems registering for the Boost Sandbox Vault. Email me directly after doing the registration, and I'll activate the user manually. Hopefully SF can resolve the issue soon.. Or I can figure out a way around the problem. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

1 0

Singleton
by Jason Hise 14 Jan '05

14 Jan '05

Yay, I finally got the singleton working with allocation and lifetime policies, in addition to being in CRTP form. I know that threading policies still remain, however I would like an opinion on what I have so far. A major difference from Loki is that my lifetime policy needs to know about the allocation policy in order for dependencies to be possible to implement. The code is available here: http://www.ezequal.com/chaos/libs/policy_singleton.h After I am assured that the structure of the code is pretty much correct, i will begin adding additional policies, such as the longevity lifetime that Loki supports. If there are policies that Loki doesn't provide that might be widely useful, please mention them so that they can be incorporated. I look forward to any and all feedback. -Jason

8 20

Lets restart the decimal type discussion
by Martin 14 Jan '05

14 Jan '05

I think the discussion on the decimal went in the wrong direction and is it probably my own fault. Lets start it over in more general terms. My view on decimal types are that they can be based on 4 different base types 1. binary floating-point, explicit rounding 2. decimal floating-point, explicit rounding 3. decimal fixed-precision, global rounding 4. decimal fixed-precision, object rounding * Explicit rounding means that all operations store the full precision supported by the type. Rounding to a number of decimals is performed when needed by a (maybe implicit) call to a function like round(x, rounding_mode). Ofcourse there is a rounding mode used to fit the result of an operation into the type which might cause rounding errors (e.g. 0.499999 might first be rounded to 0.5000 to fit the type which is then explicitly rounded to 1). I think the cases where the double rounding is a problem are so rare that it is enough to point out the problem in the documentation. * global rounding means the same rounding is used for all objects. * object rounding means that the rounding is specified for each object. The decimal type I proposed was in category 4. The proposed TR decimal type is category 2 and it might also support type 3. Float, double is category 1. --- The discussion on decimal types, including the review of a decimal library two years ago, indicates that to be accepted in boost a solution should allow some (or all 4) types to be used as base in something like "basic_decimal<>". So lets discuss how a basic_decimal interface should look like. The main problem I see lies in the construction: Type 1 & 2: basic_decimal(value) Type 3: basic_decimal(value, precision) Type 4: basic_decimal(value, precision, rounding_mode) Rounding is not a big problem since a sensible default can be used but how to solve the precision? Creating a decimal type 3 or 4 without specifying a precision is bad since there is no good value to use as default. Precision also has a different meaning for a decimal type 1 & 2 (i.e. only affects extractions, not operations). I see three possible solutions: 1. basic_decimal include all variants of constructors and then generates compiler error if that type of constructor isn't suitable for the underlying type 2. basic_decimal only got the "full" constructor (value, precision, rounding_mode) but supplies default for precision (=0?) and rounding mode 3. basic_decimal only includes the minimal constructor (value) and then other members are needed to specify precision and rounding_mode for type 3 & 4 decimals. The other members of basic_decimal isn't very complicated: A full set of arithmetic operations (+,-,*,/,%) and assignment must be included. Operations should work on integers and maybe also string literals. For decimal type 1 & 2 it makes sense to also allow operations on doubles. Assignment should work on integers, string literals and double for all types. There needs to be a way to extract the decimal as a binary floating point value and probably also a decimal floating point value (when available). Functions like round, abs etc are also needed but they can be free functions (maybe friends for performace reasons). Note that the above only deals with the decimal type. Money and currency might need a slightly different interface. My view is that the types should built up like: typedef basic_decimal<value_type> decimal_type; typedef basic_money<decimal_type> money_type; typedef basic_currency<money_type> currency_type; Any comments?

3 3

Singleton
by Jason Hise 13 Jan '05

13 Jan '05

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? -Jason

1 0

RFC: mixing std::map and boost::optional
by Ulrich Eckhardt 13 Jan '05

13 Jan '05

I had the idea to use boost::optional on the interface of a std::map-like object. I have neither coded a prototype nor is this a fully grown design yet, I'd just like to discuss this idea. The rough outline is this: class my_map { public: optional<value>& operator[](key const&); optional<value> const& operator[](key const&) const; // iterators, ctors, dtor, etc the same private: optional<value> const m_empty_value; tree< pair<key, optional<value> > > m_content; }; The important differences to std::map are: 1. operator[] is available as const and non-const memberfunction. The const memberfunction returns 'm_empty_value' in case the key is not found. The non-const one inserts a new node into the tree and returns a reference to that. 2. operator[] return an optional<value>, not a direct value. This means that you have to check the return-value of this call. OTOH, you _can_ check the return value to see if a key was associated with a value. Some example code, compared with the equivalents using std::map: // two maps std::map<string,float> stdmap; my_map<string,float> mymap; // const references, for cases where it makes a difference std::map<string,float> const& stdmapc = stdmap; my_map<string,float> const& mymapc = mymap; ///////// inserting an element: stdmap["key"] = 41.0f; mymap["key"].reset(42.0f); ///////// accessing an element access(stdmap["key"]); std::map<string,float>::const_iterator it = stdmapc.find("key"); if(it!=stdmapc.end()) access(it->second); else access(float()); boost::optional<float>& value = mymap["key"]; if(value) access(*value); else access(float()); boost::optional<float> const& value = mymap["key"]; if(value) access(*value); else access(float()); ///////// removing an element stdmap.erase("key"); mymap["key"].reset(); ///////// finding out if an element exists if(stdmap.find("key") != stdmap.end()) found(); if(mymap["key"]) found(); ///////// iterating and accessing for(std::map<string,float>::const_iterator it=stdmap.begin(); it!=stdmap.end(); ++it) access(it->second); for(my_map<string,float>::const_iterator it=mymap.begin(); it!=mymap.end(); ++it) if(it->second) access(*(it->second));

2 1

Sealed/Final implementation.
by kalin 13 Jan '05

13 Jan '05

Hi All, I've made a simple implementation of making a class non-derivable. Aside from the pros/cons of actually using this, which I'm sure could be debated for months, I thought I'd present the implementation anyway to see if there is interest in it. I thought something like this might already be in Boost, but I couldn't locate it, or any threads about the subject. Usage is as: class Foo : Sealed<Foo> {}; class Bar : Foo {}; // Error. And it should all work as intended (unless I've missed something) and not allow you to instantiate Bar. --- Implementation --- namespace Detail { template <class T, class Parent> class Sealed { friend T; friend Parent; }; } template <class T> class Sealed : public virtual Detail::Sealed<T, Sealed> { friend T; }; --- kalin

5 8

boost.test covered in testing frameworks rundown
by Max Khesin 13 Jan '05

13 Jan '05

http://www.gamesfromwithin.com/articles/0412/000061.html Well, some good marks but no victory. Perhaps the people involved in the library will find this useful. cheers, max This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

3 10

Linking w/ Boost 1.3.2 and STLport 4.6.2
by Aleksandar Fabijanic 13 Jan '05

13 Jan '05

Hello, I'm having problems comiling linking with Bosst and STLport. Development environment is Visual Studio .NET 2003. I am building Boost like this: C:\Projects\boost\boost_1_32_0>bjam -sTOOLS="vc-7_1-stlport" -sBUILD="<stlport-iostream>on" -sBUILD="<native-wchar_t>on" stage C:\Projects\boost\boost_1_32_0>bjam -sTOOLS="vc-7_1-stlport" -sBUILD="<stlport-iostream>on" -sBUILD="<native-wchar_t>on" install This builds and creates C:\Boost\... inlcude and lib dirs. When I try to include <boost/thread/thread.hpp> from my app, I am encountering following problems: Debug: warning: STLPort debug versions are built with /D_STLP_DEBUG=1 c:\Boost\include\boost-1_32\boost\config\auto_link.hpp(206) : fatal error C1189: #error : "Build options aren't compatible with pre-built libraries" Release: Linking... LINK : warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/OPT:ICF' specification LINK : fatal error LNK1104: cannot open file 'libboost_thread-vc71-mt-sp-1_32.lib' I have libboost_thread-vc71-mt-sgdp.lib What bjam options do I use to build Boost so it compiles in Debug and produces the library name linker is looking for in Release? Any help will be appreciated. Thanks in advance. Alex __________________________________ Do you Yahoo!? The all-new My Yahoo! - What will yours do? http://my.yahoo.com

1 0

[test] CHECK_EQUAL and problem with class constants
by Jody Hagins 13 Jan '05

13 Jan '05

Consider this simple example... #include <boost/test/test_tools.hpp> struct Foo { static unsigned int const x = 10; }; int test_main( int, char* [] ) // note the name! { BOOST_CHECK_EQUAL(10U, Foo::x); return 0; } At least under gcc, I get a linker error, unable to find Foo::x, while the following code works fine... int test_main( int, char* [] ) // note the name! { BOOST_CHECK(10U == Foo::x); return 0; }

3 2