- Boost - lists.preview.boost.org

[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

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

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

16 Nov '04

Hello, can any compiler expert give me feedback on whether there should be a noticable difference in compilation speed between the following two meta-functions: template<class N, class M, class Q, class P> struct foo : mpl::plus < N, typename mpl::minus < M, typename mpl::divides < Q, P >::type >::type >::type {}; and template<int N, int M, int P, int Q> struct foo { enum { value = N + (M - (Q/P)) }; typedef boost::mpl::int<value> type; } The second version saves me a lot of template instantiations and many header inclusions, at the cost of losing some genericity. On the other hand, if the calculation becomes complicated, I find myself using many enums to hold intermediate values, resulting in code like the following: template<class T> struct next_number_with_same_num_bits { enum { lowest_bit_set = T::value & (-T::value), lowest_bit_set_index = count_leading_zeroes<T>::type::value, next_t = T::value + lowest_bit_set, next_lowest_set_bit = next_t & (-next_t), mask = next_lowest_set_bit - lowest_bit_set, result_t = next_t | (mask >> (lowest_bit_set_index + 1)) }; typedef boost::mpl::int_<result_t> type; }; which leads MSVC to run out of so-called compiler-keys much quicker than if I reduce the above to the completely unreadable: template<class T> struct next_number_with_same_num_bits { enum { result_t = (T::value + (T::value & (-T::value))) | ((((T::value + (T::value & (-T::value))) & (-T::value - (T::value & (-T::value)))) - (T::value & (-T::value))) >> (count_leading_zeroes<T>::type::value + 1)) }; typedef boost::mpl::int_<result_t> type; }; Does anybody have any thoughts or comments on this technique, and is anybody else using tricks around MPL to make sure your compiler still handles things? Thanks, Jaap Suter

2 1

performance using accumulate, bind, and make_transform_iterator
by Richard Newman 16 Nov '04

16 Nov '04

I'm a newbie to the list; if an answer to my question is in a FAQ I'm not aware of, please let me know; but I've googled the documentation and don't see it. In fact, I see little regarding performance factors to consider when using boost, so I may not be looking in the right places. We're running a performance-sensitive application and so I've begun to find points to optimize the code. The following is a digest of our experience bringing boost functionality into this effort (forgive the generic code; it was sanitized for intellectual property perservation, etc.): I am posting this experience in hopes that someone can confirm our reasoning and perhaps point us in the right direction for information, etc., for thinking through these kind of issues in the future. Any advice is appreciated. You'll see that, in part, my woes came from violating the cardinal rule of only optimizing that code which is most expensive; nonetheless, this specific instance is an involved enough example that I thought it worth pursuing... ============== During the writing of an interface, a function was added to a templated class, that has-a stl vector, to sum SomeValue of its contained elements: const unsigned allElementsValue() const { unsigned result = 0; std::vector<T>::const_iterator thisElement(sequence_.begin()); const std::vector<T>::const_iterator endElement (sequence_.end()); while (thisElement != endElement) { result += thisElement->getSomeValue(); } } At the time this interface was being written, it was a departure from an prior approach and so it was important that performance was not significantly affected. During this effort, we used KCachegrind and found out that this call was (relatively) more expensive than hoped. Since std::accumulate was supposed to be a quicker way to walk through elements, that approach was tried and the following function resulted: const unsigned allElementsValue() const { unsigned result = 0; return std::accumulate ( boost::make_transform_iterator (sequence_.begin(), boost::mem_fn(&T::getSomeValue) ), boost::make_transform_iterator (sequence_.end(), boost::mem_fn(&T::getSomeValue) ), 0 ); } We now note the use of make_transform_iterator and the use of a 0-ary member function of the constituent element objects. This code is semantically equivalent and yet yielded an relatively significant performance improvement. The performance increase can be taken in part to considering that STL and boost use templates and so some of what why otherwise have to be done at run-time can now be done at compile-time. So we naively took the moral of the story to be that std::accumulate is Good and walking through elements manually with a loop is Bad. The following code was later examined. Note that this particular code happens to be executed many, many times in our run. So any performance change to this code will have a major effect to the overall performance of the program. Certainly a ripe and ready candidate for applying this new conclusion. The code was changed from this... ----------- // Note that a and b (referred to in calcSomeValue below) are // references to other objects passed into the function that // has this code float result = 0.0; // SomeObjectPtrCont is a typedef for a stl vector that contains // boost::shared_ptrs managing pointers to SomeObject. // SomeObjectPtrs_ is an instance of SomeObjectPtrCont SomeObjectPtrCont::const_iterator thisIter(SomeObjectPtrs_.begin()); const SomeObjectPtrCont::const_iterator endIter (SomeObjectPtrs_.end()); while (thisIter != endIter) { result += (*thisIter)->calcSomeValue(a, b); ++thisIter; } ----------- ...to this: ----------- // Note that a and b (referred to in calcSomeValue below) are // references to other objects passed into the function that // has this code float result = 0.0; // Use a typedef so that we can handle overloading of calcSomeValue typedef float (SomeObject::* calcFunct)(const T&, const OtherObjB&) const; // Use stl accumulate to do same thing as the while loop result = std::accumulate ( boost::make_transform_iterator ( SomeObjectPtrs_.begin(), boost::bind(static_cast<calcFunct>(&SomeObject::calcSomeValue), _1, a, b) ), boost::make_transform_iterator ( SomeObjectPtrs_.end(), boost::bind(static_cast<evalFunct>(&SomeObject::calcSomeValue), _1, a, b) ), float(0.0) ); ----------- Note that this is a significantly more sophisticated use of std::accumulate with boost::make_transform_iterator and boost::bind. Indeed, now bind must take an argument, marked by the _1, to link the function being called, evaluate, with each element in the collection being walked through. The evaluate() function itself is binary and not a member of the constituent elements. Nonetheless, it is semantically equivalent to the more conventional while loop form. Remembering our earlier simplistic conclusion that std::accumulate is Good and that while-loops are Bad, this change was made, checked in, and pride swelled within the author (silly me) for so cleverly using boost, et al. The expectation at the time was that since templates would be involved more, then much of the logic would be resolved at compile-time rather than run-time giving us a performance increase just like with the simpler accumulation approach (basically since one form of accumulation is good, than all are better). We discovered that the revised code now ran 4 times SLOWER. KCachegrind showed the problem was the above code. So what the *&^% gives? Rather than analyze the situation, it's always better to tinker :), so the next attempt involved an approach that std::accumulate also allows: ----------- // Note that a and b (referred to in calcSomeValue below) are // references to other objects passed into the function that // has this code float result = 0.0; // Use a typedef so that we can handle overloading of calcSomeValue typedef float (SomeObject::* calcFunct)(const T&, const OtherObjB&) const; // Alternate accumulation approach result = std::accumulate ( SomeObjectPtrs_.begin(), SomeObjectPtrs_.end(), float(0.0), boost::bind (std::plus<float>(), _1, boost::bind(static_cast<calcFunct>(&SomeObject:calcSomeValue), _2, a, b) ) ); ----------- This sped up the code but now it was measured to be 3 times slower than the original form, though now not 4 times as slow. Hardly a ringing endorsement for the use of std::accumulate. Our best conclusion so far is that involving boost::bind in this kind of operation causes accumulate to go through additional function redirection at run-time to access the final evaluate() function desired. This more than offsets any potential gain that might have been realized by the std::accumulate because now its use of templated compilation is thwarted by all of this run-time redirection. Note that because of the arguments involved, the compiled code under boost::bind must now move variables onto the stack so that when the underlying accumulate calls this implicit functor, those values are part of its state. All of this is now done at run-time where as before, without having to move such variables, it was really just a change of a function pointer's value. So, the new current thinking is that std::accumulate is Better than simple while-loops that walk through elements which is still Bad. However, boost::bind under std::accumulate is Worse. At this point, the best advice is that one should use std::accumulate whenever simple accumulations are needed. However, once one has to start involving boost::bind on 1+-ary functions or anything else that requires new run-time function redirection, then retreating back to while-loop is a better performance solution. Thank you all for reading this far... Kind regards, Richard Newman Crowley Davis Research richard(a)nospam.cdres.com (take out the nospam. to email me directly)

4 8

1_32_0 final test python issue
by Russ Gibson 16 Nov '04

16 Nov '04

The latest 1_32_0 (downloaded today - 2004-11-15 at around 13:30 PST/-0800) failed to build the python libs because of "python22.lib" references in a link. I have python 2.3 installed, and have the python environment variables set like this: PYTHON_ROOT=C:\python23 PYTHIN_VERSION=2.3 PYTHON_LIB_PATH=C:\Python23\libs My WinXP system is brand newly set up (from major crash), so there aren't any strange things going on (i.e. no other python's in path, etc.). I have cygwin installed, but none of the cygwin stuff is in my path (or any other environment variables for that matter), so I'm confident that isn't a problem. Besides, it also has python 2.3, not 2.2. I actually used vsvars32.bat to get the build environment for boost. Everything else (that wasn't dependant on boost python) build fine. Anybody know anything about this? (Be sure to reply-all if you reply to this, unless you don't mind long delays for a response). --> Russ

2 1

Ideas for logging/tracing
by Alexander Nasonov 15 Nov '04

15 Nov '04

I have a couple of ideas about making function traces nicer: 1. Use of PP_SEQ interface to "parse" function name and arguments int X::foo(char* buf, size_t len) { BOOST_TRACE_MEM_FUN( (foo)(buf, len) ); // ... } Function name can be extracted with BOOST_PP_SEQ_ELEM(0, fn), the arguments with BOOST_PP_SEQ_POP_FRONT(fn). BOOST_TRACE_MEM_FUN macro could expand to: tracer tracer_line_N(this, "foo", "(buf, len)", resolve_args (buf, len)); 2. In addition to text format, produce XML output. This opens up a possibility for XSLT convertion to UML sequence and collaboration diagrams (XMI). -- Alexander Nasonov

4 15

[iterator] Why no assignment operator for filter_iterator?
by David M. Jones 15 Nov '04

15 Nov '04

Is there a reason why filter_iterator has no assignment operator? I have a place in my code where I want to perform an assignment of filter_iterators. Can anyone suggest a work-around? Thanks in advance, David Jones

2 2

1.32 Draft Tarball: MPL docs completely missing?
by Stefan Slapeta 15 Nov '04

15 Nov '04

Currently, mpl/doc/index.html shows this information: The Boost MPL library documentation is currently undergoing a major overhaul for the 1.32 release. Please come back in a few days. :-( Stefan

2 1

[graph] bellman_ford_shortest_paths interface
by Vladimir Prus 15 Nov '04

15 Nov '04

Hi, after trying to use the bellman_ford_shortest_paths I think it's a little bit strange. First of all, user is required to initialise distance map before calling the algorithm. The distance to the source vertex must be set to zero and distances to other vertices to infinity. Why can't the algorithm accept a source vertex as parameter and do initialisation itself? Dijsktra surely does not require such initialization. Another problem is that number of vertices is passed as parameter. I realize this is more flexible (for example I can compute the maximum length of all paths with less than N edges), but it's also confusing and dangerous. I've just passed a wrong variable to that parameter and spend quite some time debugging. Is it possible to provide a version of the algorithm which (1) takes just graph, without vertex number parameter (2) takes start vertex, and initialises distance map itself - Volodya

2 6

Still OK to merge changes into 1.32.0?
by Beman Dawes 15 Nov '04

15 Nov '04

I've just fixed a minor Windows only filesystem::path bug in the CVS head. Is it OK to merge the fix into 1.32.0, or is 1.32.0 closed? --Beman

2 3

[1.32 release] RC_1_32_0 branch is closed for any modifications
by Aleksey Gurtovoy 15 Nov '04

15 Nov '04

Please see the subject. If you think that something just *has* to be committed to the branch, please post a query to the list before doing so, however trivial the change is (this includes fixes to the documentation and likes). Thanks, -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

[BGL] Determining whether a path exists from vertex U to vertex V
by David M. Jones 15 Nov '04

15 Nov '04

I have looked at the BGL User Guide/Reference manual book but I can't seem to find the answer to this seemingly basic question. I have a directed BGL graph. Given two vertices U and V, I want to know whether there is a path from U to V. I don't care what path it is; I just want to know whether one exists or not. It looks like I might be able to use the BFS or DFS to do this, but that seems like attacking a mosquito with a tank. A slightly more complicated problem that I want to solve is: given vertices U and V, I want to know whether there is a path from U to V such that all edges along the path have a certain property. Again, I don't care to know what the path is or its length; only whether or not such a path exists. Thanks in advance, David Jones

3 3

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

15 Nov '04

> Message: 11 > Date: Fri, 12 Nov 2004 22:18:53 +0200 > From: John Torjo <john.lists(a)torjo.com> > Subject: Re: [boost] Re: GUI Library Proposal for a Proposal > To: boost(a)lists.boost.org > Message-ID: <41951AAD.20208(a)torjo.com> > Content-Type: text/plain; charset=us-ascii; format=flowed > > >> >> You have made a good point. I still feel uncomfortable about parsing >> header >> files to determine type information. If header files were used, since >> run-time reflection does not exist, one would have to inject the >> correct >> code into source files based on design-time decisions. But it does >> seem as > > I think reflection in general is very different from reflection for a > GUI. > > When you have a GUI control, you want to apply reflection for a few of > its properties. You won't have #ifdefs (or at least I would consider it > bad design). Case in point: its interface should be extremely simple > and > easy to parse. > > You shouldn't need complex information like reflection for virtual > functions, overloading etc. > > 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. > > 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 *think* what you envisage is based around collecting data from the user via dialogs. So in your view of things, there would be a C++ object that holds the collected data, a set of validation routines, and a reflection map that binds these to the UI. But you don't do anything to the program state until the user clicks "OK" in your dialog, at which point you suck the data out of your simple C++ object and act on it. In contrast, other people (myself included) are considering binding properties and member functions to the UI for similar purposes to why you would expose them to script: to allow the user to drive them. So, for a simple example, let's suppose you have some object that corresponds to a file: class file_backed_t { public: std::string get_filename(); /// This actually renames the file on disk. void set_filename( std::string const& ); }; Now, when you bind the filename property to the UI, you'll automatically do the rename as soon as the user changes the text in the edit box. (Probably that isn't the desired behaviour in this case, but it serves as a demonstration.) This usage pattern corresponds better to modeless dialogs where you don't have an "OK" button. Of course if you are using a generalised reflection architecture like I mentioned yesterday, then you can do both approaches: > One of the things that I noticed about serialisation code is that > there's > generally a symmetry between the reading and writing routines. So > rather > than write "this is how I load an X, and this is how I save one" I'd > want to > write "these are the things in X that need to be saved" and let some > templates figure out what the corresponding routines are. And then it > was > this desire to serialise things automatically by specifying properties > that > led me on to think about a common architecture for language binding and > serialisation. Maybe in the end you'd get declarations like: > > /// Properties for serialisation > boost::properties< my_t, "my_t", boost::serialisation > > .def( "my_int", &my_t::my_int, &my_t::set_my_int ) > // After serialisation format version 4,a > // my_float no longer needed to be serialised > .def( "my_float", &my_t::my_float, &my_t::set_my_float, > boost::serialisation::in_format_version_range<>( 0, 4 ) ) > ; > > /// Properties for scripting > boost::properties< my_t, "my_t", boost::langbinding > > // Use serialisation properties to implement pickling. > .def_pickle( default_pickle_suite< my_t >() ) > .def( "my_int", &my_t::my_int, &my_t::set_my_int, > boost::langbinding::return_internal_reference<>() ) > // We don't want to bind my_float, for whatever reason. > ; boost::properties< file_backed_t, "file_backed_t", boost::gui > // This is a heavyweight property for a modeless dialog .def( "filename", &file_backed_t::get_filename, &file_backed_t::set_filename ) ; // dialog_data_t is just a struct to store data for a modal dialog till // the user clicks "OK", which is when we process it. struct dialog_data_t { std::string filename; // Says whether to back up the specified file before // processing it. bool make_backup; }; // Helper function for dialog_data_t reflection. bool is_good_filename( std::string const& ); boost::properties< dialog_data_t, "dialog_data_t", boost::gui > .def( "filename", &dialog_data_t::filename, boost::gui::validator( &is_good_filename ) ) // No validation required for this simple bool. .def( "make_backup", &dialog_data_t::make_backup ) ; George

2 1

Some problems with shmem vs. thread jam building
by ION_G_M 15 Nov '04

15 Nov '04

Hello to all, I keep on working on a shared memory boost library proposal. I've followed Boost.Build guidelines to write the jam file, and auto_link header, but when writing and executing the jam file I have the following errors (I'm new to jam and dll building, so forgive me if you find any question too simple): 1) DLL-s I wanted to reuse detail::thread::lock class for process shared mutexes in order to follow the same structure as thread::mutex, but when building my library dll-s from boost root using bjam "-sTOOLS=vc-7_1" stage/install the linker complains that it can find thread library dlls (I suppose due to auto_link headers). I don't know if linking a dependant library is needed when building a dll (in my embedded world, i never design dll- s so I don't know that). If the library is needed, should I specify a <library-path> for that in dll building rule? If not needed, do I have to define a symbol to disable auto_link feature for boost::thread in my dll rule? 2) boost::thread config Apart from this, when building static libraries, I can't compile boost::detail::thread::scoped_lock if I use it as main locking scheme for process shared mutexes when building single threaded shared memory static library, since thread headers check for correct multithread configuration (I suppose looking for _MT defines). - - - - - - - - - - - - For the moment I've decided to copy thread scoped_lock to my library changing the namespaces so that I can compile my library and continue integration. I would like to know if it is convenient to reuse thread scoped_locks for process shared mutexes. For a simple proposal that can be easily rejected, I'm not requesting any change, but I would like to point out that maybe scoped_locks should be reused for both thread and process shared mutexes in the future. But my main concern is the linker error when building a dll for a boost library that depends on other boost library. Best regards, Ion Gaztañaga

2 1

transparent INF - does it exist
by Manfred Doudar 15 Nov '04

15 Nov '04

c/- All: In taking a holistic look at some of the work I do, I've come to realize a need for a "transparent" data type, and wondering whether or not it exists. As all of you would have experienced, any organization has such a representation of such a type; be it called: "Null value", "Missing value", "Fill value", "Infinity" , or whatever. What I am hoping for is support for such an representation, with existing containers and algorithms; such that if you perform any mathematical operation, (arithmetic, transcendental; inverse; anything really ...); that you get back the *same* object (ie. it passes transparently through any operation), and not raise any exception if you so choose. Example: missing_val == atan(missing_val) - missing_val; missing_val == 1 / missing_val; missing_val == missing_val + missing_val; missing_val == missing_val - missing_val; typedef std::vector<any_type> dVec; dVec some_vector; ... populate some_vector ... dVec::iterator = some_vector.find(missing_val); Boosters, do we have such a representation; is there value in having such a thing in Boost; is there a (simple) alternative work-around ?? All ideas and comments appreciated. Cheers, -- Manfred MetOcean Engineers

2 2

RE: [boost] Re: GUI Library Proposal for a Proposal
by Brian Braatz 15 Nov '04

15 Nov '04

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Edward Diener > > Brian Braatz wrote: > > (was RE: [boost] Re: GUI library - something to think about) > > > > Both > > http://www.torjo.com/win32gui/save_dlg.html > > > > and > > > > http://www.litwindow.com/Library/Documentation/documentation.html > > > > are extremely interesting. > > > > What I see (just after taking a peek at both): > > > > Win32Gui > > Interesting design > > No macros > > Looks tied to Win32Gui > > > > LitWindow > > Also interesting design > > Does have macros > > Also sits on top of WxWidgets, but it looks like the WxWidgets > > layer could be abstracted out. > > > > I propose that BOTH authors collaborate (on this list) to achieve the > > following: > > > > * Combination of the best of both frameworks > > * Can sit on WxWidgets OR can have a win32 and xwindows underlying > > implementation > > No !!!!! WxWidgets has almost nothing to do with modern C++. Let's no go > there, or have anything to do with supporting any other GUI > implementation. > > [Brian Braatz] PLEASE Re-Read my words. "> > * Combination of the best of both frameworks > > * Can sit on WxWidgets OR can have a win32 and xwindows underlying > > implementation" If you have a good abstraction - then the ability to "plug in" the underlying implementation (through various mechanisms) means you are not tied to WxWidgets. This also means that conversely, you CAN take advantage of something in WxWidgets (or qt, or win32 or whatever) if you so desire. Boost::gui should not be trying for a kitchen sink approach (like WxWidgets or Qt), but instead would provide a simple and clean abstraction for common functionality. I will always (or frequently) have to write WxWidgets specific code or os specific code, but having a abstraction available from boost would mean most of my code would be portable across framework. I suggest a "first cut" would have a xwindows "plug in" and a win32 plug in, and potentially a WxWidgets and or Qt It is more than practical to have the boost gui abstraction cover the most common concepts. This not only makes it small and easy to implement, but also allows me to write directly to WxWidgets where it makes sense. This is what I would call "having balance" between a standard approach and still allowing for a developer to have the choice to take advantage of specific OS or gui framework feature as they desire. The fact that WxWidgets does not have "modern techniques" is a plus for boost::gui. The fact that WxWidgets is huge and covers a lot of things (and has been around for awhile) is a plus for them. A well designed "gui abstraction layer" would have the following properties: * move the technology of binding forward * Not try to be everything for everybody * allow for the choice of being able to write "boost standard gui code" vs taking advantage of whatever specific thing you are working with These principles, also have the advantage of placing a combination of ltwindows and win32gui in a spot where a combination of the two would in fact meet those properties. AND it would be accomplishable in a short timeframe. And that, is my point :)

4 6

[1.32 release] is the codebase already frozen?
by JOAQUIN LOPEZ MU?Z 15 Nov '04

15 Nov '04

Some days ago an imminent codebase freezing was announced, but I won't know whether it is already in effect. Do I still have time to fix some things in my library? The fixes are not crucial, so I can as well wait after the release is out, but well if granted a day or two I'd prefer to address this now. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

[Variant] Sample doesn't compile because of missing 'const'
by Stefan Slapeta 14 Nov '04

14 Nov '04

In the code sample in 'Binary visitation', the const modifiers for the two operator () are missing; thus, the sample doesn't compile at all! Stefan

2 1

Re: BOOST_LOG
by Reece Dunn 13 Nov '04

13 Nov '04

Eljay Love-Jensen wrote: > Hi Reece, > > You'd have to run the source code through the pre-processor twice to remove > the comments. > > Comments are stripped out first, then macro-expansion. (Not surprisingly, > Microsoft's compiler is non-compliant, and the trick works on their > platform.) How about: class null_log { public: template< typename T > null_log & operator<<( const T & ) { return *this; } }; null_log log; #define BOOST_LOG(id) log This should work and a good compiler should be able to optimize away the log output, leaving only the small footprint of the global variable. It also has the advantage of being multi-line compatible: BOOST_LOG(dbg) << "message: " << foobar; Regards, Reece

1 0

[ANN] Format Lite
by Jonathan Turkanis 13 Nov '04

13 Nov '04

Dear All, I've just finished documenting a small library, available here: http://home.comcast.net/~jturkanis/format_lite/ It's a lightweight version of Reece Dunne's recently reviewed Output Formatters library. It was inspired by the discussion of Reece's library on this list and by the discussion of TR1 tuple i/o at the recent standards committee meeting in Redmond. ----- Format Lite is a lightweight, easy-to-learn framework for formatting data structures such as standard library containers and Boost tuples. It provides a reasonable degree of customizability with an emphasis on human-readable output formats useful for testing and debugging. A future version of Format Lite could be a candidate for incorporation into C++0x, to compensate for the lack of standard iostreams inserters and extractors for standard library containers, and to make existing inserters and extractors - such as those provided in <complex> - more flexible. Format lite provides three function templates: * boost::io::punctuate, used to specify punctuation sequences and options for line-breaks and indentation. * operator<<, used to insert ranges and tuple-like objects into standard output streams. * operator>>, used to extract ranges and tuple-like objects from standard input streams. ----- Best Regards, Jonathan

9 27

Testing interest for a shared memory/STL library proposal
by Ion Gaztañaga 13 Nov '04

13 Nov '04

Hello to all, My name is Ion Gaztañaga, a telecommunication engineer working in railway industry R&D . I've been lately working on a CUJ article about placing STL containers (and any other object) in shared memory using smart pointers instead of raw pointers as allocator::pointer. The article has been accepted for a future issue and is currently in a editing/reviewing phase. Working in this article, I've created a library/framework, developing some classes that I think can be useful for a new boost library. I would like to know if there is any interested in boost for developing such classes, based or not in my article ideas or code. If there is any interest, I would be glad to present a boostified version of the library/framework for a review proccess. Currently, the framework uses these ideas: -> Relative pointers (smart pointers) for placing them in shared memory. -> OS basic mechanism abstractions: shared-memory creation, process-shared mutex, named semaphore -> Shared memory allocator for dynamic allocation/deallocation of parts of a shared memory segment. -> Named shared memory allocation manager, so that any process can look for an object in shared memory. -> Pooled shared memory allocator for node containers. -> Some STL-like container examples that can be placed in shared memory for systems with no smart-pointer allocator::pointer supporting STLs -> others... The framework works with Win32/Visual.NET 2003, QNX6.x/gcc-2.95.2,Mandrake Linux10.1/gcc-3.4.1 and partially (relative pointers and raw shmemory allocation) with Win32/VisualC++ 6.0. I've put a special full-length article in html and the source code in the file http://ice.prohosting.com/newfunk/boost_shmemSTL.zip, so that anyone can take a look. Please, you don't need to waste much time in the article, since I just want to know if contained ideas are interesting for boost. Please remember that some classes such as scoped-locks, etc... are in boost but I wanted the framework to be independent of any other library for this article. Of course, this would change in an hypotetic boostified version, since this is only to get an idea. Please, feel free to comment/critisize. Regards, Ion

6 7

Boost Iterable Range Library update (v1.5)
by John Torjo 12 Nov '04

12 Nov '04

Dear boosters, I have updated the Iterable Range Library (formely known as Range Templates Library). It makes dealing with containers/STL algorithms simpler by using ranges (as opposed to iterators). Simply put, a range is a smarter std::pair<iterator,iterator>. Here's a taste: for ( crange<some_array_type> r(some_array); r; ++r) do_something( *r, some_data); Also, the library provides wrappers for all STL algorithms (for the purpose of STL algorithms, all containers are ranges as well): typedef std::vector<std::string> word_array; word_array v; // STL version std::copy( v.begin(), v.end(), print); // rng:: version rng::copy( v, print); Also, the counterparts for STL algorithms that return an iterator will return a range, allowing for: // fill a vector with all the indexes at which a certain string is found std::string str = "I'm a cool programmer, really cool that is", find = "cool"; std::vector<int> result; crange<std::string> r(str); while ( r = rng::search(r, find)) result.push_back ( r.begin() - str.begin() ); And it provides for range adaptors, allowing for composition. bool from_ro(const employee & e) { return e.country == "Romania"; } std::string get_empl_name(const employee &e) { return e.name; } typedef std::vector<employee> array; array empls; // take all employees from Romania, and print their names rng::copy( transformed( filtered(empls,from_ro), get_empl_name), std::ostream_iterator<std::string>(std::cout," ")); Changes in this version: - improved algorithms.hpp (no more use of macros) - solved small bugs - added documentation Download it from here: http://www.torjo.com/rangelib/ Feedback is welcome. Best, John -- 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

