STL-container used with references

[Pete Becker]

Re: STL-container used with references

Kevin Goodsell wrote:[color=blue]
>
> Pete Becker wrote:
>[color=green]
> > Mike Wahler wrote:
> >[color=darkred]
> >>What's the significance of the (namespace?) name 'tr1'?
> >>[/color]
> >
> >
> > The C++ standards committee has a Technical Report in the works,
> > incorporating recommended library extensions. It's known informally as
> > TR1, and its extensions go in namespace std::tr1.
> >[/color]
>
> I don't like the sound of this. Are they going to permanently put these
> things in std::tr1::?[/color]

TR1 puts them in std::tr1. Future TRs and future standards could do
something different.
[color=blue]
> Why wouldn't they just use std::?[/color]

Because they're recommended extensions and not part of the standard.
[color=blue]
> If they put it
> in std:: later, will they have to also support it in std::tr1:: for
> compatibility?
>[/color]

Maybe. Maybe the new stuff won't ever go into the standard.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

[Pete Becker]

Re: STL-container used with references

Kevin Goodsell wrote:[color=blue]
>
> Pete Becker wrote:
>[color=green]
> > Mike Wahler wrote:
> >[color=darkred]
> >>What's the significance of the (namespace?) name 'tr1'?
> >>[/color]
> >
> >
> > The C++ standards committee has a Technical Report in the works,
> > incorporating recommended library extensions. It's known informally as
> > TR1, and its extensions go in namespace std::tr1.
> >[/color]
>
> I don't like the sound of this. Are they going to permanently put these
> things in std::tr1::?[/color]

TR1 puts them in std::tr1. Future TRs and future standards could do
something different.
[color=blue]
> Why wouldn't they just use std::?[/color]

Because they're recommended extensions and not part of the standard.
[color=blue]
> If they put it
> in std:: later, will they have to also support it in std::tr1:: for
> compatibility?
>[/color]

Maybe. Maybe the new stuff won't ever go into the standard.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

[Kevin Goodsell]

Re: STL-container used with references

Pete Becker wrote:
[color=blue]
> Kevin Goodsell wrote:
>[color=green]
>>Why wouldn't they just use std::?[/color]
>
>
> Because they're recommended extensions and not part of the standard.
>[/color]

OK. I didn't make the connection that a TR is different from a TC, and
was thinking that this /would be/ part of the standard (the comment
"coming to your compiler soon" threw me off). If it's just a
possibility, this makes more sense.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

[Kevin Goodsell]

Re: STL-container used with references

Pete Becker wrote:
[color=blue]
> Kevin Goodsell wrote:
>[color=green]
>>Why wouldn't they just use std::?[/color]
>
>
> Because they're recommended extensions and not part of the standard.
>[/color]

OK. I didn't make the connection that a TR is different from a TC, and
was thinking that this /would be/ part of the standard (the comment
"coming to your compiler soon" threw me off). If it's just a
possibility, this makes more sense.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

[Sergei Matusevich]

Re: STL-container used with references

On 2004-04-06, Severin Ecker <secker@gmx.a t> wrote:
[color=blue]
> std::vector<Ele ment &> vec;[/color]

[...]
[color=blue]
> what i want to avoid (if possible) are 2 things:
> dynamic allocation of the objects, and having an extracontiner for every
> type derived from the basetype to store the elements.
>
> i hope, i made clear what i'm trying to do... so is there a solution (except
> for the 2 mentioned above?)[/color]

Severin,

You cannot have a container of references, but you very well can have
a container of pointers, i.e. something like std::vector<Ele ment*>.
Better yet, you can use smart pointers, e.g. boost::shared_p tr<Element>.
In any case, remember that you have to dereference pointers (e.g. using
functors) when you access the data (for example, using standard
algorithms).

You may also want to make your Element class a lightweight proxy that
holds a reference to an actual data stored outside the container.
(Some kind of a Featherweight pattern?)

Hope this helps!
Sergei.

--
Sergei Matusevich,
Brainbench MVP for C++

http://www.brainbench.com

[Sergei Matusevich]

Re: STL-container used with references

On 2004-04-06, Severin Ecker <secker@gmx.a t> wrote:
[color=blue]
> std::vector<Ele ment &> vec;[/color]

[...]
[color=blue]
> what i want to avoid (if possible) are 2 things:
> dynamic allocation of the objects, and having an extracontiner for every
> type derived from the basetype to store the elements.
>
> i hope, i made clear what i'm trying to do... so is there a solution (except
> for the 2 mentioned above?)[/color]

