- Boost - lists.boost.org

Re: [Boost-testing] Re: Re: Intel 7.1-linux tarball results
by Aleksey Gurtovoy 17 Nov '04

17 Nov '04

Robert Ramey writes: > I was considering the situation whereby a particular compiler/configuration > fails all or most of the test because of some issue in the test computer's > build configurtation. Which is what we had. > Since the "release package" just points to the test > results, they can be updated at anytime after the release. Of course. > So I don't see > that this test problem should hold up the release. Oh, definitely not. > > That's all I meant to say. OK, thanks for the clarification. -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

[logging] file_appender and rolling_file_appender
by Caleb Epstein 17 Nov '04

17 Nov '04

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. The "file_appender" is meant as a more-or-less drop-in replacement for John's write_to_file functor, except that it keeps the output file open instead of re-opening it for each write. "rolling_file_appender" derives from file_appender and allows the user to specify a maximum file size and a number of files to keep. After each write, it checks if the file is >= <max_size> and, if so, calls the rollover method. This method renames existing logfiles using a numbered suffix, keeping at most <num_files> backups. If <max_size> is specified as 0, rolling_file_appender behaves the same way as file_appender. If <num_files> is 0, there will be only one logfile which will be truncated every time it reaches <max_size>. Both of these objects support a "filename_factory" function which the caller can use to generate unique or date-stamped (or ...) filenames from a user-supplied filename "prototype". I've included a factory function called "strftime_filename_factory" which will take the filename prototype and run it through std::strftime. The rolling_file_appender uses boost::filesystem to handle file remove/rename operations. Feedback is welcome. -- Caleb Epstein caleb dot epstein at gmail dot com

2 2

Re: [Boost-testing] Re: Intel 7.1-linux tarball results
by Aleksey Gurtovoy 17 Nov '04

17 Nov '04

Robert Ramey writes: > Isn't this a link from the 1.32 release package. I'm sorry, but the question doesn't make sense to me. What _is_ "a link from the 1.32 release package"? For that matter, what's "1.32 release package"? We didn't release yet; we only have "final draft tarballs", and the link I posted points to the reports for those. > Can't the link just be left and point to the updated results? Please be more specific: which link? left where? > In fact, isn't possible that a newer version of a compiler (e.g. gcc > 3.4.3?) comes out and we want to re-run show updated test results > eventhough the 1.32 package is frozen. OK, I understand this one :). Yes, it's surely possible, and we can easily do that. > I don't see this has having anything to do with release drafts. Depends what "this" is. The results at http://www.meta-comm.com/engineering/boost-regression/developer/index.html most definitely report the status of the draft tarballs. -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

[TEST] please disregard
by Stuart Allie 17 Nov '04

17 Nov '04

test

1 0

Boost Graph Library Property Map
by Manas Singh 17 Nov '04

17 Nov '04

Is it possible to convert other Property Maps to Vector Property Map? My requirement is that the property map should be able to grow/expand (as I am using it with a dynamic graph which also grows). But I want to make it generic so that it works for any kind of property map. So I think if I am able to convert any type of property map to vector property map then I can grow the property map, when I add new vertices to the graph. Thanks, Manas.

2 1

Re: [boost] Lazy Metaprogramming Library
by Vesa Karvonen 17 Nov '04

17 Nov '04

