- Boost - lists.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

[shared_ptr] supress warning for BCB6.4
by Pavel Vozenilek 30 Jun '05

30 Jun '05

Borland C++ 6.4 emits a warning (in release mode) for function add_ref_lock() from sp_counted_base_w32.hpp ("cannot expand it inline because of for inside"). I use CVS version few weeks old. Wrapping the function with #pragma helps: ----------------- #include <boost/detail/workaround.hpp> .... #if BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x564)) # pragma warn -8027 // function with "for" is not expanded inline #endif bool add_ref_lock() // true on success { .... } #if BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x564)) # pragma warn .8027 #endif --------------------- Could this workaround be applied? - it is a bit annoying and completely useless warning /Pavel

2 1

Re: [boost] Library Proposal: Boost.Geom 2D and 3DGeometricPrimitives
by Hickerson, David A 30 Jun '05

30 Jun '05

I will locate the library this evening and upload it. One this about it was I developed it before I saw Boost and had developed my own conventions. I did this as part of a thesis work in Robotics and will I was working for a 3D Vis company. There are references to robot convension and a graphics convension. This is because the robotics and engineering use a column vector notation and the graphics community uses a row vector convension or least OpenGL does. If those involved with Boost are interested, I would like to donate the code for use in developing the capabilities here. Dave Hickerson -----Original Message----- From: Geoff Carlton [mailto:gcarlton@iinet.net.au] Sent: Wednesday, June 29, 2005 8:22 PM To: boost(a)lists.boost.org Subject: Re: [boost] Library Proposal: Boost.Geom 2D and 3DGeometricPrimitives Hickerson, David A wrote: > I have done some of this in the library I wrote in 97. I'd be curious to see that. I'd like a simple, common set of geom classes. The concept of these traits is a very interesting and clever one, but I don't think its useful in practice. You'd want a simple set of classes, and if they are generically useful then the conversion to library variants is simple: either construct a new temporary, or even a straight reinterpret_cast for performance. In particular, the basics are: 1.) Easy definition Preferably: class point2i; // descended from point2<int> void DoSomething(const point2i& mypoint); Alternatively: template<class T> class point2; typedef point2<int> mypoint2i; void DoSomething(const point2i& mypoint); 2.) Easy instantiation Definitely: point2i pos(1,2); Ideally (somehow): point2i pos2[2] = { { 3, 4 }, { 5, 6 } }; 3.) Very clear class layout So we can know when reinterpreting the object is possible. 4.) Minimum of templates and macros Want this to be compile-able across the board, and simple to understand. 5.) Basic methods in class Length(), LengthSq(), Normalise(), etc 6.) Set of algorithm functions to operate on these types Similar to STL, a separate group of functions. Having written all this, its hard to go past the MagicSoftware library. It defines many basic primitives and then a whole lot of useful operating functions. Hmm.. I should probably just use that in the future. :) Geoff _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

Boost Installer using NSIS
by Christopher Boumenot 30 Jun '05

30 Jun '05

Greetings, I been following the discussion about the generation of a Boost installer, and decided to take the plunge. I have the beginning of a Boost installer. It's a Perl script that scans an already installed version of Boost and generates a generic XML description. (I envision the release manager building Boost and then uploading the Windows installer to sourceforge.net.) This XML description is fed back into the script, and it generates an NSIS script. I've been doing some testing on my system. Using the free compiler from Microsoft (Windows 2003 Toolkit) and building Boost myself results in about 525 MB of data. Using the NSIS installer brings the entire installation down to 10.5 MB, a sizeable reduction. Not all of the targets are built because the toolkit doesn't ship with all of the necessary libraries. I think people were quoting 700 MB or so, that should still result in a small installer. The XML file is broken up into modules, or libraries. It uses bcp to generate a list of dependencies for each module. Only those files necessary are installed. The list of modules is generated dynamically based on the top-level files located in the include/boost-1_XX/boost. The library directory is also scanned to determine which files correspond to which module. (This is on my TODO list, see boostal.pl for details.) It should be easy to add support for other installers. They can parse the XML file to get all of the information they need. More information can be added as necessary I've placed the script on the Web for perusal: http://www.divebomb.org/proj/scripts/boostal.tgz, and the generated NSIS file is available http://www.divebomb.org/proj/scripts/boost.nsi.gz. I've added more documentation to the script about how it works. I'm also looking at the Boost builder GUI for Windows as well. (Someone had suggested win32gui as a start, and that looks good to me.) Let me know what you think, if this works, what needs to be addressed/fixed/tweak, etc. Christopher

1 0