July 2005 - Boost - lists.preview.boost.org

Re: [boost] [serialization] Argument (was: Regressions?)
by Marcin Tustin 01 Jul '05

01 Jul '05

While the discussion continues regarding policy decisions in the serialization library, I think I might contribute the following observation, having only recently become a user of this library: The library has the feel of a library for building serialisation, and serialisation-based libraries, rather than a fully-featured library suitable for a programmer to pick up and start throwing objects at. In this regard, the documentation might make explicit the choices and policy decisions that users have to make, and the limitations that obtain (for example, you can't just pick up a text oarchive, and hook it to a text iarchive with connected streams have things Just Work(TM), which is quite reasonable, but not totally obvious) because of the way it has (largely necessarily) been implemented. Please understand that I am not saying that the library cannot simply be used for simple use-cases - quite the reverse, when you only want to do simple things, then the library does just work out of the box. However, things are rarely that simple for very long. It may help to think of the library this way.

1 0

[regex] Boost.Regex and TR1 fundamentally broken?
by Eric Niebler 01 Jul '05

01 Jul '05

I've had a nagging feeling about character ranges and the TR1 regex proposal, so today I did some digging. I've found what I think is a showstopping issue for TR1 regex. I hope I'm wrong. The situation of interest is described in the ECMAScript specification (ECMA-262), section 15.10.2.15: "Even if the pattern ignores case, the case of the two ends of a range is significant in determining which characters belong to the range. Thus, for example, the pattern /[E-F]/i matches only the letters E, F, e, and f, while the pattern /[E-f]/i matches all upper and lower-case ASCII letters as well as the symbols [, \, ], ^, _, and `." A more interesting case is what should happen when doing a case-insentitive match on a range such as [Z-a]. It should match z, Z, a, A and the symbols [, \, ], ^, _, and `. This is not what happens with Boost.Regex (it throws an exception from the regex constructor). The tough pill to swallow is that, given the specification in TR1, I don't think there is any effective way to handle this situation. According to the spec, case-insensitivity is handled with regex_traits<>::translate_nocase(CharT) -- two characters are equivalent if they compare equal after both are sent through the translate_nocase function. But I don't see any way of using this translation function to make character ranges case-insensitive. Consider the difficulty of detecting whether "z" is in the range [Z-a]. Applying the transformation to "z" has no effect (it is essentially std::tolower). And we're not allowed to apply the transformation to the ends of the range, because as ECMA-262 says, "the case of the two ends of a range is significant." So AFAICT, TR1 regex is just broken, as is Boost.Regex. One possible fix is to redefine translate_nocase to return a string_type containing all the characters that should compare equal to the specified character. But this function is hard to implement for Unicode, and it doesn't play nice with the existing ctype facet. What a mess! -- Eric Niebler Boost Consulting www.boost-consulting.com

5 16

Re: [boost] [home page] Marketing?
by Martin Bonner 01 Jul '05

01 Jul '05

----Original Message---- From: Beman Dawes [mailto:bdawes@acm.org] Sent: 01 July 2005 13:50 To: Boost mailing list Subject: [boost] [home page] Marketing? > If we go forward with this, I'll try to get quotes from one or two > other C++ luminaries to go in the "What do others say about Boost" > sub-section. >From http://www.research.att.com/~bs/abstraction.pdf: "The obvious solution for most programmers is to use a library that provides an elegant and efficient platform independent to needed services. Examples are BOOST ..." I'm sure the man would be prepared to give you a slightly punchier quote. On the other hand, quotes that people have made unprompted somehow feel more honest. The best I can find for Sutter is "Use the Boost, Luke", which is perhaps a bit nerdish for selling to managers. I can't find a thing for Andrew Koenig - google finds LOTS of things for "boost koenig", but they nearly all refer to Koenig lookup, and the rest seem to refer to "Accelerated C++". (I'm sure he /has/ said something complimentary, I just can't find it). -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

3 2

Re: [boost] [function types] New tag type logic
by Greer, Joe 01 Jul '05

01 Jul '05

> From: David Abrahams <dave(a)boost-consulting.com> > > Rob Stewart <stewart(a)sig.com> writes: > > > > > > When classifying types, it is often necessary to test for any > > > one of several variations of an aspect. A common case is > > > ignoring an aspect which means to allow a match for any > > > variation of that aspect > > Please excuse me for jumping into the middle of this discussion. I am only a budding metaprogrammer, so that influences how I read things like this, so bear with me. With this phrasing, it is unclear to me whether the common case is "ignoring an aspect" or if it is really "allowing a match for any variation of an aspect" which I can do by "ignoring an aspect." > > Neither quoted sentence seems long or complex. Perhaps there > was something you snipped to which you were referring? > > Here's the full text of my suggestion: > > When classifying types, it is often necessary to test for any > one of several variations of an aspect. A common case is > ignoring an aspect which means to allow a match for any > variation of that aspect and is only useful when also testing > for other aspects. Ignoring an aspect means using an > "unspecified_*" tag. For example, allowing a match for any > decoration requires using the <tt>unspecified_decoration</tt> > tag. > In this paragraph, you are telling me that "ignoring an aspect" is "allow a match for any variation of that aspect" (sentence 2) and that "ignoring an aspect" is "using an "unspecified_*" tag" (sentence 3). The use of "means" in both sentences is awkward. It is also unclear that "allow a match for any variation of that aspect" is actually the same as "using an unspecified_* tag." I tend to be more conversational in my writing, but I would be tempted to write something like: When classifying types, it is often necessary to test for any one of several variations of an aspect. A common case is allowing a match for any variation of an aspect. This is done by ignoring that aspect and is implemented by using an "unspecified_*" tag. For example, to allow a match For any decoration would require using the <tt>unspecified_decoration</tt> tag. I just wanted to throw in my $.02. I'll go back into lurker mode now. :) Joe

