- Boost - lists.boost.org

Re: [boost] [filesystem] Major changes before standardization
by brangdon＠cix.compulink.co.uk 16 Nov '04

16 Nov '04

In-Reply-To: <6.0.3.0.2.20041115095103.028e91e0(a)mailhost.esva.net> bdawes(a)acm.org (Beman Dawes) wrote (abridged): > Your strongest argument IMO is the point about conversions not > necessarily being value preserving. I believe conversions from char to wchar_t are always value preserving, or can be made to be. I've known MultiByteToWideChar() to fail with CP_SYMBOL on Win98, but it's easy to handle that as a special case (and replicate the XP behaviour). I would be interested to hear of any other counter-examples. > (I guess we could tell Windows users that they should not expect > such conversions to work unless supported by the applicable > codepage. But that seems spin rather than a real solution.) I don't think there's any magic here. WideCharToMultiByte() is usually a misnomer, as most code pages only support 256 characters. Even the double-byte ones cannot support the whole of 16-byte Unicode, let alone surragate pairs. Typically converting an unsupported character will yield a question mark, which is not valid in a file name. So if we do the conversion, the unsupported characters will fail in our code, and if we don't, it will fail in the OS. There's no magic to make it work. When "OS" means "Win98+MSLU", in my experience it is better to handle the conversion explicitly as MSLU doesn't always do what I'd want. I have sometimes found the best way to convert a Unicode path to ANSI is via GetShortPathName(). This isn't an argument against using two path classes. It is an argument against wpath relying on MSLU. In my Unicode apps an important use case was passing Unicode filenames to other, ANSI apps and libraries. So if we do have two path classes we will still need to offer conversions between them. Probably this conversion should match the one you get when making OS calls, which is another argument for doing the conversion ourselves. Having 2 classes is probably the clearest way to manage such cases. -- Dave Harris, Nottingham, UK

1 0

Intel 7.1-linux tarball results
by Aleksey Gurtovoy 16 Nov '04

16 Nov '04