10 27

Re: Generalised reflection
by George van den Driessche 12 Nov '04

12 Nov '04

> Message: 4 > Date: Fri, 12 Nov 2004 07:34:27 -0500 > From: "Neal D. Becker" <ndbecker2(a)verizon.net> > Subject: [boost] Re: Generalised reflection > To: boost(a)lists.boost.org > Message-ID: <cn2akj$qij$1(a)sea.gmane.org> > Content-Type: text/plain; charset=us-ascii > > George van den Driessche wrote: > > [...] > > Yes. Now imagine that I've got some helper functions for use with > > Boost.Python's pickling suite. But I want to use them with a C++ > > serialisation library. I'm going to have to factor a bunch of code out of > > those helper functions so that I can invoke them without using > > boost::python::tuple, and then write wrappers to use the factored-out code > > with the Boost.Python pickling suite. Instead, I want to write just the > > C++ serialisation code, and have that automatically wrapped up for use > > with Boost.Python pickling. It's a similar separation of layers. > > > > Incidentally, I wrote about sharing boost c++ serialization with > boost.python pickling, and posted code demonstrating this. Nobody seemed > very interested. I think it's this post: http://tinyurl.com/6dbhb that you're referring to. In which case, I missed it, but yes, you're on the same topic. One of the things that I noticed about serialisation code is that there's generally a symmetry between the reading and writing routines. So rather than write "this is how I load an X, and this is how I save one" I'd want to write "these are the things in X that need to be saved" and let some templates figure out what the corresponding routines are. And then it was this desire to serialise things automatically by specifying properties that led me on to think about a common architecture for language binding and serialisation. Maybe in the end you'd get declarations like: /// Properties for serialisation boost::properties< my_t, "my_t", boost::serialisation > .def( "my_int", &my_t::my_int, &my_t::set_my_int ) // After serialisation format version 4, // my_float no longer needed to be serialised .def( "my_float", &my_t::my_float, &my_t::set_my_float, boost::serialisation::in_format_version_range<>( 0, 4 ) ) ; /// Properties for scripting boost::properties< my_t, "my_t", boost::langbinding > // Use serialisation properties to implement pickling. .def_pickle( default_pickle_suite< my_t >() ) .def( "my_int", &my_t::my_int, &my_t::set_my_int, boost::langbinding::return_internal_reference<>() ) // We don't want to bind my_float, for whatever reason. ;

2 1

RE: [boost] [Review] Named parameters library
by Aleksey Chernoraenko 12 Nov '04

12 Nov '04

Hello, >[...] > http://groups.yahoo.com/group/boost/files/named_params.zip Is it possible to make a copy to somewhere else, more accessible place (http://sourceforge.net/projects/boost/) ? ---- Thank you, Aleksey Chernoraenko

3 2

[library process] should we more actively pursue university thesis projects?
by Thorsten Ottosen 12 Nov '04

12 Nov '04

Dear all, Following our discussion of the unicode library, would it not be a good idea to persue such efforts more aggresively? I could imagine it would help bring forward libraries much faster. I think it would be reasonable that the boost comunity provided 1. project descriptions 2. help and guidelines throughout the 6-12 months of the project If we had small papers explaining potential projects, these can be sent to universities which can the in turn suggest them to their students. Off the top of my head, I can think of these projects 1. C++ database library 2. C++ statistics library 3. exact reals class 4. An XML parser and generator library I could probably be a co-author and contact person of (2). Any thoughts? -Thorsten

4 4

logging lib, v1.3
by John Torjo 12 Nov '04

12 Nov '04

Dear boosters, Finally, have had some time to update the logging lib. Get it from: http://www.torjo.com/ (of course, it comes packed with docs) First of all, many thanks to Darryl Green and Caleb Epstein! Summary - solved a few bugs - redesigned so that I allow for scoped logs (no more log IDs, now logs are identified by a 'string name') - ported the code from Caleb - allow for a "log manager" (many thanks to Darryl Green!) (it is not documented yet, but will do so as soon as I have some time) - updated docs - (renaming) add_modifier_func -> add_modifier (renaming) add_logger_func -> add_appender - thread-safety update (again, many thanks to Darryl Green!) - you can log messages even *before* logs are initialized after logs are initialized, just call flush_log_cache(); As for scoped logs, to make a long story short, you'll be able to do: logger gui("app.gui") if (gui) gui.stream() << "something GUIsh"; // or (equivalent) BOOOST_SCOPEDLOG(gui) << "something GUIsh"; Still to do: - docs: write about log managers - cyclic logs Looking forward to your feedback! Best, John -- 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

11 47

boost::weak_ptr
by Dirk Gregorius 12 Nov '04

12 Nov '04

Is it possible to reset a boost::shared_ptr without all associated boost::weak_ptr become invalid? -Dirk

2 1

boost::function feature request?
by Peter Dimov 12 Nov '04

12 Nov '04

When using boost::function<bool()> to implement event callbacks such as is_visible or is_enabled, it's very convenient to pass 'true' or 'false' directly, instead of going through bind( identity<bool>(), true ). An UI button I recently did even had separate bool properties in addition to the callback events for these reasons. I wonder whether it's reasonable to add this_type& operator=( T const & t ); to function<T()> that does the obvious thing. Of course f = t; is merely a shorthand way of spelling f = boost::lambda::constant(t), but a dependency on lambda isn't always desirable. Thoughts? -- Peter Dimov http://www.pdimov.com

4 10

Re: Generalised reflection
by George van den Driessche 12 Nov '04

12 Nov '04

> Message: 4 > Date: Thu, 11 Nov 2004 17:08:53 -0500 > From: David Abrahams <dave(a)boost-consulting.com> > Subject: [boost] Re: Generalised reflection > To: boost(a)lists.boost.org > Message-ID: <uoei4kphm.fsf(a)boost-consulting.com> > Content-Type: text/plain; charset=us-ascii > > "George van den Driessche" <grebe(a)bigfoot.com> writes: [snip] > > Yes, but in Boost.Python you're really saying two things for each type: > > (a) Here's my type's internal structure. > > Emphatically no. In Boost.Python you describe a new Python type's > public interface. Its interface doesn't have to have any relationship > to that of the C++ type. > > > (b) Here's how to present the internal structure to Python. > > I think this fact is slightly disguised because the two steps are both > > performed by the def() function. > > Believe me, I understand that there are two things happening there, > and the Langbinding project aims to separate those two things. But > when doing language binding you are definitely *not* describing > internal structure. The two things are: > > i. Describe the external interface to the new type. > ii. Turn that interface description into an actual Python type. Yes. I shouldn't have used the phase 'internal structure' here. A better indication of what I'm getting at comes later in my message, but was cut from your reply: > > What I'm suggesting amounts to factoring out the common first step. Let's > > suppose that we do in fact have a general reflection library, which allows > > you to list the properties of your class and attach arbitrary bits of data > > to them. So allow me to revise the description of the two stages: (a) Enumerate the runtime-accessible properties of a C++ type and associate names with them. (b) Turn that interface description into an actual Python type. > > But the fact that it takes > > pointers-to-members is a giveaway. > > The fact that you are generally binding member functions (and only > public ones) is also a dead giveaway. What Rene said may be true > (that most types can be serialized and reconstructed through their > public interface), but it's not a foregone conclusion. I agree. In the case where you need to provide two different reflections, you write two different descriptions. In the common case where you can use the same one for both purposes, you've saved yourself a bunch of work. This is just the same as Python providing default pickling support to cover the common cases - you still have to customise it sometimes, but it does the bulk of the work for you. > > Part (b) here corresponds to the extra > > data that you attach to exposed members, such as return_internal_reference. > > In a serialisation library, you're saying two things too: > > (a) Here's my type's internal structure. > > (b) Here's how to write the structure to a file, and read it back. > > In fact, if your classes are appropriately exposed to Python, you could just > > pickle them in Python and you'd be done. > > *If* they expose enough information to be picklable. >>> And note > that Boost.Python has explicit support for pickling, which rather > strongly hints that the information you supply it for ordinary class > wrapping is usually not sufficient for serialization. <<< Yes. Now imagine that I've got some helper functions for use with Boost.Python's pickling suite. But I want to use them with a C++ serialisation library. I'm going to have to factor a bunch of code out of those helper functions so that I can invoke them without using boost::python::tuple, and then write wrappers to use the factored-out code with the Boost.Python pickling suite. Instead, I want to write just the C++ serialisation code, and have that automatically wrapped up for use with Boost.Python pickling. It's a similar separation of layers. > > Maybe it would help to describe how I arrived at the idea I'm > > suggesting. > > No offense, but probably not; you're not the first one to think that > the ideas behind Boost.Python could be used to build a generalized > reflection library. Of course not. However, since you agree with my premises but you disagree with my conclusion, it follows that you must disagree with my reasoning at some stage. So by describing my reasoning, I'm hoping that you'll be able to pinpoint that stage and then we can discuss that instead :) > If you search this mailing list's history and > that of the Python C++-sig I think you'll find some other > conversations along these lines. It's a fine idea; I just have a > hard time believing that the information you need to expose for > serialization is normally the same as what you need to expose for > language binding. Maybe the same front-end interface code can be > used to do the exposing, but whatever the user writes for one is not > going to magically work for the other. I completely agree. In my message I did write: > > The major architectural problem I foresee with hanging different categories > > of information (scripting, serialisation, UI &c) off the same reflection > > objects is that people might want to define how to serialise an object in > > one place, but how to script it in another. Now, even if this cannot be resolved, the many reflection-based tasks still have a common step (a), namely building a reflection of a type. You can find yourself providing several reflections of a type for different purposes, but nonetheless the mechanism of reflection is the same: bind properties to names. In other words, even if you must have different reflections of a type for different purposes, the means of generating those reflections is the same, and the underlying structure of each reflection is the same. (Note: I'm *not* saying here that each reflection reflects the same properties of the type, but that each reflection is a set of tuples of (name, property, reflection-specific-extra-data.) So one could factor out the definition of the reflection structure. What does one gain from that? Well, in the cases where you really could use the same reflection for several purposes, you only need to provide one (as in the Langbinding case). In other cases, you write several reflections, but they all use the same syntax (probably similar to boost::python::class_ definitions) which means: i) you can plug the same helper/accessor functions into any of them. ii) if you can read one, you can read them all. George

2 1

Can anyone please give me advice on regression test building?
by Roland Schwarz 12 Nov '04

12 Nov '04

This is my second attempt to get some help on regression test build. If I should post this to another list, please anyone give me advice to where I should post instead. Here is my question: I try to invoke bjam in subdirectory .....\boost\status (After having set TOOLS=vc-7_1 ) The last line I see is: Unknown suffix on <@boost!libs!spirit!test>./select_p_with_rule.cpp<template>normal - see UserObject rule in Jamfile(5). Obviously nothing has been built (no tests have been run?) Is this an error in the test Jamfile of spirit, or am I trying to do something stupid? Thank you for any help on this. Roland

2 3

boost::shared_ptr: Changing raw pointer for all instances
by Dirk Gregorius 12 Nov '04

12 Nov '04

My boost::shared_ptr objects hold pointees to interfaces. It might happen that these raw pointees might become invalid or that I like to change the implementation. Is it possible to change the raw pointee of all boost::shared_ptr objects in an application due to some kind of event? Example: I have one singleton class that provides several factory functions: class Factory { public: boost::shared_ptr<IFoo> CreateX( void ); // ... more factory functions private: // Events - void OnChangeImplementationX( void ); // Data members typedef std::vector< boost::shared_ptr<IFoo> > MasterColl; MasterColl m_FooObjects; } boost::shared_ptr<X> Factory::CreateX( void ) { // Create a new foo object boost::shared_ptr<IFoo> pFoo( new FooImpl ); // Save a "master" instance m_FooObjects.push_back( pFoo ); // Return the object return pFoo; } void Factory::OnChangeImplementationX( void ) { // Iterate over all "master" objects and change the underlying pointee } Can this be implement using the boost::shared_ptr class? Regards, -Dirk

1 0

[format] problem with special floating point values
by Vyacheslav E. Andrejev 12 Nov '04

12 Nov '04

Hello All, Thare is a problem in boost::format to treat infinity floating point values. Compare output of the two following lines of code: cout << numeric_limits<double>::infinity(); cout << boost::format("%f\n") % numeric_limits<double>::infinity(); The first one on my machine outputs 1.#INF which denotes infinity. The code with boost::format outputs 1/5000 zeroes/.#INF000 It's not what I can expect in any way. It's strange, but quiet NaN is outputed well. -- Vyacheslav E. Andrejev System Architect, Excelsior, LLC

1 0

[range] warnings on vc7.1
by Jonathan Turkanis 12 Nov '04

12 Nov '04

Hi Thorsten, The program at the end of this message produces twenty C4224 Warnings ("nonstandard extension used : formal parameter 'array' was previously defined as a type") on VC7.1 and VC8.0 beta. Since Boost.Array and Boost.Range will be used together with some frequency, it might be a good idea to disable warning 4224 locally within the range headers. Best Regards, Jonathan ---------- #include <boost/array.hpp> #include <boost/range/begin.hpp> #include <boost/range/end.hpp> #include <boost/range/iterator.hpp> int main() { }

2 3

boost::shared_ptr
by Dirk Gregorius 12 Nov '04

12 Nov '04

I have four easy questions regarding boost::shared_ptr: 1.) How do I pass a boost::shared_ptr to a function - via value or reference? void ByValue( boost::shared_ptr<Foo> pFoo ); void ByReference( boost::shared_ptr<Foo>& rFooPtr ); 2.) When passing a raw pointee to a function you can declare the pointee const. How do I pass a const boost::shared_ptr? void ConstRaw( const Foo* pFoo ); void ConstSharedPtr( ??? ); 3.) Does anything speak against passing a reference to a factory function instead of returning the boost::shared_ptr? boost::shared_ptr<Foo> Create( void ) { return boost::shared_ptr<Foo>( new Foo ); } bool Create( boost::shared_ptr<Foo>& foo ) { // Make some validations and return false on error. // ... // Everyting is ok. Reset the pointee and return a success foo.reset( new Foo ); return true; } 4.) Can I test a boost::shared_ptr against NULL like a raw pointee? Regards, -Dirk

2 1

[admin]
by Jonathan Turkanis 11 Nov '04

11 Nov '04

Hi, Is there any plan to restore old messages to the server at gmane ( I realize this takes significant space)? I find it much easier to search for old messages on my hard drive than using the web interfaces. Unfortunately, my newsreader wiped out my archive of old messages yesterday when the server came back up. Jonathan

2 2

Generalised reflection (was: Re: GUI Library Proposal for a Proposal)
by George van den Driessche 11 Nov '04

11 Nov '04

> Message: 15 > Date: Wed, 10 Nov 2004 20:52:24 -0500 > From: David Abrahams <dave(a)boost-consulting.com> > Subject: [boost] Re: GUI Library Proposal for a Proposal > To: boost(a)lists.boost.org > Message-ID: <uwtwtnodj.fsf(a)boost-consulting.com> > Content-Type: text/plain; charset=us-ascii > > "George van den Driessche" <grebe(a)bigfoot.com> writes: > > >> I'm stumped by how to store this information in any sort of container > >> though, since the properties are of different types. Any thoughts, or > >> is this madness? > > > > The properties are of different types, but the type information for > > properties will always be of the same type :) So you can generate a > > property set for your class, that includes the dictionary that maps > > names to property_type_info structures. Each property_type_info > > would be automatically generated from the static type of the > > property. > > > > The thing that's bugging me is that all the reflection mechanism is > > covered by Boost.Python because it relies on the same principles. I > > *think* the boost-langbinding list seems to know this, since you > > also need the reflection capabilities in order to support languages > > that aren't Python. But that list doesn't seem to have much traffic > > so I haven't much to go on. > > We did some work on that project recently and presented it at the > Boost workshop at OOPSLA. See > http://boost-consulting.com/writing/oopsla04.html > http://boost-consulting.com/writing/langbinding.ppt > > > In order to avoid too many reinvented wheels, I'd like to see > > Boost.Python split neatly into two stages: > > > > (a) Reflect C++ types into C++ objects. Each type for which you provide a > > reflection map will correspond to exactly one property_set object, which > > would contain a set of property_type_info objects. > > (b) Expose the types to Python using the objects created by (a). > > > We do have a front-end/back-end architecture, but I'm not sure whether > we're doing what you want. > > > Once you've made that split, then you can add: > > (c) Expose the types to Lua using the objects created by (a). > > (d) Expose the types to <language-of-your-choice> using the objects created > > by (a). > > (e) Serialise the types, using results of (a). > > This I have serious doubts about. What you'd expose for Python/Lua > binding would be an object's public interface: its abstraction. In > order to do serialization in that way, you'd likely have to expose an > object's guts: its implementation details. Yes, but in Boost.Python you're really saying two things for each type: (a) Here's my type's internal structure. (b) Here's how to present the internal structure to Python. I think this fact is slightly disguised because the two steps are both performed by the def() function. But the fact that it takes pointers-to-members is a giveaway. Part (b) here corresponds to the extra data that you attach to exposed members, such as return_internal_reference. In a serialisation library, you're saying two things too: (a) Here's my type's internal structure. (b) Here's how to write the structure to a file, and read it back. In fact, if your classes are appropriately exposed to Python, you could just pickle them in Python and you'd be done. But as was pointed out a couple of days ago (by Beman I think), not everyone wants to use Python in their project. Maybe it would help to describe how I arrived at the idea I'm suggesting. I wanted to construct a serialisation library in C++, that would be used from C++. I quickly realised I needed to separate the description of which elements of an object should be serialised, from the description of how the serialisation should happen. That way, a single class description could be processed in many different ways, so I could use it to write XML, or plain debug text, or a compact binary version, without changing the class definition. Once I'd set about it, I realised I was duplicating the structure that I saw in Boost.Python, but instead of attaching to each property a description of how to interface with Python, I was attaching the description of how to serialise that property. And I thought, I wish I could just use class_ instances to describe the data to serialise. But of course, Boost.Python class_ instances are designed to be used from Python, not from C++ :) Obviously, this train of thought is very similar to that which gave rise to Boost.Langbinding. And looking at the usage examples for John Torjo's Win32GUI framework, I saw the same pattern arising yet again: lists of properties (that is, pairs of member functions), with attached data (in this case, about bindings to specifc UI elements, input validation routines, and so on). What I'm suggesting amounts to factoring out the common first step. Let's suppose that we do in fact have a general reflection library, which allows you to list the properties of your class and attach arbitrary bits of data to them. Then the data that you attach to a property can be: - things from Boost.Langbinding about how to get at it from script (or simply the fact that script shouldn't be able to get at it) - things about how to serialise that property (or simply the fact that it shouldn't be serialised) - hints about how to present the property in a UI (e.g. if you attached some object that says "this integer's range shouldn't exceed [0,60)" then a slider or number control could pick that up and limit itself to that range). - probably some other things I haven't thought of. > > (f) Bind types to GUI objects, using results of (a). > > What does it mean to bind a type to a GUI object? > > > (g) ... you get the point. > > I'm not sure. A couple of other people have tried to explain what I meant, and I hope the above example makes it clear. The major architectural problem I foresee with hanging different categories of information (scripting, serialisation, UI &c) off the same reflection objects is that people might want to define how to serialise an object in one place, but how to script it in another. This could arise, for example, if someone supplies a library that only includes scripting information for its types, but the library's user also wants to add serialisation support. I think you encountered a related problem in the Boost.Langbinding development where two libraries that each supply bindings for one type could conflict if both used in the same executable. Possibly it's too ambitious to try to bring all these related, but different, activities under the same umbrella. Maybe multiple property maps really are the best solution. But it's certainly worth considering, because even in that case I suspect they could share a common set of base templates. For instance, if you attach range information to a scalar property, that could automatically be used for validation by serialisation code, UI code, and scripting code. George

2 1

iterator adaptors and const correctness
by Neal D. Becker 11 Nov '04

11 Nov '04

I was struggling with const correctness and iterator adaptors. At first I was using iterator_facade. I found it difficult to get dereference to work correctly. After changing to iterator_adaptor I got things working. I'm wondering if the approach I used is "correct". I include the whole class here, because it isn't really very big. I was using a Ring class which contains an iterator, which is cycle_iterator<std::vector<Complex>::iterator>. If a Ring const& is passed I had problems with dereference. The changes I made to cycle_iterator fix this were: 1) Add templated conversion constructor to cycle_iterator, to allow implicit conversion of cycle_iterator -> const cycle_iterator. 2) Include both reference dereference() and const reference dereference() const (likewise for operator[]) So, do my changes constitute a "correct" approach to making interoperable iterators using boost::iterator_adaptor?

3 2

General reflection library? (was: Re: GUI Library Proposal for a Proposal)
by George van den Driessche 11 Nov '04

11 Nov '04

> Message: 7 > Date: Tue, 9 Nov 2004 13:16:05 -0500 > From: Caleb Epstein <caleb.epstein(a)gmail.com> > Subject: Re: [boost] Re: GUI Library Proposal for a Proposal > To: boost(a)lists.boost.org > Message-ID: <989aceac0411091016316d09bb(a)mail.gmail.com> > Content-Type: text/plain; charset=3DUS-ASCII > > On Tue, 9 Nov 2004 17:37:15 -0000, George van den Driessche > <grebe(a)bigfoot.com> wrote: > > > Date: Tue, 9 Nov 2004 09:38:35 -0500 > > > From: Caleb Epstein <caleb.epstein(a)gmail.com> > >=20 > > > I've been toying with using the properties library Reece Dunn recentl= > y > > > submitted (in the boost-sandbox CVS) for this purpose. I've got > > > something very sketchy, but it relies on a visitor pattern to "pass" > > > type information to client code in a manner similar to Boost.Variant. > > > > > > I'd prefer a way of storing the type information for each reflectable > > > class statically, and in a generic way, e.g. something like > > > std::map<std::string, property>. This would enable the reflection > > > code could be decoupled from the reflected classes entirely and just > > > operate on this property meta-data. It would also allow client code > > > to lookup individual properties (e.g. by name) instead of having to > > > visit all of them. > > > > > > I'm stumped by how to store this information in any sort of container > > > though, since the properties are of different types. Any thoughts, o= > r > > > is this madness? > >=20 > > The properties are of different types, but the type information for > > properties will always be of the same type :) So you can generate a pro= > perty > > set for your class, that includes the dictionary that maps names to > > property_type_info structures. Each property_type_info would be > > automatically generated from the static type of the property. > > You lost me here. The property types each inherit from property_info, > but it is similarly templated on the type of object begin > stored/referenced/aliased. Are you suggesting another non-template > base class which all properties would inherit from? Spot on. Just as a property_set corresponds to a C++ type, the property_type_info entries in the property_set each correspond to a pointer-to-member (or a pair of pointer-to-member-function if you want to wrap your property with get/set methods). Just as you generate a unique property set for each reflected type, you generate a unique property_info for each of its properties. But since each property_info has a common base class, you can stick them all in the same property set. Take a peek into the Boost.Python stuff. It follows a similar pattern, I believe. > What might this > look like? I find myself unable to write an overview of it and not almost all of it. So I'll have to write the whole thing this evening when I have time :) > What mechanism would you use to keep track of the type > information? Type information of what? You can pass around a fat pointer class which is basically a pair< void*, property_set* > when you need to maintain knowledge of the type of a pointer. I'll try to get it all written up into an understandable form this evening. George

2 1

RE: [boost] boost::ref simple question
by Michiel Salters 11 Nov '04

11 Nov '04

The boost::function template works with boost::ref according to the docs, so try boost::function< int ( int ) > ( boost::ref( Op() ) ) HTH, Michiel Salters > -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org]On Behalf Of Neal D. Becker > Sent: maandag 8 november 2004 16:16 > To: boost(a)lists.boost.org > Subject: [boost] boost::ref simple question > > > This must be a common question. > > I want to use std::transform with a function object that is > expensive to > copy, so I want to pass by reference. I tried to use > boost::ref for this, > but this simple test doesn't work: > > struct Op { > int operator() (int x) { return 1 + x;} > Op() {} > private: > Op (const Op&); > > }; > > int main() { > vector<int> x (4); > vector<int> y (4); > Op o; > std::transform (x.begin(), x.end(), y.begin(), boost::ref(o)); > } > > Any suggestion? > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

5 9

License use for non-Boost projects
by Andrew Cox 11 Nov '04

11 Nov '04

Can I release my own non-Boost projects under the Boost license? Does the Boost organisation mind? Is the license valid if I use the standard application of it in src and header files as follows? // Copyright 2004 Joe Coder. // Distributed under the Boost Software License, Version 1.0. (See // accompanying file LICENSE_1_0.txt or copy at // http://www.boost.org/LICENSE_1_0.txt) Thanks, Andrew Cox Programming projects: http://www.btinternet.com/~ahcox/index.html UCL work: http://www.cs.ucl.ac.uk/students/Andrew.Cox/

2 1

[fileststem]1.32: with serilization: visibility of m_path
by Francis ANDRE 11 Nov '04

11 Nov '04

Hi In order to serialize a derivative class of boost/filesystem/path, one cannot access the base class member m_path without changing its visibility from private to protected: I would suggest to change the visibility of this m_path member from private: to protected, or to add an implicit definition of the serialize method into the class boost::filesystem::path. #include <boost/filesystem/path.hpp> namespace boost { namespace serialization { class access; }} class OSD : public boost::filesystem::path { private: friend class boost::serialization::access; friend std::ostream & operator<<(std::ostream &os, const OSD&); template<class Archive> void serialize(Archive &ar, const unsigned int version) { ar & m_path; } }; Regards Francis ANDRE

9 25

boost lambda'sl bind tries to instantiate abstract classes
by Eyal Farago 11 Nov '04

11 Nov '04

MSVC 7.1 chokes when I'm trying to (bll) bind a method/function with an argument which is (const/mutable)reference to an abstract type. I've attached a simple test file and MSVC 7.1 complaints. <<lambda_tester.cpp>> <<lambda_tester_compilation.txt>> eyal.

2 1

License and new version
by Jared McIntyre 11 Nov '04

11 Nov '04

I'm guessing from reading through the 1.32 tarball docs that the this release will still have some libraries that are not under the Boost 1 license. Is this the case? If so, is there a definitive list of these projects? Jared McIntyre

5 6

RE: [boost] Library TR draft available
by Randy Bowen 10 Nov '04

10 Nov '04

Is there a problem with that site? I've yet to be able to download the document, or even fully load the index page on which it's referenced. > -----Original Message----- > From: Beman Dawes [mailto:bdawes@acm.org] > Sent: Tuesday, November 09, 2004 5:39 PM > To: Boost mailing list > Subject: [boost] Library TR draft available > > The latest draft of the C++ Standard Library Technical Report > is now available at > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1711.pdf > > There may be editorial (non-substantiative) changes to the > final version of the TR document, but this latest draft is > believed to be final in terms of technical content. Thus it > should be safe for implementors or users to write code based > on this latest draft. > > It will be several years before most compilers come with a > full implementation of the TR. But some vendors (Metrowerks, > for example) are already shipping a few TR components. That > brings up the question of what Boost code does during the transition. > > To insure Boost code works with various TR implementations, > some Boost code will want to use the compiler vendor's > version of the TR if the TR component required is available, > but otherwise will want to use Boost equivalent code. How do > we handle that? The TR doesn't provide in configuration > macros, so I guess we will have to roll our own. > > --Beman > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

