February 2011 - Boost - lists.preview.boost.org

[local] Simplifying the parenthesized syntax
by Lorenzo Caminiti 24 Feb '11

24 Feb '11

On Sun, Feb 6, 2011 at 10:26 AM, Vicente Botet <vicente.botet(a)wanadoo.fr> wrote: > The fact that you can not use variadic macros at work doesn't means that > your library can not provide in addition variadic macros on compilers > supporting them. I have no idea the work that this suppose, but if the > interface could be more appealing your library will have much more people > interested in. > > Have you an idea of how the interface could be simplified if variadic macros > were used? The purpose of this email if to brainstorm possible ideas to simplify the parenthesized syntax. Sorry in advance if not all that I say is correct -- I haven't implemented it yet so I might be saying inaccurate/unfeasible things here and there. As always, your feedback is very welcome :) PRELIMINARY IDEAS TO SIMPLIFY THE PARENTHESIZED SYNTAX Consider the following parenthesized syntax for local functions: (void) (f)( (int)(x) (double&)(y) (const bind)((a)(&b)) (bind)((&c)(d)) ) // [0] The followings are possible ways to simply this syntax. 1 MERGING PARAMETER TYPES AND NAMES (C++ preprocessor) Parameter names can be passed to function types so I can transform `int x` into `int` at compile-time: int x --[make function type]--> void (int x) --[get 1st parm type]--> int This should allow me to simplify the parenthesized syntax [0] to: (void) (f)( (int x) (double& y) (const bind)((a)(&b)) (bind)((&c)(d)) ) // [1] Note that the (unbound) parameter type and name are merged into a single sequence element. The following should also be possible: (void) (f)( (int x) (double& y) (const bind a) (const bind& b) (bind& c) (bind d) ) // [1a] Is [1a] simpler than [1]? Maybe it is... 2 TOWARD THE NORMAL PARAMETER LIST SYNTAX (C99 preprocessor) Using variadic macros I _might_ be able to use a variable length tuple (can I? I am not very familiar with these yet...) instead of a sequence to represent the function parameters: (void) (f)(int x, double& y, const bind a, const bind& b, bind& c, bind d) // [2] I think, this is a great simplification over [0] because it is the exact same syntax used by C++ to declare function parameters! Note that `const bind` and `bind` have been distributed to all the bound parameters. Given that sequences are best avoided here (to reduce extra parenthesis), I do not think there is a less verbose way to enumerate the bound parameters. The followings could also be possible: (void) (f)(int x, double& y, const bind (a, &b), bind (&c, d) ) // [3] (void) (f)(int x, double& y) (const bind)(a, &b) (bind)(&c, d) // [4] But I think enumerating every bound variable separately as in [2] makes the parameter list syntax look the closet to normal C++ syntax even if it requires the repetition of `const bind` and `bind` as the types of the bound variables. Therefore, I would prefer [2] over both [3] and [4]. 3 RETURN TYPE AND FUNCTION NAME (C++ and C99 preprocessors) I don't know how/if I can simplify the passing of the return type and function name because I do need the function name as a separate token within the preprocessor to do token concatenation and generate unique names that refer to the function name... Something like this should be possible (using tuples instead of sequences): void, f, ( (int)(x) (double&)(y) (const bind)((a)(&b)) (bind)((&c)(d)) ) // [5] void, (f)( (int)(x) (double&)(y) (const bind)((a)(&b)) (bind)((&c)(d)) ) // [6] And again, on C99: void, f, (int x, double& y, const bind a, const bind& b, bind& c, bind d) // [7] void, (f)(int x, double& y, const bind a, const bind& b, bind& c, bind d) // [8] However, I don't see how these are simpler than [0] and [2]. I need to think about this more to see if other syntaxes are possible... 4 DEFAULT PARAMETER VALUES (C++ and C99 preprocessors) Currently local functions support default parameters via the following parenthesized syntax: (void) (f)( (int)(x)(default)(-1) (double)(y)(default)(1.23) ) // [9] I think this could be simplified to (note the removal of the parenthesis around the default value): (void) (f)( (int)(x)(default -1) (double)(y)(default 1.23) ) // [10] An additional simplification could be to merge parameter types and names together as in [1]: (void) (f)( (int x)(default -1) (double y)(default 1.23) ) // [10a] Plus using C99 variadics as in [2]: (void) (f)(int x, default -1, double y, default 1.23) // [11] I am not a big fan of this because `default` is separated from its parameter by the comma `,`... but I don't think I can do better than this. 5 OTHERS CONSIDERATIONS These considerations are not directly relevant to local functions but the parenthesized syntax [0] was designed as a general syntax that makes *all* the elements of a function declaration available for preprocessor metaprogramming. Instead, syntaxes [1] and [2] cannot separate the parameter type token from the parameter name token at preprocessing time. Therefore: a) I don't think [1] and [2] allow to generate a parameter with the specified name but a different type. For example, say I want to add `const&` to `int x`, how can I do that unless `int x` is specified as `(int)(x)` or `(int, x)`? int x --[how can I do this??]--> add_reference<add_const<int>::type>::type x (I have to double check, but I don't think local functions need to manipulate parameter types retaining instead the parameter names so I don't think this is an issue for local functions.) b) Having the parameter names as separate tokens (which is possible with [0] but not with [1] or [2]) could be useful to generate unique names to handle function overloading (even if with some limitations). For example, in another library, I concatenate the function name token with the parameter name tokens to generate unique names for overloaded functions. As long as the overloaded functions use different parameter names (and not just different parameter types) this mechanism works. (Overloading is not supported for local functions -- see Rationale in library docs -- so this is not an issue for local functions.) Therefore, *IF* there was an interest in defining the parenthesized syntax to be as general as possible so it could be adopted everywhere macros spoil function definitions (to avoid requiring programmers to learn different syntaxes for the different macros), [0] is more general because it separates the parameter types from their names (at the cost of the extra parenthesis of course). Of all of these syntaxes, I _personally_ like [0] because it is pure C++ preprocessor and it is the most general (maybe with simplification [10] for default parameters). I also would like to provide [2] if the C99 preprocessor is detected -- ideally, the same parsing macros will be smart enough to accept both [2] and [0] on C99 and just [0] on pure C++ preprocessors. -- Lorenzo