5 15

RegEx VC6.0 error LNK2005 errors
by Alexander Balaev 01 Jul '05

01 Jul '05

Hello, I am new to the list and I already have an issue. LOL. I downloaded the latest BOOST because I need regex to support UNICODE (so I do have UNICODE and _UNICODE in the project settings) and release build is OK but in debug I have the errors LIBCMTD.lib(_wctype.obj) : error LNK2005: _iswalpha already defined in libboost_regex-vc6-mt-sgd-1_32.lib(c_regex_traits.obj) LIBCMTD.lib(_wctype.obj) : error LNK2005: _iswupper already defined in libboost_regex-vc6-mt-sgd-1_32.lib(c_regex_traits.obj) LIBCMTD.lib(_wctype.obj) : error LNK2005: _iswlower already defined in libboost_regex-vc6-mt-sgd-1_32.lib(c_regex_traits.obj) LIBCMTD.lib(_wctype.obj) : error LNK2005: _iswdigit already defined in libboost_regex-vc6-mt-sgd-1_32.lib(c_regex_traits.obj) LIBCMTD.lib(_wctype.obj) : error LNK2005: _iswxdigit already defined in libboost_regex-vc6-mt-sgd-1_32.lib(c_regex_traits.obj) LIBCMTD.lib(_wctype.obj) : error LNK2005: _iswspace already defined in libboost_regex-vc6-mt-sgd-1_32.lib(c_regex_traits.obj) LIBCMTD.lib(_wctype.obj) : error LNK2005: _iswpunct already defined in libboost_regex-vc6-mt-sgd-1_32.lib(c_regex_traits.obj) LIBCMTD.lib(_wctype.obj) : error LNK2005: _iswcntrl already defined in libboost_regex-vc6-mt-sgd-1_32.lib(c_regex_traits.obj) I found the workaraund at http://aspn.activestate.com/ASPN/Mail/Message/2509074 but it doesn't work for me Could some one please help me on this.... MSVC6.0 SP6, Window XP with the latest MS SDK. Thanks in advance, Alex. Thank you again, Alex. mailto:alexbalaev@yahoo.com ____________________________________________________ Yahoo! Sports Rekindle the Rivalries. Sign up for Fantasy Football http://football.fantasysports.yahoo.com

3 2

Re: [boost] Regressions in your Boost libraries as of 2005-06-27
by David Abrahams 01 Jul '05

01 Jul '05

Douglas Gregor <dgregor(a)cs.indiana.edu> writes: > You are receiving this report because one or more of the libraries you > maintain has regression test failures that are not accounted for. > A full version of the report is sent to the Boost developer's mailing > list. > > Detailed report: > http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… > > There are failures in these libraries you maintain: > python (4) > type_traits (2) > > |python| > extract: gcc-3.3.6-linux > list: gcc-3.3.6-linux > operators: gcc-3.3.6-linux > slice: gcc-3.3.6-linux Hi Doug, Is there a machine I can login to at OSL where I can GDB this setup? I could build that compiler myself, but... I wonder a little why we're testing 3.3.6 when there's a 3.4.0 release, but I s'pose my wondering won't change anything ;-) > |type_traits| > decay_test: cw-8_3 This one should be fixed now. > is_enum_test: vc-8_0 The chart disagrees. -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 3

Re: [boost] VC8 function template ambiguity problems
by Jason Shirk 01 Jul '05

01 Jul '05

I fixed this problem after Beta 2. I can't think of a workaround. We are failing type deduction too early during partial ordering when encountering a dependent type. If you try the June CTP (community technology preview), I think you'll see the fix, but if not, rest assured, I verified our most recent internal build compiles this example cleanly (well, we warn about the use of default int as the return type in main().) -- Jason Shirk VC++ Compiler Team -----Original Message----- From: Michael Stevens [mailto:mail@michael-stevens.de] Sent: Tuesday, June 28, 2005 12:41 PM Subject: VC8 function template ambiguity problems Dear All, I was hoping that VC8 would finally fix up problems with it's ambiguity resolution system for function template arguments. Sadly the current beta version as used for Boost regression tests still has problems. See http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/out put/RudbekAssociates-bin-boost-libs-numeric-ublas-test-test1-test-vc-8_0 -debug-threading-multi.html for a failure in Boost::uBLAS. The same problem is not shown for previous VC compilers as the offending tests are simply disabled. The problem can easily be exemplified with the follow code which still fails on VC-8 struct range { }; template<class V> struct vector_range { typedef range range_type; }; template<class V> struct vector_slice { typedef range range_type; }; template<class V> void simple (V &data, const range &r) {} template<class V> void simple (vector_slice<V> &data, const range &r) {} template<class V> void hard (V &data, const typename vector_range<V>::range_type &r) {} template<class V> void hard (vector_slice<V> &data, const typename vector_slice<V>::range_type &r) {} main () { vector_slice<int> vs; simple (vs, range() ); hard (vs, range() ); } There are no problems with the functions 'simple'. It thinks the functions 'hard' are ambiguous despite the fact that the first parameter is more specialised in the second version. It seems to be disturbed by template parameter dependence of the second parameter. Anyone know of a workaround? For those that know a little more about MS compiler, or have support for it. Is the current beta of VC-8 close to the final version or is it likely that i such deeply rooted template problems are going be fixed? Michael -- ___________________________________ Michael Stevens Systems Engineering 34128 Kassel, Germany Navigation Systems, Estimation and Bayesian Filtering http://bayesclasses.sf.net ___________________________________ _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1