Martin, Almost all Intel 7.1 tarball tests fail with the following diagnostics (from http://tinyurl.com/4jvoo) /opt/intel/compiler70/ia32/lib/libcprts.a(xlocinfo.o)(.text+0x29): In function `_Getctyptab': : undefined reference to `__ctype_b' /opt/intel/compiler70/ia32/lib/libcprts.a(xlocinfo.o)(.text+0x41): In function `_Getctyptab': : undefined reference to `__ctype_b' /opt/intel/compiler70/ia32/lib/libcprts.a(xlocinfo.o)(.text+0x66): In function `_Getctyptab': : undefined reference to `__ctype_b' /opt/intel/compiler70/ia32/lib/libcprts.a(xlocinfo.o)(.text+0x8b): In function `_Getctyptab': : undefined reference to `__ctype_b' /opt/intel/compiler70/ia32/lib/libcprts.a(xlocinfo.o)(.text+0xb0): In function `_Getctyptab': : undefined reference to `__ctype_b' /opt/intel/compiler70/ia32/lib/libcprts.a(xlocinfo.o)(.text+0xd2): more undefined references to `__ctype_b' follow . /opt/intel/compiler70/ia32/bin/iccvars.sh icpc -g -o "../bin/boost/libs/algorithm/minmax/test/minmax.test/intel-7.1-linux/debug/minmax" "../bin/boost/libs/algorithm/minmax/test/minmax.test/intel-7.1-linux/debug/minmax_test.o" -lrt This is obviously a configuration/environment problem, but it'd be nice to get the reports cleaned from all these red cells. Could you take a look into this, please? -- Aleksey Gurtovoy MetaCommunications Engineering

2 3

[1.32 Release] Final draft release tarballs are available
by Aleksey Gurtovoy 16 Nov '04

16 Nov '04

Hi All, Final draft tarballs for the 1.32 release are available from the following locations: http://www.meta-comm.com/engineering/boost/200411150916/boost_1_32_0.tar.bz2 http://www.meta-comm.com/engineering/boost/200411150916/boost_1_32_0.tar.gz http://www.meta-comm.com/engineering/boost/200411150916/boost_1_32_0.zip This time, there are no known issues. Once these are tested and confirmed to be good, we are releasing them. For your convenience, the unpacked contents is available online at http://www.meta-comm.com/engineering/boost/1_32_0_draft/. You can consider this to be a draft version of post-1.32 Boost website. TESTING ------- Please see the original announcement for details -- http://article.gmane.org/gmane.comp.lib.boost.devel/112562 -- Aleksey Gurtovoy MetaCommunications Engineering

4 4

[MPL] document not updated
by Allen Yao 16 Nov '04

16 Nov '04

It seems that the MPL document in CVS is still not updated to reflect the changes since 1.31, for example there is still "apply_if" instead of "eval_if", this will cause great confusion. I wonder if the final 1.32 tarballs have the same problem.

3 2

Re: [logging] file_appender and rolling_file_appender
by John Torjo 16 Nov '04

16 Nov '04

Hi Caleb, Thanks! Totally cool! I'll include them in the next version. Best, John > Attached please find an implementation of two functors for John > Torjo's boost::log library which I have called "file_appender" and > "rolling_file_appender". Documentation is scant, so I'll try to > describe them here. > -- John Torjo, Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.5 - tooltips at your fingertips (work for menus too!) + bitmap buttons (work for MessageBox too!) + tab dialogs, hyper links, lite html

1 0

Re: [boost] Boost Iterable Range Library update (v1.5)
by Richard Peters 16 Nov '04

16 Nov '04

"Robert Ramey" <ramey(a)rrsd.com> wrote in message news:cmrl55$hng$1@sea.gmane.org... > "Thorsten Ottosen" <nesotto(a)cs.auc.dk> wrote in message > news:cmrk1g$f70$1@sea.gmane.org... > > > Here's my general take on it: iterators are important and useful as the > > lower-level > > infrastructure. iterators are, however, not too user-friendly; the > > user-friendly interface > > can be build on top so easy task becomes , well, easy. and that is the > purpose > > of ranges and johns range library. > > without a good iterator library underneith ranges where hard to craft, but > now > > that we have a good iterator library, we should persue > > higher abstractions > > I agree that iterators aren't that easy or intuitive to work with. So our > motivations have much in common. My view is that iterators can be made > easier to work with without changing their fundamental character and without > the need to introduce what I see as a new concept (ranges) that is "almost > the same" as an existing concept - pair of iterators. > > Robert Ramey While iterators are very good at what they do -- provide access to elements in a sequence -- they do not capture the concept of a sequence very well. If I want to access a sequence of elements, I'd like to see a clean front-end, and I believe that John's range library can provide me with such a clean front-end. Using for_each(s.begin(), s.end(), ...) is too low-level, it exposes details of a sequence that I do not want to know. I do not want to for_each on a begin and an end, I want to for_each on a sequence: for_each(s, ...). It's a conceptual layer, admittedly a small one, but it provides a great front-end for the back-end of iterators. std::pair<iterator, iterator> fails at creating a decent front-end. For one thing, the iterator type must by typed twice. This adds quite some text. Secondly, it stays in the 'begin-end' concept, instead of advancing to a real range, of which you can extract an element and advance to the next by shrinking the range. You said before that the STL had a very good reason to use iterators. I agree there, iterators are very effective at what they do, but I'd like a higher-level interface built on top of that. For me, the following example from the Range Adaptors and Composition(s) documentation illustrates that: // [1] print all even elements (not using range adaptors) typedef boost::filter_iterator<array> filter_iterator; rng::for_each( irange<filter_iterator>( filter_iterator(some_array.begin(), is_even), filter_iterator( some_array.end(), is_even), print ); // [2] print all even elements (using range adaptors) rng::for_each( filtered(some_array, is_even), print); [1], while already using ranges, is easily rewritten to an iterator-only version. In [1], two iterators have to be wrapped with a filter_iterator constructor, both containing the same predicate. In [2], a range adaptor is used, and the predicate need only be given once. When I read the second version aloud, I hear exactly what I want to hear: "Take the elements of some_array, filter out the even elements, and print them". With [1], it's much more difficult to read it aloud. It also contains redundancy: is_even is passed twice. While possibly even error-prone, I think this is just ugly. It's not filter_iterator's fault, the filter_iterator is great at what it does, but it is the range adaptor that wraps it up nicely and provides a clean interface to ranges, not just begin-end pairs. best regards, Richard Peters

6 19

Re: MPL compilation speed trade-offs...
by Jaap Suter 16 Nov '04

16 Nov '04

> My advice: use the MPL constructs and optimize later. When > you're done you can measure the compilation speed difference > when using mpl::plus, minus and divides vs. the ugly version at > the bottom. I bet you dollars to donuts that it's not a significant > hit. But if it is, you can make some informed choices. Believe me, I'm better known for premature pessimization then premature optimization. It's no longer a matter of compilation times (I can live with that), but a matter of the compiler no longer being able to handle it (running out of memory, out of keys, etcetera). I've tried many other things first (/Zm, splitting up source files, etcetera), but I'm beginning to believe that meta-C++ is just not quite ready for the algorithmic complexity of some of my meta-code. I've started reaching for the preprocessor a lot lately, and I'm now writing a blend of template code and preprocessor code that is quite elegant, albeit completely unreadable ;). It does compile a lot faster fortunately. Thanks, Jaap Suter

