plib-devel

[Plib-devel] sg & STL

[Amit B. <am...@cr...>]

Has anyone tried putting any of the sg* types into an STL container yet?
I tried it but it doesnt work as most types are typedef'd to float[n]. I was
thinking of wrapping the simple types into a class which provides proper
operators so that the sg* functions still work. Has anyone done this yet?

Re: [Plib-devel] sg & STL

[Curtis L. O. <cu...@me...>]

Amit Bakshi writes:
> Has anyone tried putting any of the sg* types into an STL container yet?
> I tried it but it doesnt work as most types are typedef'd to float[n]. I was
> thinking of wrapping the simple types into a class which provides proper
> operators so that the sg* functions still work. Has anyone done this yet?

Just so you know, the plib author is not exactly thrilled with using
the STL (probably mostly because of the portability issues it
creates.)  There is a wide variety of STL implimentations (or various
stages of implimentations) out there which can cause a lot of
compatibility problems between the various compilers.

Before you get too far down this path, you probably will want to have
a serious discussion about it with Steve because I doubt he will be in
favor of making these sorts of modifications to plib.

Regards,

Curt.
-- 
Curtis Olson   Human Factors Research Lab       Flight Gear Project
Twin Cities    cu...@hf...                cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org

Re: [Plib-devel] sg & STL

[Steve B. <sjb...@ai...>]

"Curtis L. Olson" wrote:
> 
> Amit Bakshi writes:
> > Has anyone tried putting any of the sg* types into an STL container yet?
> > I tried it but it doesnt work as most types are typedef'd to float[n]. I was
> > thinking of wrapping the simple types into a class which provides proper
> > operators so that the sg* functions still work. Has anyone done this yet?
> 
> Just so you know, the plib author is not exactly thrilled with using
> the STL (probably mostly because of the portability issues it
> creates.)  There is a wide variety of STL implimentations (or various
> stages of implimentations) out there which can cause a lot of
> compatibility problems between the various compilers.

Yep - as Curt predicts - I'm not very fond of STL - but I don't think
that's the issue here.
 
> Before you get too far down this path, you probably will want to have
> a serious discussion about it with Steve because I doubt he will be in
> favor of making these sorts of modifications to plib.

Does this actually require making changes to SG?

SG is really the most basic low level thing - I quite expect you to
want to wrap it with other things when you need to - but to use it
"raw" when speed is needed (eg in SSG).

However, I don't see a whole lot of benefit to including those
wrappers in PLIB...and as usual I'm very averse to adding dependancies
to PLIB.

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

Re: [Plib-devel] sg & STL

[Amit B. <am...@de...>]

I was under the impression that STLport was quite portable.
Anyway, I don't care too much if my modification would make
it to the official plib. I was just wondering if anyone has attempted
this before. Surely I can't be the only one using STL :)

Regards,
Amit

 "Curtis L. Olson" wrote
>
> Just so you know, the plib author is not exactly thrilled with using
> the STL (probably mostly because of the portability issues it
> creates.)  There is a wide variety of STL implimentations (or various
> stages of implimentations) out there which can cause a lot of
> compatibility problems between the various compilers.
> 
> Before you get too far down this path, you probably will want to have
> a serious discussion about it with Steve because I doubt he will be in
> favor of making these sorts of modifications to plib.
> 
> Regards,
> 
> Curt.

Re: [Plib-devel] sg & STL

[Curtis L. O. <cu...@in...>]

Amit Bakshi writes:
> I was under the impression that STLport was quite portable.
> Anyway, I don't care too much if my modification would make
> it to the official plib. I was just wondering if anyone has attempted
> this before. Surely I can't be the only one using STL :)

We use the STL extensively in the flightgear project, but have had to
do a lot of fancy stepping, portability work, etc. to maintain
compatibility.  You'd really be surprised at the STL variants out
there.  They are often generally the same, but between different
versions of the STL, different stages of implimentation, etc.  It's
not even just differences between platforms or compilers, there are
often differences between versions of compilers.  The STL has a lot of
good points which is why the flightgear project uses it, just be
prepaired for a lot of headaches and a lot of extra work if you want
your project to be portable.

Regards,

Curt.
--
Curtis Olson   Human Factors Research Lab       Flight Gear Project
Twin Cities    cu...@hf...                cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org

Re: [Plib-devel] sg & STL

[<Va...@t-...>]

Amit Bakshi wrote:
> 
> Has anyone tried putting any of the sg* types into an STL container yet?
> I tried it but it doesnt work as most types are typedef'd to float[n]. I was
> thinking of wrapping the simple types into a class which provides proper
> operators so that the sg* functions still work. Has anyone done this yet?

The WeatherDatabase of the FlightGear project has wrappers for the basic
sg types (actually, only the vectors).

The reason why I had to wrap them, was that I wanted to store them in a
vector (or was it a list?).

It's very easy to achieve that. So I think that everybody could do it
himself in the own code if Steve doesn't want it in PLIB. But we might
consider putting it in the yet to come Aux library.

Hm, it'll perhaps might be a good idea to move the FGFS STL
inportability handling to the Aux library, so that other projects can
benefit.

CU,
Christian