- Boost - lists.boost.org

Boost.Dynamic Config
by Dan Weber 15 Feb '11

15 Feb '11

Hi guys, I feel as part of the Boost community and having worked on multiple platforms that we're missing something to manage reading/writing configuration information for an application thread safely across platforms. The best example I know of that handles this job is Qt's QSettings which writes to the registry on windows, inis on linux, and some sort of xml on Mac OS X. The inspiration for this comes from the fact that I am looking to build web browser plugins that run on multiple platforms. I started by looking at how I could extend boost::program_options, and decided it wasn't the right tool because it was primarily for reading configurations, but not really writing to them. Likewise, it doesn't appear to provide anything in terms of thread safety. The interface should model after several things already in existence such as: QSettings, std::map, and tbb::concurrent_hash_map. It should also take into consideration how systems such as the Windows Registry works, as well as browser specific configuration systems like the one that comes with Mozilla Firefox, and of course file based storage. It should be easily extensible with a simple interface to implement a new backend with minimal work. At a later date, I think it should also be able to support things like boost::property_map or boost::fusion to make it easy to insert and extract objects from the underlying configuration system with automatic type conversion. I'm not sure how to combine it with boost::fusion or boost::property_map yet, so I'm hoping that's where you guys come in. Thanks, Dan Here is a preliminary interface: namespace boost { namespace dynamic_config { template<typename charT> class backend { public: enum operation_performed { none, // e.g. no value changed insert, update }; bool insert(basic_string<charT> key, (int, basic_string<charT>, bool, int64_t, char) value); // These values may be easily implementable with boost::variant, or separately if enable_if is used. bool update(basic_string<charT> key, (see above..) value); // Note this returns operation performed because optional locking will be done around these functions, so combining insert with update replaces a possible race condition over those 2 operations performed separately operation_performed replace(basic_string<charT> key, (...) value); template <T> bool select(basic_string<charT> key, T& value); // returns success if retrieved, this can also use boost::optional otherwise bool delete(basic_string<charT> key, bool cascade); // cascade takes effect if key takes a whole tree with it }; template <typename charT, typename Backend, typename Mutex> class property_config : boost::noncopyable { public: property_config(); property_config(basic_string<charT> organizationName, basic_string<charT> applicationName); // Pretty much required for use in the windows registry and in firefox ~property_config(); size_type erase(basic_string<charT> key); void clear(); template<typename T> bool find(basic_string<charT> key, T & value); template<typename T> bool insert(basic_string<charT> key, T value); template<typename T> bool update(basic_string<charT> key, T value); template<typename T> backend::operation_performed replace(basic_string<charT> key, T value); template<typename T> bool select(basic_string<charT> key, T& value); template<typename T> bool delete(basic_string<charT> key, T& value); }; template <typename charT, typename Backend, typename Mutex> template <typename T> backend::operation_performed property_config<charT, Backend, Mutex>::replace(basic_string<charT> key, T val) { scoped_lock(mutex_); backend_.replace(key,val); } } }

4 6

Bug fix in WFMO from the Boost vault
by Emil Dotchevski 14 Feb '11

14 Feb '11

Hello, I had uploaded a portable Wait For Multiple Objects based on Boost Thread in the vault. Few months ago a memory leak was reported and I finally fixed it this weekend. If you're one of the few people using it, you can download the new version from http://www.boostpro.com/vault/index.php?action=downloadfile&filename=wfmo.z…. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

1 0

[Git] Boost Filesystem now has public GitHub repository
by Beman Dawes 14 Feb '11

14 Feb '11

I'm now doing routine maintenance and development of the Boost Filesystem library via a public Git repository hosted on GitHub. See https://github.com/Beman/filesystem The point of this public repo is to gain actual use experience with Git and with a modularized Boost library. Modularization followed the pattern ryppl is proposing - the top level directory is the same as the current SVN list/filesystem, with the addition an "include" directory with a "boost" sub-directory containing the current SVN boost/filesystem stuff. None of the existing filesystem content was changed. So that the development environment will be identical to the current SVN trunk, I setup my local filesystem trunk repository using a little script: svn export %BOOST_TRUNK% fs-trunk cd fs-trunk/libs rm -r filesystem git clone git@github.com:Beman/filesystem.git filesystem cd ..\boost del filesystem.hpp rm -r filesystem mklink filesystem.hpp ..\libs\filesystem\include\boost\filesystem.hpp mklink /d filesystem ..\libs\filesystem\include\boost\filesystem The effect is to export the SVN trunk, then replace libs/filesystem with a git clone of the public repository. boost/filesystem is replaced with a symlink to libs\filesystem\include\boost\filesystem Note that no changes whatsoever needed to be made to either my Visual Studio or Boost.Build setups, Jamfiles, or anything else. Everything just works. The setup is a pleasure to use. I commit changes locally whenever it makes sense, without any need to maintain stability. Then when work reaches a stable state, I push it out to GitHub. When it comes time to apply the changes to the Boost repo, I'm applying the diffs locally and then committing. If Boost were using Git, I'd send a "pull" request. So far this whole experiment has been very reassuring. No problems and everything worked instantly. There was almost no learning curve, since I'd already been using Git and GitHub for awhile. --Beman