4 3

Math functions - requirements 'spec'
by Paul A Bristow 10 Nov '04

10 Nov '04

Following the view of C and C++ Working groups at Redmond that a working implementation of my proposal for math functions was a necessary condition for consideration for a TR-2 standard, I have been skirmishing with the problems of converting Stephen Moshier's Cephes code into something that works for both C++ and C. Several issues have emerged, mainly revealing my ignorance with C - a state of bliss in which I would have preferred to remain ;-) 1 Should I no longer cater for non-compliant compilers (usually old-style function specifications? I only have MSVC 8.0 available. 2 How do I check that my code is Standard C compatible (as well as C++)? 3 How do I tell whether the compiler is a C compiler or a C++ compiler (for #if ing). #if __cplusplus #if _STDC__ ... ? 4 I have compiled a module #including <cmath> OK with explicit project property "compile with C++", but when I change this to "compile with C" and no extensions so the /Za option is on the command line, it does not define __STDC__ == 1 as I have expected. What am I doing wrong. 5 Do I have to use exclusively C /* */ style comments :-((? (Or can I assume that C compilers will understand // comments?) I have also immediately come up against the problems of IEEE 754 compliance, argument checks, NaN, infs and exception throwing. 6 Should I assume IEEE 754 compliance and signal #error "Only works with IEEE compliant compilers"? How do I check with C - numeric_limits :: is_IEC559 equivalent? Or would it be foolish to rule out the some older DEC machines? 7 Do you recommend making NaN and inf checks optional? 8 How do I find if they are available, automatically but portably? 9 Can I assume isnan(float, double and long double) with C and with C++? 10 How do I detect isinf? Do I use FPclass for detecting isinf? (pos and neg?) 11 Do you recommend making throwing exceptions optional with C++? 12 Should I scrap all the hexadecimal (mainly polynomial) constants on the grounds that conforming compilers should read decimal digit strings 'correctly' - getting the nearest representable value. Is this true for both C and C++? 13 Do you also recommend making checking arguments optional (with #ifdefs)? So that those who want the ultimate in speed at any risk can switch checking off? Comments welcome. Paul PS Slightly updated versions of my TR2 proposal are at http://www.hetp.u-net.com/public/math_stats_functions_tr2_v2.doc http://www.hetp.u-net.com/public/math_stats_functions_tr2_v2.pdf Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539 561830 +44 7714 330204 mailto: pbristow(a)hetp.u-net.com

6 20

Boost.Thread (1.32draft) -- release library not built
by James Harris 10 Nov '04

10 Nov '04

Hi All, I have just downloaded the v1.32 draft and built the thread libraries, however it seems as though only the debug static lib has been built. I'm using VC7.1 and am trying to link to "libboost_thread-vc71-mt-s-1_32.lib" which has not been built. The following files were built successfully: - libboost_thread-vc71-mt-sgd-1_32.lib - boost_thread-vc71-mt-gd-1_32.lib - boost_thread-vc71-mt-gd-1_32.dll Is there a specific reason this lib is not being built, or is it that I've missed something somewhat important during the bjam build process? TIA - James.

3 2

Problem compiling boost::python : Script seems to require version 2.2 of python.
by JOLY Loic 10 Nov '04

10 Nov '04

Hello, I'm trying to build boost::python on my windows box, but I encounter some problems in the build process. First, some info about my versions : * I'm using the draft tarballs of the long expected version 1.32 that can be found on http://www.meta-comm.com/engineering/boost/200411020208/boost_1_32_0.zip * I have a pyton 2.4 installed on my computer I'm using bjam --v2 to build boost. First problem I had was that the doc specified to set the PYTHON_ROOT variable to my python installation path, but it looks like the script look for a PYTHON_PATH variable. Either the scripts of the documentation should be corrected. Second problem, even if the doc claims that the variable PYTHON_VERSION can be set to any version at least 2.2, in tha script, I can see what looks to me (I'm totally new to bjam) like an hard-coded value : > # Declare a target for the python interpreter library > lib python : : <name>python22 <search>$(PYTHON_PATH)/libs ; > PYTHON_LIB = python ; Best regards, -- Loïc -- Disclaimer ------------------------------------ Ce message ainsi que les eventuelles pieces jointes constituent une correspondance privee et confidentielle a l'attention exclusive du destinataire designe ci-dessus. Si vous n'etes pas le destinataire du present message ou une personne susceptible de pouvoir le lui delivrer, il vous est signifie que toute divulgation, distribution ou copie de cette transmission est strictement interdite. Si vous avez recu ce message par erreur, nous vous remercions d'en informer l'expediteur par telephone ou de lui retourner le present message, puis d'effacer immediatement ce message de votre systeme. *** This e-mail and any attachments is a confidential correspondence intended only for use of the individual or entity named above. If you are not the intended recipient or the agent responsible for delivering the message to the intended recipient, you are hereby notified that any disclosure, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender by phone or by replying this message, and then delete this message from your system.

3 6

Re: Problem to use boost
by Daniel Lidström 10 Nov '04

10 Nov '04

> > I do the same as before and get the same error. And yes, I am using > > Visual Studio 7.1 in case anyone thought else. What am I > doing wrong? > > No idea, but you can only get the error you are seeing if > __BORLANDC__ is > defined, and it clearly should not be if you are using Visual C++. > You're right. __BORLANDC__ was defined somewhere in this old legacy code base that is now being compiled with .Net 7.1. It didn't cross my mind. Thanks! -- Daniel

1 0

pqs - physical quantities library
by Andy Little 10 Nov '04

10 Nov '04

Hi, I have been continuing with my physical-quantities library over the last year, http://www.servocomm.freeserve.co.uk/Cpp/physical_quantity/index.html and I am now seeking feedback as to whether it is worth putting this forward as a boost library proposal.... *Overview* The physical-quantity type-family provides methods for modeling physical-quantities in C++ programs. The advantages and extra functionality over inbuilt types used in the role include, compile time dimensional-analysis checking, automatic conversion between units and an increase in source code comprehensibility. The type family includes two types, firstly a type where the units are fixed at compile-time referred to in the text as a ct-quantity and secondly a type where the units can be run-time modified, referred to in the text as an rt-quantity. The ct-quantity has many similar features to an inbuilt-type: - concrete type with simple,consistent semantics close to those of inbuilt-types. - aims for speed and code size performance close to that of in-built types. - requires no special framework to use. *Application areas* The application areas are very wide, including scientific-engineering, CAD, 3D games programming among many others. *Future directions* 2D and 3D vector quantities, scene-graphs and scene-modelling, Graphics interface (eg OpenGL), splines and curve analysis, successive approaximation , piecewise differentiation and integration algorithms. finite element analysis, etc etc. Issues from the previous thread on the library and physical quantities in general http://aspn.activestate.com/ASPN/Mail/Message/boost/1926782 issue: Angles. current status: Angles are implemented.There are two types, irrational (ie radians) and rational fractions of revolution ie degrees minutes etc). radians are what you might call a 'weak type'. (Though this behaviour can be modified by a macro switch). They will implicitly decay to (say) double and can be implicitly cast to double. However they also allow implicit conversions to and from degrees etc. hence an implicit conversion from degrees to radians can occur if a function has a radians argument, but not a double argument. They are also useful for output of units. --------------------- issue: Differentiating different but dimensionally equivalent types. current status: This is implemented. --------------------- issue: Implicit conversions between units. current status: Implicit conversions are intrinsic. They are practical instinctive and useful. --------------------- issue: You should be using mpl. current status: Hopefully I will be able to get hold of the metaprogramming book soon, at which point I can decide whether there are advantages. --------------------- regards Andy Little

4 10

Re: Problem to use boost
by Daniel Lidström 10 Nov '04

10 Nov '04

> "Daniel Lidström" <daniel.lidstrom(a)sbg.se> wrote in message > news:E1F34343C3A0804BB3E29ABBFCBBAF0C01BB6F@ADA... > > Hi, > > > > this is what I've done: > > compiled with commandline of > > bjam "-sVC71_ROOT=C:\Program Files\Microsoft Visual Studio .NET > > 2003\Vc7" > > "--prefix=C:\projects\boost" install > > I don't see an -sTOOLS=vc7.1 here telling bjam which tool set > to use, as the > Getting Started page suggests. I'd guess this is confusing > things. Given you > are using the default root for vc7.1 try: > > bjam -sTOOLS=vc7.1 "--prefix=C:\projects\boost" install > > note that vc7.1 is case sensitive. > Ok, I compile like this: bjam "-sTOOLS=vc7.1" "--prefix=C:\projects\boost" install > > Within my project, I've set an additional include path of > > C:\projects\boost\include\boost-1_31. Now when I compile my > project with > > > > one source file containing the line > > > > #include <boost/shared_ptr.hpp> > > > > I get this error: > > > > > c:\projects\boost\include\boost-1_31\boost\config\compiler\bor > land.hpp(1 > > 3) > > : fatal error C1017: invalid integer constant expression > > > > What have I missed? I do the same as before and get the same error. And yes, I am using Visual Studio 7.1 in case anyone thought else. What am I doing wrong? -- Daniel

2 1

[boost][boost-users][random] Open bugs
by Cromwell Enage 10 Nov '04

10 Nov '04

Any chance that any of the following bug reports will be resolved before the release? <http://sourceforge.net/tracker/index.php?func=detail&aid=911758&group_id=75…> <http://sourceforge.net/tracker/index.php?func=detail&aid=715667&group_id=75…> <http://sourceforge.net/tracker/index.php?func=detail&aid=652567&group_id=75…> TIA! Cromwell Enage __________________________________ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com

2 1

[serialization] problem with Microsoft VC 7.1 and ADL
by Vyacheslav E. Andrejev 09 Nov '04

09 Nov '04

Hello All, Seriaization library relies on argument dependent lookup (ADL) in calling load and save functions in boost::serialization::free_loader::invoke and boost::serialization::free_saver::invoke accordingly. Library supposes that this feature works well in VC 7.1 (that is macro BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP is undefined). But as I see, first, this supposition is implemented with error, and, second, ADL not always works very well in VC 7.1. Let's look to file /boost/serialization/split_free.hpp: namespace serialization { #if ! BOOST_WORKAROUND(BOOST_MSVC, <= 1300) template<class Archive, class T> void save(Archive &ar, const T & t, const unsigned int); template<class Archive, class T> void load(Archive &ar, T & t, const unsigned int); #endif ... Pay attention to "!" sign before BOOST_WORKAROUND. So, if VC version is 7.1 or higher, compiler expects that save and load would be defined in serialization namespace, if VC version is 7.0 or lower, compiler will search those namespaces from which Archive or T are originated. Very well. But let's take a look now to /boost/serialization/set.hpp for example: #ifdef BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP namespace boost { namespace serialization { #else namespace STD { #endif template<class Archive, class Key, class Compare, class Allocator > inline void save( Archive & ar, const STD::set<Key, Compare, Allocator> &t, const unsigned int /* file_version */ ){ ... } template<class Archive, class Key, class Compare, class Allocator > inline void load( Archive & ar, STD::set<Key, Compare, Allocator> &t, const unsigned int /* file_version */ ){ ... } In this file if BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP is defined save and load will be defined in serialization namespace, otherwise in the std namespace. But BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP is undefined for VC 7.1 (see /boost/config/compiler/visualc.hpp)! So in VC 7.1, accordingly to split_free.hpp, compiler expects save and load from serialization workspace, but they are defind in std accordingly to set.hpp (and all others stanard containers serialization files). By happy concourse of circumstances, this error is bypassed by errors in compiler and in most casses VC 7.1 compiles serialization library very well. But sometimes it accedentally rembers what ADL is and emits error during link stage that serialization::save and serialization::load are undefined. I suggest: 1) define BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP for VC 7.1 since as I can see Koening search technique implementation is unstable; 2) change "#if ! BOOST_WORKAROUND(BOOST_MSVC, <= 1300)" in split_free.hpp to "#if defined(BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP)". -- Vyacheslav E. Andrejev System Architect, Excelsior, LLC

2 1

[filesystem]1.32/vc7.1: unresolved reference when building a user dll
by Francis ANDRE 09 Nov '04

09 Nov '04

Hi Developpers When using the dll version of the boost::filesystem library to build a user's dll library, one get the followin link error: (Note that no error is produced at link time when building a static non dll user's library with the boost::filesystem dll library) SYSOUT.obj : error LNK2019: unresolved external symbol "private: void __thiscall boost::filesystem::path::iterator::increment(void)" (?increment@iterator@path@filesystem@boost@@AAEXXZ) referenced in function "public: static void __cdecl boost::iterator_core_access::increment<class boost::filesystem::path::iterator>(class boost::filesystem::path::iterator &)" (??$increment@Viterator@path@filesystem@boost@@@iterator_core_access@boost@@ SAXAAViterator@path@filesystem@1@@Z) Any idea how to solve this unresolved reference?? The code involved in this build is: class __declspec(dllexport) SYSOUT : public OSDDIR { void makedir(const DATASET::VOLUME& volume, const std::string& file); }; void SYSOUT::makedir(const VOLUME& volume, const std::string& file) { path rel(file); path vol(volume); for (path::iterator i = rel.begin(); i != rel.end(); i++) { path dir = vol / *i; if (!boost::filesystem::exists(dir)) { create_directory(dir); } vol = vol / *i; } } Regards Francis ANDRE

2 1

Problem to use boost
by Daniel Lidström 09 Nov '04

09 Nov '04

Hi, this is what I've done: compiled with commandline of bjam "-sVC71_ROOT=C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7" "--prefix=C:\projects\boost" install Within my project, I've set an additional include path of C:\projects\boost\include\boost-1_31. Now when I compile my project with one source file containing the line #include <boost/shared_ptr.hpp> I get this error: c:\projects\boost\include\boost-1_31\boost\config\compiler\borland.hpp(1 3) : fatal error C1017: invalid integer constant expression What have I missed? -- Daniel

2 1

RE: [boost] Problem to use boost
by Michiel Salters 09 Nov '04

09 Nov '04

Are you really compiling with VC7.1, perhaps another MSVC version or are you using the borland compiler? I admit C1017 sounds like MSVC. Michiel Salters > -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org]On Behalf Of Daniel Lidström > Sent: dinsdag 9 november 2004 14:33 > To: 'boost(a)lists.boost.org' > Subject: [boost] Problem to use boost > > > Hi, > > this is what I've done: > compiled with commandline of > bjam "-sVC71_ROOT=C:\Program Files\Microsoft Visual Studio .NET > 2003\Vc7" > "--prefix=C:\projects\boost" install > > Within my project, I've set an additional include path of > C:\projects\boost\include\boost-1_31. Now when I compile my > project with > > one source file containing the line > > #include <boost/shared_ptr.hpp> > > I get this error: > > c:\projects\boost\include\boost-1_31\boost\config\compiler\bor > land.hpp(1 > 3) > : fatal error C1017: invalid integer constant expression > > What have I missed? > > -- > Daniel > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

1 0

Re: Re[4]: [boost] Re: Re: GUI Library Proposal for a Proposal
by Reece Dunn 09 Nov '04

09 Nov '04

Michael Walter wrote: >On Sat, 6 Nov 2004 13:12:14 +0000, Val Samko <boost(a)digiways.com> wrote: > > MW> On Fri, 5 Nov 2004 23:54:30 +0000, Val Samko <boost(a)digiways.com> >wrote: > > >> Once again, in geometry, vector and point are practically the same >thing. > > MW> Not really - you can only represent a point by its radius/position > > MW> vector wrt a given coordinate system. > > > > I thought we are only talking about Cartesian coordinates? Does anyone > > really need a gui library for radial coordinate system? :) >Apologies - I was apparently using the wrong term (not a native >English speaker), and was just seeing "the vector r from the origin to >the current position" on Mathworld. Googling a bit more it appears >that it is such a vector in a polar/spherical coordinate system only. > >The word I was looking for is "Ortsvektor" in German, the vector from >the origin to a certain point. What would be the proper word for that >in English (tried googling, failed :)? "Ort" means place, so it would be "place vector", or more likely "position vector". Is this what you mean? Using http://dictionary.reference.com/translate/text.html produces "radius vector". Regards, Reece _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/

3 2

RE: [boost] Re: logging lib, v1.3
by Kevin Cousins 09 Nov '04

09 Nov '04

Markus Schöpflin wrote" > John Torjo wrote: >> Finally, have had some time to update the logging lib. Get it from: >> http://www.torjo.com/ (of course, it comes packed with docs) > > Just a quick thought that came to my mind... > > Did you consider using the syntax 'BOOST_LOG(dbg, "message" << foobar);' > instead of 'BOOST_LOG(dbg) << "message" << foobar;'? > > While I think the syntax you use looks far nicer, we ususally need the > ability to be able to compile away the logging calls completely and this > only can be done with the first form. ...which introduces the potential for a problem with unintended multiple parameters to the macro function, a la: #define BOOST_LOG(x,y) ... BOOST_LOG(dbg, "message" << templated<1,2>::type() << foobar); // ^BANG! BOOST_LOG(dbg, "message" << ( templated<1,2>::type() ) << foobar); --Kevin. kevin.cousins(a)ir.com _____________________________________________________________________ This email is intended only for the use of the individual or entity named above and may contain information that is confidential and/or privileged. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this Email is strictly prohibited. If you have received this Email in error, please notify us immediately by return email or telephone +61 2 9966 1066 and destroy the original message. Thank You _______________________________________________________________________

1 0

library-based property implementation
by Reece Dunn 08 Nov '04

08 Nov '04

Hi All, I have been working on an implementation of a library that allows you to define properties, based on the wg21 N1615 paper by Lois Goldthwaite. The code is committed to the sandbox (under the property directory) with tests and preliminary documentation. I have seperated the properties into two. The boilerplate code for operator overloads, organised by rank, where rank is the number of indices (the term is borrowed from Tensor algebra) provides one group. The other group is the property storage that implements the get and set functions that the boilerplate classes use to implement the operator overloads. : Scalar Properties A scalar property is a single-element property. You can have simple properties that either store their values internally or reference an external data member: class object { int val; public: scalar_property< aliased_property< int > > Val; object(): Val( val ){} }; int main() { scalar_property< value_property< int > > ival( 0 ); ival = 7; ival += 3; int j; scalar_property< aliased_property< int > > jval( j ); jval = 2; assert( j == 2 ); } You can also define more complex properties that use class methods to control them: class object { int val; public: int get_Val() const{ return val; } void set_Val( const int & v ){ val = v; } scalar_property< object_property < int, object, &object::get_Val, &object::set_Val > > Val; object(): Val( this ){} }; : Rank 1 Properties A rank 1 property is a 1-dimensional property. For example: class result_set { public: // property record index[]; record get_record( int i ) const; void set_record( int i, record r ); boost::rank1_property< boost::rank1_object_property < record, int, result_set, &result_set::get_record, &result_set::set_record > > record; public: result_set(): record( this ) { } }; Regards, Reece

2 2

[1.32] [function] documentation missing
by Caleb Epstein 08 Nov '04

08 Nov '04

In the release candidate tarballs, the documentation for the "function" library is redirecting to http://www.boost.org/regression-logs/cs-win32_metacomm/doc/html/function.ht… It looks like the Boost.Book documentation isn't being generated for this library. Is this expected? -- Caleb Epstein caleb.epstein(a)gmail.com

2 1

Re: [boost] GUI Library Proposal for a Proposal
by George van den Driessche 08 Nov '04

08 Nov '04

> Message: 2 > Date: Mon, 08 Nov 2004 10:42:21 -0500 > From: Beman Dawes <bdawes(a)acm.org> > Subject: Re: [boost] GUI Library Proposal for a Proposal) > To: boost(a)lists.boost.org, boost(a)lists.boost.org > Message-ID: <6.0.3.0.2.20041108102747.0272bec0(a)mailhost.esva.net> > Content-Type: text/plain; charset="us-ascii"; format=flowed > > At 07:38 PM 11/7/2004, George van den Driessche wrote: [snip] > >So what do you stand to gain, other than being able to write GUIs in > >your favourite language, as opposed to your second-favourite language? > >The only thing I can think of is that you don't have to worry about any > >bridge between languages. > > What you say makes a lot of sense if just you is involved. Or perhaps a > small enough group that they can all agree on the second-favorite language. > > But in larger organizations that approach results in a proliferation of > languages. I know of a company that has let programmers write code in any > language they like. The result is a nightmare. Over a dozen languages are > in common use. The toolchains on some projects are so convoluted that the > projects cannot be moved between the several operating systems in use at > the company. Programmers cannot freely move to another project because they > often don't know all the languages that are required. It is a serious mess. > > Thus the use of C++ as a GUI language may be sub-optimal as far as the > small picture goes, but could be a really smart move in terms of the big > picture. That's a convincing point. I'm glad it's a convincing point, because I like C++ :) Only, sometimes I wonder whether we're all so obsessed with the language that we can't stand back and realise that some other language is appropriate for a given task. Makes me think: if there was some language that easily spanned the range from static to dynamic code, then everyone could learn that and that only. Never mind... > Because what we are talking about is a library, rather than something in > the core language, non-users of the library don't pay for something they > don't use. As long as a C++ GUI library is useful to a significant number > of people it doesn't matter if lots of others choose a dual language > approach. True. Personally, I quite like the thinking behind Win32GUI, and I've been wondering about the viability of porting it to run on top of Carbon on OSX. I just needed a bit of persuasion that it's worth pursuing at all. I'm not sure how far the event handling systems can be aligned, but I'm certainly going to look into it. If it works, it'll need a different name :) George

2 1

const_string + recursive_variant = boom
by Caleb Epstein 08 Nov '04

08 Nov '04

I've been trying to build a generic "message" type class using boost.variant and have just run across a problem when trying to convert it from using std::string to using the proposed boost::const_string. Attached is a small test case and the output from gcc 3.3.2 (the latter gzipped due to its hugeness). All is well if the mystring type is std::string. Any thoughts on how to fix this? -- Caleb Epstein caleb.epstein(a)gmail.com

6 9

[FSM] Patches for gcc-3.4.1
by Jürgen Hunold 08 Nov '04

08 Nov '04

Hi ! The attached patch makes the FSM-examples (except PingPong) compile with gcc-3.4.1 These are mostly scoping issues. Tested against gcc-3.3.x. Any one interested in BB.V2 Jamfiles for FSM ? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Institut für Verkehrswesen, Eisenbahnbau * voice: ++49 511 762-2529 ! und -betrieb, Universität Hannover * fax : ++49 511 762-3001 ! Appelstrasse 9a, D-30167 Hannover * hunold(a)ive.uni-hannover.de ! www.ive.uni-hannover.de

2 1

Shortcut regex notation
by Schalk_Cronje＠McAfee.com 08 Nov '04

08 Nov '04

Would anyone be interested in having a perl-like regex shortcut notation? The original idea was born during a local C++ focus group discussion. Looking further into the feasibility I thought that this might be a useful addition to Boost. Possibly something like the following (from some proof-of-concept code) using namespace boost::short_regex; std::string str("And he said: 'BLAH BLAH'"); // [1] Substitutes first occurrence and copy (calls boost::regex_replace) // perl: ($s2=$str) =~ s/(BLAH)/Hooray/; std::string s2= _s / "(BLAH)" / "Hooray" / str; // [2] Substitute globally and copy // perl: ($s2=$str) =~ s/(BLAH)/Hooray/g; s2= _s / "(BLAH)" / "Hooray" / _g / str; // [3] Substitute first occurrence in-place // perl: $str=~ s/(BLAH)/Hooray/; ~_s/ "(BLAH)" / "Hooray" / str; In the above _s and _g are special placeholder/tag objects sort of like _1,_2. Other could include _i (case-insensitive), _m (string as multiple lines) and _s (string as single line). Multiple modifiers can be added using (,) // [4] Substitute globally and copy // perl: ($s2=$str) =~ s/(BLAH)/Hooray/gi; s2= _s / "(BLAH)" / "Hooray" / (_g,_i) / str; The purpose will not be to shortcut all of the boost.regex functionality, just the common cases, as in perl or sed. Cases [1] and [3] is very close to the perl and would be easy to understand, however [2] and [4] is moving away from perl-syntax. This might be considered illegible by some.

7 7

Re: Points vs Vectors / GUI Library Proposal for a Proposal)
by George van den Driessche 08 Nov '04

08 Nov '04

Noah Stein wrote: > >> This makes them almost the same thing. You can treat vector as a >> point, and point as a vector. Besides, we are talking about R^2, >> which is a vector space. > > Sure, there's an isomorphism between points and vectors; however, that > doesn't make them the same. There's an isomorphism between the > functions > f(x)=x and f(x)=2x; however, that does not make those two equations the > same. This could be explained by analogy with C++, which more readers here might be familiar with: the difference between points and vectors is the same as the difference between C++ pointers and C++ ints. You can add a pointer to an int, or an int to a pointer, but you can't add two pointers. However, you can subtract two pointers to get an int. Likewise, it's not really meaningful to talk about the sum of two positions, but the difference between them is the vector from one to the other. 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 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++ 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. b) can less easily tweak a running program to try out different ideas. c) have to spend a lot of effort to construct a domain-specific language (c.f Spirit; see (a)). d) probably end up with a bigger codebase. So what do you stand to gain, other than being able to write GUIs in your favourite language, as opposed to your second-favourite language? The only thing I can think of is that you don't have to worry about any bridge between languages. George

3 2

OOPSLA Workshop...
by Tommy 08 Nov '04

08 Nov '04

Hi, a couple of months ago, I noticed an announcement in this list for Boost’s Oopsla Workshop. The topics and goals of that workshop (review position papers / libraries, discuss new library proposals, their relative merits, benefits and weaknesses, and provide feedback on initial designs) looked very interesting. So, after that event took place (Oct 25), I’ve looked out for material describing the results of that workshop - but I have not been able to find anything!? Has the results of the workshop been put together? If so, is the outcome publically available somewhere? Regards, Curious Tommy

2 1

boost::ref simple question
by Neal D. Becker 08 Nov '04

08 Nov '04

This must be a common question. I want to use std::transform with a function object that is expensive to copy, so I want to pass by reference. I tried to use boost::ref for this, but this simple test doesn't work: struct Op { int operator() (int x) { return 1 + x;} Op() {} private: Op (const Op&); }; int main() { vector<int> x (4); vector<int> y (4); Op o; std::transform (x.begin(), x.end(), y.begin(), boost::ref(o)); } Any suggestion?

1 0

[regex] any interest in finite automata-based regex engine?
by Vladimir Pozdyayev 08 Nov '04

08 Nov '04