8 19

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

24 Feb '11

Hello Ion, > - In a mixed environment, each shared heap can be no larger than 32 bit. > - offset_ptr must have the ability to point to any place _in any of potentially many heaps_ > because at the time of dereferencing it has no information about the heap it is meant > to point to. This requires a heap-relative 32 bit quantity plus some "heap selector", > or a this-relative 64 bit quantity. The latter is simple, fast and not significantly > less compact than the former, so we pick the latter. > - Option 1: For the rest of the code, the easiest option is to make everything 64 bit, e.g., > deriving size_type et. al. from offset_ptr. Unfortunately, this makes all interfaces 64 bit. > So even on 32 bit you can request a 64 bit shared heap. Internally, when going to the OS > to allocate the heap, there is a cast to 32-bit size_t with data loss, which is ugly. > - Option 2: So the interfaces should really be 32 bit on both 32 bit and 64 bit. > This would require a second template parameter size_type for the MemoryAlgorithm, > in addition to the pointer type. We can then migrate parts of the code to use this 32 bit > quantity as much as possible for compactness. I think this Option 2 is safer and > philosophically closer to what is really going on. - Option 3: Actually, the right solution is to make offset_ptr::difference_type of a mixed-environment offset pointer 32 bit, but its internal offset representation 64 bit. So all shared size_types and difference_types will be 32 bit, which is correct because all array sizes and differences between pointers within arrays are limited to 32 bit. For those places where internal algorithms (such as the rbtree memory algorithm) need modulo arithmetic, we will make a custom typedef in offset_ptr to export the "virtual address space size". Any objection? It would be great if you could give us feedback, because we want to get done with that stuff, we need it badly... Thanks! 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 5

About task library
by Jorge Lodos Vigil 24 Feb '11

24 Feb '11

Hi I am currently evaluating the task library currently in the vault for production use. The library is very well thought in my opinion, thank you very much Oliver for providing it to the community. It seems it was scheduled for review before but now it isn't. Vicente was the review manager. Is the library still intended to be reviewed? Is there some active work in the library? What about other libraries task depends on? The bound queues used in thread pools always causes the thread submitting task to wait if the queue is full. In our use cases, we need to fail the queuing, rather than wait. Is there any interest in adding this functionality to the library? In case there is I could perform the programming and testing. Thank you again. Cheers Jorge

2 2

additions to boost community calendar
by Ronald Garcia 24 Feb '11

24 Feb '11

I would like to list the review periods for upcoming library reviews, with brief library descriptions, on the boost community google calendar at http://www.boost.org/community/index.html. What is the process for doing this? Thanks, Ron

2 1

Boost.MPI --- Scatterv / Gatherv
by Júlio Hoffimann 24 Feb '11

24 Feb '11

Hi, Some collective operations are not implemented in Boost.MPI, namely Scatterv and Gatherv. Probably there is a great reason and i don't know. Something related to Boost.Serialization or the "skeleton and content" approach? (due to memory offsets, displacements, etc.) Can i write some code to you? I did check scatter.hpp and maybe is easy to implement by analogy. Best Regards, Júlio.

