March 2006 - Boost - lists.preview.boost.org

[Boost-bugs] [ boost-Bugs-1450260 ] boost::format and empty string crash in MSVC 8.0
by SourceForge.net 22 Mar '06

22 Mar '06

Bugs item #1450260, was opened at 2006-03-15 12:21 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=1450260&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: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Adal Chiriliuc (adalx) Assigned to: Nobody/Anonymous (nobody) Summary: boost::format and empty string crash in MSVC 8.0 Initial Comment: std::string x; cout << boost::format("%s") % x; MSVC 8.0 will assert because of a NULL pointer. This was also reported here with details: http://lists.boost.org/Archives/boost/2006/01/99194.php ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1450260&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

2 1

boost::variant - ambiguity in boost::variant source code I cannot disambiguate
by Peter Schregle 22 Mar '06

22 Mar '06

Hi, I cannot figure out, why the following little program does not compile. It simply typedefs a variant of a specific bounded type set and then derives a class from this type. I've tried to compile it with VC 2005. It does not compile because of ambiguous overloads within the boost::variant source. It would be very helpful if somebody could shed light on the issue. Best regards Peter PS: I intended to post this to the boost developers list, but I was unable to log onto the list today. ************************************************************* #include <boost/variant.hpp> typedef boost::variant<char, int, double> numeric_type_variant; class numeric_type : public numeric_type_variant { public: /// Default constructor. numeric_type() : numeric_type_variant() { } template <typename T> /// Converting constructor. numeric_type(T const& t) : numeric_type_variant(t) { } // some more code }; int main(int argc, char* argv[]) { char ba; int bb; double bc; numeric_type a; numeric_type b(ba); numeric_type c(bb); numeric_type d(bc); a = ba; a = bb; a = bc; return 0; } ************************************************************* This is the build log: ------ Build started: Project: test_variant, Configuration: Debug Win32 ------ Compiling... test_variant.cpp c:\_ngi\toolkits\boost_1_33_1\boost\variant\variant.hpp(1342) : error C2666: 'boost::variant<T0_,T1,T2>::convert_construct' : 2 overloads have similar conversions with [ T0_=char, T1=int, T2=double ] c:\_ngi\toolkits\boost_1_33_1\boost\variant\variant.hpp(1327): could be 'void boost::variant<T0_,T1,T2>::convert_construct<char,int,double,boost::detail:: variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,b oost::detail::variant::void_,boost::detail::variant::void_,boost::detail::va riant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boo st::detail::variant::void_,boost::detail::variant::void_,boost::detail::vari ant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost ::detail::variant::void_,boost::detail::variant::void_,boost::detail::varian t::void_,boost::detail::variant::void_>(const boost::variant<T0_,T1,T2> &,long)' with [ T0_=char, T1=int, T2=double ] c:\_ngi\toolkits\boost_1_33_1\boost\variant\variant.hpp(1258): or 'void boost::variant<T0_,T1,T2>::convert_construct<const T>(T &,int,boost::mpl::false_)' with [ T0_=char, T1=int, T2=double, T=numeric_type ] while trying to match the argument list '(const numeric_type, long)' c:\_ngi\toolkits\boost_1_33_1\boost\variant\variant.hpp(1580) : see reference to function template instantiation 'boost::variant<T0_,T1,T2>::variant<T>(const T &)' being compiled with [ T0_=char, T1=int, T2=double, T=numeric_type ] c:\_ngi\toolkits\boost_1_33_1\boost\variant\variant.hpp(1590) : see reference to function template instantiation 'void boost::variant<T0_,T1,T2>::assign<T>(const T &)' being compiled with [ T0_=char, T1=int, T2=double, T=numeric_type ] c:\_schrott\test_variant\test_variant\test_variant.cpp(36) : see reference to function template instantiation 'boost::variant<T0_,T1,T2> &boost::variant<T0_,T1,T2>::operator =<numeric_type>(const T &)' being compiled with [ T0_=char, T1=int, T2=double, T=numeric_type ] Build log was saved at "file://c:\_schrott\test_variant\test_variant\Debug\BuildLog.htm" test_variant - 1 error(s), 0 warning(s) ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

1 0

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

22 Mar '06

