- Boost - lists.preview.boost.org

The art of naming namespaces [was: Re: algorithms namespace]
by Bjorn.Karlsson＠readsoft.com 25 Feb '04

25 Feb '04

> From: Peter Dimov [mailto:pdimov@mmltd.net] > > > You can always shorten it in your code with an alias. > > This is precisely what makes it dangerous. Design mistakes that have a > trivial workaround are the worst, because you will never get > the feedback > that will set you on the right path. Everyone just patches around it > locally. I agree. If a name "works", programmers will use it. If it's too long, it'll be aliased or removed with using declarations/directives. If it's too cryptic, it'll be aliased or removed with using declarations/directives. I think that two equally valid points have been made in this thread: 0) If the name is too long, people won't use it as-is. This diminishes the information that the name carries. 1) If the name is too short/cryptic, people won't even know what it's supposed to mean. If one agrees to the above, it seems reasonable to search for a short name with lots of expressive power (oh yeah, why didn't I think of _that_...). I'd say that for boost::filesystem, Dave's suggestion "files" would be a great compromise. I'd say that for algorithms, a special name isn't actually needed; it doesn't add any information, because anyone who calls sort, trim, hash, or whatever, understands that somewhere an algorithm is involved. boost::, std::, you_name_it::, will get the job done. [Note: Some libraries (Spirit and MPL come to mind) are sexy enough to handle a non-related word/acronym as their name, without sacrificing informational value. Now that's good branding!] > No we do not. The abbrv anlgy is flwd. It's more like English::this > English::kind English::of English::writing versus en::this > en::alternative > en::style. What's "en"? ;-) > > Also a global search is easier if the letters to be searched for are > > more or less a unique set. > > Of course it isn't. Your global search for 'filesystem' will > only find using > directives and namespace alias directives. A global search > for 'fs' will > stand a better chance to point you to the lines that actually > use something > from 'fs'. Good point. Bjorn "Put the bicycle shed next to my office" Karlsson

2 1

Re: Proposed modifications to make compose_f_*_t use *ary_traitsand call_traits
by Jonathan Turkanis 25 Feb '04

25 Feb '04

". Sneechy" <sneechy(a)hotmail.com> wrote in message news:F295smOU9Xlk0H1jLUL00026d99@hotmail.com... > Traits classes can make templates more generic and otherwise flexible > (performance-wise for example). I believe that the compose_f_*_t template > class family in boost/compose could benefit from using *ary_traits (from > boost/functional), and boost/call_traits. Are you aware that compose has been deprecated? Jonathan

1 0

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

25 Feb '04

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

2 1

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

25 Feb '04

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

3 2

1.31.0 regressions
by David Abrahams 24 Feb '04

24 Feb '04

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

25 105

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

24 Feb '04

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

2 1

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

24 Feb '04

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

5 9

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

24 Feb '04

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

4 3

random_device
by Richard Peters 24 Feb '04

24 Feb '04

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

1 0

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

24 Feb '04

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

4 3

Re: [boost] Re: Customization via Overloading in Namespace
by Peter Dimov 24 Feb '04

24 Feb '04

Peter Dimov wrote: > David Abrahams wrote: >> >> Simple: specializations that follow the point of instantiation aren't >> considered. This program exits with an error: >> >> template <class T> >> int f(T) { return 1; } >> >> int main() { return ::f(0); } >> >> template <> int f(int) { return 0; } > > It's ill-formed, actually. On reflection, I think I see what you are trying to illustrate, and I also think that you are wrong. #include <iostream> // f.hpp template<class T> void f(T) { std::cout << "General\n"; } // g.hpp template<class T> void g(T t) { ::f(t); } // X.hpp struct X {}; /*template<>*/ void f(X) { std::cout << "X-specific\n"; } // main.cpp int main() { f( X() ); g( X() ); } Uncomment the /*template<>*/ to see what I mean. No order dependency.

2 1

Re: [utility] question on prior(x,n)
by Bjorn.Karlsson＠readsoft.com 24 Feb '04

24 Feb '04

> From: Daniel Frey [mailto:daniel.frey@aixigo.de] > Should we propose std::regress (the counter-part for > std::advance) for > standardization (via a DR)? The current definition of > std::advance seems > to limit the number of elements that can be skipped backwards > to signed > types, but the container can be larger (OK, in theory, never tried it > myself :). This would also nicely solve the implementation > issue for us. I don't think it's really a defect; there's a slight inconsistency with regards to the max/min values on most platforms, but nothing inherently wrong AFAICS. Note that the reverse_iterator trick can be used by client code too, so the "signed type limit" is easily defeated. [snip] > right? Although I wonder what happens if T is already a reverse > iterator. Is it legal to reverse a reverse_iterator? Or do we need a > trait and implement both cases separately? Yes, reversing a reverse_iterator this way is fine (because a reverse_iterator satisfies the iterator requirements). Bjorn

4 4

allocator_facade
by Alberto Barbati 24 Feb '04

24 Feb '04

Hi Boosters, I had a very good time writing iterators with the new iterator_facade template. Very good job! It makes writing iterators so much simpler! What about having a similar template for allocators? Given that a large class of useful allocators are de facto built over a couple of typeless malloc-like/free-like functions, I imagine something that could be used like this: struct malloc_impl { static void* allocate(size_t n) { return malloc(n); } static void deallocate(void* p) { free(p); } }; std::vector<int, boost::allocator_facade<int, malloc_impl> > v; where boost::allocator_facade<T, malloc_impl> satisfies all requirements that std::allocator<T> does. An implementation for a conforming compiler and library is straightforward and allocator_facade could also include workarounds for specific platforms where possible (for example it can easily and automatically provide the __stl_alloc_rebind hack in STLport). Is there any interest for such a thing? Alberto

3 2

RE: [boost] Re: [Threads] Simple active object wrapper, take 2
by Hurd, Matthew 24 Feb '04

24 Feb '04

> On Behalf Of Matthew Vogt > Subject: [boost] Re: [Threads] Simple active object wrapper, take 2 > > >Hurd, Matthew <hurdm <at> sig.com> writes: > > > Had a little thought that might be relevant. Please spank me if this is > > OT given the rather specific implementation I'm dropping in on... > > > > Not at all. If this proves useful, I would certainly want to support it. > > > As mentioned previously, future values could give you a lazy way of > > evaluating the result, even when you aren't multithreaded. > > > > In the truly "active" object, that is, it has at least one thread, you > > could call the methods with a future instead of a normal value so that > > when the result arrives it percolates through the implied queue. > > > > Now for a new thought. What about using an expression template > > mechanism so that when you combine futures they are glommed at compile > > time to remain lazy? > > > > boost::future<double> sum = some_thing_maybe_active.total(); > > boost::future<double> count = some_thing_maybe_active.count(); > > boost::future<double> average = sum / count; > > > > sum / count forms a lazy expression > > > > if a method groks a future and then this becomes interesting... > > > > boost::future<double> result = > > some_thing_maybe_active.do_stuff(average); > > > > You can end up with the active object percolating all the way through to > > "result" without any blocking until the result of "result" is used. > > > > Yes, certainly. I'm not au fait with expression templates, but you could > alternatively implement arithmetic operations in future<T> which > maintained > shared pointers to operands, and stored a function pointer to std::plus, > etc. Expression templates are just a way of doing the kind of thing you have just described at compile time. Here is a famous intro http://www.adtmag.com/joop/crarticle.asp?ID=627 that I like anyway. > > If you get rid of the thread(s) in the active object idea, you end up > > with a mechanism for lazy evaluation. > > > > This I don't really follow. If you take away the thread from the active > object > then the calling thread must perform the evaluation itself, eventually. > What > you have left is equivalent to a sequence of boost::binds to a standard > function, haven't you? No, it doesn't have to perform the operation, the future could simply contain a boost::optional<value> with a boost::function callback, for one example implementation, so the calc might not be done until it is really needed... I was thinking about this situation in terms of what it would take to move this successfully to a single threaded (or passive object?) case and the problem of messy dependencies that automagically resolve themselves in the threaded active object sense might not have a solution, or might have a less efficient solution, if laziness was not the default behaviour. That is you could end up waiting on things that haven't been kicked off and thus you deadlock without laziness. > > Perhaps there is a more general mechanism / pattern and bike shop name > > lurking in this pattern... > > > > Regards, > > > > Matt Hurd > > Are you suggesting that the 'future' template is a convenient syntactic > sugar > for lazy evaluation, as a separate concern to the threading involved? If > so, > I can't disagree... > > Matt Yup, laziness and possibly a neat way of keeping things architectural neutral with appropriate policies. Regards, Matt Hurd _______________________ Susquehanna Pacific P/L hurdm(a)sig.com +61.2.8226.5029 _______________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

1 0

RE: [boost] Re: [Threads] Simple active object wrapper, take 2
by Hurd, Matthew 24 Feb '04

24 Feb '04

> On Behalf Of Matthew Vogt > Subject: [boost] Re: [Threads] Simple active object wrapper, take 2 > > > scott <scottw <at> qbik.com> writes: > Had a little thought that might be relevant. Please spank me if this is OT given the rather specific implementation I'm dropping in on... As mentioned previously, future values could give you a lazy way of evaluating the result, even when you aren't multithreaded. In the truly "active" object, that is, it has at least one thread, you could call the methods with a future instead of a normal value so that when the result arrives it percolates through the implied queue. Now for a new thought. What about using an expression template mechanism so that when you combine futures they are glommed at compile time to remain lazy? boost::future<double> sum = some_thing_maybe_active.total(); boost::future<double> count = some_thing_maybe_active.count(); boost::future<double> average = sum / count; sum / count forms a lazy expression if a method groks a future and then this becomes interesting... boost::future<double> result = some_thing_maybe_active.do_stuff(average); You can end up with the active object percolating all the way through to "result" without any blocking until the result of "result" is used. If you get rid of the thread(s) in the active object idea, you end up with a mechanism for lazy evaluation. Perhaps there is a more general mechanism / pattern and bike shop name lurking in this pattern... Regards, Matt Hurd _______________________ Susquehanna Pacific P/L hurdm(a)sig.com +61.2.8226.5029 _______________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

2 1

RE: [boost] Re: [utility] question on prior(x,n)
by Bjorn.Karlsson＠readsoft.com 24 Feb '04

24 Feb '04

> From: David Abrahams [mailto:dave@boost-consulting.com] > Hey! These implementations using "advance" don't work for > non-iterators (e.g. int) the way regular next() and prior() do. I > consider this a bug! Are there really use cases where implementations should work seamlessly for both non-iterators and iterators? Or are there (common) non-iterator types that share the iterators' "operator++() but not operator+()" issue? I understand the problem that next/prior solves for iterators, but when dealing with numeric types, I'm thinking there's always binary +/- operators available. Bjorn

2 1

[format]: c_str() function
by Pavel Vozenilek 23 Feb '04

23 Feb '04

Would it be possible to add function c_str() into format interface? It would return const char/wchar_t* to internal string buffer. Use cases for such function: 1. void foo(const char*) { ...} format f("...") f % ... foo(f.c_str()); This is shorter and faster than foo(f.str().c_str()); No temporary gets created. 2. // class used to accept any string type struct parm_string { parm_string(const char* s) : str_(s) {} parm_string(const std::string& s) : str_(s.c_str()) {} const char* str_; }; void foo(parm_string) { ... } format f("...") f % ... // ERROR - pointer to deleted temporary gets used inside foo() foo(f.str()); foo(f.c_str()); // would be OK /Pavel

2 2

[indexed_set] Release 9.1
by Joaquín Mª López Muñoz 23 Feb '04

23 Feb '04

Release 9.1 available at: http://groups.yahoo.com/group/boost/files/indexed_set.zip The sandbox version is also updated, but the ViewCVS tool has some delay and changes are not visible yet. Minor changes in the code and a big overhaul of the docs. I've rewritten a major portion of the documentation, and now the reference reflects the existence of sequenced indices as well as prior, regular indices. I'd very much appreciate if proofreaders can indicate on the understandability of the reference (things are a little more abstract now.) The tutorial, which is the only part left to rewrite to accommodate new sequenced index types, remains untouched as of now. Again, if some kind soul with skills at writing English volunteers to help rewrite the tutorial, my eternal gratitude would go to her/him (I'm suspicious I don't have perspective enough to write some good introductoy material on the library.) Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Moving Boost.Thread barrier from thread_dev to HEAD
by Michael Glassford 23 Feb '04

23 Feb '04

The thread_dev branch in CVS contains a barrier class that I would like to move to the main branch, as has recently been requested by more than one Booster. Is anyone aware of any problems that should be addressed before this happens? For reference, see thread.hpp, http://cvs.sourceforge.net/viewcvs.py/*checkout*/boost/boost/boost/thread/A… and thread.cpp, http://cvs.sourceforge.net/viewcvs.py/*checkout*/boost/boost/libs/thread/sr… One potential problem that I am aware of is that it is possible for the m_generation counter (see barrier.cpp) to overflow on systems that detect overflow of integer addition instead of wrapping (I assume there are such systems though I've never used one). Is it worthwhile checking for this and forcing wrapping in code? Mike

5 14

Re:[boost] (For me a) showstopper [was: boost thread static library]
by Robert Ramey 23 Feb '04

23 Feb '04

Stefan Slapeta wrote: >There's one more big "surprise": the need for the shared runtime >libraries! I'm very frustrated at the moment because I don't know which >strategy to choose for boost.thread at all: >Sorry for this critisism. I know about all your efforts and appreciate >them very much. This time it seems that the need for new functionality >broke too much of existing code for my taste! I'm not sure I'm following all this. Given that you are understand what the consequences of building and using a static library in this context, and you decide that they are not a problem for you, what prevents you from building your own statically linked library and using it in your own projects? Wouldn't that solve your whole issue Robert Ramey

4 8

Re: [boost] Re: algorithms namespace
by Dave Gomboc 23 Feb '04

23 Feb '04

> Well. It's actually the opposite. Because English is > (presumably) your first language, you prefer the > non-abbreviated "filesystem" over "fs". From the perspective > of someone who doesn't "think in English", the two have > pretty much the same inherent value, i.e. they are arbitrary > identifiers. >From the perspective of this English-speaking software developer, I recognize filesystem, and I also know what fs means. Furthermore, the first time I hear "fs", I imagine that I was able to guess from the context it was used in that fs means filesystem. >From the perspective of a developer who knows English but whose native tongue is not English, filesystem is understandable, because the component words, file and system, either are known or are looked up in a translation dictionary. "fs", on the other hand, is incomprehensible without supporting documentation. > A mental mapping translates these identifiers > into the entities they represent. Since the extra letters in > the longer identifier do not add any semantic value to > non-English speakers, they are merely clutter and do not > contribute to readability. You're missing the point -- the extra letters *do* add semantic value to those who speak English, but not as a first language. > Your observation that "stdio" is a _word_ in non-English > programmer cultures, and not an abbreviation of "standard > input/output", is very much in line with the above. Stdio was *not* a word to them, it was just a jumble of random characters. The whole concept of "standard" had been lost! Dave

2 1

Re: [boost] Re: mpl::for_each and polymorphic function object
by Aleksey Gurtovoy 23 Feb '04

23 Feb '04

Gennadiy Rozental wrote: > > mpl::for_each<mpl::transform<s, wrap<_1> >::type>(foo()); > > I saw this in mpl::for_each test. Actually, if you do it as in the test, it's even simpler: mpl::for_each< types,wrap<_1> >(foo()); > It may probably solve my problem. But is tyhe more generic solution? Sorry, cannot parse this one. > Or why doesn't for each pach mpl::identity in a first place? Sometimes the value semantics is exactly what you want: typedef mpl::range_c<int,0,10> numbers; std::vector<int> v; mpl::for_each<numbers,mpl::_>( boost::bind(push_back, &v, _1) ); > Or could we eliminate parameter at all and make for_each to > work with explicit type specialization, like this: > > aux::unwrap(f, 0)::operator()<arg>(); Like the previous suggestion, it would rule out ordinary function objects; besides, it's not portable. -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

Re: [utility] question on prior(x,n)
by Bjorn.Karlsson＠readsoft.com 23 Feb '04

23 Feb '04

> From: Daniel Frey [mailto:daniel.frey@aixigo.de] > > // A strange way to retrieve my_container.begin(): > boost::prior( my_container.end(), my_container.size() ); > > Is that legal? The second template parameter of boost::prior > is deduced > to an unsigned(!) type, which IMHO means that -n is > undefined, right? Do > we need to fix this? It's both legal and well defined, but perhaps not very intuitive... For unary minus, the negative of an unsigned is computed as 2^n-v (where n is the number of bits in the type yielded by performing integral promotion on the operand and v is the value of the operand [5.3.1/7]). The resulting type is the promoted operand; this means that unsigned char and unsigned short will typically work as expected with boost::prior (those types can be promoted to int on most [all?] platforms), whereas unsigned int and unsigned long will always return a positive value (because here, the resulting type of integral promotion is the type of the operand, and the result of the unary - operator is therefore 2^n-v). So, the effect of this is that the example above is valid, but the resulting iterator is past-the-end, typically way too far to ever be seen again...and the name 'prior' thus becomes misleading for certain types. > or shall we document that it's illegal/undefined to call > boost::prior() > with an unsigned second parameter? I think Dave's suggestion of using reverse_iterator would be cool; that also adds a good reason for using boost::prior rather than std::advance for decrementing. Something like this should work: template <class T, class Distance> inline T prior(T x, Distance n) { return next(std::reverse_iterator<T>(x),n).base(); } (Daniel, good work spotting this issue!) Bjorn Karlsson

2 1

Re: [boost] Re: [mpl] BOOST_MPL_METAFUNCTION_MAX_ARITY
by Aleksey Gurtovoy 23 Feb '04

23 Feb '04

Jonathan Turkanis wrote: > > Defining BOOST_MPL_METAFUNCTION_MAX_ARITY together with > > BOOST_MPL_NO_PREPROCESSED_HEADERS the should do it. If not, it's a > > bug. I'll check if that's the case with the current CVS state. > > Thanks. FYI I got the errors with VC7.1. These were caused by a hard-coded 'bind' specialization in the "if.hpp" header. The code fails only if you disable the preprocessed headers _and_ reconfigure the arity, while the usual testing procedure was to test only with BOOST_MPL_NO_PREPROCESSED_HEADERS, and that's why the regression hasn't been caught earlier. Fixed in the main trunk. Thanks for reporting it, -- Aleksey Gurtovoy MetaCommunications Engineering

2 1

mpl::for_each and polymorphic function object
by Gennadiy Rozental 23 Feb '04

23 Feb '04

Hi, I found following issue: if I have const type in a list of types test case template facility initialized with, it really gets instantiated with non const type. After some investigation I found the reason. The reason is the mpl::for_each, used in the facility implementation, rely on type deduction based on type of single argument it passes. It works for simple function and function object. But it does not for function object with template operator(). It's all originated from the fact that following code compiles: struct { template<typename T> void operator()( T ) { T t = 0; ++t; } } foo; int main() { char const x = 0; foo( x ); return 0; } because foo.operator() is instantiated with type char - not char const. Is the any workarounds? Could we fix that? Gennadiy. P.S. Actually I was concerned with this unused parameter from the very beginning. It prohibit using for_each with types without default constructor and also could be source for performance problems. Could we eliminate this unused parameter at all?

2 2

Re: [boost] [mpl] BOOST_MPL_METAFUNCTION_MAX_ARITY
by Aleksey Gurtovoy 22 Feb '04

22 Feb '04

Jonathan Turkanis wrote: > I was having a bit of trouble this afternoon getting some MPL code to > compile, when I realized I was trying to use a placeholder symbol > embedded in an expression using a metafunction of arity 7. I know that > the maximum metafunction arity is set at 5, so I tried setting > BOOST_MPL_METAFUNCTION_MAX_ARITY to 7. This didn't work either, > because of the preprocessed headers. So I tried defining > BOOST_MPL_NO_PREPROCESSED_HEADERS. This reduced the number of error > messages from infinity to 27. > > So I have these questions: > > 1. Am I right that as presently configured mpl::lambda cannot look for > placeholders inside (fully-curried) metafunctions of arity > 5? Yes. You either need to regenerate preprocessed headers for the new configuration, or to go with BOOST_MPL_NO_PREPROCESSED_HEADERS. > 2. Are preprocessed headers used just to cut compilation times, or for > some more fundamental reason? The former, and also to workaround a bug present in old EDG front-ends. > If it is just to save time, how much > time does it save? IIRC, it makes a noticeable difference for EDG-based compilers (10-20%, I think), and not so noticeable for others (< 5%). It's been a long time since I did the measurements, so chances are things changed since then. It's always safe to do the comparison yourself, just to be sure :). > 3. Is there any way to circumvent the preprocessed headers entirely to > compile mpl with a different max arity? Defining BOOST_MPL_METAFUNCTION_MAX_ARITY together with BOOST_MPL_NO_PREPROCESSED_HEADERS the should do it. If not, it's a bug. I'll check if that's the case with the current CVS state. -- Aleksey Gurtovoy MetaCommunications Engineering

2 1

request: tokenizer documentation
by Bronek Kozicki 22 Feb '04

22 Feb '04

It would be nice if tokenizer documentation clearly explains that tokenizer constructor is not making a copy of its input data, thus passing temporary value as first argument to its constructor invites undefined behaviour. Following code can be given as an example of such undefined behaviour: #include <string> #include <iostream> #include <boost/tokenizer.hpp> using namespace std; using namespace boost; int main() { typedef tokenizer<char_separator<char>, string::const_iterator, string> Tokenizer; const char_separator<char> semicolon(";"); Tokenizer tokens(std::string("a;b;c"), semicolon); string t("x;y;z"); for (Tokenizer::const_iterator i = tokens.begin(); i != tokens.end(); ++i) std::cout << *i << std::endl; } (program may produce different output depending on compiler and its options, or simply crash) B.

1 0

Re: [boost] Re: algorithms namespace
by Dave Gomboc 22 Feb '04

22 Feb '04

> >>We can (re-)consider 'boost::meta': > >> > >>Doesn't look bad at all, actually. > > > > I'm a big fan of using "meta" instead of "mpl". > > FWIW, I'm not. I type it often enough to be bothered by the > completely unnecessary extra character. And I'd prefer boost::metaprogramming, but I'll settle for meta if it's the best that I can get. ;-) Human languages are full of "extra characters": why should programming languages be different in this respect? If the typing truly bothers you, try out an editor that supports word completion. fs is arguably sufficiently common, but I still prefer filesystem. Not all that long ago someone posted something here and abbreviated it as "rng", and I thought to myself that it was very odd that they'd use something that, as far as I am concerned, abbreviates "random number generator". On the flip side, perhaps if I had referred to one of these as "rng" they would be thinking the converse. Ergo, prefer filesystem: those who want it shorter probably don't want the boost:: part either, and will define fs = ::boost::filesystem once and use four characters (fs::) from there on. Besides which, "fs" is difficult for an English-as-a-second-language speaker to look up in the dictionary. I have the impression that some simply don't care about that because English is _their_ first language -- an unfortunate attitude. Last year I vistied Slovenia, and when I said "standard-eye-oh-dot-aitch" to some people, they didn't understand me, and asked what I was talking about. After some discussion back and forth, it turns out that they spell that header name out character by character: "s-t-d-i-o-pika-h". (pika = dot, and all the letters are pronounced differently too, of course.) They had no idea that "std" was being used as an abbreviation for standard in this context. "So 's-t-d' means standard?" "Yes... how do you say standard in Slovene?" "Standardija." (!) This demonstrates that even small differences for us can be huge differences for others. It turns out that the "i-o" for input/output doesn't translate well into Slovene, so those person (and all their programming friends, I'm sure) are now happily calling it "standardija-i-o-pika-h", something I'm sure most readers of this message will have taken the English equivalent of for granted since the first week they programmed in C. Had "standard" been used instead of "std", this confusion would never have arisen, but more importantly the name would have been meaningful to more people. Re: boost::algorithm::<subnamespaces>, it's easy to add using directives to bring things defined in these up to boost::algorithm. The opposite operation is not easy. If it turns out do be better to have them all together, using declarations can be added to boost itself down the road. Dave P.S. I think that the average teenager probably has a different meaning for 'std' than we do too, though I'll grant that that's less relevant. ;-)

8 7

Nightly CVS docs
by David Abrahams 22 Feb '04

22 Feb '04

The "Nightly CVS" link on the home page doesn't take you to our full documentation. Instead it points at the generated docs at meta-comm for whatever subset of Boost libraries that applies to. Doesn't seem right to me. -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 1

[Filesystem] Notes for Cygwin users
by Beman Dawes 22 Feb '04

22 Feb '04

The Cygwin environment is special in that it supports both the native Windows API's and Linux/POSIX emulation API's. The default for Boost.Filesystem builds is to treat Cygwin environment as native Windows. Some Cygwin users would prefer the Linux/POSIX emulation. Boost.Filesystem has now been tested in both Cygwin environments. No changes were required in the 1.31.0 or current CVS head implementation code. Two of the test programs have been changed in CVS to make testing both Cygwin environments easier. The docs in CVS have been updated with the following "Notes for Cygwin users": The library's implementation code automatically detects the current platform, and compiles the POSIX or Windows implementation code accordingly. Automatic platform detection during object library compilation can be overridden by defining BOOST_POSIX or BOOST_WINDOWS macros. With the exception of the Cygwin environment, there is usually no reason to define one of the macros, as the software development kits supplied with most compilers only support a single platform. The Cygwin package of tools supports traditional Windows usage, but also provides an emulation layer and other tools which can be used to make Windows act as Linux (and thus POSIX), and provide the Linux look-and-feel. GCC is usually the compiler of choice in this environment, as it can be installed via the Cygwin install process. Other compilers can also use the Cygwin emulation of POSIX, at least in theory. Those wishing to use the Cygwin POSIX emulation layer should define the BOOST_POSIX macro when compiling the Boost Filesystem Library's object-library. The macro does not need to be defined (and will have no effect if defined) for Boost Filesystem Library user programs. --Beman

1 0

Status
by agurtovoy＠meta-comm.com 22 Feb '04

22 Feb '04

The message cannot be represented in 7-bit ASCII encoding and has been sent as a binary attachment.

1 0

value_initialized and msvc6.5
by Gennadiy Rozental 22 Feb '04

22 Feb '04

I couldn't compile following code with msvc 6.5. #include <boost/utility/value_init.hpp> boost::value_initialized<char const> c; Others compilers seems to be ok. Any pointers? Gennadiy. P.S. Error message: ...boost/utility/value_init.hpp(29) : error C2758: 'x' : must be initialized in constructor base/member initializer list ...\boost/utility/value_init.hpp(31) : see declaration of 'x' ...\boost/utility/value_init.hpp(29) : while compiling class-template member function '__thiscall boost::vinit_detail::const_T_base<char const >::boost::vinit_detail::const_T_base<char const >(void)' P.P.S. But it does present in member initializer list??!! const_T_base() : x() {}

1 0

[mpl] BOOST_MPL_METAFUNCTION_MAX_ARITY
by Jonathan Turkanis 21 Feb '04

21 Feb '04

I was having a bit of trouble this afternoon getting some MPL code to compile, when I realized I was trying to use a placeholder symbol embedded in an expression using a metafunction of arity 7. I know that the maximum metafunction arity is set at 5, so I tried setting BOOST_MPL_METAFUNCTION_MAX_ARITY to 7. This didn't work either, because of the preprocessed headers. So I tried defining BOOST_MPL_NO_PREPROCESSED_HEADERS. This reduced the number of error messages from infinity to 27. So I have these questions: 1. Am I right that as presently configured mpl::lambda cannot look for placeholders inside (fully-curried) metafunctions of arity > 5? 2. Are preprocessed headers used just to cut compilation times, or for some more fundamental reason? If it is just to save time, how much time does it save? 3. Is there any way to circumvent the preprocessed headers entirely to compile mpl with a different max arity? Jonathan

1 0

Re: algorithms namespace
by Robert Ramey 21 Feb '04

21 Feb '04

I've followed this discussion for a while hoping it would just go away. Well I can't stand it any more - here's my 2 cents. Keeping names in my head is a big problem. So I don't like making any more names than necessary. I'm not crazy about abbreviations either - it's one more thing to remember. Of course if its one or two it wouldn't be a big deal but once it starts it tends to spread. I do like analogies: STL -> RTL -> VTL -> MPL Help me remember things. I'm aware this is probably not the motivation of the authors but none the less it helps me remember. In a short context ( within a code file ) if I get tired of typing, I will use a LOCAL alias e.g. Using namespace fs = boost::filesystem - or whatever the correct syntax is. But a global one - used everywhere is one more thing I have to remember everywhere. It's a bad idea. It's the same problem as global variables - as boost gets bigger I can't keep it all in my head at once. I don't like to do a lot of work for almost no good purpose - changing mpl to meta through a lot of already written code would be a huge waste of time at best and a big pain at worst - does anyone know for a fact that meta wouldn't clash with something? Is it even worth the time to check? The following two are important to me also - though I don't know whether anyone has proposed that they be abandoned. I much like the current practice of having the namespace hierarchy parallel the file directory hierarchy. This should be maintained at all costs. Its just another waste of global brain capacity to try to maintain two such hierarchies in ones head. I think its very valuable that one library/maintainer correspond to a namespace. In short, I don't think any changes in this area would be anything but detrimental. Robert Ramey

1 0

Cyclic Queue Requirements and Description
by Sasha Goldshtein 21 Feb '04

21 Feb '04

Good day, Assume the following requirements from a container: - O(logn) find operation - O(1) random access operation - O(logn) insert, O(logn) delete of a block of SEVERAL elements at a random position in the container This container can be described as a cyclic queue - a queue that you push items at its back and remove items from its front, but retaining the ability to randomly access any element in the container according to its index. The cyclic nature of the queue is in that if gaps are created due to element removal, then the inserts will first attempt filling those gaps (and expanding the queue IN THE MIDDLE if necessary) prior to moving to the back of the queue, enlarging it and copying the elements. The following 'diagram' demonstrates the idea: x x x x x x x x x x x x x x x x x x x (1) (2) (3) (1) - elements are normally removed from here. (2) - a gap that was created due to removal of two elements from the middle of the container. (3) - elements are normally inserted here, unless there are gaps in the container. Now if we want to insert two elements, we can just put them instead of (2) and we're done. But what if we want three? The requirement is to expand the queue to fill the gap and make room for the elements - i.e. insert at (2) but make room, at (2), for another element. I hope the requirements are clear :) Anyhow, I've had an idea of implementing this as a linked list of blocks, each being moved to the free pool when fully deallocated and pushed at the end of the queue from the free pool if all end blocks are full, if needed. Is there any interest in this sort of container? Is there any existing / pending library in Boost or elsewhere that provides an implementation of a similar concept? Have you any ideas that can make the whole problem go away by using some combination of the standard containers? Thanks in advance to all, Sasha Goldshtein.

3 3

Future of Boost.Thread part II
by Michael Glassford 21 Feb '04

21 Feb '04

In the "Future of Boost.Thread" thread, Jeff Garland said: > I believe exception propagation can be a useful model at times, <snip> > But as I believe I said earlier I hardly believe it is the > most important capability that should be added to Boost threads. In another post he said: > There are lots of other things that boost.threads lacks > when stacked up against more comprehensive solutions > which are probably more important than cross-thread exceptions... In yet another post, Matt Hurd said: > I do need to set thread priorities however. > This is more important to me than cancellation. This leads me to ask, while the interest sparked by the "Future of Boost.Thread" thread is still hot: what are the most important things, in your opinion, that Boost.Thread lacks? Mike

8 14

unique_type
by Jody Hagins 21 Feb '04

21 Feb '04

This code is extremely simple, but it begs several questions, and I hope this forum is appropriate for discussion: 1. Is there something similar in boost already? 2. Are nested anonymous namespaces portable across most common implementations? 3. Does anyone know of a better way of doing this, especially overcoming the problem with having multiple declarations on the same line? 4. Does anyone know of a way to create a unique object id constant that does not require something like using the address of a static variable -- this would require memory for each instance of the object id? 5. Any other comments about this snippet, or related issues? Thanks!! #ifndef wjh__unique_type__hpp_ #define wjh__unique_type__hpp_ // Some of my meta-programming tasks require a completely // unique type. I am sure there is a better way, but this // is what I currently have. // // Simply use the macro WJH_UNIQUE_TYPE in any source file, // and a unique type will be defined. // // This depends on: // __LINE__ providing the line number of the source from which // the macro is called. // // The nested anonymous namespace is specific to the compilation // unit. So, each unit can have a type created with the same // line number, but the two types will still be unique. // // Note that it "breaks" if you put more than one WJH_UNIQUE_TYPE // on a single line of code. // // I tried to create an OID at compile time, but was unsuccessful. // This would certainly make the job of creating a unique type // a lot easier. // // I almost always use the macro directly: // wjh::typemap<std::string, WJH_UNIQUE_TYPE> // but there may be reasons for: // typedef WJH_UNIQUE_TYPE type_x; namespace wjh { namespace detail { namespace { template <int v> struct unique_type_helper { }; } // end anonymous namespace } // end detail namespace } // end wjh namespace // Construct a "unique" type #ifdef WJH_UNIQUE_TYPE #warning WJH_UNIQUE_TYPE is already defined! #else #define WJH_UNIQUE_TYPE wjh::detail::unique_type_helper< __LINE__ > #endif #endif // wjh__unique_type__hpp_ -- Jody Hagins Some men are born mediocre, some men achieve mediocrity, and some men have mediocrity thrust upon them. -- Joseph Heller, "Catch-22"

