- Boost - lists.boost.org

[filesystem] directory iterator operator++ patch
by Vladimir Prus 11 May '04

11 May '04

Beman, the attached patch enables the operator++(int) in directory_iterator. To summarize our discussion with Dave: 1. New single pass iterator requirements did not meants to outlaw returning proxy from operator++(int) 2. Even if proxy is automatically generated by iterator_facade, this might take some time to be implemented. In fact, I no longer believe it's really desired. So, implementing operator++(int) is directory_iterator makes sense. The attached patch basically uncomments your code, adds one using declaration to bring preincrement operator++ into the scope and changes the tests. Okay to commit? - Volodya

1 0

Metacomm BoostBook-generated documentation not updated?
by Douglas Gregor 11 May '04

11 May '04

It looks like the Metacomm BoostBook documentation hasn't been regenerated in a few days. Is there a problem of some sort? Doug

2 1

Boost Array Documentation
by Stephan T. Lavavej 11 May '04

11 May '04

See http://boost.org/doc/html/array.issues.html : g++ 3.3.3 accepts array<int, 5> a = { 0, 1, 2, 3, 4 }; without complaint when using -Wall -W. Assuming that other modern compilers do too, then this Open Issue should be removed, and the documentation updated accordingly. (Also, the Lambda Doc Bug I pointed out has not yet been addressed; see http://lists.boost.org/MailArchives/boost/msg64450.php .) Stephan T. Lavavej http://nuwen.net

1 0

typeof
by Arkadiy Vertleyb 10 May '04

10 May '04

Hello everybody, A couple of weeks ago I initiated the discussion about simple typeof emulation, and provided an example on how it can be done with the help of MPL vector of integral constants. I then used MS-specific __COUNTER__ macro to spare the user from specifying the unique integer for each registered class/template. I hoped to find a way to do something similar in standard C++, and asked preprocessor experts for help. Indeed, Paul Mensonides suggested such a way. At first I thought that it will not be good enough replacement for the __COUNTER__, but then I realized that I was wrong. So I re-worked my implementation of typeof, and now offerring it to your attention. Besides removing __COUNTER__, I used the Boost.Preprocessor library to cleanup the implementation. Also, after the discussion with Jody Hagins, I put the encoding/decoding classes inside anonimous namespace to avoid collisions between translation units. The provided example shows what registration needs to be done to calculate the type of a lambda functor: #include BOOST_TYPEOF_BEGIN_REGISTRATION() BOOST_TYPEOF_REGISTER_TEMPLATE(tuples::tuple, 2); BOOST_TYPEOF_REGISTER_TEMPLATE(lambda_functor, 1); BOOST_TYPEOF_REGISTER_TEMPLATE(lambda_functor_base, 2); BOOST_TYPEOF_REGISTER_TEMPLATE(relational_action, 1); BOOST_TYPEOF_REGISTER_TEMPLATE(logical_action, 1); BOOST_TYPEOF_REGISTER_TYPE(greater_action); BOOST_TYPEOF_REGISTER_TYPE(less_action); BOOST_TYPEOF_REGISTER_TYPE(and_action); BOOST_TYPEOF_REGISTER_TYPE(placeholder<1>); BOOST_TYPEOF_REGISTER_TYPE(placeholder<2>); #include BOOST_TYPEOF_END_REGISTRATION() main() { BOOST_TYPEOF_ALLOCATE(fun, _1 > 15 && _2 < 20); // <unspecified> fun(_1 > 15 && _2 < 20); int n = 19; assert(fun(n, n)); } One of remaining problems is inability to process top-level consts and references, that get eatten up at the function level, before the partial template specialization gets involved... Although I believe that I don't do anything non-standard now, unfortunately I can't prove it myself. The only compiler I have besides MSVC is GCC, and it gives me "sorry not implemented" on something as simple as mpl::int_<sizeof(foo(...))>... Besides, GCC already has a typeof. Would anybody be so kind as to try the "typeof" with some other compiler? I would really apprciate this... Here is the link: http://groups.yahoo.com/group/boost/files/typeof.zip Any comments are greatly appreciated. Thanks, Arkadiy

10 39

RE: [boost] Re: static sized strings
by Reece Dunn 10 May '04

10 May '04

John Nagle wrote: > There are fundamental issues with string size that have to be >resolved. > > STL strings are variable-sized, with no limit. When you >add characters, "size()" increases. Should fixed-size >strings be similar? If the STL string operations are >to be meaningful, they have to be. The way I see it, size() relates to the current size of the string, and capacity() relates to the current storage size, thus you have: -- null-terminated, fixed size (char_string< n > s) size() = strlen( s.c_str()); capacity() = n; string manipulations guaranteed such that size() < capacity() in order to cope with null character null character is always added fixed size (fixed_string< n > s) size() = capacity() = n; > In STL strings, "size" doesn't include a trailing null. >Using "c_str" can result in expanding the string to add a >trailing null. With fixed-size strings, we don't have that >option. size() will not include the trailing null; c_str() will return the character buffer; null character is added by the string operations, thus there is no need to add it on the c_str() operation. > If c_str is provided, there must always be space >for a trailing null. So you can't use char_string >when you need a specific fixed length, as for Macintosh >4-character file signatures. Perhaps "boost::array<char>" >is the way to go for that sort of thing. Trying to do >both null-terminated and non-null-terminated strings >in the same class will get ugly. I don't think it will be that ugly. In a previous post that contained the updated char_string class, I had an implementation of it as a boolean template parameter (null-terminate). > Top priority, I think, is a size policy. Do you mean how to handle size() and capacity()? If so, see above. > Is Dunn's version in the Boost sandbox? Where? I have not yet added it to the sandbox, but will in the next few days. Regards, Reece _________________________________________________________________ Stay in touch with absent friends - get MSN Messenger http://www.msn.co.uk/messenger