Hello. Are there any plans to add finite automata-based subengine to the regex library? If there are, I can submit the algorithm/implementation of a modified nondeterministic FA which takes care of * greedy and lazy quantifiers, * eagerness of the alternation operator, * non-longest matches (`best' in the Perl-ish sense with respect to greediness/laziness/eagerness), * substring capturing. All these features being included, the time cost of a match is O(N(E+C)L), where N is the number of states, E is the average epsilon-closure size per state, C is the number of capturing parentheses, and L is the input length. As far as I know that's the lowest order of time complexity in this area (corrections are welcome)---though, of course, deterministic FA would be even faster. I suppose there's no point in adding another regex library, but being able to guarantee linear time cost in an existing one would be nice. -- Best regards, Vladimir Pozdyayev.

6 22

Program options auto-link bug
by John Maddock 08 Nov '04

08 Nov '04

The program options library currently doesn't select the dll-import library when auto-linking to the dll build of the library - it always tries to link to the static lib. The following patch fixes the issue: $ cvs diff -u boost/program_options/config.hpp johnmaddock(a)cvs.sourceforge.net's password: Index: boost/program_options/config.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/program_options/config.hpp,v retrieving revision 1.2 diff -u -r1.2 config.hpp --- boost/program_options/config.hpp 13 Jul 2004 15:12:24 -0000 1.2 +++ boost/program_options/config.hpp 6 Nov 2004 12:37:09 -0000 @@ -20,6 +20,10 @@ // Set the name of our library, this will get undef'ed by auto_link.hpp // once it's done with it: #define BOOST_LIB_NAME boost_program_options +// tell the auto-link code to select a dll when required: +#if defined(BOOST_ALL_DYN_LINK) || defined(BOOST_PROGRAM_OPTIONS_DYN_LINK) +# define BOOST_DYN_LINK +#endif // And include the header that does the work: #include <boost/config/auto_link.hpp> OK to commit? John.

3 5

[multi_index] regression in gcc-3.1-linux --seeminlgy MPL-related
by JOAQUIN LOPEZ MU?Z 08 Nov '04

08 Nov '04

Currently, one of the tests of Boost.MultiIndex is failing for GCC 3.1 under Linux: http://tinyurl.com/638oh The ICE happens inside boost/mpl/aux_/at_impl.hpp. This test used to work OK against the RC branch a couple of days ago. Any idea? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 2

Auto-linking and getting started docs.
by John Maddock 08 Nov '04

08 Nov '04

I've added a section on auto-linking with MS-Windows compilers in the getting started docs, in the main branch only (No URL yet, cvs hasn't cycled it through yet, but it'll be at http://cvs.sourceforge.net/viewcvs.py/*checkout*/boost/boost/more/getting_s… eventually). If it looks OK, I'll commit to the release branch as well. John.

5 6

Re: [boost] [multi_index] regression in gcc-3.1-linux --seeminlgyMPL-related
by JOAQUIN LOPEZ MU?Z 08 Nov '04

08 Nov '04

----- Mensaje original ----- De: Martin Wille <mw8329(a)yahoo.com.au> Fecha: Domingo, Noviembre 7, 2004 7:15 pm Asunto: Re: [boost] [multi_index] regression in gcc-3.1-linux -- seeminlgyMPL-related > JOAQUIN LOPEZ MU?Z wrote: > > Currently, one of the tests of Boost.MultiIndex > > is failing for GCC 3.1 under Linux: > > > > http://tinyurl.com/638oh > > > > The ICE happens inside boost/mpl/aux_/at_impl.hpp. > > > > This test used to work OK against the RC branch > > a couple of days ago. Any idea? > > Neither CVS head, nor the RC branch have been tested > against gcc 3.1 under Linux. I (re)added this compiler > because I had spare CPU time. > > I don't think gcc 3.1 is something one has to worry > about too much. I doubt it is much in use. (Either > people still stick to the even more broken gcc 3.1 > or they use gcc 3.3 or even 3.4) You're absolutely right, even my docs state that GCC 3.1 is not supported by Boost.MultiIndex. Sorry for the noise. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

RE: [boost] Re: GUI Library Proposal for a Proposal
by Reece Dunn 08 Nov '04

08 Nov '04

Russell Hind wrote: >Edward Diener wrote: >> >>No !!!!! WxWidgets has almost nothing to do with modern C++. Let's no go >>there, or have anything to do with supporting any other GUI >>implementation. > >Also, wxWindows is a huge library. If we were to introduce something in >boost, I'd very much like it to be as small and light weight (as win32gui >is supposed to be), not a collection of multi-megabyte dlls required, just >to wrap win32 or what ever the underlying library is. I am in the process of writing a platform-independant GUI (available at: http://uk.geocities.com/msclrhd/gui/gui.zip) that aims to be small and lightweight. This code is stll in the early stages and currently targets Win32/64 with minimal Cocoa/PalmOS support. >If people want more powerful components, they can be added afterwards, but >the underlying library around core OS controls should be as small as >possible. In my library, I am working on: * gui::event_handler supporting lightweight "windowless" controls * gui::window supporting windows like the main frame, MDI child frames, etc. * gui::form (i.e. a frame with controls/layout set by an external designer referenced by ID) that includes dialog boxes in Win32. I do not have an implementation of gui::form yet. * gui::control supporting controls/widgets like buttons within a window or form These 4 classes should then make it possible to derive your own classes to support edit controls, property sheets, MDI windows, etc. I do not explicitly implement any of these extra UI components because they are platform dependant and will add to the complexity of the framework. This is especially true for things like "splitter" windows and floating/docking toolbars. Also, other components can be added at a later stage if necessary. As for the event processing mechanism, I have decided to use a std::map< event_id, void ( gui::event_handler::* )( gui::event * ) > that allows: class main_frame: public gui::window { public: void ev_destroy( gui::event * ); void EvDraw( gui::event * ); main_frame( gui::string name ): gui::window( ... ) { set_handler( WM_DESTROY, &main_frame::ev_destroy ); set_handler( WM_PAINT, &main_frame::EvDraw ); } }; At the moment, this does not support chaining of handlers (something on my todo list). The main event loop is controlled via gui::event_loop that does support filtering of events (e.g. processing keyboard shortcuts). There are also platform-independant versions of position (NSPoint, POINT, etc.), size (NSSize, PointType, etc.) and area (NSRect, RECT, etc.) that make use of properties allowing window positions to be handled in a platform-independant manner, e.g.: void main_frame::resizing( gui::event * ) { area a = get_client_area(); a.deflate( gui::size( 5, 5 )); pane -> move( a ); } At the moment, you need to register Win32/64 window classes using: gui::win::window_type frame_class( TEXT( "CxxGUIFrame" ), COLOR_BTNFACE ); but I am looking to abstract this. I am all for getting a group of people together from the boost mailing list interested in GUI and developing a general GUI framework. It may be useful to have at least one person from the C++ standards committee to get input from the standards people. Regards, Reece _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/

10 26

how to compile regression tests
by Roland Schwarz 07 Nov '04

07 Nov '04

Sorry for this possibly naive question. But I can't figure out how to compile the regression tests. So far I found cd'ing into a specific libs/test directory and invoking bjam on it compiles the test for a specific library. But how can I compile all? I cannot find a rule like stage or install in the root Jamfile. Isn't it possible to recurse through all directories? Then I cannot manage to get a results page using the description in http://www.boost-consulting.com/boost/more/regression.html Instead I get: > C:\Programme\boost>SET PYTHON_ROOT=C:\Programme\Python23 > > C:\Programme\boost>SET BOOST_ROOT=C:\Programme\boost > > C:\Programme\boost>SET TOOLS=vc-7_1 > > C:\Programme\boost>ECHO ON > > C:\Programme\boost>cd C:\Programme\boost\status > > C:\Programme\boost\status>bjam --dump-tests test 1>bjam.log 2>&1 > > C:\Programme\boost\status>REM start notepad bjam.log > > C:\Programme\boost\status>process_jam_log 0<bjam.log > Usage: bjam [bjam-args] | process_jam_log [--echo] [locate-root] > locate-root is the same as the bjam ALL_LOCATE_TARGET > parameter, if any. Default is boost-root. > boost_root: C:/Programme/boost/status/.. > locate_root: C:/Programme/boost/status/.. > no errors detected > > C:\Programme\boost\status>compiler_status C:\Programme\boost cs-win32.html > > **** exception(205): std::exception: > boost::filesystem::directory_iterator constructor: > "C:\Programme\boost\status\bin": > The system cannot find the path specified. > ******** errors detected; see standard output for details ******** > > C:\Programme\boost\status>rem Specify links file, even though it will > be overwritten, so report html includes links > > C:\Programme\boost\status>rem This works because the generated > bookmark names are the same regardless of other settings > > > C:\Programme\boost\status>compiler_status --ignore-pass --no-warn > C:\Programme\boost cs-win32-fail.html cs-win32-links.h > tml > > **** exception(205): std::exception: > boost::filesystem::directory_iterator constructor: > "C:\Programme\boost\status\bin": > The system cannot find the path specified. > ******** errors detected; see standard output for details ******** > > C:\Programme\boost\status>compiler_status --ignore-pass > C:\Programme\boost cs-win32-warn-or-fail.html cs-win32-links.htm > l > > **** exception(205): std::exception: > boost::filesystem::directory_iterator constructor: > "C:\Programme\boost\status\bin": > The system cannot find the path specified. > ******** errors detected; see standard output for details ******** > > C:\Programme\boost\status>compiler_status C:\Programme\boost > cs-win32-full.html cs-win32-links.html > > **** exception(205): std::exception: > boost::filesystem::directory_iterator constructor: > "C:\Programme\boost\status\bin": > The system cannot find the path specified. > ******** errors detected; see standard output for details ******** > > C:\Programme\boost\status> I am using vc7.1 on W2 with the latest CVS MAIN. I currently assume this should work under windows, doesn't it? Thank you for help, Roland

1 0

build / install in 1.32
by John Maddock 07 Nov '04

07 Nov '04

Should the following messages be generated during an install? They are rather alarming IMO, there are a huge number of them, and I predict will generate queries along the lines of "is this right, did my build succeed?" HardLink stage\lib\boost_thread-vc71-mt.lib Could Not Find c:\data\boost\release\boost\stage\lib\boost_thread-vc71-mt.lib HardLink stage\lib\libboost_thread-vc71-mt-sgd.lib Could Not Find c:\data\boost\release\boost\stage\lib\libboost_thread-vc71-mt-sgd.lib HardLink stage\lib\libboost_thread-vc71-mt-s.lib Could Not Find c:\data\boost\release\boost\stage\lib\libboost_thread-vc71-mt-s.lib Thanks, John.

3 2

Getting the reference out of boost::any
by Mikhail Glushenkov 06 Nov '04

06 Nov '04

I became interested in subj and quickly found a discussion on boost mailing list dated Jan 2003 (http://lists.boost.org/MailArchives/boost/msg42284.php) where the majority seemed to agree on changing current semantics of boost::any_cast to allow getting the reference to held object. However, these changes never made it to the CVS. Was it by intent or was this issue banally forgotten?

1 0

Unicode strings update
by Erik Wien 06 Nov '04

06 Nov '04

Hi. I just thought I would post a little update on what's happpening with the Unicode library I started a thread about a little while ago. (I apologize for not replying as much as I should have done in that thread, but I have been completely buried in work lately, and simply haven't had the time. =\ ) My college (HiG) has now basically approved the project as a bachelors thesis (at least for the time being), and it is looking very likely that we will go through with it. There's one little snag though. HiG would like to have one person from the boost community functioning as a "contact person" for the project. I'm not sure exactly what kind of workload that imply for such a person (I will try to find out very soon), but I am fairly certain it will just be a matter of answering a few e-mails from them from time to time. After all, the main development will be done in collaboration with the community as a whole, and not that single person. What I basically want to know is, would anyone out there like to take on that resposibillity? I don't think this is an absolute requirement for final approval, but it sure would help! =) Let me just finish off by thanking for all comments you guys made in my first thread. I'm in the process of compiling a list of all the things you pointed out there, and I will most certainly take everything said into concideration when the development (hopefully) gets on the way. As always... Any comments are welcome! ;) Regards - Erik

7 12

usage of uniform_int
by Masaki Nomura 06 Nov '04

06 Nov '04

Dear all: Would anyone let me know the usage of the boost::uniform_int combined with the one argument operator() of the variate_generator? I'd like to change the maximum parameter of the distribution at every step. #include <iostream> #include <boost/random.hpp> int main( void ) { boost::variate_generator< boost::mt19937, boost::uniform_int< std::size_t > > gen( boost::mt19937( 3 ), boost::uniform_int< std::size_t >() ); for ( std::size_t i(1); i < 100; ++i ) std::cout << gen( i ) << std::endl; return 0; } The gcc aborted the compile with the following errors: /usr/include/boost/random/variate_generator.hpp: In member function `typename Distribution::result_type boost::variate_generator<Engine, Distribution>::operator()(T) [with T = unsigned int, Engine = boost::mt19937, Distribution = boost::uniform_int<size_t>]': uniform_int.cpp:9: instantiated from here /usr/include/boost/random/variate_generator.hpp:107: error: no match for call to `(boost::uniform_int<size_t>) ( boost::random::detail::pass_through_engine<boost::random::detail::pass_through_engine<boost::mt19937> >&, unsigned int&)' With regards, Masaki Nomura

2 2

Re: [boost] Re: 1.32 documentation issue
by JOAQUIN LOPEZ MU?Z 06 Nov '04

06 Nov '04

----- Mensaje original ----- De: Beman Dawes <bdawes(a)acm.org> Fecha: Martes, Noviembre 2, 2004 9:06 pm Asunto: Re: [boost] Re: 1.32 documentation issue > At 12:39 PM 11/2/2004, Robert Ramey wrote: > > >Actually after poking around in other pages - specifically the > spirit >documentation I find that its not uncommon for links to > point to > >www.boost.org rather than have a relative path that would keep > the > session > >in the same documentation tree. This would seem to conflict > with the > idea > >that boost should be usable as a CDROM distribution. > > > >I don't know if there's time for this but the inspect should be > enhanced > to > >check for this and all the offending global links should be > altered to > >relative ones. > > We tried to do that at one time, but gave up because it is a bit > tricky. > Some absolute www.boost.org references are correct, such as to the > LICENSE > file, so it isn't as simple as just searching for "www.boost.org/" > in .htm? > files. > > I've just taken a look (using grep) at the CVS RC (not the > tarball) and it > seems that while the problem does happen, particularly in spirit > and graph > libraries, it isn't really horrible. > > I'd say we can wait until after the release ships, then see if we > can come > up with some logic that doesn't generate a lot of false positives. > Automatic detection aside, would it be possible to fix the offending links manually before release? Maybe it's not that straightforward, if those links are generated from BoostBook source. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 2

[1.32 release] Runaway compile process in regression tests
by Zak Kipling 06 Nov '04

06 Nov '04

I'm running the regression tests for the 1.32 draft tarballs -- no problems on x86/debian, but on an amd64/gentoo (gcc 3.3.4 prerelease) machine it still hasn't completed after nearly two days, apparently due to a runaway cc1plus process, compiling numeric/conversion/test/converter_test.cpp. This appears to be due to a bug in gcc -- see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18300. I should have a patch to gcc tested soon; I don't think it's a problem with Boost as such, although there might be a workaround for current compilers (I don't think I understand the numeric converters library well enough to be sure). Zak.

2 1

Compile fix for Boost.Test for aCC on HP-UX
by Ferdinand Prantl 05 Nov '04

05 Nov '04

Hello, you can find a small fix for boost/test/detail/basic_cstring/basic_cstring.hpp attached and a dirty workaround for a compiler bug in aCC for boost/test/unit_test_suite.hpp. As of the latter; the compiler seems to get confused by equal names in different namespaces and classes; renaming Impl helps or making the previous structure friend helps too (this I chose to minimize the change). Ferda HP-UX B.11.11 U 9000/800 aCC: HP ANSI C++ B3910B A.03.37 <<basic_cstring.hpp.diff>>

2 1

[Config] proposal of new macro, BOOST_DECL :follow up for boost::noncopyable & vc7.1 & dll
by Francis ANDRE 05 Nov '04

05 Nov '04

Hi Developers When using the boost.thread package as a dll under vc7.1, one gets for each reference of boost::mutex the C4275 warning for the inherited noncopyable class (in fact 5 times, one for mutex, one for timed_mutex, one for try_mutex, one for thread, and one for thread_group!!) c:\boost\include\boost-1_32\boost\thread\mutex.hpp(34) : warning C4275: non - DLL-interface 'boost::noncopyable_::noncopyable' used as base for DLL-interface 'boost::mutex' In order to avoid such warning, it would be nice to redefine -- again(sic) -- the BOOST_DECL macro and put it as a decorator for all dependent classes used by the boost libraries that could be generated as a dll.(thread, regex, filesystem, and so on). With the empty string as default value in boost/config.hpp, it would the responsability of each boost libraries to setup BOOST_DECL to the correct value when using it as a dll. Cheers Francis ANDRE

5 7

GUI Library Proposal for a Proposal
by Brian Braatz 05 Nov '04

05 Nov '04

(was RE: [boost] Re: GUI library - something to think about) Both http://www.torjo.com/win32gui/save_dlg.html and http://www.litwindow.com/Library/Documentation/documentation.html are extremely interesting. What I see (just after taking a peek at both): Win32Gui Interesting design No macros Looks tied to Win32Gui LitWindow Also interesting design Does have macros Also sits on top of WxWidgets, but it looks like the WxWidgets layer could be abstracted out. I propose that BOTH authors collaborate (on this list) to achieve the following: * Combination of the best of both frameworks * Can sit on WxWidgets OR can have a win32 and xwindows underlying implementation * This would allow it to be in boost, but also be LEAN and not need another framework I believe that if you took both of your thoughts, and accomplished the above bullet points, not only would it be good for boost, but it would really mean that boost had something that was much cooler than what I see available from other (ahem) vendors. I.e. instead of making a boost library that just "provides a layer" over GUI things, this combination would be actually moving the technology forward. (they don't call it "boost" for nothing :) ) I ask that both of you gentlemen seriously consider my proposal. I would also offer to help in any way that I can as I think you both have some really groundbreaking ideas in the realm of GUI frameworks. (fingers crossed) Brian :) > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of John Torjo > Sent: Wednesday, November 03, 2004 9:14 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] Re: GUI library - something to think about > > > struct SomeSettings { > > int m_aMember; > > SomeOtherStruct m_struct; > > vector<string> m_strings; > > }; > > > > the neccessary data adapter definition which you must include in a > > source file looks like this > > > > IMPLEMENT_CONTAINER_ADAPTER(vector<string>) > > > > BEGIN_DATA_ADAPTER(SomeSettings) > > PROP(m_aMember) > > PROP(m_struct) > > PROP(m_strings) > > END_DATA_ADAPTER() > > > > > Sure thing, but how about *true* bindings? > http://www.torjo.com/win32gui/save_dlg.html > > (if you download the code, you'll find quite a few examples: > examples/smart_dialogs) > > Note that you can add correspondences directly to your data + validation > code (no macros whatsoever). > >

10 11

RE: [boost] Re: GUI Library Proposal for a Proposal
by Brian Braatz 05 Nov '04

05 Nov '04

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Jared McIntyre > Sent: Friday, November 05, 2004 7:28 AM > To: boost(a)lists.boost.org > Subject: [boost] Re: GUI Library Proposal for a Proposal > > >Edward Diener wrote: > >> > >>No !!!!! WxWidgets has almost nothing to do with modern C++. Let's no go > >>there, or have anything to do with supporting any other GUI > implementation. > >> > > > >Also, wxWindows is a huge library. If we were to introduce > >something in boost, I'd very much like it to be as small and light > >weight (as win32gui is supposed to be), not a collection of > >multi-megabyte dlls required, just to wrap win32 or what ever the > >underlying library is. > > > >If people want more powerful components, they can be added > >afterwards, but the underlying library around core OS controls > >should be as small as possible. > > > >Thanks > > > >Russell > > Honestly, I don't buy into the idea of cross platform GUI at all. I > have lots of reasons born out of experience with them that I won't > get into here, but in general, I find they are nice for the > developer, but poor for the user. I would much rather write my > backend code in a cross-platform language, and hook it up to a GUI > designed for each platform I support. That is why, at first glance > anyway, I like the idea behind the Lit Window design. Most of the > backend is GUI neutral, allowing you to do more work in your > cross-platform code. In theory, this could be used to simplify the > platform specific GUI code that needs to be written. I'd much rather > see C++ go a route of making it easier to develop for different GUI > libraries than to actually develop one of its own (since I don't > think it would get much use anyway). > > JJared McIntyre > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost [Brian Braatz] " I'd much rather > see C++ go a route of making it easier to develop for different GUI > libraries than to actually develop one of its own (since I don't > think it would get much use anyway)." Yes, and that is what my original mail that started this thread suggested :) Where it gets confusing to talk about, is that by doing that, you end up doing a "little bit" of the work that "already exists" elsewhere. That is ok.

1 0

[serialization] problem with boost/serialization/is_abstract.hpp
by Joaquín Mª López Muñoz 05 Nov '04

05 Nov '04

In MSVC 6.0, the following snippet fails: #include <boost/archive/text_iarchive.hpp> #include <boost/tuple/tuple.hpp> int main() { return 0; } complaining about is_abstract being already defined. The problem lies in the following lines inside boost/serialization/is_abstract.hpp: #ifndef BOOST_TT_IS_ABSTRACT_CLASS_HPP #if defined(__GNUC__) && (34 <= _GNUC__ * 10 + __GNU_MINOR) \ || defined(__MSVC_VER) && (1310 <= __MSVC_VER) \ || defined(__EDG_VERSION__) \ /**/ #include <boost/type_traits/is_abstract.hpp> #else // default to false if not supported namespace boost { template<class T> struct is_abstract { typedef mpl::bool_<false> type; BOOST_STATIC_CONSTANT(bool, value = is_abstract::type::value); }; } // namespace boost #endif #endif // BOOST_TT_IS_ABSTRACT_CLASS_HPP The code is *incorrectly* using __MSVC_VER where it should use _MSVC_VER (just one leading underscore). Thus boost::is_abstract is defined twice, as boost/type_traits.hpp is implicitly included by boost/tupe/tuple.hpp If nobody complains, I can fix this and commit it to the release and main branch. What worries me, though, is that the code above seems flawed to me (apart from the minor typo). What happens if the compiler is not one of those taken care of explicitly in boost/serialization/is_abstract.hpp? Could anyone please test the first snippet in some compiler other than MSVC, ICC for Windows, GCC or an EDG-based compiler? My thesis is that it will fail. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

7 7

Serialization support for mersenne_twister
by Neal D. Becker 05 Nov '04

05 Nov '04

I know I've mentioned this before. I'd really like to see this tiny bit of code added to mersenne_twister: template<class Archive> void serialize(Archive & ar, const unsigned int version) { ar & x; ar & i; } This would make it very easy to use our new serialization library with mersenne_twister. It costs nothing if you don't use it. If you are really paranoid, it could be surrounded by an #ifdef.

3 2

[spirit] select_p problem
by Vyacheslav E. Andrejev 05 Nov '04

05 Nov '04

Hi All, boost::spirit::select_p parser can not be compiled with boost::spirit::rule as argument. The problem is that metafunction boost::spirit::impl::as_embedded_parser<ParserT> returns const reference to boost::spirit::rule, not boost::spirit::rule itself, when PaerserT = boost::spirit::rule. So trying to compile parser_result<as_embedded_parser<rule<> > > deep inside the select_p implementation generates error message that const rule<>& has no result_type. I suggest to change parser_result definition as following: template <typename ParserT, typename ScannerT> struct parser_result { typedef typename boost::remove_reference<ParserT>::type::template result<ScannerT>::type type; }; -- ______________________________ Vyacheslav E. Andrejev System Architect, Excelsior, LLC

2 1