Daryle Walker <darylew(a)hotmail.com> writes: > [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. Why is "some web design website" an arbiter of good 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. I'm a below-average or middling web user and for me it has nothing to do with "kewlness." Once I discovered the feature I considered it useful. > 1. This word is an out-link without looking like an out-link. What's 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>.) It's useful if you discover it, but non-crucial, so it doesn't matter if you don't discover it. Coloring the text like a link would hurt overall readability of the page, which is more important than discovering this back-link. Furthermore, I don't see any relation to guideline #3 there: 3. Use color to distinguish visited and unvisited links This is about whether you can tell it's a link at all in the first place. > 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 isn't a memnonic for that. Did you even try clicking it? It links back to the TOC entry that links to the heading, so you can see the context you're in. I suppose Jonathan Turkanis' menu control might be able to solve the same problem, but apparently we're not ready to use that everywhere, yet. Why do you think newbies will consider their link click to have failed? > (It's based on guideline #10 from the web page I > mentioned in [1].) That guideline is useless because it precludes putting a linked TOC on the page. The rationale is wrong as long as the page is too large to fit on the screen all at once. -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 2

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

22 Mar '06

Daryle Walker <darylew(a)hotmail.com> writes: > On 3/21/06 2:03 PM, "David Abrahams" <dave(a)boost-consulting.com> 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. > > You don't implement the feature at all, just read the URL from the browser's > input/status line for copy & paste. The feature doesn't add anything the > the user couldn't already do, Unless you have been very unclear (which is what I assume you meant by saying that Joel and I have "confused ourselves"), it certainly does. It provides a way to find a direct link to the subsection header. When I've had to do that with other pages I often find myself viewing the page source to see if there's an <a name="..."> tag I can use, which is terrible. If you use the original docutils semantics, it also provides a way to see where you are in the TOC in context. -- 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: >> 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? > > Ok, agreed. I'll follow that behavior. While Daryle has > good points, unless they are backed up by actual usability > studies, it will be just a matter of perception. Not sure what you're agreeing to, here. -- 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: >> >>>>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. > > Not exactly true. In fact it benefits the one who will use the link > more than the one who does the link. First, let me say that indeed > the MPL docs, as far as headings are concerned, does it the same > way as QuickBook. Then you must be looking at a different set of MPL docs than I am. Or you're using a different browser, that acts completely differently from all the browsers I've used. For example, the "Terminology" heading at http://www.boost.org/libs/mpl/doc/refmanual/terminology.html links back to http://www.boost.org/libs/mpl/doc/refmanual.html#id529, which is an entry in the top-level TOC of the refmanual. The fact that many of the pages are broken up in such a fine-grained way may make it hard to see that it's doing exactly the same thing as the other docutils-generated docs, because you don't see the page scrolled to show the TOC entry right at the top of the screen when the pages are small. I guess it would be a lot better if the links went back into http://www.boost.org/libs/mpl/doc/refmanual/refmanual_toc.html rather than up a level into the fine-grained pages. > In my other post, I posed a usage scenario. I'll repeat parts of it > here for reference. > > Anyway, imagine I have a doc that links to the "Invariants" section > of the MPL doc's "ForwardSequence" concept at > http://tinyurl.com/omouw. Okay, that link works differently from the other ones I've seen. I guess I don't understand the logic in use here. Aleksey must have made some interesting choices when he built the docutils backend that generates multi-page documents. > Thanks to the self links of headings in the MPL docs, I can know > the exact location. For reference it is at: > > http://www.boost.org/libs/mpl/doc/refmanual/forward-sequence.html#invariants > > AFAICT, there is no way to know that if the heading itself is > not self linked. Sure there is. You click the link, which takes you to a page with a TOC entry that points to the heading. Then you right-click the TOC entry and copy the link location. > The only way is to link to the page and say, "ok, please go to > link http://tinyurl.com/omouw and see section Invariants." How > usable is that? The user will have to search a potentially long > page for the particular /Invariants/ section. 1) Imagine if the > page is long. 2) What if there are more than one /Invariants/ > in various sub-sections? Yes, it's a useful tool. I just think it's worth one more click from you in order to make the link generally useful for browsing users. -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

[multi_index] Warnings with level 4 on Microsoft compiler
by Alexei Alexandrov 22 Mar '06

22 Mar '06

