- Boost - lists.boost.org

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

[date_time] serialization of ptime with bcc32-5.6.4
by Russell Hind 13 Jan '05

13 Jan '05

I'm trying to serialize a ptime to an xml archive. I've included boost/date_time/posix_time/time_serialize.hpp but get an ambiguity error: [C++ Error] serialization.hpp(121): E2015 Ambiguity between 'boost::serialization::void serialize<boost::archive::xml_iarchive>(boost::archive::xml_iarchive &,boost::posix_time::ptime &,const unsigned int)' and 'boost::serialization::void serialize<boost::archive::xml_iarchive,boost::posix_time::ptime>(boost::archive::xml_iarchive &,boost::posix_time::ptime &,const unsigned int)' Is this a problem with the compiler or should this work? Thanks Russell

2 3

[test] Detecting timeout support
by Jody Hagins 13 Jan '05

13 Jan '05

The example, unit_test_example2.cpp, demonstrates the detection of a timeout... void infinite_loop() { // unit test framework can break infinite loops by timeout #ifdef __unix // don't have timeout on other platforms BOOST_CHECKPOINT("About to enter an infinite loop!"); while(1); #else BOOST_MESSAGE( "Timeout support is not implemented on your platform" ); #endif } In my tests, I'd rather not have #ifdef __unix all over the place. Is is possible to add a macro in the Test framework itself that can be checked (on the off chance that timeout support is expanded)?

2 8

building boost 1.32 library under vc7.1 with _fastcall
by Alex Baskakov 13 Jan '05

13 Jan '05

How are you, boost? I'm using /Gr option in my project under vc7.1 (the __fastcall calling convention for all functions except C++ member functions and functions marked __cdecl or __stdcall) And I'm trying to build boost with /Gr option but there are some troubles, for example, with Boost.Test library (it define 'main' function without __cdecl) So, what is the right way to do that? Is it possible to use boost in another calling vc7.1 conventions? Bye.

2 1