- Boost - lists.boost.org

[interest] Egg, function object builders and adaptors
by shunsuke 17 Jan '08

17 Jan '08

Hi, all. In a recent discussion, a library named Egg possibly left a good impression on boosters, so I propose it. Introduction: It is not so easy to define FunctionObjects especially if you want to support Boost.ResultOf and Boost.Lambda. Therefore, as Boost provides iterator_facade and iterator adaptors, Egg provides function_facade and function adaptors. Egg provides the following features: * Helpers to build FunctionObject: * egg::function and egg::function_facade provides the way to build FunctionObject which supports Boost.ResultOf and Lambda. * FunctionObject Adaptors(in other words, higher-order functions): * egg::curryN supports the currying. * egg::pipable emulates extension methods(C#). * egg::fuse emulates variadic templates in very limited way. * etc... The zipped source code is in Vault/FunctionObjects: http://tinyurl.com/34lgda The document is on line: http://p-stade.sourceforge.net/boost/libs/egg/ svn repository: https://p-stade.svn.sourceforge.net/svnroot/p-stade/trunk/boost Tested under: trunk and Boost1.34.1. An example of currying in Egg: int plus(int x, int y) { return x + y; } typedef result_of_curry2<int (*)(int, int)>::type T_curried_plus; T_curried_plus const curried_plus = BOOST_EGG_CURRY2(&::plus); void test() { BOOST_CHECK( curry2(&::plus)(4)(9) == 13 ); BOOST_CHECK( curried_plus(4)(9) == plus(4, 9) ); BOOST_CHECK( uncurry(curry2(plus))(4, 9) == 13 ); } If interested enough, it might be enqueued to the review queue. Anyway, comments are most welcome. Regards, -- Shunsuke Sogame

6 9

Re: [boost] Boost.Tests: Unit test defines own main() function, why?
by Vectra17 17 Jan '08

17 Jan '08

This code needed #define BOOST_TEST_DYN_LINK and now works perfectly. Well almost perfectly, before I realised something rather strange: the compiler ask for a .LIB as well. I am sure it exectues the DLL because when I erase it, the program crashes(.dll not found). So why is the compiler still asking for a .LIB file when I specifeid DLL linking? -- View this message in context: http://www.nabble.com/Boost.Tests%3A-Unit-test-defines-own-main%28%29-funct… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 1

Re: [boost] Is there any interest in a template geometry library?
by artemp 17 Jan '08

17 Jan '08

Barend Gehrels wrote: > > Is there any interest in a template geometry library? > I'm very interested! --Artem http://mapnik.org -- View this message in context: http://www.nabble.com/Is-there-any-interest-in-a-template-geometry-library-… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

wave lexed_tokens sample gives an unexpected answer
by Leo Davis 17 Jan '08

17 Jan '08

Hello, I built the Wave preprocessing lib out of CVS head today using GCC 4.2.1 on Linux x86 box (openSUSE 10.3). I then built the lexed_tokens sample and ran it on the attached header file. The unexpected answer was how the 'defined' keyword was treated. I expected it to treat it as T_DEFINED, but it seems to return T_IDENTIFIER as shown by this output fragment: ... PP_IF (#370) at foo.h ( 4/ 1): >#if< SPACE (#393) at foo.h ( 4/ 4): > < IDENTIFIER (#381) at foo.h ( 4/ 5): >defined< SPACE (#393) at foo.h ( 4/12): > < IDENTIFIER (#381) at foo.h ( 4/13): >BAR< NEWLINE (#395) at foo.h ( 4/16): >\n< ... Leo #ifndef FOO_H #define FOO_H #if defined BAR #define BAZ #endif #endif /* FOO_H */

2 3

Globally Unique Identifier library by Andy Tompkins ?
by Janek Kozicki 16 Jan '08

16 Jan '08

Hello, I wasn't following boost development for about 8 months, now I'm slowly getting back on track (about 4000 unread emails had accumulated in my inbox, gotta look through them ;) I just looked at http://www.boost.org/more/formal_review_schedule.html and I didn't see any information about the mini review for Andy's library. Is it scheduled, was it already done, is it accepted? What's the status? best regards -- Janek Kozicki |

3 3

Re: [boost] Terminology:Type Unification? (was Re: RFC Generic data structure traversal / manipulation library
by dan marsden 16 Jan '08

16 Jan '08

Larry Evans wrote: >Page: > >http://spirit.sourceforge.net/dl_docs/traversal/html/traversal/quick_start_… > >contains a section titled: > >Type Unification > >however, it appears like what it describes is more like the stl's >accumulate or mpl's fold. Could you explain the reason for the >title and why a title using accumulate or fold wouldn't be >more intuitive to readers? The terminology is taken from the paper by Ren and Erwig, in the references section. I've borrowed a lot of the naming conventions and terminology from this paper. In the original there are 2 traversal types, type preserving which return a result of the same type as their input argument, and type unifying, which take all input types to the same (fixed) output type. In my library, I've currently replaced the type preserving traversals with inplace traversals, as C++ suits modification in place better than large amounts of copying. The 2 numbered points at the start of the Type Unification section attempt to explain this, but obviously this could be clearer. I'll have a look at rewording things. The operation is certainly not a fold, so I think it would be misleading to associate the example with fold like terminology. Cheers Dan ___________________________________________________________ Yahoo! Answers - Got a question? Someone out there knows the answer. Try it now. http://uk.answers.yahoo.com/

3 2

[utility] initialized_value - a convenience class for value_init.hpp
by Niels Dekker - mail address until 2008-12-31 16 Jan '08

16 Jan '08

For the convenience of the end users, I would like to add a little class to value_init.hpp, called initialized_value, having a conversion operator as its one and only member. Because it's just an extra feature of value_init, and Fernando Cacciola (the owner of value_init) already agrees that this class is a useful addition, I don't think an officially review of the class is necessary. But please tell me if you think otherwise. Details: The following syntax should initialize an object in a generic way, assuming that its type T is CopyConstructible: T obj1 = T(); Unfortunately this object may *not* be initialized properly, because of value-initialization related compiler issues of various C++ implementations, including MSVC, Borland, and GCC. (Boost ticket #1217, #1459, and #1491.) Fernando Cacciola and I have recently reimplemented boost::value_initialized, to work around those issues. (value_init.hpp, release branch, changeset [42501].) So the next release version of boost::value_initialized can be used to properly initialize an object, even in the presence of those compiler issues, as follows: T obj2 = get( value_initialized<T>() ); Still this way of initializing an object is rather verbose, and it has a form of code duplication, because it mentions the type of the object (T) twice. Within user code, the type may of course look more like Namespace::Template<Arg>::Type. Therefore I would like to add a class, boost::initialized_value, supporting the following: T obj3 = initialized_value(); The class would be implemented as follows: namespace boost { class initialized_value { public : template <class T> operator T() const { return get( value_initialized<T>() ); } }; } Its conversion operator would provide an appropriate value-initialized object for any CopyConstructible type T. Any comments are welcome. If it's okay, I would like to add it to the trunk version of value_init.hpp, next week. Kind regards, -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center

1 1

Re: [boost] [review] Fast track review of Boost.Utility/Singleton
by Tobias Schwinger 16 Jan '08

16 Jan '08

Nat, thanks for your very positive review. Nat Goodspeed wrote: > John Torjo wrote: > >> Today starts the formal Fast-Track review of the Boost.Utility/Singleton >> library. >> >> What to include in Review Comments >> ================================== >> >> Here are some questions you might want to answer in your review: >> >> * What is your evaluation of the design? > > Very strong. I like it! > I've implemented CRTP Singleton templates a few times before -- > highlighting the need for a Boost library. ;-) I'm pleased with the > deluxe functionality: >> * What is your evaluation of the documentation? > > Very clear, though not entirely complete, as described below. The > organization and style is excellent, and when polished, this > documentation will be exemplary. I like the examples. Pointing out the > ability to bind() instance and/or lease, and the semantics of each, is > great. Also the multiple-inheritance example to graft Singleton behavior > onto an existing class. > I didn't fully understand the thrust of the example described as: "We > might as well have a static facility use the Singleton internally, by > using non-public inheritance". A few more words about that example would > be useful; maybe a bit of the implementation of static void message(). I might have kept it so brief since I'm not too sure it's good practice. I think I'll better just remove it. > It appears that the third template parameter SubsystemTag was a > recent introduction. The documentation (especially the reference > material) doesn't describe it enough, and often fails to mention it > entirely. Yes. > The first paragraph under > http://torjo.com/tobias/index.html#boost_utility_singleton._singletons_and_… > seems to want to be a bullet list that got flowed instead. Yes. > Very little is said about BOOST_SINGLETON_PLACEMENT and > BOOST_SINGLETON_PLACEMENT_DECLARATION. The reference material mentions > them without any explanation. That "Singletons and dynamic libraries" section explains their purpose. What exactly is missing? I'm not too fond of specifying what those macros expand to and I don't really want to mention them in the introductory section either, as for me they are kind-of workarounds for the imperfect ABIs we have to deal with. > The example > http://torjo.com/tobias/index.html#boost_utility_singleton._singletons_and_… > appears to be inconsistent: shouldn't mylib_tag and library_tag be the > same, one way or the other? They should. My head must had been on vacation revising the docs. > Also, that example combines three different > mechanisms: BOOST_SINGLETON_PLACEMENT, destroy_singletons() and > SubsystemTag. More explanation of the role of each (why are we using > that mechanism here?), and how they interact -- or remain orthogonal -- > would clarify. Yes. Regards, Tobias

1 0

RFC Generic data structure traversal / manipulation library
by dan marsden 15 Jan '08

15 Jan '08

Hi All I'm posting an early version of a library for manipulating hierarchical data structures, for example the parse trees that are produced by Spirit2. The library enables traversals, and local modifications of complex data structures, without the need to implement large amounts of repetitive traversal code. The library is in a very early state, but has a pretty large introduction and quick start guide, which (hopefully) will help get people started with the library. Formal documentation is unfortunately non-existent at this point. The library is based on techniques from the Haskell community, links to relevant papers are provided in the documentation. The library is intended to play well with the rest of Boost, it already contains support for structures built with Boost.Optional and Boost.Variant, and Boost.Fusion, and will support other Boost libraries in future releases. The library makes heavy use of function objects, and is intended to work with Boost.Lambda, Phoenix, and other function object libraries in Boost. Online documentation can be found at: http://tinyurl.com/2eyjeh A gzip copy of the latest source is available for download at. http://tinyurl.com/2h2tb6 I've also detailed some of the directions that future implementations of the library make take. Any feedback gratefully accepted. Thanks Dan ___________________________________________________________ Yahoo! Answers - Got a question? Someone out there knows the answer. Try it now. http://uk.answers.yahoo.com/

6 9

[result_of][borland-5.9.2] BOOST_NO_RESULT_OF
by Jonathan Turkanis 15 Jan '08

15 Jan '08

Hi, I make one fairly modest use of result_of in Boost.Iostreams. My initial implementation included result_of.hpp and guarded the use of result_of with the macro BOOST_NO_RESULT_OF. I then discovered that Borland 5.9.2 and Borland 5.9.3 don't support result_of well enough for my needs, but that result_of.hpp header doesn't set BOOST_NO_RESULT_OF for these toolsets (since they supposedly support SFINAE). So I added checks for Borland version to the guard around result_of. This worked until yesterday. Now it seems that simply including the result_of header fails on Borland (see std_test_result_of_header: http://tinyurl.com/26umcr) I'd like to patch Iostreams as soon as possible, so I'm wondering whether this regression will be resolved by making the header includable by Borland or by marking std_test_result_of_header as an expected failure. It seems to me that result_of.hpp either has to be unconditionally includable, or BOOST_NO_RESULT_OF has to be defined in boost/config.hpp so I can tell whether to include it. If result_of is now really unusable on Borland (and if late model Borland really supports SFINAE), then it's no longer true that BOOST_NO_RESULT_OF is simply the disjunction of two existing config macros, and so it seems natural to define it in config.hpp instead of in result_of.hpp. (It could be defined in config/compiler/borland.hpp and also in config/suffix.hpp if BOOST_NO_SFINAE or BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION is defined.) Thanks, -- Jonathan Turkanis CodeRage http://www.coderage.com

1 1