1 0

[MPL] Wiki docs
by David B. Held 16 Nov '04

16 Nov '04

Here: http://www.mywikinet.com/mpl/mpl_1_32_changelog/numeric-metafunctions-proto… I'm guessing that: template< int n > struct my_int { static int const value = n; typedef my_iny type; }; is really supposed to be: template< int n > struct my_int { static int const value = n; typedef my_int type; ^^^^^^ }; And same for the "After" example. Dave

2 1

Member function detection: VC7.1 workaround needed
by Jonathan Turkanis 16 Nov '04

16 Nov '04

Hi All, I'm writing a macro-based interface definition language, which I hope to post soon. For this, I need to be able to detect the presence of member functions with given name and signature. My current formulation generates code like the following to test whether a class has a non-const member function named 'one' with the signature char(int, float): template<typename T> struct has_member_function_one { template<typename U, char (U::*MemFun)(int, float)> struct one_holder { }; static ::boost::type_traits::no_type one_tester(...); template<typename U> static ::boost::type_traits::yes_type one_tester ( ::boost::mpl::identity<U>*, one_holder<U, &U::one>* = 0 ); static const bool value = sizeof(one_tester((::boost::mpl::identity<T>*)0)) == sizeof(::boost::type_traits::yes_type); typedef ::boost::mpl::bool_<value> type; }; This works fine on Comeau 4.3.3, Intel 8.0 for Windows, GCC 3.4.1 and VC8.0 (beta). But on VC7.1, it works only if the member function 'one' is not overloaded. I've tried Terje Slettebø's operator_concept_traits library, some code posted long ago by Brock Peabody, but they all use the same technique and fail on VC7.1. Does anyone have a workaround? Best Regards, Jonathan

3 7

Two points about the Named parameters library
by Joaquín Mª López Muñoz 16 Nov '04

16 Nov '04

Hello, This is not a review of the Named params library. I'd just want to make the following two points about it: 1. Some have considered this library as a means to gain experience about named parameters interfaces for possible inclusion into the standard as a built-in facility. I think this won't happen, since this issue has already been discussed (and rejected) prior to C++98. The library does not raise (AFAIK) any new issue about the suitability of such interfaces, so why should the comittee change their minds. So, we'd better consider named_params as a utility on its own, without hoping for future built-in support. 2. I think the docs miss an important point. Consider a final user exposed to a named_params-powered interface. Of course this user is not concerned about the implementation of the interface, or about the named_params lib, for that matter. Instead, she should be presented the interface as if named params were a built-in facility. A possibility: void foo(int :x:=0,int :y:=0,std::string :msg:="") foo does so and so... :x:,:y: and :msg: are named params that the user can resort to in order to subvert the traditional argument-by-position invokation interface. For instace: foo(msg="hello"); I don't claim this particular documentation example is any good (in fact, I found it rather bad), but I hope you get the idea. named_params docs are the perfect place to propose and "standardize" a general syntax and wording to document named parameter interfaces for the final user. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1