Terje Slettebø: [...] >It's an interesting approach, and IIUC, one that has come up >before (see the "Meta function variants of mpl::apply_if >necessary?" thread a couple of years ago - BTW, I independently invented the equivalent of `apply_if' and described it publicly under the name `type_inner_if' (although I recall it wasn't the first name I gave to the metafunction): http://lists.boost.org/MailArchives/boost/msg12815.php IIRC, MPL didn't have `apply_if' at the time. Ever since I first used template metaprogramming, I have been searching for a template metaprogramming "style" (a minimal and unambiquous set of rules to follow), that would make template metaprogramming as simple as ordinary programming. Most template metaprograms are fundamentally very simple (usually next to trivial), but the simplicity is hidden behind a ton of intricate syntax and evaluation order annotations. >Your algorithms, such as: > >template<class l> >struct SIEVE > : CONS<HEAD<l>, > SIEVE<FILTER<NOT_DIVISIBLE_BY<HEAD<l> >, > TAIL<l> > > > {}; The above is from an old version of the library. You might want to get the latest snapshot, which has a couple of important improvements. You can find the latest snapshot at: http://groups.yahoo.com/group/boost/files/LazyMPL/ ... > http://thread.gmane.org/gmane.comp.lib.boost.devel/73829) > >However, as shown in the posting by Aleksey, it was considered and >reconsidered during MPL development, but dropped, due to not at >least problems with passing nullary metafunctions to functions, >without evaluating them in the passing. Hmm... From a cursory reading of the thread, it seems to me that there are some similar ideas, but crucially, what seems to be missing is a "holistic" treatment of laziness. I think that is quite understandable given that (implementation of) lazy functional programming (languages) isn't something that C++ programmers generally think about. Basically, all the examples in the thread seem to mix and match strict and lazy evaluation: >[...] my example in the above thread: > >template<class V> >struct factorial >{ > typedef typename V::type Value; > > typedef typename apply_if<equal_to<Value,value<Value,0> >, > value<Value,1>, > mul<Value,factorial<prior<Value> > > > >::type type; >}; > >The reason there are still "::type" expressions in the above, is that it >relies on MPL metafunctions that aren't lazy. [...] Yes, that is exactly what I mean above. *Systematic* use of lazy template metaprogramming would yield the following (unoptimized) factorial function: template<class n> struct FACT : IF<IS_0<n>, INT<0>, TIMES<n, FACT<PRED<n> > > > {}; As you can see, all explicit invocations are eliminated. I think that there is a huge difference between applying laziness in an essentially ad hoc manner (little here and little there) rather than applying it systematically (all metafunctions are lazy). An *optimized* version of the factorial function could look like this (I haven't compiled the code): template<class n> struct FACT : FACT<typename n::eval> {}; // #1, #2 template<long n> struct FACT<INT<n> > // #1.A : INT<(n * FACT<(n-1)>::eval::value)> {}; template<> struct FACT<INT<0> > // #1.B : INT<1> {}; #1) The crucial note to make of the above code is the explicit invocation ::eval used in the non-specialized version of the FACT-template. The purpose is to reveal the INT<> constructor for pattern matching (#1.A and #1.B). #2) I use the name `eval' instead of `type', because `eval' describes the intention more clearly: `::eval' forces the evaluation of a parameter. [The name `type' is used with boxing (BOX<t>::type == t and BOX<t>::eval == BOX<t>). (Boxing is also mentioned later in this message.)] The factorial function is not a very good example in the sense that it is completely strict. In other words, the factorial function *always* needs to examine the substructure of *every* parameter it receives. There are, however, lazy metafunctions that have both strict and non-strict parameters. The APPEND<l, r> metafunction for concatenating two lists is one example of such a function. Let's first see the unoptimized version: template<class l, class r> struct APPEND : IF<IS_NIL<l>, r, CONS<HEAD<l>, APPEND<TAIL<l>, r> > > {}; It is easy to see that APPEND is strict in the `l' parameter, because it is *always* examined by the conditional. However, the `r' parameter never needs to be examined---and a correct implementation of APPEND must never force the evaluation of (explicitly invoke) the `r' parameter. Consider the following definition of an infinite list: struct INFINITE_LIST_OF_ONES : APPEND<LIST<ONE>, INFINITE_LIST_OF_ONES> {}; If APPEND<l,r> would force the evaluation of the `r' parameter the above definition would not work correctly. (Can you see why?) Let's then look at an optimized version of APPEND: template<class l, class r> struct APPEND : APPEND<typename l::eval, r> {}; // #1 template<class lh, class lt, class r> struct APPEND<CONS<lh, lt>, r> // #1.A : CONS<lh, APPEND<typename lt::eval, r> > {}; template<class r> struct APPEND<NIL, r> // #1.B : r {}; // #2 Notes: #1) Only the `l' parameter is forced (or explicitly invoked). It would be an error to invoke the `r' parameter. #1.A and #1.B) The explicit invocation of the `l' parameter reveals the substructure of the `l' parameter for pattern matching. (Note: I use pattern matching for simplicity. Lazy metaprogramming should be doable without pattern matching. I also have no more sympathy for lousy compiler implementers. RANT: How many years does it take to correctly implement a language (C preprocessor) described in about 20 pages of prose? For some it seems to take more than a decade.) #2) Yes, the template really inherits from `r'. The way the lazy metaprogramming library is designed is to require "foreign" types to be explicitly BOX<>:ed. IMO, the minimal cost (notation, readability) of boxing (which can mostly be hidden anyway) is insignificant compared to the semantic simplicity offered. Essentially, we can now read a structure definition as an equation: f p = expression // Haskell template<class p> struct f : expression // Lazy C++ metaprogram ... The following snippet is from the (old) thread cited above: Aleksey Gurtovoy: >I considered and re-considered the idea a couple of times during >MPL development. It doesn't really work well; in particular, it >conflicts with the notion of nullary metafunctions, pretty much >making the library useless for manipulating the latter ones: [[ I wont quote more. Please lookup the message yourself. ]] Well, looking at the code that Aleksey shows, I see that laziness is *not* used systematically like in the lazy metaprogramming library. The rule is that a lazy metafunction may only invoke an parameter if it really has to. In particular, the following line (not the only line) of the push_back example Aleksey Gurtovoy: > , typename T::type // apply0<T>::type would be (clearly) incorrect, because it invokes the parameter T. The push_back metafunction doesn't need to examine the substructure T and therefore should not force it to be evaluated. In other words, the push_back metafunction is not supposed to be strict in the T parameter. *NOTE*: The code in the cited thread is probably even more "confusing" than ordinary strict metacode that essentially contains evaluation order annotations. Please do not confuse the programming style used in the cited thread with the programming style used in the lazy metaprogramming library. They are very different. In particular, explicit invocations are used in the lazy metaprogramming style only for two purposes: 1) When a primitive metafunction *explicitly* has to examine the substructure of an actual parameter (e.g. to check whether a list is NIL or CONS<h, t> or to get the value of an integer or boolean parameter). 2) *Optionally* for (safe) optimization based on strictness analysis. >One thing, though: Why the very non-Boost style identifiers (lower >case template parameters, and upper case template names), such as: The upper case naming is the last thing you should worry about. :) Some reasons: * I don't like trailing underscores, e.g. `if_' and `int_'. * I had the idea of making a lazy metaprogramming library while I implemented a template metalanguage interpreter (similar to http://lists.boost.org/MailArchives/boost/msg36510.php, but with some fresh ideas). In the language I used upper case identifiers for "keywords" of the language and lower case identifiers for everything else. When I started implementing the lazy library, I ended up using upper case identifiers (and haven't bothered to rename globally). >Writing pp-code (using uppercase characters) a hard habit to break? ;) Not really. On the other hand, I rarely program in C++ these days, but when I do, I usually play with metaprogramming techniques. >Come to think of it, the "Generative Programming" book had the >same convention of upper case names for metafunctions. The GP book used upper case identifiers for control structures like IF, WHILE, FOR, etc... and for the "keyword" like names such as RET. -Vesa Karvonen _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.com/

