- Boost - lists.boost.org

Re: [boost] [quickbook] [MPL] Knowing where you are the wrong way
by Joel de Guzman 22 Mar '06

22 Mar '06

Daryle Walker wrote: > [I've added the main Boost list to this response so the MPL guys can see > it.] > > On 3/16/06 5:46 AM, "Joel de Guzman" <joel(a)boost-consulting.com> wrote: > > >>In the link I presented a while ago (http://snipurl.com/no8s) >>you might have noticed that the headings are clickable. >>Headings now link to itself. Again, this is borrowed from >>the MPL docs. This allows you to right click and copy >>the URL, for example (especially useful in deeply nested >>sections). You know where you are, anywhere. > > So my final advice is to remove this mis-feature, and have the MPL docs > purge it too. Good points! Thanks for taking the trouble to explain in detail. Makes perfect sense, IMO. Anyway, I am curious as to how the MPL folks would think? IIRC, the MPL docs was written using ReST(?). Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

3 2

Re: [boost] [quickbook] [MPL] Knowing where you are the wrong way
by David Abrahams 22 Mar '06

22 Mar '06

Joel de Guzman <joel(a)boost-consulting.com> writes: >> That's what you have to do, neh? You click once to get to the TOC, >> then you right-click the link at the top of the page. > > Tedious and possibly error prone, IMO ;) I should add that it could only be considered tedious and error-prone from the POV of someone who wants to provide a link to the section. For the ordinary browsing user, who wants to see where in the overall outline of the document he is currently, the no-op link is *definitely* tedious: it doesn't do anything! It's also confusing, of course. I think serving the ordinary browsing user is much more important than serving the guy who wants to provide a link to the section, especially if the difference is just one click. -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

Re: [boost] [quickbook] [MPL] Knowing where you are the wrong way
by David Abrahams 22 Mar '06

22 Mar '06

Joel de Guzman <joel(a)boost-consulting.com> writes: > David Abrahams wrote: >> Joel de Guzman <joel(a)boost-consulting.com> writes: >> >>>It is very useful indeed. I can attest to that. It's very useful for >>>me when I have to provide someone with information. I can simply >>>right click and grab the URL of the specific section I wish to >>> share. >> >> How does right clicking help? If you go to >> http://www.boost.org/libs/parameter/doc/html/index.html#portability-conside… >> and right click you can copy a link to >> http://www.boost.org/libs/parameter/doc/html/index.html#id45. > > Aha! The way I did it with quickbook, you can have the exact link. > Try it here: http://tinyurl.com/rlqz8. Try to right click > a heading. The URL is exactly what you get copied. Well. Those headings do have the no-op problem that Daryle mentioned and I think that's problematic. When you said that you borrowed the idiom from the docutils-generated docs and that it "helps you know where you are" I assumed that you were doing the same thing as the docutils links, which take you exactly to the location in the TOC that links to the section header. That gives you useful context, rather than simply making it possible to copy a link. >>>The alternative would be to go back to the table of contents >>> and grab the link there. >> >> That's what you have to do, neh? You click once to get to the TOC, >> then you right-click the link at the top of the page. > > Tedious and possibly error prone, IMO ;) Works beautifully for me. The link to copy is exactly at the top of the window. I've never made a mistake with it. > How's that any different from just clicking the "Up" link? Try it; you'll see. -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

Re: [boost] [quickbook] [MPL] Knowing where you are the wrong way
by David Abrahams 21 Mar '06

21 Mar '06

Joel de Guzman <joel(a)boost-consulting.com> writes: > David Abrahams wrote: >> Joel de Guzman <joel(a)boost-consulting.com> writes: >> >>>Date: Wed, 22 Mar 2006 02:04:02 +0800 >>>Reply-To: boost(a)lists.boost.org >>> >>>Daryle Walker wrote: >>> >>>>[I've added the main Boost list to this response so the MPL guys can see >>>>it.] >>>> >>>>On 3/16/06 5:46 AM, "Joel de Guzman" <joel(a)boost-consulting.com> wrote: >>>> >>>> >>>> >>>>>In the link I presented a while ago (http://snipurl.com/no8s) >>>>>you might have noticed that the headings are clickable. >>>>>Headings now link to itself. Again, this is borrowed from >>>>>the MPL docs. This allows you to right click and copy >>>>>the URL, for example (especially useful in deeply nested >>>>>sections). You know where you are, anywhere. >>>> >>>>So my final advice is to remove this mis-feature, and have the MPL docs >>>>purge it too. >>> >>>Good points! Thanks for taking the trouble to explain in detail. >>> Makes perfect sense, IMO. >> Not to me. Despite what Daryle says, the feature hurts nobody (or >> at >> least he hasn't explained why it hurts anyone), and once you discover >> it's there, it's very useful. If there were a more explicit way to >> implement those links without interfering with presentation, I might >> go for it, but I don't have any brilliant ideas and nobody else has >> offered any so for now, that's the best we can do. > > It is very useful indeed. I can attest to that. It's very useful for > me when I have to provide someone with information. I can simply > right click and grab the URL of the specific section I wish to > share. How does right clicking help? If you go to http://www.boost.org/libs/parameter/doc/html/index.html#portability-conside… and right click you can copy a link to http://www.boost.org/libs/parameter/doc/html/index.html#id45. > The alternative would be to go back to the table of contents > and grab the link there. That's what you have to do, neh? You click once to get to the TOC, then you right-click the link at the top of the page. -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

[test] msvc problems with user-testcase, shared_ptr and quick allocator
by Juergen Hunold 21 Mar '06

21 Mar '06

Hi ! I've been playing around with boost test and tried to run my test on my win32 box (after a needed hardware upgrade and reinstall) using msvc 7.1. To my surprise the tests don't run anymore. I've tracked this down to the attached minimal testcase (using V2). I admit that my setup is somewhat unusual, but now for the story: I use: - a user defined testcase ( to set up a lot of things in my tests, omitted here.) - our project uses BOOST_SP_USE_QUICK_ALLOCATOR to speed up shared_ptr. (proven to boost performance by 50%) - is multithreaded. When running the testcase, the test runs smooth, but then the msvc debug-runtime bombs at program exit and fires up the debugger. It claims it has detected a memory leak. The start of the message (see result.txt in attachment for full output): ====== BEGIN OUTPUT ====== Running 2 test cases... user_testcase.cpp(27): error in "Tests::testFailure": failure *** No errors detected Detected memory leaks! Dumping objects -> {173} normal block at 0x00326030, 12 bytes long. Data: <0`2 0`2 > 30 60 32 00 30 60 32 00 CD CD CD CD The cause seems to be some static variables in the quick allocator that are not deleted at program exit. I think this a known issue. I've tried to disable the msvc runtime check but it failed. Using the debugger I've traced this down to boost/test/impl/execution_monitor.ipp and there to detect_memory_leaks (line 623). It seems that the call to _CrtSetDbgFlag in line 629 is somehow failing. Myself being a linux programmer my wisdom ends at this point. This could even be a red herring and the failure might be caused by something else. Query: Can someone reproduce this ? Query: Is this a bug in boost.test, boost.shared_ptr or my fault ? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * hunold(a)ive-mbh.de ! www.ive-mbh.de

2 2

Repost: [inspect] Bug report: Terminates with std::out_of_rangeexception
by Andreas Huber 21 Mar '06

21 Mar '06

Hi there The following was posted a week ago: > When I run the inspect tool in boost/libs/statechart (current CVS) I > always get a std::out_of_range exception: > > **** exception(205): std::out_of_range: basic_string::substr > ******** errors detected; see standard output for details ******** > > I tried with vc-7_1 and mingw builds, both with the same result. Does > this ring a bell or should I investigate further? Is this already known and a fix in the works? If the author (Beman Dawes ?) doesn't have time to investigate this, I'd happily give it a try. Thanks & Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.

1 0

[Boost-bugs] [ boost-Bugs-1455604 ] regex_replace bug
by SourceForge.net 21 Mar '06

21 Mar '06

Bugs item #1455604, was opened at 2006-03-21 11:31 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1455604&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: regex Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: John Maddock (johnmaddock) Summary: regex_replace bug Initial Comment: boost::tregex e("(.*)"); strResult = boost::regex_replace("a", e, "$1b"); strResult now equals "abb", but should be "ab". My e-mail: kdn01003(a)student.mdh.se ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1455604&group_… ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Boost-docs] [quickbook] [MPL] Knowing where you are the wrong way (was: Re: know where you are)
by Daryle Walker 21 Mar '06

21 Mar '06

[I've added the main Boost list to this response so the MPL guys can see it.] On 3/16/06 5:46 AM, "Joel de Guzman" <joel(a)boost-consulting.com> wrote: > In the link I presented a while ago (http://snipurl.com/no8s) > you might have noticed that the headings are clickable. > Headings now link to itself. Again, this is borrowed from > the MPL docs. This allows you to right click and copy > the URL, for example (especially useful in deeply nested > sections). You know where you are, anywhere. [That URL is <http://spirit.sourceforge.net/dl_docs/quickbook_doc/quickbook/doc/html/quic kbook/intro.html>, BTW. Check out the first word "Introduction" right before the quote for the link Joel is talking about.] I've read on some web design website that this is horrible UI. This is a feature that may be "kewl" for very advanced users, but it's obscure for above-average users, and detrimental to anyone else. 1. This word is an out-link without looking like an out-link. We shouldn't be presenting data like Easter egg hunts. You could counter by saying that the disguise is a good thing to dissuade newbies, but then how could oldbies discover it without looking at the source, scrubbing the page, or reading this e-mail? (It's a variant of guideline #3 at <http://www.useit.com/alertbox/20031110.html>.) 2. Out-links to the same page is confusing to newbies. They'll think "my link click failed," not "it's a mnemonic for my browser's 'copy URL link' contextual-menu function." (It's based on guideline #10 from the web page I mentioned in [1].) 3. You implemented it as: <a name="quickbook.intro"></a><a href="intro.html" title="Introduction">Introduction</a> As I said before, using an empty "<a name>" as an in-link is a bad idea. You need to associate the link with something. AFAIK, nothing prevents an anchor from being an in- and out-link simultaneously: <a href="intro.html" name="quickbook.intro" title="Introduction">Introduction</a> If you don't care about anything before HTML-4, you can use the "id" attribute to mark destinations. (That's why it shares the same namespace as the "name" attribute.) <h2 id="quickbook.intro">Introduction</h2> So my final advice is to remove this mis-feature, and have the MPL docs purge it too. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

1 0

[Serialization] xml_archive version
by Richard Crossley 21 Mar '06

21 Mar '06

Hi, I'm trying to read in a xml_archive created by a previous version of the serialization library (version="3") with the version from CVS head (version="4"). The reading fails in load_collection here as there is no "item_version" field. if(3 < ar. get_library_version ()){ ar >> BOOST_SERIALIZATION_NVP(item_version); } Shouldn't a xml_archive be doing a set_library_version() based on the version of the archive it's reading, or am I missing something? Regards, Richard.

2 1

[Wave][Serialization] Problems with class versioning
by Hartmut Kaiser 21 Mar '06

21 Mar '06

Hi all, I was trying to add class versioning to the serialization code for the Wave library (for storing macro tables et.al.) but couldn't succeed. I've added a class version to the code by adding: namespace boost { namespace serialization { template< typename Iterator, typename LexIterator, typename InputPolicy, typename Hooks > struct version<boost::wave::context<Iterator, LexIterator, InputPolicy, Hooks> > { typedef boost::wave::context<Iterator, LexIterator, InputPolicy, Hooks> target_type; typedef mpl::int_<target_type::version> type; // version == 0x100 typedef mpl::integral_c_tag tag; BOOST_STATIC_CONSTANT(unsigned int, value = version::type::value); }; }} // namespace boost::serialization The save function of the context<> now get's called during serialization with the correct version value. But during load the context<>::load function still get's passed zero as the loaded version. Is this a known behaviour, am I ding something wrong (perhaps essential: context is explicitely marked as 'track_never')? Regards Hartmut

2 2