[ODE] ODE and the STL
hidden.asbestos at googlemail.com
Sun Dec 24 16:42:04 MST 2006
> Your argument on the bug tracker is too vague. Would you mind citing
> some of those platforms where STL is undesirable or broken?
Yeah, sorry for being vague, to clarify I had PS2 in mind. When I was
working on a game for that system a few years back, seemingly we
didn't have a particularly robust STL implementation. However I
generally like to make claims proportional to the amount of supporting
evidence I have, and unfortunately I didn't spend very long looking
into the reasons STL wasn't favoured on the project that I joined.
In general terms, I agree - none of the platforms I'm using ODE on
have a "broken" STL (currently Win32 and PSP). I think my problem with
using STL is that it seems, to me, a bad idea for it to creep into
what is essentially the extremities of the library. If the body or
joint management code were using it, this email wouldn't exist.
> Well, if you make it have the same interface as STL, I see no problem
> providing it as a configure-time fallback for STL-less systems.
Sorry, this was not my intention - I just wanted to contribute a
lightweight equivalent to std::list and std::vector to help out with
alternatives to using the STL, (which I do believe is not the right
thing to do here, but that's just my opinion)
> But I don't think it's feasible to maintain it, as once the STL is used
> somewhere, there's nothing preventing it from going to other places.
This is exactly why I raised this issue on the mailing list.
At this point in time, no STL is used in ODE - integrating this new
heightfield patch would change that, and I didn't want to be the one
to seemingly green-light this as acceptable without consulting with
people it might have a big impact on.
More information about the ODE