I compile my program which uses Boost.multi_index and get some obscure warnings. It would be great if the library maintainer could disable them in the source code - it is really annoying and I would like to bracker my #include <boost/...> with #pragma-s. The warnings are: boost\multi_index\detail\hash_index_node.hpp(89) : warning C4610: struct 'boost::multi_index::detail::hashed_index_node_trampoline<Super>' can never be instantiated - user defined constructor required boost\multi_index\composite_key.hpp(570) : warning C4512: 'boost::multi_index::composite_key_result<CompositeKey>' : assignment operator could not be generated boost\multi_index\detail\bucket_array.hpp(152) : warning C4512: 'boost::multi_index::detail::bucket_array<Allocator>' : assignment operator could not be generated The line numbers are against 1.33.1 release.

2 6

[date-time][format][regex][range][tokenizer] Re: 1.33.1 Bugs, With Patches
by Stephan T. Lavavej 22 Mar '06

22 Mar '06

[David Abrahams] > Please always put the relevant library names in the subject > line. Gotcha. I've been out of the loop for a while. [Jeff Garland] > I've applied a modified form of your patches to CVS for the > date_time files. Thanks! Can the appropriate maintainers look at my patches for the following files? (Original message, with patches, is here: http://lists.boost.org/Archives/boost/2006/03/102185.php ) [format] boost/format/format_implementation.hpp [regex] boost/regex/v4/basic_regex_creator.hpp boost/regex/v4/match_results.hpp boost/regex/v4/basic_regex_parser.hpp libs/regex/build/gcc_gen.sh The generated gcc.mak [range] boost/range/detail/implementation_help.hpp [tokenizer] boost/token_iterator.hpp Stephan T. Lavavej

2 1

Re: [boost] [Boost-docs] [quickbook] [MPL] Knowing where you are the wrong way
by Daryle Walker 22 Mar '06

22 Mar '06

On 3/21/06 6:49 PM, "Joel de Guzman" <joel(a)boost-consulting.com> wrote: > David Abrahams wrote: >> Daryle Walker <darylew(a)hotmail.com> writes: >> >>> >>> I've read on some web design website that this is horrible UI. >> >> >> Why is "some web design website" an arbiter of good UI? > > I assumed that they based it on usability studies. But I am > not so sure. Daryle could you post some links to actual studies? I've been reading the notes at <http://www.useit.com>, specifically the "Alert Box" section at <http://www.useit.com/alertbox/>. >>> 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. >> >> I'm a below-average or middling web user and for me it has nothing to >> do with "kewlness." Once I discovered the feature I considered it useful. > > I agree with Dave, it has nothing to do with "kewlness". I too > find them very useful. I think there's been a big misunderstanding here. I never looked at any of the pages besides the first one Joel explicitly mentioned in the original message. I didn't realize that Joel applied the technique at a sub-section level too. (The sub-sections link to themselves, like '<a name="hi" href="#hi">') I feel that I'm right at the whole-page level, but I don't have a fully-formed opinion at the section level yet. I see why it could be helpful, but couldn't you use an explicit mnemonic instead (maybe a linked "bookmark this" button next to the title)? -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

1 0

Re: [boost] [Boost-docs] [quickbook] [MPL] Knowing where you are the wrong way
by Daryle Walker 22 Mar '06

22 Mar '06

On 3/21/06 5:59 PM, "Joel de Guzman" <joel(a)boost-consulting.com> wrote: > 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. The alternative would be to go back to the table of contents > and grab the link there. Two more clicks away, and possibly error > prone (I have to verify that what I grabbed is the correct section). > > So... yes, Daryle, I'd like to hear if you have a better suggestion. I think you and Dave confused yourselves. What you guys think I said had nothing to do with what I actually said. You think I'm complaining about links that jump to a sub-section anchor within the same page. I'm only talking about a link that jumps to the same page as a whole (no anchor in particular). Ironically, the page you gave as an example, <http://snipurl.com/no8s>, only has the self-whole-page link I actually complained about, and zero instances of the cross-section links you thought I was complaining about. Whoever snipped my full explanation away did a big disservice. I thought that maybe I didn't make the distinction clear, but I realize that I shouldn't have to make the distinction at all. The distinction is important, but the profiled page only has a self-whole-page link and no cross-section links, so possibility never entered my mind. I have no idea how you and Dave presumed that cross-section links were my focus. [Aside: if my impromptu terms "self-whole-page link" and "cross-section links" confuse you, here's an example. In file "my_page.html":   <p>This <a href="my_page.html">link</a> uselessly reloads the current page.</p>  <h2 id="contents">Contents</h2> <p><a href="#text1">Text 1</a></p> <h2 id="text1">Text 1</h2> <p>Go back to <a href="#contents">contents</a>.</p>  ] -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

1 0