- Boost - lists.preview.boost.org

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

Lambda patch to enable *_1 for smart pointers
by Peter Dimov 25 Feb '04

25 Feb '04

I've taken the liberty to apply the following patch to boost/lambda/detail/operator_return_type_traits.hpp: *** 19,24 **** --- 19,26 ---- #include "boost/lambda/detail/is_instance_of.hpp" #include "boost/type_traits/same_traits.hpp" + #include "boost/indirect_reference.hpp" + #include <cstddef> // needed for the ptrdiff_t #include <iosfwd> // for istream and ostream *************** *** 221,227 **** // A is a nonreference type template <class A> struct contentsof_type { ! typedef typename std::iterator_traits<A>::reference type; }; // this is since the nullary () in lambda_functor is always instantiated --- 223,229 ---- // A is a nonreference type template <class A> struct contentsof_type { ! typedef typename boost::indirect_reference<A>::type type; }; // this is since the nullary () in lambda_functor is always instantiated This (hopefully) makes *_1 work for smart pointers. Feel free to revert the patch if it breaks something; I don't have a full regression test system set up. -- Peter Dimov http://www.pdimov.com

2 1

Announce: Metrowerks Pro 9 Windows Now Shipping
by Howard Hinnant 25 Feb '04

25 Feb '04

If the kind moderators allow this through I promise not to send such blatantly commercial announcements to the boost developers list again (at least for awhile :-) ). <commercial> Here is contact info which can also be found at our website www.metrowerks.com: info(a)metrowerks.com US Mail: Metrowerks Sales Metrowerks 9801 Metric Blvd. Austin, TX 78758 Telephone: Toll Free: 800-377-5416 International: +1 512 997 4700 Fax: +1 512 997 4901 I'm personally very proud of many of the Pro 9 features which include pseudo move semantics for vector. For example you might want to try running the following demo under CodeWarrior and your 2nd favorite compiler (optimize for speed): #include <string> #include <set> #include <iostream> #include <time.h> #include <vector> int main() { std::string s(20, ' '); std::multiset<std::string> ms; for (int i = 0; i < 100; ++i) ms.insert(s); std::vector<std::multiset<std::string> > v(10000, ms); clock_t t = clock(); v.erase(v.begin()); t = clock() - t; std::cout << (double)t/CLOCKS_PER_SEC << '\n'; } Assuming your clock() function has sufficient resolution to produce reasonable results on your platform you might be interested in the results. Of course this should be old hat to Mac users (Pro 9/Mac has been out for months). Fwiw, here's what I'm getting on my Mac: [G4:~/Documents/Development/JunkMac] hinnant% ./helloworld 0.01 // CodeWarrior Pro 9 [G4:~/Documents/Development/JunkMac] hinnant% g++ -v Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs Thread model: posix gcc version 3.3 20030304 (Apple Computer, Inc. build 1495) [G4:~/Documents/Development/JunkMac] hinnant% g++ -O4 HelloWorld.cp [G4:~/Documents/Development/JunkMac] hinnant% ./a.out 1.08 </commercial> -Howard

3 2

1.31.0 regressions
by David Abrahams 24 Feb '04

24 Feb '04

IIUC, we've already found some regressions with 1.31.0, having to do with the graph library and MSVC6. These regressions affect the Python lib also, and the problems show up in the regression test results. It's very disappointing to me that even though the Python library was being tested continuously, we let the release go out anyway. We ought to ask ourselves how this happened and see if there's something we can do to prevent it in the future. My guess is that inspecting regression results by hand isn't good enough, and we need an automated system like the BuildBot. We also ought to be thinking about releasing 1.31.1 ASAP. -- Dave Abrahams Boost Consulting www.boost-consulting.com

25 105

Lambda patch to make it recognize a nested ::result_type
by Peter Dimov 24 Feb '04

24 Feb '04