9 17

[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

Re: [boost] [UTF String] Feedback on UTF String library, please
by Brent Spillner 14 Feb '11

14 Feb '11

On 2/11/2001 17:05:25, Phil Endecott wrote: >Brent Spillner wrote: >>>Just when is it really valid to want to jump the 278th "abstract >>>character" in a string? >>> >>>Seriously, how often do these situations arise? >> >> Well, Boyer-Moore string searching, obviously. > >If you're doing Boyer-Moore on a UTF-8 string you should normally do it >on the bytes, not on the codepoints, so there is no need for random >access to the codepoints. This works because of the particular >properties of UTF-8, and will be faster because you don't have the >overhead of the UTF-8 decoding. The discussion was about 'abstract characters,' not codepoints. I think a codepoint iterator is likely useful too, but for most applications the character view is required. >The exception would be if you want to do comparison at the "grapheme >cluster" level, i.e. if you want to consider a single-codepoint, >multi-byte representation of e.g. an accented character as equal to the >multiple-codepoint, multi-byte representation comprising a base Yes, I think that's the behavior desired for most applications. >character plus a combining accent. I would suggest that it would be >better to first normalise your strings, so that this doesn't arise. ...but I think that's a little too glib. If you have the string "résumé" in your data store, and a user enters "resume" as a search key, then you either have to search independently for each plausible variant for "resume," or you have to maintain a parallel, accent-free copy of the original text and the means to translate indices into the accent-free version into indices into the rich version, or you have to have some notion of 'abstract character' comparison and iteration. I think the last solution is by far the most preferable, particularly for a low-level library. This is how people actually use strings in practice, after all. >Even if you did want to do Boyer-Moore on the codepoint-sequence, I >think that using std::advance to move a bidirectional iterator would >not change its complexity order. It clearly won't; you need to ::advance at most O(n) times, and Boyer-Moore is already a linear complexity algorithm (and I'd be amazed to see a sublinear one for the general case.) But since the whole algorithm is linear, those extra O(n) iterator advancements past code units that you already know to be irrelevant could be a measurable contributor to the total run time. >Are you suggesting some sort of indexed string? I guess you could use >an augmented tree to provide O(log N) access to the N'th character in a >UTF-8 string. In fact didn't someone propose something like that a few Yes, that's what I was thinking. >months ago? Not as a string but as a "vector whose iterators are not >invalided" or "list with random access" or something? Good to know; I'll take a look at that.

2 1

[function_types] Number of default parameters
by Lorenzo Caminiti 14 Feb '11

14 Feb '11

Hello all, Is there a way to determine at compile-time the number of parameters with default values from a function type? For example, can I program the following `count_defaults` metafunction? count_defaults< bool(*)(int x, int y) >::value // == 0 count_defaults< bool(*)(int x, int y = 1 >::value // == 1 count_defaults< bool(*)(int x = 2, int y =1) >::value // == 2 (If this is possible, it could be added to Boost.FunctionTypes.) Thank you. -- Lorenzo

5 7

TTI library updated in the sandbox to version 1.3
by Edward Diener 13 Feb '11

13 Feb '11

I have updated the TTI library in the sandbox 'tti' directory to version 1.3. The TTI library, which is an abbreviation for the 'Type Traits Introspection' library, allows a programmer to introspect at compile time the inner elements of a C++ type. The introspection process depends on specifying the name of the inner element by different macros for different types of elements, and then using a generated metafunction to determine whether that element exists within the enclosing type. The inner elements which can be introspected are type, class template, member data, member function, static member data, and static member function. With this update no functionality in the library has changed, but names have changed. The major change is that the library has been Boostified for possible review. 1) The update changes the library to use the Boost naming conventions. 2) The names of the main header files have been shortened and changed to 'tti.hpp' and 'tti_vm.hpp' respectively. 3) The macros in the library now start with BOOST_TTI. 4) The main namespace is now boost::tti. 5) Other filenames now follow Boost filename convention. 6) The documentation is distributed in both HTML and PDF format with indexes, and can be regenerated. 7) The variadic macro support in the library only works with the latest version 1.3+ of the variadic_maco_data library in the sandbox. The TTI library is based on the type_traits_ext portion of the Concept Traits Library, with improvements and additions, and also reproduces functionality ( without changing existing code ), for the purposes of completeness, from Boost.MPL regarding introspection of types and templates. The purpose of the library is to provide a consistent set of interfaces for doing compile-time introspection of a type, which other template metaprogrammers can use in their code. If you are at all interested in compile-time introspection of types, please take a look at the functionality of this library. There is a readme.txt in the top-level directory, for anyone browsing the sandbox. There is a build.txt file in the doc subdirectory for building the documentation and running the tests. The documentation is also included as part of the sandbox files for those who can not build the docs. The library has been tested and works with gcc 3.4.2, 3.4.5, 4.3.0, 4.4.0, 4.5.0-1, 4.5.2-1 and VC++ 8.0, 9.0, 10.0. It may also work with other compilers. Questions, comments, suggestions, and bug reports are all welcome.