2 1

FC++ formal review extended through 3/1/04
by Mat Marcus 21 Feb '04

21 Feb '04

I have received several requests to add time to the formal review period for the FC++ library. This library presents a new paradigm for many C++ programmers and requires a healthy investment of time to review properly. In addition, interesting relationships exist between FC++ and existing boost components. So far, there have been relatively few reviews. For these reasons I am extending the review period through the end of Monday, 3/1/2004. Please try to find time to post your review next week if you haven't already. Even if you don't have time for a full review, simple questions that may promote discussion about the intent of the library, its relation to other components, the ease of understanding for typical boost users, etc. are very welcome. But most of all, deeper reviews by the boost community will serve as essential aids to help me decide whether this library is ready to become a part of boost. If you are interested in FC++, now is the time to come forward. Thanks in advance for you time/volunteering, Mat ### original notice reproduced below for your convenience The formal review of fcpp by Brian McNamara and Yannis Smaragdakis is now in progress, running from Friday February 13th at 12 noon, PST and and run to Monday, February 23rd, 12 noon PST. The library is currently available at <http://www.cc.gatech.edu/~yannis/fc++/boostpaper/> Here is a brief introduction to the library: FC++ is a library for doing functional programming in C++. The library provides a general framework to support various functional programming aspects, such as higher-order polymorphic functions, currying, lazy evaluation, and lambda. In addition to the framework, FC++ also provides a large library of useful functions and data types. The main utility of the library comes from its ability to implement functional programming designs, especially those which use higher-order polymorphic functions or lazy evaluation in significant ways. The library also contains a number of ancillary components that implement features like currying and lambda for function objects; these features are also useful in their own right. For information about submitting a Formal Review, see <http://www.boost.org/more/formal_review_process.htm> Please try out the library and read the documentation and say whether or not you think the library should be accepted by Boost and why. Compiler notes: This library has been tested with icc7 and with gcc-3.1.1 (and various other gcc-3.x.y versions) on Solaris and Linux. The library is also likely to compile on VC++7.1 and Comeau (prior versions of the library succeeded with these compilers, but this particular snapshot has not been tested with them). The library covers a great deal of the C++ language and thus requires a high degree of standard conformance; compilers like gcc-2.95.x and VC++6 will not be able to compile the library. Getting started: The web page http://www.cc.gatech.edu/~yannis/fc++/boostpaper/ mentions all the basics: The zip file will expand into these subdirectories: fcpp/fcpp/ # the library (.hpp) files fcpp/fcpp_clients/ # the example (.cpp) files Running the examples just involves invoking the complier with the right #include paths; for example, # in the fcpp_clients directory g++ -I/path/to/boost -I../fcpp some_example.cpp There is also a gnu-style Makefile included with the clients (examples), which will compile all of the examples in batch (you will have to edit a tiny bit at the top of the Makefile). The examples in the clients directory are a mix of both (regression-type) tests cases which cover the features of the library and example applications which demonstrate some of the library's utility. The README file in the client directory gives a short explanation of some of the more interesting clients. The documentation at http://www.cc.gatech.edu/~yannis/fc++/boostpaper/ provides a walkthrough and reference for most of the main features of the library. There are also some pointers out to other papers and documentation on the main FC++ web site: http://www.cc.gatech.edu/~yannis/fc++/ Conformance to Boost guidelines: The library meets most of the requirements described at http://www.boost.org/more/lib_guide.htm Here are a few notable exceptions: - the current library headers are too "monolithic"; you #include "prelude.hpp" and suck in all of the library - some of the lambda internals should be rewritten to use MPL rather than hand-rolled metaprogramming code - only a few of the example programs utilize the Boost testing framework (to automate regression testing) Should the library be accepted into Boost, Brian will remedy these deficiencies. (If you notice other major problems along these lines, please bring them to Brian's attention during the review.) The Formal Review manager is Mat Marcus.

2 1

RE: [boost] Re: [Threads] Simple active object wrapper, take 2
by Darryl Green 21 Feb '04

21 Feb '04

Hi Matty, > -----Original Message----- > From: Matthew Vogt [mailto:mvogt@juptech.com] > Subject: [boost] Re: [Threads] Simple active object wrapper, take 2 > > Actually, the paper does note that for performance reasons, > the thread could > be replaced with a thread pool. This requires support, > however, in that the > Method Request needs to be able to lock the resources needed > to perform the > task prior to doing so. I haven't read the paper you mentioned, but I do have POSA volume 2 by Schmidt et al in front of me. Based on the description in it, your code definitely does (very cleanly) provide a way to implement the active object pattern. > > In terms of my wrapper, the object wrapped needs to have > 'hooks' for locking > its resources, and the active<> wrapper class would need to > have a policy > class to perform the 'Scheduler' role, which knew enough to > use the resource > locking hooks. I don't see a great deal of use for the thread-pool based active object variant briefly described in the book, where the active object has a whole thread-pool to itself and the object needs its own internal locking. This seems to me to be an implementation detail of the object itself - nothing to do with the active object model. Further I have real difficulty imagining a circumstance in which I'd want all those threads sitting around dedicated to one AO (like I can talk...). However, it sounds like you are describing something different. I can (if I try hard enough) imagine that I'd like to specify the level of concurrency allowed between methods of an object and have a scheduler clever enough to order the execution of those methods efficiently based on this (and probably request priority as well) on a (shared by multiple such AOs) thread pool. A dynamic thread pool could then scale the number of threads used based on the actual observed/required concurrency. However, I suspect that the above isn't going to fly, if only because it is likely to make the scheduler a bottleneck. Anyway, nobody seems to want to give me a box with enough processors and I/O to make this much fun - and I can't think of anything (useful) to run on it :-) Is that anything like what you had in mind? Does anyone actually re-use some of the more exotic veriations of these patterns often enough that they consider a framework for implementing them is actually anything more than a (fun?) excercise? Regards Darryl. ########################################################################## This e-mail is for the use of the intended recipient(s) only. If you have received this e-mail in error, please notify the sender immediately and then delete it. If you are not the intended recipient, you must not use, disclose or distribute this e-mail without the author's prior permission. We have taken precautions to minimise the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. ##########################################################################

3 2

status of wchar_t support in filesystem::path?
by Paul Miller 20 Feb '04

20 Feb '04

I just started using boost recently and it seems excellent so far. One of the first classes I started using is filesystem::path, with the intention to use it portably on Windows, OS X, and Linux. On Windows and OS X, you can work with paths in Unicode. Presumably Linux still works with multi-byte characters. Is there progres toward a wchar_t-aware path? Is there an existing strategy for storing my Unicode Windows/Mac paths as UTF-8 with the existing path? I notice the existing posix checks would fail horribly in this case. Is a UTF-8 checker in order?

8 25

[MPL] insert_range bug with empty sequences
by Jonathan Turkanis 20 Feb '04

20 Feb '04

I have found that applying insert_range to append elements to an empty sequence has no effect. E.g., the following compiles without error on every compiler I have tried (VC7.1, GCC 3.2, Intel 7.1 and CW8.0). typedef mpl::insert_range< mpl::list0<>, mpl::end< mpl::list0<> >::type, mpl::list<int> >::type result; BOOST_STATIC_ASSERT((size<result>::type::value == 0)); I get the same result if I use vectors instead of lists. This looks like a bug to me. Jonathan

2 2

RE: [boost] Re: algorithms namespace
by Reece Dunn 20 Feb '04

20 Feb '04

Stefan Slapeta wrote: >Pavol Droba wrote: > >>It is not really reasonable to await from >> a user to always type boost::algorithm::string::trim. >> > >Maybe it could help a little bit to replace 'algorithm' by 'algo' and >'string' by 'str'. > >IMHO, also shorter namespaces like 'boost::filesystem' have the problem of >beeing too long to be used on every access. Long typenames like >boost::filesystem::directory_iterator have a very high capability to make >the code unreadable very quickly. why not use: namespace sa = boost::algorithm::string; sa::trim( ... ); or namespace fs = boost::filesystem; fs::directory_iterator di = ...; Surely this gives you what you are after (shorter namespace names) without modifying the namespace currently used by the library (which will break existing code that uses the libraries). This is what namespace aliases are for and is used for the filesystem library in the regression test implementation. Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

8 14

Re: [boost] [Filesystem] behaviour of branch_path
by Beman Dawes 20 Feb '04

20 Feb '04

At 10:48 PM 1/25/2004, Gustavo Guerra wrote: >Why does branch_path return path("") with simple paths like "file.ext"? >Would'nt it make more sense to return path(".")? At least that was I was >expecting. I had to go carefully see at documentation to discover it wasn't >like that, because in other place in the docs its writen "A non-empty path >is specified as a precondition because an empty path is almost certainly an >error". > >This way, for example, if I have some code that gets the parent directory >of a path and then uses that in other path operations, I'm forced to make >special cases checking for has_branch_path, when if it returned "." it >would work better for most cases... In thinking more about this need, it seems to me that changing path::branch_path() may not be the best approach. Class path member functions work only on the lexical representation of a path, regardless of the actual state of the external filesystem. The use cases I can think of usually need to look at the external filesystem. Also, The decomposition functions return elements of the path. It seems a bit surprising for a decomposition function to return "." when it is not an element of the path. Perhaps the use cases you are running into would be better dealt with by new operational functions which do look at filesystem state. Two possible functions come to mind (subject to better naming): path directory_path_of_file( const path & ph ); Throws: !exists(ph) || is_directory(ph) Returns: branch_path(ph).empty() ? path(".") : branch_path(ph) path directory_path( const path & ph ); Throws: !exists(ph) Returns: is_directory(ph) ? ph : directory_path_of_file(ph) Thoughts? --Beman

1 0

RE: [boost] Re: Re: full functoids
by Rozental, Gennadiy 20 Feb '04

20 Feb '04

> > (BTW it would really help for the whole > > library review, if you could provide a little introduction what is a > > "functional programming" in a first place; how it differ from other > > programming styles and what is the place of your library in > this - I mean > > what purpose does it serve, what solution does it provide). > > I think this is way out of scope for the library. Functional > programming has > been around for ages, and it shouldn't be up to Brian to > introduce and > explain all of it in his introduction. I merely need just few starting pointers and if possibly couple links. Also explanation what does this library provide exactly would be helpful. > > If I need to include boost/fcpp/plus.hpp separately from > boost/fcpp/minus.hpp, > I'm going to very, very unhappy. I agree with breaking up > large components > intro multiple headers, but when we get 20 headers with 10 > lines of code in > them each, all related, we've gone too far. > > Doug Well. It's the matter of taste. I believe we both could be happy if structure would include separate headers in boost/function directory and one boost/functional.hpp that include them all. Gennadiy.

2 1

Re: [Boost-users] [Graph] What can I do with null_vertex?
by Jeremy Siek 20 Feb '04

20 Feb '04

Hi Doug, On Feb 20, 2004, at 11:06 AM, Douglas Gregor wrote: > There are no semantics for null_vertex. I assume I can copy it, but > can I > compare it against other vertex descriptors via == and !=? Is it always > different from "real" vertex descriptors? By "null_vertex", do you mean the graph_traits<G>::null_vertex() function? I believe http://www.boost.org/libs/graph/doc/Graph.html does give the semantics. It says: Returns a special <tt>vertex_descriptor</tt> object which does not refer to any vertex of graph object which type is <tt>G</tt>. Also, in the section describing the associated types: <td><pre>boost::graph_traits<G>::vertex_descriptor</pre> A vertex descriptor corresponds to a unique vertex in an abstract graph instance. A vertex descriptor must be <a href="http://www.sgi.com/tech/stl/DefaultConstructible.html">Default Constructible</a>, <a href="http://www.sgi.com/tech/stl/Assignable.html">Assignable</a>, and <a href="http://www.sgi.com/tech/stl/EqualityComparable.html">Equality Comparable</a>. </td> </tr> Cheers, Jeremy _______________________________________________ Jeremy Siek <jsiek(a)osl.iu.edu> http://www.osl.iu.edu/~jsiek Ph.D. Student, Indiana University Bloomington C++ Booster (http://www.boost.org) Office phone: (812) 856-1820 _______________________________________________

1 0

bind, lambda, fc++
by Jim Apple 20 Feb '04

20 Feb '04

IN Section 14 of the FC++ boost doc, I find the example: oid g( std::string s, int x ); void h( fcpp::fun0<void> f ); fcpp::fun1<int,void> f = lambda(X)[ ptr_to_fun(h)[ lambda()[ ptr_to_fun(g)[ std::string("hi"), X ] ] ] ]; Does anyone know how to do this with bind or lambda? Jim

2 1

Proposal: configurable tuple arity limit
by Max Motovilov 20 Feb '04

20 Feb '04

I may have posted something to this effect in Apr. 2003 but got no response if I have; just thought I might have better luck the second time as there were no changes to the tuple library since then. Proposal: current boost/tuple library has a hardcoded limit on the tuple arity (10 elements). Some applications may require substantially larger tuples even at a cost of extended compilation time. Using boost/preprocessor library, it is relatively easy to rewrite the tuple code in such a way that arity limit will depend on a single configuration macro without incuring any other changes to the library. No additional cost will be imposed on the users who are satisifed with the current tuple library. I have a working implementation of such configurable tuples that I've been using since Apr. 2003. As I had no need to support C++ compilers that do not implement partial specification, I have only converted boost/tuple/detail/tuple_basic.hpp so far. Arity limit is controlled by the BOOST_TUPLE_MAX_ARITY macro which is defaulted to 10 inside tuple_basic.hpp if it is not defined prior to its inclusion. Since I am not sure what procedure should I follow to submit such a modification to an existing Boost library, I decided just to post the proposal here and provide a link to the modifed file: http://fridge.yymap.com/files/tuple_basic.hpp Regards, ...Max...

5 5

algorithm namespace - conclusion
by Pavol Droba 20 Feb '04

20 Feb '04

Hi, After the discussion here, it seems, that reasonable solution would be the one summarized by Doug Gregor > #include <boost/algorithm/string.hpp> > - Includes all string algorithms, in namespace boost::algorithm > #include <boost/algorithm/container.hpp> > - Includes all container algorithms, in namespace boost::algorithm > #include <boost/algorithm.hpp> > - Includes all boost/algorithm/* and imports them all into namespace > "boost" with using declarations. My addtion is, that is might be better to do imports into "boost" namespace in string.hpp resp. container.hpp headers. Idea of subnamespaces seems to bring more burden then benefits. Ambiguity problems has not been identified with the respect to the algorithm library. If anybody have serious objections, please state them now. Otherwise, this policy should be adopted by all algorithms libraries. I will adapt string algo library to follow this. Regards, Pavol

1 0

[Threads] Simple active object wrapper, take 2
by Matthew Vogt 19 Feb '04

19 Feb '04

This is a reworking of the wrapper to make any object active (that is, to execute all its methods in its own thread of execution). Changes since the previous post: 1. Extensible - the proxy implementation method can now be extended to any number of parameters. 2. Future values - where the client can, if desired, postpone the wait to acquire the result of invoking a method on an active method by explicitly capturing a handle to the result for later inspection. 3. Policy for void proxies - the implementer of the class which wraps a non- active class, can specify whether a client must wait for a void method to complete exceution or not. This would be useful if a wrapped method had side effects that a client would expect to see after invoking the method. Comments welcome. Matt (Sorry this is so long, I can only post in text mode via gmane) // test_active_object.cpp -------------------------------------------------- #include "active_object.hpp" using std::cin; using std::endl; using ActiveWrapper::active; // Active-object wrapper using ActiveWrapper::future; // Future value encapsulator using ActiveWrapper::output; // std::cout locking object using ActiveWrapper::sleep; // 3-second pause to make effects observable // An example class to test active behaviour struct Object { int non_void_with_param(int i) { { output() << "\tInside Object::non_void_with_param" << endl; } sleep(); return (i*i); } const char* non_void_without_param(void) { { output() << "\tInside Object::non_void_without_param" << endl; } sleep(); return "Hello"; } void void_with_param(double) { { output() << "\tInside Object::void_with_param" << endl; } sleep(); } void void_without_param(void) { { output() << "\tInside Object::void_without_param" << endl; } sleep(); } }; // An active version of the Object class struct ActiveObject : private active<Object> { ActiveObject() : object(), non_void_with_param(&object, &Object::non_void_with_param, this), non_void_without_param(&object, &Object::non_void_without_param, this), void_with_param(&object, &Object::void_with_param, this), void_without_param(&object, &Object::void_without_param, this) { } // Proxy declarations for all methods of the active object proxy<int (int)> non_void_with_param; proxy<const char* (void)> non_void_without_param; proxy<void (double), true> void_with_param; proxy<void (void)> void_without_param; private: Object object; }; int main(int, char**) { { ActiveObject object; { output() << "Invoking methods from main thread" << endl; } // Implicit wait until task is completed by acquiring result int i = object.non_void_with_param(5); { output() << "Result of non_void_with_param: " < c = object.non_void_without_param(); { output() << "Returned from non_void_without_param" << endl; } // Block until task completion by accessing result { output() << "Result of non_void_without_param: " << c << endl; } // Block until task completion, due to proxy policy parameter object.void_with_param(3.1415927); { output() << "Returned from void_with_param" << endl; } // Explicitly bypass completion-wait policy future<void> v = object.void_with_param(1e2); { output() << "Not waiting for void_with_param" << endl; } // Non-blocking call due to default policy object.void_without_param(); { output() << "Returned from void_without_param" << endl; } // Block until active object thread closes on destruction { output() << "Waiting for completion of all tasks" << endl; } } { output() << "Press <Enter> to continue..." << endl; } cin.get(); return 0; } // active_object.hpp ------------------------------------------------------- #include <iomanip> #include <iostream> #include <queue> #include <boost/any.hpp> #include <boost/bind.hpp> #include <boost/function.hpp> #include <boost/optional.hpp> #include <boost/shared_ptr.hpp> #include <boost/thread.hpp> #include <boost/thread/xtime.hpp> #include <boost/tuple/tuple.hpp> #include <boost/utility.hpp> namespace ActiveWrapper { // Lock the output stream to prevent interleaving struct output { output() : lock(mutex) {} static unsigned count; private: static boost::mutex mutex; boost::mutex::scoped_lock lock; }; unsigned output::count; boost::mutex output::mutex; template <typename T> std::ostream& operator<< (const output& out, T t) { ++out.count; return std::cout << std::setw(2) << std::setfill(' ') << out.count << ": " << t; } // Pause to demonstrate effect int sleep(void) { boost::xtime time; boost::xtime_get(&time, boost::TIME_UTC); time.sec += 3; boost::thread::sleep(time); } namespace detail { // A generic thread-safe queue template <typename T> struct safe_queue { safe_queue(void) : terminated(false) { } bool enqueue (T t) { if (terminated) return false; boost::mutex::scoped_lock lock(mutex); queue.push(t); not_empty.notify_one(); return true; } boost::optional<T> dequeue(void) { boost::mutex::scoped_lock lock(mutex); if (terminated) return boost::optional<T>(); while (queue.empty()) { not_empty.wait(lock); if (terminated) return boost::optional<T>(); } T t = queue.front(); queue.pop(); return t; } void terminate(void) { boost::mutex::scoped_lock lock(mutex); terminated = true; not_empty.notify_all(); } private: bool terminated; std::queue<T> queue; boost::mutex mutex; boost::condition not_empty; }; // Object used to wait for the completion of a task struct synch_type { synch_type(boost::optional<boost::any*> a, boost::mutex* m, boost::condition* c) : result(a), mutex(m), condition(c), completed(false) {} ~synch_type() { if (result) delete *result; delete mutex; delete condition; } void wait_for_completion(void) { boost::mutex::scoped_lock lock(*mutex); if (completed == false) { if (result) { while ((*result)->empty()) (*condition).wait(lock); } else { (*condition).wait(lock); } completed = true; } } void notify(void) { boost::mutex::scoped_lock lock(*mutex); (*condition).notify_all(); completed = true; } boost::optional<boost::any*> get_result(void) { return result; } private: boost::optional<boost::any*> result; boost::mutex* mutex; boost::condition* condition; bool completed; }; // A reference-counted pointer to a synch type typedef boost::shared_ptr<synch_type> synch_ptr; // A type to enforce waiting policy on synchronisation struct waiter_type { waiter_type(synch_ptr s, bool force) : synch(s), force_wait(force), waited_for_completion(false) {} ~waiter_type() { if (force_wait) { wait_for_completion(); } } void wait_for_completion(void) { if (waited_for_completion == false) { synch->wait_for_completion(); waited_for_completion = true; } } boost::optional<boost::any*> result(void) { waited_for_completion = true; return synch->get_result(); } private: synch_ptr synch; bool force_wait; bool waited_for_completion; }; } // An encapsulation of a result that might require waiting for template <typename T> struct future { future(boost::shared_ptr<detail::waiter_type> w) : waiter(w) {} operator T& (void) { if (!value) { waiter->wait_for_completion(); boost::optional<boost::any*> result = waiter->result(); value = boost::any_cast<T>(*(*result)); } return *value; } protected: boost::optional<T> value; boost::shared_ptr<detail::waiter_type> waiter; }; template <> struct future<void> { future(boost::shared_ptr<detail::waiter_type> w) : waiter(w) {}; protected: boost::shared_ptr<detail::waiter_type> waiter; }; // Forward reference required by proxy_impl template <typename base> class active; namespace detail { // The type of tasks that are executed by the active object wrapper typedef boost::function<boost::any (void)> task_type; // A task and associated notification machinery typedef boost::tuple<task_type, boost::shared_ptr<synch_type> > task_descriptor; // A thead safe queue of tasks to be performed typedef safe_queue<task_descriptor> task_queue; // Dispatch to task queue, returning a facility to wait for the result template <typename result_type> future<result_type> invoke(task_queue* queue, bool force_wait, task_type task) { synch_ptr synch(new synch_type(new boost::any(), new boost::mutex(), new boost::condition())); task_descriptor td(task, synch); queue->enqueue(td); boost::shared_ptr<waiter_type> waiter (new waiter_type(synch, force_wait)); return future<result_type>(waiter); } template <> future<void> invoke<void>(task_queue* queue, bool force_wait, task_type task) { synch_ptr synch(new synch_type(boost::optional<boost::any*>(), new boost::mutex(), new boost::condition())); task_descriptor td(task, synch); queue->enqueue(td); boost::shared_ptr<waiter_type> waiter (new waiter_type(synch, force_wait)); return future<void>(waiter); } template <typename base, typename signature, bool force_wait> class proxy_impl; // Handler for non-void functions with one parameter template <typename base, typename R, typename T1, bool force_wait> class proxy_impl<base, R (T1), force_wait> { typedef R result_type; typedef T1 arg1_type; typedef result_type (base::*method_type)(arg1_type); typedef boost::function<result_type (arg1_type)> wrapper_type; typedef boost::function<future<result_type> (task_type)> invocation_type; static boost::any wrap(wrapper_type task, arg1_type arg1) { return task(arg1); } invocation_type invocation; wrapper_type task; public: proxy_impl(base* object, method_type method, active<base>* active) { task = boost::bind(method, object, _1); invocation = boost::bind(&invoke<result_type>, active->queue(), force_wait, _1); } future<result_type> operator()(arg1_type arg1) { return invocation(boost::bind(&wrap, task, arg1)); } }; // Handler for void functions with one parameter template <typename base, typename T1, bool force_wait> class proxy_impl<base, void (T1), force_wait> { typedef void result_type; typedef T1 arg1_type; typedef result_type (base::*method_type)(arg1_type); typedef boost::function<result_type (arg1_type)> wrapper_type; typedef boost::function<future<result_type> (task_type)> invocation_type; static boost::any wrap(wrapper_type task, arg1_type arg1) { task(arg1); return boost::any(); } invocation_type invocation; wrapper_type task; public: proxy_impl(base* object, method_type method, active<base>* active) { task = boost::bind(method, object, _1); invocation = boost::bind(&invoke<result_type>, active->queue(), force_wait, _1); } future<result_type> operator()(arg1_type arg1) { return invocation(boost::bind(&wrap, task, arg1)); } }; // Handler for non-void functions with no parameters template <typename base, typename R, bool force_wait> class proxy_impl<base, R (void), force_wait> { typedef R result_type; typedef result_type (base::*method_type)(void); typedef boost::function<result_type (void)> wrapper_type; typedef boost::function<future<result_type> (task_type)> invocation_type; static boost::any wrap(wrapper_type task) { return task(); } invocation_type invocation; wrapper_type task; public: proxy_impl(base* object, method_type method, active<base>* active) { task = boost::bind(method, object); invocation = boost::bind(&invoke<result_type>, active->queue(), force_wait, _1); } future<result_type> operator()(void) { return invocation(boost::bind(&wrap, task)); } }; // Handler for void functions without parameters template <typename base, bool force_wait> class proxy_impl<base, void (void), force_wait> { typedef void result_type; typedef result_type (base::*method_type)(void); typedef boost::function<result_type (void)> wrapper_type; typedef boost::function<future<result_type> (task_type)> invocation_type; static boost::any wrap(wrapper_type task) { task(); return boost::any(); } invocation_type invocation; wrapper_type task; public: proxy_impl(base* object, method_type method, active<base>* active) { task = boost::bind(method, object); invocation = boost::bind(&invoke<result_type>, active->queue(), force_wait, _1); } future<result_type> operator()(void) { return invocation(boost::bind(&wrap, task)); } }; } // Wrapper class to supply active behaviour to other objects template <typename base> class active { void thread_function(void) { while (true) { boost::optional<detail::task_descriptor> td = tasks.dequeue(); if (!td) break; detail::task_type task = td->template get<0>(); detail::synch_ptr synch = td->template get<1>(); boost::optional<boost::any*> result = synch->get_result(); if (result) { *(*result) = task(); } else { task(); } synch->notify(); } } detail::task_queue tasks; boost::thread thread; protected: active(void) : thread(boost::bind(&active<base>::thread_function, this)) { } ~active() { tasks.terminate(); thread.join(); } template <typename signature, bool force_wait = false> struct proxy : public detail::proxy_impl<base, signature, force_wait> { typedef detail::proxy_impl<base, signature, force_wait> impl_type; typedef typename impl_type::method_type method_type; proxy(base* object, method_type method, active<base>* active) : impl_type(object, method, active) {} }; public: detail::task_queue* queue(void) { return &tasks; } }; };

1 0

Random: Minor documentation fix
by Michael Stevens 19 Feb '04

19 Feb '04

Looking at the documentation I stumbed across a couple of issues. In normal_distribution is states Requires: sigma > 0 This looks like a typo as the constructor uses assert(sigma >= result_type(0)); and sigma ==0 is no problem numerically. Oddly lognormal_distribution has no "Requires" section. The constructor requires assert(mean > result_type(0)); and it inherits the sigma requirement from normal_distribution. I think I have also found a few left overs from the old interface. The introduction states "All of the distribution functions described below store a non-const reference to the underlying source of random numbers. Therefore, the distribution functions are not Assignable... This is no longer true. Only uniform_01 now constructed with a reference to an underlying UniformRandomNumberGenerator. Actually uniform_01 seems to be a very odd beast now. It is different from all the other Distributions. It would seem to make sense to document it separately as a special case. One major stumbling block for me in the documentation is the definition of the operator() as: template<class UniformRandomNumberGenerator> result_type operator()(UniformRandomNumberGenerator& urng); This leads the unsuspecting user to think they can use any type the models a UniformRandomNumberGenerator for example a boost::mt19937 Although in theory this is correct this can lead to big surprises in practice. For example normal_distribution uses a probability density function p(x) = 1/sqrt(2*pi*sigma) * exp(- (x-mean)2 / (2*sigma2) ) This combine with the numerical range of the result_type will lead to normal_distribution almost always producing NaN! variate_generate implicitly goes to great care to avoid this, so the problem only arrises if the distribution is used directly. Obviously a big Caution in the type documentation would be good. However I am wondering if a better way to deal with it would be to add a new concept. Something like RestrictedUniformRandomNumberGenerator where the range of the output is restricted in order for the distribution to give meaningful results. Anyway apart from these Minor doc issues the new Random looks very good. Thanks Jens, Michael -- ___________________________________ Michael Stevens Systems Engineering Navigation Systems, Estimation and Bayesian Filtering http://www.sf.net/Bayes++ ___________________________________

1 0

another idea - two sets of regression tests ?
by Bronek Kozicki 19 Feb '04

19 Feb '04

This message is actually result of subthread in "1.31 regressions" where I started discussion about dropping support for older compilers. My idea was to split boost to two branches : "current" and "old compilers" (based on 1.31 release). New features could be developed in "current", while "old compilers" should be still supported, and some new features (and most importantly - fixes) could be backported to this branch. Here is part of discussion: >>>>>>>>>> (my voice) > Thus hopefully they will not mind if we just ask them to use > releases in 1.31.x branch. But it also means that we will need to > support two branches for (at least) next two years. This might be > cumbersome, but on the other hand it should simplify development in > "current" branch. (David Abrahams) Yep. It'll be cumbersome, that's for sure. Would it be any better than bringing in new "non-vc6" features with #ifdefs and new non-vc6 libraries without apology? >>>>>>>>>> (my voice) > However, I do suggest that *if there is new branch* of boost, > many regression tests targeted at old (nonconforming) compilers should > be pulled out from this branch. Effectively, to make new features > available for old compilers, these features have to be back-ported to > the "old branch". > (Pavel Vozenilek) I am afraid it woudn't work very well: - There are many small fixed and updates and these could be easily be missed. - The effort to keep multiple branches of Boost would take more than maintaining current state. >>>>>>>>>> (my voice) > I think nobody is going to prevent you from supporting any compiler you > want :> However, I do suggest that *if there is new branch* of boost, > many regression tests targeted at old (nonconforming) compilers should > be pulled out from this branch. (Peter Dimov) That's what I disagree with. I want these compilers to participate in the regression tests, so that I can see when I inadvertently introduce a regression. >>>>>>>>>> I can see there are strong points against this idea. However, I still feel there is urgent need to simplify regression tests in order to make future releases simpler. I'd also like to give choice to developers if they want to support old compilers (like MSVC6, GCC 2.95 or BCC32) or not. Here's another idea: two sets of regresion tests. Library maintained by developer willing to support old compilers will be tested against both, while other libraries will be tested against only one. Users of old compilers will have a list of libraries which have been tested against both sets (including results) - if they don't see on this list library they need, they can still use older release of boost. B.

2 2

boost thread static library
by Arkadiy Vertleyb 19 Feb '04

19 Feb '04

Hi all, I just built boost 1.31.0 (windows, with mingw toolset), and I can't find the static thread library. Did I do something wrong or is it no longer supported (it was there at least in 1.29)? Thanks, Arkadiy _________________________________________________________________ Find and compare great deals on Broadband access at the MSN High-Speed Marketplace. http://click.atdmt.com/AVE/go/onm00200360ave/direct/01/

6 14

boost::filesystem::exists bug and patch
by Jonathan Ultis 19 Feb '04

19 Feb '04

