June 2004 - Boost - lists.preview.boost.org

RE: [boost] Re: Documentation
by Reece Dunn 11 Jun '04

11 Jun '04

David Abrahams wrote: >"Reece Dunn" <msclrhd(a)hotmail.com> writes: > > David B. Held wrote: > >>If we're going to demand uniformity in licensing, should we also > >>demand more uniformity in documentation? > > > > I agree on this. At the moment, we have the docs written in HTML, > > those in BoostBook format (like Boost.Any and the BBv2 docs) and the > > Spirit docs which have their own format. > >And others; we used ReST for the iterator library. It should be fairly easy to adapt the ReST/SpiritDoc/whatever translation phase to generate BoostBook instead of HTML. > > As far as I understand it, the BoostBook tool is relatively new and > > has a learning curve, so it will take some time to migrate the docs to > > this format. > >And it requires writing in XML :-( or translating to it :-|. XML is essentially a stricter version of HTML. The main problem I see is porting the existing HTML-based docs to BoostBook. The others can be generated using a BoostBook generator (not sure how easy it will be for each format). I have a Spirit-based HTML parser that does basic correction (not as good as HTMLTidy) that is event based (like SAX for XML) and can be used to generate XHTML. It should be possible to adapt this to generate a BoostBook document that can be used as the basis for migrated docs. The SpiritDoc processor tool is freely available and should be easy to migrate to BoostBook output. Other generators can be produced for ReST, etc. NOTE: The output of these should be seen as a basis for the actual docs as they won't be able to properly detect things like the licence info, author name or library name/category; these will need to be edited by the document provider. (It all depends on how this information is encoded in the base text. If there is a markup pattern, then it should be possible to identify this and extract the information.) Let me know if I should take a look into seeing how feasible this is. Having a common document format will help maintain a consistent navigation/look. Also, it should be possible to generate frames as an alternate look by editing the BoostBook stylesheets and with a little wizardry it should be possible ot turn this on or off, depending on your preferences like it is currently possible to select Spirit or DocBook navigation styles. Regards, Reece _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/

2 1

feature request: file lock
by Jordi Vilar 11 Jun '04

11 Jun '04

