May 2005 - Boost - lists.preview.boost.org

[Review] Named parameters library
by Doug Gregor 10 Jul '05

10 Jul '05

The formal review of the Named Parameters library by David Abrahams and Daniel Wallin starts today and runs until Monday, November 22nd. The Named Parameters library provides a framework for writing functions that can accept arguments by name or by position. The use of named parameters can improve the readability of calls to these functions, especially when the functions have many parameters with default values. The Named Parameters library allows one to write a new_window function that allows a call such as: window* w = new_window("alert2", movable = true); The library is available in the Boost sandbox here: boost/named_params.hpp libs/utility And in the files area (login required): http://groups.yahoo.com/group/boost/files/named_params.zip Reviewers may wish to compare this solution to the named parameters already used by the Boost Graph Library, documented here: http://www.boost.org/libs/graph/doc/bgl_named_params.html Please send your reviews either to the Boost list or to me personally. The former is preferred, because it allows the community to consider your review as well. When writing your review, you may wish to consider the following questions (from http://www.boost.org/more/formal_review_process.htm#Comments) - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? As always, please remember to clearly state whether you believe the library should be accepted into Boost. Thank you Doug Gregor Review Manager, Named Parameters library

23 131

RE: [boost] Re: Customer Friendlier Boost Installation
by Martin Bonner 05 Jul '05

05 Jul '05

----Original Message---- From: Jason Earl [mailto:Jason@hybd.net] Sent: 25 May 2005 15:32 To: boost(a)lists.boost.org Subject: Re: [boost] Re: Customer Friendlier Boost Installation > I think a lot of Windows users are too used to things just working > out of the box, and give up if things don't work like that. If you change that to "A lot of Windows users are used to things just working out of the box, and give up if things don't work like that", you have it exactly right. What is wrong with such expectation? > > As for understanding what targets are etc, I think most developers > will know what targets are. I don't. If you use the Microsoft IDE, you never use the term. [snip] > Maybe it would be good to have some control over build verbosity > (there probably already is some, I just haven't looked yet), Maybe > logging the build info to a file would be better and then logging > errors, messages etc to the screen (and maybe a separate) log file. What people REALLY want, is to download headers + pre-built binaries. If they can't have that, then next best is a pretty gui which asks them all the questions (with the right defaults), and just works. If they can't have that, then really good documentation is required, and I don't think boost is there yet. -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

14 38

RE: [boost] Re: Customer Friendlier Boost Installation
by Brian Braatz 05 Jul '05

05 Jul '05

Wild thought- Is there a rational way to have a "environment" checker. I am NOT a bjam expert- but it would be handy if we had some cmd line program that would follow spit out all the info BJAM looks for and finds. I am slightly half cocked in this idea, but basically it would have to be enough information that you could get a better sense for what Bjam was doing Something like C:\boost\> boostenvcheck.exe ** Enviroment Report** Python is not in the path User-config.jam file is setup to use gcc, vc7.1 Etc.... I have been using boost for (has it been that long) 2 years now. Bjam still confounds me. ( I appreciate the work effort, it is a cool tool, I remain struggling with it though) (I am also a tad frustrated because I have been trying to make vc7.1 build wave for the last 5 hours) Semi-Related: I proposed (a long time ago) building a SIMPLE gui framework- with the core elements, and then making a "boost environment checker" out of that- I.e. imagine a tree control with all the types of settings and what nots, and the ability to navigate this gui to try to determine what is not set correctly. > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Lars Gullik Bjønnes > Sent: Thursday, May 26, 2005 3:27 AM > To: boost(a)lists.boost.org > Subject: [boost] Re: Customer Friendlier Boost Installation > > "Hendrik Schober" <SpamTrap(a)gmx.de> writes: > > | Lars Gullik Bjønnes <larsbj(a)gullik.net> wrote: > >> David Abrahams <dave(a)boost-consulting.com> writes: > >> > >> | We never wanted to be the sole province of experts. We always wanted > >> | widespread usage. If you want to be a member of an exclusive > >> | "experts" club this is the wrong place to find it. > >> > >> Sure. But there, imho, must be a difference expected between _users_ > >> of the libraries, and _installers_ (or packagers) of the libraries. > > > > > | How so? Shall people employ an administrator to > | install the libs they want to check out? > > No. But IMHO it should be expect that it is a bit harder to install > (and in this case it is build as well) the library than use it. > > So: Create an windows installer and then the user can use that. > > -- > Lgb > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

7 13

Formal Review: Typeof
by Andy Little 02 Jul '05

02 Jul '05