1 0

Re: [boost] [Boost-users] [boost-users][ICL] ICL Compilation errors. Ticket #5207
by Joachim Faulhaber 24 Feb '11

24 Feb '11

(4) Using statically and dynamically bounded intervals in the same compilation unit. 2011/2/23 John Reid <j.reid(a)mail.cryst.bbk.ac.uk>: > On a side note, I don't understand the rationale for having static bounds > configured by #define whilst other aspects of intervals are parameterised > using templates. You can always instantiate ICL interval container templates with the interval type of your choice via the template parameter IntervalT. See e.g. http://www.boost.org/doc/libs/1_46_0/libs/icl/doc/html/boost_icl/interface.… #define BOOST_ICL_USE_STATIC_BOUNDED_INTERVALS switches the default value for this template-parameter from dynamically bounded to statically bounded intervals. Like any other default of a template parameter you can change it via instantiation. The rational behind this is (1) the intention, to minimize the effort for users, that have applications of ITL containers and want to change their code using statically bounded intervals now. In the ITL every interval was dynamically bounded. (2) for applications that only use one kind of intervals, e.g. statically bounded ones, #define BOOST_ICL_USE_STATIC_BOUNDED_INTERVALS can be convenient, because you need only to specify the first one or two template parameter for interval containers most of the time. > I would have liked to have both types of interval in the > same compilation unit. NP > However I guess it must be too late to change this > fundamental design choice. Fortunately it's not too late ;-) This code shows how to use icl sets with variations of interval types. BOOST_AUTO_TEST_CASE(using_vaious_interval_types) { interval_set<int, std::less, discrete_interval<int,std::less> > dyn_int_set; interval_set<int, std::less, right_open_interval<int,std::less> > stat_int_set; interval_set<float, std::less, continuous_interval<float,std::less> > dyn_float_set; dyn_int_set += discrete_interval<int>(1); BOOST_CHECK(( contains(dyn_int_set,1) )); stat_int_set += right_open_interval<int>(1); BOOST_CHECK(( contains(stat_int_set,1) )); dyn_float_set += continuous_interval<float>(1.0); BOOST_CHECK(( contains(dyn_float_set, 1.0) )); } For interval_map this can get a little verbose, because of the greater number of template parameters. Thank you for your questions. They help to clarify a lot of issues around the library (even for the author:) Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de

2 1

[ICL]
by Tal Agmon 24 Feb '11

24 Feb '11

Hi Joachim, Please note: Icl's class templates<http://www.boost.org/doc/libs/1_46_0/libs/icl/doc/html/index.html#boost_icl…> *Table 1.1. Interval class templates in *--> the link to left_open_interval<http://www.boost.org/doc/libs/1_46_0/libs/icl/doc/html/boost/icl/right_open…>opens right_open_interval instead. Thanks.

2 1

Re: [boost] [Boost-users] [boost-users][ICL] ICL Compilation errors. Ticket #5207
by Joachim Faulhaber 24 Feb '11

24 Feb '11

(2) Generalization of "find" in the Set view and the STL/iterator view. 2011/2/23 John Reid <j.reid(a)mail.cryst.bbk.ac.uk>: > On 22/02/11 20:03, Joachim Faulhaber wrote: >> >> 2011/2/22 John Reid<j.reid(a)mail.cryst.bbk.ac.uk> >>> >> >> interval_map::find is a pretty late addition to ITL/ICL, because using >> find in the STL way makes little sense on interval containers most of >> the time. We can not "find" an large interval in an icl::interval_set >> of small intervals. >> >> {[0,2),[5,7)}.find([0,9)) > > If we cannot find the large interval, isn't the end() iterator a suitable > return value to suggest it was not in the set/map? This is a question of design decisions of course. On the one hand I view intervals as Sets and also interval_set implements Set. (Capital S for concept Set). In this view, it is unusual to ask whether a set is found in a set, because one is not intended to be the element of the other. I this view (the Set view) we can achieve everything we need using predicates contains, intersects and functions add_intersection, &= and & (intersection) http://www.boost.org/doc/libs/1_46_0/libs/icl/doc/html/boost_icl/function_r… On the other hand, but with a lower priority in my design, I am supporting functions using iterators that are common to STL containers and that will be expected by users. 'find' is only defined on element_types, because only element can be "found" in sets. All functionality related to a "generalized find" in the STL/iterator related view can be provided by the member functions lower_bound, upper_bound and equal_range that are common to STL interfaces of associative containers: http://www.boost.org/doc/libs/1_46_0/libs/icl/doc/html/boost_icl/function_r… Here is some code for clarification: BOOST_AUTO_TEST_CASE(generalized_find) { typedef icl::interval_set<int>::iterator int_set_iterator; icl::interval_set<int> int_set; icl::interval<int>::type to_be_found(1,5); int_set += icl::interval<int>::type(0,2); int_set += icl::interval<int>::type(4,7); int_set += icl::interval<int>::type(8,9); int_set_iterator found; found = int_set.lower_bound(to_be_found); cout << *found << endl; // [0,2) found = int_set.upper_bound(to_be_found); cout << *found << endl; // [8,9) std::pair<int_set_iterator,int_set_iterator> exterior; exterior = int_set.equal_range(to_be_found); cout << "[" << *exterior.first << "," << *exterior.second << ")" << endl; // [[0,2),[8,9)) } It's good you brought up this question, so I could clarify the design decisions here. Thanks, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de

