January 2011 - Boost - lists.boost.org

[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

[interprocess] sharing memory between 32 bit and 64 bit Windows processes
by Arno Schödl 23 Feb '11

23 Feb '11

Hello Ion, I also need this functionality badly. Is there any chance of you implementing it? Basically, using unsigned int instead of size_t and int instead of ptrdiff_t, so the binary layout of shared memory is always like in 32 bit, would in practice do the trick. If we implement it ourselves, would you support getting this into boost? I cannot promise complete support. I already saw that rbtree_best_fit has a problem because the ring list containing the memory blocks needs to wrap around from the last block to the first. Would porting Doug Lea's allocator be an option? It will be hard to beat something that has been so thoroughly used and improved. Cheers, Arno -- Dr. Arno Schödl | aschoedl(a)think-cell.com Technical Director think-cell Software GmbH | Chausseestr. 8/E | 10115 Berlin | Germany http://www.think-cell.com | phone +49 30 666473-10 | US phone +1 800 891 8091 Amtsgericht Berlin-Charlottenburg, HRB 85229 | European Union VAT Id DE813474306 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl

2 7

Which libraries on the review schedule are ready for review?
by vicente.botet 22 Feb '11

22 Feb '11

Hi, I would like the authors of the libraries on the review schedule state clearly if his libraries are ready for review. Lexer Ben Hanson - Eric Niebler - Shifted Pointer Phil Bouchard - Needed - Logging John Torjo - Gennadiy Rozental - Join Yigong Liu - Needed - Pimpl Vladimir Batov - Needed - Task Oliver Kowalke - Vicente Botet - Endian Beman Dawes - Needed - Conversion Vicente Botet - Needed - Sorting Steven Ross - Needed - AutoBuffer Thorsten Ottosen - Robert Stewart - String Convert Vladimir Batov - Needed - Containers Ion Gaztañaga - Needed - Type Traits Extensions Frédéric Bron - Joel Falcou - Interthreads Vicente Botet - Needed - Bitfield Vicente Botet - Needed - Lockfree Tim Blechmann - Needed - Fiber Oliver Kowalke - Needed - Creasing (Sequence Properties) Grant Erickson - Needed - Static Size Linear Algebra Emil Dotchevski - Needed - Locale Artyom Beilis - Needed - XInt Chad Nelson - Needed - Context Oliver Kowalke - Needed - Stopwatches Vicente Botet - Anthony Williams - Please could you replay to this mail for each one of your libraries? Thanks, Vicente

13 36

[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

Distributed Boost with CMake: proposal and volunteering
by Daniel Pfeifer 21 Feb '11

21 Feb '11

Hi all, I would like to propose my approach to a modularized build of the Boost C++ Libraries with CMake. The project is found on http://github.com/purpleKarrot/Boost.CMake The following features are currently implemented: * Aggregate modules from different sources (CVS, SVN, GIT, tarballs, ...). * Build, Test, Install * Create a binary installer with selectable components for Windows. * Create a source package (with the modules included) that can do everything in this list (except the first entry). * Create a Debian source package that can be uploaded to a Launchpad PPA where it is built and packaged into many binary Debian packages. * Build Documentation (the usual quickbook-doxygen-boostbook-chain). * Tested on Windows (Visual Studio 10) and Ubuntu (GCC). * Precompiled headers (currently MSVC only). * Build two Boost.MPI libraries on Debian: boost_openmpi and boost_mpich2. * Tests actually make use of Boost's autolinking feature. This tool would allow the following Boost development process: * Each Boost library uses it's own repository (no matter which VCS) * Boost.CMake has a list of modules (or multiple list: eg 'boost' and 'incubating') * A modules definition consists of the information about where to get the source code from. * Boost.CMake can be used to aggregate all modules, run tests, build release packages... * Incubating libraries can be tested before they become an official part of boost. Please note that I am not proposing a development process. I am just proposing a tool. I am volunteering to extend and maintain the tool so that it can (help to) drive the development process. If you decide that all libraries should use git, I can drop the support for all other VCSs, no problem. Also, I am happy to implement other missing features. In the next couple of days I was going to write some documentation and a tutorial how to migrate the libraries to CMake. Cheers, Daniel

7 13

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

[config] Request for BOOST_SYMBOL_IMPORT_VISIBLE ?
by Mostafa 14 Feb '11

14 Feb '11

Hi, I propose the introduction of BOOST_SYMBOL_IMPORT_VISIBLE to Boost.Config that behaves like BOOST_SYMBOL_IMPORT in all cases except gcc (and like compilers?) where it expands to "__attribute__((visibility("default")))". I believe this is need to address the following two scenarios: (For gcc, assume all libraries are built with the following option: -fvisibility=hidden) ********** Scenario 1 ********** Export class MyException from Library A. Catch MyException in Library B, and be able to throw or rethrow it from Library B. Catch MyException in Library C. To be able to do this with gcc, MyException has to be visible from Library B since the exception handler in Library C will look for the class definition of MyException in Library B [1]. I don't believe it's possible to do this "out of the box" with Boost.Config and still support gcc and msvc libs. Conventionally, one would do the following: //--------------- //Start Library A //--------------- #ifdef MYLIB_BUILD #define MYLIB_API BOOST_SYMBOL_EXPORT #else #define MYLIB_API_BOOST_SYMBOL_IMPORT #endif class MYLIB_API MyException ... { ... }; //------------- //End Library A //------------- But this technique fails to make MyException visible from Library B with gcc. And where I to use BOOST_SYMBOL_VISIBLE instead, it would fail to export MyException from Library A with msvc. ********** Scenario 2 ********** Export class MyShape from Library A. Import class MyShape from Library A into Library B and have Library B export the following the function: MyShape & foo(); Import MyShape and foo into Library C, and Library C export the function: MyShape & bar(); To be able to do this with gcc, MyShape has to be visible from Library B and Library C [2]. Conventionally, one would do the following: //--------------- //Start Library A //--------------- #ifdef LIB_A_BUILD #define LIB_A_API BOOST_SYMBOL_EXPORT #else #define LIB_A_API_BOOST_SYMBOL_IMPORT #endif class LIB_A_API MyShape ... { ... }; //--------------- //Start Library B //--------------- #ifdef LIB_B_BUILD #define LIB_B_API BOOST_SYMBOL_EXPORT #else #define LIB_B_API_BOOST_SYMBOL_IMPORT #endif LIB_B_API MyShape & foo(); //--------------- //Start Library C //--------------- #ifdef LIB_C_BUILD #define LIB_C_API BOOST_SYMBOL_EXPORT #else #define LIB_C_API_BOOST_SYMBOL_IMPORT #endif LIB_C_API MyShape & bar(); But this leads back to the same problem/proposed solution as Scenario 1. Thanks in advance, Mostafa [1] http://gcc.gnu.org/wiki/Visibility: "Problems with C++ exceptions (please read!)", 2nd Paragraph. [2] http://gcc.gnu.org/wiki/Visibility: "Problems with C++ exceptions (please read!)", 3rd Paragraph.

7 22

Problem with boost::random seed
by Anton Skvorts 10 Feb '11

10 Feb '11

Testing boost::random with the following code boost::mt19937 gener(1); boost::normal_distribution<> normal(0,1); boost::variate_generator<boost::mt19937 &,boost::normal_distribution<> > rng(gener, normal); cout << rng() << endl; cout << rng() << endl; cout << rng() << endl; gener.seed(2); cout << rng() << endl; cout << rng() << endl; cout << rng() << endl; I'm getting unexpected values after gener.seed(2) -2.971829031 1.706951063 -0.430498971 -2.282022417 x -0.5887503675 0.2504171986 The value -2.282022417 is the forth number in the sequence originated by gener(1) and not the first number in the sequence originated by gener.seed(2) as one would expect (this number is actually -0.5887503675). If I reseed next with gener.seed(3)it works fine, but if after that I reseed again with gener.seed(1) I'll get the same problem, and so on and off... How can I reseed the random number generator to overcome this problem? Thanks in advance

3 10

[general] What will string handling in C++ look like in the future [was Always treat ... ]
by Matus Chochlik 10 Feb '11

10 Feb '11

The string-encoding-related discussion boils down for me to the following: What fill the string handling in C++ look like in the (maybe not immediate) future. *Scenario A:* We will pick a widely-accepted char-based encoding that is able to handle all the writing scripts and alphabets that we can think of, has enough reserved space for future additions or is easily extensible and use that with std::strings which will become the one and only text string 'container' class. All the wstrings, wxString, Qstrings, utf8strings, etc. will be abandoned. All the APIs using ANSI or UCS-2 will be slowly phased out with the help of convenience classes like ansi_str_t and ucs2_t that will be made obsolete and finally dropped (after the transition). *Scenario B:* We will add yet another string class named utf8_t to the already crowded set named above. Then: library a: will stick to the ANSI encodings with std::strings It has worked in the past it will work in the future, right ? library b[oost]: will use utf8_t instead and provide the (seamles and straightforward) conversions between utf8_t and std::string and std::wstring. Some (many but not all) others will follow library c: will use std::strings with utf-8 ... library [.]n[et]: will use String class ... library q[t]: will use Qstrings .. library w[xWidgets]: will use wxStrings and wxChar* library wi[napi]: will use TCHAR* ... library z: will use const char* in an encoding agnostic way Now an application using libraries [a..z] will become the developers nightmare. What string should he use for the class members, constructor parameters, who to do when the conversions do not work so seamlesly ? Also half of the cpu time assigned to running that application will be wasted on useless string transcoding. And half of the memory will be occupied with useless transcoding-related code and data. *Scenario C:* This is basically the status quo; a mix of the above. A sad and unsatisfactory state of things. *Consequences of A:* - Interface breaking changes, which will require some fixing in the library client code and some work in the libraries themselves. These should be made as painless as possible with *temporary* utilities or convenience classes that would for example handle the transcoding from utf8 to UCS-2/UTF-16 in WINAPI and be no-ops on most POSIX systems. - Silent introduction of bugs for those who still use std::string for ANSI CP####. This is worse than above and will require some public-relations work on the part of Boost to make it clear that using std::strings with ANSI may be an error since Boost version x.y.z. - We should finally accept the notion that one byte, word, dword != one character and that there are code points and there are characters and both of them can have variable length encoding and devise tool to handle them as such conveniently. - Once we overcome the troubled period of transition everything will be just great. No headaches related to file encoding detection and transcoding. Think about what will happen after we accept IPV6 and drop IPV4. The process will be painful but after it is done, there will be no more NAT, and co. and the whole network infrastructure will be simplified. *Consequences of B:* - No fixing of existing interface which IMO means no or very slow moving on to a single encoding. - Creating another string class, which, let us face it, not everybody will accept even with the Boost influence unless it becomes standard. - We will abandon std::string and be stuck with utf8_t which I *personally* already dislike :) - People will probably start to use other programming languages (although this may by FUD) *Consequences of C:* Here pick all the negatives of the above :) *Note on the encoding to be used* The best candidate for the widely-accepted and extensible encoding vaguely mentioned above is IMO UTF-8. - It has been given a lot of thought - It is an already widely accepted standard - It is char-based so no need to switch to std::basic_string<whatever_char_t> - It is extensible, so once we have done the painful transition we will not have to do it again. Currently utf-8 uses 1-4 (or 1-6) byte sequences to encode code points, but the scheme is transparently extensible to 1-N bytes (unlike UCS-X and i'm not sure about UTF-16/32). So, [dark-sarcasm] even if we dig out the stargate or join the United Federation of Planets and captain Kirk, every time he returns home, brings a truckload of new writing scripts to support, UTF-8 will be able to handle it. just my 0.02 strips of gold pressed latinum :) [/dark-sarcasm] Best regards, Matus

23 117