- Boost - lists.boost.org

RE: [boost] Re: Request for small test in VC7.1
by Ferdinand Prantl 11 May '04

11 May '04

> From: Joaquín Ma López Munoz [mailto:joaquin@tid.es] > > Maxim Yegorushkin ha escrito: > > > JOAQUIN LOPEZ MU?Z wrote: > > > > > I'd appreciate if someone on the list could try the following in > > > VC7.1 and report the results: > > > > [] > > > > If you have a Windows machine you can try it yourself as > Microsoft has > > released free Visual C++ 2003 Toolkit - > > http://msdn.microsoft.com/visualc/vctoolkit2003/ > > > > Ummm... do you know whether it clashes with a preexisting > VC++ 6.0 installation? (that I don't want to loose). Nope; I have all VC++ 6.0, 7.0, 7.1 and 8.0-preview on a one machine happily working (installed in this order: 7.0, 6.0, 7.1, 8.0). I did not register them in the environment (INCLUDE, LIB, ...) and use vcvars32 in a command-line to build. Ferda > > Joaquín M López Muñoz > Telefónica, Investigación y Desarrollo

1 0

[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