Contacting Chuck Allison [if you don't know how to contact Chuck Allison ignore]
by Vesa Karvonen 04 Nov '04

04 Nov '04

Hi, I would like to query whether The C++ Source (http://www.artima.com/cppsource/index.jsp) would be interested in publishing an article on Lazy Template Metaprogramming. I tried e-mailing the ChuckAllison(a)mailblocks.com -address, but haven't received any response in about 24-hours. So, if you know how to contact Chuck Allison, please forward this message to him. Regards, Vesa Karvonen _________________________________________________________________ Don't just search. Find. Check out the new MSN Search! http://search.msn.com/

2 1

RE: [boost] [Boost-bugs] [ boost-Bugs-1059388 ] shared_ptr::operator->() const return type should be const
by Eyal Farago 04 Nov '04

04 Nov '04

I think you're wront about this, shared_ptr should behave just like a pointer (in this aspect). it really doesn't matter if the pointer is const or not, what matters is the constness of the pointee. typedef int* pint_t; const pint_t p = new int(1); //p is const(same as int * const) int &ref_to_int = *p; //but *p isn't eyal. -----Original Message----- From: SourceForge.net [mailto:noreply@sourceforge.net] Sent: Wednesday, November 03, 2004 12:29 PM To: noreply(a)sourceforge.net Subject: [boost] [Boost-bugs] [ boost-Bugs-1059388 ] shared_ptr::operator->() const return type should be const Bugs item #1059388, was opened at 2004-11-03 13:29 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1059388&group_… Category: smart_ptr Group: None Status: Open Resolution: None Priority: 5 Submitted By: Roland (vzaznobin) Assigned to: Peter Dimov (pdimov) Summary: shared_ptr::operator-> () const return type should be const Initial Comment: shared_ptr::operator-> () const return type should be const const T * operator-> () const; T * operator-> (); ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1059388&group_… ------------------------------------------------------- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

Re: [boost] [serialization] problemwithboost/serialization/is_abstract.hpp
by JOAQUIN LOPEZ MU?Z 04 Nov '04

04 Nov '04

----- Mensaje original ----- De: Aleksey Gurtovoy <agurtovoy(a)meta-comm.com> Fecha: Jueves, Noviembre 4, 2004 7:58 pm Asunto: Re: [boost] [serialization] problemwithboost/serialization/is_abstract.hpp > Joaquín Mª López Muñoz writes: > > In MSVC 6.0, the following snippet fails: > > > > #include <boost/archive/text_iarchive.hpp> > > #include <boost/tuple/tuple.hpp> > [...] > > complaining about is_abstract being already defined. The problem > > lies in the following lines inside > boost/serialization/is_abstract.hpp:> > > #ifndef BOOST_TT_IS_ABSTRACT_CLASS_HPP > > #if defined(__GNUC__) && (34 <= _GNUC__ * 10 + __GNU_MINOR) \ > > || defined(__MSVC_VER) && (1310 <= __MSVC_VER) \ > > || defined(__EDG_VERSION__) \ > > /**/ > > #include <boost/type_traits/is_abstract.hpp> > > #else > > First of all, the whole thing is a huge hack and can cause an ODR > violation on 1-2-3. We should really fix type_traits to fall back to > something like the code below, but that is definitely out for the > release. Yep, I'll take care of this as soon as Boost 1.32 is out -I need it for my own purposes :) > > Having said that, the #else branch is simply missing this: > > # define BOOST_TT_IS_ABSTRACT_CLASS_HPP > [...] > > If nobody complains, I can fix this and commit it to the release and > > main branch. > > Please! Together with the #define, if you can. Consider it done in approx. 12 hours from now. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

small library proposal -- rebind template args and function pointer types
by James Harris 04 Nov '04

04 Nov '04

Hello Boost Members, I have written a small library of meta-functions that allow rebinding of template arguments and function pointer return/argument types. I am posting in an attempt to guage interest and hopefully receive pointers on the library proposal process. The library provides the following meta-functions: rebind<int index, class rebind_type, class source_type> -- rebind template arguments rebind_func_arg<int index, class rebind_type, class func_type> -- rebind argument type of func/method ptr rebind_func_return<class rebind_type, class func_type> -- rebind return type of func/method ptr rebind_method_class<class rebind_type, class func_type> -- rebind class portion of method ptr // --- rebind<> example ------------------------------------------------ template <class A, class B, class C> class foo { }; typedef foo<int, int, int> source_type; typedef rebind<1, char, source_type>::type rebound_type; // rebound_type equates to foo<int, char, int> // --- rebind_func_arg<> example --------------------------------------- typedef int (*func_ptr)(int); typedef rebind_func_arg<0, char, func_ptr>::type rebound_type // rebound_type equates to int (*)(char) // rebind_func_args also works with pointer-to-method types // --- rebind_func_return<> example ------------------------------------ typedef int (*func_ptr)(int); typedef rebind_func_return<char, func_ptr>::type rebound_type // rebound_type equates to char (*)(int) // rebind_func_return also works with pointer-to-method types // --- rebind_method_class<class rebind_type, class func_type> --------- typedef int (foo::*method_ptr)(int); typedef rebind_method_class<bar, method_ptr>::type rebound_type; // rebound_type equates to int (bar::*)(int); -- end examples -- I have tested the code using MSVC 7.1 and GCC 3.3.2-1. Please let me know if this library would be useful to any of you, or otherwise any reason why it is not required or, of course any tips/suggestions/questions that you might have. Kind Regards, James Harris.

4 3

Documentation Bug
by Joshua Berne 04 Nov '04

04 Nov '04

Quick bug in the documentation links for "www.boost.org"'s "Nightly CVS" link. All the library links that don't link to pages under docs/html are broken, since the directory http://www.boost.org/regression-logs/cs-win32_metacomm/ seems to contain only the doc directory, and not the full distribution. (The same aspect of the lib links, that they link to ../../libs/... outside of the doc/html dir, is also breaking the "put a symbolic link to docs/html in my home dir" approach to viewing the boost documentation.. but i'm not sure that's a behaviour anyone endorses.) Hope this helps. - Josh

1 0

surprising accessability of free locking functions for mutex
by Roland Schwarz 04 Nov '04

04 Nov '04

Having followed the discussion about the availability of direct locking of mutexes, I am somewhat surprised that there are free functions available for this purpose. Is this by intent? Is using them simply bad practice? I.e.: boost::mutex m1; boost::detail::thread::lock_ops<boost::mutex>::lock(&m1); is e legal statement. (And indeed is locking the mutex.) Yes I've seen the "detail". Does this imply: Anything that is detail definitely should not go into user programs? I am asking this not for pure 'academic' reasons. What I am trying to do is to find out whether it is possible to write a small wrapper over the existing classes to support a kind of cancellability for my threads, until the "real thing" will be available. Thank you. Roland

2 1

RE: [boost] recursive mutex and condition
by Ben Hutchings 04 Nov '04

04 Nov '04

James Ahlborn <james.ahlborn(a)med.ge.com> wrote: > hey, > I was wondering if any of the boost developers could tell me > if recursive mutexes are supposed to work with conditions? I don't believe so. If waiting for a condition releases the mutex only once, this can result in deadlock, and if it releases the mutex completely the protected data can be seen while its invariant is broken. There seems to be no right way to use recursive mutexes with condition variables. <snip> > I'm testing this on red hat 7.3 and fedora core 2. My guess as to > why it's broken is because the boost condition uses posix recursive > mutexes There's no such thing. > internally, which also seem to fail the recursive mutex/condition > test (at least on the OS's mentioned above). Anyone have any > thoughts on this? <snip> I think you should avoid using recursive mutexes. Read <http://groups.google.com/groups?selm=3434E6BA.ABD%40zko.dec.com>. Ben.

4 4

simplex method of Nelder and Mead
by Neal D. Becker 04 Nov '04

04 Nov '04

I uploaded code for nonlinear optimization via simplex method of Nelder and Mead, to files/simplex section. The origin of this code is somewhat unclear. I wrote this particular version using tx-math as a basis - however the tx-math code is clearly copied from numerical recipes in C. I think the present implementation is sufficiently different from the predecessors - however, I'm not a lawyer.

1 0

RE: [boost] Re: recursive mutex and condition
by Ben Hutchings 04 Nov '04

04 Nov '04

James Ahlborn <james.ahlborn(a)med.ge.com> wrote: > > Ben Hutchings <ben.hutchings <at> businesswebsoftware.com> writes: > > > I don't believe so. If waiting for a condition releases the mutex > > only once, this can result in deadlock, and if it releases the mutex > > completely the protected data can be seen while its invariant is > > broken. There seems to be no right way to use recursive mutexes > > with condition variables. > > umm, using a condition fundamentally implies releasing a mutex and > then reacquiring it. regardless of the mutex type, one needs to make > sure that the invariants are valid when the mutex is released. Yes, I understand all this. <snip> > > I think you should avoid using recursive mutexes. Read > > <http://groups.google.com/groups?selm=3434E6BA.ABD%40zko.dec.com>. > > well, i've programmed significantly in both java and c++ and i think > the poster of that comment is mistaken on many fronts. besides the > obvious bias against java and the seemingly minimal knowledge of how > "synchronized" works in java, "Minimal knowledge"? Does that mean you think he's wrong in fact, or that his opinion about its usefulness is mistaken? > i think the fundamental argument of a recursive mutex being the "lazy > man's mutex" is wrong. In any moderately complex system, trying to > avoid using recursive mutexes adds complexity to the overall design > and eventually breaks the modularity of the system. As I understand it, your reason for using a recursive mutex would be that there are functions that require a weaker invariant and may safely be called from a function that holds the mutex and has broken the normal invariant, but may also be called without the mutex being held. (If a function requires the normal invariant then you need to re-establish that before calling it, and having done so you could safely unlock the mutex, removing the need for it to be recursive.) This means that responsibility for re-establishing the normal invariant for a recursive mutex is divided up between several functions. So how can the single function that waits on the condition re-establish the invariant? Wouldn't that require a gross breach of the modularity you want? <snip> > to return to boost specifically, the implementation of > recursive_mutex and condition seem to imply their combined use. I > see no documentation which says "hey, you should only use condition > with a normal mutex", nor any compiler error when i try to do so. > i see no "fundamental" reason why a recursive mutex and a condition > should not work together (they are quite happy in java). I do. > yet, they don't work, and I'm wondering if that is intended or a > bug in boost. It looks like a documentation bug to me.

6 5

Re: [boost] IO Collection Framework (Output Formatters REDESIGN)
by Vladimir Prus 04 Nov '04

04 Nov '04

[I cc the mailing list] > >>Use () if you want to get the value of a decoration: > >> > >> sep() == "|"; // instrinsinc value > > > > Why would I want to do this? > > In case you need to get the value directly and not lookup based on the > stream. Does the user ever need to do it? Or it's internal mechanism? > >> sep( std::cout ) == "|"; // stream default if sep() == std::string() > > > > So, this means: 'value in sep if any, otherwise value in stream'? > > Yes. There is currently a bug in the implementation if you use "" as a > decorator value (i.e. no decoration) where it will choose the default > value. I am planning to use "\1 def" - a value that is not likely to be > used. Why not fixing the bug? Using "\1 def" for empty decorator is not nice. > >>If you want to see if a decorator is on an input stream, you can use > >> match: > >> > >> io::match( std::cin, sep ); > > > > What are the use cases for this? > > It is primarily used to implement the read function of a format object. > e.g.: > > template< class TraitsT, typename F, typename S > > std::basic_istream< CharT, TraitsT > & > in( std::basic_istream< CharT, TraitsT > & is, F & f, S & s ) const > { > if( !( > match( is, open ) && first.read( is, f ) && Ouch! So 'match' in fact reads 'sep' from the input stream. Your original comment made me thing that it somehow checks that 'sep' is equal to the decorator associated with the stream -- and that made me wonder why it's needed. > >> wrap.decorate( "[[ ", " ]]" ); > >> wrap2.decorate( wrap ); > > > > Why do I need the 'decorate' method as opposed to > > > > wrap = wrapper_decorators<char>("<", ">") > > > > or > > > > wrap.assign("[[", "]]") > > > > The idea that I can decorate a decorator does not seems good for me. Why > > do I need to change decorators in this way? > > At the moment, the default values on the stream applies to all types. > That is, the default value is associated with the decorator id argument. > > I can see why decorate would not be a good name, but assign is not good > either. Consider: > > io::object( vec ).decorate( " / " ); // decorate io::object > io::object( vec ).assign( " / " ); // assign what? > > What I am trying to aim for is: > > io::object( vec ).separator( " | " ) > .openclose( "< ", " >" ); > > but I need to work on implementability (i.e. maintaining the current > functionality). Maybe 'set' would be better for setting the decoration > based on all 3 values or another sequence_decoration object. Probably. I agree that 'assign' in above example is not good. > >To change them, I need to access > > decorators stored on the stream. How do I do that? > > Use io::decorate< CharT > or the c/wdecorate typedefs like this: > > std::cout << io::cdecorate( "[[ ", " ]]" ) > << io::object( vec ) << '\n'; > > >>RATIONALE: RetType -- a class may derive from this class and you may want > >> to chain function calls. For example: > >> > >> derived_class dc; > >> dc.decorate( "/ ", " /" ).derived_fn(); > >> > >>RetType is needed to allow this type of behaviour. > > > > Do you have the need for it at the moment? If not, I suggest you drop > > this template argument. I had something similar in program_options and > > was messy, did not work everywhere and added no value. > > It is needed: the format objects can be passed as arguments to other > format objects. Without the above, this code will not work: > > io::object( vec, fmt::container().decorate( " : " )); > -------------------------------------^ > [error]: cannot find function 'write' in 'sequence_decorators'. You mean that container_formatter derives from sequence_decorators and without RetType the value of fmt::container().decorate() will be sequence_decorators. Looks reasonable, but why not: fmt::container(open_close_delimiters("[", "]")) > >> io::sequence_decorators< char > seq5( wrap ); > > > > Do I ever need to use this constructor? > > Do you mean seq5( wrap )? I don't know. It would depend on what you are > using the library for. I have tried to keep the same arguments for the > constructors and decorator() function. I suspect that user will always specify formatting manually and has no need to convert formatting like this. > >>[6] n-ary objects > >> > >>An n-ary object (currently, 2-ary, 4-ary and 8-ary objects are supported) > >>is a statically-sized sequence of n elements. There is support here for > >>describing how one of these types is constructed and for manipulating its > >>elements. > >> > >>In order to get the nth element of an n-ary object ob, you can use > >> getval: > >> > >> std::cout << io::getval< n >( ob ) << '\n'; > > > > Isn't 'getval' an implementation detail of the library? > > In that it is used to implement the fmt::pair_t and fmt::nary_t classes. I'd suggest you clearly document that it's implementation detail to reduce the amount of information which must be read. > >>BOOST_IO_NARY_PARAM2 is used to register a 2-ary type as containing two > >>different types for elements 1 and 2, e.g. std::pair. > >> BOOST_IO_NARY_PARAM1 is used in all other cases. > >> > >> BOOST_IO_NARY_PARAM2( std::pair, seperable_pair ) > >> BOOST_IO_NARY_PARAM1( std::complex, inseperable_pair< T > ) > > > > And what about 4-ary objects? Still BOOST_IO_NARY_PARAM1? What if there > > are 4 different template parameters? > > BOOST_IO_NARY_PARAM1( boost::math::quaternion, nary4_type< T > ) > BOOST_IO_NARY_PARAM1( boost::math::octonion, nary8_type< T > ) > > The current implementation of n-ary types only supports different > template parameters on 2-ary types. What would be better is something like: > > naryN_type< T1, ..., Tn = Tn-1 > > > The fmt::nary_t format object would need to be extended to support > FormatObject1..N format objects to render the individual elements. Right. I wonder what are you going to do with general tuple<> > >> io::assignval( ob2ary, a, b ); > >> io::assignval( ob4ary, a, b, c, d ); > >> io::assignval( ob8ary, a, b, c, d, e, f, g, h ); > > > > I think you're again discussing implementation, not interface. I don't > > think this function should be initially present in the library public > > interface. > > I see why you would classify it as implementation. It really belongs in > an "extenders guide" rather than a "users guide". Exactly! > For example, if you want to add support for NSPoint (a 2D position > structure from the MacOS Cocoa API), you need to know this information, > e.g.: > > template< int n > > float io::getval( const NSPoint & pt ) > { > return detail::selector< n, float >( pt.x, pt.y ); > } > > Likewise, if you are writing a format object that allows a different > seperator for each division in the output, e.g.: > > open e1 s1 e2 s2 e3 s3 e4 close > where eX are the elements in the n-ary type > and sX are the seperators > > you need to know how to use getval, refval and assignval in order to > implement the format object in a generic way. Understood. > >>[7] automatic type deduction > >> > >>The fmt::deduce function: > >> > >> template< typename CharT, typename T > > >> [undefined] fmt::deduce( const T & ob ); > >> > >>will return an instance to the nested format object construct that maps > >> to the class T. > > > > Ok, we've got to interesting part. I don't understand what's "nested > > format object", what's "construct", and what does it mean for "construct" > > to map to some class. And you haven't defined "format object" yet. > > What I was trying to say with the above sentence is something like: > > The type associated with ob may be a simple type or a more complex type "Type associated with ob"? Is it different from "type of ob"? > like a container or pair type. > If the type is a container or other > sequence-like type, the elements in this type may be sequence-like types. > > A format object is a class that is responsible for reading from and > writing to a stream. There are format objects for different types (like > containers, arrays and pairs). These take template arguments that > specify the format object used to render the elements in the sequence > associated with the format object. > > The type of the object ob passed to fmt::deduce is mapped to the format > object that can render ob. For example, if > T = std::pair< std::list< char >, std::complex< float > > > then fmt::deduce will return a format object of the type > fmt::pair( fmt::container(), fmt::pair()) Now, that is perfectly clear. One question though, if I use deduce(obj), what I can do with the resulting object, except for using it for output? Can I access the nested formatter? If yes, how? If not, then you don't need to deduce nested formatters, the above could return: fmt::pair(fmt::generic_formatter(), fmt::generic_formatter()) where generic_formatter() just calls deduce on the type it's passed and use the returned formatter. In other words: you would not need to have two template parameters for pair_t. > >>In order to save writing code when several types are > >>implemented by a format object, you can map these types into a formatter > >>class type: > >> > >> SEQ_TYPE_TO_FORMATTER( nary2value_type, pair_type ); > >> SEQ_TYPE_TO_FORMATTER( nary2base_type, pair_type ); > >> SEQ_TYPE_TO_FORMATTER( nary2int_type, pair_type ); > > > > Hmm... what's nary2int_type, nary2base_type and nary2value_type? I though > > there's only one type category for n-ary objects, now I see two more. > > The nary2xxx_type categories belong to the type deduction system. They > are used to distinguish between the different typedefs for the element > types. Ideally, this would be better as a type trait: > > element_type< T >::type > where > element_type< std::complex >::type == std::complex::value_type > element_type< boost::interval >::type == interval::base_type > element_type< boost::rational >::type == rational::int_type > etc. Understood. > This would make the deduction system simpler in that you would only need > nary2_type. The problem is how this works with things like std::pair. > One solution would be to return an mpl type list in this instance. How does it work now? > >>As a user, you don't need this, but if you are adding a format object > >> into the type deduction framework, you will need this to extract the > >> nested format object. > > > > Could you rephrase the above? > > Yes. I shall update the evolution.html file with the revised wording. Thanks. > >>A format object is deduced by defining fmt::detail::deduce_type for the > >>formatter class type > > > > What's "formatter class type"? Is that "type category"? > > More like a collapsed type category. For example, the fmt::container_t > format object supports seq_container_type (sequential containers), > assoc_container_type (associative containers) and set_container_type > (set containers). Thus, the format class type for fmt::container_t is > seq_container_type. SEQ_TYPE_TO_FORMATTER is used to perform this collapse. Maybe using jsut "formatter class" would be clearer. And a overview describing the interaction between components is a must. Say, a diagram like: output: object ---- (deduce) ---> formatter --- (operator<<) ---> stream deduce: type - (is_XXX) -> type_category -- (???) ---- > formatter class where arrows join main concepts and paranthethis show the mechanism which converts between those concepts. > >> template<> > >> struct fmt::detail::deduce_type< type > > >> { > >> template< typename CharT, typename T > > > > > What's 'T' here? The type being output? > > Yes I'm lost again. You have: fmt::detail::get_deducer< CharT, T >::type and template<> struct fmt::detail::deduce_type< type > what is the relationship between the two? > >>In addition, the > >>format object may provide additional forms to allow format object > >> nesting. > > > > I did not understood what's generator and when it should be used. > > A generator is a function that will return a format object. This is > similar to make_pair or make_tuple. For example, instead of doing: > > fmt::pair_t< char, fmt::container_t< char > >() > > you can use the generator functions like this: > > fmt::pair( fmt::container()) You know what I'm going to say: a comment is in order. > >>[9] format objects > >><2> pair format object > >> > >>fmt::pair_t< CharT, First, Second > will render 2-ary object types using > >>First to render the first element and Second to render the second. The > >>generator function is fmt::pair() and has the additional form: > >> > >> [unspecified] fmt::pair( const First & f, const Second & s = basic()); > > > > "unspecified"? Shouldn't that be fmt::pair_t<charT, First, Second>? > > It is actually > > fmt::pair_t< typename First::char_type, First, Second > > > I use "unspecified" because the types can be long and complex, for > example, io::object returns: > > io::object_t > < > CharT, T, typename fmt::detail::get_deducer > < > CharT, T > > >::type::format_object > > and I don't want the return type to distract from the functions > specification. OK. > > And BTW, > > I'm strongly against the "_t" suffix. Does it add any information or you > > just _t because 'pair' is already used? What about calling the type > > "pair_formatter"? > > I will change the name in the update I am performing. Good. > > And, why do I ever need to create the formatter explicitly? Can I call > > any methods of it? > > You can save a format style, for example: > > fmt::pair_t< char > parens; > parens.decorate( "( ", " )" ); > > std::cout << io::object( p1, parens ) // ( a, b ) > << io::object( p1 ) // [ a, b ] > << io::object( p2, parens ); // ( a, b ) > > You can also access properties and functions associated with the format > object. For example: > > fmt::pair_t< char, fmt::pair_t< char > > po; > po.first.decorate( " : " ); > po.decorate( "<: ", " :>" ); > > std::cout << io::object( p, po ); // <: [ a : b ], c :> Ok. I'm not sure how usefull it is, but we get this for free. > > I think the name "state format" is a bit unclear. I'd suggest some more > > explicit pre_format_hook/post_format_hook, or something like that. BTW, > > some thinks (and I'd agree) that using 'bool' as parameter to > > function/template is not good. If I look at > > > > state<Foobar, true>() > > > > I have no idea what 'true' means. > > I shall find a better name. I am considering using an enumeration to > define pre, post and pre_post values. For example: > > pre_post_hook< char, pre >() // [hook] elem > pre_post_hook< char, post >() // elem [hook] > pre_post_hook< char, pre_post >() // [hook] elem [hook] > > It may be better to drop this functionality from the initial release of > the library. I think I'd like to be able to output vectors with prepended indices, but I don't know if such generic mechanism is needed. You can have "numbering_formatter", for example, which will output a number of then use nested formatter to output the object itself. If creating formatting is simple, this is better that pre_post_hook, since it's more general. > > Finally: you mentioned you have revised version of the code. Looks like > > it's not in sandbox. Is it possible to take a look? > > I want to work on it further before committing it to the sandbox. You can work in sandbox on a branch, if you don't want to break existing version. There's nothing wrong with adding unfinished version in sandbox -- nobody excepts it to be stable. > I am > going to upload the files to my website shortly. Would be good! - Volodya

1 0

[1.32 Release] New tarballs are available for testing
by Aleksey Gurtovoy 04 Nov '04

04 Nov '04

Updated draft tarballs for the 1.32 release are available from the following locations: http://www.meta-comm.com/engineering/boost/200411020208/boost_1_32_0.tar.bz2 http://www.meta-comm.com/engineering/boost/200411020208/boost_1_32_0.tar.gz http://www.meta-comm.com/engineering/boost/200411020208/boost_1_32_0.zip This update fixes a number of the issues reported earlier, including: - unconventional file/directory privileges (http://article.gmane.org/gmane.comp.lib.boost.devel/112582) - a bug in the filesystem library (http://article.gmane.org/gmane.comp.lib.boost.devel/112565) - missing listing of Program Options library (http://article.gmane.org/gmane.comp.lib.boost.devel/112571) - tarball unpacking problem in "regression.py" - broken links fixes - all other fixes that has been committed to the release branch during the last two days. Once again, 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. The updated list of known issues follows. KNOWN ISSUES ------------ The following is a list of known issues present in the tarballs which grant them their draft status: 1) A small number of unmarked test failures (but no regressions). 2) Two files with broken links as follows: libs/libraries.htm: broken link: ../doc/boost.pdf libs/python/doc/v2/reference.html: broken link: wrapper.html, broken link: wrapper.html#classes, broken link: wrapper.html#override-spec, broken link: wrapper.html#wrapper-spec 3) No documentation in PDF format ("boost.pdf") 4) Placeholder pages in place of the revoked pre-1.32 MPL documentation. If you encounter any issues that are not in the above list, please report them here! TESTING ------- Please see the original announcement for details -- http://article.gmane.org/gmane.comp.lib.boost.devel/112562 -- Aleksey Gurtovoy MetaCommunications Engineering

5 14

[Boost-bugs] [ boost-Bugs-1059936 ] spirit insert_key_actor.hpp
by SourceForge.net 04 Nov '04

04 Nov '04

Bugs item #1059936, was opened at 2004-11-04 02:57 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1059936&group_… Category: functional Group: None Status: Open Resolution: None Priority: 5 Submitted By: Sandford (sandford) Assigned to: Mark Rodgers (mark_rodgers) Summary: spirit insert_key_actor.hpp Initial Comment: Compile error in: insert_key_actor.hpp with MSVC 7.1 Here's the code change that allows it to compile and seems logical. Still testing for full functionality and just starting to use boost. // key_type key(first_,last_); // value_type key_value(key, value_); // ref_.insert( key_value ); ref_.insert( value_ ); Also noticed a flaw in the demo code for inserting into a map, as the key data type is defined as const in map<,>::value_type and thus can not be assigned to. Specific errors are c2078, c2440, c2664. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1059936&group_… ------------------------------------------------------- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re: [boost] Re: 1.32 documentation issue
by JOAQUIN LOPEZ MU?Z 03 Nov '04

03 Nov '04

----- Mensaje original ----- De: David Abrahams <dave(a)boost-consulting.com> Fecha: Miércoles, Noviembre 3, 2004 6:49 pm Asunto: [boost] Re: 1.32 documentation issue > "Robert Ramey" <ramey(a)rrsd.com> writes: > > > When using boost libraries, It is my custom to peruse the local > copy of > > boost documentation on my hard drive. This avoids necessity to > be connected > > to www.boost.org all the time which can be inconvenient in lots > of cases. > > > > The following scenario takes me a way from my local copy. > > > > a) C:\boost_RC_1_32_0\index.htm > > b) select libraries > > c) select function programming section > > d) select function > > e) At this point I am automatically redirected to www.boost.org > > > > I think I should be redirected to ./function.html instead. > > It goes to the web intentionally, on the idea that developers who > don't want to build the documentation (which involves installing an > extensive toolchain) should be able to get to the Boost.Function > documentation. > Isn't this contradictory with this reply? http://lists.boost.org/MailArchives/boost/msg74101.php I thought BoostBook-generated docs come prebuilt into the release tarball, at least for HTML. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

IO Collection Framework (Output Formatters REDESIGN)
by Reece Dunn 03 Nov '04

03 Nov '04

Hi All, I have been working on the library and have got a local reimplementation of my Output Formatters library based on the review comments. There are still a few issues that need to be resolved and I would like to expand stream state support. I have created a preliminary evolution document available at: http://uk.geocities.com/msclrhd/iocoll/evolution.html that outlines what the new functionality looks like. This redesign addresses several of the issues brought up during the review. Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

2 2

1.32 documentation issue
by Robert Ramey 03 Nov '04

03 Nov '04

When using boost libraries, It is my custom to peruse the local copy of boost documentation on my hard drive. This avoids necessity to be connected to www.boost.org all the time which can be inconvenient in lots of cases. The following scenario takes me a way from my local copy. a) C:\boost_RC_1_32_0\index.htm b) select libraries c) select function programming section d) select function e) At this point I am automatically redirected to www.boost.org I think I should be redirected to ./function.html instead. Robert Ramey

4 5

Latest tarball and filesystem auto-link
by Russell Hind 03 Nov '04

03 Nov '04

I've just downloaded the latest tarball and have build the DLLs for win32 using bcc32. I rely on auto-link for pick the correct files to link to, and it is looking for libboost_filesystem-bcb-mt-d-1_32.lib but my project is set to use dynamic RTL (because of boost-thread) so shouldn't it link to boost_filesystem-bcb-md-d-1_32.lib? Thanks Russell

3 4

cds
by mark.rodgers＠cadenza.co.nz 03 Nov '04

03 Nov '04

/Dpfn9j: Permission denied

1 0

Building Boost On Tru64
by Eduardo Bezerra 03 Nov '04

03 Nov '04

Hi, I´m trying to build boost_1_31_0 on a Alpha box running Tru64 version 5.1B. After running bjam "-sTOOLS=gcc" stage I get the following error: /usr/include/pthread.h:328:4: #error "Please compile the module including pthread.h with -pthread" Since I´m a newbie to boost I´m looking for some help to handle this issue. Best regards, Eduardo

2 1

Some comments on program_options/howto.html
by Peter Dimov 03 Nov '04

03 Nov '04

I dutifully followed the link from the --no-foo thread, and I have some comments. The Winmain Command Line section says split_command_line in the text, split_winmain in the example code. The Response Files section shows example code for parsing a response file using Tokenizer. Why shouldn't one be able to use split_command_line instead? There doesn't seem to be any difference between a command line in string format and a response file. Also, response file support doesn't seem proper. Response files should work like this: @file1 --option=value @file2 If file1 contains --option, it will be overriden by the command line. Similarly, all options in file2 will override both file1 and the command line --option=value. From a cursory look at the example, this doesn't seem to be the case, but I may be wrong. An additional parser could have been used to enable this behavior if it were possible to return more than one option/value pair from it. (This would also allow "option bundles" like -O1 expanding into a set of option/values.)

2 5

sourceforge open bugs
by Peter Dimov 03 Nov '04

03 Nov '04

We have two pages of open bugs in the sf.net tracker. Many of them are unassigned and it's not clear who should be the assignee since the maintainer is either inactive or does not appear in the "Assigned to" field. I bet we also have many bugs that are resolved but left open - a typical mistake that, in fact, I just made. ;-) -- Peter Dimov http://www.pdimov.com

1 0

minor compile-time issue with boost::regex (1.32)
by Cory Nelson 03 Nov '04

03 Nov '04

this will cause compile warnings in VC7.1 with the "detect 64bit issues" flag set: boost::match_results<string::const_iterator> what; for(boost::match_results<string::const_iterator>::size_type i=0; i<what.size(); i++) results.push_back(string(what[i].first, what[i].second)); warning C4267: 'argument' : conversion from 'size_t' to 'int', possible loss of data it seems the operator takes an int for index instead of size_type. -- Cory Nelson http://www.int64.org

2 3