The formal review of Arkadiy Vertleyb and Peder Holt's Typeof library begins today, May 20th 2005. The review period will continue until the 30th of May. The proposed Typeof library emulates the functionality of the non-standard 'typeof' operator, and incomplete implementations of decltype and the proposed 'auto' declarator , described in http://www.osl.iu.edu/~jajarvi/publications/papers/decltype_n1478.pdf. It is commonly acknowledged that this type of functionality is sorely needed and should be standardardised in the language. For compliant compilers the library requires some help in the form of registration macros but, because use of typeof is by its nature most likely in generic libraries, it is expected that this can often be done by the library author rather than the user. In some cases the compilers capabilities (by means of extensions and even compiler bugs) have been used to remove the need for registration. However, for portability and in order to test emulation mode on the compilers where it is available but not used by default (VC7.1, GCC etc), #define BOOST_TYPEOF_COMPLIANT [see note *1*]. Testing the emulation is useful, even on compilers that provide a better option, to get a rounded view of the library and its capabilities. I hope you will find time to write a review of the library, which is available at: http://boost-sandbox.sourceforge.net/vault/ , typeof.zip The system has been tested with the following compilers: MSVC 6.5/7.0/7.1/8.0; [see note *1* regarding VC7.0 and VC6.5] GCC 3.4.2 (The following is a quote from : http://www.boost.org/more/formal_review_process.htm ) Here are some questions you might want to answer in your review: What is your evaluation of the design? What is your evaluation of the implementation? What is your evaluation of the documentation? What is your evaluation of the potential usefulness of the library? Did you try to use the library? With what compiler? Did you have any problems? How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Are you knowledgeable about the problem domain? And finally, every review should answer this question: Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Andy Little Typeof review manager notes: *1* MSVC6.5 and VC7.0 are not supported by the BOOST_TYPEOF_COMPLIANT macro

9 43

[serialization] Regressions?
by Vladimir Prus 01 Jul '05

01 Jul '05

Hi Robert, I've just updated by Boost tree and run in a number of compile errors. One is pretty easy -- I've committed the attached trivial patch to split_member.hpp. Another is this: ....boost/boost/archive/detail/oserializer.hpp:551: error: incomplete type `boost::STATIC_ASSERTION_FAILURE<false>' does not have member `value' instantiated from this code of mine: ofstream ofs(av[2]); boost::archive::binary_oarchive oa(ofs); oa << *data_builder.finish(); Where 'finish' returns auto_ptr<Data>. It's looks like serialization checks if the serialized type is 'const' and if not, complains. Basically, it's some heuritic to prevent saving on-stack object (though I don't understand why it would work at al). I find this a bit too much . I have no reason whatsoever to make 'finish' return auto_ptr<const Data>. And writing oa << const_cast<const Data&>(*data_builder.finish()); looks very strange. And modifying all places where I get this error is not nice too. So, can this static assert be removed? Then, I get ambiguity in iserializer.hpp, in this code: #ifndef BOOST_NO_FUNCTION_TEMPLATE_ORDERING template<class Archive, class T> inline void load(Archive &ar, const serialization::nvp<T> &t){ load(ar, const_cast<serialization::nvp<T> &>(t)); } For some reason, both boost::archive::load and some other 'load' in 'boost' namespace (part of earlier serialization lib) that I still use are considered overload candidates. Adding explicit boost::archive:: fixes this. See attached patch. Then I get error at this code: ar << boost::lexical_cast<std::string>(*this); The error message is: error: no match for 'operator<<' in 'ar << boost::lexical_cast(Source) [with Target = std::basic_string<char, std::char_traits<char>, std::allocator<char> >, Source = lvk::nm_model::BlockFormula]()' /space/NM/boost/boost/archive/detail/interface_oarchive.hpp:75: error: candidates are: Archive& boost::archive::detail::interface_oarchive<Archive>::operator<<(T&) [with T = std::basic_string<char, std::char_traits<char>, std::allocator<char> >, Archive = boost::archive::binary_oarchive] ...unrelated operator<< definitions snipped... Apparently, passing rvalue to "T&" does not work. Yes another attached patch fixes this issue. - Volodya

9 73

[filesystem] i18n branch committed to CVS
by Beman Dawes 26 Jun '05

26 Jun '05

CVS now contains a branch "i18n" of the filesystem directories: * Class templates basic_path, basic_directory_iterator, etc, support narrow, wide, and user-defined path types. Typedefs path, directory_iterator, etc, are provided, so most existing code continues to work. * Name checking has been moved out of class basic_path, so it no longer gets in the way of those not using the name checking facility. Deprecated versions of various functions are provided to preserve existing code. * The need to explicitly identify native format paths via special constructors has been eliminated, simplifying casual use of the library. Deprecated versions of those constructors are provided to preserve existing code. More detailed documentation is available in the i18n CVS branch at <boost-root>/libs/filesystem/doc/i18n.html. Most of the other documentation has also been updated to reflect the changes. Current issues with the i18n branch include: * Testing has been limited to Intel 8.1, Metrowerks 9.3, and Microsoft 7.1 on Windows, and GCC 3.3 on Mac OS X. How much effort to put into broken compilers is going to be a real issue - internationalization may have to be disabled, and that is a lot of work. * Some tests (particularly in operations_test.cpp) are commented out. Minor issues need to be resolved and the tests reactivated. * Two or three of the less important doc files haven't been updated yet. * The convenience header and source code hasn't been converted yet. * The UTF-8 conversion facet header and source is duplicated. Need to identify and fix the issues that prevented the boost/detail version from being used. * The "// TODO" notes in the code need to be revisited, issues fixed, and the notes eliminated. * Testing on Windows 9X would be helpful, and issues fixed or documented. * Backed up issues and patches from the mailing list need to be addressed. * Windows tests need to be run on a FAT filesystem to see what issues arise. All of the Windows analysis and design effort so far has gone into NTFS, so there may be critical problems with filesystems that only support narrow paths. * The POSIX wpath implementation assumes that UTF-8 is always the operating system's preferred external path encoding. If any Boost users are concerned about other encodings, please let me know. * A timing test is needed, particularly for directory iteration. There is concern over excessive copying by basic_path conversion functions, so need to test if speed is a real problem in a realistic application. Any comments would be appreciated (but please look at the docs first, as a lot of effort went into rationale and trying to answer anticipated questions). My plan is to pause development for a while, both to allow time for comments to be made, and also so I can attack a backlog of non-Boost work that has been building up. --Beman

