February 2004 - Boost - lists.boost.org

RE: [boost] Re: boost::any: explicit constructor?
by Bjorn.Karlsson＠readsoft.com 25 Feb '04

25 Feb '04

> From: Edward Diener [mailto:eddielee@tropicsoft.com] > > The intention was to call do_somethin on 'v.value()' but > non-explicit > > ctor is happy to accept 'variable', after which > 'do_something' breaks. > > This is a programming error, not an error in boost::any. Absolutely, but it's an error that could have been detected by the compiler given an explicit constructor. [snip] > While I am not against syntactic sugar which make it > easier to use > C++ constructs, I am against making a constructor explicit > just to keep > programmers from making errors. Isn't keeping programmers from making errors a Good Thing? For me, that's exactly the reason why boost::any's constructor _should_ be explicit. Bjorn

1 0

Re: The art of naming namespaces [was: Re: algorithms namespace]
by Bjorn.Karlsson＠readsoft.com 25 Feb '04

25 Feb '04

> From: Thorsten Ottosen [mailto:nesotto@cs.auc.dk] > > * Some names work "best" in plural (like signals, > type_traits, iterators, > > operators); this is of course very much IMHO. > > are they the names of namespaces? Signals is (and type_traits has such a namespace [albeit only in detail]), the others are the library names (living in the root boost:: namespace). > > * Just "file" seems a bit restrictive to me, but when I > think about the > > namespace "files" I read "files 'n other related stuff, too". > > then maybe it should be namespace io? Just like a big namespace for > algorithms, io > could hold file handling, zip streams, formatters etc. Yes, that's definitely an interesting option. Bjorn

1 0

boost::any: explicit constructor?
by Vladimir Prus 25 Feb '04

25 Feb '04

Hi, I just had a couple of bugs caused by the fact that constructor of boost::any is not explicit. For example: void do_something(boost::any& v) { ... } class variable { ///// boost::any& value() {} }; variable v; do_something(v); The intention was to call do_somethin on 'v.value()' but non-explicit ctor is happy to accept 'variable', after which 'do_something' breaks. Anybody has an opinion? Is non-explicit ctor really necessary? - Volodya

2 1

[config] fix for BCB and BOOST_NO_MEMBER_TEMPLATE_FRIENDS
by Pavel Vozenilek 25 Feb '04

25 Feb '04

I believe config macro BOOST_NO_MEMBER_TEMPLATE_FRIENDS should be defined for BCB 6. Currently it is defined only for BCB 5.5.1 and less but with BCB 6: - compiling test file boost_no_mem_templ_frnds.cxx fails, - the problem shows in Serialization library too. So I recommend to change borland.hpp to define this macro for BCB 6 (and likely for Kylix which is simply BCB6 ported to Linux). BCB6 patch 4 == 0x564 Kylix = 0x570 /Pavel

2 3

Re: [utility] question on prior(x,n)
by Bjorn.Karlsson＠readsoft.com 25 Feb '04

25 Feb '04

> From: Daniel Frey [mailto:daniel.frey@aixigo.de] > > > > Well, you came up with the 2-arg version. > > That was Daniel Wallin (too many Daniels error?). I guess this also > explains why I had the feeling we were talking past each > other a bit :) Heh, according to the docs it was Daniel Walker. This name-calling is getting interesting. ;-) Bjorn

1 0

Re: [utility] question on prior(x,n)
by Bjorn.Karlsson＠readsoft.com 25 Feb '04

25 Feb '04

> From: David Abrahams [mailto:dave@boost-consulting.com] > > See counting_iterator for inspiration as to why this might be useful. Got it, thanks. Perhaps these type requirements should be spelled out in the docs (proposed patch below)? And maybe is_full_iterator_traits in detail/iterators.hpp could be slightly changed and turned into a first-class traits "is_iterator", which would then be used for dispatching next/prior calls to std::advance when applicable? Although this would work, I'm not sure that the added dependencies and complexity are worth it - if possible, I think that dropping the two-argument versions of next and prior would be best. Bjorn [Note: The most interesting change to the doc are the following four lines. The one-argument version of next() and prior() can be used with any type that provides operator++() and operator--(), respectively. The two-argument version of next() and prior() can be used with any type that provides operator+() and operator-(), with the exception of iterator types, which only require operator++() and operator--() for both versions. ] *** utility.htm.orig Wed Feb 25 11:47:07 2004 --- utility.htm Wed Feb 25 11:48:17 2004 *************** *** 41,61 **** T next(T x) { return ++x; } template <class T, class Distance> ! T next(T x, Distance n) ! { ! std::advance(x, n); ! return x; ! } template <class T> T prior(T x) { return --x; } template <class T, class Distance> ! T prior(T x, Distance n) ! { ! std::advance(x, -n); ! return x; ! }</pre> </blockquote> Usage is simple: <blockquote> --- 41,54 ---- T next(T x) { return ++x; } template <class T, class Distance> ! T next(T x, Distance n); template <class T> T prior(T x) { return --x; } template <class T, class Distance> ! T prior(T x, Distance n); ! </pre> </blockquote> Usage is simple: <blockquote> *************** *** 66,71 **** --- 59,68 ---- The distance from the given iterator should be supplied as an absolute value. For example, the iterator four iterators prior to the given iterator <code>p</code> may be obtained by <code>prior(p, 4)</code>. + The one-argument version of next() and prior() can be used with any type that provides + operator++() and operator--(), respectively. The two-argument version of next() and prior() + can be used with any type that provides operator+() and operator-(), with the exception of + iterator types, which only require operator++() and operator--() for both versions. Contributed by <a href="../../people/dave_abrahams.htm">Dave Abrahams</a>. Two-argument versions by Daniel Walker. <h2><a name="Class_noncopyable">Class noncopyable</a></h2> Class noncopyable is a base class.  Derive your own class

