November 2004 - Boost - lists.preview.boost.org

Re: GUI Library Proposal for a Proposal
by George van den Driessche 16 Nov '04

16 Nov '04

> Message: 10 > Date: Tue, 16 Nov 2004 13:53:14 +1100 > From: "Mathew Robertson" <mathew.robertson(a)redsheriff.com> > Subject: Re: [boost] Re: GUI Library Proposal for a Proposal > To: <boost(a)lists.boost.org> > Message-ID: <018801c4cb87$7bf2cdf0$a901000a@mat> > Content-Type: text/plain; charset="iso-8859-1" > > > >>>The FOX GUI has exactly this capability, you can connect a variable > directly to the widget, without requiring any glue code at all. In fact, > you can connect the same variable to multiple widgets at the same time (eg > a 'spinner' widget and an 'editeline'), without requiring the programmer > to write any type of callback mechanism. > > >>> > > >>>This works because all GUI events are bi-directional. For more > information, read: http://www.fox-toolkit.org/datatarget.html > > >>> > > >> > > >>That seems a lot of code, compared to: > > >>http://www.torjo.com/win32gui/save_dlg.html > > >>Not to say about validation... > > > > > > > > > The problem with this implementation is that the 'user_name' field > cannot (usually) > > > connect to more than one widget at a time. > > > > That is a current limitation, but I don't think you need it so much. > > Anyway, you can work around it, by listening to kill_focus events: > > - you will have temporary variables, and each is bound to a control. > > - You listen for kill_focus from these variables > > - on kill_focus, you synchronize the temporary variables > > Thats a hack, plain and simple... and it requires the application > programmer to synchronise the state of these variables -> it should be a > capability within the GUI library. What I am suggesting is that the > technique described, is added as a native capability to the library so > that this error-prone code is eliminated. [snip] It wouldn't be very difficult. You can track which widgets are bound to a given datum and signal them all when its value changes. You would need that capability anyway if you ever wanted to display data that change for reasons other than user input. But you still have to detect the changes, and that's the tricky part to generalise. In the end you're going to have a hard time completely avoiding writing special-case code for data that need to update their attached views. > > > Also, most widget libraries dont allow you to connect a variable to > a widget, > > >and still allow user validation. This is because the widget library > > > doesn't callback into the validation code, > > > since it assumes that if it is connected to a widget, then no > validation code is necessary. > > > > > > > That's the win32gui' advantage :) > > > > > > "if it is connected to a widget, then no validation code is > necessary." > > - that really sounds silly. > > Not really, there are two reasons why validation code is not necessary. > > 1. User validation always needs to be done by your business/process > rules. > -> When the 'go' event is generated, your app should validate the > application variables (some of which will be connected to widgets). The > validation will need to reset any variables which are in an out-of-bound > condition (this implies that the GUI will need to re-synchronize to the > new state of the variables). I wont comment on whether it is good to > intertwine business logic within GUI update code.... You might want to provide feedback as to the validity of fields before the dialog is finished. Java does this all over the place and it's enormously helpful (it's one of the things that makes Eclipse lovely). > 2. Some widgets dont need validation eg: spinner, combobox, slider... > These almost never need validation, since they are only ever populated > with valid values. Unless there's some dependency between fields such that, for example, the values listed in a combo-boxexclude certain other choices from another combo-box. > ------------------------------ > > Message: 11 > Date: Tue, 16 Nov 2004 13:57:22 +1100 > From: "Mathew Robertson" <mathew.robertson(a)redsheriff.com> > Subject: Re: [boost] Re: GUI Library Proposal for a Proposal > To: <boost(a)lists.boost.org> > Message-ID: <019e01c4cb88$0aea6220$a901000a@mat> > Content-Type: text/plain; charset="iso-8859-1" [snip] > > Even reflected property types should be of trivial types: > > 1. build in types > > 2. std::string > > 3. types that can simply be read from /written to strings. I don't agree with this either, but: > > For case 3., you might also have a validation function which will be > > used in design-mode to validate user input. > > > > At least that's what I want. > > I'm not sure that is valid. > > Take a TreeList as an example. The items in a treelist are almost > always sub-classes, based on some type of generic 'TreeItem' class. I'm > not sure that a TreeItem can always be represented as a string. I'm not sure that a TreeItem can be represented as anything other than a string, on some platforms. > Also, the position of a treeitem (within the treelist), may not > necessarily be able to be stringified. Would it be important? Couldn't it just come out as a vector of ints if you really needed it? George

2 1

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