4 4

Re: Lazy Metaprogramming Library
by Vesa Karvonen 17 Nov '04

17 Nov '04

Terje Slettebø: [...] >From my experience, the world of metaprogramming is full of cases of >independent discovery [...] ...or rediscovery of things that the functional programming community has known or had for a long time. Of course, there is absolutely nothing wrong with that. Unfortunately, functional programming still isn't something that would, for instance, be taught to all computer science / software engineering students. For instance, there is no compulsory course at the CS department of the University of Helsinki that would introduce functional programming. This is a shame, in *my* opinion. >I guess one thing one may learn from this all is that it doesn't matter who >tells you something is a bad idea, if you're not convinced yourself that it >is (which I wasn't). Yes. It is always a good idea to really seek to understand the issues rather than take a statement as true. However, I'm not really surprised that it took quite a bit of time to discover Lazy TMP (lazy template metaprogramming). (And the case for Lazy TMP is still open, of course.) The concepts of lazy evaluation and purely functional programming are not the kind of concepts one normally thinks about when programming in C++. >By the way, Aleksey has also mentioned that the functional influence on MPL >is much inspired by you. If Aleksey has said that, then I'll take it as a compliment. I think that Aleksey has designed an impressive metaprogramming library. I must say, however, that if I hadn't been talking about functional programming a few years ago, then others would have. > > Ever since I first used template metaprogramming, I have been > > searching for a template metaprogramming "style" (a minimal and > > unambiquous set of rules to follow), that would make template > > metaprogramming as simple as ordinary programming. [...] >It seems your search is similar to what lead you to your Order PP-library. >:) (You also mention this later in the mail) Search, yes. Although I didn't mention the Order metalanguage for C preprocessor in my previous mail. (The documentation of Order is still unfinished, which is the reason I'm not drawing more attention towards it.) > > As you can see, all explicit invocations are eliminated. I think > > that there is a huge difference between applying laziness in an > > essentially ad hoc manner (little here and little there) rather than > > applying it systematically (all metafunctions are lazy). > >Absolutely, it's a fundamental difference, and crucial for the >interoperability of the components of the library. Yes, indeed. When I started working on the proof-of-concept library, I didn't immediately realize that one could, in principle, eliminate all but just the invocations that are eplicitly needed. I also didn't immediate understand that (with the aid of BOX<>) essentially all metafunctions could use inheritance (or metafunction forwarding). Although the idea of (systematically) Lazy TMP is simple (IMO), the process of getting to the idea was not straightforward. All the early articles and books (I've seen) on template metaprogramming essentially used Strict TMP. >I didn't pursue this further at the time, as it would require a >fundamental change [...] (unless one made one's own [...] proof >of concept, as you've done). I find it imperative to try out new ideas by implementing them in a smaller scale. Quite often it takes a lot of experimentation to reach the simplest solution. [I'm rarely truly satisfied with any of my own code.] > > template<class n> struct FACT [...] > > template<long n> struct FACT<INT<n> > [...] > > template<> struct FACT<INT<0> > [...] > >This is quite similar to how Loki does this, as well: using >specialisations for decisions, or pattern matching (the latter >being another common thing in FP languages). The use of pattern matching (or specializations) isn't really fundamental to Lazy TMP. In other words, Lazy TMP is orthogonal to the use of pattern matching or nested value/type definitions. I'm using pattern matching in the proof-of-library, because it can sometimes make things easier (to implement and understand). For example, the factorial function could be written like this: template<class n> struct FACT : INT<STRICT_FACT<n::value>::value> {}; Above, STRICT_FACT-would be a straightforward Strict TMP implementation of the factorial function. Also, the lazy CONS<>-constructor could be defined like this: template<class h, class t> struct CONS { typedef CONS<h,t> eval; typedef h head_type; typedef t tail_type; }; And lazy algorithms on lists would use the nested head_type and tail_type definitions instead of pattern matching. > > template<class l, class r> > > struct APPEND > > : IF<IS_NIL<l>, > > r, > > CONS<HEAD<l>, > > APPEND<TAIL<l>, r> > > {}; > > > > It is easy to see that APPEND is strict in the `l' parameter, > > because it is *always* examined by the conditional. > >*packs some ice-bags on his head* Go on.:) No, really; I'm fine. ;) ;) >Also, after reading the above a few times, it made complete sense. It just >took a moment to grok this concept of using both strict and non-strict >parameters in the same algorithm. :) Good! >Just when I thought I had grokked metaprogramming. ;) As Dave already pointed out, this has more to do with functional programming in general than template metaprogramming in particular. Issues like this are often explained (at some level) in books that introduce functional programming (particularly lazy functional programming). One interesting source for relevant information would be books and articles on programming language semantics. Here is one book I've read recently: http://www.cis.ksu.edu/~schmidt/text/densem.html The book doesn't discuss lazy functional programming at length, but it does discuss issues that relate to strictness. > > struct INFINITE_LIST_OF_ONES > > : APPEND<LIST<ONE>, > > INFINITE_LIST_OF_ONES> {}; [...] > > If APPEND<l,r> would force the evaluation of the `r' parameter the > > above definition would not work correctly. (Can you see why?) > >Oh, yes, you'd get an infinite recursion, wouldn't you? (I've experienced a >few of those in metaprogramming...) One could say so. What would essentially happen is that APPEND<LIST<ONE>, INFINITE_LIST_OF_ONES> would be defined in terms of APPEND<LIST<ONE>, INFINITE_LIST_OF_ONES> which doesn't work, because it isn't defined yet. One runtime analogy would be something like T x = x; > > RANT: How many years does it take to correctly implement a > > language (C preprocessor) described in about 20 pages of prose? > > For some it seems to take more than a decade. > >Do I detect a hint of bitterness? ;) Let's just say that I find the current situation unsatisfactory and the only party that (IMO) really has the power to make things better is the compiler vendors. >I'm sure Paul Mensonides is struggling with similar things, his Chaos >library being only usable on the most conforming compilers (from what I >understand). As Paul already replied, both Paul's Chaos library and my Order metalanguage have been developed only with/for conforming (enough) preprocessors so there has been no need to struggle with workarounds --- a most liberating feeling I should say. >I guess some of the reason might been that it hasn't been much of a >priority >for compiler vendors. It's rather unlikely that a huge number of customers >come to them, asking for better preprocessor support... :) > >On the other hand, with PP-programming having been become more >"mainstream", >being used quite a bit in Boost, for one thing, this might change. Well, I kind of hope so---it would at least open the door for new possibilities in C and C++ programming---but I think that it is unlikely to happen in the short term. Also, I'm not sure what the best course of action would be in the *long* term (say 20 years from now). > > #2) Yes, the template really inherits from `r'. The way the lazy > > metaprogramming library is designed is to require "foreign" types to > > be explicitly BOX<>:ed. > >Like using mpl::identity<>. There are some similarities, yes, but it is important to distinguish between the separate concepts. The Strict TMP identity-metafunction is considerably different from the BOX<> of Lazy TMP. In particular, identity<T>::type == T but BOX<T>::eval == BOX<T> In other words, a BOX<T> evaluates to itself (BOX<T> is idempotent). This is perhaps a bit confusing due to the fact that in Strict TMP there is no concept of "evaluation" distinct from accessing a nested type. In Lazy TMP, the boxed type can be accessed using an invocation: BOX<T>::type == T Of course, one can also implement an IDENTITY function in Lazy TMP. It would obey the equations: IDENTITY<T>::eval == T IDENTITY<BOX<T> >::eval == BOX<T> IDENTITY<BOX<T> >::type == T -Vesa Karvonen _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

1 0

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

17 Nov '04

> From: John Torjo <john.lists(a)torjo.com> > Subject: Re: [boost] Re: Points vs Vectors / GUI Library Proposal for > > To: boost(a)lists.boost.org > Message-ID: <418F48F8.9050002(a)torjo.com> > Content-Type: text/plain; charset=us-ascii; format=flowed > > > > Back on the subject of a GUI library: I understand the motivation - > > that's where wxWindows arose. And I realise that nowadays a GUI library > > could be done in a much more modern C++ style. But my question is: is > > C++ the right language? I don't want this to descend into a religious > > war - C++ is my favourite language, but it isn't the best language for > > I would say so ;) For instance, you can abstract away a lot of stuff > (true binding of data to GUI controls): > http://www.torjo.com/win32gui/save_dlg.html > > Also, I want to allow, in the future, to bind STL containers directly to > GUI list controls. > > So, I would say a higher level language won't be of help here - because > you would need to convert your data and send it back and forth. Yes - this was the one major benefit that I could think of when I wrote my original reply. But once you've exposed the data in question to the scripting language of your choice, you gain quite a bit: - By attaching validation routines and the like in your scripting layer, you can tune these without having to rebuild your program, or even restart it if you're lucky. - You can plug data and validation routines into UI elements using your UI design tool! - You can also expose the resulting bindings at the application level for things like scripting support. > I remember the days when I used to do the UI in VB - it was quite a > mixed feeling... Yes, I can see how that might put one off 'higher-level' languages :) > > every task. Would a higher-level, more dynamic language be more suitable > > for GUI work? In a perfect world, I'd do all my back-end stuff in C++ > > sometimes, certainly > > > and all the front-end development in, say, Python. By doing all the GUI > > work in C++ instead of an interpreted language, you: > > a) spend a lot more time recompiling. > > that is unfortunately true :( > > > b) can less easily tweak a running program to try out different ideas. > > We're missing a good GUI designer... But we're slowly getting there ;) The GUI designer can't help with attaching data, validation routines or anything else, unless those things are exposed to script. > > c) have to spend a lot of effort to construct a domain-specific language > > (c.f Spirit; see (a)). > > Not sure what you mean... Spirit goes to great lengths to make C++ look like a language for declaring grammars. It's a huge chunk of beautifully crafted template magic, that's clearly taken much time and effort. Because of its size, recompiling the parser you build with spirit takes a very long time (hence the reference to (a)). A parser generator such as ANTLR does the same job much quicker[1]. Similarly, you've constructed an elegant way of linking data, validation routines and UI elements together, from C++. Your usage examples are concise and expressive. But does that justify the sheer weight of header files that they require? One could write probably less than half as much code to deliver similar results using Pyrex and Python. It wouldn't run quite as fast as your code. But it would give a smaller, more versatile runtime. In fact, there's an embryonic project to do just that at: http://nz.cosc.canterbury.ac.nz/~greg/python_gui/ > > d) probably end up with a bigger codebase. > > why so? Because C++ isn't the tersest of languages :) George

11 34

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