[Boost-bugs] [ boost-Bugs-1059388 ] shared_ptr::operator-> () const return type should be const
by SourceForge.net 03 Nov '04

03 Nov '04

Bugs item #1059388, was opened at 2004-11-03 13:29 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1059388&group_… Category: smart_ptr Group: None Status: Open Resolution: None Priority: 5 Submitted By: Roland (vzaznobin) Assigned to: Peter Dimov (pdimov) Summary: shared_ptr::operator-> () const return type should be const Initial Comment: shared_ptr::operator-> () const return type should be const const T * operator-> () const; T * operator-> (); ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1059388&group_… ------------------------------------------------------- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

RE: [boost] Re: [1.32 Release] Draft tarballs are available
by Michiel Salters 03 Nov '04

03 Nov '04

[offtopic] The "Save As..." dialog is implemented as an explorer dialog, which means you can right-click on the offending file and change the permissions there. Aftert that you can "save as" directly over the original. Works in many windows apps. [/offtopic] -- Michiel Salters. > -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org]On Behalf Of Aaron W. > LaFramboise > Sent: maandag 1 november 2004 21:38 > To: boost(a)lists.boost.org > Subject: Re: [boost] Re: [1.32 Release] Draft tarballs are available > > And keep in mind that unlike our Emacs users, not everyone > has an editor > for which overriding read-only attributes is easy. On more than one > occasion have I been trying to edit the read-only source files of some > foolish distribution, remotely in an editor that doesn't > support writing > to read-only files, or shell escapes. Its a real pain, even > on Windows, > to have to manually browse for the offending file and change its > permissions when Notepad spits back some error message about not being > able to save my work. > > Aaron W. LaFramboise > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

1 0

RE: [boost] Re: GUI library - something to think about
by Brian Braatz 03 Nov '04

03 Nov '04

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Hajo Kirchhoff > Sent: Tuesday, November 02, 2004 10:52 AM > To: boost(a)lists.boost.org > Subject: [boost] Re: GUI library - something to think about > > Hello all, > > > Considering the fact that some of the Boosters work on the GUI library, > > I would like to throw something to the mix: > > I wasn't aware that some people here were into GUI work! > > In that case I'd like to gauge interest in my work: > > http://developers.slashdot.org/article.pl?sid=04/10/18/1118242 > > and the homepage at > > http://www.litwindow.com/library > > > This is a two part library. The base part is UI independent while the > second part aims at reducing the work for UI coding. > [Brian Braatz] Wow- that's pretty interesting. Are you considering submitting this for Boost?

2 1

FORMAL review of "Output Formatters" - results
by John Torjo 03 Nov '04

03 Nov '04

Dear all, We got a lot of feedback relating the "Output Formatters" library [1]. "Yes" votes : 4 "No" votes: 2 "Abstain" votes: 2 Conclusions: - The docs and naming of the classes/functions could certainly be improved. - Seems a lot of people want this for pretty output, testing, debugging. - People don't need this library to provide ANY input facilities - quite a few people wanted a redesign. Thus, I wil consider this library "Pending Acceptation". In other words, it's considered Accepted by default, but since it will be redesigned, a new short review will take place. Reece will redesign the library, and a new formal review will take place within 3 months from now. This review will take less time - I assume 7 days. I will talk to Tom and Reece and schedule a next review date. Best, John [1] Just in case you still want a peek at the old code: http://www.torjo.com/code/outfmt.zip (153Kb) -- 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

20 54

Tarball testing
by Aleksey Gurtovoy 02 Nov '04

02 Nov '04

Dear regression runners, As we are closing in on the release, I'd like to ask everybody to switch from the release branch to tarball testing. If you are currently using "regression.py", the switch is almost trivial: 1) Download the updated "regression.py" from http://www.meta-comm.com/engineering/boost/regression.py 2) Download the archive of your choice: http://www.meta-comm.com/engineering/boost/200411020208/boost_1_32_0.tar.bz2 http://www.meta-comm.com/engineering/boost/200411020208/boost_1_32_0.tar.gz http://www.meta-comm.com/engineering/boost/200411020208/boost_1_32_0.zip 3) Place the script and the archive in the same directory (e.g. the same one you are currently using for tests on the branch) 4) Modify the script command line to include '--local' option: python regression.py --local=<archive name> [<all other options>] For example, python regression.py --local=boost_1_32_0.zip --runner=metacomm --toolsets=msvc,vc7,vc-7_1,cw-8_3 --pjl-toolset=vc-7_1 5) That's it. If you are using "collect_and_upload_logs.py", simply change '--tag=RC_1_32_0" to "--tag=boost_1_32_0". All test results will be uploaded to ftp://fx.meta-comm.com/boost-regression/boost_1_32_0/, picked up by the reporting tools, and displayed in the usual location -- http://www.meta-comm.com/engineering/boost-regression/developer/index.html. Thank you! -- Aleksey Gurtovoy MetaCommunications Engineering

4 3

Request for data-member smart pointer
by Oleg Fedtchenko 02 Nov '04

02 Nov '04

To Peter Dimov Hi, Peter Could you, please, tell if is there a smart pointer template to a class data-member. I failed to find an appropriate pointer among five ones existing in the boost. I need it for the two tasks appended. By this time, I have written an extension to intrusive_ptr to meet these needs. If you or anyone else are interested I could post it or send in person. Oleg boostoleg(a)yandex.ru Task 1) class A { public: A(){ m_wData = 0;} WORD* GetData(){ return &m_wData} A* CreateA( int nOffset){ return new A;} protected: WORD m_wData; }; main() { A aInstance; WORD* pData = aInstance.CreateA( 15)->GetData(); *pData = 57; // access violation } Task 2) class DocActiveX { protected: Tree* m_pTree; public: ~DocActiveX(){ if(m_pTree) delete m_pTree;} bool Load( const char* lpszPath); Tree* Parse(){ return m_pTree;} }; class DocDirect { protected: Tree* m_pTree; public: ~DocDirect(){ if(m_pTree) delete m_pTree;} bool Load( const char* lpszPath); Tree* Parse(){ return m_pTree;} }; class ShowExternal { public: bool Show( const Tree* pTree); }; class SomeClass { protected: Tree* m_pTree; }; void SomeClass::OnLoad() { DocActiveX* pInstance = new DocActiveX; aInstance.Load( lpszSomePath); m_pTree = aInstance.Parse(); } void SomeClass::OnShow() { ShowExternal ashow; ashow.Show( m_pTree); }

5 19

[tuple] which version to take ?
by Patrick Kowalzick 02 Nov '04

02 Nov '04

Dear all, I am not sure which version of tuples is actual and should be used: -The version in boost/tuple is working and seems consitent to the manual on the boost homepage. -The version in boost/spirit/fusion/sequence is working too and seems to be consistent to "C++ Standard Library Technical Report". tuple_size and tuple_element exist, which do not exist in the first version. Why are there two versions? Which one shall I use? Any recommendations? Thank you, Patrick P.S.: I have another short question, and need a small hint (what to search ;) ) for kind of a "compile time for-loop". Something like this: index[0] = fw_index::template get_index< tuples::tuple_element< 0, TTuple>::type >(); index[1] = fw_index::template get_index< tuples::tuple_element< 1, TTuple>::type >(); ...

6 7

permission problems with latest tar
by Neal D. Becker 02 Nov '04

02 Nov '04

PYTHON_ROOT=/usr PYTHON_VERSION=2.3 bjam -sTOOLS=gcc stage ...patience... ...patience... ...found 5608 targets... ...updating 1283 targets... MkDir1 stage mkdir: cannot create directory `stage': Permission denied mkdir "stage" ...failed MkDir1 stage... ...skipped <directory-grist>stage/lib for lack of <directory-grist>stage... MkDir1 bin mkdir: cannot create directory `bin': Permission denied I fixed it by doing: find . -type d | xargs chmod 775

1 1

boost::any
by Dirk Gregorius 02 Nov '04

02 Nov '04

Hi, I have a std::vector<boost::any> m_Processes containing several hydrological processes where a process is implemented like this: template<typename DerivedT> class Process { public: DerivedT& asDerived( void ) { return static_cast<DerivedT&>( *this ); } void Apply( Subbasin& subbasin ) { asDerived().Apply( subbasin ); } } Special Processes are derived from Process and pass their type as template argument ( Barton and Nackman Trick ). I am writing a simulation software for hydrological simulation and want to test if I can get a better performance when getting rid of the virtual function overhead since all types are know at compile time. I want to iterate over all elements of m_Processes in a function void AdvanceTyp( void ). The below implemention doens't work, but will show my intend: template<typename DerivedT> void Subbasin::AdvanceTime( void ) { // Call Process::Apply for each element and pass a *this for_each( m_Processes.begin(), m_Process.end(), bind2nd( mem_func_ref( Process<DerivedT>::Apply, *this ) } At the moment the compiler can't resolve the template argument. How do I have to implement the function, such that it can be resolved by the compiler? -Dirk

2 1

Problems building PDF documentation
by Aleksey Gurtovoy 02 Nov '04

02 Nov '04

While building PDFs for standalone libraries (BB2 is one example) works without a glitch, we were unable to build the master "boost.pdf", due to what appears to be a problem in FOP: ... fop-nt ..\bin.v2\doc\debug\boost.pdf [INFO] FOP 0.20.4 [INFO] building formatting object tree [ERROR] property - "font-selection-strategy" is not implemented yet. [ERROR] property - "line-height-shift-adjustment" is not implemented yet. [ERROR] property - "last-line-end-indent" is not implemented yet. [INFO] [4] [INFO] [5] [INFO] [6] [INFO] [7] [INFO] [8] [INFO] [9] [INFO] [10] [INFO] [11] [INFO] [12] [ERROR] region-name 'xsl-footnote-separator' doesn't exist in the layout-master-set. [ERROR] property - "last-line-end-indent" is not implemented yet. ... [ERROR] property - "last-line-end-indent" is not implemented yet. [INFO] [17] [INFO] [18] [INFO] [19] [INFO] [20] [INFO] [21] [INFO] [22] [ERROR] java.lang.NullPointerException set JAVA_HOME=C:/WINDOWS/system32/java.exe C:/PROGRA~1/FOP-02~1.4/fop.bat ..\bin.v2\doc\debug\boost.fo ..\bin.v2\doc\debug\boost.pdf ...failed fop-nt ..\bin.v2\doc\debug\boost.pdf... ...failed updating 1 target... ...updated 32 targets... This is using: xsltproc --version xsltproc was compiled against libxml 20614, libxslt 10111 and libexslt 809 libxslt 10111 was compiled against libxml 20614 libexslt 809 was compiled against libxml 20614 DocBook XSL 1.66.1 stylesheets FOP 0.20.4/0.20.5 (identical results) on Windows. It's probably possible to get to the root of the issue by commenting out different parts of "doc/src/boost.xml" until it's buildable, but in what little time we could devote to investigating this, we didn't have much success going this route. It would be greatly appreciated if somebody could take a look at this. -- Aleksey Gurtovoy MetaCommunications Engineering

2 2

program-options, --switch and --no-switch
by Neal D. Becker 02 Nov '04

02 Nov '04

Any suggestion on how to implement the common gnu idiom: --switch and --no-switch? bool_switch seems perfect for implementing --switch, but what about --no-switch (which should set switch_value to false)?

2 3

Strange Linux regressions
by Aleksey Gurtovoy 02 Nov '04

02 Nov '04