3 12

[Signals] Recursive callback design questions, including socket multiplexor implementation example
by Cliff Green 22 Jun '05

22 Jun '05

I have a socket multiplexor library, with a fundamental design question relating to Boost.Signals. My current implementation is flawed, and I'm considering replacing the flawed code with Boost.Signals (that is, when the performance and multi-threading issues have been addressed). Consider the following pseudo-code (ignores lots of details and is obviously not compilable - however, I do have real working code similar to this example): class Msg { ... }; class SocketStream { void sendMsg(Msg); // ... }; class Multiplexor; // forward declaration typedef boost:function<void (Msg&, Multiplexor&, SocketStream&)> IncomingMsgCallback; class Multiplexor { void registerIncomingMsgCallback (IncomingMsgCallback); void unregisterIncomingMsgCallback (IncomingMsgCallback); // ... }; A Multiplexor object has a container of callback "IncomingMsgCallback") objects which are invoked whenever an incoming message is received on a socket stream. Within the callback, a "context" is provided (reference to the enclosing Multiplexor object) for performance and ease of use. (Even if this particular callback interface did not provide a Multiplexor context, nothing would prevent the application from storing one in the callback object itself.) From within the callback invocation, additional callback objects may be registered or unregistered. (This is actually a fairly common use case - the registration of callback functionality implements application state machines, which are transitioned based on incoming messages.) The design issue is that modifying the callback container from within the callback invocation (i.e. calling "registerIncomingMsgCallback") requires some tricky guarding and managing of the internal callback container. In effect, register and unregister requests are placed on a queue, and then applied when events (messages) are not causing the callbacks to be invoked. I've found that I've duplicated this code in multiple places (primarily because there are multiple types of callbacks - e.g. incoming msg callbacks, outgoing msg callbacks, connection monitoring callbacks, periodic invocation callbacks, etc). This is Not Good, and not yet) generic. Does Boost.Signals directly address this type of use case? I've read the tutorial and examples many times, and it's still not clear to me if it does (that may be due to my understanding versus the documentation itself). Is the trackable functionality meant to address this type of use? If not, has this kind of usage been considered as relevant or desirable for Signals? I'm willing to help enhance, within the constraints of my available time. If Boost.Signals should not support this type of usage (i.e. modifying the signal, indirectly, from within a connected slot), is it worthwhile to create a generic container to support this functionality? Or are my assumptions and approaches way off base, and I should be considering other alternatives? (I haven't described every possibility that I considered during design ...) Thoughts and comments are greatly appreciated! Cliff

2 1

Quite destructive Boost comments
by Tony Juricic 15 Jun '05

15 Jun '05

Reading the latest SR1 proposal to C++ standard, explained in recent article by some Google corporate entity, I could not but feel sad: Here we have corporate advertisers, pretending to be open source developers, defending half-assed, miniscule additions to C++ standards as a big improvenent. Shame to Google and Boost and C++ standards commitee. IMO, you deserve as much respect as Microsoft corporate develpoers. Tony

5 4

copy_on_write
by Maksym Motornyy 14 Jun '05

14 Jun '05

Hello All, I know that my idea is trivial but this thing is missing in Boost. In some cases it is useful to have copy-on-write objects. For example, everybody knows that returning std::string from a function is not very efficient (actually that's why in Qt strings are implemented as copy-on-write ones). Consider following code: copy_on_write< std::string > concatenate( const std::string &first, const std::string &second ) { copy_on_write< std::string > result; result->assign( first ); result->append( second ); return result; } // somewhere else std::cout << *concatenate( "Hello,", " world!" ) << std::endl; Here no string copy occurs. One can invent a lot of different applications of copy-on-write techinque (strings, iterators, memory pages). I have an implementation, now let community decide if this can be a part of Boost. Sincerely yours, Maksym Motornyy.

12 32

logging library - v1.3.3
by John Torjo 13 Jun '05

13 Jun '05

Hi all, Just included the nifty appenders from Caleb, and made some small fixes. Enjoy! http://torjo.com/code/logging-v133.zip Best, John -- John Torjo, Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -v1.6.3 (Resource Splitter) -- http://www.torjo.com/cb/ - Click, Build, Run!

2 2