1 May 01:03
Re: Geometry Template Library from Intel
Hartmut Kaiser <hartmut.kaiser <at> gmail.com>
2008-04-30 23:03:37 GMT
2008-04-30 23:03:37 GMT
> That's good news. I feared that you had been frightened-off by the > previous discussions. > > Although it's good to have the code, and no doubt some people who can > scan C++ faster than I can will really appreciate it, what I'd love to > see is more in the way of rationale and concept-documentation. For > example: > > - My recollection of the last part of the discussions the first time > around was that they focused on the "nasty" way in which you made it > possible to adapt a legacy struct to work with your library, and in > particular how you added methods to the class by casting from a base > class to a subclass. It would be great to see a write up of the > rationale for that compared with the alternatives. Perhaps this could > just be distilled out of the previous discussions. My feeling is that > it may come down to this: what you've done is the most pragmatic > solution for your environment, but it isn't something that could ever > make it into the C++ standard library (since it used casts in a > non-standards-compliant way). So, should Boost only accept libraries > that could be acceptable for C++, or could Boost have a more liberal > policy? Also, how much weight should be put on the "legacy" benefits > of your approach? My feeling is that the standard library, and Boost, > typically prefer to "do it right as if you could start all over again", > rather than fitting in with legacy problems. Even more as it is possible to write the algorithms in a way that these are agnostic of the concrete point data type used (as long as there are adaptors available, allowing to make this point type compatible with the expected point concept). Joel explicitly alluded to that in the first discussion and I think there is no other way forward. Remember, Boost is a collection of(Continue reading)
I will *not* do that.
Actually, I'm *not* at all interested in floating point arithmetic.
I wrote the floating point classification functions
for one reason only: I needed them.
The native fp classification functions on MSVC 7.1 do not handle
single precision floating point numbers correctly,
so I had to put together my own.
--Johan
_______________________________________________
Unsubscribe & other changes: 
RSS Feed