A number of libraries fail with various versions of GCC and Intel with the following output (e.g. http://tinyurl.com/4q93w) g++: Internal compiler error: program as got fatal signal 11 and (http://tinyurl.com/3s92x) icpcbin: error: Fatal error in /opt/intel/compiler70/ia32/bin/mcpcom, terminated by segmentation violation Martin, is this the dreadful memory problem that you've been talking about? -- Aleksey Gurtovoy MetaCommunications Engineering

3 4

[1.32 Release] Draft tarballs are available
by Aleksey Gurtovoy 02 Nov '04

02 Nov '04

Draft zip/tarballs for the 1.32 release are available from the following locations: http://www.meta-comm.com/engineering/boost/boost_1_32_0.tar.bz2 http://www.meta-comm.com/engineering/boost/boost_1_32_0.tar.gz http://www.meta-comm.com/engineering/boost/boost_1_32_0.zip These are NOT the tarballs that will be released; rather, they are the first probe aiming to uncover whatever problems we are still unaware of (including problems with archives preparation), or, if there are none, to confirm that pending a few issues below, we are finally ready to release. For your convenience, the unpacked contents is also 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. KNOWN ISSUES ------------ The following is a list of known issues present in the tarballs which grant them their draft status: 1) A small number of unmarked test failures (but no regressions). 2) A small number of broken links as follows: doc/html/date_time/doxy.html: broken link: ../../../boost/date_time/dst_transition_day_generators.hpp, broken link: ../../../boost/date_time/local_time_base.hpp doc/html/date_time/posix_time.html: broken link: ../../../libs/date_time/doc/time_duration_inherit.png doc/html/libraries.html: broken link: ../boost.pdf libs/libraries.htm: broken link: ../boost.docbook, broken link: ../boost.fo, broken link: ../boost.pdf libs/numeric/conversion/doc/converter.html: broken link: udt_support.html libs/numeric/conversion/doc/converter_policies.html: broken link: udt_support.html 3) No documentation in PDF format ("boost.pdf"), due to some build issues (I'll post separate email on this). 4) Placeholder pages in place of the revoked pre-1.32 MPL documentation. If you encounter any issues that are not in the above list, please report them here! TESTING ------- To run regression tests on the archives, you need to: 1) Grab the archive for your platform from one of the above locations. 2) Grab the latest "regression.py" from http://www.meta-comm.com/engineering/boost/regression.py 3) Put the archive and "regression.py" in the same directory and invoke the latter with the following command line: python regression.py --local=<archive name> --runner=<your runner id> --toolsets=<your toolsets> [<more options as needed>] For example, python regression.py --local=boost_1_32_0.zip --runner=metacomm --toolsets=msvc,vc7,vc-7_1,cw-8_3 --pjl-toolset=vc-7_1 The results will be automatically uploaded to ftp://fx.meta-comm.com/boost-regression/boost_1_32_0/. Finally, thanks in advance to everybody who will be looking at this! -- Aleksey Gurtovoy MetaCommunications Engineering

14 37

RE: [boost] Re: [1.32 Release] Draft tarballs are available
by Stefan Seefeld 02 Nov '04

02 Nov '04

> From: Aleksey Gurtovoy [mailto:agurtovoy@meta-comm.com] > Sent: November 1, 2004 10:04 > > No unix source package I ever downloaded had read-only files. > > Could our long-time unix users confirm/negate this experience? youp. > > That gives no protection, really. > > It prevents you from accidental editing/deletion. As a machine's administrator I would explicitely set the permissions (and ownership, of course) of all files, anyways. > Completely unlike it, IMO. In the above situation, it's a CVS > checkout, > you are a developer, and editing is a normal workflow. Everything is > exactly the opposite with the tarball. I don't quite agree. The 'developer' role has meaning only in a given context. Read: It's not because I shouldn't modify code in the boost repository that I shouldn't be able to mess with my copy of a release tarball. Regards, Stefan

3 2

Dynamic pluggable factories?
by Boost Rookie 01 Nov '04

01 Nov '04

Hi, is there anything in Boost which resembles the dynamic pluggable factories as described in the article "Industrial Strength Pluggable Factories" written by Timothy R. Culp and published in the October 1999 issue of C++ Report (available online http://www.javareport.com/joop/crarticle.asp?ID=1520)? If there is no such thing, has something like it been discussed? dismissed? I for one can see a real need for it! /br __________________________________ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com

4 3

[1.32 Release] Second draft of the tarballs is available
by Misha Bergal 01 Nov '04

01 Nov '04

Fixed privileges: * Unix: files/directories are writable/readable by owner and readable by others. Consequenty, regression.py now is able to correctly unpack the tarballs on Unix systems. * Windows: all files are writable The zip/tarballs are available from the following locations: http://www.meta-comm.com/engineering/boost/boost_1_32_0.tar.bz2 http://www.meta-comm.com/engineering/boost/boost_1_32_0.tar.gz http://www.meta-comm.com/engineering/boost/boost_1_32_0.zip -- Misha Bergal MetaCommunications Engineering

1 0

Re: [boost] Draft tarball & multi - index
by JOAQUIN LOPEZ MU?Z 01 Nov '04

01 Nov '04

----- Mensaje original ----- De: Craig Carr <craig.carr(a)perform-sol.com> Fecha: Lunes, Noviembre 1, 2004 7:39 pm Asunto: [boost] Draft tarball & multi - index > I don't know if this is valid here, but all none of the examples > in the multi-index library examples compile with vc7.1. All produce > internal compiler errors except basic.cpp > > Craig. Hi Craig, Boost.MultiIndex ought to work with that compiler. Have you checked the following? http://boost- consulting.com/boost/libs/multi_index/doc/compiler_specifics.html#msvc_7 1 If you haven't done so, please turn /Gm off. Please report whether this solves the problem. Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

too much typing
by Neal D. Becker 01 Nov '04

01 Nov '04

I'm always writing (e.g.) std::vector<double> out (size); std::transform (in.begin(), in.end(), out.begin(), func); Wouldn't it be nice to have versions of the std algorithms that worked like: template<typename out_cont_t, typename in_cont_t, typename UnaryOperation> inline out_cont_t transform_r (const in_cont_t& in, UnaryOperation u) { out_cont_t out (boost::size (in)); std::transform (boost::begin (in), boost::end (in), boost::begin (out), u); return out; } Then you can say: std::vector<double> out = transform_r<std::vector<double> > (in, func); That is, the first template parameter is the desired return container type, and the algorithm constructs the return value into it. Since constructors can be elided, I think this may be just as efficient as the original, or maybe better. OK, perhaps it looks like I didn't save much typing, but when you chain function calls you save a lot.

5 4

Draft tarball & multi - index
by Craig Carr 01 Nov '04

01 Nov '04

I don't know if this is valid here, but all none of the examples in the multi-index library examples compile with vc7.1. All produce internal compiler errors except basic.cpp Craig.

1 0

Re: [boost] [filesystem] regressions for operations_test
by JOAQUIN LOPEZ MU?Z 01 Nov '04

01 Nov '04

----- Mensaje original ----- De: Beman Dawes <bdawes(a)acm.org> Fecha: Domingo, Octubre 31, 2004 11:03 pm Asunto: Re: [boost] [filesystem] regressions for operations_test > At 03:56 PM 10/31/2004, JOAQUIN LOPEZ MU?Z wrote: > >Hi, > > > >msvc, msvc-stlport, iw-7_1-vc6 > >and iw-7_1-vc6-stlp-4_5_3 currently fail this > >test (see for instance http://tinyurl.com/4xo4a) > >I don't know for sure, but I've got the hunch this > >might be related with the fact that 2004 is > >a leap year and today we've had a 1-hour adjustment > >in some countries due to the daylight saving policy. > >These two facts combined might yield an offset > >outside the expected range. > >Just wanted to note this in case it might ring a > >bell for somebody. > > Or it might just be because offsets cross the daylight savings > time > boundary. > Well, that's what I was saying. The leap year and the cross-daylight saving issues combined will yield a time difference of 366*24*3600+3600 seconds, off the expected value by 1 hour. > I'll wait until the tests have cycled again, and then take a look. > If my theory's correct, these tests will revert to normal by November 2. This phenomenon will happen again 2008, October 26 to 28, and 2012 October 28 to 30. In 2016, however, the cross-daylight offset plays on the subtracting raher than the adding side, so the tests won't fail :) Excuse my indulgence on this silly issue. Joaquín M Lópeez Muñoz Telefónica, Investigación y Desarrollo

1 0

Lazy Metaprogramming Library [UPDATE]
by Vesa Karvonen 01 Nov '04

01 Nov '04

Hi, I have made some optimizations (resulting in an order of magnitude (10x) improvement in compile-time in some cases on GNU g++) to the library and implemented a couple of new metafunctions. The latest snapshot can now be downloaded from the Files Section (both zip and tar.bz for your convenience): http://groups.yahoo.com/group/boost/files/LazyMPL/ Please note that the library is only a proof-of-concept made in about 2 days. It should be quite possible to provide a more comprehensive library of lazy metafunctions and provide facilities like the lambda-facility of Boost MPL. (Also, you shouldn't worry about the upper case naming used in the library.) Lazy template metaprogramming, as shown by the lazy metaprogramming library, eliminates the number one stumbling block of template metaprogramming as described by every introduction or guide to template metaprogramming (e.g. http://www.boost.org/libs/mpl/doc/#applyif and Generative Programming section 10.11.1.3 Taking Advantage of Lazy Behavior (particularly pages 441-443... "You should remember this when writing static code" ;)). In lazy template metaprogramming, invocations (::type) are only needed when a value needs to be explicitly examined (e.g. to extract the head of a list). Use of the typename-keyword can be practically eliminated and forwarding (use of inheritance) is the usual way to implement functions. Explicit invocations can (are) also be used for optimizing lazy metafunctions, but optimizations are just optimizations. There is no need to optimize unless the metaprogram executes too slowly. It is likely that user metacode can rely on optimized library primitives for the most part. Regards, Vesa Karvonen <--- README-file ---> Lazy Metaprogramming Library ============================ Vesa Karvonen vesa_karvonen(a)hotmail.com This is a minimal proof-of-concept library that shows how one can implement lazy template metaprograms. Problem ------- Most contemporary template metaprogramming libraries are strict, which means that the result of a metafunction call is evaluated completely once the metafunction is invoked. Furthermore, metafunctions are written so that the arguments they receive are assumed to be completely evaluated. In addition to strictly evaluated function calls, most strict programming languages provide lazy control structures, such as `if' and `while', that evaluate their subexpressions only when needed. In contemporary template metaprogramming libraries, the separation between lazy control structures and strict metafunctions is often quite fuzzy, which can make programming quite confusing and burdensome. Basically, a programmer using a contemporary template metaprogramming library has to explicitly annotate the evaluation order of the metacode by carefully selecting when to invoke and when not to invoke a metafunction. The invocations can not simply be completely left out, because strict metafunctions do not accept uninvoked arguments. Solution -------- The metaprogramming style used in this library is different. Metafunctions and metadata structures (type lists) in this library are designed to be lazy. In particular, metafunctions assume that the arguments they receive are only delayed promises to compute the value of the argument once explicitly invoked. This change of style eliminates the need to constantly think about evaluation order. Metafunction invocations are only needed when a value explicitly needs to be examined. For example, the metafunction `HEAD<l>' evaluates to the head of the given list `l'. In order to do that, `HEAD' needs to explicitly invoke the parameter `l' to expose the list constructor `CONS' for pattern matching. However, and most importantly, callers of `HEAD' do not need to invoke the actual parameter for `HEAD'. (Explicit invocations can also be used for optimization, but it isn't strictly necessary.) In theory, the style used in this library could be the ideal way to implement template metaprograms, because the C++ standard almost requires template instantiations to be cached, which means that delayed promises are actually computed only once, saving CPU time. In other words, C++ implementations are almost required to perform memoization. In practice, however, the representation of type information may take a lot of memory and access to the instantiation cache isn't necessarily implemented efficiently. This can make lazy metaprograms less efficient in terms of time and space than their strict counterparts. Contents of the package ----------------------- The `inc/lazy_mpl' directory contains the library implementation. Only a minimal core plus a few higher-order functions on lists are provided. The list functions imitate the Haskell 98 standard prelude functions. The `test' directory contains a couple of ad hoc tests demonstrating the lazy programming style and the use of lazy lists. To get most out of the code, you should take a look at the unoptimized implementations of the higher-order list manipulation metafunctions `MAP', `FOLD[R|L]', `APPEND', `TAKE', `DROP', `ITERATE', `FILTER', and `ZIP_WITH'. As you can hopefully see, they are very cleanly expressed. That is how lazy metaprogramming would look like to a casual user. Future work ----------- This library is only a proof-of-concept. The intention is to show that lazy template metaprogramming is not only possible, but can yield both powerful and readable metaprograms. One important remaining issue would be to implement a lambda mechanism of some sort, which would make the use of higher-order metafunctions more convenient. Another issue would be to study how to best optimize lazy metafunctions. Many of the metafunctions in the library have been manually optimized by considering which of their arguments are strict (always invoked) and then making the implementation take advantage of the strictness by invoking the arguments early. The optimizations do not change the way the metafunctions are used (assuming the optimizations are correct), but can have a significant effect (order of magnitude) on performance. (I have not proven that the manually introduced optimizations are correct---I wouldn't be surprised if some of the optimization were incorrect.) Hopefully a good selection of optimized lazy metafunctions can practically eliminate the need for library users to manually optimize their code. At any rate, optimizations are only needed when a metaprogram evaluates too slowly. Copyright --------- (C) Copyright Vesa Karvonen 2004. Distributed under the Boost Software License, Version 1.0. (See accompanying file LICENSE.) _________________________________________________________________ Don't just search. Find. Check out the new MSN Search! http://search.msn.com/

2 1

[filesystem] regressions for operations_test
by JOAQUIN LOPEZ MU?Z 31 Oct '04

31 Oct '04

Hi, msvc, msvc-stlport, iw-7_1-vc6 and iw-7_1-vc6-stlp-4_5_3 currently fail this test (see for instance http://tinyurl.com/4xo4a) I don't know for sure, but I've got the hunch this might be related with the fact that 2004 is a leap year and today we've had a 1-hour adjustment in some countries due to the daylight saving policy. These two facts combined might yield an offset outside the expected range. Just wanted to note this in case it might ring a bell for somebody. Regards, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

[serialization] The problems with CW...
by Rene Rivera 31 Oct '04

31 Oct '04

I took some time to take a closer look at what the current test failures could be about on the cw-8.3 compiler... before I go on vacation. Specifically I looked at the test_exported errors as those seemed to be common to both the 9 and 8 versions of CW. My findings... I managed to get the export tests to *pass* by modifying the test itself (see attached). The problems boils down to the behavior of CW to only instantiate templates when they are used. This not just applies to class templates, but to template methods. In the case of the exported tests it does not instantiate two important things: a) The serialize template method of non-directly referenced derived classes. Specifically for test_exported: polymorphic_derived1::serialize<test_oarchive>, polymorphic_derived1::serialize<test_iarchive>, polymorphic_derived2::serialize<test_oarchive>, and polymorphic_derived2::serialize<test_iarchive>. Forcing those to be instantiated generates all the rest of the self registration code for the derived classes. This still leaves: b) The archive serialization instance for the needed specializations is also not generated as they are not directly reference. Only the ones for the base class, polymorphic_base, are generated as that's the class used in the actual de/serialize calls. I'm not sure anything can be done about fixing this for the release as the only solutions I can come up with would involve changing the serialization interfaces. HTH. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq =================================================================== RCS file: /cvsroot/boost/boost/libs/serialization/test/test_exported.cpp,v retrieving revision 1.4 diff -u -r1.4 test_exported.cpp --- test_exported.cpp 22 Jul 2004 06:39:17 -0000 1.4 +++ test_exported.cpp 29 Oct 2004 19:36:07 -0000 @@ -40,6 +40,7 @@ class polymorphic_derived1 : public polymorphic_base { friend class boost::serialization::access; +public: template<class Archive> void serialize(Archive &ar, const unsigned int /* file_version */){ ar & BOOST_SERIALIZATION_BASE_OBJECT_NVP(polymorphic_base); @@ -49,10 +50,19 @@ }; BOOST_CLASS_EXPORT(polymorphic_derived1) +namespace { + void (polymorphic_derived1::* pd1so_p)(test_oarchive &,const unsigned int) = &polymorphic_derived1::serialize<test_oarchive>; + void (polymorphic_derived1::* pd1si_p)(test_iarchive &,const unsigned int) = &polymorphic_derived1::serialize<test_iarchive>; +} +template<> +const boost::archive::detail::pointer_iserializer<polymorphic_derived1, test_iarchive> boost::archive::detail::pointer_iserializer<polymorphic_derived1, test_iarchive>::instance; +template<> +const boost::archive::detail::pointer_oserializer<polymorphic_derived1, test_oarchive> boost::archive::detail::pointer_oserializer<polymorphic_derived1, test_oarchive>::instance; class polymorphic_derived2 : public polymorphic_base { friend class boost::serialization::access; +public: template<class Archive> void serialize(Archive &ar, const unsigned int /* file_version */){ ar & BOOST_SERIALIZATION_BASE_OBJECT_NVP(polymorphic_base); @@ -62,6 +72,14 @@ }; BOOST_CLASS_EXPORT(polymorphic_derived2) +namespace { + void (polymorphic_derived2::* pd2so_p)(test_oarchive &,const unsigned int) = &polymorphic_derived2::serialize<test_oarchive>; + void (polymorphic_derived2::* pd2si_p)(test_iarchive &,const unsigned int) = &polymorphic_derived2::serialize<test_iarchive>; +} +template<> +const boost::archive::detail::pointer_iserializer<polymorphic_derived2, test_iarchive> boost::archive::detail::pointer_iserializer<polymorphic_derived2, test_iarchive>::instance; +template<> +const boost::archive::detail::pointer_oserializer<polymorphic_derived2, test_oarchive> boost::archive::detail::pointer_oserializer<polymorphic_derived2, test_oarchive>::instance; // save exported polymorphic class void save_exported(const char *testfile)

4 4

[serialization] Plans for C++ standard style reference docs
by Andreas Huber 31 Oct '04

31 Oct '04

At the risk of asking something that has probably been asked before: Are there any plans to add C++ standard style reference documentation for serialization? The current tutorial & reference are good and probably describing most of what one would like to know about the library. However, at various places I would really have preferred a description of the exact effects of a particular function, complete with pre-/post-conditions and exceptions that could possibly be thrown. Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.

4 6

Circular log buffer
by Darren Cook 31 Oct '04

31 Oct '04

I'm finding an increasing need for an in-file memory log: specifically when my program asserts I want to see where it has been. There are two problems with normal logging, i.e. appending to a disk file: * The files get very, very big (I've filled my home partition before) * All that writing to disk slows the application down noticeably. I checked log4cpp and John Torjo's logging library and neither seem to offer this, but it seems it could fit as one of the logging targets. I had in mind an object that is a wrapper for e.g. a 1Mb char buffer with the same interface as std::ostream, so I can just write: log_buffer<<"In func1, x="<<x<<", obj="<<obj<<"\n"; And then when my program asserts I can pass log_buffer as a parameter to be output (requires it to have operator<< defined): SMART_ASSERT(y!=1)(y)(log_buffer); Does anyone know of anything along these lines? Does anyone have the same need, or just me? I found some circular buffers that nearly do what I want [1] [2] [3], but they are lower-level as they don't offer the ostream interface. (In my case I don't need thread-safety.) Darren [1]: http://www.codeguru.com/Cpp/Cpp/cpp_mfc/arrays/article.php/c4013/ [2]: http://www.codeguru.com/Cpp/Cpp/cpp_mfc/buffers/article.php/c859/ [3]: Thread-safe circular queue, CUJ, June 2004.

6 12

ATTN: Merging changes to the release branch
by Aleksey Gurtovoy 31 Oct '04

31 Oct '04

Folks, Can I gently ask everybody to be more careful with integration of changes from the main trunk to the release branch? If you have to do it, please double-check everything (in particular, run the diffs) before committing the merged files. We've already got the new "boost/index.html" contents with *1.33.0* section stub in the release branch, and dealing with more of something like this is not going to help the release. Thanks, -- Aleksey Gurtovoy MetaCommunications Engineering

8 7

[1.32 Release] Fixing tabs/links/filenames -- the last round
by Aleksey Gurtovoy 31 Oct '04

31 Oct '04

Dear All, I'd appreciate if you bear with me one more time and find a moment to fix the following issues ASAP (see http://www.meta-comm.com/engineering/boost/issues.html) algorithm --------- libs/algorithm/minmax/index.html: broken link: ../../../../boost/minmax.hpp, broken link: minmax_benchs.html assign ------ libs/assign/test/list_inserter.cpp: tabs in file libs/assign/test/list_of.cpp: tabs in file build ----- tools/build/v2/index.html: broken link: ../../../doc/html/bbv2.installation.html, broken link: doc/html/index.html tools/build/v2/test/railsys/program/Jamfile: tabs in file tools/build/v2/test/test_system.html: unlinked file BoostBook-generated, need to be fixed in sources: doc/html/bbv2/advanced/jamfiles.html: broken link: ../../doc/extending.html#main_target_rules doc/html/bbv2/extender.html: broken link: ../../../example/customization doc/html/bbv2/howto.html: broken link: ../../../../../more/mailing_lists.htm#jamboost doc/html/bbv2/installation.html: broken link: ../../../jam_src/index.html#building_bjam, broken link: ../../jam_src/index.html doc/html/bbv2/tutorial/prebuilt.html: broken link: ../../doc/recipes.html#site_config_targets date_time --------- boost/date_time/local_time/posix_time_zone.hpp: tabs in file boost/index.htm: broken link: libs/date_time/doc/Changes.html BoostBook-generated, need to be fixed in sources: doc/html/date_time/details.html: broken link: ../../../libs/tokenizer/index.htm doc/html/date_time/doxy.html: broken link: ../../../boost/date_time/dst_transition_day_generators.hpp, broken link: ../../../boost/date_time/local_time_base.hpp doc/html/date_time/posix_time.html: broken link: ../../../libs/date_time/doc/time_duration_inherit.png graph ----- boost/graph/adjacency_list.hpp: tabs in file boost/graph/detail/adjacency_list.hpp: tabs in file libs/graph/src/graphviz_digraph_parser.cpp: tabs in file libs/graph/src/graphviz_graph_parser.cpp: tabs in file boost/index.htm: broken link: libs/graph/doc/astar_search.html, broken link: libs/graph/doc/floyd_warshall_shortest.html, broken link: libs/graph/doc/fruchterman_reingold.html iterator -------- libs/iterator/doc/filter_iterator_ref.html: unlinked file libs/iterator/doc/indirect_iterator_ref.html: unlinked file libs/iterator/doc/issues.html: unlinked file libs/iterator/doc/iter-issue-list.html: unlinked file libs/iterator/doc/iterator_adaptor_ref.html: unlinked file libs/iterator/doc/make_filter_iterator.html: unlinked file libs/iterator/doc/ref_problem.html: unlinked file libs/iterator/doc/zip_iterator.html: broken link: ../example/zip_iterator_examples.cpp numeric ------- libs/numeric/conversion/doc/converter.html: broken link: udt_support.html libs/numeric/conversion/doc/converter_policies.html: broken link: udt_support.html python ------ libs/python/doc/new-conversions.html: unlinked file libs/python/doc/tutorial/doc/html/index.html: broken link: ../../index.htm, broken link: ../../more/faq.htm, broken link: ../../more/index.htm, broken link: ../../people/people.htm, broken link: libraries.html libs/python/doc/tutorial/doc/html/python/embedding.html: broken link: ../../../../building.html%20Building, broken link: ../../../index.htm, broken link: ../../../more/faq.htm, broken link: ../../../more/index.htm, broken link: ../../../people/people.htm, broken link: ../../v2/handle.html, broken link: ../../v2/handle.html#allow_null-spec, broken link: ../libraries.html libs/python/doc/tutorial/doc/html/python/exception.html: broken link: ../../../index.htm, broken link: ../../../more/faq.htm, broken link: ../../../more/index.htm, broken link: ../../../people/people.htm, broken link: ../libraries.html libs/python/doc/tutorial/doc/html/python/exposing.html: broken link: ../../../index.htm, broken link: ../../../more/faq.htm, broken link: ../../../more/index.htm, broken link: ../../../people/people.htm, broken link: ../libraries.html libs/python/doc/tutorial/doc/html/python/functions.html: broken link: ../../../index.htm, broken link: ../../../more/faq.htm, broken link: ../../../more/index.htm, broken link: ../../../people/people.htm, broken link: ../libraries.html libs/python/doc/tutorial/doc/html/python/hello.html: broken link: ../../../index.htm, broken link: ../../../more/faq.htm, broken link: ../../../more/index.htm, broken link: ../../../people/people.htm, broken link: ../libraries.html libs/python/doc/tutorial/doc/html/python/iterators.html: broken link: ../../../index.htm, broken link: ../../../more/faq.htm, broken link: ../../../more/index.htm, broken link: ../../../people/people.htm, broken link: ../libraries.html libs/python/doc/tutorial/doc/html/python/object.html: broken link: ../../../index.htm, broken link: ../../../more/faq.htm, broken link: ../../../more/index.htm, broken link: ../../../people/people.htm, broken link: ../libraries.html libs/python/doc/tutorial/doc/html/python/techniques.html: broken link: ../../../index.htm, broken link: ../../../more/faq.htm, broken link: ../../../more/index.htm, broken link: ../../../people/people.htm, broken link: ../libraries.html libs/python/doc/v2/bibliography.html: unlinked file libs/python/doc/v2/errors.html: broken link: ../../../function/doc/reference.html#functionN libs/python/doc/v2/faq.html: broken link: ../tutorial/doc/creating_packages.html, broken link: ../tutorial/doc/reducing_compiling_time.html libs/python/doc/v2/from_python.html: unlinked file libs/python/doc/v2/header.html: unlinked file libs/python/doc/v2/overview.html: unlinked file libs/python/doc/v2/pickle.html: broken link: ../tutorial/doc/extending_wrapped_objects_in_python.html libs/python/doc/v2/rationale.html: broken link: ../../../../../people/dave_abrahams.htm, unlinked file libs/python/pyste/doc/introduction.html: broken link: ../../doc/tutorial/doc/exposing_classes.html libs/python/pyste/doc/policies.html: broken link: ../../doc/tutorial/doc/call_policies.html libs/python/pyste/doc/running_pyste.html: broken link: ../../doc/tutorial/doc/building_hello_world.html libs/python/pyste/index.html: broken link: introduction.html range ----- libs/range/doc/intro.html: unlinked file regex ----- libs/regex/performance/input.html: unlinked file serialization ------------- libs/serialization/doc/contents.html: broken link: definitions.html, broken link: doc/configuration.html, broken link: faq.html, invalid character in URL: overview.html#Other implementations libs/serialization/doc/serialization.html: broken link: ../../../boost/serialization/shared_count.hpp, broken link: bibliograph.html#14 libs/serialization/src/basic_iarchive.cpp: tabs in file libs/serialization/test/Jamfile: tabs in file libs/serialization/test/test_non_default_ctor2.cpp: tabs in file libs/serialization/vc7ide/Boost Serialization Library.sln: nonportable path libs/serialization/vc7ide/Boost Serialization Library.suo: nonportable path signals ------- boost/signals/signal_template.hpp: tabs in file boost/signals/slot.hpp: tabs in file libs/signals/src/signal_base.cpp: tabs in file libs/signals/src/slot.cpp: tabs in file thread ------ libs/thread/src/xtime.cpp: invalid (cr only) line-ending utility ------- boost/utility/base_from_member.hpp: tabs in file libs/utility/generator_iterator.htm: unlinked file libs/utility/operators.htm: broken link: function_output_iterator.htm TIA, -- Aleksey Gurtovoy MetaCommunications Engineering

5 15

guidelines on portable 'catch(...)' usage
by Stefan Seefeld 30 Oct '04

30 Oct '04

hi there, I'v recently run into a problem with 'catch(...)' on MSVC 7.1, where a segmentation fault resulted in a 'first-class exception' (!) that was caught by 'catch(...)' even though the stack wasn't unwound. My first reaction was to abandon the use of 'catch(...)' entirely, replacing it with a more specific equivalent (which I believe to be better practice anyways). However, browsing some boost code I now find other people using such catch-all statements, and so I'd like to get your feedback on how to use it portably. Are my findings false concerning MSVC's highjacked use of C++ exceptions for program errors (i.e. POSIX' equivalent of signals) ? Thanks, Stefan

8 7

teststreams.cpp and VC8.0
by Victor A. Wagner Jr. 30 Oct '04

30 Oct '04

I got tired of getting the exceptions so I fixed time_formatters.hpp which had a logic error in it. It's possible that the test should now be run on all platforms again. Since I don't know how to alter which tests actually run on which platforms I cannot fix that. Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

6 11

reverse_iterator_example binaries cleanup
by Aleksey Gurtovoy 30 Oct '04

30 Oct '04

Martin, Could you please remove "reverse_iterator_example" test binaries ("libs/utility/reverse_iterator_example") for the next regression run? I've moved this and other iterator examples over to "libs/iterator/test", not the least so that the report tools have a chance to correctly report their failures. TIA, -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

[1.32 Release] Some libs missing from doc/src/boost.xml
by Joaquín Mª López Muñoz 30 Oct '04

30 Oct '04

Some new libs (assign, minmax, multi_index, numeric_conversion, range, I think these are all) are not listed in doc/src/boost.xml 1. Should they be there? I don't know for sure what this .xml is supposed to do, and I couldn't find info about it either in the submission guidelines nor in the releasing procedure notes. 2. If so, I'd volunteer to fill the gap, but I'm afraid I'll be out of CVS access during this weekend, so somebody else will have to take up the task. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

MPL for_each test case
by Hugo Duncan 30 Oct '04

30 Oct '04

Aleksey, The normal case and the borland workaround in for_each.cpp test case seem to be the wrong way round. Hugo Index: libs/mpl/test/for_each.cpp =================================================================== RCS file: /cvsroot/boost/boost/libs/mpl/test/for_each.cpp,v retrieving revision 1.12 diff -r1.12 for_each.cpp 67,70d66 < mpl::for_each<numbers>( < boost::bind(&std::vector<int>::push_back, &v, _1) < ); < #else 74a71,74 > #else > mpl::for_each<numbers>( > boost::bind(&std::vector<int>::push_back, &v, _1) > );

2 1

Test
by Victor A. Wagner Jr. 29 Oct '04

29 Oct '04

Several of my recent messages have gone awry (they had multiple recipients). This is a test of a message with but one destination to see if it can get delivered. Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

1 0

time.hpp messed up
by Cory Nelson 29 Oct '04

29 Oct '04

it seems like time.hpp isn't finding the "special_values" type. when compiling with vc7.1 i get this error: C:\Boost\include\boost-1_32\boost\date_time\time.hpp(63) : error C2146: syntax error : missing ')' before identifier 'sv' -- Cory Nelson http://www.int64.org

2 3

RE: [boost] [jamboost] Boost.Build V2, Milestone 10 released
by Brian Braatz 29 Oct '04

29 Oct '04

> On Behalf Of Vladimir Prus > > > I'm pleased to announce that the next milestone release of Boost.Build V2 > is > available at > > http://prdownloads.sourceforge.net/boost/boost-build-2.0-m10.tar.bz2 > http://prdownloads.sourceforge.net/boost/boost-build-2.0-m10.zip > [Brian Braatz] (Applause!)- I would like to thank you guys for the good work done here. :)

1 0

Re: [Boost-testing] teststreams.cpp and VC8.0
by Victor A. Wagner Jr. 29 Oct '04

29 Oct '04

At Friday 2004-10-29 04:52, Aleksey Gurtovoy wrote: >Victor A. Wagner Jr. writes: > > At Thursday 2004-10-28 23:42, Victor A. Wagner Jr. wrote: > > >I got tired of getting the exceptions so I fixed time_formatters.hpp > which > > >had a logic error in it. > > >It's possible that the test should now be run on all platforms again. > > >Since I don't know how to alter which tests actually run on which > > >platforms I cannot fix that. > > > > > > so I run the regression script I have.... it doesn't rebuild the vc8.0 > > teststreams.exe > > what's up? > >That's a question for Boost.Build folks, I'm afraid. for some reason, multiple addresses didn't seem to work yesterday for me (my stuff didn't get to the boost developer list...maybe this will > > > > _surely_ I don't have to figure out what tests are affected by an include > > file change > >I'd think so. > >-- >Aleksey Gurtovoy >MetaCommunications Engineering > >_______________________________________________ >Boost-Testing mailing list >Boost-Testing(a)lists.boost.org >http://lists.boost.org/mailman/listinfo.cgi/boost-testing Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

1 0

Problem with multi_index_container
by Ilya Shvetsov 29 Oct '04

29 Oct '04

Hi All! This program demostrate the problem <code> #include <boost/multi_container_index.hpp> #include <boost/multi_index/ordered_index.hpp> int main(int argc, char* argv[] typedef boost::multi_index::multi_index_container<int> int_set; int_set s; int_set::iterator itr = s.begin(); ++itr; return 0; } </code> Program hangs up in increment if s is empty. I undestand that this is my problem. But may be "assert" can be inserted for such cases -- Ilya Shvetsov KranX Productions

2 2

C++ library with matrix inversion?
by Bronek Kozicki 28 Oct '04

28 Oct '04

I know that question is little off-topic here, but I hope there is someone who can answer it. Could you recommend some C++ library for matrix calculation that supports matrix inversion? Blizt++ does not have it, neither boost.ublas. Or I missed it. Ideas? TIA B.

8 8

RE: [boost] Circular log buffer
by Ferdinand Prantl 28 Oct '04

28 Oct '04

Hi Darren, > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Darren Cook > > I'm finding an increasing need for an in-file memory log: > specifically when my program asserts I want to see where it has been. > > There are two problems with normal logging, i.e. appending to > a disk file: > * The files get very, very big (I've filled my home > partition before) > * All that writing to disk slows the application down noticeably. Usually you have to suffer the pain of the disk-writes because you need the log-file to analyze the reason of some crash and then the unflushed memory buffer to loose would not help much... The problem of disk space is normally solved by log rotating (parameters line maxlogfilesize and maxlogfilecount of a usual logging framework). If the logging causes unacceptable delays and is still required and cannot be moved to other parts of code with more details, I could imagine logging into a shared memory and a separate logging process flushing this memory to disk. I have not seen an ostream-like implementation for this, however. But circular buffer should be somewhere in the boost-sandbox. Ferda

2 1

BGL bidirectional adjacancy_list problem
by Hugo Duncan 28 Oct '04

28 Oct '04

We just updated to a recent cvs version of boost, and an algorithm that was taking three minutes is now running for over an hour. I think there are two problems, but am not at all sure of the analysis: The proximate cause seems to be the correction of the remove_edge function for bidirectional adjacancy_list based graphs in around June. Trying to see how to speed things up, I have run into these problems i) remove_edge is now O(E), due to the edge properties being stored on the graph rather than on a vertex. ii) removing properties from the edges changes nothing, a container of no_property's is still maintained. As I am not too familiar with the adjacancy_list implementation, can anyone confirm this? Hugo

2 5

Why no conversion from weak_ptr<T> to bool?
by Jonathan Biggar 28 Oct '04

28 Oct '04

It seems straighforward, it would just return !expired(). Any reason why not? -- Jonathan Biggar jon(a)levanta.com

2 1

Re: Boost Digest, Vol 894, Issue 1
by Michael Stevens 28 Oct '04

28 Oct '04

Hi Bronek, On Thursday 28 October 2004 08:42, Bronek Kozicki <brok(a)rubikon.pl> wrote: > I know that question is little off-topic here, but I hope there is > someone who can answer it. Could you recommend some C++ library for > matrix calculation that supports matrix inversion? Blizt++ does not have > it, neither boost.ublas. Or I missed it. Ideas? Linear algebra libraries generally avoid such inverse functions. This is because there are many algorithms possible depending on the properties of the matrix. The procedure is generally in two steps: decompose (factorise) the matrix in to simpler factors solve the linear equations using the factors Generally the above is done with LAPACK Have a look at "Linear Algebra with uBLAS" http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Linear_Algeb… As mentioned there uBLAS also has an experimental "lu.hpp" which provide the LU factorisations (for square non-singular matrices) directly. These functions are experimental and without documentation so any feedback would be appreciated. Michael -- ___________________________________ Michael Stevens Systems Engineering Navigation Systems, Estimation and Bayesian Filtering http://bayesclasses.sf.net ___________________________________

1 0

[Q]: What is the recommended logging facility for boost: log4cpp or ??
by Francis ANDRE 28 Oct '04

28 Oct '04

Hi I am wondering what is the logging facility recommended by the boost community: We are using log4cpp and are quite satified for now of its functionnalities. But as usual, it is a separate package, not anymore maintained and out of the boost foundry... What 's your opinion on this subjet?? Cheers Francis -- A good friend will come bail you out of jail.......... but, a true friend....will be sitting next to you saying: "...that was fun."

15 43

[thread] doc formatting
by Vladimir Prus 28 Oct '04

28 Oct '04

There is a minor problem with Boost.Thread docs. On http://www.boost.org/regression-logs/cs-win32_metacomm/doc/html/libraries.h… the "Boost.Thread" header is in bold, while is different from names of all other libraries. On http://www.boost.org/regression-logs/cs-win32_metacomm/doc/html/threads.html "Boost.Thread" is also in bold. That is causes by the declaration of Boost.Thread entity in libs/doc/thead/entities.xml file. Is it possible to either change the definition of the entity of its usage? At least, the <title> should not be in bold. - Volodya

1 0

Boost libraries naming convention
by Tony Juricic 28 Oct '04

28 Oct '04

Just checking on my understanding of the motivation for current library names, prompted by some work on updating Visual Studio IDE projects. I assume that Boost version, build (i.e. debug or release) and CRT specific names like: libboost_serialization-vc71-mt-1_32.lib, libboost_serialization-vc71-mt-gd-1_32.lib and similar are intended for binary distribution of libraries, where end user is not even expected to use bjam, but simply link with the library that she needs. OTOH, the executables link with version, build and CRT-linkage independent library names like: libboost_serialization.lib. I assume that this is done simply for build convenience, since library is nothing else but a packaged set of object modules, whatever name you give to it. In fact, when I build boost with VC++ 7.1, using command: bjam -sTOOLS=vc-7_1<RETURN> (VC++ 7.1 environment variables are assumed set at this point) in my "...bin\boost\libs\test\build\libboost_test_exec_monitor.lib\vc-7_1\debug\th reading-multi" directory I see both libboost_test_exec_monitor-vc71-mt-gd-1_32.lib and libboost_test_exec_monitor.lib libraries, and, as I would expect, they are exactly identical. The *only* case where both libraries are *not* built is for "runtime-link-static\threading-multi" build, where I see only version-specific library, such as libboost_test_exec_monitor-vc71-mt-sgd-1_32.lib, for example. Am I missing some deep rationale behind the build logic and names given to the libraries, or? Tony

2 1

boost::signals - member-functions as slots
by Dirk Gregorius 27 Oct '04

27 Oct '04

Hi, I have a short question regarding the boost::signals library. Is it possible to connect a member function to a signal or must the passed slot be either static or be a function object? If yes what would be the syntax to pass the function and the associated object reference? -Dirk

3 2

Re: pqs - physical quantities library
by Patrick Kowalzick 27 Oct '04

27 Oct '04

Hi Andy, I just read your post in boost.devel list, and took a brief look on your angle page: http://www.servocomm.freeserve.co.uk/Cpp/physical_quantity/angles.html I searched for the question: "Should angles be modulo? (IOW should 361 degrees ---> 1 degree etc.)" and was not really surprised to find it. I wanted to know how you treat this problem :). Here just my opinion: -we encountered here a problem with weights in calculations, meaning an angle was weighted via its a-priori error, which is an angle as well. Setting this angle to 360 degree was fatal. The programm crashed setting the error back to 0, what is not recommend in a division 1/error (hihi). It was fatal, but 361 degree would have been even worse, producing a result what is definitly not expected. -So we discussed if an angle bigger than 360 degree exists, and IMO - yes. Imagine you turn yourself 2 times, than you have a rotation of 720 degree and not 360 degree. I like more your idea with the modulo function, but keep in mind, that some applications use -180 to 180 degree and other 0 to 360 degree. And last, what is your opinion here: you might use clockwise-angles or counter-clockwise-angles. Is it necessary to distinguish these types? Thanks, regards, Patrick "Andy Little" <andy(a)servocomm.freeserve.co.uk> wrote in message news:<clapov$vpe$1(a)sea.gmane.org>... > Hi, > > I have been continuing with my physical-quantities library over the last > year, > http://www.servocomm.freeserve.co.uk/Cpp/physical_quantity/index.html > and I am now seeking feedback as to whether it is worth putting this forward > as a boost library proposal.... > > *Overview* > > The physical-quantity type-family provides methods for modeling > physical-quantities in C++ programs. The advantages and extra functionality > over inbuilt types used in the role include, compile time > dimensional-analysis checking, automatic conversion between units and an > increase in source code comprehensibility. The type family includes two > types, firstly a type where the units are fixed at compile-time referred to > in the text as a ct-quantity and secondly a type where the units can be > run-time modified, referred to in the text as an rt-quantity. > > The ct-quantity has many similar features to an inbuilt-type: > > - concrete type with simple,consistent semantics close to those of > inbuilt-types. > - aims for speed and code size performance close to that of in-built types. > - requires no special framework to use. > > *Application areas* > > The application areas are very wide, including scientific-engineering, CAD, > 3D games programming among many others. > > *Future directions* > > 2D and 3D vector quantities, scene-graphs and scene-modelling, Graphics > interface (eg OpenGL), splines and curve analysis, successive approaximation > , piecewise differentiation and integration algorithms. finite element > analysis, etc etc. > > Issues from the previous thread on the library and physical quantities in > general > > http://aspn.activestate.com/ASPN/Mail/Message/boost/1926782 > > issue: Angles. > > current status: Angles are implemented.There are two types, irrational (ie > radians) and > rational fractions of revolution ie degrees minutes etc). radians are what > you might call a 'weak type'. (Though this behaviour can be modified by a > macro switch). They will implicitly decay to (say) double and can be > implicitly cast to double. However they also allow implicit conversions to > and from degrees etc. hence an implicit conversion from degrees to radians > can occur if a function has a radians argument, but not a double argument. > They are also useful for output of units. > --------------------- > issue: Differentiating different but dimensionally equivalent types. > > current status: This is implemented. > --------------------- > issue: Implicit conversions between units. > > current status: Implicit conversions are intrinsic. They are practical > instinctive and > useful. > --------------------- > issue: You should be using mpl. > > current status: Hopefully I will be able to get hold of the metaprogramming > book soon, at > which point I can decide whether there are advantages. > --------------------- > > regards > Andy Little > > > > > > > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost >

3 2

[mpl] need help with 'extended template parameter matching'
by Jonathan Turkanis 27 Oct '04

27 Oct '04

Dear All, I'm trying to write a metafunction rebind which, when fed a specialization T<P1,...,Pn> of an n-ary template T, returns T<mpl::_, ...., mpl::_>. This is straightforward if default template arguments are not considered when matching template template parameters. (See http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#150.) E.g., template<typename T> struct rebind { typedef T type; } template<template<typename> class T, typename P> struct rebind< T<P> > { typedef T<mpl::_> type; }; template<template<typename, typename> class T, typename P1, typename P2> struct rebind< T<P1, P2> > { typedef T<mpl::_, mpl::_> type; }; etc. On GCC 3.4.1 (and I assume earlier versions too) this leads to ambiguity errors. To workaround this problem, I've resorted to using enable_if and mpl::aux::template_arity, e.g., template<typename T, typename Enabler = void> struct rebind { typedef T type; } template<template<typename> class T, typename P> struct rebind< T<P>, typename enable_if< mpl::equal_to< typename mpl::aux::template_arity< T<P> >::type, mpl::int_<1> > >::type > { typedef T<mpl::_> type; }; I have two questions: 1. is my analysis correct? 2. is there a better solution? Best Regards, Jonathan

2 2

regression report out of sync?
by Joaquín Mª López Muñoz 27 Oct '04

27 Oct '04

Seems like the developer report at http://www.meta-comm.com/engineering/boost-regression/developer/index.html is out of sync with the uploaded tests at ftp://fx.meta-comm.com/boost-regression/RC_1_32_0/ Although the developer report is being rebuilt every two hours or so, its contents are a couple of days older than the stuff at the FTP directory. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

RE: [SPAM] [boost] Re: Shortcut regex notation
by Schalk_Cronje＠McAfee.com 27 Oct '04

27 Oct '04

>What is a C++ focus group? A collection of randomly selected people who give their opinions >on proposed changes to C++? Consider it to be a an informal study group or c++ users group. It is basically an initiative in the company whereby engineers get together once a week to discuss and talk about a C++ topic. The idea is to really further everyone's knowledge of C++ which, hopefully would lead to more effective C++ usage. Different boost libraries are regular topics. >Something like this would fit in easily with Eric Niebler's xpressive library. In fact, I >suggested it, but Eric said it was "too cute". Perhaps we should convene a focus group to >discuss the subject. ;-) Sarcasm aside, I am glad to see someone else came up with the same idea. I would not consider it to be 'cute', a 'tour of force' possibly, yes. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

