STL-container used with references

[P.J. Plauger]

Re: STL-container used with references

"Dietmar Kuehl" <dietmar_kuehl@ yahoo.com> wrote in message
news:5b15f8fd.0 404070821.706a1 ade@posting.goo gle.com...
[color=blue]
> tom_usenet <tom_usenet@hot mail.com> wrote:[color=green]
> > How long till Dinkumware starts to track TR1 extensions? Will you wait
> > until its almost finalised or even finished (the conservative,
> > possibly sensible approach)?[/color]
>
> I cannot speak for Dinkumware, of course, but I know that library writers
> are already implementing what is currently in the TR. Actually, quite a
> few of the defects we processed two weeks ago seem to come from people
> implementing the TR.
>
> Of course, this is no indication when there will be a release of the TR
> components, even if they closely track what is going on: since there are
> probably still some changes which will be applied, I think it would be
> unwise to release an implementation of the TR libraries just now. I would
> expect that you will be able to purchase or download a version relatively
> soon after the TR is finalized. I'm always confusing the data but I think
> the plan is to try and essentially finalize the TR at the next meeting ie.
> in October in Redmont.[/color]

Correct, and as Pete Becker indicated, Dinkumware has been implementing all
of
the pieces of TR1 for over a year now. We hope to have a *full* version soon
after the document freezes, which we still hope will be this October. Note
that it's a *very big* addition, including all of the functions added to C
with C99.
[color=blue]
> BTW, does anybody have a good open source implementation of the special
> functions in the lib TR? Well, not necessarily in C or C++ but at least
> the same functionality - or an idea how this stuff can be implemented?
> Some people apparently know how to do such stuff but I considered numerics
> a waste of time while at the university and in any case they didn't talk
> about computing these functions anyway (as far as I can remember...).[/color]

The C committee has asked for an appendix to their special functions TR
to indicate at least some way to implement each of these functions. Our
work to date has unearthed a few free functions that are excellent, quite
a few that are barely adequate to float precision, and numerous approaches
that are mediocre but make a reasonable starting point. If there's a
complete, high quality set out there we haven't found it yet. They're
pretty tough, in general.

P.J. Plauger
Dinkumware, Ltd.

http://www.dinkumware.com

[Harald Nowak]

Re: STL-container used with references

> maybe even better, use a container that takes ownership of the pointers.[color=blue]
>
> checkout the ptr_container lib in the boost sandbox.
>
> br
>
> Thorsten[/color]

Now THIS is finally what I've been waiting for for the last 5 years -
a crucial missing piece - I do certainly hope that the ptr_container
will make it into the official boost branch and from there as quickly
as possible into the standard (or the tr).
In the last years I've continuously pointed out that omission and
tried to provide workarounds that deal with STL containers of pointers
- most of the time people seemed just happy with containers of
shared_ptr's but the main point is and was, that it is dangerous and
yet at the same time possible to use normal pointers in STL
containers: dangerous because algorithms can be innocently applied (as
long as the functors are written appropriately) and yet have
devastating effects (leaks and crashes - see my Short Tip in C++ Users
Journal: "A remove_if for vector", C/C++ Users Journal, July 2001. ).
If finally a dedicated version of the STL containers exist (like
ptr_container delivers) users will be guided the correct way - thats
why I appreciate this library so much.

[Harald Nowak]

Re: STL-container used with references

> maybe even better, use a container that takes ownership of the pointers.[color=blue]
>
> checkout the ptr_container lib in the boost sandbox.
>
> br
>
> Thorsten[/color]

Now THIS is finally what I've been waiting for for the last 5 years -
a crucial missing piece - I do certainly hope that the ptr_container
will make it into the official boost branch and from there as quickly
as possible into the standard (or the tr).
In the last years I've continuously pointed out that omission and
tried to provide workarounds that deal with STL containers of pointers
- most of the time people seemed just happy with containers of
shared_ptr's but the main point is and was, that it is dangerous and
yet at the same time possible to use normal pointers in STL
containers: dangerous because algorithms can be innocently applied (as
long as the functors are written appropriately) and yet have
devastating effects (leaks and crashes - see my Short Tip in C++ Users
Journal: "A remove_if for vector", C/C++ Users Journal, July 2001. ).
If finally a dedicated version of the STL containers exist (like
ptr_container delivers) users will be guided the correct way - thats
why I appreciate this library so much.