::exists is implemented using ::stat. The ::stat routine returns an error on file sizes larger than 2 gigs in libc-2.3.2, and several others. So, very large files never exists (). Using ::access seems to fix the problem. =================================================================== RCS file: /cvsroot/boost/boost/libs/filesystem/src/operations_posix_windows.cpp,v retrieving revision 1.29 diff -c -r1.29 operations_posix_windows.cpp *** operations_posix_windows.cpp 6 Feb 2004 01:27:06 -0000 1.29 --- operations_posix_windows.cpp 9 Feb 2004 06:19:28 -0000 *************** *** 302,309 **** BOOST_FILESYSTEM_DECL bool exists( const path & ph ) { # ifdef BOOST_POSIX ! struct stat path_stat; ! return ::stat( ph.string().c_str(), &path_stat ) == 0; # else return ::GetFileAttributesA( ph.string().c_str() ) != 0xFFFFFFFF; # endif --- 302,308 ---- BOOST_FILESYSTEM_DECL bool exists( const path & ph ) { # ifdef BOOST_POSIX ! return ::access (ph.string ().c_str (), F_OK) == 0; # else return ::GetFileAttributesA( ph.string().c_str() ) != 0xFFFFFFFF; # endif

3 6

Leaner type traits tests
by John Maddock 19 Feb '04

19 Feb '04

Those asking for leaner type traits tests will be pleased to know that they have been reworked so that they no longer depend on Boost.Test (unless you want it to by using --type-traits-unit-test as a command line arg to bjam). Unfortunately, while this does cut down on build dependencies, it doesn't reduce overall build times that much (which are mainly dominated by the time taken to instantiate the various templates). John.

1 0

Re: Three questions about the new license
by David Abrahams 19 Feb '04

19 Feb '04

"Diane Cabell" <dcabell(a)law.harvard.edu> writes: >> >> Thanks, that seems less prone to misinterpretation to me also. Would >> >> // Copyright David Abrahams 2004. 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) >> >> do just as well? It's just just a little less wordy -- "made >> available subject ot the terms of" sticks in my craw a bit. > > Yes. > >> > (....) >> >> > David Abrahams wrote: >> >> > >> >>(....) >> >> >> >> Ugh I don't think we ever considered that "display" would be >> >> interpreted other than to mean "display publicly". Does that mean >> >> that in the license: >> >> >> >> Permission is hereby granted, free of charge, to any person or >> >> organization obtaining a copy of the software and accompanying >> >> documentation covered by this license (the "Software") to use, >> >> reproduce, display, distribute, execute, and transmit the >> >> Software, and to prepare derivative works of the Software, and to >> >> permit third-parties to whom the Software is furnished to do so, >> >> all subject to the following: >> >> >> >> "display" ought to be "display publicly"? >> > >> > Yes. But again, private display doesn't require permission, so a >> > court would likely interpret this to language to mean "public >> > display." If it went to court, you'd get to testify as to that >> > intention. >> >> So IIUC, changing the license wording isn't critical. We should >> probably wait 'till a critical issue comes up before making any >> non-critical changes. > > Yep. Thanks again for all your help, Diane! -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 1

RE: [boost] Re: Re:(For me a) showstopper [was: boost threadstaticlibrary]
by Randy Bowen 19 Feb '04

19 Feb '04

> -----Original Message----- > From: Stefan Slapeta [mailto:stefan@slapeta.com] > Sent: Wednesday, February 18, 2004 2:07 PM > To: 'Boost mailing list' > Subject: RE: [boost] Re: Re:(For me a) showstopper [was: > boost threadstaticlibrary] > > > I would be interested to learn how you achived this without > modifying boost. > In a MSVC++ 7.1 environment, we simply created a static library project and copied the Boost Thread cpp files into it. My only caveat would be that this was done with version 1.29.0 -- I don't know if there have been any subsequent changes that would cause complications in such an approach.

2 1

RE: [boost] Re: Re:(For me a) showstopper [was: boost thread static library]
by Randy Bowen 18 Feb '04

18 Feb '04

Edward Diener wrote: > > His problem is that if he builds a statically linked library > and uses the Boost threads library, he will be using a shared > library and all the shared RTL libraries also, since that is > what the shared Boost threads library needs to work. > > I also have found that mixing static and shared libraries in > any situation quite often leads to problems. In this latter > respect, one should use all shared libraries or all static > libraries, instead of mixing in both. > The thread_specific_ptr class is the only piece that really requires a shared library. Running in a Windows environment, we have repackaged the remainder of the library as a static library for some time now, and experience no problems. Randy Bowen Stamps.com

2 1

RE: [boost] FC++: lambda
by Powell, Gary 18 Feb '04

18 Feb '04

While I haven't had a chance to review the latest version of FC++ that's being offered for boost, I have reviewed most of the previous versions over the last few years. And I think quite highly of this library. And I believe that until there is core language support for lambda's a library solution will always be a trade off. Hence I believe that there is room in boost for both BLL and BFC++. Yours, -Gary Powell- powellg(a)amazon.com

1 0

RE: [boost] Re: Re: Future of threads (III)
by Hurd, Matthew 18 Feb '04

18 Feb '04

> On Behalf Of scott > Subject: RE: [boost] Re: Re: Future of threads (III) > > On Behalf Of Hurd, Matthew > > > AO's should either have a queue for work or hook into a > > queue. They are > > a bit like a worker pool with one worker ;-) > > yep. > > > > > Another idiom is a future value, where you ask for a value and don't > > block until you "read" the value. ACE also has an implementation of > > this. You can think of it as a bit like overlapped I/O. > > Yes. This was also in the ActiveObject pattern. It was on the "client- > side", i.e. available to the thread that submits Method Requests as a > means to acquire the results. > > While I understand its place in the ActiveObject pattern I would hope > that if a boost::active_object came into existence, there would be a > single (i.e. not _simple_) mechanism by which data passed from one thread > to the other, with an associated notification. In a behavioural sense, > the future mechanism wouldnt be appropriate for this. I'd agree here in principle to keep this asynchronous and have the equivalent of message passing with a function call with a void return type. The future_value is an elegant idiom for providing a C++ RPC / LPC equivalent. The whole store and forward expectation issue would suit this style as it just looks like a normal function or method call. > This way of thinking does require that all threads are active_objects > which may be too aggressive <shrug>. A small sample of empirical data > says its fine. It works a treat for a lot of things. Especially suited to workflows of things that you want to dynamically configure. Threading is a big overhead though. Consider these numbers: Safe increment (Athlon 2800+) (P4 3.2GHz) Interlocked primitive 11 ns 53 ns Critical section 138 ns 411 ns A bit slower than a single machine instruction. If I make a size_t volatile and time 100 increments in a row I get 3.8ns per increment on the P4 above, more then ten times slower than an interlocked increment. And it doesn't end there, the cache effects also add considerably. So in my mind, the active object pattern is good for configurability and where the work of the object is chunky enough to where the cost of the context switches and cache effects. In terms of work pools, this context overhead also led to the idea of a leader-follower pattern where you try and use the same worker if possible. This is also why we have seen the argument for a shared_ptr with multi-thread safety as a policy. On a Pentium 4 you are typically paying around ten times the cost of a normal increment for the privilege of thread safety. > > I also advocate a different architectural neutral style where you can > > have things at look like function calls that can be: > > 1. a function call > > 2. a call to queue work pool or active object > > 3. an IPC mechanism for same machine transfer, e.g. > > shared memory > > 4. a network mechanism, TCP, UDP, TIB or something, for > > > > Understand the reasons you ask for 1...4 but would like to add some > other thoughts to see what you think. > > An ActiveObject servant contains code. That code is implementation > of behaviour and its what (I believe) we tacitly want when we all > say that "thread-inherited-classes" or "active objects" are a nice > manner in which to deal with threads. > (note: more accurately the pattern says that thread==scheduler and > a scheduler executes servant code. but i think we can skip this > detail) > > If the code is in the servant, what do 1 and 2 mean? My best matching > of your thinking with the servant-based thinking would be that somehow > the "client" can submit something into the "worker pool" that _identifies_ > a function that is in the servant. It would be nice if this "work > submission" could carry some arguments for presentation to the servant. I think I understand what you're saying, but I'm not sure. Are you thinking about how the marshalling is done? > A detail that I am labouring is the separation of "calling" (would > much rather that this was "sending") and execution. Our active object > has no synchronous i/f with methods for us to call; it is simply a > "work pool" that we add to. As soon as we make a sync i/f available > then we go down that road that leads to servant code in the client. > > I suggest that notions of "function call" should be exorcised from > discussions that are targeting active objects. That type of thinking > is perfectly valid in some other thread (oops) but can scuttle work > targeting active objects; the behaviour (i.e. the code) is inherently > in the object. Not sure I agree. Think of it the small talk way. A message is a method call. You could have your active object providing a function call that puts a message on to its internal queue and returns. This way you could perhaps specialise by policy whether or not it had its own thread of control and make your architecture a lot more flexible similar to the relationship of 1. and 2. above. > a client can only submit "worker orders" or "Method Requests" or > jobs or messages or signals. > > I hope there is enough there to make a case :-) You certainly have a case. The nirvana I'm looking for is a policy approach to reconfiguring architecture so I can make late decisions about single, multi-thread, multi-process, distributed design. I think your active object can gel with this as I think you can consider parallels to the numbering above: 1. method call 2. method call that generates message to active object thread of control and returns 3. method call -> lightweight message on the same box or LRPC 4. method call -> external system message (tcp, udp, tib, etc) or RPC > > > If it can be enabled by a policy driven approach then you can > > change the > > architecture of your application by simply changing policies. > > > > I think David Abraham's named parameters could help greatly with this > > approach, along with the serialization lib for marshalling support. > > This should provide a solid basis for this. I've also thought that > > perhaps boost::signals might be the correct approach to take for this > > but I'm unsure. > > > > To support this approach you also need mutex aspects that are also > > policy driven. I am preparing to submit such locking that > > builds on the > > existing mutexes and locks. > > <phew> That is quite a scope. But yes, I can see that ultimately > it should cover all these dimensions. Maybe a phasing? Yep, I think the locking and mutex stuff needs to be cleaned up or wrapped to suit a policy approach. Need atomic op support too. Next step is a thread safe queue. Perhaps two, one with priority and a normal one. I've got these I can submit but they're defective in terms of exception safety. Next step is a way having a policy based interface approach to make calling a function result in the calling of a function or marshalling the parameters and calling something else... This is the bit where I'm not sure how best to approach it. Then it is a latter of adding transports to enrich the approach. > Cheers, > Scott Good thinking there Scott. Regards, Matt Hurd _______________________ Susquehanna Pacific P/L hurdm(a)sig.com +61.2.8226.5029 _______________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

4 4

[bind] bug when used together with function.hpp on BCB
by Pavel Vozenilek 18 Feb '04

18 Feb '04

BCB 6.4, Boost 1.31 (1.30.2 fails too). Following snippet fails to compile: ---------------------------------------- #include <boost/function.hpp> // remove and it will compile OK #define BOOST_MEM_FN_ENABLE_FASTCALL // or remove this and it will be OK #include <boost/bind.hpp> // or move <function.hpp> after <bind.hpp> and it will compile OK int main() { return 0; } ---------------------------------------- with error: [C++ Error] bind_mf_cc.hpp(20): E2316 'mf0_fastcall' is not a member of '_mfi' Full parser context Unit1.cpp(6): #include C:\boost\boost_1_31_0\boost/bind.hpp bind.hpp(44): namespace boost bind.hpp(1544): #include C:\boost\boost_1_31_0\boost/bind/bind_mf_cc.hpp [C++ Error] bind_mf_cc.hpp(20): E2040 Declaration terminated incorrectly Full parser context Unit1.cpp(6): #include C:\boost\boost_1_31_0\boost/bind.hpp bind.hpp(44): namespace boost bind.hpp(1544): #include C:\boost\boost_1_31_0\boost/bind/bind_mf_cc.hpp [C++ Error] bind.hpp(1577): E2190 Unexpected } Full parser context Unit1.cpp(6): #include C:\boost\boost_1_31_0\boost/bind.hpp When the #include <boost/function.hpp> is removed it compiles cleanly. The code compiles OK on Intel C++ so it seems to be caused by some strange interaction with Boost.Function. /Pavel

3 4

[BGL] [pri_queue] [utility] More documentation, examples, and unit tests.
by Cromwell Enage 18 Feb '04

18 Feb '04

I've consolidated the work into <http://groups.yahoo.com/group/boost/files/boost-pending.zip> I saw a pri_queue subfolder in the libs directory. Should priority queue documentation go there? In <boost/graph/graph_concepts.hpp>, a comment on the BufferConcept class implores it to move out of BGL. Will it eventually move to <boost/concept_check.hpp>? Should the documentation accompanying it similarly move to libs/utility, to maintain consistency? I'm also not sure about where boost::queue documentation should go. Fortunately, only two documents mention it: breadth_first_search.html and breadth_first_visit.html. I've added documentation for a new UpdatableBuffer concept, which both mutable_queue and fibonacci_heap currently model. In the spirit of the Buffer concept documentation, only the update() function and its associated time complexity requirement are added. The zip file contains all of my proposed changes. Once again, feedback appreciated. Cromwell Enage __________________________________ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools

1 0

boost threads
by John Fuller 18 Feb '04

18 Feb '04

A recent project of mine uses shared queues based on Ted Yuan's producer-consumer code. The producer consumer code has been modified to use timed waits, and in my concurrency directory I provide management for named threads and channels. See http://sourceforge.net/projects/easyasap/

2 2

Update on the Interval library
by Guillaume Melquiond 18 Feb '04

18 Feb '04

Hi, Now that the 1.31 version of Boost has been shipped, I am gradually pushing into the CVS a new version of the Interval library. The main change is the support for conversion between intervals with different base types. I am pushing it gradually in order to follow the evolution of the regression tests. It seems Borland and pre-7.1 Microsoft compilers won't support at all (there was a partial support in the previous versions of the library) the new version since they are not even able to parse the headers. On the other hand, GCC 2.95 doesn't ice anymore with this new scheme (quite strange, isn't it?). All the other compilers seem to quietly support the new version. Except for cwpro8: there is one failure (det.cpp) in the test-suite. Does this compiler have some known problems when dealing with template ordering? And is there some workaround? Regards, Guillaume

1 0

[threads] rw_lock question
by Vladimir Prus 18 Feb '04

18 Feb '04

Hello, I was looking at rw_lock implementation in the thread_dev branch and see that member variable m_num_waiting_promotion is only set in constructor to '0' and then once tested for equality with 1. So, looks like it has no effect at all? Did I miss anything? Note: I'm not yet planning to use rw_lock, I'm just looking at implementation. - Volodya

2 1

[signals] is assertion necessary when no slots connected
by Jody Hagins 18 Feb '04

18 Feb '04

When signalling, with no slots connected, an assertion is raised (if the return type of the slot is not void). For example: boost::signal<void ()> sig; sig(); does "nothing" while boost::signal<int ()> sig; sig(); asserts (if the default combiner is used). I guess that makes sense, because there can be no "combined" return value if there are no slots. However, an assertion seems a bit harsh. I am really not sure what should happen, but maybe an exception is a better alternative, or maybe an alternative interface can define a default value to be returned if there are no slots connected), or maybe something else... Anyway, I guess I was wanting to know why this is the case, and what is the usual method of handling this circumstance. I assume something like: if (!sig.empty()) { result = sig(); } but that just does not look pretty...

3 3

[Type Traits] Deprecating/eliminating is_stateless
by Douglas Paul Gregor 18 Feb '04

18 Feb '04

is_stateless was a mistake. It is poorly defined and of very limited value. The only place it is used in Boost is in Function, where it's interacting badly with the new operator== functionality. I'd like to deprecate it in CVS head, or even outright kill it. Any objections? Doug

2 1

[BGL] [sandbox] new make_random_paths algorithm
by Cromwell Enage 18 Feb '04

18 Feb '04

Changes to <http:://groups.yahoo.com/group/boost/files/bgl_algo/make_random_paths.zip>: * Added loop_erased_random_paths algorithm. (Thanks to Jonathan de Halleux for the research!) * Renamed make_random_paths as ddnw_random_paths, to make it less appealing. * Updated documentation, example, and unit test. Keep those suggestions coming! Cromwell __________________________________ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools

1 0

Re: [function] timing trivia
by matt＠finray.com 18 Feb '04

18 Feb '04

I think I found a suitable trick to measure boost::function overhead in release mode on my platform. I'm getting 14-30 nanoseconds consistently now by forcing the result into a volatile double: Results are: -------------------------------------------------------------------------------- looper invasive timing estimate boost_function_call -------------------------------------------------------------------------------- median time = 33.52057416267943 microseconds 90% range size = 2.514354066985641 microseconds widest range size (max - min) = 19.96459330143541 microseconds minimum time = 25.20813397129187 microseconds maximum time = 45.17272727272728 microseconds 50% range = (33.51961722488039 microseconds, 33.52057416267943 microseconds) 50% range size = 0.9569377990413671 nanoseconds -------------------------------------------------------------------------------- looper invasive timing estimate boost_function_call_equiv_with_in_line_source -------------------------------------------------------------------------------- median time = 33.50287081339713 microseconds 90% range size = 2.509569377990427 microseconds widest range size (max - min) = 16.82918660287082 microseconds minimum time = 25.18851674641148 microseconds maximum time = 42.0177033492823 microseconds 50% range = (33.50287081339713 microseconds, 33.50382775119618 microseconds) 50% range size = 0.9569377990413671 nanoseconds Press any key to continue . . . Which is about an 18ns difference. From this code: #define MAX_FN_LOOP 1e4 static double not_empty() { static double sum; static double i; sum = 0.0; for (i = 0.0; i < MAX_FN_LOOP ; ++i) { sum += i * i; } return sum; } inline double boost_function_call( matt::timer& t ) { boost::function< double (void)> fn = ¬_empty; double now; volatile double x = 0; t.restart(); x += fn(); now = t.elapsed(); return now; } inline double boost_function_call_equiv_with_in_line_source( matt::timer& t ) { double now; volatile double x; t.restart(); static double sum; static double i; sum = 0.0; for (i = 0.0; i < MAX_FN_LOOP ; ++i) { sum += i * i; } x = sum; now = t.elapsed(); return now; } If I change the size of the loop to something much smaller, say 1e1, I get a reasonably consistent result now: -------------------------------------------------------------------------------- looper invasive timing estimate boost_function_call -------------------------------------------------------------------------------- median time = 60.28708133971293 nanoseconds 90% range size = 0.9569377990430612 nanoseconds widest range size (max - min) = 2.90622009569378 microseconds minimum time = 60.28708133971293 nanoseconds maximum time = 2.966507177033494 microseconds 50% range = (60.28708133971293 nanoseconds, 61.244019138756 nanoseconds) 50% range size = 0.9569377990430612 nanoseconds -------------------------------------------------------------------------------- looper invasive timing estimate boost_function_call_equiv_with_in_line_source -------------------------------------------------------------------------------- median time = 43.54066985645935 nanoseconds 90% range size = nanoseconds widest range size (max - min) = 34.92822966507178 nanoseconds minimum time = 43.54066985645935 nanoseconds maximum time = 78.46889952153111 nanoseconds 50% range = (43.54066985645935 nanoseconds, 43.54066985645935 nanoseconds) 50% range size = nanoseconds Press any key to continue . . . About a 17ns difference. Pretty consistent with the previous measurement even though the function workload is a couple of orders of magnitude different. I think my quoteable message for Doug would read: <message> The cost of boost::function can be reasonably consitently measured at around 20ns +/- 10 ns on a modern >2GHz platform versus directly inlining the code. However, the performance of your application my benefit from or be disadvantaged by boost::function depending on how your C++ optimiser optimises. Similar to a standard function pointer, differences of order of 10% have been noted to the _benefit_ or _disadvantage_ of using boost::function to call a function that contains a tight loop depending on your compilation circumstances. </message> HTH... Which is where I'll leave it. I think I'm satisfied with my lack of understanding of this trivial trivia now. Regards, Matt Hurd.

2 1

Re: [boost] Re: Future of threads (III)
by Jody Hagins 18 Feb '04

18 Feb '04

On Tue, 17 Feb 2004 22:13:17 -0500 "Hurd, Matthew" <hurdm(a)sig.com> wrote: > > Or zero threads ;-) with an architecture neutral approach. Exactly. The point is that the user of the AO could care less (except maybe for performance reasons, where the locking strategy may be parameterized to eliminate some overhead). -- Jody Hagins Give him an evasive answer.

1 0

RE: [boost] Re: Future of threads (III)
by Hurd, Matthew 18 Feb '04

18 Feb '04

> On Behalf Of Jody Hagins > David Abrahams <dave(a)boost-consulting.com> wrote: > > > > Are ActiveObjects like all objects were in Simula: each running in its > > own thread, with fully asynchronous inter-object communications? > > > Doesn't have to be. An Active Object could actually have a number of > threads doing work on its behalf. > -- > Jody Hagins Or zero threads ;-) with an architecture neutral approach. Regards, Matt Hurd _______________________ Susquehanna Pacific P/L hurdm(a)sig.com +61.2.8226.5029 _______________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

1 0

Future of threads (III)
by scott 17 Feb '04

17 Feb '04

hi y'all, i have been listening-in to the recent thread thread (intentional); its worth it! threading is a special interest for myself at the moment. i have been working on something different (distributed messaging) and have been forced to consider threading. again and again. it seems to be impossible to address the one (messaging) without also addressing the other (multi-threading). this would come as no real surprise to anyone, but the slightly unnerving thing has been the "distance" between the threading model that seems to fulfil the requirements of my distributed messaging and the model in boost::threads. this is not intended to question the validity of that model; quite the opposite. i have wondered if my model is invalid and considered the task of "porting" the messaging code to the boost model (if not the implementation) calling it the "boost model" seems a little unfair as i think i can say it is in the spirit of other implementations such as rogue wave's. recent work has taken me on a different path. i have been cornered into applying my messaging+threading model within a significant body of complex production code. millions of lines of code and dozens of threads. the interesting thing (for me :-) has been how effectively the new threading model has integrated with the existing model(s). this did make me feel better about the track i had taken. so, is there room for 2? very briefly, the boost model treats threads as a resource (fair enough to :-) and submits code fragments for asynchronous execution. in the alternate model, threads come about as a consequence of instantiating final (a la java) objects. the distinguishing attribute being that threads only run code that is "part of themselves" rather than code being submitted from "outside". execution of the code is initiated by sending of a message (within my vocabulary that is actually a signal). the message can contain arbitrary data. is this different enough? is there enough value there? cheers, scott

11 33

Perfect Forwarding (almost)
by David Abrahams 17 Feb '04

17 Feb '04

The example below shows a technique for perfect forwarding that seems to work with GCC 3.3.1. rvalues are always moved automatically, and lvalues are copied. Except for one rather important case, it works with Comeau (errors only in strict mode). The important case that causes the error clearly violates 12.2/1 of the standard, but see below. VC++ and CodeWarrior have different kinds of problems with it from Comeau/strict. I am hoping that they are wrong, but I am not enough of a core language jock to make a determination on which of these compilers is correct (if any). 12.2/1 says that the act of binding an rvalue to a (const) reference creates a temporary (which may be elided). The creation of the temporary requires the existence of a copy ctor with a const& argument. As far as I know, that rule serves no useful purpose, but I may have missed something. *If* my example actually works other than this case, I'd like to try to get the rule lifted, and soon! This is by no means the cleanest route to move semantics, but it's probably the smallest "language extension" we'd ever need to get it, and might even be possible before C++0x Enjoy, Dave -- Dave Abrahams Boost Consulting www.boost-consulting.com

14 70

RE: [boost] Re: Moving Boost.Thread barrier from thread_dev to HE AD
by Bjorn.Karlsson＠readsoft.com 17 Feb '04

17 Feb '04