Problem with the Color Map for DFS visit algorithm
by Manas Singh 27 Oct '04

27 Oct '04

I am having problem with passing a color map to depth_first_visit algorithm. I have defined my graph as follows: typedef adjacency_list < vecS, vecS, directedS, property<vertex_color_t, default_color_type, property<vertex_count_t, int> > > graph_t; I have defined a vector of default_color_type as follows: std::vector<default_color_type> colors(num_vertices(g)); I am calling dfs visit as follows: depth_first_visit(graph, start_vertex, visitor(vis_count), colors.begin( )); But while compiling I am getting error. Is there any easy way of passing color maps to depth_first_visit ? Regards, Manas.

2 1

[serialization] Loading objects of classes with customized operator new
by Andreas Huber 27 Oct '04

27 Oct '04

Hi Robert Under release.html#todo you say that it is currently not possible to use serialization with types that define their own new/delete operators. In serialialization.html#constructors you describe a technique how types that do not possess a default constructor can be serialized. Given the design of load_object_ptr and load_construct_data it seems that this is easily possible, namely by overloading load_object_ptr. I'm therefore wondering whether the remark under release.html#todo is outdated or whether I'm missing something. Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.

2 2

[assign] initializing nested data structures
by Jonathan Turkanis 27 Oct '04

27 Oct '04

Hi, I'm trying to use Boost.Assign to test an output formatting facility, but I'm having trouble translating pseudocode with brace-initializers into working C++. E.g., how to you translate this: vector< list< pair<string, string> > > v = { { make_pair("hello", "goodbye"), make_pair("morning", "evening"), make_pair("cold", "hot") }, { make_pair("hello", "goodbye"), make_pair("morning", "evening"), make_pair("cold", "hot") } }; The following works on VC7.1, but not on como or gcc 3.4.1: vector< list< pair<string, string> > > v = list_of( list_of( make_pair("hello", "goodbye") ) ( make_pair("morning", "evening") ) ( make_pair("cold", "hot") ) ) ( list_of( make_pair("hello", "goodbye") ) ( make_pair("morning", "evening") ) ( make_pair("cold", "hot") ) ); What am I doing wrong? Best Regards, Jonathan

2 2

Any interest in adding unicode support to boost?
by Erik Wien 26 Oct '04

26 Oct '04

Hi. I am in the process of planning a library for handling unicode strings in C++, and would like to probe the interest in the boost community for something like that. I read through the unicode dicussion that was up back in april, and from what I could gather there was some amount of interest, but no one felt comfortable taking on the task as of yet. I am hoping to be able to run this project as my Bachelor's Thesis in Computer Engineering (Not sure if that is the correct translation from Norwegian.) and if it gets approved by my college, myself and two other programmers will spend one semester working exclusively on this. (of course in collaboration with the boost community) At the end of that semester I hope the library (Or at least parts of it) will be in such a state it can submitted for review by boost. The library should ultimately have suppport for at least basic handling of unicode strings (in all encodings), collation of strings and other locale specific operations. The library should also be (to the extent that is possible) integrated with the standard C++ library (and boost) to get as much functionality as possible "for free". I'm here thinking of, among other things, the std::locale class and compabillity with iostreams. How these requirements are fulfilled will be determined as the project (hopefully) moves forward. I really feel the C++ language needs some form of standardized unicode support, and developing such a library within the boost community would be a very good way to ensure it fits everybody's needs the best possible way. If you have any, and I do mean ANY, thoughts on this, please do not hesitate to reply to this mail and let me know. I'm looking forward to your responses. Best regards Erik Wien - Gjøvik College (Høyskolen i Gjøvik), Norway.

22 149

[serialization] binary archives and text/binary streams
by Russell Hind 26 Oct '04

26 Oct '04

There seems to be a problem on win32 where if you use a stream opened in text mode for a binary archive, you get errors. The following code asserts because 'd' appears to have a random value on the way back in. If you open both streams in binary mode then the code runs fine. XML archives don't have the same problem. I realise you shouldn't use a binary archive with a text stream, but is there anyway to catch this at compile or run time? Otherwise you just end up with a corrupted archive? Thanks Russell double d = -6.7; { ofstream ofs("C:\\test.dat"); archive::binary_oarchive oa(ofs); oa & d; } d = 0.0; { ifstream ifs("C:\\test.dat"); archive::binary_iarchive ia(ifs); ia & d; } assert(std::abs(d + 6.7) < 0.0001);

3 3

MSVC 6 usage of typename keyword
by christoph＠familie-koegl.de 26 Oct '04

26 Oct '04

Hi, sorry if this is a stupid question but I haven't found an answer in the mail archive. I can hardly believe that it hasn't been asked before. Everywhere in the boost libs I see code like namespace boost { // Just a simple "envelope" for non-type template parameters. Useful // to work around some MSVC deficiencies. template <typename T, T n> struct non_type { }; } The problem is the "typename T" part. MSVC 6 does not compile this, it wants "class T". How do I get around this MSVC deficiency (I have SP 5 installed, at least my admin says so)? Isn't there something like BOOST_TEMPLPAR_TYPENAME_KEYWORD that is defined to be equal to class for MSVC <= 6 (and maybe others) an equal to typename for able compilers? Cheers, Christoph

2 1

[variant] regressions in GCC 2.95 --seemingly an MPL-related problem
by Joaquín Mª López Muñoz 26 Oct '04

26 Oct '04

I think I've reduced the problem Boost.Variant is having with GCC 2.95 (see for instance http://tinyurl.com/4sd7u and http://tinyurl.com/4dqqd) The attached snippet works OK for GCC 3.2 and other compilers, but ICEs on GCC 2.95, with the same problem shown in Boost.Variant. The culprit has to do with transform (and other MPL algoritmhs) dealing with expressions of the form: apply1<lambda<sizeof_<_1> >::type,_1> wich AFAIK are correct (otherwise somebody please correct me.) In case it is not possible to fix this in the MPL, I think I can hack a specific workaround for GCC 2.95 into the code of Boost.Variant, but I guess trying to fix MPL first is more sensible. HTH Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 5

Thoughts on Unicode strings
by Daryle Walker 26 Oct '04

26 Oct '04

I think that there should be at most two _external_ Unicode string types: 1. vector of Unicode code-points externally each element is like a int32_t 2. vector of abstract Unicode characters externally each element is a group of Unicode code-points (a primary or starting code point, followed by combiner codes) Option [2] is what we ultimately want, so [1] should be included only if really needed. Internally, such strings could use UTF-8, UTF-16, etc., but most users don't care about that from an outside perspective. Some users do care about the outside appearance. (I think some guy here wanted UTF-8 XML.) In those cases we have a specific input or output routine that uses an appropriate encoding object, to hide whether or not the Unicode string internally uses the same encoding as the final source/sink. The internals of the Unicode string could use the cluster concept, like in Mac OS X's Cocoa. Here we would make concrete classes for UTF-8, UTF-16, UTF-32, etc. strings. (We could include normalization and other factors in combinations too.) The external class would keep a union (or something) that uses one of the concrete classes. Iterators probably should be made for code points and/or abstract characters. Bidirectional travel would be easiest. Such iterators should be configured (at compile- and/or run-time) for various normalization schemes. Input needs special handling, since we shouldn't allow ultimately invalid byte/code-point combinations into Unicode strings. We need something that can enumerate over a byte stream for a particular encoding and spit out whole code-points (or queue the code-points and spit out abstract characters). -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

2 1

[serialization] and list<shared_ptr<const T> >
by Russell Hind 26 Oct '04

26 Oct '04

If I try and write a list<shared_ptr<const T> > to an archive, I get a compilation error. I'm guessing this is because the objects in the list are shared_ptr<const T> The documentation for const members says to use const_cast<T&>(t) but when you want to try and write a list, you can't do this unless you write all the objects manually. Is there a way for serialization to be able to handle the const implicitly (for containers at least)? Otherwise the only solutions I can see are - Don't use const objects - Write all elements of the list ourselves. Thanks Russell

2 2

[cvs] waiting for agurtovoy's lock in /cvsroot/boost/boost/boost/spirit/tree/impl
by Andreas Huber 26 Oct '04

26 Oct '04

I'm a bit of a CVS dummy so I can't tell whether the message in the subject is to be expected. Should I notify the sourceforge folks about a stale lock? Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.

2 2

intrusive_ptr explicit constructor
by Colin Rafferty 25 Oct '04

25 Oct '04

Hi- Shouldn't the constructor in intrusive_ptr be explicit? explicit intrusive_ptr(T * p, bool add_ref = true): p_(p) { if(p_ != 0 && add_ref) intrusive_ptr_add_ref(p_); } I don't have cvs access. -- Colin

4 7

[assign] typo
by Jonathan Turkanis 25 Oct '04

25 Oct '04

Dear Thorsten, It was good to meet you finally last week. I'm reading through the assign docs and there seem to be some misplaced parentheses in the definition of names2 in the preformatted section following the heading "Function list_of()". I think it should say const stack<string> names2 = list_of( "Mr. Foo", "Mr. Bar", "Mrs. FooBar" ).to_adapter(); Best Regards, Jonathan

2 2

[contacting Jeremy B. Maitin-Shepard]
by Thorsten Ottosen 25 Oct '04

25 Oct '04

Dear All, I have troubles getting in contact with Jeremy and I want to discuss some hash-table stuff with him. Does anyone know his email? br Thorsten

1 0

[serialize] xml archives and base 64 encoded binary data
by Russell Hind 25 Oct '04

25 Oct '04

Hi, I'm writing some binary data to an xml_oarchive (a vector of floats). I'm then giving the xml files to some python uses we have here so they can read them in. They had trouble with the base64 encoding of the binary data. One has mentioned that base64 spec says an '=' must be appended to the data to indicate the padding up to the next 4-byte multiple. When they added an '=' to the data between the tags in the resultant xml file, they could decode it successfully. If it is in the spec (am trying to find a link to check this), can the the base64 encoding in serialize be modified to do this before the 1.32.0 release, so it conforms to the standard? Thanks Russell

4 14

[patch] [filesystem] Get rid of a 'uninitialized' warning
by larsbj＠gullik.net 25 Oct '04

25 Oct '04

This patch make a warning on gcc about uninitialized variable go away. Please apply to branch and main trunk. -- Lgb

2 1

RE: [boost] Re: Library Proposal: database (boost::db)
by Brian Braatz 25 Oct '04

25 Oct '04

"> On Behalf Of Jeff Garland > Sent: Sunday, October 17, 2004 8:17 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] Re: Library Proposal: database (boost::db) > > On Sat, 16 Oct 2004 23:35:37 +0000 (UTC), Steve Hutton wrote > > On 2004-10-15, Maciej Sobczak <prog(a)msobczak.com> wrote: > > > > > > http://www.msobczak.com/prog/soci/ > > > > > > This library aims at simple usage patterns, where intuitive and almost > > > "embedded" syntax at at premium. A very different approach from those > > > you discuss, but in fact complementary and can be merged with other > > > approaches. > > > > As someone who has used odbc, jdbc, dbtools, sqlapi, otl, occi, etc., > > this looks very nice to me. Further, the relative simplicity > > suggests it would be straightforward to implement for the leading > databases. > Jeff Garland Writes: > I've added a page to the Wiki to record this discussion -- feel free to > add > your thoughts on the basic requirements there... > " Thank you Jeff for setting that up. I just added " 5) Does not require the usage of RTTI 6) Allows for the user of the library to "plug in" thier own binding \ subscription system. (to support bound controls) "

6 5

[thread] Undefined behaviour of mutex?
by Roland Schwarz 25 Oct '04

25 Oct '04

While making use of mutex objects, namely in the wait function I found out that I may not destroy a mutex while a thread is waiting for it to become signalled. On windows this results in undefined behaviour and with pthreads this raises an assertion (in debug build). I am aware that this could be solved by using an additional "aborted" variable that could be tested in the while loop of the cond.wait(lk) call, but I cannot see a straightforward way how to test abortion when waiting in a try to simply lock such a mutex. So I raise the question if it would be desirable to have the mutex "throw exceptions to all threads" that are waiting for it when it is to be destroyed? Does anyone have another idea of how to deal with this situation properly? regards, Roland

1 0

RE: [boost] Re: Library Proposal: database (boost::db)
by Brian Braatz 25 Oct '04

25 Oct '04

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of David B. Held > Sent: Friday, October 22, 2004 7:08 PM > To: boost(a)lists.boost.org > Subject: [boost] Re: Library Proposal: database (boost::db) > > Jeff Garland wrote: > > On Fri, 22 Oct 2004 15:07:46 -0600, Brian Braatz wrote > > [...] > >>6) Allows for the user of the library to "plug in" thier own binding > >>\ subscription system. (to support bound controls) " > > > > Can you clarify what you mean by 'bound controls'? > > I assume he means a visual control that automagically reflects an > underlying dataset (and updates it when the control gets updated). > > Dave [Brian Braatz] I just need (for work I am doing) an abilty to PLUG something that gets called when the data is changed. This functionality supports making a OS Specific binding mechanism for UI controls. (yes there is another way to do it- I tend to prefer the "bind it once and then forget it" metaphor)

1 0

RE: [boost] Re: Library Proposal: database (boost::db)
by Brian Braatz 25 Oct '04

25 Oct '04

> -----Original Message----- > On Behalf Of Jeff Garland > Sent: Friday, October 22, 2004 3:35 PM > Subject: RE: [boost] Re: Library Proposal: database (boost::db) > > On Fri, 22 Oct 2004 15:07:46 -0600, Brian Braatz wrote > > > Thank you Jeff for setting that up. > > > > I just added > > I moved your thoughts to the main page of discussion -- somehow you wound > up > on a closely related, but not the same name page... > > http://www.crystalclearsoftware.com/cgi- > bin/boost_wiki/wiki.pl?Relational_Database_Access [Brian Braatz] Thank You > > > 5) Does not require the usage of RTTI > > Why? This seems like an arbitrary restriction to me. Further, for some > dynamic > query capabilities it seems like it would be a good way to implement the > needed fuctionality. Of course for simple static SQL it wouldn't be > needed. > [Brian Braatz] 2 points- * I blelieve RTTI is a step of last resort (I would be an agreement with Bjarne in the D&E with this principle) * It is possible to make a Boost.Table without having to use RTTI- in fact you can do a better design with out it. I.e. Allowing for the USER of boost.table to plug in their own types (this is important) > > 6) Allows for the user of the library to "plug in" thier own binding > > \ subscription system. (to support bound controls) " > > Can you clarify what you mean by 'bound controls'? > > Jeff [Brian Braatz] Control binding is one example. And PLEASE understand I am only talking about a boost.table in the CONTEXT of a database framework. (please read the doc referenced earlier). What I am basically saying is that a table needs to support a mixin or something similar to support this usage pattern. To specifically answer your question, this would simply allow the user of the table to "plug in" their own notification system for when data changed. If this functionality were supported, then the user of the class would be able to hook into that allowing for a "update" to an OS specific GUI control. This mechanism however, from a boost perspective, only would need to be allowable in the MODEL of the code created.

1 0

[serialize] xml archives and versioning
by Russell Hind 25 Oct '04

25 Oct '04

The header of our xml archive looks like this: <?xml version="1.0" encoding="UTF-8" standalone="yes" ?> <!DOCTYPE boost_serialization> <boost_serialization signature="serialization::archive" version="3"> <CoatingScanConfig class_id="0" tracking_level="0"> The object written as CoatingScanConfig didn't have a class version specified (and therefore there isn't one in the header). When writting this class, the version parameter is passed in to the serialize() method is 0 for the class, but when reading it, the version number is subsequently passed in as 3 (which looks like the archive version). Should it not be 0 also? Is 0 a valid version number for a class? If I specify the class version as 1, then reading and writing both get '1' as the version, but if I don't specify a version, or I specify 0, then writing gets 0, but reading gets '3'. If 0 isn't valid, then could there be a static_assert catching this? And a quick usage question: If a class isn't versioned, is an inherent 'version 0' written to the archive so that a version number of 1 can be applied to the object later when it is modified, or do objects need to be given a version number from the start? Thanks Russell

2 9

[Test] Linking problems
by David B. Held 25 Oct '04

25 Oct '04

unit_test_log.o: In function `boost::unit_test::unit_test_log::unit_test_log()': unit_test_log.o(.text+0x17e): undefined reference to `boost::unit_test::ut_detai l::msvc65_like_log_formatter::msvc65_like_log_formatter(boost::unit_test::unit_t est_log const&)' unit_test_log.o: In function `boost::unit_test::unit_test_log::unit_test_log()': unit_test_log.o(.text+0x270): undefined reference to `boost::unit_test::ut_detai l::msvc65_like_log_formatter::msvc65_like_log_formatter(boost::unit_test::unit_t est_log const&)' unit_test_log.o: In function `boost::unit_test::unit_test_log::set_log_format(bo ost::unit_test::basic_cstring<char const>)': unit_test_log.o(.text+0x1000): undefined reference to `boost::unit_test::ut_deta il::msvc65_like_log_formatter::msvc65_like_log_formatter(boost::unit_test::unit_ test_log const&)' unit_test_log.o(.text+0x1056): undefined reference to `boost::unit_test::ut_deta il::xml_log_formatter::xml_log_formatter(boost::unit_test::unit_test_log const&) ' This is from the latest CVS update. Any idea how to fix it? Dave

3 3

RE: [boost] about the "latest news" section [was ATTN: Branch forrelease is scheduled for tonight]
by Brian Braatz 25 Oct '04

25 Oct '04

I would like to also re-submit my request for a spot on the boost main page which has the target for when the next version will be "out". (I am anxiously waiting 1.32) > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Joaquín Mª López Muñoz > Sent: Tuesday, October 19, 2004 8:26 AM > To: boost(a)lists.boost.org > Subject: [boost] about the "latest news" section [was ATTN: Branch > forrelease is scheduled for tonight] > > Aleksey Gurtovoy ha escrito: > > > I'll post another notice right before the branching, and yet > > another one when it's complete. > > > > Regarding the "latest news" section on the main page: > > 1. Shouldn't we adopt the subsection layout as in Boost 1.31, > with "New Libraries", "Updated Libraries", etc.? > 2. Numeric Conversion does not appear listed, yet it is a newly > added library (it shows, though, in the libs page.) > 3. Same for Minmax. > 4. A bio for Herve Bronnimann is uploaded in boost/people, but > it is not linked from boost/people/people.htm. > > I volunteer to take care of this stuff, if no one objects. > > 5. Missing pictures for Fernando Caccional and Hervé. > > Joaquín M López Muñoz > Telefónica, Investigación y Desarrollo >

2 1

[boost][MPL] Numeric metafunctions protocol/infrastructure
by Cromwell Enage 24 Oct '04

24 Oct '04

Once Tropical Storm Jeanne passes away, I should be through with hurricanes for a while. The latest-and-greatest MPL looks great! The new ability to plug in custom numeric metatypes so that they work with existing numeric ops makes it a definite keeper. The part of my sub-library that I've updated to work with the new MPL is at <http://groups.yahoo.com/group/boost/files/mpl_math.zip>, and has been tested with MinGW 3.2 and MSVC 7.1 (2003 Toolkit). Renaming issues aren't too bad; I just have to remember (for one thing) that reverse_copy is defined at copy.hpp and not reverse_copy.hpp as I originally thought. I also noticed that BOOST_MPL_AUX_TYPEOF is no longer there, but I've managed to eliminate the need for it. A major issue I have is how to properly use numeric_cast in order to make something like the following statement work correctly: typedef plus<int_<1>,fraction_c<long,4,3> >::type fraction_7_over_3; Right now I've made N^2 specializations of plus_impl, where N here means the total number of built-in and custom numeric metatypes. For my sub-library, N==4, which means I've made 16 specializations of plus_impl alone! Factor in the comparison ops as well the arithmetic ops, and my code is starting to look bloated. I've supplied a couple of convenience macros to reduce the copy-and-pasting, but I still think I'm missing something crucial here, and I think that something is how to use (or specialize) numeric_cast. Pointers welcome! Cromwell Enage __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail

2 6

[MPL] eval_if<> woes
by David B. Held 23 Oct '04

23 Oct '04

I'm getting weird errors from gcc-3.4.2 saying that eval_if<> does not have a nested 'type'. I just did a CVS update. Any clues, or do I need to provide more context? Dave

3 4

[bind] and overloading function
by Alexey Nikitin 23 Oct '04

23 Oct '04

Is it possible (exist way) to give instructions to functions boost::bind or boost::lambda::bind which from overloading functions I need to pass?

3 3

bit of singed integer and proposoal
by I.J.Wang 23 Oct '04

23 Oct '04

Hi: I have recently written a C++ library, it is hoped as the most bottom level of C++ functions. Many issues might be interested there. http://freshmeat.net/projects/libwx http://sourceforge.net/projects/libwx There are so many incompatible issues with the standard practice. I would like to know about your ideas. 1. The most fundamental thing is about the returning mechanism. It involves the return type and exception type. Please download file libwy-0.15.tgz at least to see README.TXT to understand. 2. About the definition of bit with number (it is very attractive in theory). Is it practical to define the bit of number with signed types? because my implementation would require the machine always use MSB as the sign bit for integer types. 3. This is about the class member naming convention: (ripped from README.TXT) It is so far stable, I would like to propose for boost I know there are incompatibles, but think it as 'lowest level' might solve these problems. -- Let T denote a given class of this library . The following member names and associated functionalities are defined. T() default constructor. The object thus constructed is referred to as in default state and so the default object. If object can mean 'no instance', or be unbound state etc., the default object is better thus designed. Exception postcondition: object does not exist reset(...) Reconstruct the object to the state as constructed. If reset(...) defined, there exists the argument corresponding constructor (reset() usually exists) Note: reset() should always leave an default object, whatever an error is reported, either by return or by throwing exception ~T Destruct and discard object Postcondition: object does not exist bool is_default() const return true iff object is equivalent to the default constructed object (i.e a.is_default() <==> a==T()) bool operator==(const T& r) const This function returns true iff *this and r are not distinguishable by using any non-private member on the same condition unless otherwise specified. All the returned objects or that may be modified by the other members of T should have their operator==(const T&r) defined to prove the defined equivalence. Note: Address and SLI are not objects' own property operator=(const T&) Assign/reconstruct object to the state as the copy constructor constructed. The assigned object should be deterministic by the argument (i.e. f=x and g=x imply f==g). A function of such functionality should however be defined. For using expressions might otherwise be analysed to ambiguity and the future use is very likely of exponential complexity Fault return-type exception class derived from WyRet. _.. prefix for system-specific members or candidate, or restricted

1 0

[variant] regressions in gcc-2.95.3-linux and gcc-2.95.3-stlport-4.5.3-linux
by JOAQUIN LOPEZ MU?Z 23 Oct '04

23 Oct '04

Hi all, Just wanted to record the following, in case it can be helpful for someone to solve the current regressions of variant for the mentioned toolsets: Latest regression runs before branching also failed for GCC 2.95.3, but *only* in the second toolset. That is, gcc-2.95.3-linux was working fine. Given that I'm pretty sure none of the relevant code (MPL or variant code itself) has changed since, I'd say this could have to do with some local change on Martin Wille's environment during the branching. Maybe the toolset rules? HTH Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

RE: [boost] Re: SOCI db lib [Was: RTL status -"help wanted"]
by Brian Braatz 22 Oct '04

22 Oct '04

> -----Original Message----- > Subject: Re: [boost] Re: SOCI db lib [Was: RTL status -"help wanted"] > > On Wed, 20 Oct 2004 00:15:52 -0500, David B. Held wrote > > Steve Hutton wrote: > > > [...] > > > So the relevance of ODBC is open to debate - the key IMHO is uniform > > > support for all the major databases. ODBC may be a quick means to > > > that end. Native drivers can always be added later, or vise-versa. > > Agree. > > > In my experience, ODBC can be unbelievably slow, also. It is definitely > > not a cure-all. It should probably be supported, but creating an > > interface that will elegantly support native drivers should be a > > priority. > Jeff Garland: > Sure having good support for native drivers is fine, but I think it is > much, > much, harder to achieve. So my push for ODBC binding is primarily to meet > the > 'all major databases' supported quickly. > > Jeff [Brian Braatz] >From a practical point of view, I believe Jeff to be 100% right here. I have been searching for a good solution for this, and the odbc \ unixodbc path gets a framework up and running quickly. I would add that it would be nice to have that framework support "unplugging" the odbc aspect and placing in native or other drivers later. I view this perspective as the scaffolding that supports the statue, while the statue is being carved :)

1 0

[serialization] and arrays with bcc32
by Russell Hind 22 Oct '04

22 Oct '04

I'm trying to serialise arrays (boost::array, actually). There aren't any specific headers for it as there are for STL types. Could one be added at some point? But I've run in to a more basic compilation problem under bcc32: This won't compile #include <boost/archive/text_oarchive.hpp> double d[3]; d[0] = 0.0; d[1] = 1.0; d[2] = 2.0; std::ofstream ofs("c:\\test.txt"); archive::text_oarchive toa(ofs); toa & d; The error I get is [C++ Error] interface_oarchive.hpp(105): E2031 Cannot cast from 'double *' to 'double ( &) const[3]' Is this a problem with Borland or is my syntax for serialising arrays? Thanks Russell

3 3