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

Re: [boost] Library Proposal: Boost.Geom 2D and 3D Geometric Primitives
by Anis Benyelloul 02 Jul '05

02 Jul '05

> Sérgio Vale e Pace wrote: > graphical libraries usually are incompatible and sometimes even > "unusual" for a reason, performance, when you´re processing lots and > lots of points per second, the simple act of calling a non inline > function is too much overhead. I totally agree with you. But, who said that my code was calling non-inline functions ? > Don´t take me wrong I also believe that > a "unique" implementation for points would be great, but such > implementation is not trivial. Sorry, I actually don't beleive so. I do not intend to create just one more implementation for points and rectangles, I want to give points and rectangles of *others* the same inteface. Yes, after having specialized some traits class you'll be able to write : geom::point<QPoint> pt; // use QPoint as an implementation geom::box<SDL_Rect> bx; // use SDL Rect as an implementation // Now mix ! bx+=pt; // !! // And still be able to extract the QPoint out of pt; QDrawPoint(pt.impl()); SDL_UpdateRect(&(bx.impl()); // And the SDL_Rect out of bx, at no cost ! > I´m not sure about the internals of > your implementation, Then you should check the 'Boost Sandbox File vault' for a file named geom.zip and make your own opinion. Reading through the documentation should give a better idea of the general "spirit" of the library. -- Anis Benyelloul -- Anis Benyelloul benyelloul(a)mailbolt.com -- http://www.fastmail.fm - mmm... Fastmail...

6 20

Re: [boost] Library Proposal: Boost.Geom 2D and 3D GeometricPrimi tives
by Martin Bonner 02 Jul '05

02 Jul '05

----Original Message---- From: Anis Benyelloul [mailto:benyelloul@mailbolt.com] > " There is no such a thing as a 2D point, There is even no such a > thing as 2D, the world is 3D, and all points are 3D. Now, some point > are always located on Z=0 plan and don't need to actually store their > Z attribute, we call them 2D points." Actually one of the current popular physical theories is that the world is 11D (or is it 15?). [Snip] >> Mixing 2D and 3D points doesnt actually happen in my experience. >> They live in separate spaces. > Like I say, 2D points are elements of IRxIR which is U which is part > of IRxIRxIR which is the set of all 3D points. It just a matter of > how you look at things .. Yes, but insisting that people consider 2D points a subset of 3D points (rather than a different concept which is isomorphic with a subset of 3D points), is probably a mistake. -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

2 1

Re: [boost] Library Proposal: Boost.Geom 2D and 3D GeometricPrimitives
by Hickerson, David A 02 Jul '05

02 Jul '05

I could not find the original message to look at the proposed code, is it on the web site some where? Here are my requirements for a Geometry library. 1. The primitives integrate with translational and rotational elements, such as homogenous transforms (4x4 matrices), quaterions, Euler angles, and translation vectors. 2. The translationals and rotation elements convert to one another where applicable. The rotational part of the homogenous transform convert to and from a rotational quaterion and to and from Euler angles, or quaterion to Euler angles. The translation parts can be extracted and set in the homogenous transform. 3. At a minimum, OpenGL array extraction from homogenous tranforms, points, and shapes. A float array in the order that OpenGL expects for these elements. Support for DirectX, and others would be good. I have done some of this in the library I wrote in 97. Dave -----Original Message----- From: Joel de Guzman [mailto:joel@boost-consulting.com] Sent: Tuesday, June 28, 2005 11:02 AM To: boost(a)lists.boost.org Subject: Re: [boost] Library Proposal: Boost.Geom 2D and 3D GeometricPrimitives Anis Benyelloul wrote: > Joel de Guzman <joel <at> boost-consulting.com> writes: > > >>How do you plan to implement your regions? If your Points can use >>native platform points, I assume your regions can also use native >>platform regions? Or are we talking about different things? I'm >>interested on how you can make it use the Macintosh classic Region, >>for example. > > > Well, let me think of it.... What is a region ? A collection of (non- > overlapping ?) boxes. Now what is a collection of boxes ? > - std::vector<box> > - boost::array<box, 20> > - box ; // Note: a single box ! > - XRegion ;// Maybe some pre-existing region object in other libraries > > As you see, the problem is quite the same: for one abstraction > (region) being > able to choose among many implementations, and just "plug" them in some > convenient wrapper class. > > Actually, I haven't studied much the subject, but it doesn't seem of > extrem > complexity ... Well, not so fast. Been there done that. The problem is how to interoperate on two regions. Example: I need to XOR a YRegion with a MacRegion. The thing is, a classic mac region is an opaque data type (actually, it's not implemented as a collection of boxes). The mere fact that it is opaque makes it impossible to even copy a mac region to a YRegion. Cheers, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

4 4

Boost.Build v2 with VC8
by Johan Johansson 01 Jul '05

01 Jul '05

How do you do it? I've tried adding using msvc : 8.0 to user.config and I've tried using msvc : vc-8_0 since that didn't appear to work. At that point I got the message that the python lib wouldn't be build - but I've set both PYTHON_ROOT and PYTHON_VERSION to the satisfaction of Boost.Build v1. Can someone please tell me what to configure and the exact command line I should use to build it? I've already spent 2 hours running in circles in the docs and that doesn't seem to get me anywhere. Thanks, Johan

2 1

[serialization] Regressions?
by Vladimir Prus 01 Jul '05

01 Jul '05

Hi Robert, I've just updated by Boost tree and run in a number of compile errors. One is pretty easy -- I've committed the attached trivial patch to split_member.hpp. Another is this: ....boost/boost/archive/detail/oserializer.hpp:551: error: incomplete type `boost::STATIC_ASSERTION_FAILURE<false>' does not have member `value' instantiated from this code of mine: ofstream ofs(av[2]); boost::archive::binary_oarchive oa(ofs); oa << *data_builder.finish(); Where 'finish' returns auto_ptr<Data>. It's looks like serialization checks if the serialized type is 'const' and if not, complains. Basically, it's some heuritic to prevent saving on-stack object (though I don't understand why it would work at al). I find this a bit too much . I have no reason whatsoever to make 'finish' return auto_ptr<const Data>. And writing oa << const_cast<const Data&>(*data_builder.finish()); looks very strange. And modifying all places where I get this error is not nice too. So, can this static assert be removed? Then, I get ambiguity in iserializer.hpp, in this code: #ifndef BOOST_NO_FUNCTION_TEMPLATE_ORDERING template<class Archive, class T> inline void load(Archive &ar, const serialization::nvp<T> &t){ load(ar, const_cast<serialization::nvp<T> &>(t)); } For some reason, both boost::archive::load and some other 'load' in 'boost' namespace (part of earlier serialization lib) that I still use are considered overload candidates. Adding explicit boost::archive:: fixes this. See attached patch. Then I get error at this code: ar << boost::lexical_cast<std::string>(*this); The error message is: error: no match for 'operator<<' in 'ar << boost::lexical_cast(Source) [with Target = std::basic_string<char, std::char_traits<char>, std::allocator<char> >, Source = lvk::nm_model::BlockFormula]()' /space/NM/boost/boost/archive/detail/interface_oarchive.hpp:75: error: candidates are: Archive& boost::archive::detail::interface_oarchive<Archive>::operator<<(T&) [with T = std::basic_string<char, std::char_traits<char>, std::allocator<char> >, Archive = boost::archive::binary_oarchive] ...unrelated operator<< definitions snipped... Apparently, passing rvalue to "T&" does not work. Yes another attached patch fixes this issue. - Volodya

9 73

[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] [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