Hi, I propose the inclussion of the following set of private members to the boost::filesystem::fstream class: private: void do_lock(); bool do_trylock(); bool do_timedlock(const xtime& xt); void do_unlock(); void do_lock(cv_state& state); void do_unlock(cv_state& state); this will enable additional classes: namespace boost { namespace filesystem { class scooped_lock; class scooped_try_lock; class scoped_timed_lock; } } with an interface like boost::thread::scooped_lock and sccoped_try_lock. What do you think about this? If you want to proceed and need help, please let me know, I can provide an implementation for Windows (NT and above) and posix (I'm currently working on this functionality). Cordially, Jordi Vilar

1 0

program_options and optional
by Neal D. Becker 11 Jun '04

11 Jun '04

Seems natural to use boost::optional with program_options. Has anyone tried this? For example, consider this: int main (int argc, char** argv) { namespace po = boost::program_options; optional<double> x; po::options_description desc("Allowed options"); desc.add_options() ("help", "produce help message") ("x", po::value<double>()->notifier (var(x)=_1)) ; To set the optional<double> x, this uses boost::lambda. Is there a more direct approach?

2 1

Re:[boost] [serialization18] conflict definition of "is_abstract" with type traits library(in cvs)
by Robert Ramey 11 Jun '04

11 Jun '04

Allen Yao wrote: > The file is_abstract.hpp in serialization18 and is_abstract.hpp in type > traits library (in cvs) have conflict definitions of "boost::is_abstract". > May Ramey fix this. For now, I just comment out the latter in order to use > serialization18. I am aware of this. serialization #18 is meant to be compatible with boost 1.31. >In addition, I am confused with the ".ipp" files in libs/serialization/src/ >in serialization18. It is strange to write >#include <libs/serialization/src/basic_binary_oprimitive.ipp> // for serialization18 >in user code instead of >#include <boost/serialization/basic_binary_oprimitive.ipp> // for serialization17 >I wonder why these files can not be just named ".hpp" It is my practice to distinguish between header files containing declarations to be included by "users" of the library (*.hpp) from function implementations (*.cpp) and template implementations (*.ipp). I moved the *.ipp files to the src directory because they seemed no need for library users to ever include them when building with the library. Since then it has occurred to me that they may be included when one makes a new archive when deriving from an existing one. Accordingly, these *.ipp files will be moved to boost/archive/impl in the next version. This system is helpful to me - I don't know what other peoples views are on this. > when will we see the serialization library in boost cvs, please? I have made changes to address all issues raised in the recent review. I'm now making changes to permit builds on all the compilers I have. I hope to upload a version compatible with 1.31 "real soon now". I will then build against my cvs tree. Then I will request authorization to check in. It will take a little time. Robert Ramey

1 0

MSVC 7.1 and BOOST_NO_MEMBER_TEMPLATE_FRIENDS
by Maxim Yegorushkin 11 Jun '04

11 Jun '04

I think the following condition in visualc.hpp is incorrect #if _MSC_VER <= 1310 # define BOOST_NO_MEMBER_TEMPLATE_FRIENDS #endif I've checked that MSVC 7.1 supports memeber template syntax. And, AFAIR, MSVC 7.0 supports it too, but I haven't got it to check. Should the condition for BOOST_NO_MEMBER_TEMPLATE_FRIENDS macro here and in other places in visualc.hpp be changed to #if _MSC_VER < 1300? Or am I missing something? -- Maxim Yegorushkin

2 1

Re: Some remarks on PP docs
by Vesa Karvonen 11 Jun '04

11 Jun '04

Dave Abrahams: >I am not even trying to cover the whole PP library in this appendix, >much less the topic of PP metaprogramming in general. [...] [...] >... but, thanks for the suggestions. I don't mean to sound >ungrateful, but I'm really trying to limit this to a small-scale >practical overview of the things you need to know in order to get >started with the PP library. I see your point, but... >"Understanding the preprocessor and PP metaprogramming" is beyond the >scope of the book. ...while understanding all the consequences of the PP design is obviously not necessary for basic PP metaprogramming, I think that it is almost impossible to be able to use the PP (and the Boost.PP library) profitably (beoyond trivial use of macros like ENUM_PARAMS and REPEAT) without having a fairly good understanding of the capabilities and limitations of the PP. -Vesa Karvonen _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail

2 1

RE: [boost] Geometric Algebra Library
by Johannes Brunen 11 Jun '04

11 Jun '04

Hi Jaap, fine to hear that you are still working on your GA library. I'm eager to see such a library in the boost pool. So I'm very interested in the library. One point however, Paul Leopardi is still working on GluCat and I have the impression that he is also targeting boost. It would be fine if you could bundle together your efforts in oder to get the best of each GA libraries. With best regards, Johannes

1 0

[serialization18] conflict definition of "is_abstract" with type traits library(in cvs)
by Allen Yao 11 Jun '04

11 Jun '04

The file is_abstract.hpp in serialization18 and is_abstract.hpp in type traits library (in cvs) have conflict definitions of "boost::is_abstract". May Ramey fix this. For now, I just comment out the latter in order to use serialization18. In addition, I am confused with the ".ipp" files in libs/serialization/src/ in serialization18. It is strange to write #include <libs/serialization/src/basic_binary_oprimitive.ipp> // for serialization18 in user code instead of #include <boost/serialization/basic_binary_oprimitive.ipp> // for serialization17 I wonder why these files can not be just named ".hpp" Ramey, when will we see the serialization library in boost cvs, please? Thank you:)

1 0

[thread] Thread specific pointer cleanup handlers
by Malcolm Noyes 11 Jun '04

11 Jun '04

During my 'research' into different ways to implement thread specfic storage (tss) on Win32, I needed to implement custom cleanup handlers. The thread_dev branch allows for a custom cleanup handler on the basis of 'one cleanup handler per global object instance'. This is *not* the same as 'one cleanup handler per tss object instance' since with tss there is of course one object instance per thread. Consider: void no_cleanup(int*) { // do nothing } thread_specific_ptr p(no_cleanup); int main(int, char*[]) { int some_number = 42; // leaving aside why someone might want to do this, it's // the mechanincs that we're interested in! p.reset(&some_number); // fine p.reset(new int(0)); // leak - 'p' has no cleanup! return 0; } The theoretical alternative would be to allow (enforce?) a different cleanup handler per thread object, e.g.: void no_cleanup(int*) { // do nothing } void delete_cleanup(int* pd) { delete pd; } thread_specific_ptr p; int main(int, char*[]) { int some_number = 42; // this time call reset with a specfic handler for this thread //object instance p.reset(&some_number, no_cleanup); // fine p.reset(new int(0), delete_cleanup); // ok now, will call delete return 0; } My feeling is that boost::thread should only allow the first form and document that the use above leads to unspecified behaviour (it may not be a memory leak, we don't know what the cleanup handler may do). My only reason for this however is that allowing the latter case is probably not a frequent use and makes the implementation much complicated. Does anyone think the latter is required ? Malcolm Malcolm Noyes

1 0

[Test] Linking
by David B. Held 11 Jun '04

11 Jun '04

What is the canonical way to link the Boost.Test library? Is it better to just include the sources in the project, or to try to link to a built library? Dave --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com) Version: 6.0.701 / Virus Database: 458 - Release Date: 6/7/2004

2 1