1 0

XSL regression reporting changes
by Misha Bergal 25 Feb '04

25 Feb '04

I have checked in the modifications to split the failed test logs HTML file (links.html) into on HTML file per test log. The regression testers using xsl_reports will need to update their upload scripts. -- Misha Bergal MetaCommunications Engineering

1 0

warning when using borland toolset
by Gennadiy Rozental 25 Feb '04

25 Feb '04

I am getting following warning when I try to compile using Borland toolset: ...boost\tools/build\v1\borland-tools.jam:182: in include-tools warning: unknown rule W32_GETREG ...boost\tools/build\v1\boost-base.jam:760: in relevant-features ...boost\tools/build\v1\boost-base.jam:828: in select-properties ...boost\tools/build\v1\boost-base.jam:799: in variant ...boost\tools/build\v1\features.jam:179: in boost-build ...boost\boost-build.jam:16: in module scope ...boost\tools/build\v1\borland-tools.jam:182: in include-tools (actually repeated multiple times) any suggestions? Gennadiy

2 1

The art of naming namespaces [was: Re: algorithms namespace]
by Bjorn.Karlsson＠readsoft.com 25 Feb '04

25 Feb '04

> From: Peter Dimov [mailto:pdimov@mmltd.net] > > > You can always shorten it in your code with an alias. > > This is precisely what makes it dangerous. Design mistakes that have a > trivial workaround are the worst, because you will never get > the feedback > that will set you on the right path. Everyone just patches around it > locally. I agree. If a name "works", programmers will use it. If it's too long, it'll be aliased or removed with using declarations/directives. If it's too cryptic, it'll be aliased or removed with using declarations/directives. I think that two equally valid points have been made in this thread: 0) If the name is too long, people won't use it as-is. This diminishes the information that the name carries. 1) If the name is too short/cryptic, people won't even know what it's supposed to mean. If one agrees to the above, it seems reasonable to search for a short name with lots of expressive power (oh yeah, why didn't I think of _that_...). I'd say that for boost::filesystem, Dave's suggestion "files" would be a great compromise. I'd say that for algorithms, a special name isn't actually needed; it doesn't add any information, because anyone who calls sort, trim, hash, or whatever, understands that somewhere an algorithm is involved. boost::, std::, you_name_it::, will get the job done. [Note: Some libraries (Spirit and MPL come to mind) are sexy enough to handle a non-related word/acronym as their name, without sacrificing informational value. Now that's good branding!] > No we do not. The abbrv anlgy is flwd. It's more like English::this > English::kind English::of English::writing versus en::this > en::alternative > en::style. What's "en"? ;-) > > Also a global search is easier if the letters to be searched for are > > more or less a unique set. > > Of course it isn't. Your global search for 'filesystem' will > only find using > directives and namespace alias directives. A global search > for 'fs' will > stand a better chance to point you to the lines that actually > use something > from 'fs'. Good point. Bjorn "Put the bicycle shed next to my office" Karlsson

2 1

Re: Proposed modifications to make compose_f_*_t use *ary_traitsand call_traits
by Jonathan Turkanis 25 Feb '04

25 Feb '04

". Sneechy" <sneechy(a)hotmail.com> wrote in message news:F295smOU9Xlk0H1jLUL00026d99@hotmail.com... > Traits classes can make templates more generic and otherwise flexible > (performance-wise for example). I believe that the compose_f_*_t template > class family in boost/compose could benefit from using *ary_traits (from > boost/functional), and boost/call_traits. Are you aware that compose has been deprecated? Jonathan

1 0