November 2010 - Boost - lists.preview.boost.org

[Opaque] Request for interest in Opaque typedefs library emulation
by vicente.botet 27 Jul '11

27 Jul '11

Hi, I have started to play with a class to define opaque typedefs on funcdamental types. It is based on the C++ proposal " Progress toward Opaque Typedefs for C++0X" by Walter E. Brown http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1891.pdf and http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1706.pdf Please take a look on the preceding links to understand the motivation. Boost.Sericalization provide a BOOST_STRONG_TYPEDEF already, but in my opinon the implementation is not complete,as only the order operators are defined (But maybe I'm wrong). Evidently it can not provide everything we can have with a language approach, but IMO this could yet be useful. The library include two class templates (CRTP) to define opaque types: * public_opaque_type<OT,UT> : implicit conversion from OT to UT * private_opaque_type<OT,UT> : no conversion from OT to UT An opaque type (OT) is a new type, different from the underlying type (UT) and other OT. It defines explicit constructor from the UT, and defines all the operators the UT support but this time applied to the OT. To define a new OT with this mixin classes struct serial_number: public_opaque_type<serial_number, unsigned> { BOOST_OPAQUE_PUPLIC_FORWARD_CONSTRUCTORS(serial_number,unsigned); }; struct game_score: private_opaque_type<game_score, unsigned> { BOOST_OPAQUE_PRIVATE_FORWARD_CONSTRUCTORS(game_score,unsigned); }; In addition, defines macros that make this simpler BOOST_OPAQUE_PUBLIC_TYPEDEF(unsigned, serial_number); BOOST_OPAQUE_PRIVATE_TYPEDEF(unsigned, game_score); Next follows the definition of the public_opaque_type template <typename Final, typename T> class public_opaque_type : boost::totally_ordered< Final , boost::integer_arithmetic< Final , boost::bitwise< Final , boost::unit_steppable< Final , boost::totally_ordered< T, Final // public specific conversions , boost::integer_arithmetic< T, Final // public specific conversions , boost::bitwise< T, Final // public specific conversions > > > > > > > { protected: T val_; typedef public_opaque_type opaque_type; public: typedef T underlying_type; explicit public_opaque_type(const T v) : val_(v) {}; public_opaque_type() {}; public_opaque_type(const opaque_type & rhs) : val_(rhs.val_) {} public_opaque_type & operator=(const opaque_type & rhs) { val_ = rhs.val_; return *this; } public_opaque_type & operator=(const T rhs) { val_ = rhs; return *this; } T const& underlying() const { return val_; } T& underlying() { return val_; } operator const T & () const { return val_; } operator T & () { return val_; } #if 0 bool operator==(const opaque_type & rhs) const { return val_ == rhs.val_; } #endif bool operator<(const Final & rhs) const { return val_ < rhs.val_; } Final& operator+=(const Final & rhs) { val_ += rhs.val_; return static_cast<Final&>(*this); } Final& operator-=(const Final & rhs) { val_ -= rhs.val_; return static_cast<Final&>(*this); } ... }; I have started to make some tests and it works well for the moment. Limitations: * As we can not specialize the behaviour of static_cast/dynamic_cast the library sould provide two specific casts opaque_static_cast and opaque_dynamic_static_cast (Not yet implemented). * As operator.() can not be overloaded, it works transparently only for underlying types that don't defines member functions (C++ fundamental types, as int, char, ...). For the others an explicit use of the underlying() member function is needed :( * Others I have not catched yet :( Do you think it is worth continuing? Please, let me know if you see a error on the design. _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

4 8

[filesystem] home_directory_path
by Jeff Flinn 24 Jul '11

24 Jul '11

In looking at implementing a portable home_directory_path function a few questions arise. Based on http://en.wikipedia.org/wiki/Home_directory, POSIX and other UNIX flavors 'appear' to be a straight forward use of the "HOME" environment variable. Does anyone have any experience where the "HOME" variable is not the proper source of the user's home directory? Windows NT and above have the "USERPROFILE" environment variable. Using this would be the easiest to use. But I've seen discussion that this may not always be properly defined, in particular if the user has reset their home directory to a non-system drive. I haven't tracked down it's availability on WinCE. Does anyone have experience with this platform? There is the windows GetUserProfileDirectory api function also available since NT4. This is in the Userenv.lib/dll, obviously adding a link dependancy. How are these sorts of system link dependencies handled? Through bjam? Or is it acceptable/better to use #pragma comment(lib,"Userenv.lib")? In looking at some client code using home_directory_path, I see that they generally are looking for the user's Desktop directory(Mac & Windows). Obviously this only makes sense on GUI platforms. The issue with merely getting this path via home_directory_path() / "Desktop" is IIRC, that at least on windows "Desktop" is localized and may not exist with that name on non-english localized systems. Windows has the SHGetFolderPath api. I need to look into Mac's native support. Any thoughts on the general usefulness of a portable desktop_directory_path? Thanks, Jeff

16 60

[mpl] string to type conversion
by Bartosz Marcinkiewicz 19 Jun '11

19 Jun '11

Hello, I would like to have a macro which could be used like this: STRING_TO_TYPE( MyType ) which would yield: typedef mpl::string<'M','y','T','y','p','e'> MyType_id_t; Any ideas how to implement something like that? Thanks for any help, bma. -- Bartosz Marcinkiewicz tel. (+48) 516 034 243 e-mail: bma(a)epcon.pl, bartosz.marcinkiewicz(a)epcon.pl EPCON Sp. z o.o. www.epcon.pl adres: 53-407 Wrocław, ul. Gajowicka 114/116 tel. (+48) 71 361 75 55 ext.36 fax (+48) 71 361 74 44 NIP PL 899-24-92-498 KRS 0000190187 REGON 932963731 Kapitał zakładowy: 500 000 PLN

4 4

Re: [boost] [date_time] Time zone improvements
by Rutger ter Borg 25 May '11

25 May '11

Jeff Garland wrote: > Very cool :-) One question -- is there a portable solution where a user > could deploy a files onto a Windows system or is it a Unix only solution? > I'm fine with incorporating a *nix only solution because what your > suggesting will be a nice solution for *nix platforms, but it will need to > be clear that it's not portable. I don't see why it wouldn't be possible to deploy the (big-endian) binary files to any platform. Getting it into this binary form (using zone info compiler zic) may be harder to do cross-platform, but cygwin may help here. [snip] > As the primary maintainer of Boost date-time I can say with certainty that > there is interest in this functionality -- it's long been on my todo list > and I haven't had time to get to it. You can email me privately and we > can discuss all the details of how to get your code incorporated. I'll do! Regards, Rutger

5 9

accurate sum accumulator (kahan)
by Gaetano Mendola 27 Apr '11

27 Apr '11

Hi all, I had to implement in terms of boost accumulators the Kahan summation algorithm. I will paste at the end of this message the accumulator, the feature and the extractor source code. This accumulator reduces the numerical error obtained with standard sequential sum, as example the sum of 1e6f elements equal to 1e-6f should give 1.0f, this is the results obtained with sum and sum_kahan: tag::sum: 1.009038925 tag::sum_kahan: 1.000000000 I'm not sure if that sum_kahan is worth to be inserted in the accumulators provided with boost, I'm not an expert of boost:accumulators (I just followed the guide to make this new accumulator) so not sure if you prefer to have a fast_sum and an accurate_sum instead of sum and sum_kahan. Regards Gaetano Mendola // File kahan_sum.hpp #ifndef KAHAN_SUM #define KAHAN_SUM #include <boost/accumulators/framework/accumulator_base.hpp> #include <boost/accumulators/framework/parameters/sample.hpp> #include <boost/numeric/conversion/cast.hpp> namespace boost { namespace accumulators { namespace impl { template<typename Sample> struct sum_kahan_accumulator : accumulator_base { typedef Sample result_type; template<typename Args> sum_kahan_accumulator(Args const & args) : sum(args[sample | Sample()]), compensation(boost::numeric_cast<Sample>(0.0)) { } template<typename Args> void operator ()(Args const & args) { const Sample myTemp1 = args[sample] - this->compensation; const Sample myTemp2 = this->sum + myTemp1; this->compensation = (myTemp2 - this->sum) - myTemp1; this->sum = myTemp2; } result_type result(dont_care) const { return this->sum; } private: Sample sum; Sample compensation; }; }}} namespace boost { namespace accumulators { namespace tag { struct sum_kahan : depends_on< > { typedef impl::sum_kahan_accumulator< mpl::_1 > impl; }; }}} namespace boost { namespace accumulators { namespace extract { extractor< tag::sum_kahan > const sum_kahan = {}; } using extract::sum_kahan; }} #endif

21 68

D-style scope guards?
by Martin Christiansson 07 Mar '11

07 Mar '11

Hi, I have used the good old scopeguard in the past and recently done some experiments with the Boost.ScopeExit library. Still I feel that the clean scope statements in D is missing. It will not be possible to do an equally clean solution without having the same features in the language itself, but I could reach as far as this example that reuses the ScopeExit library: void foo() { GUARDED_SCOPE_BEGIN GUARDED_SCOPE_EXIT() { cout << "Returning from foo()" << endl; } GUARDED_SCOPE_EXIT_END GUARDED_SCOPE_SUCCESS() { cout << "foo(): No Errors occurred!" << endl; } GUARDED_SCOPE_SUCCESS_END GUARDED_SCOPE_FAILURE() { cout << "foo(): Exception caught!" << endl; } GUARDED_SCOPE_FAILURE_END GUARDED_SCOPE_END } The GUARDED_SCOPE_BEGIN macro declares one boolean guard to handle return from several levels of nested scopes and one boolean to guard the current scope from exceptions (will be shadowed in nested scopes). GUARDED_SCOPE_END will set the exception_thrown guard to false before that variable is used by the GUARDED_SCOPE_*() destructors. The latter is actually reused ScopeExit code with an added wrapper with a single if-statement. GUARDED_SCOPE_EXIT() will allways run on scope exit. GUARDED_SCOPE_SUCCESS() will only run if the function is exited with wrapper for return keyword (GUARDED_SCOPE_RETURN). The wrapper must be used since it updates the hidden guard variables. Using plain "return" will behave as if exception was thrown. GUARDED_SCOPE_FAILURE() will run when exception is thrown. There is also a separate GUARDED_SCOPE_NESTED_BEGIN that is supposed to be used for all nested scopes. A reference is kept to the return_called variable in the top-level-scope (variable declared by GUARDED_SCOPE_BEGIN). The biggest issue here is that any extra closing curly bracket inserted between GUARDED_SCOPE_*-definitions and GUARDED_SCOPE_END will cause destructors to run before update of guard variable. Could happen if someone thinks it "looks better" without understanding how stuff works. That kind of error will behave as if exception was thrown. Is this something to investigate further? Messy or potentially useful? Suggestions for improvements? I've appended the contents of my small test program at the end of this email. Can be tested by inserting GUARDED_SCOPE_RETURN() and "throw exception();". Regards, /Martin ----------- #include <iostream> #include <exception> #include <boost/scope_exit.hpp> using namespace std; #define GUARDED_SCOPE_BEGIN bool return_called = false; { bool& return_called_ref = return_called; bool exception_thrown = true; #define GUARDED_SCOPE_NESTED_BEGIN { bool& return_called_ref = return_called; bool exception_thrown = true; #define GUARDED_SCOPE_END exception_thrown = false; (void) return_called_ref; } #define GUARDED_SCOPE_RETURN(rc) { return_called_ref = true; return rc; } #define GUARDED_SCOPE_EXIT(Seq) BOOST_SCOPE_EXIT(Seq) #define GUARDED_SCOPE_EXIT_END BOOST_SCOPE_EXIT_END #define GUARDED_SCOPE_SUCCESS(Seq) BOOST_SCOPE_EXIT( (&return_called_ref) (&exception_thrown) Seq) { if(return_called_ref || !exception_thrown) #define GUARDED_SCOPE_SUCCESS_END } BOOST_SCOPE_EXIT_END #define GUARDED_SCOPE_FAILURE(Seq) BOOST_SCOPE_EXIT( (&return_called_ref) (&exception_thrown) Seq) { if(!return_called_ref && exception_thrown) #define GUARDED_SCOPE_FAILURE_END } BOOST_SCOPE_EXIT_END void foo() { GUARDED_SCOPE_BEGIN GUARDED_SCOPE_EXIT() { cout << "Returning from foo()" << endl; } GUARDED_SCOPE_EXIT_END GUARDED_SCOPE_SUCCESS() { cout << "foo(): No Errors occurred!" << endl; } GUARDED_SCOPE_SUCCESS_END GUARDED_SCOPE_FAILURE() { cout << "foo(): Exception caught!" << endl; } GUARDED_SCOPE_FAILURE_END do { GUARDED_SCOPE_NESTED_BEGIN GUARDED_SCOPE_FAILURE() { cout << "Inner scope: Exception caught!" << endl; } GUARDED_SCOPE_FAILURE_END GUARDED_SCOPE_SUCCESS() { cout << "Inner scope: No Errors occurred!" << endl; } GUARDED_SCOPE_SUCCESS_END GUARDED_SCOPE_END } while(0); GUARDED_SCOPE_END } int main() { try { foo(); } catch(exception& e) { cout << "main(): Caught exception: " << e.what() << endl; return -1; } cout << "main(): No Errors occurred!" << endl; return 0; }

9 16

[scope_exit] MSVC error C2355: 'this' : can only be referenced inside non-static member functions
by Lorenzo Caminiti 01 Mar '11

01 Mar '11

Hello all, I am trying to use Boost.ScopeExit parameter binding mechanism to implement Boost.LocalFunction. To do so, I need to use some internal ScopeExit code to detect the type of `this` and bind its value to the local function declaration. The following code works on GCC but not on MSVC... This appears to be a MSVC 2008 bug: http://connect.microsoft.com/VisualStudio/feedback/details/331418/erroneous… 1) Can anyone please try this code on MSVC versions later than 2008 to see if it was fixed? 2) Do you know of a workaround for this problem? // File: lf03.cpp #include <boost/scope_exit.hpp> struct c { void f() { typedef void (*this_t)(int this_ ); #if defined(BOOST_MSVC) // for MSVC typedef boost::type_of::msvc_typeid_wrapper< sizeof(*boost::type_of::encode_start( #else // for GCC typedef __typeof__( boost::type_of::ensure_obj( #endif boost::scope_exit::aux::wrap( boost::scope_exit::aux::deref( this, (this_t)0 ) ) ) #if defined(BOOST_MSVC) // for MSVC )>::type #else // for GCC ) #endif this_w; } }; int main() { c cc; cc.f(); return 0; } I get this error on MSVC 2008 but the code compiles just fine on GCC: Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.42 for 80x86 Copyright (C) Microsoft Corporation. All rights reserved. lf03.cpp using native typeof lf03.cpp(17) : error C2355: 'this' : can only be referenced inside non-static member functions lf03.cpp(22) : error C2955: 'boost::type_of::msvc_typeid_wrapper' : use of class template requires template argument list C:\Program Files\boost\boost_1_42\boost/typeof/msvc/typeof_impl.hpp(212) : see declaration of 'boost::type_of::msvc_typeid_wrapper' Thank you very much. -- Lorenzo

5 8

[serialization] boost/serialization/path.hpp
by Johan Råde 21 Feb '11

21 Feb '11

There is no boost/serialization/path.hpp. I suggest the following: ---------------------------------------------------------------------------------------------------------------- #ifndef BOOST_SERIALIZATION_PATH_HPP #define BOOST_SERIALIZATION_PATH_HPP // MS compatible compilers support #pragma once #if defined(_MSC_VER) && (_MSC_VER >= 1020) #pragma once #endif #include <boost/config.hpp> #include <boost/filesystem/path.hpp> #include <boost/serialization/level.hpp> BOOST_CLASS_IMPLEMENTATION(boost::filesystem::path, boost::serialization::primitive_type) #ifndef BOOST_NO_STD_WSTRING BOOST_CLASS_IMPLEMENTATION(boost::filesystem::wpath, boost::serialization::primitive_type) #endif namespace boost { namespace serialization { template<class Archive, class String, class Traits> void serialize(Archive& ar, boost::filesystem::basic_path<String, Traits>& p, const unsigned int version) { String s; if(Archive::is_saving::value) s = p.string(); ar & boost::serialization::make_nvp("string", s); if(Archive::is_loading::value) p = s; } }} #endif //-------------------------------------------------------------------------------------------------------------- Comments? Any suggested improvements? --Johan Råde

5 11

Re: [boost] [filesystem] temp_dir_path()
by Domagoj Saric 21 Feb '11

21 Feb '11

"Beman Dawes" <bdawes(a)acm.org> wrote in message news:AANLkTinFigAxpqkbgwQCnOXrr-Jg44=_dep1QWn+hy-Z@mail.gmail.com... > On Tue, Oct 19, 2010 at 3:35 AM, Domagoj Saric <dsaritz(a)gmail.com> wrote: >> Would it be perhaps possible to provide a lower-level function (even in >> the detail namespace) that uses a plain char buffer and an error code, >> that is free of std::vectors, std::strings, boost::paths, >> system::error_codes and >> other things one might not want to pay for (especially if one does not >> use them otherwise) just to make a system API call..? The 'proper' >> version can then wrap the thinner one... > > It would be technically possible, of course, but ... > > What you are really asking for, I think, is a C language interface or > something pretty close to that. The attitude/assumption that anything C++ must implicitly become intimate with the keywords new, virtual and throw otherwise it is actually 'only C' is just plain wrong in the fullest sense of the word: - it is wrong 'factually' not only because (most of) C is a subset of C++ but because it is quite possible to do heavy C++ programming (e.g. so heavy that it causes GCC 4.2.1 to allocate tens of gigabytes of RAM before it eventually kills the entire OS) practically without using any of the before mentioned STL 'goodies'... - it is wrong 'morally' because it is guilty of the typical 'premature pessimization' that feeds the typical anti C++ and anti Boost arguments...IOW Linus will no longer have to ask 'How many memory allocations does it take a C++ programmer to concatenate two strings?' but 'Guess how many tens of kilobytes will calling boost::temp_dir_path() add to your binary?' The 'plain char buffer' can also be understood in a more 'relaxed'/'broader' way to for example also encompass a, more C++ like, iterator_range that specifies a preallocated chunk of storage... > I could have designed the library that way, but didn't want to add a > third way for users to do things, and didn't want to take on the > increased documentation, test, etc, workload. Calling it a 'third way' is bit too hard IMO, why not think of it just as an overload (albeit of a more extreme kind)? -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman

3 2

[C++0x] Emulation of scoped enums
by Beman Dawes 16 Feb '11

16 Feb '11

The improved type safety of the C++0x scoped enum feature is attractive, so I'd like to start using it as it becomes available in compilers. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf for a description. Note that the committee changed the name from strongly typed enums to scoped enums. See the attached for a boost/detail header that provides macro wrappers that use scoped enums if available, otherwise fall back on C++03 namespaces and unscoped enums. It lets a library write: BOOST_SCOPED_ENUM_START(algae) { green, red, cyan }; BOOST_SCOPED_ENUM_END ... BOOST_SCOPED_ENUM(algae) sample( algae::red ); void func(BOOST_SCOPED_ENUM(algae)); and then a user can write: sample = algae::green; func( algae::cyan ); Comments or suggestions appreciated, --Beman // scoped_enum_emulation.hpp ---------------------------------------------------------// // Copyright Beman Dawes, 2009 // Distributed under the Boost Software License, Version 1.0. // See http://www.boost.org/LICENSE_1_0.txt // Generates C++0x scoped enums if the feature is present, otherwise emulates C++0x // scoped enums with C++03 namespaces and enums. The Boost.Config BOOST_NO_SCOPED_ENUMS // macro is used to detect feature support. // // Caution: only the syntax is emulated; the semantics are not emulated and // the syntax emulation doesn't include being able to specify the underlying type. // // See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf for a // description of the feature. Note that the committee changed the name from // strongly typed enums to scoped enums. // // Sample usage: // // BOOST_SCOPED_ENUM_START(algae) { green, red, cyan }; BOOST_SCOPED_ENUM_END // ... // BOOST_SCOPED_ENUM(algae) sample( algae::red ); // void foo( BOOST_SCOPED_ENUM(algae) color ); // ... // sample = algae::green; // foo( algae::cyan ); #ifndef BOOST_SCOPED_ENUM_EMULATION_HPP #define BOOST_SCOPED_ENUM_EMULATION_HPP #include <boost/config.hpp> #ifndef BOOST_NO_SCOPED_ENUMS # define BOOST_SCOPED_ENUM_START(name) enum class name # define BOOST_SCOPED_ENUM_END # define BOOST_SCOPED_ENUM(name) name #else # define BOOST_SCOPED_ENUM_START(name) namespace name { enum enum_t # define BOOST_SCOPED_ENUM_END } # define BOOST_SCOPED_ENUM(name) name::enum_t #endif #endif // BOOST_SCOPED_ENUM_EMULATION_HPP

14 27