2 2

Re: [boost] [Boost-users] [boost-users][ICL] ICL Compilation errors. Ticket #5207
by Joachim Faulhaber 24 Feb '11

24 Feb '11

2011/2/24 John Reid <j.reid(a)mail.cryst.bbk.ac.uk>: > On 24/02/11 11:51, Joachim Faulhaber wrote: >> >> (3) More compilability issues >> >> 2011/2/23 John Reid<j.reid(a)mail.cryst.bbk.ac.uk>: >>> >>> I'm interested to hear reasons why the following don't compile when using >>> static bounds: >>> >>> icl::add( icl::interval_set< int>(), 0 ); >>> icl::add( icl::interval_set< int>(), icl::interval< int>::type( 0, 1 ) >>> ); >>> icl::interval_set< int>() += 0; >>> icl::interval_set< int>() += icl::interval< int>::type( 0, 1 ); >>> >>> icl::subtract( icl::interval_set< int>(), 0 ); >>> icl::subtract( icl::interval_set< int>(), icl::interval< int>::type( 0, >>> 1 >>> ) ); >>> icl::interval_set< int>() -= 0; >>> icl::interval_set< int>() -= icl::interval< int>::type( 0, 1 ); >>> >>> icl::interval_set< int>()&= 0; >>> icl::interval_set< int>()&= icl::interval< int>::type( 0, 1 ); >>> >>> icl::interval_set< int>() ^= ( icl::interval< int>::type( 0, 1 ) ); >>> >>> >>> They all seem reasonable operations to me. In particular, for a discrete >>> domain, operations like icl::interval_set< int>() += 0 make sense to me. >>> That is the following are equivalent: >>> icl::interval_set< int>() += 0 >>> icl::interval_set< int>() += icl::interval< int>::type( 0, 1 ); >> >> Yes, you are right! The code you are giving should compile and it >> actually compiles on my machine with different msvc compilers. I guess >> it also compiles for gcc. If the problem persists try to generate a >> minimal code example so I can look again. > > We are still talking about static intervals. You did try setting the #define > for static intervals? Yes. > If you did, then my minimal example consists of > putting the code above in the function f() below: > > #define BOOST_ICL_USE_STATIC_BOUNDED_INTERVALS > #include <boost/icl/interval_set.hpp> > #include <boost/icl/interval_map.hpp> > > void f() { > namespace icl = ::boost::icl; > } > The reason that your code does not compile with gcc but compiles with msvc is, that gcc is pickier when you try to pass a temporary object to a reference parameter. When I pass the non-temporary object 'int_set' to the function calls, the code compiles. #define BOOST_ICL_USE_STATIC_BOUNDED_INTERVALS #include <boost/icl/interval_set.hpp> #include <boost/icl/interval_map.hpp> void f() { namespace icl = ::boost::icl; icl::interval_set<int> int_set; icl::add( int_set, 0 ); icl::add( int_set, icl::interval< int>::type( 0, 1 ) ); int_set += 0; int_set += icl::interval< int>::type( 0, 1 ); icl::subtract( int_set, 0 ); icl::subtract( int_set, icl::interval< int >::type( 0, 1 ) ); int_set -= 0; int_set -= icl::interval< int >::type( 0, 1 ); int_set &= 0; int_set &= icl::interval< int >::type( 0, 1 ); int_set ^= ( icl::interval< int >::type( 0, 1 ) ); } Regards, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de

1 0

[interprocess] file_mapping opening opening unicode path on Windows
by Jeff Flinn 24 Feb '11

24 Feb '11

Is it possible to open a interprocess::file_mapping for a unicode path on windows? Any workarounds? I'm using boost 1.44 but don't see any changes in this respect in the latest boost 1.46 release. Thanks, Jeff

2 2