- Boost - lists.boost.org

[xpressive] Range-based interface (was: Re: How about other kinds of lists...)
by João Abecasis 22 Mar '06

22 Mar '06

[moving this thread to the the main Boost list, please don't reply to Boost-Docs.] For the benefit of those who are joining us now, I'm pursuing a range-based interface for Spirit (see my post on Spirit's list http://tinyurl.com/npvnz) Eric Niebler wrote: > João Abecasis wrote: >> Also what is the rationale for singling out std::basic_string (and >> Char const *) instead of going for the more general Range concept? > > Very off-topic here, but I'm just following the TR1 regex spec. Besides, > in the future, Range won't cover Char const *. A Range-based interface > might make for a nice extension to TR1, though. For Spirit, the situation is the same. To circumvent this, I'm locally extending the Range concept to include istreams, fstreams and, when Range drops support for those, string literals. To this end, there's an extensible as_range<T> class template that is specialized to offer automatic conversion of T to a real range. Working code is available through the link above. What do you think of this? Regards, João

2 2

[date-time] test failure (was: Boost.Build v1 broken?)
by David Abrahams 22 Mar '06

22 Mar '06

David Abrahams <dave(a)boost-consulting.com> writes: > Aleksey Gurtovoy <agurtovoy(a)meta-comm.com> writes: > >> Our continuous regressions against CVS HEAD have been failing for the >> last 24 hours or so with the following log: >> >> boost-test(RUN) "date_time/testtime_serialize" : "libs\date_time\test\posix_time\testtime_serialize.cpp" >> boost-test(RUN) "date_time/testtime_serialize_std_config" : "libs\date_time\test\posix_time\testtime_serialize.cpp" >> **** DLLs cannot be built with this compiler and stlport 4.x **** >> **** skipping build of <@boost!libs!serialization!build>boost_serialization.dll; toolset= vc-6_5-stlport variant= debug **** >> C:\Users\Administrator\boost\main\boost\tools/build/v1\boost-base.jam:1585: in find-compatible-subvariant >> *** argument error >> * rule split-target-subvariant ( target-var properties-var toolset-var variant-var : subvariant ) >> * called with: ( sv-target sv-properties sv-toolset sv-variant : ) >> * missing argument subvariant >> C:\Users\Administrator\boost\main\boost\tools/build/v1\boost-base.jam:2032:see definition of rule 'split-target-subvariant' being called > ... >> C:\Users\Administrator\boost\main\boost\tools/build/v1\testing.jam:552: in run >> ..\libs\date_time\test\Jamfile:220: in load-jamfiles >> C:\Users\Administrator\boost\main\boost\tools/build/v1\allyourbase.jam:1764: in SubInclude >> C:\Users\Administrator\boost\main\boost\tools/build/v1\allyourbase.jam:1352: in subinclude >> Jamfile:25: in load-jamfiles >> C:\Users\Administrator\boost\main\boost\tools\build\v1\bootstrap.jam:21: in boost-build >> C:\Users\Administrator\boost\main\boost\boost-build.jam:16: in module scope >> >> Does this ring a bell to anybody? > > I don't know what command-line arguments bjam is being invoked with, > but for me, building in libs/date_time/test works without a hitch. I am, however, getting the following test failure: execute-test c:\tmp\build\v1\bin\boost\libs\date_time\test\testlocal_time.test\vc-8_0\debug\threading-multi\testlocal_time.run ====== BEGIN OUTPUT ====== Pass :: Zone abbreviation Pass :: base offset Pass :: zone has dst Pass :: is_dst check Pass :: to_string: 2003-Dec-20 05:00:00 MST Checking copy construction Pass :: is_dst check Pass :: to_string: 2003-Dec-20 05:00:00 MST Pass :: zone has dst Pass :: base offset Checking special_value construction Pass :: is special_value Pass :: to_string: not-a-date-time Pass :: is_dst Pass :: is special_value Pass :: to_string: +infinity Pass :: is_dst Pass :: Add a duration to a special value Pass :: max_date_time to_string: 9999-Dec-31 18:59:59.999999999 EST EXIT STATUS: 3 ====== END OUTPUT ====== -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

[Boost-bugs] [ boost-Feature Requests-1456195 ] mkstemp
by SourceForge.net 22 Mar '06

22 Mar '06

Feature Requests item #1456195, was opened at 2006-03-22 07:27 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=357586&aid=1456195&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: mkstemp Initial Comment: Could you add a function similar to mkstemp in boost::filesystem? It would be interesting if it could receive an boost::filesystem::path or an std::string as input and return a ofstream and a path or a string as output jesus.malo(a)bsc.es ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=357586&aid=1456195&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-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