> From: Michael Glassford [mailto:glassfordm@hotmail.com] > One potential problem that I am aware of is that it is > possible for the > m_generation counter (see barrier.cpp) to overflow on systems that > detect overflow of integer addition instead of wrapping (I > assume there > are such systems though I've never used one). Is it > worthwhile checking > for this and forcing wrapping in code? Checking for overflow isn't needed in this case, since the underlying type is unsigned (and unsigned integer arithmetic does not overflow [per §3.9.1.4]). Bjorn

2 1

Re: boost thread static library
by Arkadiy Vertleyb 17 Feb '04

17 Feb '04

Thanks, Russell and Michael, from your responces I realise that I will probably have to leave with DLL. However, the next question then would be why am I getting these undefined refs while linking with boost_thread-mgw-mt-d-1_31d? obj\synchronizer.o(.text$_ZN5boost9condition7do_waitINS_5mutexEEEvRT_+0x29):sync hronizer.cpp: undefined reference to `boost::detail::condition_impl::do_wait(__p thread_mutex_t**)' obj\synchronizer.o(.text$_ZN5boost6detail6thread8lock_opsINS_5mutexEE4lockERS3_R NS3_8cv_stateE+0x14):synchronizer.cpp: undefined reference to `boost::mutex::do_ lock(boost::mutex::cv_state&)' obj\synchronizer.o(.text$_ZN5boost6detail6thread8lock_opsINS_5mutexEE6unlockERS3 _RNS3_8cv_stateE+0x14):synchronizer.cpp: undefined reference to `boost::mutex::d o_unlock(boost::mutex::cv_state&)' Thanks, Arkadiy _________________________________________________________________ Get fast, reliable access with MSN 9 Dial-up. Click here for Special Offer! http://click.atdmt.com/AVE/go/onm00200361ave/direct/01/

2 1

Numeric Conversion Library and VC7.0
by Fernando Cacciola 17 Feb '04

17 Feb '04

Hi All, Michael Borghart is helping me fix some extrange problem with the numeric conversion lib on VC7.0 The problem doesn't exist on VC7.1 and it is not a compilation problem (at least not one that produces a compile fail). If anyone with VC7.0 can help me here I'll appreciate it, TIA The problem can be seen with the following simple test: #include<boost/numeric/converter.hpp> int main() { long l = -1 ; boost::numeric_converter<unsigned long,long>::convert(l); } that code is supposed to raise an exception at runtime because -1 is out of range for "unsigned long". On VC7.0, however, it doesn't. For you to help me, you'll have to step into the code to see what is it doing, Here's a description of the code and what it is should happen: There are two main kinds of converters: rounding and non-rounding: The rounding converter is used ONLY for float to integral conversions. Their conversion entry code looks like: static result_type convert ( argument_type s ) { RangeCheckerBase::validate_range(s); source_type s1 = Float2IntRounderBase::nearbyint(s); return RawConverterBase::low_level_convert(s1); } And for non-rounding converters (used by anything but float to int): static result_type convert ( argument_type s ) { RangeCheckerBase::validate_range(s); return RawConverterBase::low_level_convert(s); } There you can see the different "steps" of the conversion process. First, validate_range() performs the range checking. If this function returns (which shouldn't in case of an out of range), low_level_convert() is called to perform the actual conversion. low_level_convert() is supplied by the user as part of the RawConverter policy, but validate_range() is selected at compile time accordining the the combined properties of the Source and Target types. In our case, it appears that VC7.0 is choosing the wrong validate_range() implementation. Unless Source==Target, validate_range() calls the function out_of_range() which looks like: static range_check_result out_of_range ( argument_type s ) { typedef typename combine<IsNegOverflow,IsPosOverflow>::type Predicate ; return Predicate::apply(s); } Here you can see that the actual checking is performed by a "predicate" which is composed at compile time. Depending on the type properties, the predicate might be "combined", meaning that two cascading tests are performed instead of just one. If for a given case only a single predicate is used, the code should step into a function of the form: static range_check_result apply ( argument_type s ) { return {...some specific test....} } Otherwise, the "outer" apply simply calls two applies in a row: static range_check_result apply ( argument_type s ) { range_check_result r = PredA::apply(s) ; if ( r == cInRange ) r = PredB::apply(s); return r ; } } ; Finally, each individual "apply" is implemented by the set of objects that appear at the top of "detail\converter.hpp" These predicates perform the minimally neccesary testing to decide if the source value is out of range. For this particular conversion: long->unsigned long The only required test is (s<0), so the predicate that should be selected by the metaprogramming is the class: LT_Zero I suspect that VC7.0 is using a different predicate. So, if you could step inside validate_range() out_of_range() apply() apply() // only if it stepped into the "combiner" predicate and print the stack from there I'll see what's happening. TIA Fernando Cacciola SciSoft

1 0

Re: [boost] Re: [OT] Hiding template parameters [was: FC++ Formal review is...]
by Gabriel Dos Reis 17 Feb '04

17 Feb '04

David Vandevoorde <daveed(a)vandevoorde.com> writes: | (I'm not on the Boost list. Gabriel: Apologies if you | get this twice. I don't know if you're on the list. | So to be sure, I left you on the recipients' list.) { Don't worry: duplicate messages are automatically deleted. :-) I used to read Boost mailing list in batch mode these times, but Dave sent about this issue on Boost list with a copy to me and Steve; but later, he decided that the issue should be OT. I'm having trouble following that part. } | On Feb 17, 2004, at 6:29 AM, Gabriel Dos Reis wrote: | [...] | > Someone has characterized it as inconsistent without giving details as | > to why; all I'm saying is that, if one accepts the principle that | > "scopes nest", then the rule is a logical consequence, hence | > consistent with that principle. | | You're making one more assumption: That template | parameters really have their own full-fledged scope. No. I'm reasoning with the -fact- that the scope of template-parameters encloses the template. That is not an assumption. | I say that they shouldn't, just as function parameters | don't. But, the situation is not similar: template-parameters are introduced *before* the thingy being parameterized. You'd have the same situation with function parameters if they were introduced before the function they are part of (Note: declaring them before the function may "solve" some of the problems with auto/decltype type-deduction issues in the auto/decltype proposal). | > Now, it might be that that logical | > consequence is unacceptable for some non-rational reasons, but that | > does not mean the consequence itself is inconsistent. | | The current situation is IMO unacceptable for | _rational_ reasons, no matter what the language- | legalistic arguments for it may be. I'm not offering language-legalistic arguments. In the first message Dave sent to me (which generated this thread), he said he was just registering a strong opinion. That is not rational reasons, it is just a statement of feeelings. In subsequent messages, he made more assertions mostly based on misuderstanding of what I was proposing. As I said in another message, if one starts from a principle and you reach a logical conclusion that is unacceptable to ones believes, the thing to change is not the conclusion, but the principle that logically leads to that conclusion. At least, if one wants to stay consistent. | > | The POV is that | > | | > | class B { typename X }; | > | | > | template< typename X > class Y // 1 | > | : public B // 2 | > | { // 3 | > | ... | > | }; | > | | > | You think that template parameter X is declared in line 1, then | > hidden | > | by the base classes name introduced by line 2, thus non-accessible in | > | line 3, right? You think of the name scopes to nest in the same | > order, | > | do you? | > | > What I think is: If we accept the principle that scopes should nest, | > then we should accept its logical consequences; if don't want to | > accept those logical consequences, then we should abandon the idea | > that scopes nest. Which one do you want to pick? | | As mentioned above, I disagree that these are the | only options. Which "only options"? If you make template-parameters hide members, *then*, you no longer have nesting of scope of the template in the scope of template-parameters. It is not an option :-) | But even if you insist on thinking | in those terms, then there it is still possible | to come up with a mechanism that matches what most | of us expect: Simply consider the base class scope | to enclose the scope of the derived class parameters. Could you elaborate more on this mechanism? Not that it would not "solve" this particular issue, but so that I can see whether it actually works with rest of the rules. | > | This is a reasonable point of view, actually it's the current | > | language's interpretation of the topic, but it's not what I call | > | intuitive. | > | > One major problem is what is defined "intuitive" and when "intuitive" | > is defeated by logic. | | Oh please. I notice you posted to the thread "Opinion | sought on name hiding issue" in comp.lang.c++.moderated. | Except for you, the other dozen participants seem to | have no problem on agreeing what is intuitive. | | See above for what I think is the flaw in your logic. You did not point out a flaw. You thought I was assuming something; which I did not. | > | While it's technically correct, it still feels wrong - at | > | least to me. | > | > If you think it is wrong, while being consistent with first principle, | > then propose a a new first principle. The worst thing to do, I | > believe, is to introduce barnacled hacks that comes from nowhere. | > | > | I see things more from a visibility-point-of-view. I | > | > "scopes nest" is visitbility-point-of-view :-) | > | > | can't see the base class' names at 2, | > | > yet, you see the following | > | > struct A { | > struct iterator { }; | > }; | > | > struct B : A { | > vodi f(iteraror); | > }; | > | > don't you? Or are you proposing that to be ill-formed? | | I also see: | | struct A { typedef int I; }; | struct B: A { | typedef long I; | }; | struct C: B { | I x; // B::I hides A::I | }; Exact. So, at least you agree that the issue has nothing particular to do with templates. As I told you last week, if it is considered important, it should be solved as a general issue, not added as yet another special case to the already overly long list of special cases. | Same with template parameters: They hide the homonyms | in farther scopes. | | > We need general rules on which to decide, we don't need barnacled | > hacks that would appear "intuitive" at a moment when we don't have a | > working definition of "intuitive". | > | > | I have to go back (that is, I | > | have to go one "scope" up) to see the names that are contained. This | > | makes me think of the lines 1 and 2 to be swapped wrt the names they | > | introduce into the scope of 3. To put it another way: The names of B | > | are not declared at 2, and that line 2 is also not like a using | > | declaration, although it might seem similar. | > | | > | If we use Dave's or my POV (and we are not alone ;), the | > advantages of | > | scopes can be used in this example, too. The advantage is a smaller | > | scope to search for a name: If you need to know what a name refers | > to, | > | you just look into the scopes from the inside (nearest scope), to the | > | outside. And it feels more natural to me if the scope of the template | > | parameters is closer than the scope of the class' base(s). | > | > If the scope of the template-parameters should come after the scope | > of base classes -- that is the way I understand you "is closer" -- | > then one would not be able to use template-parameters in base classes. | | And you cannot: You can only use them to _name_ base | classes. Yes, "name" is what I intended. Sorry. Just to be clear: If template-parameters had a scope that comes after the scope etablished by base classes, you could not use them in the naming base classes. | In fact, now that I reflect on it, base | classes are not really "enclosing scopes" of derived | classes. You can simulate the lookup that way, but | you could just as well say that inheritance is a sort | of "base class using-directive" (which is how many | compilers implement it). | | > If you don't agree with the "scopes nest" principle, then propose | > another principle, but please don't label it "intuitive" :-) | | On the contrary: If that what Daniel's intuition says, | he should label it as intuitive. The point is there: according to *his* intuition. Do you see what I mean? What we need is a working definition I can consistently apply to accept of reject conclusions. | > If I were to design a new programming language, I'm not sure I would | > just stick to "scopes nest", but here we're not designing a new | > programming language. IMO, one of the the worst things we can to the | > already complex C++ scope rules, is to come up with yet another | > special scope. At this point of complexity, following logical | > consequences is less evil than "intuitive" hacks where we don't have | > working definition of "intuitive". | | You seem to imply that scope nesting is the only | mechanism that directs C++ name lookup. That is I'm actually implying that scope nesting is the first principle that directs C++ name lookup rule, and things like ADL are local deviations that reserve occasional confusions (I already mentioned that, but since you don't read Boost mailing lists you probably have missed the mention to that deviation). And those deviations are causing many confusions for many people. Two weeks ago, I had a serious discussion on that topic with Bjarne [ any discussions that followed on the CWG reflector were purely coincidental, but the fact he brought up an example he thought should be covered by nesting effect is, I guess, a sign that he thinks, scope nesting guides C++ name lookup rules. That guidance is not full, as examplified by local barnacled rules, but for the most majority part, it is the guiding principle. ] | not the case though (using directives, using | declarations, and ADL don't work that way; inheritance | doesn't really work that way either). Whowever they have been worded to display the effect of nesting scopes (except access-checking for using-declaration at class-scope). | Anyway, as many have pointed out, enabling sound | C++ engineering requires the current situation to | be fixed. As you know (since we have been discussing this issue for some time now), I don't disagree with the idea that something should be done. I disagree on the -specific- suggestion of parallel scope or enclosing scopes being injected into enclosed scopes. Did I disagree that anything should be done, I would not have made the proposal in the first place. -- Gaby

2 1

RE: [boost] FC++ Lambda
by Powell, Gary 17 Feb '04

17 Feb '04

> >> bind(delete_ptr(), _1) > > std::for_each( tests.begin(), tests.end(), delete_ ); > That is nice. I wonder why BLL didn't do this instead of delete_ptr()? *) Because I didn't think about using trailing "_" until I saw Joel use them with spirit. *) And because what to you call delete_array() ? (overload operator[T] ? for delete_ ? (With actually trying to code this:) std::for_each( tests.begin(), tests.end(), delete_[noop] ); Yours, -Gary-

1 0

Doc error on Getting Started page
by Jody Hagins 17 Feb '04

17 Feb '04

On the page (http://www.boost.org/more/getting_started.html) the following text (under the Build/Install section)is inaccurate. There are additional options as supported by Boost.Build and Boost.Jam. Of the additional options perhaps the most imporant is "-sBUILD=<features/variants>" which lets you override what is built by default. The "<features/variants>" value is a list, separated by spaces, of build requests. Features take the form of a tag and a value or values. And variants are single symbolic names for a collection of features. For example the default is to request "debug release <runtime-link>static/dynamic <threading>single/multiple", in which "debug" and "release" are variants, and the rest features with two values each. The main problem is that this is considered (by myself and maybe others) as an example. However, actually issuing this command does not properly build multithreaded code. The jamfiles apparantly interpret "<threading>multi" differently from "<threading>multiple" and we do end up with a "<threading>multiple" set of libraries, but they are not built with threading enabled. To get threading enabled, one must use "<threading>multi" instead. This brings up another issue. Should the jamfiles correctly accept threading attributes which are not properly interpreted? Since I am not a jam expert, and have no idea how difficult this is to fix, I'll leave it alone, and make sure my incantations are properly formed. However, it should be addressed in some form, especially since the official docs even seem a bit confused.

2 2

Serialization16 - xml_oarchive std::string representation
by Robert Ramey 17 Feb '04

17 Feb '04

Jeff Flinn wrote: >Knowing next to nothing about xml, I'm surprised by xml archive file that >I've generated which expresses std::string as in the following example: ><item> > <count>3</count> > <item>65</item> > <item>108</item> > <item>108</item> ></item> >which corresponds to std::string("All") >Is this intended? Is this representation configurable? The demo_file.xml >does not use this representation, rather it generates strings in the form: > <street1>24th Street</street1> >Needless to say the former representation is not very space efficient. For >a text archive of 1.2MB I get an xml archive 21.5MB. Hmmm were you sure to included boost/serialization/string.hpp (or maybe it should be left out). In any case the intention is that strings be automatically represented in a readable way and I would be curious as to how you accidently managed to get around that code. >I am unable to compile(VC7.1) the demo_xml_save project with the following >error: >Compiling... >demo_xml_save.cpp >c:\boost\boost_1_31_0\libs\serialization\example\demo_xml_save.cpp(20) : >fatal error C1055: compiler limit : out of keys This is an issue with the VC 7.1 compiler under the IDE. I had the same thing using VC 7.0 . Its amazing to me they could ship this product without fixing this. I love the MS IDE but it has lots of annoying features of this type. Anyway, this problem doesn't appear when you build with the command line. Also I've had good luck in making it go away by cleaning the projects and rebuilding. If all else fails you can redefine certain macros such as assert with something like: #undef assert #define assert(x) x Which will effectively comment out the asserts which provoke the problem. Robert Ramey

2 1

Boost Lambda Doc Buglet
by Stephan T. Lavavej 17 Feb '04

17 Feb '04

In Table 1 of http://boost.org/libs/lambda/doc/ar01s05.html#sect:construction_and_destruct ion it says: destructor()(pa) pa.->A(), where pa is of type A* That should probably say ~A(). Stephan T. Lavavej http://nuwen.net

2 1

Re: Three questions about the new license
by David Abrahams 17 Feb '04

17 Feb '04

"Diane Cabell" <dcabell(a)law.harvard.edu> writes: > "David Abrahams" <dave(a)boost-consulting.com> wrote: >> >> Diane, I want to clarify something you may have missed: the point in >> question does not concern the Boost license itself, but the way in >> which our source files declare the license to be applicable to them. >> They do not contain a copy of the license, but instead make reference >> to it in a comment, typically: >> >> // Copyright David Abrahams 2004. Use, modification and distribution is >> // subject to 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) > > No, I didn't understand that. > > You could just say > // Copyright David Abrahams 2004 and made available subject to the terms of > 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, that seems less prone to misinterpretation to me also. Would // Copyright David Abrahams 2004. 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) do just as well? It's just just a little less wordy -- "made available subject ot the terms of" sticks in my craw a bit. > (....) >> > David Abrahams wrote: >> > >>(....) >> >> Ugh I don't think we ever considered that "display" would be >> interpreted other than to mean "display publicly". Does that mean >> that in the license: >> >> Permission is hereby granted, free of charge, to any person or >> organization obtaining a copy of the software and accompanying >> documentation covered by this license (the "Software") to use, >> reproduce, display, distribute, execute, and transmit the >> Software, and to prepare derivative works of the Software, and to >> permit third-parties to whom the Software is furnished to do so, >> all subject to the following: >> >> "display" ought to be "display publicly"? > > Yes. But again, private display doesn't require permission, so a > court would likely interpret this to language to mean "public > display." If it went to court, you'd get to testify as to that > intention. So IIUC, changing the license wording isn't critical. We should probably wait 'till a critical issue comes up before making any non-critical changes. >> This is what makes me think you might have missed the fact that "use, >> modification and distribution" isn't in the license itself. The >> suggestion is that "use, modification and distribution" be removed >> from source files to avoid having to repeat all the rights named in >> the license. > > Yes, I did miss that. I think it will be solved by deleting reference to > any specific rights in the comment. Great. >> >> (....) >> >> Sorry, I think I was just bringing up a linguistic technicality. >> >> These are all copyrightable files. The question is whether a *thing* >> >> can be subject to a license, or only actions that might be performed >> >> on that thing. That's why I suggested "licensed under ... " instead >> >> of "subject to ... ". >> > >> > Copyright licenses copying; patents protect operations. Since patent >> > rights were only recently recognized for pure software, the line is >> > not really clear in a lot of cases. Interpretation of the licenses >> > isn't just limited to the linuisitics, however, but looks at the >> > purpose the agreement is trying to accomplish, what people in the >> > trade normally intend to happen in such situations, etc. >> >> I'm not sure how to apply that information to our situation. My >> remark about "subject to" was akin to saying "I think you're using a >> noun as a verb; here's a way to phrase it that avoids grammatical >> problems." > > Then I still don't understand your query. The file is a thing and you are > licensing rights to use the thing. The rights are verbs, permitting people > (or machines) to perform certain activities using the thing. Both of them > are subject to the license. I think we're OK. Maybe Devin has another > perspective. > dc Great, thanks for all your help. -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

Serialization16 - xml_oarchive std::string representation
by Jeff Flinn 17 Feb '04

17 Feb '04

Robert, Knowing next to nothing about xml, I'm surprised by xml archive file that I've generated which expresses std::string as in the following example: <item> <count>3</count> <item>65</item> <item>108</item> <item>108</item> </item> which corresponds to std::string("All") Is this intended? Is this representation configurable? The demo_file.xml does not use this representation, rather it generates strings in the form: <street1>24th Street</street1> Needless to say the former representation is not very space efficient. For a text archive of 1.2MB I get an xml archive 21.5MB. I am unable to compile(VC7.1) the demo_xml_save project with the following error: Compiling... demo_xml_save.cpp c:\boost\boost_1_31_0\libs\serialization\example\demo_xml_save.cpp(20) : fatal error C1055: compiler limit : out of keys Thanks, Jeff

1 0

mistake in filesystem documentation
by Janusz Piwowarski 17 Feb '04

17 Feb '04

Hello In operations.hpp documentation there is boost::maxint_t file_size() instead of boost::intmax_t . Regards, Janusz

2 1

having a variable act as a function call
by Noel Yap 17 Feb '04

17 Feb '04

I'd like to have a variable act as a function call. For example: Foo& getFoo(); foo; // really calls getFoo Is there a boost way to do this? Thanks, Noel -- NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited.

3 3

RE: [boost] Re: Future of threads (III)
by Hurd, Matthew 17 Feb '04

17 Feb '04

> On Behalf Of Matthew Vogt > Allowing the use of asynchronous I/O seems to break the abstraction, which > leaves me wondering why the object should be active? (This is in the > context > of *local* objects, BTW - if the object is remote there is very little > difference between a client/server solution and one using active objects, > is > there?) > > Apologies in advance if I'm not getting something obvious... > > Matt > I think you're confusing the reference to asynch i/o I made, or I'm confused. Recent form would suggest the latter ;-) I was suggesting that a future value is a bit like asynch i/o. I meant that in the sense that with asynch i/o you request something get on with your life and react to it later. A future works like this too, but a little more indirectly, your future is your handler mechanism. You call your function/method which returns a future, say boost::future< double >. When you go to use your future if the value is not yet available then it blocks waiting until it is. If it is available then you use it. This would fit with an active object pattern where the method call returns a result quite nicely, especially if futures where compatible with triggering results on to the queues of other active objects. Though I think the asynch design approach is superior in performance, the semantics of a synchronous approach are often clearer as it looks like a traditional serial program. This would lead to a cute pattern that I haven't seen or thought of before where you get a future value from an active object, but call a method on another active object with that future value ad infinitum and the results just percolate through. :-) Sounds neat but a little impractical I think. The traditional call a method on the Active object and have the results percolate through the pre-allocated workflow of queues and active objects makes a lot more sense. Regards, Matt Hurd _______________________ Susquehanna Pacific P/L hurdm(a)sig.com +61.2.8226.5029 _______________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

2 1

RE: [boost] Re: Re: Future of threads (III)
by Hurd, Matthew 17 Feb '04

17 Feb '04

> On Behalf Of scott > Subject: RE: [boost] Re: Re: Future of threads (III) > Do you guys have any thoughts on how to "get work into" the > class (now that it is truly a running thread)? Cos this is > the essence of what an AO is. I think :-) > > Cheers, > Scott > AO's should either have a queue for work or hook into a queue. They are a bit like a worker pool with one worker ;-) Another idiom is a future value, where you ask for a value and don't block until you "read" the value. ACE also has an implementation of this. You can think of it as a bit like overlapped I/O. I also advocate a different architectural neutral style where you can have things at look like function calls that can be: 1. a function call 2. a call to queue work pool or active object 3. an IPC mechanism for same machine transfer, e.g. shared memory 4. a network mechanism, TCP, UDP, TIB or something, for If it can be enabled by a policy driven approach then you can change the architecture of your application by simply changing policies. I think David Abraham's named parameters could help greatly with this approach, along with the serialization lib for marshalling support. This should provide a solid basis for this. I've also thought that perhaps boost::signals might be the correct approach to take for this but I'm unsure. To support this approach you also need mutex aspects that are also policy driven. I am preparing to submit such locking that builds on the existing mutexes and locks. Regards, Matt Hurd _______________________ Susquehanna Pacific P/L hurdm(a)sig.com +61.2.8226.5029 _______________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

4 5

FW: [boost] Re: Re: Future of threads (III)
by scott 17 Feb '04

17 Feb '04

forwarding to boost on the assumption that it was your intention. apologies if i got that wrong. -----Original Message----- From: scott [mailto:scottw@qbik.com] Sent: Tuesday, February 17, 2004 4:42 PM To: 'Jody Hagins' Subject: RE: [boost] Re: Re: Future of threads (III) > -----Original Message----- > From: Jody Hagins [mailto:jody-boost-011304@atdesk.com] > > > The "typical" (i.e., most commonly implemented) method is to use a > thread-safe message queue, coupled with a condition variable. While > there are messages to be processed, the "active object" pulls > them from > the messages queue, and responds appropriately (the AO > specific logic). > When there are no messages available, the AO sits on the condition > variable, awaiting an indication of the arrival of a new > message. I am > sure you understand this, but I could not figure out any other > interpretation of your question... I was responding to your mentioning of the "future" mechanism. Its a perfectly valid mechanism but I was trying to build a case for an implementation of boost::active_object that would never use it. > > I suggest that notions of "function call" should be exorcised from > > discussions that are targeting active objects. That type of thinking > > is perfectly valid in some other thread (oops) but can scuttle work > > targeting active objects; the behaviour (i.e. the code) is > inherently > > in the object. > > > > a client can only submit "worker orders" or "Method Requests" or > > jobs or messages or signals. > > > > I hope there is enough there to make a case :-) > > > I think what you are saying is right in line with traditional methods > for implementing an AO, but I thought we were trying to find alternate > methods, unless I mistakenly misinterpreted the preceeding > communications. > Well, I've learnt to not take anything I send too seriously. These days I am happy if I get the spelling right. I can imagine that there are many approaches to application of the ActiveObject pattern. What I am trying to do so badly is steer discussions away from certain directions. Technically they may be completely justifiable. Strangely I have seen well intentioned implementations of AOs go down some of these paths and the result is not what anyone wants. And nobody really knows where it wandered off target. Personally I believe that what people (developers) _really_ want is the ability to conveniently right a bunch of code fragments that are executed in response to some event (e.g. reception of a message). The collecton of fragments is "the active object". We want the environment to take care of all the nasties such as multi-threading, temporary storage of messages (queueing), routing of message to code fragment and calling of code (passing parameters from message). I think the most insidious error in previous developments has been the assumption of an equivalence between the message sent and a specific function call. Once this assumption is tossed out, implementation becomes more sane and the result is what was targeted. Or closer anyhow :-) The collection of code fragments is the active object. The collection of messages exchanged is a protocol. Until these concepts are to the fore (rather than synchronous, procedural type concepts) then any implementation of boost::active_object will tread the path that others have. actually i have no doubt it would result in something amazing; just not what i was hoping for in an active object :-) > Drinking is not a spectator sport. Cin cin, Scott

2 1

FC++ Lambda
by Darren Cook 17 Feb '04

17 Feb '04

Hi, I've read the lambda sections of the FC++ docs, and the paper on the subject, and am a bit confused how to use it. Could you show the FC++ equivalents of these BLL examples: 1. (from the paper) int a[]={5,3,8,4}; std::for_each(a,a+4,std::cout<<_1<<"\n"); 2. int a[]={5,3,8,4}; std::for_each(a,a+4,std::cout<<constant("v=")<<_1<<"\n"); 3. (a vector of MyClass pointers) std::for_each( tests.begin(), tests.end(), bind(&MyClass::save,_1,f) ); 4. std::for_each( tests.begin(), tests.end(), bind(delete_ptr(), _1) ); 5. (in a spirit parser) Node= +( (+range_p('A','Z'))[bind(&MyClass::on_name, this, _1,_2)] >> +( ch_p('[') >> (*(anychar_p-']'))[bind(&MyClass::on_value, this, _1,_2)] >> ch_p(']') ) ); Darren *: For each I'm doing something like: #include <boost/lambda/lambda.hpp> #include <boost/lambda/bind.hpp> #include <boost/lambda/construct.hpp> using namespace boost::lambda;

2 3

Boost on tandem
by Hurd, Matthew 17 Feb '04

17 Feb '04

Any experience out there with this? Regards, Matt Hurd IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

1 0

[Boost-bugs] [ boost-Bugs-898333 ] Boost.Build fails with Dev-Cpp
by SourceForge.net 16 Feb '04

16 Feb '04

Bugs item #898333, was opened at 2004-02-16 14:05 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=898333&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Boost.Build fails with Dev-Cpp Initial Comment: Boost.Build fails to build correctly with a bare install of the Dev-Cpp environment (http://www.bloodshed.net/devcpp.html) which is an IDE with a mingw gcc backend. There are two aspects to the problem: 1. Supplying MINGW_INCLUDE_DIRECTORY to bjam does not yield the necessary -isystem directives to the gcc invocations. 2. [More general] The environment-derived path to the archiver executable may contain spaces, but is not escaped when the archiver is invoked. Matt Vogt (mvogt(a)juptech.com) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=898333&group_i… ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re: Three questions about the new license
by David Abrahams 16 Feb '04

16 Feb '04

Diane, I want to clarify something you may have missed: the point in question does not concern the Boost license itself, but the way in which our source files declare the license to be applicable to them. They do not contain a copy of the license, but instead make reference to it in a comment, typically: // Copyright David Abrahams 2004. Use, modification and distribution is // subject to 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) Diane Cabell <dcabell(a)law.harvard.edu> writes: > David Abrahams wrote: > >> Thanks for replying, Diane. >> > (....) >> OK, I think I understand you below, but your wording is a bit >> confusing, so I'll ask for clarification: >> >>>US copyright law only grants the author the right to control public >>> display of the work. >> >> Meaning "the right to control public display of the work is granted >> solely to the author?" > > Meaning, anyone can privately display a work without the author's > permission. There is no copy "right" to control private > displays. [There may be other laws that prevent private display, and > one of them would be the right of the patent owner to prohibit > unauthorized "use" of his invention.] Ugh I don't think we ever considered that "display" would be interpreted other than to mean "display publicly". Does that mean that in the license: Permission is hereby granted, free of charge, to any person or organization obtaining a copy of the software and accompanying documentation covered by this license (the "Software") to use, reproduce, display, distribute, execute, and transmit the Software, and to prepare derivative works of the Software, and to permit third-parties to whom the Software is furnished to do so, all subject to the following: "display" ought to be "display publicly"? >>>See See 17 USC 106 at >>><http://www4.law.cornell.edu/uscode/17/106.html>. Yes, if the right >>>isn't specifically granted, it is not included. >> >> Therefore, the fact that a source file doesn't specifically say that >> "display is subject to the Boost Software License" means that it isn't >> granted at all? The OP was actually concerned that leaving out >> "display" implicitly granted a right to do so. My understanding is >> that it does not. Please confirm/deny. > > Right. Leaving things out does not grant any implied > permission. However (there's always a "however"), it is not necessary > to specifically grant a right to private display [unless there are > patents involved]. I don't think we're concerned about private display. >> This brings up another possible problem, though: if the license >> grants >> certain rights to display, but the source file comment only says that >> "Use, modification, and distribution" are subject to the license, >> perhaps we're failing to grant any display rights. Probably the OP >> was right to suggest that we drop the specific mention of "use, >> modification, and distribution" from source file comments. Even if we >> *are* granting display rights as intended, why risk ambiguity on this >> point? > > It does not grant them, so there is no inconsistency. What is "it"? The license certainly does grant display rights. Are you saying that the part of the license that grants display rights isn't applicable to source files with the comment shown at the top of this message? > If, on the > other hand, you believe that _public_ display should be a right > granted to users We do. > then you should add "public display" everywhere that > you see "use, modification and distribution." This is what makes me think you might have missed the fact that "use, modification and distribution" isn't in the license itself. The suggestion is that "use, modification and distribution" be removed from source files to avoid having to repeat all the rights named in the license. > (....) >>>I'm not sure how you're using the term "file", but you can erase doubt >>>by including it specifically as suggested above. >> >> Sorry, I think I was just bringing up a linguistic technicality. >> These are all copyrightable files. The question is whether a *thing* >> can be subject to a license, or only actions that might be performed >> on that thing. That's why I suggested "licensed under ... " instead >> of "subject to ... ". > > Copyright licenses copying; patents protect operations. Since patent > rights were only recently recognized for pure software, the line is > not really clear in a lot of cases. Interpretation of the licenses > isn't just limited to the linuisitics, however, but looks at the > purpose the agreement is trying to accomplish, what people in the > trade normally intend to happen in such situations, etc. I'm not sure how to apply that information to our situation. My remark about "subject to" was akin to saying "I think you're using a noun as a verb; here's a way to phrase it that avoids grammatical problems." > Diane Cabell > Clinical Program Director > Berkman Center for Internet & Society > Harvard Law School > http://cyber.law.harvard.edu -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

Re: Google links
by Jeff Squyres 16 Feb '04

16 Feb '04

This message was forwarded to the sysadmins of the boost list; Dave asked me to reply here on the list. I am not on the boost list; please CC me on any replies. ---------- Forwarded message ---------- Date: Fri, 13 Feb 2004 16:02:35 -0500 From: David Abrahams <dave(a)boost-consulting.com> Subject: Re: [Osl-sysadmin] Care to respond? On Thu, 12 Feb 2004, David Abrahams wrote: > This showed up on the Boost list... > All the "next in thread" type links I've seen have been internally > consistent. Unfortunately, this renumbering almost certainly means that > external references to the old URL for a given message (e.g. on another > mailing list or newsgroup) will be wrong. From what I've seen of > Google's old links, you usually get a different message, not the one you > expected and not a HTTP 404 for instance. Yup -- definitely an unfortunate side-effect. > It might have been (or still be) a good idea to invalidate completely > the old style URLS to avoid confusion. In consultation with David, we decided not to do this in order to not break all the external (non-search-engine/self-healing) links. > Better still would have been to support both the old and new numberings > in parallel, since you can't know what references exist for the old > URLs. So I thought that we had restored the old numbering, and I thought that Larry (the OSL sysadmin) had checked that. Is there something other than Google (which will eventually fix itself) that is pointing to an incorrect address? -- {+} Jeff Squyres {+} jsquyres(a)osl.iu.edu {+} Research Associate, Open Systems Lab, Indiana University {+} http://www.osl.iu.edu/

3 2

Re: Three questions about the new license
by David Abrahams 16 Feb '04

16 Feb '04

Thanks for replying, Diane. Diane Cabell <dcabell(a)law.harvard.edu> writes: > David Abrahams wrote: > >>>>Do you consider documentation to be software? I don't. >>> >>>No, I don't consider it software either :) I was asking if *in the >>>text of the license* they used the word "Software", with an uppercase >>>'s', as a shortcut for software + docs. That's because it says: >>> >>> Permission is hereby granted, free of charge, to any person or >>> organization obtaining a copy of **the software and accompanying >>> documentation** covered by this license (**the "Software"**) >> >> Now that you remind me, yes, "Software" clearly includes the >> documentation. > > Not always. Often they are treated separately. However, the clause > above ensures that they are both covered. Right. I meant that it clearly includes the documentation **in this case**. >>>>[...] >>>> >>>>>b) IIUC again, the comments we are inserting into source files >>>>> >>>>> >>>>> // Use, modification and distribution are subject to 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) >>>>> >>>>> >>>>> are unnecessarily verbose (and potentially dangerous). >>>> >>>>Care to elaborate on why you think it's dangerous? >>> >>>Potentially. I was just asking. My question was: the file says use, >>>modification and distribution are subject to the license. Taken >>>strictly I may interpret that only this three things are subject to >>>the license (not display, for instance). If, from a legal point of >>>view, "display" isn't one of these three things then I can display the >>>software without even reading the license. OK, I think I understand you below, but your wording is a bit confusing, so I'll ask for clarification: > US copyright law only grants the author the right to control public > display of the work. Meaning "the right to control public display of the work is granted solely to the author?" > See See 17 USC 106 at > <http://www4.law.cornell.edu/uscode/17/106.html>. Yes, if the right > isn't specifically granted, it is not included. Therefore, the fact that a source file doesn't specifically say that "display is subject to the Boost Software License" means that it isn't granted at all? The OP was actually concerned that leaving out "display" implicitly granted a right to do so. My understanding is that it does not. Please confirm/deny. This brings up another possible problem, though: if the license grants certain rights to display, but the source file comment only says that "Use, modification, and distribution" are subject to the license, perhaps we're failing to grant any display rights. Probably the OP was right to suggest that we drop the specific mention of "use, modification, and distribution" from source file comments. Even if we *are* granting display rights as intended, why risk ambiguity on this point? > >>>>One could simply say >>>>> >>>>>// Subject to the Boost Software License, Version 1.0. (See etc. etc.) >>>> >>>>I don't think a _file_ can be subject to a license, can it? The file >>>>just exists. >>> >>>Hmm... I don't know. It seems to me that the file is the *medium* >>>through which a piece of software is distributed. >> If we were to make a change like that one, I'd say "Licensed under >> the >> Boost...", just to avoid any ambiguity. >> > Whether or not any particular file is capable of copyright protection > would depend on what is contained in the file. US law distinguishes > between facts/data (not protected by copyright) and creative > expression (protectable to the extent that it is severable from the > underlying idea). If a file were just an alphabetical list of names > and addresses, it would not be considered copyrightable in the US > because that's just a bare and unoriginal set of statements of fact. > > I'm not sure how you're using the term "file", but you can erase doubt > by including it specifically as suggested above. Sorry, I think I was just bringing up a linguistic technicality. These are all copyrightable files. The question is whether a *thing* can be subject to a license, or only actions that might be performed on that thing. That's why I suggested "licensed under ... " instead of "subject to ... ". -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

shared_from_this() fails when the object was handled by an auto_ptr<object const>
by Ulrich Eckhardt 16 Feb '04

16 Feb '04

Greetings! Firstly, this is not a regression, the behaviour was present in 1.30, too. I have attached a simple program that should demonstrate the behaviour, but the core is these lines, with foo being derived from enable_shared_from_this: // 1 std::auto_ptr<foo> g(new foo); boost::shared_ptr<foo> f(g); // 2 std::auto_ptr<foo> g(new foo); boost::shared_ptr<foo const> f(g); // 3 std::auto_ptr<foo const> g(new foo); boost::shared_ptr<foo const> f(g); In all three cases, I'd expect to be able to call shared_from_this(). However, only the first two cases really work. I think it boils down to the function detail::sp_enable_shared_from_this() in the ctor of shared_ptr<> that takes an auto_ptr<>. I'm not certain if there is a fix for this and what that fix would be, but I think the problem is that the 'right' function is not taken because at one place we have a 'foo' and at the other we have a 'foo const'. BTW: I believe that a conversion from auto_ptr<T> to shared_ptr<T const> doesn't compile on VC6, but I can't test that ATM(I'm not at work). If any kind soul wants to, they could add such a conversion to the regression-tests. Same goes for volatile probably. greetings and thumbs up Ulrich Eckhardt

4 6

Re: [boost] [BGL] Interest in a random-path algorithm.
by Cromwell Enage 16 Feb '04

16 Feb '04

> On a second thought and after a bit of googling, > don't you think that > Propp-Wilson Cycle Popping Random Tree algorithm > would be more efficient ? Actually, I'm looking for more path randomness, but competitive performance/speed is definitely a minimum requirement. > The paper describing the article is at > http://dbwilson.com/ja/ > It is very well explained and > pseudo-code is clear enough to easily implement it > :) I'll read up on it when I get back from the dentist. > Cheers, > Jonathan You too. Cromwell __________________________________ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html

1 0

[BGL] Interest in a random-path algorithm.
by Cromwell Enage 16 Feb '04

16 Feb '04

Hi, everyone. For your informal reviewing pleasure, I've uploaded a random path algorithm with accompanying documentation at <http://groups.yahoo.com/group/boost/files/bgl_algo/make_random_paths.zip> I've stated in an earlier thread that I was working on a multi-state-mazes project. Obviously the ability to create random underlying paths could give the application high reusability value. It's my hope that other developers here will also find use for this algorithm in their own projects. Feedback appreciated! Cromwell Enage __________________________________ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html

2 2

Re: [boost] Re: 1.31.0 regressions
by Reece Dunn 16 Feb '04

16 Feb '04

Aleksey Gurtovoy wrote: >Beman Dawes writes: > > All of our formats are also painfully slow on less than broadband > > connections if you try to drill down to see a specific failure. > >They are slow even on broadband. That page definitely needs to be >split, somehow. Would it not be possible to employ a technique like that used by the DocBook "chunking" stylesheet. This would allow you to have a HTML page for the summary and one for each of the test sets. Regards, Reece _________________________________________________________________ Sign-up for a FREE BT Broadband connection today! http://www.msn.co.uk/specials/btbroadband

4 3

Odd TOC numbering in the BoostBook docs
by Reece Dunn 15 Feb '04

15 Feb '04

If you look at the table of contents for the boost libraries: http://www.boost.org/regression-logs/cs-win32_metacomm/doc/html/index.html there is: 8. The BoostBook Documentation Format Introduction ... I. Boost.Build v2 User Manual 9. How to use this document 10. Installation ... This seems to be a bug in the DocBook numbering system given the current chapter, section, etc layout for the Boost docs. Regards, Reece _________________________________________________________________ Find a cheaper internet access deal - choose one to suit you. http://www.msn.co.uk/internetaccess

2 1

[boostbook] xsltproc using the internet?
by Ronald Garcia 15 Feb '04

15 Feb '04

Howdy, I'm trying to build the boostbook docs. Having looked through the boostbook.jam file, seems like I should get a warning message if any DTDs are going to be fetched over the internet. I set the location of the DTD and XSL files in user-config.jam to values that I *think* are correct. In any case, It appears that the command "xsl-xsltproc" is still fetching some data remotely. A) Should I be receiving a warning about this, or am I misunderstanding the boostbook jamfile B) How exactly do I make it stop? I'm trying to use the docbook-dtd and docbook-xsl information installed on my machine using a package manager (fink). If I incorrectly specify these directories, should I expect an error that specifically points this out, or general "badness" instead? Thanks, ron

3 5

RE: [boost] Re: status of wchar_t support in filesystem::path?
by Hurd, Matthew 15 Feb '04

15 Feb '04

> On Behalf Of Edward Diener > Subject: [boost] Re: status of wchar_t support in filesystem::path? > > Paul Miller wrote: > > I just started using boost recently and it seems excellent so far. > > > > One of the first classes I started using is filesystem::path, with the > > intention to use it portably on Windows, OS X, and Linux. > > > > On Windows and OS X, you can work with paths in Unicode. Presumably > > Linux still works with multi-byte characters. > > > > Is there progres toward a wchar_t-aware path? > <snip> As a philosophy, I consider boost's filesystem to be attempting to offer a portable filesystem ability, rather than being a portable interface to a file system. As it currently stands, without unicode support, it is not much use if you want to be able to deal with arbitrary file and directory names on win32 which is not a handicap if this is not its intention. For example, I could not use it for an archiving program as I must deal with the potential for unicode names and internal stream in files. It does an admirable job of dealing with your own files where you can control the naming. Regards, Matt Hurd _______________________ Susquehanna Pacific P/L hurdm(a)sig.com +61.2.8226.5029 _______________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

1 0

Re: [function] timing trivia
by matt＠finray.com 15 Feb '04

15 Feb '04

"Pavel Vozenilek" wrote in message news:c0nfp0$pp5$1@sea.gmane.org... > > "Hurd, Matthew" <hurdm(a)sig.com> wrote > > > This is an Intel P43.2 I'm running on now and I'm getting output like: > > > > boost function measurements: median time = 250.698 microseconds > > direct in-line: median time = 250.691 microseconds > > > > You see here I look at the median time for boost function and > > direct-inline and see only a 7 ns difference which is probably smaller > > than I can truly measure I suspect... > > > I wrote my own test (the most simple one, call function/boost::fn > in loop and measuring total time). > > The numbers I got give me ~18 microseconds overhead per single > boost::function call (raw call takes ~404 microseconds). > > I use Intel C++ 8.0 plugged in VC6 IDE,, release mode, > Athlon XP 2200+, W2K. > > /Pavel > <snipped code> > ---------------------------------- > > test1() and test2() took each 30-40 seconds. > GetTickCount() resolution is at least 10 milliseconds. Thanks Pavel. I ran your test with vc7.1 in an optimised form as is with the only change being test1 and test1 returning tick2-tick1 as a long. Similar ball park figures for overall run time as you. test1 = 33312 ms test2 = 30625 ms Yep, boost function call based loop is faster. vc7.1, athlon 2800+, xp1a Also the 18 microseconds cost you measured, or roughly 30 microseconds benefit measured with my optimisation settings, can't just be put down to the boost::function difference I think as 18 microseconds is 36,000 cycles at 2 GHz and I don't think boost function could possibly cost that. If I crank the loop down to #define MAX_FN_LOOP 1e2 with 10,000,000 iterations in the test fn's I get test1 = 3578 ms test2 = 3219 ms Still curiously faster. Though the overhead indicated is 3.6 nanoseconds... If I turn my optimisations off for the last case, but still run in release mode I get: test1 = 8594 ms test2 = 8797 ms Which is the way around you'd expect it to be with boost::function being slower given some kind of abstraction penalty. So, I guess the insight is, your mileage may vary, optimisers are strange beasts, benchmarks are often misleading and weird... cliches are cliches. By the way, I have a slightly improved little bench harness that correctly measures emptiness at zero nanoseconds for an instrusive style of benchmark now if you or any one is interested I can email it to you. That is it correctly measures: inline double blank( matt::timer& t ) { double now; t.restart(); now = t.elapsed(); return now; } to be zero ns consistently for me. Thanks again for your numbers Pavel. Regards, Matt Hurd.