Severin,

You cannot have a container of references, but you very well can have
a container of pointers, i.e. something like std::vector<Ele ment*>.
Better yet, you can use smart pointers, e.g. boost::shared_p tr<Element>.
In any case, remember that you have to dereference pointers (e.g. using
functors) when you access the data (for example, using standard
algorithms).

You may also want to make your Element class a lightweight proxy that
holds a reference to an actual data stored outside the container.
(Some kind of a Featherweight pattern?)

Hope this helps!
Sergei.

--
Sergei Matusevich,
Brainbench MVP for C++

http://www.brainbench.com

[Thorsten Ottosen]

Re: STL-container used with references


"Sergei Matusevich" <motus2@yahoo.c om> wrote in message
news:Z4Gcc.2756 3$7r2.6081053@n ews4.srv.hcvlny .cv.net...
[snip][color=blue]
> You cannot have a container of references, but you very well can have
> a container of pointers, i.e. something like std::vector<Ele ment*>.
> Better yet, you can use smart pointers, e.g. boost::shared_p tr<Element>.[/color]

maybe even better, use a container that takes ownership of the pointers.

checkout the ptr_container lib in the boost sandbox.

br

Thorsten

[Thorsten Ottosen]

Re: STL-container used with references


"Sergei Matusevich" <motus2@yahoo.c om> wrote in message
news:Z4Gcc.2756 3$7r2.6081053@n ews4.srv.hcvlny .cv.net...
[snip][color=blue]
> You cannot have a container of references, but you very well can have
> a container of pointers, i.e. something like std::vector<Ele ment*>.
> Better yet, you can use smart pointers, e.g. boost::shared_p tr<Element>.[/color]

maybe even better, use a container that takes ownership of the pointers.

checkout the ptr_container lib in the boost sandbox.

br

Thorsten

[tom_usenet]

Re: STL-container used with references

On Tue, 06 Apr 2004 14:24:13 -0400, Pete Becker <petebecker@acm .org>
wrote:
[color=blue]
>Mike Wahler wrote:[color=green]
>>
>> What's the significance of the (namespace?) name 'tr1'?
>>[/color]
>
>The C++ standards committee has a Technical Report in the works,
>incorporatin g recommended library extensions. It's known informally as
>TR1, and its extensions go in namespace std::tr1.[/color]

How long till Dinkumware starts to track TR1 extensions? Will you wait
until its almost finalised or even finished (the conservative,
possibly sensible approach)?

Tom
--
C++ FAQ: http://www.parashift.com/c++-faq-lite/
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html

[tom_usenet]

Re: STL-container used with references

On Tue, 06 Apr 2004 14:24:13 -0400, Pete Becker <petebecker@acm .org>
wrote:
[color=blue]
>Mike Wahler wrote:[color=green]
>>
>> What's the significance of the (namespace?) name 'tr1'?
>>[/color]
>
>The C++ standards committee has a Technical Report in the works,
>incorporatin g recommended library extensions. It's known informally as
>TR1, and its extensions go in namespace std::tr1.[/color]

How long till Dinkumware starts to track TR1 extensions? Will you wait
until its almost finalised or even finished (the conservative,
possibly sensible approach)?

Tom
--
C++ FAQ: http://www.parashift.com/c++-faq-lite/
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html

[Pete Becker]

Re: STL-container used with references

tom_usenet wrote:[color=blue]
>
> 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]

If all goes well, the technical work on TR1 will be finished in October.
A significant number of changes from the original proposals have been
the result of our work implementing it.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

[Pete Becker]

Re: STL-container used with references

tom_usenet wrote:[color=blue]
>
> 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]

If all goes well, the technical work on TR1 will be finished in October.
A significant number of changes from the original proposals have been
the result of our work implementing it.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

[Dietmar Kuehl]

Re: STL-container used with references

tom_usenet <tom_usenet@hot mail.com> wrote:[color=blue]
> 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.

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...).
--
<mailto:dietmar _kuehl@yahoo.co m> <http://www.dietmar-kuehl.de/>
<www.contendix. com> - Software Development & Consulting

[Dietmar Kuehl]

Re: STL-container used with references

tom_usenet <tom_usenet@hot mail.com> wrote:[color=blue]
> 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.

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...).
--
<mailto:dietmar _kuehl@yahoo.co m> <http://www.dietmar-kuehl.de/>
<www.contendix. com> - Software Development & Consulting

[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