2 3

[local] Bound types for concepts, etc?
by Lorenzo Caminiti 13 Feb '11

13 Feb '11

On Sun, Feb 6, 2011 at 2:25 PM, Mathias Gaunard <mathias.gaunard(a)ens-lyon.org> wrote: > As I said, it does. With Boost.Local, you can still call polymorphic > functions on the variables captured from scope without specifying the types > of the arguments. I am thinking to provide the type of the bound parameters within the local function body as `<BOUND_PARAM_NAME>_type`. This way you can use such types to check concepts, etc... Is there value in this? #include <boost/local/function.hpp> #include <boost/concept_check.hpp> #include <iostream> template<typename T> class Addable { T x; T y; void return_type(T); // Used to check addition returns type `T`. public: BOOST_CONCEPT_USAGE(Addable) { return_type(x + y); // Check addition `T operator+(T x, T y)`. } }; struct pod {}; int main() { pod sum; // Can't be added. int factor = 10; BOOST_LOCAL_FUNCTION( (void) (add)( (double)(num) (const bind)((factor)) (bind)((&sum)) ) ) { // In here `sum_type` and `factor_type` are the types of the respective bound parameters. BOOST_CONCEPT_ASSERT((Addable<sum_type>)); sum = sum + factor * num; // Error because `sum`'s type can't be added :( } BOOST_LOCAL_FUNCTION_END(add) add(100.0); return 0; } On GCC: $ g++ -Wall -Werror -I../../.. concepts.00.cpp concepts.00.cpp: In static member function ‘static void main()::boost_local_auxXfunctorXadd::boost_local_auxXbody(main()::boost_local_auxXfunctorXadd&, int, main()::boost_se_capture_t_1_add35&, double)’: concepts.00.cpp:39: error: no match for ‘operator+’ in ‘sum + (#‘float_expr’ not supported by dump_expr#<expression error> * num)’ concepts.00.cpp: In destructor ‘Addable<T>::~Addable() [with T = pod]’: /usr/include/boost/concept/detail/general.hpp:29: instantiated from ‘static void boost::concept::requirement<Model>::failed() [with Model = Addable<pod>]’ concepts.00.cpp:37: instantiated from here concepts.00.cpp:22: error: no match for ‘operator+’ in ‘((Addable<pod>*)this)->Addable<pod>::x + ((Addable<pod>*)this)->Addable<pod>::y’ Note: In this specific case even the GCC error without the concept assert (error on line 39) is pretty clear but in general allowing programmer to add concept specifications might lead to better error reporting and a better specification of the local function. -- Lorenzo

2 2

Variadic_macro_data library updated to version 1.3
by Edward Diener 13 Feb '11

13 Feb '11

I have updated the variadic_macro_data library in the sandbox 'variadic_macro_data' directory to version 1.3. The variadic_macro_data library adds support and functionality for variadic macros to Boost as well as integrating variadic macros with the Boost PP library without changing the latter library in any way. With this update no functionality in the library has changed, but names have changed. The major change is that the library has been Boostified for possible review. 1) The update changes the library to use the Boost naming conventions. 2) The name of the main header file has been shortened and changed to 'vmd.hpp'. 3) The macros in the library now start with BOOST_VMD. 4) Other filenames now follow Boost filename convention. 5) The documentation is distributed in both HTML and PDF format with indexes, and can be regenerated. There is a readme.txt in the top-level sandbox directory, for anyone browsing the sandbox. There is a build.txt file in the doc subdirectory for building the documentation and running the tests. The documentation is also included as part of the sandbox files for those who can not build the docs. The library has been tested and works with gcc 3.3.3, 3.4.2, 3.4.5, 4.3.0, 4.4.0, 4.5.0-1, 4.5.2-1 and VC++ 8.0, 9.0, 10.0. It should also work with other compilers which support variadic macros. Questions, comments, suggestions, and bug reports are all welcome.

1 0

Errors in "getting started" documentation
by Loïc Joly 12 Feb '11

12 Feb '11

Hello, I recently upgraded to the 1.45 version on windows, with VC++2010. I noticed several errors in the documentation. I think they are really important, because installation is the first thing people will ever encounter from boost, and if the installation procedure is buggy, people might decide not to look any further. http://www.boost.org/doc/libs/1_45_0/more/getting_started/windows.html#get-… If we get a prebuild bjam program, the compilation step will fail. We need to get a bjam by executing the bootstrap file in the distribution, not by downloading it. http://www.boost.org/boost-build2/doc/html/bbv2/reference/tools.html#bbv2.r… This section does not refer to msvc 10.0, so it may look like this compiler version is not supported. (btw, should this kind of problem be reported in trac or here ?) Regards, -- Loïc Joly

1 0