2 1

Re: [boost] Re: A VC6 bug in const_reverse_iterator implementation?
by RGProlog＠aol.com 15 Feb '04

15 Feb '04

I am talking about 1.30.2 version of Boost Libraries. I tried the following in the VC6 enviroment: array<int, 3> arr = {{1, 2, 3}}; array<int, 3>::const_iterator ci = arr.begin(); // works fine array<int, 3>::const_reverse_iterator cri = arr.rbegin(); // fails to ompile

1 0

RE: [boost] Re: [function] timing trivia
by Hurd, Matthew 15 Feb '04

15 Feb '04

> On Behalf Of Pavel Vozenilek > Subject: [boost] Re: [function] timing trivia > > > "Matthew Hurd" <matt(a)finray.net> wrote > > [snip boost::function benchmark info] > > > Can't explain it. Boost function can't be faster for the 10 million > loop > by > > more than a millisecond. I see none of this whacky behaviour with > release > > optimized code. > > > Can you post complete test code somewhere? > > /Pavel Probably small enough to post here... (12KB) Open the .sln, compile and run the "test" project and you should see something similar to: This is an Intel P43.2 I'm running on now and I'm getting output like: --------------------------------------------------------------------- quick time before overhead estimate= 393.5650855126686 nanoseconds time including previous console output = 1.157412246893155 milliseconds overhead estimate = 127.8459831920134 nanoseconds quick time after overhead estimation = 95.25779139797076 nanoseconds time including previous console output = 1.160907957159062 milliseconds --------------------------------------------------------------------- new timer for checking static carry --------------------------------------------------------------------- quick time -1.253391992078558 nanoseconds quick time -5.013567968314233 nanoseconds overhead estimate = 127.8459831920134 nanoseconds quick time 2.506783984157143 nanoseconds quick time -5.013567968314233 nanoseconds --------------------------------------------------------------------- check timing jitter on a simple loop --------------------------------------------------------------------- --------------------------------------------------------------------- estimating indirect function call overhead --------------------------------------------------------------------- --------------------------------------------------------------------- boost function measurements --------------------------------------------------------------------- median time = 250.698 microseconds 90% range size = 6.26696 nanoseconds widest range size (max - min) = 149443 nanoseconds minimum time = 250.695 microseconds maximum time = 400.138 microseconds 50% range = (250.695, 250.701) microseconds 50% range size = 6.26696 nanoseconds stop the optimiser eliding garbage = 3.33328e+017 stop the optimiser eliding garbage = 3.33328e+017 --------------------------------------------------------------------- direct in-line --------------------------------------------------------------------- median time = 250.691 microseconds 90% range size = 6.26696 nanoseconds widest range size (max - min) = 29324.4 nanoseconds minimum time = 250.688 microseconds maximum time = 280.013 microseconds 50% range = (250.688, 250.692) microseconds 50% range size = 3.76018 nanoseconds stop the optimiser eliding garbage = 3.33328e+017 stop the optimiser eliding garbage = 3.33328e+017 Press any key to continue . . . You see here I look at the median time for boost function and direct-inline and see only a 7 ns difference which is probably smaller than I can truly measure I suspect... At the top of looper.hpp there is #define MAX_FN_LOOP 1e5 which controls the iterations in the timing loop. If my hacked up untidy code is buggy or if you have some insight I would love to hear about it. Regards, Matt Hurd _______________________ Susquehanna Pacific P/L hurdm(a)sig.com +61.2.8226.5029 _______________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

2 1

Boost Filesystem Build On GCC
by Stephan T. Lavavej 15 Feb '04

15 Feb '04

When Boost Filesystem is built with bjam "-sTOOLS=gcc" or bjam "-sTOOLS=mingw" on MinGW, the resulting static library is a .lib consisting of .obj files. However, it is traditional for gcc to use .a files which consist of .o files. I fix this by hand by renaming the .obj files to .o and then executing ar rvs libboost_filesystem.a *.o , but it would be nice if bjam would get it correctly by itself. Stephan T. Lavavej http://nuwen.net

4 3

[Boost-bugs] [ boost-Bugs-897250 ] boost::mutable_queue constructor with iterators
by SourceForge.net 14 Feb '04

14 Feb '04

Bugs item #897250, was opened at 2004-02-14 22:45 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=897250&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Cromwell Enage (expaler) Assigned to: Nobody/Anonymous (nobody) Summary: boost::mutable_queue constructor with iterators Initial Comment: Constructing a mutable_queue using container.begin() and container.end() causes the elements in container to be inserted twice into the mutable_queue. This is because the mutable_queue's internal container c is first initialized with the same iterators, thus already inserting the elements into c, and then the while loop inserts the elements into c again. Changing c(first, last) to c() in the constructor should fix the bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=897250&group_i… ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

indirect_pmap
by Cromwell Enage 14 Feb '04

14 Feb '04

Does anybody remember (or, is anybody actively) using the indirect_pmap functor class template defined at <boost/pending/indirect_cmp.hpp>? A Google search within the Boost site turned up empty. Sifting through most of the graph source code (haven't yet looked at the detail subfolder) was also fruitless. Nevertheless, my documentation quest continues... Cromwell Enage __________________________________ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html

2 1

future of boost.threads
by Burc Arpat 14 Feb '04

14 Feb '04

i was actually waiting for the rush of the new release to go away to ask this question: i have seen some recent discussions regarding the threads library and from what i gathered there are plans to start working on it again. but, it also seems the original owner of the lib has disappeared from the list here at the petroleum eng. dept. of stanford university, we use boost rather heavily and lately we started into looking parallelization issues. we, of course, would like to use a cross-platform library such as boost.threads but are a bit worried about the future of it so, i guess, the questions are: is there gonna be a new release of boost.threads? if so, are there any plans to change the interface to a degree that it will require significant changes in the user code? with that said, let me also state that, i will be more than glad to give full test support for the library if any changes are being considered burch - - - G. Burc ARPAT Ph.D. Candidate Dept. of Petroleum Engineering Stanford University Stanford, CA 94305 Internet: www.burcarpat.com

17 52

[BGL] [boost-sandbox] make_random_paths
by Cromwell Enage 14 Feb '04

14 Feb '04

<http://groups.yahoo.com/group/boost/files/bgl_algo/make_random_paths.zip> Changes made: * Now uses concept checking. * No more fat from in_edges, cout_utility, etc. * New unit test added. * Documentation mistakes fixed. Cromwell Enage __________________________________ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html

1 0

Building boost::filesystem without bjam
by Joe Gottman 14 Feb '04

14 Feb '04

I just upgraded to boost 1.31. I use filesystem with MSVC 6.0, but I don't use the jamfiles to create my .dsp and .dsw files. I just created simple projects myself. It worked previously, but now when I try to include the filesystem.dll file, I get the error LINK : fatal error LNK1104: cannot open file "libboost_filesystem-vc6-mt-gd-1_31.lib" Do you have any suggestions?

4 4

Got a boost-request email with MyDoom in it...
by Dan W. 14 Feb '04

14 Feb '04

My antivirus killed it so fast I can't remember if it was a, b or c variant. It was appended to the last message, which starts like, ------------------------------ Date: Thu, 12 Feb 2004 08:36:48 +0800 From: kevlin(a)curbralan.com To: boost(a)lists.boost.org Subject: [boost] Mail Transaction Failed Message-ID: <200402120032.i1C0Wq529796(a)heart-of-gold.osl.iu.edu> Content-Type: multipart/mixed; boundary="----=_NextPart_000_0006_642BC3B6.52190D69" MIME-Version: 1.0 Precedence: list Message: 10 This is a multi-part message in MIME format. ------=_NextPart_000_0006_642BC3B6.52190D69 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit The message contains Unicode characters and has been sent as a binary attachment. ------=_NextPart_000_0006_642BC3B6.52190D69 Content-Type: application/octet-stream; name="message.pif" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="message.pif" TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ........................ ------------------------------ I guess the SMTP server doesn't scan what it sends... Not that that I have much of an issue with the spirit of it... ;-) The microsoft server is kind of slow tonight, trying to get all those patches between the DOS cracks... Cheers!

5 8

boost random question
by Neal D. Becker 13 Feb '04

13 Feb '04

For the new random number generators, if I want to share a single underlying uniform random generator, I need to do like so: typedef boost::mt19937 rng_t; rng_t rng; boost::variate_generator<rng_t&, boost::normal_distribution<> > tn (rng, boost::normal_distribution<> (0, sqrt (var))); boost::variate_generator<rng_t&, boost::pnseq_generator<1> > pn (rng, boost::pnseq_generator<1>()); That is, I need to say "rng_t&" for the 1st template param rather than "rng_t". Is this correct? The old rng lib passed the engine by ref in the constructor, but the new one doesn't. Correct?

2 1

RE: RE: Boost Test Framework - log and report files
by "Kåsa, Daniel Roy" 13 Feb '04

13 Feb '04

First of all thank you Gennadiy! I appreciate the speedy response and help. > > 1. I need to have the test log and report written to two > > separate files in xml format. (It would be nice to have a DTD > > of both xml formats) > > Ok. Will do. Will the schema work? Yes it would. You write 'the' schema does it exist? If so where? I am concerned with this because I am trying to provide a well formed set of html reports based upon our regression tests. To do this I need the complete specification of the available tags and their respective attributes. > > I did this by instructing the framework > > with the command line argument: --output_format=XML. Now that > > I had both the log and result report in XML format I needed > > to create two file streams to redirect the output of them to > > each their own file. This was easy to achieve with the log > > using the set_log_stream method, but not so trivial with the > > result report. Calling the singleton of the result report > > before the test framework has initialized my code first calls > > a null pointer crashing the test. How should this be done? > > The documentation states that the interface of the > > unit_test_result does not need to be used directly, but in my > > case where I want a file stream instead of the std::err I > > need to have access to the singleton and preferable in the > > same place I set up the rest of my test suites. > > First of all why would you need to do anything? By default log goes to > std::out and report goes to std::err. Also as you mentioned log output > stream could be reset using set_log_stream method. Very true, I was so busy trying to redirect the output that I didn't even notice this fact (Is this stated in the documentation?) > This should be enough for your purposes As for report output stream it's > actually unit_test_main who is responsible for setting specific stream and > it not configurable at the moment. > > > 2. To achieve pt 1 I needed to edit unit_test_framework.hpp > > (I think). I wanted to add support for my own command line > > argument which would instruct the framework of the two files > > I would like to create. So I thought it would be convenient > > to use the reteive_framework_parameter method to retrieve my > > custom command argument. Sadly enough I noticed that the > > method doesn't return the value assigned to my argument > > unless it is recognized. Is this fair? > > Yes. This is true. reteive_framework_parameter only strips parameters from > command line that it knows about. The > rest you are getting in init function. You could use any method to > retrieve the value needed for you. I will have to, but I it would be convenient to have this as an available service. If it is ever meant that the framework could be customized I would expect support methods of this sort. > Actually CLA support will be the first thing I am going to rework > completely for next release. I think it should address your concern > either. See mailing list for updates. Nice to hear. :) > > Daniel R. Kåsa > > > Gennadiy.

1 0

libs/iterator/doc/iterator_facade.html typo?
by Angus Leeming 13 Feb '04

13 Feb '04

libs/iterator/doc/iterator_facade.html#tutorial-example In the section "Template Arguments for iterator_facade" is the subsection "CategoryOrTraversal". I suspect that should be "CategoryOfTraversal" (s/Or/Of/). The iterator_adapter docs spell it "CategoryOrTraversal" too. Regards, Angus

3 13

RE: [boost] Re: 1.31.0 regressions
by Rozental, Gennadiy 13 Feb '04

13 Feb '04

> > Say a library now covers 100 test cases spread out among five test > > programs. I'd like to see those five programs refactored into one > > program, still covering the 100 test cases. Or even adding more test > > cases. A single program would cut the overhead, including the human > > overhead. Sorry I missed the beginning of the thread: how would having one program help? > There are at least three drawbacks to this approach: > > 1. "something is wrong" is all the information you get from > a failing test. Esp. you'll likely see only one of several > problems related to a failing test program. The next > problem will only become visible after the first problem > has been fixed. This is not necessarily true. If one uses Boost Unit test framework you most probably get all the errors in one shot. > 2. Some tests are known to fail for certain compilers. > If those tests are joined with other tests then we'll > lose information about these other tests. If it runtime errors you could rely on "expected errors" feature. You are right for compile time errors, though one could try to ifdef part of test program. Gennadiy.

3 3

[boostbook] setup documentation minor nit:
by Ronald Garcia 13 Feb '04

13 Feb '04

Howdy, In the documentation for setting up boostbook located at: http://www.boost.org/regression-logs/cs-win32_metacomm/doc/html/boostbook.g… The path "tools/build/new" is mentioned as the location of user-config.jam. It appears that the path has since changed to "tools/build/v2". cheers, ron

2 1

1.31.1 critical update patch?
by David Abrahams 13 Feb '04

13 Feb '04

We need to fix the regressions in 1.31.0 right away. Since I don't have time to manage a release, and nobody else has volunteered to do it, I'd like to suggest that we post a 1.31.1 "critical update" patch for 1.31.0 on the website. This would save us from having to deal with a site update or making new release archives until someone can really devote the attention a full release deserves. Thoughts? -- Dave Abrahams Boost Consulting www.boost-consulting.com

4 3

broken image on the web pages?
by Ronald Garcia 13 Feb '04

13 Feb '04

Howdy, If I go to http://www.boost.org/ and select "Nightly CVS" Under "Documentation", I find a broken image in the top left corner where I would expect to see the Boost logo. I'm presuming that this page is autogenerated from boostbook? Cheers, ron

1 0

Constructing boost::posix_time::ptime from "flat" time?
by charles.crain＠ni.com 13 Feb '04

13 Feb '04