The following patch to boost/lambda/detail/return_type_traits.hpp enables it to extract the return type information from a nested ::result_type typedef instead of insisting on a sig<> template. This is useful since all standard function objects in <functional> and many user-defined function objects (including those produced by boost::mem_fn) have result_type but no sig<>. I have not commited the patch yet, even though it seems to work fine for me, since it alters the Lambda behavior in the case where a function object defines both result_type and sig<>. Currently, sig<> is used. With the patch, result_type would override sig<>. All function objects known to man that have both do define sig<> to return the same type as result_type; nevertheless, I'd like confirmation from the maintainers first, before I commit. Thanks for listening; patch follows: *** 17,22 **** --- 17,24 ---- #ifndef BOOST_LAMBDA_RETURN_TYPE_TRAITS_HPP #define BOOST_LAMBDA_RETURN_TYPE_TRAITS_HPP + #include "boost/mpl/aux_/has_xxx.hpp" + #include <cstddef> // needed for the ptrdiff_t namespace boost { *************** *** 239,244 **** --- 241,265 ---- typedef Ret type; }; + // ::result_type support + + namespace detail + { + + BOOST_MPL_HAS_XXX_TRAIT_DEF(result_type) + + template<class F> struct get_result_type + { + typedef typename F::result_type type; + }; + + template<class F, class A> struct get_sig + { + typedef typename function_adaptor<F>::template sig<A>::type type; + }; + + } // namespace detail + // Ret is detail::unspecified, so try to deduce return type template<int I, class Args> struct return_type_N<function_action<I, detail::unspecified>, Args > { *************** *** 251,257 **** public: // pass the function to function_adaptor, and get the return type from // that ! typedef typename function_adaptor<plain_Func>::template sig<Args>::type type; }; --- 272,282 ---- public: // pass the function to function_adaptor, and get the return type from // that ! typedef typename detail::IF< ! detail::has_result_type<plain_Func>::value, ! detail::get_result_type<plain_Func>, ! detail::get_sig<plain_Func, Args> ! >::RET::type type; }; -- Peter Dimov http://www.pdimov.com

2 1

vc71 - tokenizer not working with static runtime and unicode?
by Bronek Kozicki 24 Feb '04

24 Feb '04

Following problem has been reported on boost users list. If following code is compiled with compiler option /MD (dynamically link to runtime library) it works, but when compiled without it (statically linked to runtime), it produces no output. >>>> code begin #include <string> #include <iostream> #include <boost/tokenizer.hpp> int main() { typedef boost::tokenizer<boost::char_separator<std::wstring::value_type>, std::wstring::const_iterator, std::wstring> MyTokenizer; const boost::char_separator<std::wstring::value_type> sep(L"a"); MyTokenizer token(std::wstring(L"abacadaeafag"), sep); for (MyTokenizer::const_iterator it = token.begin(); it != token.end(); ++it) std::wcout << *it << std::endl; } >>>> code end I suppose there might be some problem with vc71 static runtime library, but maybe you have other explanation? B.

5 9

Re: Intel 8.0 on Windows now passes all Boost regression tests
by Michael Stevens 24 Feb '04

24 Feb '04

[boost] Intel 8.0 on Windows now passes all Boost regression tests > A bug fix version of Intel 8.0 for Windows has been posted on their web > site. This new version passes all Boost regression tests. See > http://boost.sourceforge.net/regression-logs/ > Congratulations to Intel, and thanks for fixing several bugs which were > causing Boost tests to fail! Oh this is definitely very good. Time I downloaded the Linux version. There are some false positives however. uBLAS test3,4,5 should fail really. They have a couple of missing typenames with gcc-3.4 correctly picks up. The patches for this should be merged into Boost CVS very soon. I wonder if the Intel compiler can be configured to be a little more strict. The more good compilers that can pick up code that is non standard conforming the better. Michael -- ___________________________________ Michael Stevens Systems Engineering Navigation Systems, Estimation and Bayesian Filtering http://www.sf.net/Bayes++ ___________________________________

4 3

random_device
by Richard Peters 24 Feb '04

24 Feb '04

The random_device.cpp in boost version 1.31.0 does not support a nondeterministical random device for Windows. I used the Windows CryptoAPI to make random_device.cpp support the Windows platform as well. The attached random_device.cpp has new code at lines 100-152 and is tested under VC 7.1. Best regards, Richard Peters

1 0

BBv1 New CodeWarrior toolset.
by Rene Rivera 24 Feb '04

24 Feb '04

Boosters, Yesterday I added a new Boost.Build v1 toolset for use with the Metrowerks CodeWarrior compilers. This is a cleanup, and improvement, of the current toolsets metrowerks-tools, cwpro8-tools, cwpro9-tools. The new toolset "cw" implements all the functionality in those three and more. It is meant as a replacement for them, and hence they will be removed soon. Documentation is in the usual place, boost-root/tools/build/v1/cw-tools.html. For testers I ask that they test with the new toolset at the earliest opportunity. Especially those with version 9 of CW, as I only have version 8. Right now the toolset still only supports the Windows platform. But if people have CW on other platforms changes to accommodate them are welcome ;-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

4 3