2 1

c.l.c++.m post
by David Abrahams 10 May '04

10 May '04

Hi, The enclosed post showed up on c.l.c++.m; AFAICT it has little or nothing to do with MPL, but it does contain several boost-related issues. The best answer isn't really clear to me; we could detect dereferenceability, use a hack involving get_pointer, or maybe something else would be appropriate. Would anyone like to tackle this one? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

2 1

RE: [boost] Re: static sized strings
by Reece Dunn 10 May '04

10 May '04

John Nagle wrote: >John Nagle wrote: >> I've been doing some work on this too. I made char_string >>a subclass of a non-templated char_string_base, so you can >>pass references to char_string_base. This has the disadvantage >>of requiring a vtable, but makes the class much more useful. >> >> I'll put this someplace publicly visible in the next day >>or two. > > It's at > http://www.animats.com/source >Take a look and see if you like the direction this is going. >Thanks. Hmm. Which way to go? My latest version has been generalized to incorporate char/wchar_t support, so you can use wide-character strings. It also uses a StringPolicy class (i.e. char_traits) so you can control the length, copy, comparison, etc functions that are used. BTW: the reason I use the const char( & s )[ m ] on compilers that support it is because this picks up the string literals in order to remove a call to strlen, thus improving performance. Which design do you like better: using a virtual base class, or using a policy template? I have been working on providing an interface similar to std::basic_string, hence some of my latest design choices. Ideally, the class should: * safeguard against buffer overflow on static-sized character arrays; * interoperate with classic C string operations; * interoperate with std::basic_string; * provide support for null-terminated strings and also fixed-length strings; * prevent silly mistakes by the user, ideally providing compile-time errors wherever possible. At the moment, both implementations provide a different subset of those aims. Do you mind if I look into this and let you know what I come up with. Regards, Reece _________________________________________________________________ Use MSN Messenger to send music and pics to your friends http://www.msn.co.uk/messenger

3 2

FW: Bjam error on Windows
by Janet Schneider 10 May '04

10 May '04

_____ From: Janet Schneider Sent: Monday, May 10, 2004 10:40 AM To: 'boost(a)lists.boost.org' Subject: Bjam error on Windows Hello, I'm seeing the following error when I try to run bjam on a Windows 2003 system: F:\Liberty\Boost\src\boost_1_31_0>..\bjam --prefix=F:\Liberty\Boost\32bit\boost_1_31_0 -sTOOLS="vc7.1-stlport" -sBUILD="<stlport-iostream>on <runtime-link>static release debug" install Jamfile:118: in load-jamfiles *** argument error * rule install-subinclude ( jamfiles + : options * ) * called with: ( : ) * missing argument jamfiles F:\Liberty\Boost\src\boost_1_31_0\tools/build/v1\boost-base.jam:2766:see definit ion of rule 'install-subinclude' being called F:\Liberty\Boost\src\boost_1_31_0\tools\build\v1\bootstrap.jam:15: in boost-buil d F:\Liberty\Boost\src\boost_1_31_0\boost-build.jam:16: in module scope Does anyone have any hints why this is happening? Thanks, Janet

1 0

Re:[boost] Regression testing -- some new testing options?
by Robert Ramey 10 May '04

10 May '04

Testing everything all the time amounts to using one package to test another - which is OK but not as efficient as a complete test suite. What I would like to be able to do is run the tests on a demand basis. That is, I would like to request a test for a specific set of compiler, dll/lib, debug/release options. As a practical matter, I will get everything working with the compilers I have on hand, upload to cvs, run tests on compilers I don't have. This wouldn't take a huge amount of time. Only on special occasions - i.e. right before release, would it be necessary to re-test everything. Maybe a facility could be include whereby I just submit a jamfile and it's queued up. Robert Ramey

1 0

bind behavior
by Dill, John 10 May '04

10 May '04

I ran into some possibly confusing behavior when trying out the documentation example from bind. When you have: struct F { int operator()(int a, int b) { return a - b; } bool operator()(long a, long b) { return a == b; } }; F f; int x = 104; bind<int>(f, _1, _1)(x); // f(x, x), i.e. zero What could be confusing is when you do this: long y = 104; bind<int>(f, _1, _1)(y) // Calls the operator<bool>, not operator<int> which is counter-intuitive as the documentation says your binding on the return type, but the return type is not actually what function call the type deduction gets. Does anyone else observe this behavior? I tried this on gcc 3.4. Thanks, John

1 0