I am having a hard time figuring out how to construct a ptime from a "flat" time (i.e., some number of time units since some epoch) other than a time_t. For instance, we have a lot of software here at work that represents time as a double-precision floating point number of seconds since 1/1/1904 00:00:00 GMT. As you can imagine, any sensible number is bigger than a 32-bit integer. I would like to be able to construct a ptime something like this: ptime p(date(1904, Jan, 1), microsec(boost::int64_t(float64_time * 1000000.0)); ...or even better... ptime p(date(1904, Jan, 1), float64_time); Problem is, it seems the constructors to most time_duration types use longs, even if they use int64's internally. I can't get the above example to work with any time past 12/31/1904 23:24:12, which just happens to be 0x80000000 microseconds past 1/1/1904. Another thing I would like to do is construct a ptime from a Win32 FILETIME, which is an int64 number of 100ns intervals since 1/1/1601. Something like this: ptime p(date(1601, Jan, 1), nanosec(100 * fileTime)); Is there a better way to do this? I am using MSVC 6.0 SP5 with Boost 1.31.0. -Charles

3 5

boost::function & gcc 2.96 problem
by Ralf W. Grosse-Kunstleve 13 Feb '04

13 Feb '04

Because of a problem in boost/function/function_template.hpp Boost.Python in the current CVS HEAD does not compile with gcc 2.96 under RedHat 7.3. Attached is a suggested workaround (tested with gcc 2.96 and EDG 245). Ralf Index: function_base.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/function/function_base.hpp,v retrieving revision 1.72 diff -u -r1.72 function_base.hpp --- function_base.hpp 11 Feb 2004 18:16:55 -0000 1.72 +++ function_base.hpp 12 Feb 2004 22:01:42 -0000 @@ -188,8 +188,10 @@ // The trivial manager does nothing but return the same pointer (if we // are cloning) or return the null pointer (if we are deleting). template<typename F> - inline any_pointer - trivial_manager(any_pointer f, functor_manager_operation_type op) + struct trivial_manager + { + static inline any_pointer + get(any_pointer f, functor_manager_operation_type op) { switch (op) { case clone_functor_tag: return f; @@ -209,6 +211,7 @@ // Clears up a warning with GCC 3.2.3 return make_any_pointer(reinterpret_cast<void*>(0)); } + }; /** * The functor_manager class contains a static function "manage" which Index: function_template.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/function/function_template.hpp,v retrieving revision 1.70 diff -u -r1.70 function_template.hpp --- function_template.hpp 24 Jan 2004 23:31:40 -0000 1.70 +++ function_template.hpp 12 Feb 2004 22:01:42 -0000 @@ -508,7 +508,7 @@ invoker_type; invoker = &invoker_type::invoke; - this->manager = &detail::function::trivial_manager<FunctionObj>; + this->manager = &detail::function::trivial_manager<FunctionObj>::get; this->functor = this->manager( detail::function::make_any_pointer( @@ -529,7 +529,7 @@ >::type invoker_type; invoker = &invoker_type::invoke; - this->manager = &detail::function::trivial_manager<FunctionObj>; + this->manager = &detail::function::trivial_manager<FunctionObj>::get; this->functor = detail::function::make_any_pointer(this); } __________________________________ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html

4 6

Any news about the formal review process re-animation?
by JOAQUIN LOPEZ MU?Z 12 Feb '04

12 Feb '04

Some weeks ago it was discussed in the mailing list how to boost the review process which seemingly had stuck for quite a while. Unfortunately the discussion seemed to fade away with no definitive conclusions. Could it be possible to know what the status of the review queue is? The review schedule page does not seem to have changed since the discussion took place. I'm interested myself because I applied for formal review some time ago. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Re: [boost] Re: 1.31.0 regressions
by Robert Ramey 12 Feb '04

12 Feb '04

Beman Dawes wrote >It comes down to resources. I suppose if people really care about older >compilers, they will be willing to contribute testing. I still think a platform guru would be a useful function. This Person would run the tests on his local resources for a particular Platform and help with issues on that platform. Such a person would Have similar status to that of a library maintainer. >Say a library now covers 100 test cases spread out among five test >programs. I'd like to see those five programs refactored into one program, >still covering the 100 test cases. Or even adding more test cases. A single >program would cut the overhead, including the human overhead. I would strenuously disagree with this idea. In some cases it would result in a truly humongous program. When I included a test of this nature with my submission last year it was criticized for the above reason - rightly so in my opinion. There are lots of other problems besides. Suppose a test case doesn't compile - then none of the other tests are run. I'm still convinced that the problem with the release process is rooted In developer's desire to include features directly into release "heaven" Without having spent time in development "purgatory". Is_abstract and Autolib come to mind. The branch was announced approx 1 november. The autolib document is dated 26 November. Can't someone just monitor the state Of the development tree and when it looks pretty good say "We're branching today - nothing but bug fixes in the release". The current process is so Painful and takes so long that developers feel under pressure to get the Latest great feature in now because if not its going to take 6 months for The next one. Under this proposal, releases could be more frequent and In smaller increments. After all what's the point of running the tests on The development tree on a daily basis if its going to be more or less Bypassed under pressure for a release? Robert Ramey

1 0

A VC6 bug in const_reverse_iterator implementation?
by RGProlog＠aol.com 12 Feb '04

12 Feb '04

I tried to createa const_reverse iterator for the Dynamic Multi Array Library non constant object. It did not work. I then tried the same thing for Boost.Array with the same result. Which made me suspect it was the const_reverse_iterator implementation problem. Any answers? Roman Gitlin

2 1

Lexical_cast improvement not included in 1_31
by Boost 12 Feb '04

12 Feb '04

| Subject: Lexical_cast improvement not included in 1_31 release | | I proposed some time ago an improvement to lexical_cast to | deal with the corner cases where there were insufficient | decimal digits to deal with some float values. For example, | a 'loopback' test should work for any type T and any value l: | | template <typename T> bool test(T l) | { | cout << l << ' '; | string sl = lexical_cast<string>(l); | cout << sl << ' '; | T ll = lexical_cast<T >(sl); | cout << ll << ' ' | << (l == lexical_cast<T>(lexical_cast<string>(l))) | // Convert type T to string and back to T. | << endl; // eg for long 2147483647 2147483647 2147483647 true | return (l == lexical_cast<T>(lexical_cast<string>(l))); | } // test | | The current version fails this test. | | There seemed no dissent at the time to calculating the | significant digits using std::numeric_limits<Target>::digits10 +1. | | But alas my suggestion (below) has not been included in the | latest release. | | lexical_stream() | { | stream.unsetf(std::ios::skipws); | // was: | /*if(std::numeric_limits<Target>::is_specialized) | stream.precision(std::numeric_limits<Target>::digits10 +1 ); | else if(std::numeric_limits<Source>::is_specialized) | stream.precision(std::numeric_limits<Source>::digits10 +1 );*/ | | Suggested: | | // New calculation to give more accurate number of | significant decimal digits: | // 32 significand bits | digits10 = 6 significant_digits10 = 9 | // 53 significand bits | digits10 = 15 significant_digits10 = 17 | // 64 significand bits | digits10 = 18 significant_digits10 = 21 | // 106 significand bits | digits10 = 31 significant_digits10 = 33 | // 113 significand bits | digits10 = 33 significant_digits10 = 36 | // 128 significand bits | digits10 = 38 significant_digits10 = 40 | | if(std::numeric_limits<Target>::is_specialized && | std::numeric_limits<Target>::radix == 2) { | stream.precision(2 + std::numeric_limits<Target>::digits * | 301/1000); } else | if(std::numeric_limits<Source>::is_specialized && | std::numeric_limits<Source>::radix == 2) { | stream.precision(2 + std::numeric_limits<Source>::digits * | 301/1000); } // Else if not specialized or unusual radix then | use default stream precision, probably 6. // All builtin | types, bool, char, integer and floating point, should be | specialized. } // lexical_stream() | | It is also irritating that current version produces a long | list of spurious 'error' messages which can avoided by | inheriting from boost noncopyable (suggested by Reece Dunn). | | What should I do to progress this? | | Prepare a Boost test for lexical_cast using the Boost Test framework? | | Paul | | Paul A Bristow, | Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB | +44 1539 561830 +44 7714 330204 | mailto: pbristow(a)hetp.u-net.com | |

1 0

[indexed_set] release 9 available
by Joaquín Mª López Muñoz 12 Feb '04

12 Feb '04

For those interested in indexed_set, release 9 is available at: http://groups.yahoo.com/group/boost/files/indexed_set.zip the sandbox version is not in sync, it'll be by tomorrow. New features: * Added a new index type called "sequenced", which sorts the elements in the order they were inserted. In fact, sequenced indices mimic the functionality of std::list, which allows to build, for instance, list-like containers with fast lookup (by combining a sequenced index and a non_unique index.) There're no docs about sequenced yet, but an example of use is provided (example 5 in the examples section.) * Added a new section with performance measurements, showing that in general indexed_set does it better wrt to memory and time than handcrafted compositions of containers. * indexed_set works with Boost 1.31.0 (some fixing had to be made because of changes in Boost.Iterator.) * Some internal improvements that do not affect the library interface. To be completed: * For the moment being, sequenced is not documented (save some scattered references to it.) The task is not trivial, because original docs were strictly focused on set-like indices, and large portions of the material will have to be rewritten. BTW, volunteers with skills at writing are most welcome. * Compiler status is outdated. The library has been confirmed to work in GCC 3.3.1, ICC 7.1 and MSVC 6.5. Reports about other compilers appreciated. As always, I'm very much interested in knowing others' comments about the library. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[function] timing trivia
by Matthew Hurd 12 Feb '04

12 Feb '04

Just a note to say thanks for boost::function ;-) Just completed some timings of the cost of a boost function call using a boost::function<void (void)> and a raw function pointer versus inlining the function's code directly into the source. For my circumstances (your mileage may vary): Calling via raw function pointer = 314 microseconds +/- 1 Calling via boost function variable = 328 microseconds +/- 1 Only 14 microseconds of difference. Nice work, I was expecting much more. Regards, Matt Hurd. Note: Optimised VC7.1 output, winXP 1a, Athlon 2800+ (2.09GHz)

3 5

RE: [boost] Re: 1.31.0 regressions
by Rozental, Gennadiy 12 Feb '04

12 Feb '04

> One small addition to the regression presentation that would > help would be a view organized first by library, and then by > OS/compiler. Currently I have to click all over the place to > find the results for a single library. > > Cheers, > Jeremy Second that. Though it will require extra work. Gennadiy.

1 0

<boost/pending/*.hpp> documentation, examples, and bugs.
by Cromwell Enage 12 Feb '04

12 Feb '04

I'm assuming "ground zero" here also means "square one" :) Preliminary documentation and an example program for <boost/pending/indirect_cmp.hpp>, <boost/pending/mutable_queue.hpp>, and <boost/pending/fibonacci_heap.hpp> can be found at: <http://groups.yahoo.com/group/boost/files/pending/> Bugs: The mutable_queue constructor that takes InputIterator arguments is push()-ing each element twice, because the the internal vector c is first initialized with the elements, then each push() in the while loop adds each element into c again. The example program demonstrates this. The fibonacci_heap fails at the first assert() during pop(). More to come! Cromwell Enage __________________________________ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html

1 0

VTL question (sorry if this is slightly off-topic)
by Matt Verona 12 Feb '04

12 Feb '04

Hello, I was reviewing the View Template Library (VTL) - see http://www.zib.de/weiser/vtl/ ... and have a few questions regarding Views as applied to STL Maps. I was also wondering if Boost was planning to eventually provide a VTL-like framework? I'm looking for a type of View that provides read-only access to an STL map, with only const iterators, but also provides limited insertion and removal access as well (as shown below): This new limited View-like map will only allow clients to iterate using const iterators, and also provides only one public insert(const key&) and one erase(const key&) method. These insert and erase member functions need to be implemented as "Template Method Functions", as follows: (see Design Patterns) * Note: these are shown using the latest SGI STL implementation (i.e., the _M_t.insert_unique and _M_t.erase calls) virtual bool preInsert(const value_type&) { return true; } pair<iterator, bool> insert(const value_type& x) { if(preInsert(x) { return _M_t.insert_unique(x); } return make_pair(end(), false); // make compiler happy } virtual bool preErase(const key_type&) { return true; } size_type erase(const key_type& x) { if(preErase(x) { return _M_t.erase(x); } return 0; // make compiler happy } The preInsert and preErase methods are virtual Hook Methods, and derived classes override these to add behavior to the (non-virtual) insert and erase functions.. Another nice addition to this map view would be a const _Tp& operator[](const key_type& k) const function, implemented something like this: const _Tp& operator[](const key_type& k) const { const_iterator i = lower_bound(k); if(i == end() || key_comp(k, (*i).first)) // if i->first is >= k throw SearchError(k); return (*i).second; } * Note: this simple implementation assumes that the key can be converted to a string in the constructor of the SearchError exception object. I have at least three Manager-like (Mediator) classes that can use this pattern (i.e., derived from this Map View class) as well as others that need a vector view with a similar filtered design... Thanks in advance, ~Matt Verona Houston, Texas USA

3 2

RE: [boost] Re: 1.31.0 regressions
by Rozental, Gennadiy 12 Feb '04

12 Feb '04

> What about generating an email to the maintainers of the > corresponding library, which makes sure they will know about > a failed test ... :-) I do not mind. If it will only happened once - when test start failing. Or anytime test status changed. It may be convenient also to notify when kind of error test reports changed, but it's quite difficult to analyze in generic fashion. Gennadiy.

2 1

RE: [boost] Boost Test Framework - log and report files
by Rozental, Gennadiy 12 Feb '04

12 Feb '04

> 1. I need to have the test log and report written to two > separate files in xml format. (It would be nice to have a DTD > of both xml formats) Ok. Will do. Will the schema work? with the command line argument: --output_format=XML. Now that > I had both the log and result report in XML format I needed > to create two file streams to redirect the output of them to > each their own file. This was easy to achieve with the log > using the set_log_stream method, but not so trivial with the > result report. Calling the singleton of the result report > before the test framework has initialized my code first calls > a null pointer crashing the test. How should this be done? > The documentation states that the interface of the > unit_test_result does not need to be used directly, but in my > case where I want a file stream instead of the std::err I > need to have access to the singleton and preferable in the > same place I set up the rest of my test suites. First of all why would you need to do anything? By default log goes to std::out and report goes to std::err. Also as you mentioned log output stream could be reset using set_log_stream method. This should be enough for your purposes As for report output stream it's actually unit_test_main who is responsible for setting specific stream and it not configurable at the moment. > 2. To achieve pt 1 I needed to edit unit_test_framework.hpp > (I think). I wanted to add support for my own command line > argument which would instruct the framework of the two files > I would like to create. So I thought it would be convenient > to use the reteive_framework_parameter method to retrieve my > custom command argument. Sadly enough I noticed that the > method doesn't return the value assigned to my argument > unless it is recognized. Is this fair? Yes. This is true. reteive_framework_parameter only strips parameters from command line that it knows about. The rest you are getting in init function. You could use any method to retrieve the value needed for you. Actually CLA support will be the first thing I am going to rework completely for next release. I think it should address your concern either. See mailing list for updates. > Daniel R. Kåsa > Gennadiy.

1 0

any smart pointer alternative suggestions?
by Trey Jackson 12 Feb '04

12 Feb '04

All, I'm loving the shared_ptr class, however we have one issue that doesn't seem to be addressed by any of boost's smart pointers, and I'm looking for a work-around/alternative. Any help? The issue is that the smart pointers assume the pointer type to be 'T*', which is fine on a 32-bit system, but means that we get a near doubling of run-time size on our application when we move to a 64-bit application. As a result, we're using the standard technique to have a custom heap, and use our own 'pointers' into that heap that are smaller (typically 32-bits). But of course our ClassOnHeapPtr type does not match a 'ClassOnHeap *', so a boost::shared_ptr<ClassOnHeap> won't work. Are there any other libraries you boosters would recommend? thanks for any info... TJ -- Trey Jackson tjackson(a)ichips.intel.com "This is gonna cost me." -- Homer

5 5

Passing value safely to functions
by Michael D. Borghardt 12 Feb '04

12 Feb '04

This started with looking at sign/unsigned interfaces and how to handle range problems. Now this looks to me to handle any numeric conversion problems. Comments, and criticisms welcome. #include <boost/numeric/cast.hpp> template<typename Target> class numeric_class { public: template<typename Source>numeric_class(numeric_class<Source> &s) { value_ = boost::numeric_cast<Target>(s); } template<typename Source>numeric_class(Source s) { value_ = boost::numeric_cast<Target>(s); } numeric_class(Target s) { value_ = s; } template <typename Resultant> operator Resultant() { return boost::numeric_cast<Resultant>(value_); } operator Target() { return value; } private: Target value_; }; void Bar(numeric_class<unsigned long> ul) { // we know that value in ul is in range if we get here } numeric_class<float> Foo(numeric_class<unsigned long> ul) { // we know that value in ul is in range if we get here return numeric_class<float>(ul); } int main () { try { float f = 5.5; numeric_class<unsigned long> ul(f); char c1 = ul; // function interface converts float to unsigned long AND checks to make sure it is in range Bar(f); // function interface converts char to unsigned long AND checks to make sure it is in range // return float that is in range f = Foo(c1); // if we get here we have a valid f } catch(std::exception const &ex) { std::cerr << "EXCEPTION: " << ex.what() << "\n"; } return 0; }

1 0

STL compatible tables
by Arkadiy Vertleyb 12 Feb '04

12 Feb '04

Hi all, I am re-posting this message in hope that the lack of responce is somehow related to incorrect moment I chose for the original post (just hours after 1.31.0 was released). Please indicate if you have any (potential) interest in this library. Thanks, Arkadiy ============================================= Dear Boosters, A while ago we introduced RTL the Relational Template Library a lightweight facility to create relational tables and perform relational operations on them. The main concept RTL operates with is a relation, which has two types of models: tables and operators. Tables can store, in a type safe manner, fields of any types that satisfy requirements imposed by a typical STL container. Operators store references to their arguments, and produce data on the fly. Both provide iterators that can be used in STL algorithms. Any relation (operator or table) can serve as an argument to yet another operator, thus forming an arbitrary complicated expression tree. A relation has a sort order, which is calculated at compile time based on the sort order of its arguments. Range queries are available, based on this sort order. RTL allows to index any relation, which again can be either a table or a relational operator. In this sense our indexing models the ORDERED BY feature, provided by SQL. Therefore a relational expression can contain any number of indexes, used to re-sort tuples to better suite a particular query or queries. The March issue of C/C++ users journal will contain our article about RTL, where we described the library in more depth. This article reflects the state of the library as of about a year ago. NEW FEATURES ============ This time we are offering a significantly enhanced version of the library. The main addition is the TRANSACTION facility, that allows for synchronized updates to one or more tables. The additional very powerful (in our opinion) benefit is the possibility of incremental index update. When a table is changed, all the indexes that depend on this table get invalidated, and need to be updated. RTL takes care of this by calculating deltas on each index, and applying only necessary changes incrementally. We also modified the library interface to use MPL sequences instead of our proprietary type list implementation, and replaced all our meta-programming code to also make use of MPL. RTL allows the user to choose between available table implementations, as well as define new ones. The current in-stock implementation is based on std::vector, and therefore is most appropriate when the updates dont happen too often. We also experimented with indexed_set library to define a set-based implementation. Since the indexed_set is not a part of boost yet, we do not currently supply this implementation. However we do have it, and if anybody has immediate interest, please let us know well make it available (you will have to download the indexed_set library). We struggled to support VC6 up to the last moment, when some of our tests failed to build with Boost release candidate 2. The problems are with quantitative limitations we are getting ISO, and have to brake down our tests in smaller units. Since Microsoft no longer supports this compiler, we also decided to stop supporting it (we may re-consider if there are significant objections). The library has been tested with VC7.1 and GCC 3.3. Here is the link: http://groups.yahoo.com/group/boost/files/tables.zip As always, we are looking forward to any feedback. Arkadiy vertleyb(a)hotmail.com Dmitriy dmitriy_arapov(a)hotmail.com _________________________________________________________________ Plan your next US getaway to one of the super destinations here. http://special.msn.com/local/hotdestinations.armx

6 10

Boost Test Framework - log and report files
by "Kåsa, Daniel Roy" 12 Feb '04

12 Feb '04

I have just downloaded the latest release of boost so that I could start using the Test Framework. I am part of a fairly large project working on complex software. My project feels as though the boost test framework is beginning to become more mature and we interested in applying it to our test procedures. I have been working on a prototype test environment for my project using the test framework and I have come across some minor problems: 1. I need to have the test log and report written to two separate files in xml format. (It would be nice to have a DTD of both xml formats) I did this by instructing the framework with the command line argument: --output_format=XML. Now that I had both the log and result report in XML format I needed to create two file streams to redirect the output of them to each their own file. This was easy to achieve with the log using the set_log_stream method, but not so trivial with the result report. Calling the singleton of the result report before the test framework has initialized my code first calls a null pointer crashing the test. How should this be done? The documentation states that the interface of the unit_test_result does not need to be used directly, but in my case where I want a file stream instead of the std::err I need to have access to the singleton and preferable in the same place I set up the rest of my test suites. 2. To achieve pt 1 I needed to edit unit_test_framework.hpp (I think). I wanted to add support for my own command line argument which would instruct the framework of the two files I would like to create. So I thought it would be convenient to use the reteive_framework_parameter method to retrieve my custom command argument. Sadly enough I noticed that the method doesn't return the value assigned to my argument unless it is recognized. Is this fair? Daniel R. Kåsa

1 0

RE: [boost] Re: Perfect moving (almost)
by Powell, Gary 12 Feb '04

12 Feb '04

-------------------------------- If Rani is right about the reference binding I'd like to find some way to library-ize this idiom, so your "ref" converting constructor will come in handy. BTW, you don't need the other "ref" constructor anymore. -- Dave Abrahams ---------------------------------------------------------------------- Ok, reusing Andrei's mojo name I've got the following working: template <class T> class mojo { protected: struct ref { template<class T2> ref(T2 *rhs) : p(rhs) {} // works if there is a conversion. template<class T2> ref(mojo<T2> *rhs) : p( static_cast<T *>(rhs) ) {} // works if there is a conversion. template<class T2> ref(mojo<T2> &rhs) : p( static_cast<T *>(rhs.p) ) {} // works if there is a conversion. T * p; T *operator->() const { return p; } T *operator&() const { return p; } }; mojo() {} // intended to be derived from. public: // Move stuff operator ref() { return ref(this); } }; struct X : public mojo<X> { .... // non-const rvalue X(mojo<X>::ref rhs) : id(++cnt) , owner(rhs->owner) { std::cout << "MOVE X#" << id << " <== X#" << rhs->id << " owner = " << std::boolalpha << rhs->owner << std::endl; rhs->owner = false; assert(owner); } .... }; struct Y : public X, public mojo<Y> { .... // non-const rvalue Y(mojo<Y>::ref rhs) : X ( &rhs ) , id(++cnt) , owner(rhs->owner) { std::cout << "MOVE Y#" << id << " <== Y#" << rhs->id << " owner = " << std::boolalpha << std::boolalpha << rhs->owner << std::endl; rhs->owner = false; assert(owner); } ... }; struct V : virtual public X, public mojo<V> { .... // non-const rvalue V(mojo<V>::ref rhs) : X( &rhs) , id(++cnt) , owner(rhs->owner) { std::cout << "MOVE V#" << id << " <== V#" << rhs->id << " owner = " << std::boolalpha << rhs->owner << std::endl; rhs->owner = false; assert(owner); } ... }; same for class W. (virtual inheritence) struct U : virtual public V, virtual public W, public mojo { .... // non-const rvalue U(mojo::ref rhs) : X( &rhs ) , V( &rhs ) , W( &rhs ) , id(++cnt) , owner(rhs->owner) { std::cout << "MOVE U#" << id << " <== U#" << rhs->id << " owner = " << std::boolalpha << rhs->owner << std::endl; rhs->owner = false; assert(owner); } ... }; And it all seems to work correctly. IMO it's not too bad of a "library" module. In any case I like using the operator->() as you can stop referencing the pointer "ref.p". And I chose operator &() but perhaps a "get() member fn of mojo is the right thing to do. As to whether to call it mojo or not...well I didn't have another class name in mind. If you don't have mulitiple inheritence you don't have to specify mojo<Type>::ref, so that's nice as well. Anyway I saw Bjarne's call for items on the list, and IMO, this topic deserves it if nothing more than to clarify that its OK. -Gary-

2 1

RE: [boost] Re: Perfect Forwarding (almost)
by Powell, Gary 12 Feb '04

12 Feb '04

> > I must be dense but I'm not seeing how a move function would give us > > the right type. > > > > template<class T> > > ??? move(T &) > > {... } > > > > X( move (*rhs.p) ) // T is a Y > > // calls X copy if move returns T *. > > > > and we need > > > > X ( X::ref) // and X::ref only takes a X * and X::ref > private to X. > > > > What am I missing here? > > That ref doesn't need to be private in X? > > template<class T> rvalue_ref<T> move(T&); > Ok, but then class X has X (rvalue_ref<X> &rhs) Which IMO is no better.. but each to their own. > > ========================================== > > > >>All in all > >>I like it better than the MOJO soln which IMO was much more > >>invasive. > > > > > > What about the MOJO approach seems more invasive to you? > > =========================================== > > Gary > Well you need to modify both the functions you use > and the class. > > And the class requires more modification. > > It's only more modification because you added a whole lot of > assignment > operators, it's not like the generated one will do the right > thing with > the new approach. > > > // Special return type from an object to use it.... > > // test with binary operator + > > ::mojo::fnresult<Y> operator +(Y lhs, Y const &rhs) { > > return lhs; // do the addition here > > } > > > > vs with move.cpp, no special type necessary.... > > Y operator + (Y lhs, Y const &rhs){ > > return lhs; // do the addition here. > > } > > fnresult is only used to work around the rvalue to const& binding > problem. I'm not sure I understand what Rani has been saying, but it > seems like whatever applies here would apply to Mojo as well. > So AFAICT: > if it works with Dave's code, it should work with Mojo. I > might as well > be wrong though. > I think that without using Dave's approach to removing the const T & constructor you have to have all these other MOJO types. Dave's approach does the right thing for non const r-value's returned by functions. Including the operator=() stuff. Without a special Mojo type mojo does not. The beauty of move.cpp is that you only have to modify the class not the functions which you may not have control of. If the question is whether to use inheritence to gain move semantics, I think I answered that already, and it works pretty well. What fails for both of them is that the const &T contructor has to be visible to the compiler even if its not called or used. And whether that is the correct action is the current point of discussion. Yours, -Gary- PS Sorry about the quoting, I dislike the ">"'s with a passion but this email has them for you.

3 2

Re: Units libraries.,.. (long reply)
by Dan W. 12 Feb '04

12 Feb '04

Haven't been around in a while, I was just checking back to the units threads and saw a bit more discussion 'bout adding temperatures, date and time, absolute vs. relative quantities. Now I suddenly saw the light: "absolute" is a relative term... 0.5f * pun_intended(). I will prove this once and for all time with a simple example of a mechanical drawing. If you've been procrastinating setting a monospaced font for viewing messages, procrastinate no more: ____________ V0 = 000 ("datum" line) | __ | / \ | | | -.- V1 = 150 | \__/ | | __ | / \ | | | -.- V2 = 450 | \__/ | | __ | / \ | | | -.- V3 = 750 | \__/ |____________ V4 = 900 (dimensions are in mils (thousands of an inch) ) assert( V4 - V3 == V1 - V0 ); // no problemo assert( V3 - V2 == V2 - V1 ); // no problemo assert( V1 + V2 + V3 >= V4 ); // uhhhh....??? In other words, dimensions that are all measured to the same edge are "absolute" relative to each other. (See I'm no punster?) So far so good. Now, what happens if I have... a = V2 - V1; b = V3 - V1; //NOT V3 - V2, note... Both we might call "relative", since they are both differences between absolutes, right? I should be able to add them right? WRONG!!! assert( a + b >= b ); // DOH!... a and b are both measured from V1, and therefore, relative to each other, they are, again, you guessed it, "absolute". In other words, forget the whole subject. I regret I brought it up in the first place. Leave it for the PhQS (Philosophical Quantities Library). Cheers!

1 0

Mail Transaction Failed
by kevlin＠curbralan.com 12 Feb '04

12 Feb '04

The message contains Unicode characters and has been sent as a binary attachment.

1 0

RE: [boost] Re: Perfect Forwarding (almost)
by Powell, Gary 11 Feb '04

11 Feb '04

Nice. I think we'd implement a "move" function which could handle that explicitly in any real implementation: Y(ref rhs) : X( move(*rhs.p) ) // <== here , id(++cnt) , owner(rhs.p->owner) { std::cout << "MOVE #" << id << " <== #" << rhs.p->id << std::endl; rhs.p->owner = false; assert(owner); } ========================================== Gary > Thank you! I must be dense but I'm not seeing how a move function would give us the right type. template<class T> ??? move(T &) {... } X( move (*rhs.p) ) // T is a Y // calls X copy if move returns T *. and we need X ( X::ref) // and X::ref only takes a X * and X::ref private to X. What am I missing here? ========================================== > All in all > I like it better than the MOJO soln which IMO was much more > invasive. What about the MOJO approach seems more invasive to you? =========================================== Gary > Well you need to modify both the functions you use and the class. And the class requires more modification. class Y : public ::mojo::enabled<Y> { ..... Y &operator=(Y const & rhs) // source is a non const lvalue { using ::std::swap; Y tmp(rhs); tmp.swap(*this); return *this; } Y &operator=(::mojo::temporary<Y> src) // source is a temporary { src->m_ptr.swap(m_ptr); src->release(); return *this; } Y &operator=(::mojo::fnresult<Y> src) // source is a fn result { return operator=(::mojo::temporary<Y>(src)); } ..... }; // Special return type from an object to use it.... // test with binary operator + ::mojo::fnresult<Y> operator +(Y lhs, Y const &rhs) { return lhs; // do the addition here } vs with move.cpp, no special type necessary.... Y operator + (Y lhs, Y const &rhs){ return lhs; // do the addition here. } I have source code that does a similar set of tests with mojo.h as I did for move.cpp if you want to look at it. Yours, -Gary- powellg(a)amazon.com

2 1

RE: [boost] Re: Perfect moving (almost)
by Powell, Gary 11 Feb '04

11 Feb '04

One other thing that makes writing base class and derived classes easier is to add this to the ref struct class X { .... private: struct ref { ref (X *rhs) : p (rhs) {} template<class T> // new ref (T *rhs) : p(rhs) {} // compiles if T is derived from X. X *p; }; ..... }; Then in the derived class you can call: class Y : public X { .... Y(ref rhs) : X (rhs.p) // no cast needed to call X::ref , id(++cnt) , owner(true) { .... } .... }; Anyway the more I play with this the better I like it. Yours, -Gary-

2 1

RE: [boost] VTL question (sorry if this is slightly off-topic)
by Powell, Gary 11 Feb '04

11 Feb '04

Hello, I was reviewing the View Template Library (VTL) - see http://www.zib.de/weiser/vtl/ ... and have a few questions regarding Views as applied to STL Maps. I was also wondering if Boost was planning to eventually provide a VTL-like framework? ---------------------------------- Gary > Yes, I'm planning on using the new Iterator Adaptors and converting the VTL library to use boost. --------------------------- I'm looking for a type of View that provides read-only access to an STL map, with only const iterators, but also provides limited insertion and removal access as well (as shown below): This new limited View-like map will only allow clients to iterate using const iterators, and also provides only one public insert(const key&) and one erase(const key&) method. These insert and erase member functions need to be implemented as "Template Method Functions", as follows: (see Design Patterns) * Note: these are shown using the latest SGI STL implementation (i.e., the _M_t.insert_unique and _M_t.erase calls) virtual bool preInsert(const value_type&) { return true; } pair<iterator, bool> insert(const value_type& x) { if(preInsert(x) { return _M_t.insert_unique(x); } return make_pair(end(), false); // make compiler happy } virtual bool preErase(const key_type&) { return true; } size_type erase(const key_type& x) { if(preErase(x) { return _M_t.erase(x); } return 0; // make compiler happy } The preInsert and preErase methods are virtual Hook Methods, and derived classes override these to add behavior to the (non-virtual) insert and erase functions.. Another nice addition to this map view would be a const _Tp& operator[](const key_type& k) const function, implemented something like this: const _Tp& operator[](const key_type& k) const { const_iterator i = lower_bound(k); if(i == end() || key_comp(k, (*i).first)) // if i->first is >= k throw SearchError(k); return (*i).second; } * Note: this simple implementation assumes that the key can be converted to a string in the constructor of the SearchError exception object. I have at least three Manager-like (Mediator) classes that can use this pattern (i.e., derived from this Map View class) as well as others that need a vector view with a similar filtered design... ---------------------------------------------- Gary > If you are asking me to write this code, well I'm not likely to get around to it. However I'd be glad to review it as an addition to the library. We generally stayed with the STL model of no virtual functions. In the meantime you might like to look at the Iterator Adaptor library and generate your own special view container. -Gary-

2 1

Re: [BGL] Interest in a random-path algorithm.
by Cromwell Enage 11 Feb '04

11 Feb '04

Oh, yeah, I forgot to mention you could use the random path algorithm, too. And thanks for the credit! Cromwell Enage __________________________________ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html

1 0

RE: [boost] Perfect Forwarding (almost)
by Powell, Gary 11 Feb '04

11 Feb '04

Just because I like this sort of stuff, I added a test case with 1 level of inheritence, and it works pretty well. There is a minor amount of trickiness to get the derived class to call the right base class constructor. Just need to remember to use the ref.p. All in all I like it better than the MOJO soln which IMO was much more invasive. (I still like the core soln of adding && to indicate you are taking a move reference though, seems to be less error prone to code IMHO.) tested only on gcc 3.22 (2.93 fails miserably.) Anyway "cool" Dave! Yours, -Gary-

2 1

RE: [boost] Re: future of boost.threads
by Glen Knowles 11 Feb '04

11 Feb '04

From: David Abrahams [mailto:dave@boost-consulting.com] >> Of course you cannot portably pass all exceptions, but you may be able >> to pass all the ones that use standard types. > >And what if the std library or somebody else throws exceptions >*derived* from the standard types? If it is not a recognized corba exception what the ACE TAO does is eat it with a catch(...) and then throws a corba system exception on the other side. Glen

13 35

Boost.Python proposed patch 1.31.0
by John Gerschwitz 11 Feb '04

11 Feb '04

It would appear numeric.cpp has some () missing. This means calls to functions such as nelements fail. The text "isaligned" replaced with "iscontiguous" in iscontiguous call. John Gerschwitz *** numeric.cpp.orig 2004-02-11 10:57:50.000000000 +1000 --- numeric.cpp 2004-02-11 11:00:33.000000000 +1000 *************** *** 226,247 **** bool array_base::isaligned() const { ! return extract<bool>(attr("isaligned")); } bool array_base::iscontiguous() const { ! return extract<bool>(attr("isaligned")); } long array_base::itemsize() const { ! return extract<long>(attr("itemsize")); } long array_base::nelements() const { ! return extract<long>(attr("nelements")); } object array_base::nonzero() const --- 226,247 ---- bool array_base::isaligned() const { ! return extract<bool>(attr("isaligned")()); } bool array_base::iscontiguous() const { ! return extract<bool>(attr("iscontiguous")()); } long array_base::itemsize() const { ! return extract<long>(attr("itemsize")()); } long array_base::nelements() const { ! return extract<long>(attr("nelements")()); } object array_base::nonzero() const

2 1

Re: [boost] Is anyone interested in dynamic multi array libarray
by RGProlog＠aol.com 11 Feb '04

11 Feb '04

Wrote garcia(a)cs.indiana.edu >Greetings, >I am trying to grok what it is you describe, but I am afraid I may be >missing something. Could you explain in what ways >dynamic_multi_array >differs from the arrays in the Boost.MultiArray library? >Thanks Thank you for your interest. The dynamic_multi_array arrays differ from the the arrays in the Boost.MultiArray library in the same way the arrays in the Boost.Dynamic Bitset library differ from the arrays in the std::bitset library; it is dynamic vs. static. Thus the rationale behind the Dynamic Multi Array library is similar to the rationale behind Boost.Dynamic Bitset library. It complimemts the Boost.MultiArray library. The way the Dynamic Multi Array library is implemented is different. The relationship between the components of the Dynamic Myltiarray library, for example, is different. While the coupling between multi_array and multi_array_ref the Boost.Dynamic Bitset library is almost the stongest possible, public inheritance, the relationship between dynamic_multi_array & dynamic_multi_array_ref is the weakest possible. The dynamic_multi_array_ref points to the data initialized and managed by the dynamic_multi_array and that's it. (for the details see documentation once it will become available on the vault.) There is a clear rationale behind this decision. The dynamic_multi_array component does not provide the capacity to hone in on its subviews; the dynamic_multi_array and the dynamic_subarray components do. The dynamic_multi_array is stricly an extension of std::vector into the multi dimensional enviroment. Thus a user who needs just that --- a strict extension of std::vector --- and wants to avoid the performance penalty the subview capacity would incur, he/she can use the the dynamic_multi_array component of the library alone. For those who want it all, though, the rest of the components will do the job. Also, the Dynamic Multi Array library does not define a subview type. Instead, at a meager price of a few numeric assignment, an existing dynamic_multi_array_ref object can be parametrized to act as any subview of the same dimension of the array object it references, and still retain its iterator interface. Also, the Dynamic Multi Array library does not define an analog of the Boost.MultiArray library index_gen facility. In analogy to std::vector whose objects can be both accessed and generated using a single integral type, the dynamic_multi_array object can be constructed and accessed using C++ arrays, boost::arrays, std::vector arrays or any other class that contains a contiguous block of integral data and has a random access interface. I did e-mail to you, and will e-mailt to anyone expressing interest in the Dynamic Multi Array library the library's code untill the day I will be able to put the code on the wault. ---Roman

1 0

Three questions about the new license
by Gennaro Prota 11 Feb '04

11 Feb '04

Sorry, if this has already been discussed before, but a) the new license text says: "The copyright notices in the Software and this entire statement, including the above license grant, this restriction and the following disclaimer, must be included in all copies of the Software". IIUC, "the Software" (with a capital 's') includes documentation. Am I right? b) IIUC again, the comments we are inserting into source files // Use, modification and distribution are subject to 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) are unnecessarily verbose (and potentially dangerous). One could simply say // Subject to the Boost Software License, Version 1.0. (See etc. etc.) That avoids repeating "use, modification and redistribution" which I'm not sure is everything one can do with the Software (I see for instance, that the license talks about "use, *reproduce*, *display*, distribute, execute, and transmit"). Are, legally speaking, "display" and "reproduce" something different from "use"? c) Suppose one wants to redistribute documentation only (for instance, documentation for one library). Is that allowed? The license seems to say that the docs can only _accompany_ the software (with a lowercase 's'). Genny.

2 3

Python 2.3
by Sebastian Henriksen 11 Feb '04

11 Feb '04

I cannot seem to get Boost.Python properly working with version 2.3. I define the root directory correctly, and the version as 2.3 but vc7.1 tries to link to python22.lib instead of python23.lib. How can I solve this? Thanks... --------------------------------- Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online

2 1

Questions about the new license
by Powell, Gary 11 Feb '04

11 Feb '04

I know this is pretty late in the process but also have a couple of questions: #1 I'd prefer that any software I contribute to boost remain "free", as in I don't want someone to add 20 lines of code to a library and then sell it. You can sell the compiled machine code but not the original or the modified source other than to cover duplication and distribution costs. #2 I have worked for a overly restrictive employer who was paranoid that anything anyone might do on their own time might be owned by the employee and not the employee. It would be extremely helpful if the license states clearly that derivatives cannot be owned. I'm all for a company like "Boost Consulting", I think they add plenty of value to the boost community and give back way more than they take from the free software. However greedy companies have been known to take free software, modify it and not return it to the public domain. There of course is no time limit and no way to prevent this from happening but it would be better if the copyright was a copy left. Also all that bit about the liability disclaimers, forget it, you can be sued for anything, at anytime, not withstanding the claim about the liability, it might as well not be there for all the good it will do us. On the other hand it does give us a leg up in the event of a lawsuit, "We claimed it was worthless your honor." Also one should be able to write a book about boost, use part of the documentation without a heap of trouble. But a bound reprint of the documentation is owned by???? In general I support this effort. Perhaps some clarifying statements in the FAQ would be enough to calm my fears. -Gary-

3 2

Copyright on bigint in sandbox
by Richard Peters 11 Feb '04

11 Feb '04

Hello, I'm working on a big integer library, and for outputting the value of the integer to a stream I would like to use the code in the bigint library in the sandbox. Unfortunately, the file containing the code (bigint.hpp) hasn't got a copyright notice. Could I have permission to use that code in my own big integer library? For what it's worth, I'm planning to submit my big integer library to boost eventually. thanks, Richard Peters

2 3

(no subject)
by mark.rodgers＠cadenza.co.nz 11 Feb '04

11 Feb '04

The message cannot be represented in 7-bit ASCII encoding and has been sent as a binary attachment.

1 0

RE: [boost] Re: Questions about the new license
by Glen Knowles 11 Feb '04

11 Feb '04

From: Powell, Gary [mailto:powellg@amazon.com] >>Boost licensing policy aside for a moment, the CPL is your friend. > >I agree. Or course that begs the question why have a special "boost" >license? (Although I understand that not all parties to boost are bound >by the laws of NY State and those of the US. And the USofA has not >signed up for the world court. > >What does it take to include a CPL? a copy of the full text? > >And would including both a CPL AND the boost text corrupt the code to >make it not boost acceptable? If you look at the faq for the CPL: http://www-106.ibm.com/developerworks/library/os-cplfaq.html Points 12 and 18 are problematic. Glen

2 1

Re: [BGL] Interest in a random-path algorithm.
by Cromwell Enage 11 Feb '04

11 Feb '04

> I would like to integrate that algorithm into > QuickGraph, a C# graph library. > <http://www.dotnetwiki.org> > > May I? You may do so. The LSP algorithm for acyclic digraphs (nothing more than a shortest-path algorithm on edges with negative weights) is freely available across the Internet. Cromwell Enage __________________________________ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html

2 1

Is anyone interested in dynamic multi array libarray
by RGProlog＠aol.com 11 Feb '04

11 Feb '04

Is anyone interested in dynamic_multi_array template library that offers user intuitive convenience of use as well as capacity to hone in upon any specific subset of a multi-dimensional array? As an example of usage, a dynamic_multi_array object can be constructed and then resized and then reshaped like this: size_t arrayShape = { 3, 7, 15}; dynamic_multi_array<double, 3> A(arrayShape); boost::array<size_t, 3> anotherArrayShape = {{ 5, 4, 22}}; A.resize(anotherArrayShape); boost::array<size_t, 5> yetAnotherArrayShape = {{ 440, 1, 1, 0, 0}} ; A.reshape(yetAnotherArrayShape); size_t stillAnotherArrayShape[4] = { 22, 10, 2, 11}; A.reshape(stillAnotherArrayShape); The library’s design owes a lot to Andrei Alexandrescu’s ideas. It is based on the data_table helper class template defined as follows: template<typename X> class data_table { … protected: std::vector<X> data_table_ ;}; template<> <value_type> class data_table { … protected: value_type* data_table_ ;}; Then, a sequence of the table class instantiation types is recursively defined and then given a name that is shared in different dimensional contexts as follows: typedef data_table<value_type> data_table_01; ……………………………………………. typedef data_table< data_table_49 > data_table_50 ; class Int2Type<int> { typedef data_table_01 data_table; } …………………………………………… class Int2Type<> <50> { typedef data_table_50 data_table; } Being a recursive template class, the data_table is implemented in a concise code that is mostly about stating a few recursive rules and implementing some access operators and is totally dimension independent. This is the central feature of the design since the user level wrapper class template by virtue of exporting a dimension appropriate data_table instantiation that uses its shared name template <T, size_t i, Allocator> class dynamic_multi_array { ………………………………………. typedef …. class Int2Type ::data_table; } is also implemented in a way that hides all the implementation details, is concise and dimension independent, thus providing user with a great deal of flexibility, syntax safety, and, in case of a new user, a flat learning curve. This is a std::vector based design. The dynamic_multi_array template class, the library’s main component, extends, where appropriate, std::vector capacities, replicates its exception safety guarantees and has std::vector as its back end storage device. The library’s code, documentation including a short tutorial and a few key tests and will be posted in Dynamic Multi Array Folder on boost Files once the issue of available space will be resolved.

3 2

RE: [boost] Re: Questions about the new license
by Powell, Gary 10 Feb '04

10 Feb '04

Ok then, forget it.... If you want to rip off this software you aren't going to ask anyway. No amount of laws is going to prevent it, and there is no money on my side to enforce it even if I thought you were ripping boost off. I'll trust to the wrath of public opinion of those contributors to Boost when they find out, and they will eventually, will be enough. Who would want to work for someone who did that? Not I. Beman, You can add my name to the page which lists those who agree to the new license and can have any of their previously submitted source code modified to use it. Yours, Gary Powell

1 0

Questions about the new license
by Robert Ramey 10 Feb '04

10 Feb '04

Powell, Gary wrote >#1 I'd prefer that any software I contribute to boost remain "free", as in >I don't want someone to add 20 lines of code to a library and then sell it. >You can sell the compiled machine code but not the original or the modified >source other than to cover duplication and distribution costs. Why not? Who cares? >#2 I have worked for a overly restrictive employer who was paranoid that >anything anyone might do on their own time might be owned by the employee >and not the employee. It would be extremely helpful if the license states >clearly that derivatives cannot be owned. Again: why not? As long as the status of the original is unchanged why should anyone care? >I'm all for a company like "Boost Consulting", I think they add plenty of >value to the boost community and give back way more than they take from the >free software. >However greedy companies have been known to take free software, modify it >and not return it to the public domain. Again so what? If this is such a concern, don't contribute it - just sell it yourself. >There of course is no time limit and no way to prevent this from happening >but it would be better if the copyright was a copy left. Nothing wrong with copy left. Its different, but not necessarily better. >Also all that bit about the liability disclaimers, forget it, you can be >sued for anything, at anytime, not withstanding the claim about the >liability, it might as well not be there for all the good it will do us. On >the other hand it does give us a leg up in the event of a lawsuit, "We >claimed it was worthless your honor." With such little faith in the legal system, why are you even concerned About the license at all? >Also one should be able to write a book about boost, use part of the >documentation without a heap of trouble. But a bound reprint of the >documentation is owned by???? Hmmm - a good question. Robert Ramey

1 0

Fwd: [boost] Re: Exceptions as streams
by Geoff Leyland 10 Feb '04

10 Feb '04

On 10/02/2004, at 12:14 PM, Jonathan Turkanis wrote: > "Geoff Leyland" <gley001(a)ec.auckland.ac.nz> wrote in message > news:9EDC4024-5B52-11D8-B48C-000A95DB9BF6@ec.auckland.ac.nz... >> Hi, >> >> Excuse me if this is already somewhere in boost - I haven't managed > to >> find it. Does anyone else think that an exception that you can > write >> to like a stream would be useful? >> ... > > Have you seen > > http://www.boost.org/more/error_handling.html > > particularly item 4 ("Format the what() message o demand"), but also 3 > and 5? > > Jonathan I have now, thanks, and in principle I agree with what it says. I think, though, that not all exceptions are created equal. When I first started using exceptions I wrote an exception class that had static buffers for the data it might need to store, because I thought that exceptions might be thrown in low memory situations. I don't think I have ever seen any of my code throw an out of memory exception. I don't think I've ever seen a string constructor throw. I know that the stream operators could probably throw, but they don't very much compared to the mistakes I make. I have also been down the road of writing loads of little exception classes for different kinds of problem, each containing the relevant fields for the particular type of exception, so that all the data you needed to interpret the exception was available in the public interface of the exception. Needless to say, it was a pain in the ass, and I never wrote any code that interpreted the data in the exception (except to format "what") In my little command line world, the errors I usually get are that people have forgotten a key-value pair in an input file, or they've spelt the path to a plugin wrong. I could print out the problem and try to continue, and inevitably crash. I could print out the problem and exit or assert, but sometimes I'm running hundreds of tests over a few days, and I don't want the damn thing to stop completely in the middle of the night because I've made a mistake configuring one of the tests. So what I do is throw an exception with a readable message. The main program running the test loop can catch these exceptions, store them all up, and print them all out right at the end of the tests, telling me which tests had problems and why, so that they don't get lost in all the other guff the tests are printing out. There are lots of legitimate reasons for throwing lots of types of exceptions, and I'm not implying that throwing some kind of "streamy_exception" is appropriate in all (or even more than a few) places, but it has made my life a lot easier, and made a lot of silly mistakes easier to fix. cheers, Geoff

4 11

Silently ignoring errors (was Re: future of boost.thread s )
by Rob Lievaart 10 Feb '04

10 Feb '04

The discussion drifted away from "should we be able to pass exceptions from one thread to another" to a more general topic of what to in case of unexpected errors. I'd like to put in my $0.02 cents here. While there are cases where the best solution to unexpected errors, is restart a thread, ignore part of the results and pray. I think they are not that common and require explicit programmer action to decide when to pray and when to really give up and abort the program. Catching and silently ignoring an error by default is IMHO the worst possible choice. It should be possible for a programmer to ignore a lot of errors if he wants to, even acces violations in some cases, but I think the default behavior should be for the system to "scream" as as loud as possible if something unexpected happens. So coming back to the boost.threads discussion, if the default behavior for unexpected exceptions was to dump core, or jump into the debugger that seems like a pretty loud scream. (As several others allready pointed out the more information you get in a situation like this the better) When I need other behavior, it should be a conscious decission on my part to handle these unexpected situations, and then they are not really unexpected anymore. Kind regards, Rob Lievaart. <war story> The first example that comes to mind is a system where I spent a week and a half looking for a bug (After several others had tried to find it before me an failed) that had been in the system for wel over a year. The bug caused _allways_ caused an error in the program that was silently ignored. The program worked "perfectly", for a while, untill the harddisks became larger and the amount of free space on customers computer increased. Then it started giving loads of problems. If this error had not been silently ignored, the bug would have been spotted during the first test after it was introduced, and it probably would never have been checked in into the revision control system. </ware story>

2 1

RE: [boost] Re: Questions about the new license
by Powell, Gary 10 Feb '04

10 Feb '04

Boost licensing policy aside for a moment, the CPL is your friend. --------------------------------- I agree. Or course that begs the question why have a special "boost" license? (Although I understand that not all parties to boost are bound by the laws of NY State and those of the US. And the USofA has not signed up for the world court. What does it take to include a CPL? a copy of the full text? And would including both a CPL AND the boost text corrupt the code to make it not boost acceptable? -Gary-

1 0

Re: [boost] [BGL] <boost/pending/*.hpp> documentation
by Cromwell Enage 10 Feb '04

10 Feb '04

Will all the header files mentioned in the TO-DO list stay where they're at once they're polished up? If not, where will their final home(s) be? Cromwell Enage __________________________________ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html

2 1

serialization update for boost-1.31.0?
by Robert Ramey 10 Feb '04

10 Feb '04

Niel Becker wrote: >Is serialization13 the latest? It doesn't seem to build with boost-1.31.0. >Looks like it maybe isn't converted to new iterator adaptors? I'm hoping to upload an updated version in the next couple of days. I Had some difficulties in tracking changes in the release candidates. I'm Chasing a couple of final bugs, and making tweaks for VC 6.0, Intel, And dinkumware. My latest (pretty good) version can be found a www.rrsd.com Its #16, or you can wait a couple of days. Robert Ramey

1 0

Interest in aspect oriented library
by christopher diggins 10 Feb '04

10 Feb '04

Would there be some interest in an Aspect Oriented Programming library amongst Boost users? I have done some preliminary work on creating macros for crosscutting concerns into existing classes at http://www.heron-language.com/aspect-cpp.html and I am wondering if I should continue work on it. Thanks in advance! Christopher Diggins yet another language designer and avid Boost fan http://www.heron-language.com

4 4

RE: [boost] Re: future of boost.threads
by Darryl Green 10 Feb '04

10 Feb '04

> -----Original Message----- > From: Peter Dimov [mailto:pdimov@mmltd.net] [snip] > Now, in C++ functions actually can return either a value or > an exception. > That is, > int f(); > can return an int or throw an exception. Hence, when you > execute that f in a > thread, you should be able later to call > > int thread::join(); > > and it should return whatever f returned. Yes. I think you mentioned this last time exception propogation across threads was discussed, and I agree. I seem to recall that William Kempf was keen to shift the burden of these sorts of things to some form of wrapper/function object (see http://article.gmane.org/gmane.comp.lib.boost.devel/14237) > > Note that you can't add exception marshalling on a higher > level (with the > current interface) because you can't access a thread's state > (to retrieve > its return value or exception) from another thread. Can't some function object wrapper catch and store the exception somewhere other than in the "thread state" for later access from some sort of async call object regardless of the underlying thread implementation? The joining thread would wait on one of these async call objects (ie join). The async call object and the wrapper would have shared access/ownership of the result (exception or return value) storage. What am I missing? Regards Darryl Green. ########################################################################## This e-mail is for the use of the intended recipient(s) only. If you have received this e-mail in error, please notify the sender immediately and then delete it. If you are not the intended recipient, you must not use, disclose or distribute this e-mail without the author's prior permission. We have taken precautions to minimise the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. ##########################################################################

3 2

Access to regression-logs/cs-win32_rc_1_31_0_metacomm?
by Douglas Paul Gregor 10 Feb '04

10 Feb '04

Aleksey, Could we get group-write access to htdocs/regression-logs/cs-win32_rc_1_31_0_metacomm on Sourceforge? We'd like to be able to do a "cvs update" in doc/html, to get the BoostBook makeover into the nightly documentation. Doug

5 6

RE: [boost] Re: future of boost.threads
by Darryl Green 10 Feb '04

10 Feb '04

> -----Original Message----- > From: Stefan Seefeld [mailto:seefeld@sympatico.ca] > > Darryl Green wrote: > > What am I missing? > > to 'catch and store' an exception, i.e. to take it out of its > (C++) call stack, you need a 'virtual constructor' of some sort, > so the exact type is remembered in the clone (which is not just > a slice of a common base class) and can be re-dispatched in > a different context, i.e. the joining thread. I was assuming that all the discussion about how to define the set of exceptions to be caught was about trying to (rather painfully) avoid slicing. The virtual constructor sounds like magic to me, but maybe it is just sufficiently advanced technology. Do you have a trick up your sleeve to actually do this? And how does it relate to whether it can be done without changing the existing boost.thread interface? Thinking about it, I suspect Peter Dimov was thinking of avoiding the virtual constructor by keeping the referenced object alive after the "join". I guess you could do this by blocking in the catch block (ie don't really terminate at all) until the async call object is destroyed. I'm probably still missing something... Regards Darryl. ########################################################################## This e-mail is for the use of the intended recipient(s) only. If you have received this e-mail in error, please notify the sender immediately and then delete it. If you are not the intended recipient, you must not use, disclose or distribute this e-mail without the author's prior permission. We have taken precautions to minimise the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. ##########################################################################

1 0

serialization update for boost-1.31.0?
by Neal Becker 10 Feb '04

10 Feb '04

Is serialization13 the latest? It doesn't seem to build with boost-1.31.0. Looks like it maybe isn't converted to new iterator adaptors?

1 0

RE: [boost] Perfect Forwarding (almost)
by Powell, Gary 10 Feb '04

10 Feb '04

It also seems to work with virtual base classes! (ick!) tested on: gcc 3.2 Yours, -Gary- PS I won't post any more files to the listserv after this one. (promise!)

1 0

RE: [boost] Re: Re: Exceptions as streams
by Reece Dunn 10 Feb '04

10 Feb '04

Jonathan Turkanis wrote: >To me, the ability to write an exception to a stream is unimportant, >since you can just use what(). The ability to write to an exception >class using operator<< has a certain appeal; I would defintely use if >it were free. On the other hand, if the stream operations are only >happening before the exception is thrown, and if you are dealing with >an exception type that already has the ability to hold some text, you >can get the same effect by using a stringstream. I'm not sure it's >worth introducing a new exception class just to save programmers the >trouble of defining a stringstream. Maybe for use in certaint types of >testing it would be helpful. Using a stringstream would be my approach to achieve this affect, but I wonder what would happen if the stream operation generated an exception? E.g. throw( std::ostringstream() << "Error #" << 404 << weberror( 404 )); what if weberror thows an exception? Also, is ostringstream guaranteed not to throw an exception? Throwing an exception during the exception process is not a good idea! Regards, Reece _________________________________________________________________ Stay in touch with absent friends - get MSN Messenger http://www.msn.co.uk/messenger

2 1

Announcement: Upcoming formal review of FC++
by Mat Marcus 10 Feb '04

10 Feb '04

The formal review of fcpp by Brian McNamara and Yannis Smaragdakis will commence on Friday February 13th at 12 noon, PST and and run to Monday, February 23rd, 12 noon PST. The library is currently available at <http://www.cc.gatech.edu/~yannis/fc++/boostpaper/> Here is a brief introduction to the library: FC++ is a library for doing functional programming in C++. The library provides a general framework to support various functional programming aspects, such as higher-order polymorphic functions, currying, lazy evaluation, and lambda. In addition to the framework, FC++ also provides a large library of useful functions and data types. The main utility of the library comes from its ability to implement functional programming designs, especially those which use higher-order polymorphic functions or lazy evaluation in significant ways. The library also contains a number of ancillary components that implement features like currying and lambda for function objects; these features are also useful in their own right. For information about submitting a Formal Review, see <http://www.boost.org/more/formal_review_process.htm> Please try out the library so that you will be prepared to say whether or not you think the library should be accepted by Boost during the upcoming review period next week and why. Compiler notes: This library has been tested with icc7 and with gcc-3.1.1 (and various other gcc-3.x.y versions) on Solaris and Linux. The library is also likely to compile on VC++7.1 and Comeau (prior versions of the library succeeded with these compilers, but this particular snapshot has not been tested with them). The library covers a great deal of the C++ language and thus requires a high degree of standard conformance; compilers like gcc-2.95.x and VC++6 will not be able to compile the library. Getting started: The web page http://www.cc.gatech.edu/~yannis/fc++/boostpaper/ mentions all the basics: The zip file will expand into these subdirectories: fcpp/fcpp/ # the library (.hpp) files fcpp/fcpp_clients/ # the example (.cpp) files Running the examples just involves invoking the complier with the right #include paths; for example, # in the fcpp_clients directory g++ -I/path/to/boost -I../fcpp some_example.cpp There is also a gnu-style Makefile included with the clients (examples), which will compile all of the examples in batch (you will have to edit a tiny bit at the top of the Makefile). The examples in the clients directory are a mix of both (regression-type) tests cases which cover the features of the library and example applications which demonstrate some of the library's utility. The README file in the client directory gives a short explanation of some of the more interesting clients. The documentation at http://www.cc.gatech.edu/~yannis/fc++/boostpaper/ provides a walkthrough and reference for most of the main features of the library. There are also some pointers out to other papers and documentation on the main FC++ web site: http://www.cc.gatech.edu/~yannis/fc++/ Conformance to Boost guidelines: The library meets most of the requirements described at http://www.boost.org/more/lib_guide.htm Here are a few notable exceptions: - the current library headers are too "monolithic"; you #include "prelude.hpp" and suck in all of the library - some of the lambda internals should be rewritten to use MPL rather than hand-rolled metaprogramming code - only a few of the example programs utilize the Boost testing framework (to automate regression testing) Should the library be accepted into Boost, Brian will remedy these deficiencies. (If you notice other major problems along these lines, please bring them to Brian's attention during the review.) The Formal Review manager is Mat Marcus.

1 0

Boost files space on Yahoo Groups nearly full
by Beman Dawes 10 Feb '04

10 Feb '04

The Boost files space on Yahoo Groups nearly full. Please delete files and directories you may have created which are no longer of interest. Thanks, --Beman

1 0

Exceptions as streams
by Geoff Leyland 09 Feb '04

09 Feb '04

Hi, Excuse me if this is already somewhere in boost - I haven't managed to find it. Does anyone else think that an exception that you can write to like a stream would be useful? So that you could go throw streamy_exception() << "Couldn't open the file " << file_name; and then later catch (streamy_exception &s) { std::cerr << "Oops! : " << s; // or std::cerr << "Oops! : " << s.what(); } I have code that does the above - it really isn't very tricky. If there was interest I could tidy it up a bit. It'd probably be even better to use the format library to compose the error message - then translations would become much easier. Cheers, Geoff

2 1

RE: [boost] Re: future of boost.threads
by Hurd, Matthew 09 Feb '04

09 Feb '04

> On Behalf Of David Abrahams > Subject: [boost] Re: future of boost.threads > > Stefan Seefeld <seefeld(a)sympatico.ca> writes: > > > Glen Knowles wrote: > >> From: David Abrahams [mailto:dave@boost-consulting.com] > >> >> Of course you cannot portably pass all exceptions, but you may be > able > >> >> to pass all the ones that use standard types. > >> > > >> >And what if the std library or somebody else throws exceptions > >> >*derived* from the standard types? > >> If it is not a recognized corba exception what the ACE TAO does is > >> eat it with a catch(...) and then throws a corba system exception on > >> the other side. > > > > > > yes, so all exceptions that are allowed to pass have to be explicitely > > declared > > as such. If it is not declared, a special standard exception will be > > thrown (or may be something equivalent to 'unexpected'). If it is > > derived from a declared one, it will be sliced. > > Is everyone convinced that propagating the exception into the joining > thread is the right behavior or even semantically sensible? No. I'm not. Though I do think it makes sense sometimes. Other times, (perhaps most other times for my code??), I think normal unhandled exception behaviour is appropriate. For example, if I have a pool of worker threads it makes no sense to me to have the unhandled exception propagate back. What happens to the other threads happily chewing through work? It should be the responsibility of the worker pool to handle this appropriately. If it was a simple single thread work off load or perhaps a block waiting thread then exception propagation may make sense to me. That is, if I have someone waiting to join() me. What happens if no one wants to join() the fun, where does your exception go? Sometimes a thread might just do its work and shutdown or some such, the semantics of your app might not require a join(). It might be an asynch messaging passing app where program life time is determined by shutdown messages propagating through or some such. I think support for propagating exceptions to support particular use cases and idioms makes sense, but I don't see it as a safe thing for all. Default behaviour should be to blow up and cause the chaos you've asked for within your design. You should have to ask for propagation explicitly where appropriate. I am also completely and utterly convinced that I am fairly ignorant of these matters ;-) Regards, Matt Hurd _______________________ Susquehanna Pacific P/L hurdm(a)sig.com +61.2.8226.5029 _______________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

1 0

RFC: parm_string
by Kevin Atkinson 09 Feb '04

09 Feb '04

Here is a very simple, but extremely useful, class I would like to submit for inclusion for boost: parm_string. parm_string is a special string class that is designed to be used as a parameter for a function that is expecting a string. It will allow either a "const char *" or "string" class to be passed in. It will automatically convert to a "const char *". The string can also be accesses via the "str" method. Usage example: void foo(parm_string s1, parm_string s2) { const char * str0 = s1; size_t sz = s2.size() if (s1 == s2 || s2 == "bar") { ... } } .. string s1 = "..."; foo(s1); const char * s2 = "..."; foo(s2); By using parm_string instead on "const char *" one avoids the need to have to use the c_str() member every time a string is passed into a function. It is also more effect than just using "const char *" as the length information is passed in if it is known. It is also more efferent than just using "const string &" as that will involve creating an unnecessary temporary when a non string object is used. In my experience most functions that require a string as a parameter really only need the value of the string and possibly its length. They don't need the functionally of the full "string" class. Attached is parm_string.hpp and a simpile program parm_string.cpp I use a variant of this class heavily in my programs I find it extremely useful. -- http://kevin.atkinson.dhs.org

2 1

Re: GPL'd doc makefile
by Alexander Terekhov 09 Feb '04

09 Feb '04

Alexander Terekhov wrote: > > David Abrahams wrote: > [...] > > I fear that's right. Maybe I should just rewrite that stuff using > > Boost.Build. Heh, easy, right? > > Fix the Boost Software License first, please. BSL does impose > the reciprocation provision with respect to derivative works > (not imposing an obligation to make the source code available), > but it doesn't really authorize the distribution of derivatives. > > http://www.digital-law-online.info/lpdi1.0/treatise26.html > > --- > if there are different authors, then the copyright owner in any > work has to authorize the MAKING of any further derivative works > AND must approve of any DISTRIBUTION of the work that contains > his material. Unless ownership and distribution rules are > resolved at the time the work is being developed, there could be > problems at a later time. > --- > > http://www.opensource.org/licenses/cpl.php > > --- > a) Subject to the terms of this Agreement, each Contributor > hereby grants Recipient a non-exclusive, worldwide, royalty- > free copyright license to reproduce, PREPARE DERIVATIVE WORKS > of, publicly display, publicly perform, DISTRIBUTE AND > SUBLICENSE the Contribution of such Contributor, if any, AND > SUCH DERIVATIVE WORKS, in source code and object code form. > --- http://article.gmane.org/gmane.comp.lib.boost.user/5072 David Abrahams wrote: [...] > > > Clearly, I may distribute "the Software", but may I distribute > > the derivative work? > > This is the answer from our lawyer, Devin Smith. Sorry it took so > long: > > A programmer who -- with the permission of the copyright holder -- > creates a derivative work based on another work actually owns the > derivative work. So, since the programmer of the derivative work owns > it, there's no need for the owner of the original work to grant that > programmer a license to distribute the derivative work. > > Now, that doesn't mean that the owner of the original work can't put > contractual restrictions on what the programmer of the derivative work > can do with the derivative work. The Boost license, for instance, > requires programmers who develop derivative works to include the Boost > license with non-object code distributions of the derivative work. http://crynwr.com/cgi-bin/ezmlm-cgi?3:mss:7647 ---- >> He also has no rights in the derivative work as a whole - such rights don't >> exist. There is no copyright in the work as a whole, only seperate >> copyrights in the pre-existing work, and in the added work. > > This directly contravenes the text of the statute. No. You have to read §103 carefully. I explain below. > The copyright owner say author here instead of copyright owner, it makes things simpler > of a derivative work is a copyright owner with all the rights of a > copyright owner, Yes. He has copyright in his contribution to the whole work. But he does not have the right to make copies of the whole derivative work that include (parts of) another's original work. > except that he cannot prevent the creation of other > works derivative of the original work but not based on his contribution. §103 in full: "Subject matter of copyright: Compilations and derivative works (a) The subject matter of copyright as specified by section 102 includes compilations and derivative works, but protection for a work employing preexisting material in which copyright subsists does not extend to any part of the work in which such material has been used unlawfully. (b) The copyright in a compilation or derivative work extends only to the material contributed by the author of such work, as distinguished from the preexisting material employed in the work, and does not imply any exclusive right in the preexisting material. The copyright in such work is independent of, and does not affect or enlarge the scope, duration, ownership, or subsistence of, any copyright protection in the preexisting material." You might think that (a) means there is copyright in a compiled or derived work, but it is not necessarily so. If eg a compilation (not the compiled work, but the work of compilation) is not itself an original work os authorship then there is no copyright. The same law applies to derivative works. I agree that that is confusing. What (a) really says is that if you make a derivative work without permission from the copyright holder of the original work then you don't even have copyright in your own work. You might think that (a) says there can be copyright in a compiled or derived work as a whole, but it doesn't. (b) make the overall situation perfectly clear - any copyright in the derived work does not extend beyond the contribution of the author of the derived work. Any preexisting material is unaffected by the new copyright. The only thing the second author has copyright in is his own work. If the second author has to make copies of the original work in order to make copies of the whole derived work (which would usually be the case), he has to have the separate permission of the first author to do so. Only the original author has the right to do that. Permission to make a derivative work does not automatically (or even usually) include permission to make copies of/distribute the original work as part of a whole. ---- And, finally, this is fun: http://crynwr.com/cgi-bin/ezmlm-cgi?3:mss:7651 ---- Alan writes an original computer program. It is 3 lines long. It is called "Hello world". Bob takes Alan's program and replaces line 2. The new program is called "Goodbye asshole". "Goodbye asshole" is a derivative work. If Bob did not have Alan's permission to create a derivative work then he gets no rights at all. If Bob had Alan's permission to create a derivative work then he gets the sole right to distribute line 2. He does not get any right to distribute lines 1 and 3. He cannot distribute "Goodbye asshole" including lines 1 and 3 without separate permission from Alan. ---- regards, alexander. P.S. I just love the unified Boost Software License Version 1.0. ;-) -- http://www.xfree86.org/pipermail/forum/2004-February/001978.html http://www.xfree86.org/pipermail/forum/2004-February/001980.html

1 0

[serialization] crash with save/load binary
by Vladimir Prus 09 Feb '04

09 Feb '04

Robert, the attached program crashes for me, and I can't understand why. There's a class which contains an array and stores/loads that array. When I run the program, I see: Saving 3{3 4 5 6 } Saving 2{2 3 } Read 3{3 4 5 6 } Aborted That is, first object is deserialized correctly, but the second is not. Is there something wrong with my code, or it's a bug in serialization library? Thanks in advance, Volodya

1 1

[BGL] <boost/pending/*.hpp> documentation
by Cromwell Enage 09 Feb '04

09 Feb '04

What's the status of the code/doc polishing for the items in boost/pending? I'd like to help out, especially with: * The queues and heaps: queue.hpp, mutable_queue.hpp, fibonacci_heap.hpp. * disjoint_sets I'm planning on using these classes in my multi-state mazes project. Cromwell Enage __________________________________ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html

2 2

Is the release boost_1_31_0.tar.gz file OK?
by Beman Dawes 09 Feb '04

09 Feb '04

I've had a report that boost_1_31_0.tar.gz gets a checksum error halfway through unzipping. Has anyone else had a problem? Or used the file successfully? --Beman

7 7

Re: [Boost-users] [BGL] Removing vertices and internal properties
by Jeremy Siek 09 Feb '04

09 Feb '04

Hi Frédéric, Could you post a short (but complete) program showing what you are trying to do? Thanks, Jeremy On Feb 9, 2004, at 3:41 AM, Frédéric Mayot wrote: > Hi, > > I have a graph in the form of an adjacency_list with an internal > property. I'm > using vecS for both vertices and edges (and I don't want to use listS). > > When I remove a vertex with remove_vertex(), it seems that my property > map is > invalidated. Can I remove the property (from the map) which > corresponds to the > deleted vertex ? Is there any solution ? > > Thanks. > > Fred > > _______________________________________________ > Boost-users mailing list > Boost-users(a)lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-users > _______________________________________________ Jeremy Siek <jsiek(a)osl.iu.edu> http://www.osl.iu.edu.edu/~jsiek Ph.D. Student, Indiana University Bloomington C++ Booster (http://www.boost.org) Office phone: (812) 856-1820 _______________________________________________

1 0

[BGL] Problems in adjacency_list_io.hpp
by Frédéric Mayot 09 Feb '04

09 Feb '04

Hi, I tried to use adjacency_list_io.hpp functions and I saw a small problem : 2 functions void getSubset ( no_property& p, const no_property& s ); and std::istream& operator >> ( std::istream& in, no_property& ) are not templated and are in a header file ! This prevents me to link my program since I include this header in different compilation units. I added "inline" before the two functions and the problem was solved. Fred

2 1

[Boost-bugs] [ boost-Support Requests-893381 ] problem buildingboost_python.dll from boost V1.31.0
by SourceForge.net 09 Feb '04

09 Feb '04

Support Requests item #893381, was opened at 2004-02-09 05:23 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=893381&group_i… Category: Python Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: David Abrahams (david_abrahams) Summary: problem building boost_python.dll from boost V1.31.0 Initial Comment: hi everybody, when trying to build the boost_python.dll and lib of the new boost 1.31.0 with the visual studio project files (found in: boost/libs/python/build/VisualStudio) (i use MSVC6 ). i get following errors: ../boost/graph/detail/adjacency_list.hpp (lines 1055, 1057) error C2244: 'bidirectional_graph_helper_with_property.... and error C2954: template definitions can't be put into each other ../boost/mem_fn.hpp (line 315) error C2039: 'dm' no element of '_mfi' i had no problem building those files in boost 1.30.2: 0 errors 0 warnings (my genuine respect here!!) did anyone come across the same problem and solved it? by the way i couldn't build the dlls (neither from 1.30.2 nor 1.31.0) with the stlport (i use stlport 4.6.1). is there any possibility to do that? i get the errors "fprintf" not in _STL and "strcmp" not in _STL could you please help me ? with my best regards oliver ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=893381&group_i… ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re: BGL random algorithms and Boost.Random number generators.
by Cromwell Enage 09 Feb '04

09 Feb '04

Oops, forgot to check the docs! I'll update my code right away! Cromwell __________________________________ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html

1 0

mpl functions, pow_, root_, reciprocal
by Andy Little 09 Feb '04

09 Feb '04

Hi, Following preliminary ok of "pow" mpl metafunction by Alexey Gurtovoy... Here are some basic headers for mpl functions pow_, root_ and reciprocal. useage: boost::mpl::pow_<type,exponent>::type boost::mpl::root_<type,exponent>::type boost::mpl::reciprocal<type>::type Obvious type for the type and exponent is a static_rational type. For pow_ param order is same as runtime std::pow(x,y) , "root_" follows logically from pow_ .... but obviously ... pow_ could do the job) reciprocal also useful to represent 1/ type. I don't know enough mpl yet to provide generic examples except using the pqs types. If anyone else wants to have a go...? And of course docs :-) . Otherwise will get on with it asap. Feedback welcome. regards Andy Little ---------------------------------------------------------------- headers: #ifndef BOOST_MPL_POW_HPP_INCLUDED #define BOOST_MPL_POW_HPP_INCLUDED namespace boost { namespace mpl{ template <typename Type, typename Power> struct pow_ { typedef implementation_defined type }; }} //boost::mpl #endif //----------------- #ifndef BOOST_MPL_ROOT_HPP_INCLUDED #define BOOST_MPL_ROOT_HPP_INCLUDED namespace boost { namespace mpl{ template <typename Type, typename Power> struct root_ { typedef implementation_defined type; }; }} //boost::mpl #endif //----------------------------------- #ifndef BOOST_MPL_RECIPROCAL_HPP_INCLUDED #define BOOST_MPL_RECIPROCAL_HPP_INCLUDED namespace boost { namespace mpl{ template <typename Type> struct reciprocal{ typedef implementation_defined type; }; }} //boost::mpl #endif

6 30

[MPL, TypeTraits] Absurd template nesting on GCC 2.95
by Jonathan Turkanis 09 Feb '04

09 Feb '04

Hi all, I'm working on some code which if naively implemented would involve deep template nesting. Since I can't get a version using MPL algorithms to work on BCC 5.5.1 or VC6 , I wrote out the algorithm with hand-coded loop unrolling. It worked beautifully on a whole bunch of compilers, but when I tried it on GCC 2.95 I found I had to set the template nesting depth to 34 to get it to compile. The same code worked on GCC 3.2 with the depth restricted to 11. After making a few changes, I got the depth on GCC 2.95 (and 3.2) down to 7. One of the changes I made was to switch from using is_based_and_derived to a hand-rolled version restricted to a particular base type. This last change eliminated 11 levels of nesting on GCC 2.95 and 4 on GCC 3.2, although is_based_and_derived had been used in only one place, with fairly simple types, at the center of the algorithm. So I am wondering: is GCC 2.9x known to to be wasteful with respect to template nesting? Also, are the workarounds for GCC 2.9x in Type Traits or MPL known to add a lot of extra template nesting? Jonathan

2 2

BGL random algorithms and Boost.Random number generators.
by Cromwell Enage 08 Feb '04

08 Feb '04

The boost::uniform_int random number generator in Boost.Random was compatible with the BGL random algorithms in version 1.30.2 but can no longer be directly passed to them in version 1.31.0. Should I work around this issue, as I'm currently doing, or will there be some sort of fix? TIA! Cromwell Enage __________________________________ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html

2 1

function (object) return and argument metafunctions?
by David Abrahams 08 Feb '04

08 Feb '04

Hi, I know we've discussed this in the past, but did we ever settle on an interface for deducing the return and parameter types of function (object)s? Doug G.'s result_of<F(a,b)> template works for return types, but it's not very portable and is not even in Boost proper AFAIK. Many function objects and all function pointers have specific (non-templated) parameter types, and it would be extremely valuable to be able to deduce those as well. It's hard to believe that with all the functional programming libraries we have, there's no standardized facility for this sort of deduction. -- Dave Abrahams Boost Consulting www.boost-consulting.com

6 8

RE: [boost] future of boost.threads
by Bennett, Patrick 08 Feb '04

08 Feb '04

Honestly, I'd suggest you just use ACE for threading/synchronization primitives. It's available for a large number of platforms and is heavily used and frequently updated. I like Boost a lot, but I think some people are trying to make Boost more than (IMO) it should be. People discussing efficient io dispatch techniques for example would be better served to just use ACE, which already does many of these things extremely well. (http://www.cs.wustl.edu/~schmidt/ACE.html) Just my (possibly unwanted) $.02. Patrick -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Burc Arpat Sent: Thursday, February 05, 2004 5:14 AM To: boost(a)lists.boost.org Subject: [boost] future of boost.threads i was actually waiting for the rush of the new release to go away to ask this question: i have seen some recent discussions regarding the threads library and from what i gathered there are plans to start working on it again. but, it also seems the original owner of the lib has disappeared from the list here at the petroleum eng. dept. of stanford university, we use boost rather heavily and lately we started into looking parallelization issues. we, of course, would like to use a cross-platform library such as boost.threads but are a bit worried about the future of it so, i guess, the questions are: is there gonna be a new release of boost.threads? if so, are there any plans to change the interface to a degree that it will require significant changes in the user code? with that said, let me also state that, i will be more than glad to give full test support for the library if any changes are being considered burch

4 4

Slight problem testing BOOST_STATIC_ASSERT
by Daryle Walker 08 Feb '04

08 Feb '04

Maybe I missed something in my quick glance.... I just downloaded Boost 1.31.0, and took random looks/comparisons at some of the files. The test files for BOOST_STATIC_ASSERT have something like: BOOST_STATIC_ASSERT( sizeof(int) == sizeof(char) ) // should fail Whoever wrote this should know that platforms that have EVERY built-in type be the same size are allowed! The only guarantee for size differences would be to use "T" v. "T[L]" or "T[N]" v. "T[M]", where N and M are different compile-time constants and L cannot be 1. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

2 1

gcc on win32: RC_1_31_0
by Johannes Brunen 08 Feb '04

08 Feb '04

Hi, can anyone please tell me the status of the following gcc failures on win32 RC_1_31_0: date_time testmicrosec_time_clock integer cstdint_test iterator interoperable_fail math octobion_test math quaternion_test test error_handling_test Won't these errors be solved for the upcomming release? I can't found any tests of spirit and mpl for the win32 gcc (mingw) platform. Aren't there any? It would be fine to have a regression table of all boost libraries for a particular platform. With kind regards Johannes

6 13

[regression][regex] regex_timer.test hangs
by Ronald Garcia 08 Feb '04

08 Feb '04

Hi, I'm running the boost regression tests using a modified "run_tests.sh" on a Windows XP machine using cygwin, and it seems that one of the tests, regex_timer.test hangs. This has happened for both "msvc" and "vc7" toolsets. I'm curious if anyone else has run into this and what may be the possible fix. Having looked at the actual program run, I found that I can make regression testing continue by typing "quit" and enter, which I presume the program takes as input at that point. Any hints on this would be helpful. ron

2 1

[function] bug in docs?
by Angus Leeming 08 Feb '04

08 Feb '04

doc/html/class.boost.function_base.html 1. bool empty() const; Returns: true if this has a target, and false otherwise. Throws: Will not throw. Surely it returns true if the boost::function var has *no* target? Regards, Angus

2 1

Re: future of boost.threads
by Burc Arpat 07 Feb '04

07 Feb '04

patrick, thanx for the suggestion. i am actually a fan of ace myself and i have happily used it before the problem is: nowadays it is becoming more and more common for non-cs depts. to try and write reusable, near-commercial quality code. this is true at least for some major private universities that i know of. that typically happens because companies who supply research funds expect to see software that is immediately useful, not just proof of concept coding. in other words, we are supposed to deliver quality scientific c++ libraries and software that implements all the research that's going on in the dept. given that, sticking with a single 3rd party library for such fundamental tools makes sense for several reasons: (1) when a new student arrives, you tell him/her to go to boost.org and start reading and that's the only burden. you don't also say, "oh, also read about ace, etc.". these people do not need to be very fluent in c++ ( remember, we are talking about non-cs engineering students ) so it's only confusing to force them to use different interface styles. boost interfaces sometimes vary to but at least the overall 'feel' of them is unified and in sync with the standard library (2) when a company wants to use the code, they only need to download and compile boost and our code and nothing else. the less 3rd party dependency, the better (3) and, finally, it is much easier to justify the use of boost than any other library out there. i can simply say "some of their sub-libraries are gonna make it to the next standard" and "they have c++ standards committee members on board" and will persuade even the biggest anti-open-source zealot for the above reasons, we prefer to use a boost sub-library whenever we can rather than using some other 3rd party library regardless of how high quality it might be. 'hope this explains the situation ... everyone, thanks for the responses. i guess, this means, i can start using the lib and then incorporating the changes is not gonna be a big problem. great! one question, though: i understand thread cancellation is gonna be one of the topics to work on. to be honest, it is gonna be quite important for us in the future. do you think it will be safe to say at least an alpha level work on this issue will be available within the next 6 months? although i don't consider myself a threading guru, as i mentioned before, i'll help out as much as i can towards such a goal burch Bennett, Patrick <Patrick.Bennett <at> inin.com> writes: > > Honestly, I'd suggest you just use ACE for threading/synchronization > primitives. It's available for a large number of platforms and is > heavily used and frequently updated. > I like Boost a lot, but I think some people are trying to make Boost > more than (IMO) it should be. People discussing efficient io dispatch > techniques for example would be better served to just use ACE, which > already does many of these things extremely well. > (http://www.cs.wustl.edu/~schmidt/ACE.html) > > Just my (possibly unwanted) $.02. > > Patrick

11 13

Re: [boost] Is the release boost_1_31_0.tar.gz file OK?
by Reece Dunn 07 Feb '04

07 Feb '04

Douglas Gregor wrote: >On Saturday 07 February 2004 09:30 am, Beman Dawes wrote: > > I've had a report that boost_1_31_0.tar.gz gets a checksum error halfway > > through unzipping. > > > > Has anyone else had a problem? Or used the file successfully? > >Works for me. I get the problem. I am using WinXP SP2 with a current version of cygwin and bzip2 version: bzip2, a block-sorting file compressor. Version 1.0.2, 30-Dec-2001. but have replicated the error with WinRAR. Using bzip2 -tvv I get: boost_1_31_0.tar.bz2: [1: huff+mtf rt+rld] [2: huff+mtf rt+rld] [3: huff+mtf rt+rld] [4: huff+mtf rt+rld] [5: huff+mtf rt+rld] [6: huff+mtf rt+rld] [7: huff+mtf rt+rld] [8: huff+mtf rt+rld] [9: huff+mtf rt+rld] [10: huff+mtf rt+rld] [11: huff+mtf rt+rld] [12: huff+mtf rt+rld] [13: huff+mtf rt+rld] [14: huff+mtf rt+rld] [15: huff+mtf rt+rld] [16: huff+mtf rt+rld] [17: huff+mtf rt+rld] [18: huff+mtf rt+rld] [19: huff+mtf rt+rld] [20: huff+mtf rt+rld] [21: huff+mtf rt+rld] [22: huff+mtf rt+rld] [23: huff+mtf rt+rld] [24: huff+mtf rt+rld] [25: huff+mtf rt+rld] [26: huff+mtf rt+rld] [27: huff+mtf rt+rld] [28: huff+mtf rt+rld] [29: huff+mtf rt+rld] [30: huff+mtf rt+rld] [31: huff+mtf rt+rld] [32: huff+mtf rt+rld] [33: huff+mtf rt+rld] [34: huff+mtf file ends unexpectedly Is this a Windows problem? Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

2 1

[regression] run_tests.sh: support for paths with spaces
by Ronald Garcia 07 Feb '04

07 Feb '04

Howdy, I have attached to this message a patch to run_tests.sh to support running the script when some of the paths have spaces in them. It turns out when running this script under cygwin, some of the Windows paths involved have spaces in them, resulting in errors. The fix involves placing in double quotes any variable referring to a path. If this patch seems okay, I would like to commit the changes, unless someone else would like the honors. Cheers, ron Index: run_tests.sh =================================================================== RCS file: /cvsroot/boost/boost/tools/regression/run_tests.sh,v retrieving revision 1.6 diff -u -r1.6 run_tests.sh --- run_tests.sh 26 May 2003 12:01:36 -0000 1.6 +++ run_tests.sh 7 Feb 2004 19:35:11 -0000 @@ -15,7 +15,7 @@ # This can be either a non-exitent directory or an already complete Boost # source tree. # -boost_root=$HOME/CVSROOTs/Boost/boost_regression +boost_root="$HOME/CVSROOTs/Boost/boost_regression" # # Wether to fetch the most current Boost code from CVS (yes/no): @@ -45,7 +45,7 @@ # "comment_path" is the path to an html-file describing the test environment. # The content of this file will be embedded in the status pages being produced. # -comment_path=$boost_root/../regression_comment.html +comment_path="$boost_root/../regression_comment.html" ### DEFAULTS ARE OK FOR THESE. @@ -63,20 +63,20 @@ # The location of the binary for running bjam. The default should work # under most circumstances. # -bjam=$boost_root/tools/build/jam_src/bin/bjam$exe_suffix +bjam="$boost_root/tools/build/jam_src/bin/bjam$exe_suffix" # # "process_jam_log", and "compiler_status" paths to built helper programs: # The location of the executables of the regression help programs. These # are built locally so the default should work in most situations. # -process_jam_log=$boost_root/tools/regression/build/run/process_jam_log$exe_suffix -compiler_status=$boost_root/tools/regression/build/run/compiler_status$exe_suffix +process_jam_log="$boost_root/tools/regression/build/run/process_jam_log$exe_suffix" +compiler_status="$boost_root/tools/regression/build/run/compiler_status$exe_suffix" # # "boost_build_path" can point to additional locations to find toolset files. # -boost_build_path=$HOME/.boost-build +boost_build_path="$HOME/.boost-build" ### NO MORE CONFIGURABLE PARTS. @@ -84,16 +84,16 @@ # # Some setup. # -boost_dir=`basename $boost_root` -export BOOST_BUILD_PATH=$boost_build_path $BOOST_BUILD_PATH +boost_dir=`basename "$boost_root"` +export BOOST_BUILD_PATH="$boost_build_path" "$BOOST_BUILD_PATH" # # STEP 0: # # Get the source code: # -if test ! -d $boost_root ; then - mkdir -p $boost_root +if test ! -d "$boost_root" ; then + mkdir -p "$boost_root" if test $? -ne 0 ; then echo "creation of $boost_root directory failed." exit 256 @@ -101,13 +101,13 @@ fi if test $cvs_update = yes ; then echo fetching Boost: - echo "/1 :pserver:anonymous@cvs.sourceforge.net:2401/cvsroot/boost A" >> $HOME/.cvspass - cat $HOME/.cvspass | sort | uniq > $HOME/.cvspass - cd `dirname $boost_root` + echo "/1 :pserver:anonymous@cvs.sourceforge.net:2401/cvsroot/boost A" >> "$HOME/.cvspass" + cat "$HOME/.cvspass" | sort | uniq > "$HOME/.cvspass" + cd `dirname "$boost_root"` if test -f boost/CVS/Root ; then - cvs -z3 -d `cat $boost_dir/CVS/Root` co -d $boost_dir boost + cvs -z3 -d `cat "$boost_dir/CVS/Root"` co -d "$boost_dir" boost else - cvs -z3 -d :pserver:anonymous@cvs.sourceforge.net:2401/cvsroot/boost co -d $boost_dir boost + cvs -z3 -d :pserver:anonymous@cvs.sourceforge.net:2401/cvsroot/boost co -d "$boost_dir" boost fi fi @@ -116,7 +116,7 @@ # rebuild bjam if required: # echo building bjam: -cd $boost_root/tools/build/jam_src && \ +cd "$boost_root/tools/build/jam_src" && \ LOCATE_TARGET=bin sh ./build.sh if test $? != 0 ; then echo "bjam build failed." @@ -128,8 +128,8 @@ # rebuild the regression test helper programs if required: # echo building regression test helper programs: -cd $boost_root/tools/regression/build && \ -$bjam -sTOOLS=$toolset -sBUILD=release run +cd "$boost_root/tools/regression/build" && \ +"$bjam" -sTOOLS=$toolset -sBUILD=release run if test $? != 0 ; then echo "helper program build failed." exit 256 @@ -146,15 +146,15 @@ # run the regression tests: # echo running the $tool regression tests: -cd $boost_root/status -$bjam -sTOOLS=$tool --dump-tests test 2>&1 | tee regress.log +cd "$boost_root/status" +"$bjam" -sTOOLS=$tool --dump-tests test 2>&1 | tee regress.log # # STEP 4: # post process the results: # echo processing the regression test results for $tool: -cat regress.log | $process_jam_log +cat regress.log | "$process_jam_log" if test $? != 0 ; then echo "Failed regression log post processing." exit 256 @@ -168,7 +168,7 @@ # uname=`uname` echo generating html tables: -$compiler_status --comment $comment_path $boost_root cs-$uname.html cs-$uname-links.html +"$compiler_status" --comment "$comment_path" "$boost_root" cs-$uname.html cs-$uname-links.html if test $? != 0 ; then echo "Failed HTML result table generation." exit 256

2 1

Failed to build boost 1.31.0 on Windows 2000 with vc7.1
by Li Lirong 07 Feb '04

07 Feb '04

Here are some of the error messages: ...failed HardLink C:\Boost\lib\libboost_unit_test_framework-vc71-mt-s.lib... HardLink C:\Boost\lib\libboost_unit_test_framework-vc71-mt.lib Could Not Find C:\Boost\lib\libboost_unit_test_framework-vc71-mt.lib del /f/q C:\Boost\lib\libboost_unit_test_framework-vc71-mt.lib && copy C: \Boost\lib\libboost_unit_test_framework-vc71-mt-1_31.lib C:\Boost\lib\libboost_ unit_test_framework-vc71-mt.lib ...failed HardLink C:\Boost\lib\libboost_unit_test_framework-vc71-mt.lib... HardLink C:\Boost\lib\boost_thread-vc71-mt-gd.lib Could Not Find C:\Boost\lib\boost_thread-vc71-mt-gd.lib del /f/q C:\Boost\lib\boost_thread-vc71-mt-gd.lib && copy C:\Boost\lib\bo ost_thread-vc71-mt-gd-1_31.lib C:\Boost\lib\boost_thread-vc71-mt-gd.lib ...failed HardLink C:\Boost\lib\boost_thread-vc71-mt-gd.lib... HardLink C:\Boost\lib\boost_thread-vc71-mt.lib Could Not Find C:\Boost\lib\boost_thread-vc71-mt.lib del /f/q C:\Boost\lib\boost_thread-vc71-mt.lib && copy C:\Boost\lib\boost _thread-vc71-mt-1_31.lib C:\Boost\lib\boost_thread-vc71-mt.lib ...failed HardLink C:\Boost\lib\boost_thread-vc71-mt.lib... ...failed updating 56 targets...

2 1

FYI: latest gcc 3.4 + Boost 1.30.0 OK
by Ralf W. Grosse-Kunstleve 07 Feb '04

07 Feb '04

For those who remember my worries from a few days ago when gcc 3.4 didn't work with the Boost release candidate, it's all fixed now in the gcc-3_4-branch. Ralf __________________________________ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html

2 3

[filesystem] size() on directory?
by Beman Dawes 07 Feb '04

07 Feb '04

How should size( "foo" ) behave if "foo" is a directory? 1) Throw. The function should be renamed file_size(). 2) Return 0. Directories don't strictly speaking have a size. 3) Return the number of entries in the directory. Directories are really just containers; so of course they have a size. (1) and (3) seem most attractive to me; (2) seems useless for directories, and probably misleading. The problem with (3) is that for many (most?) operating systems the implementation would have to iterate over the directory to get a count, and this difference in complexity compared to getting the size of a file (which is usually constant complexity) could be pretty surprising. I'm inclined to go with (1), naming the function "file_size", and then add a function later to get the number of entries in a directory. But only if there is enough demand. I don't want to clutter up the library with a lot of seldom used functions that can be trivially written as user code. Thoughts? --Beman

8 9

Big problem with web site
by Daryle Walker 07 Feb '04

07 Feb '04

I hope it's just my ISP caching web pages.... I've been working on something for the past few days, so I wasn't looking at our e-mails. However, I did look at <http://www.boost.org> a few times to see if the latest version cam out yet. I didn't see anything there. When I looked at our e-mails, I saw an announcement for Boost 1.31.0. Do you know what that means? Our home page has NOT been updated! Can we fix this? (I noticed that the library documentation page <http://www.boost.org/libs/libraries.htm> _did_ get updated, but the library download page <http://www.boost.org/more/download.html> is now _gone_. I didn't check any other part of the web site.) -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

2 1

any interest in generic operators?
by Andy Little 07 Feb '04

07 Feb '04

Hi, Attached is a demo of generic operators. (tested on VC7.1 , gcc3.2) Can be parameterised on the operator itself Optional Concept checking for exact argument types (identifying.. so eliminating unnecessary implicit conversions) Can be specialised for UDTs.... giving standardised format regards Andy Little user: meta::operator_plus< lhs,rhs,check_exact_funda_args >::return_type plus_ret1= meta::operator_plus< lhs,rhs,check_exact_funda_args >()(x,y); std::cout << "lhs + rhs = " << plus_ret1 <<'\n'; templateable... meta::binary_operation< lhs,std::divides,rhs,check_exact_funda_args >::return_type div_ret= meta::binary_operation< lhs,std::divides,rhs,check_exact_funda_args >()(x,y); std::cout << "lhs / rhs = " << div_ret <<'\n'; begin 666 generic_operators.zip M4$L#!!0````(`"-F1S %C)M+Q D``,4O```:````='EP97-?<')O;6]T:6]N M7W1R86ET<RYH<'#-&OUOVS;V]P'['QY:8$ZNJ9ND+0YSFA195VP%FB9HO!T. MQ4&@I6>;5XG42"H^-^O_?GR49%&R9#NI`E0(6IGB^_XB^?CL&<!4R01^D5(; M2.VK-%R*P"C&C1[.TQ3FR")4,.4Q`CSUGQ]_^/$'PK#W9A_>R'2I^&QNX#S& MSQJ7\%NFC+R12S@^/#P<PA6JA&MMD8.1$-KI!Y!I/,A1)#+B4SNB,8Z!B0@B MKHWBD\P(a)F#G7H.74+)A"L.\SQ83!B-B]X9%]H1DYGG#%AK""A @L39$I#5P` MLZCM=XYZ".,FSA)7CN81LQ#Z$2RXF<O,`/XO5:@U2 4\26-N:5I 8L/R3.S2 M1$L2PICQ!%C!C164&TLGXX9->,S-$J86!1-+2#.52HW#0H?GX6<A%S%&LP2% MT2,W^(N%^/+DB2-@Y@CO63*)&+SG$\74LA)?RP1!&Z8,%S.P0Y9[HN,4YS 1 MTTB8&5D7Y!3,,D4]J"P.N<5/8"X7>(/JP%&LPSE4$XSEPL*A01%I$G&"D$B% MP,(P4\P@Z3J1$<8QL4-H8C0&E2,[=YR*B*DH9\W,F7!:LB@C#%%KJ32<[)>* M$=$28FY,C' ,4YS X0MP3G.T#RQ:B3\@@01+<.!T?[P/"M.8A?;[A'Q[-(K0 M,!Z/1C0Q4$Q\?C4^<W;+Q5J?I(-F/)1@!/&\FP+-"K3!-'>+.^)WD 3S8A_" M.1.SBD ^'P,C`\UG`J- JB 3^3LDF$Q0`2G!D72!K5!GL2$S$4D:#V624BR3 M5TTR'D=@4%,X20%_OOGG\,@!OZR(H\@29VA-;A "%P9"*;2!/3N(,4\H& 07 M,TTX9F'X?'CL[/>83T6$4[AX.SX/QO^^>GL=7'V\O+@<O[O\$(P_GK\;7P>_ M7UW9B786%[A](N$489Q%"(^<4IXE:?R,3RE3/:+/)+U.68B0H&%P"S0(]J$H M$ 9GBL5K>J^GM2*W%4#DL5,9QW+A@JL>2%S#A.E<=]I$*R"-H?O^8O@2/H52 MW R)Y'^&/C>3)5BI&5G',8;*BT8*WTQ03A"%X0JH2**FW#:WW SS48.6*6;P M5?Z3GC!F6L,X'SB#_']M5!::;BW<5O!$D(a)PW=F\G!8*O)Q[[#=$.(&6*V=$& M3[L2]YB?2!D7G-_".D_D?IU<D=Z*<' A!MRXBI$QRDRN5# #`XMCL(()F:!0 M5JC1HJ8J03:_87%FX<N<)3,5(E1>89'#!,DEBJ",8&^"(<LT%2Q<`M45PE7Y M1,X6A9WF7U!.]RP7^W!V6OX<[\-BCA9L7'FLAD$!%\Z9&E !&NBY5&:PWX.F M/=2EPN^B[XKTW2F3##O0;#%Q,TA\<Q]L<<^C'2.F)L_FK-OFHF4M*O.VI38: M\6D0>@3IV:LY0N4'^P?U>?9[8V1%WGZJOISEA:53=<^'/P^/X-.$:1X.IYF( MF$ME\4H]H\I=WXE\G4*KBC"+F6KDO@-@U>0T9ES H/#1R7\Q-"ZL#/N,E!N1 MFSFJ6D[5I)\BR)C]6W?TU72+:+ 2V'T^@<6<AW.+VBW>JGBIL?@TKRK1MP=* M/4)<82,[_W)Y>3T._OAP_>ZW#V]_#=[\?OXQ>'=Q]?[MQ=L/XW,J7AM\8Z-; M-1REHM]BYL<8:]P80X]11'S:8_C6K+$A5]]%QA:<OK#M3OTM1ET1W)*,[B6$ MAW-K9);+I-R=/EP&_W*>- ZN_[BZNOPX[DA]"U)48 XZ<MWQ215 L99;@__E M",;$X@IJ4! 86&&HDLW9#5:A2\GJH*@@PL^\5.!8;,<)/2C\*^/*Q:2&/<O# M/D4[Q6U>65=@DC+$RFY%.H?0$J8L9[P@#RSOJ.(E%[.G;C'?0R4L1&UQY?90 M+RVT+=KO50`*9EK+`-2'MN!?HP&GI["-3+.^-&GN2->G'4LQVT' \J'I'9]6 MC-&<]2E%G-4_K VV1*,S=7LBO9,-3W<Q8GVD+DDK;WD")^>_@Q]^+<";P&T) M9A5<X\M?+T?YEN_UZW*\VE3E^U>X+;]XR^&.[6S+WJICLU7@6D@Q,/9?]=EE MN3PON%,"VJV:ISS?$6G/4.O+N;4EG;\1\G+#!L9/:K,;.]]M^W<XA:-#./'5 MM):>=F.C(52U.5K+5*V,NA66Y>;0\_.O'7Q]`UOMI7MG[C81(HG/1J-\:AW? MD^UV\*W8)?>WV*-KU7+;@^0>YE(!=Y?_0<W^$/:N:?2^<G>*O=M:JS__J"TL MO+TE/7WX2(]*JLI(a)OEOH.T4T5L0]2)^[^#^*5/N ?MZYK.\ES GG=QK@]>.% M/J2MJ[+W^.[7W/V+;V?W&*Y]9ZO&4K17>_<G^4-9^P&D)Y3?B]336#+3;_FI M$G#OZ\M(9I,8?7;[6%SD.G@X@]POY" 7MF??*S38I[!?:8/6W UZNT>FN)DG M:'D-Z#P*%?7[]:8NVPKT)7RB+GMY&O6S=Q1]00?1$RZHZ2U35,Q0B]AU<BP( MG36[46I'RVD++W283#M:@G2M;MI?YZT:C\O:`=:28QRMFJ=Y)TD``\T33F?A M"[:D2P3>:5G1T*?C:",+>&;Q)TE!\: XL[83Z#RN=ACN."I:33G1XHI"RJAS M[AJ-Q5%8#2[(=,9B7U1?[25%IKS^87XD3H=P>5>3[AIT=D56A]7CHX.VT>.V M?LEF)R@\.U7\QM+RK$P[?J9D)B*W[[^X_O,-3+*9ME+P.*9;!@J?+BQN@\+U M_".VO,<90&L2<FZ_EF'6CNQWNQU0ZY:M)POR1,IFX'(1%[,@E5R8"EW+<=MI MQ>6K\5%Q1-0:V"LY?9 RZWE0+43^_MNG<MP+E4:>;"ITEZ-9>L9'ZP=D9=\U M,$?KJZ%[$SK>1.BXU9"4P0.R8+F0<#]"F5#*RN_-0./QU=:N64^ZSE/.;E,Z M&MN)=*]U[T3MIY]VHN3I<1="W8AVE&Q]07MGR6HAL<U0+5)]9X:ZE[%:_&]7 M8^TH6;>1-F:39\^*6NEN:;A;8%0%I+L<1[><LKP-K*%^ODQ7+(J+6^ZZ17EM MHZB_Q?THI0<UL)0I75SWF,28Z!-:$-CYTA)S%SY"F<41E:D:V-[KU_O 7!N] M)+#J*]!-NO5T0I^/\G78S 3TZS@O3W<K"QWF/]N0XUM:+GDS(W ISG)3_"Q= ML8VC]HZ/[[QM71_/W5:B>Y&5*V"+!CP<=U:%1ZO+L<L]=YI-8AZ.[G_KHZON M-]2R*[IR;IO/M&BZMI)K*WM>W'T#1UN+8@L7=\&_W3E;"/326^R!\5V\O8-' M#[2M+[MK16J KH]NNTK4O(a)3N;O;YH.[*L$XQY"SF7S!?[V<:57EA![P&7U^[ MD@Z&;S?$\<:-S-H*M6F.MJ7DFC8;&VJZL^KN%ZU:MCO<B/T_4$L#!!0````( M`&]F1S"7-]UG# (``&D%```,````87)G=6UE;G0N:'!PS9-/:]M $,7O`GV' MP880%V.%TI/BFAK;M(4DF*+0HUE+L_80:5?LCIRJ)=^]LU+JM"$M:<FANFAG M]\WOS=.?(6E3H(;+53;?S#^]O[Y<766;#^OUYN/5XN)ZN5K&T5 $9/"/FB0! MC5AL57X#;$&9HGWGT1UL;JMJHAUBJ'"2VTEST\EA8>O6T6[/<+H8P5PZX(*8 M2QS#YSTQ2A4.EWB@'.'UV=F;2=^X1E>1]V1-L,H%,X;&2UME"])2>"S+, (4 MY-G1MA$8[\F#MYIOE<.>(QL[IPQC`;6S!RIDT<GRXV3&<C!7=8W*>2 #2M!R M3NCOI\E^!@?FD350TN$'<$N\MPT#?JD=>@_6`55U22*1GC!!.^Y98>:@%E_( M2T45"$(R$HM%0ZRV5!*WH 6A3 MUXVKK42:)HR&9O&P*A,'66L^)."2D)_NZ M'L21417Z6DF4"EE]BR.02QPE6-F"0]V]-+=K*C0,!=9HBK"R!CQ]Q5[/*$S% M"%/@5A3"A&S6GWEV3<Y'Q+U#UR72\(4=6[KQTE18:4IZDT\?M*>=F]6GV0BF M;X_%J]%H_""2*WM4GCR4LS0-3IW=.?3[=^<_`CNL[ &[P-K9JEO(S"^0>)J= MS/Z_U(]C_"Z%;DRA0@Q5/A$BZ[F_/LR_@DYS:SR+X#GT?^$__?1?!@W]\,]S M"/<XNDN2[D^+HR&:@G0<?0=02P,$% ````@`;V9',&*6>XZQ`0``H@0```P` M``!C;VYS=&%N="YH<'"EDM]KVT ,Q]\#^1]$`V6%X)2QMY:RD!0VZ++ 7/H8 M%%MN1.V[XR2G,Z/_^W1Q4L;(1G_8+R=+WX^^DF_$E2NI@F_7^70U^[[XD4\7 M^>K+<KGZNIC=W,ZOY\/!R K8T7]KAH/)!"JB<HW%`Z@'=&7W62AN?>&;)JLB M48HH*WS6/NS*8>9#%_E^H_!A=@934\ -J]8TAKL-*UF4DG/:<D'P\?S\4]8+ MEQ0;%F'O4JO",&-HQ62-+[FR0*BNDP4H633RNC68;EA ?*6/&*GGV(?[B$ZI MA!#]EDL[[,J*9V?.:VJ.(1!&`7: AK8\D^S=Y'^"$_.9=8*FD!-X9-WX5H%^ MAD@BX"-P$VJV$M,D!]VX9R7/J=KZ0E$C-V (FY'56K2LN.::M8/*$.@Z"&T, M7BA+?\!A0Q+0W#:D^&LX`'L,:M[KSBP[T83*^X22.4 EN 3M`B4QY%=]3C2V MA?82,[='[516FNY+?N!9?-&GGRY>#;[,3Z^.P _T4W@OOS?YVB[]Z<7=MA@9 MUS4=7=,;)S@P#Q,<&^#]\'\NYLV;_]OWRQND]VDRV=W==!Z1*[D:#GX#4$L# M!!0````(`&]F1S!&WKP;H@<``#HG```5````9V5N97)I8U]O<&5R871O<G,N M:'!P[5KK;]LX$O\>(/_#H NT]IZ:M'M[+R<QSDZ#O0)[VZ*7P^U^$FAI9!.A M1"U)I=$9^=^/I!ZF'I;59GTH%G6_2"3GR=^,9B8]/3'_OJ%1$F($_[RY7?@_ MW/QT\^'MM?_N_<V'Q>V[#__R__'^O?_VI^L?__WFYHT^K$_2!,<=/CTY/X<( M,5R1X X4!Y*$^=\EBGL>\#@^BP2B><.S@)]E=_8X7/,T%W2]43"YGL)"4\"/ M5"F&'OQG0Q7J-[/Y!N]I@/#=JU??GQ6$[U'$5$K*$R,JT&P\R*0FBWE((_TB MD3&C`H14*D%7F6:F-E2"Y)'Z2 06?/3"6I!$80BIX/<TU _V6%!KEG!EA),T M12(DT 2(9JWW*<I2FUN7L>%9\WI&-(5\!A^IVO!,`3ZD`J4$+H#&*:/ZB*8Q M&N1>P<OH;$YKN1 P0F/0++2-5&D1&55D11E5.42:!4ER2#.1<HEGY0UD$LG: M&J?E9$SY/+I<>#SUEO/93.5I8;=Y,'JJ#1;//++/!8UY6P!/86D/\Q0%45K< M"\7O,)$O]#%C!5JWK?+Z@'7.990E@:(\(6QNR5?:[(!G+#1W8RS!)(LEH I* ME8G0YL:H:&#\%G-#;#86#!\PAQ\RH?@]+[Q:[,(&28C"4DMF;HGEL"'!'88& MXDG LA#AF;%,^C65KP2A2IYMTO09%))3<P427JQ0JA=:D746:ZN,DK<NHVK# MDEK*F-QINEMM6"(5291[NEHK3]<;3<^<GB0D1IF2`$$;3[:G)Z!_FC=-(BYB M8@TE*X.:VL$>$"EY0/7F/56Y!ZG `$-,`JS(K5_-HU0B"Q2L:$)$[E<L_)0( M+5>AD*5$_3,W4G"&+<-(^3LIZ-DH<%<>+VI"V#UID\T-6N.U"<HN:BJZ3HSK M_!+YQJ@K>'UQ@%"_A;3PE4-Y]=TA.L;7-- TVE"'[(]CR4@2NG3?'Z*S5ROI M/;8$_ND0(3[T$_[Y$&%+P[\<%/1K1DR^<(G^>HA(("-=Y__M$)G<T,B]Z*O7 MKPZ:$YIKOL<&U4%TQ!E3-&4T(!W:"B&/%RY$Z]A*4>SRF0FT>B<FN;;[UXP* M!)EB0 FCL@A"DVJS4!5'%<8I(PHO=SJ:/&."&1:>LUB=JW;G)IU+">]2KX=T M6:S-&[';"=XB@\'6A&!+'4<)A^M\,!<4["X7GE3A;):R3'K+.6R'O+_SM1^1 MF++<20%7`\EF-NNYZJ%[;B2ZL3(ZN6J?A!7G#*CT36F2*7M4LU8BPQH_1_!P M3),OUL6CA3S1QQ%A\KA.+I,#'M/3>S/0%^?O8V,ZU-:$7WW]?$V#[,R2W_U M=K^WS\]!H,I$TNQN2 (\=4ILVT_9S1CCE>DERJV%[<"6(#>V9UDA1%D2:IT3 M19BED/79A"LM+)*0*E%W-.7>KIDP)/H5(=APB44Y81H.4XS82M^IW@N#/:N# MYHS"E/9 (Y#TO\BCR>T4YE?UR[?3SRY?X$CU"PRB.2",U45,S:7)SHPG:K8K MSJ6:S;0JLQF-_,#1NO)SW6(XH*]NKT""\6390B.+8+)X/FVRF>R-NG=%X]P) MIR:]A?J!3W-?)S0%K\EH\;RU,-81GV<%=)G82QPVI5WF3ULZ%Q<3$[7QBI8` M7KZ<E\V[&:_8(42;H#:TOVGO,=?ZJT>T^2V[R^7XHU?7@,=I=]UDG>9J/4)I M+4 )--^\U)FH`FB:LKP:,=C3)B!-;DJ)H$'&B*B3A6Q0+KPEV,31SD #`5,- M'UH.J_<K29>+_<9 1(54?G6T:]48J5V)RP&)$DW'WQ+92 _5U&&7P,9\3G<` M9IELI)_94')JM43;QN?%S@?O4=A$HVGX1[G+]MJ,<FOWF:#=&X209RN&)C+, M][,>VNR^395:DRE4<Z-1&1RZ*1S&YG!GT7YRKS<8W/4UI(a)W7%;7!Y]Q.FTW3 M[9[]P,^W7=R-OSG@Z<4`;GDZFSFAVPKC0;*>&-D3-X-L^H#?'PU]0S=7=P^E^6W+;ROYP^KB\2DAN@\$9;/$!34#??O$09?PN6_ M/-;E.TW\TQ#0F 9\A<%Q8 #?PI& 4(\7GH0"9TCQ%0)'@L!Y%P+07S/QA.55 MX80/)%"[LE@+E,U*R!C4JH/:+3LRB69@P)@L_G2Z*-6^KHLQ_11@.JX'?DH% M-:98*ALRSTSF/AW/MI?[7:&X9E7AI+[GB&=)"/JA0,D.'/M!/QF+\$]&_+:: M)NR[SR)!:16(MYJ:4!AA6&+03%2PH<FZB )CI.=2EJ,,)>AZC0),KTH9^HK& M""@$%Q"CE/:/_OM&-_"SDWA_F1_T(?P,#^#!+Y"[]C=]6#K#VM23:/:&X"3A MRJ>AWC)_<;WLN:[Y9.H]] T5QO+LNTK#-)_"U 'N8ZM1#PIF$)BNAR;K@5D8 MW#I.+,.\H<.VBHI;Z_B+QV;_W/T;XG"VL8W8OM'0VTJHTUAW!JD]R<HRO:RI MJV9\=W*_O]NDQ0#@N5>O@'*14V)%-8*BTLS%H 53?P2/"-!>@(Z+U@8J/FE\ M[SFM\L#LH3UOZ':[!8=MNWSZ?+&V^1F06S58O[W@NN8>DNY6^+^Y"F7!-R!_ M5U@ZPD]/'L_/S?_&.3WY!I.01F;I?U!+`P04````" "/9D<P.SJ,O: #```R M#0``" ```&UA:6XN8W!PM57-;N,V$+X'R#L,G(/MUG4V04^.';3-7@KTT,,N M]K* 05,C:Q"*),B1$Z'HNW<HV[(VZ[BQTNI@B-3,]S,<#R\OKJ]+17:JO4_O MD"-F*Z4?@1THF]6_1 P;IUU93O. F%8XU6Y:/3;A\.!\'6A=,(P>QO"K9, ? MQ&QP`E\*8I15^O@1-Z01;C]\^'FZ3?P30TDQDK.)2@O,!*HH::7+*)=%1&.2 M!,@H<J!5)6!<4(3H<GY2`;<XLK$.RC)FX(/;4"8O39ANE5G'B5QYCRI$( M* MH.4[8=RI^=0%3I@MUD!)1AS $W'A*@9\]@%C!!> 2F](0B0G*:@G6ZRD.44+ M+VBCJ 2!$(_$0E$1JQ49XAIR@5"V!E\%[R**DLN+*[+:5!G"8(T6`^FE\Q@4 MNQ"GA?>#3L2<7.2 JKQ/B609TD&.QI<7?UU>@#RB)2)#;M0:AKDR$8<-YPJ9 M,4#T*-I'*L:J)+N&S]9YII(B9N,6X/=<#"O-H,(ZPJ-U3Q9^J_A[`O$WY% ) MA;P].*O1,SP4J!^WJ:5B76RQ3+U-U\Y&ALB*2</*.0,ZQ2^;H&5>V4PM4^XV M&A:0\.^2V2WYW*N@RG@/C07Q4F# 1+]":+)+M*Q,JU6L:R.Q,/K\\=,8N/8H M[S95(7K4I Q%T2*J#OX)4_> YP`!\[C3O'%&`@T"LIY.I[ /EVB#:H--9S1M M73(a)7401)TI.JTY9/"@ZVMK])2X8YI%,T1;S[=C=SU4K(0ONA6S\)AV=8P"W< M=;<E&&K9OIG>=$H&&0;:B.&VJYJ.J&+JAZ:=-?'N>")GLYE.+3^?PR"%B-6O M=M#"E<AJ-MLC+;VIXGQW5O*(KHF(F)PZT_O9+"!7P2Z354@(2]FX6?QG!*/Q MZ'E2C^^.6;J%'U-Y8 &#M&[993'\:H>O^2S)OM=H`W'":2^*TU9_ZEH]\!^\ M'OKJI9C*,*5!]U[3E3EEN3?+:=\_?.-[)^%?3CBC-/K?:5= 3MCM27':ZW77 MZYZ_Z_6*<AA]Z$PW61[G&\.:-AA?3'(,P06Q$J-:X^O_T60E-T[Q*V8Z-J[0 M9J*B,Z%V]][W$RK=VXRE-XHQMN'#?1RP>T0[!*ULN@":NP%9H")FQ\JUY]E# M'AUN*[(JU+L[F)Q]<5X-8K+<=](M_A^R'E/O^%_B+9*:8=)[`IY=@3?2]9F& MKP_#-PEK)UC/R7A^*<Y@/']*]N^(W7#K.3'/+L.;Z<Z?GMT:_)U^+B_^`5!+ M`0(H`!0````(`"-F1S %C)M+Q D``,4O```:``````````$`( ````````!T M>7!E<U]P<F]M;W1I;VY?=')A:71S+FAP<%!+`0(H`!0````(`&]F1S"7-]UG M# (``&D%```,``````````$`( ```/P)``!A<F=U;65N="YH<'!02P$"* `4 M````" !O9D<P8I9[CK$!``"B! ``# `````````!`" ````R# ``8V]N<W1A M;G0N:'!P4$L!`B@`% ````@`;V9',$;>O!NB!P``.B<``!4``````````0`@ M````#0X``&=E;F5R:6-?;W!E<F%T;W)S+FAP<%!+`0(H`!0````(`(]F1S [ M.HR]H ,``#(-```(``````````$`( ```.(5``!M86EN+F-P<%!+!08````` .!0`%`#4!``"H&0`````` ` end

1 0

[BGL] Removing vertices and internal properties
by Frédéric Mayot 07 Feb '04

07 Feb '04

Hi, I have a graph in the form of an adjacency_list with an internal property. I'm using vecS for both vertices and edges (and I don't want to use listS). When I remove a vertex with remove_vertex(), it seems that my property map is invalidated. Can I remove the property (from the map) which corresponds to the deleted vertex ? Is there any solution ? Thanks. Fred

1 0

Mail Delivery System
by pdimov＠mmltd.net 07 Feb '04

07 Feb '04

Mail transaction failed. Partial message is available.

1 0