- Boost - lists.boost.org

[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

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

12 Feb '11

On 02/11/2011 14:09:27 Marsh Ray wrote: >So let me ask the question: > >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. And as noted previously, short snippets of null-terminated text are not the only things that people store within a std:string or behind a char *. There's a tremendous amount of data out there in fixed-column databases, for example, and undoubtedly many maintainers who'd like a painless way to upgrade the column unit from 'byte' to 'generic character.' It's also probably a logical fallacy to assume that every string algorithm on every device supported by Boost will always be cache-limited. If strings for you are just handles that you pass to other people's APIs, then no, you don't need random access to the contents. But if you're seriously aiming to create a Unicode-aware drop-in replacement for existing string classes, then it ought to support all of the existing code that assumes efficient random access. And if you can provide measurable speedup for at least the common case, even at the cost of a few extra bits per data chunk, that's worth pursuing.

2 1

[pool][hit-squad] Kudos! Updates?
by Jim Bell 12 Feb '11

12 Feb '11

Looking at the commit log (/sandbox/guild/pool), I see commits by pbristow, ktchan, danieljames, marshall, and steven_watanabe. Thanks for your efforts! Kudos to John Maddock for the idea and impetus. How's it going? Road-blocks? Show-stoppers? Thoughts? Need more hands/eyeballs/brains/hours-in-the-day? Best, -Jim

2 1