Standard library and managed objects

[Ioannis Vranos]

So to be more excited, will it be possible to use standard library
containers with handles in VC++ 2005/.NET 2.0 era?
Like this:
vector<Button ^>buttonArray;

and with managed objects in the stack:
vector<Button>b uttonArray; // ?

Regards,

Ioannis Vranos

[Ronald Laeremans [MSFT]]

We are working on a library using the same patterns as standard STL that
works with ref, value and enum class types. It is not in Beta 1, but we hope
that it will make Beta 2 (and release) for VS 2005.

Ronald Laeremans
Visual C++ team

"Ioannis Vranos" <iv*@guesswh.at .grad.com> wrote in message
news:uZ******** ******@TK2MSFTN GP11.phx.gbl...

So to be more excited, will it be possible to use standard library
containers with handles in VC++ 2005/.NET 2.0 era?
Like this:
vector<Button ^>buttonArray;

and with managed objects in the stack:
vector<Button>b uttonArray; // ?

Regards,

Ioannis Vranos

[Russell Hind]

The documentation I've seen for Whidbey says you still have to use
gcroot which is a shame. It would be nice if the compiler could
auto-generate the handle-wrapping for you when it saw the ^ in unmanaged
objects.

std::vector<gcr oot<Button^> > buttonArray;

Cheers

Russell

Ioannis Vranos wrote:

So to be more excited, will it be possible to use standard library
containers with handles in VC++ 2005/.NET 2.0 era?
Like this:
vector<Button ^>buttonArray;

and with managed objects in the stack:
vector<Button>b uttonArray; // ?

Regards,

Ioannis Vranos

[Ioannis Vranos]

Russell Hind wrote:

The documentation I've seen for Whidbey says you still have to use
gcroot which is a shame. It would be nice if the compiler could
auto-generate the handle-wrapping for you when it saw the ^ in unmanaged
objects.

std::vector<gcr oot<Button^> > buttonArray;

The above style is lame. I had heard that managed and unmanaged code
would be able to be combined more elegantly in VS 2005 (something like
"an STL library working with managed objects"). The above means, that
everything remains the same!


Regards,

Ioannis Vranos

[Ronald Laeremans [MSFT]]

"an STL library working with managed objects".

Which is about what I said in my previous message in this thread.

Ronald

"Ioannis Vranos" <iv*@guesswh.at .grad.com> wrote in message
news:uK******** ******@TK2MSFTN GP09.phx.gbl...

Russell Hind wrote:

The documentation I've seen for Whidbey says you still have to use gcroot
which is a shame. It would be nice if the compiler could auto-generate
the handle-wrapping for you when it saw the ^ in unmanaged objects.

std::vector<gcr oot<Button^> > buttonArray;

The above style is lame. I had heard that managed and unmanaged code would
be able to be combined more elegantly in VS 2005 (something like "an STL
library working with managed objects"). The above means, that everything
remains the same!


Regards,

Ioannis Vranos

[Ronald Laeremans [MSFT]]

This full type system unification is a potential feature of the next release
after 2005.

What we are trying to deliver in the 2005 release is a set of containers
that work directly with handles. Which is in most cases what you would want
to use in the case where you want a collection of managed types for
performance reasons.

Ronald

"Russell Hind" <no****@no-where.com> wrote in message
news:OV******** ******@TK2MSFTN GP10.phx.gbl...

The documentation I've seen for Whidbey says you still have to use gcroot
which is a shame. It would be nice if the compiler could auto-generate
the handle-wrapping for you when it saw the ^ in unmanaged objects.

std::vector<gcr oot<Button^> > buttonArray;

Cheers

Russell

Ioannis Vranos wrote:

So to be more excited, will it be possible to use standard library
containers with handles in VC++ 2005/.NET 2.0 era?
Like this:
vector<Button ^>buttonArray;

and with managed objects in the stack:
vector<Button>b uttonArray; // ?

Regards,

Ioannis Vranos

[Russell Hind]

From reading your posts, I am a little confused. Are you saying you
are working on a library that will have containers that are 'similar' to
STL containers,

Or are you customising the STL that is used in managed code so that it
can deal with ^ objects? i.e. are we going to be able to write

std::vector<But ton^> MyVector

or will it be

{namespace}::{v ector_class}<Bu tton^> MyVector;

where {namespace} and {vector_class} are yet to be announced?

Thanks

Russell

Ronald Laeremans [MSFT] wrote:

This full type system unification is a potential feature of the next release
after 2005.

What we are trying to deliver in the 2005 release is a set of containers
that work directly with handles. Which is in most cases what you would want
to use in the case where you want a collection of managed types for
performance reasons.

Ronald

[Tomas Restrepo \(MVP\)]

Hi Russell,

From reading your posts, I am a little confused. Are you saying you
are working on a library that will have containers that are 'similar' to
STL containers,

Or are you customising the STL that is used in managed code so that it
can deal with ^ objects? i.e. are we going to be able to write

std::vector<But ton^> MyVector

or will it be

{namespace}::{v ector_class}<Bu tton^> MyVector;

where {namespace} and {vector_class} are yet to be announced?

Potentially, both. The second scenario is what they are trying to enable for
Whidbey, but the first one, which would support full type unification
(managed and unmanaged mixed seamlessly) is something they are looking at
post-whidbey

I hope I got it right, Ronald ;)
--
Tomas Restrepo
to****@mvps.org

[Russell Hind]

Tomas Restrepo (MVP) wrote:

Potentially, both. The second scenario is what they are trying to enable for
Whidbey, but the first one, which would support full type unification
(managed and unmanaged mixed seamlessly) is something they are looking at
post-whidbey

I hope I got it right, Ronald ;)

This was my understanding of Ronald's statements.

I wonder if the intermediate step is worth the effort? Personally, I'd
rather use

std::vector<gcr oot<Button^> > rather than a new class even if the
'interface' is common.

I'm already used to using

std::vector<boo st::shared_ptr< Class> > all over the place anyway so an
intermediate step of a different library doesn't seem worth the hassle
for me.

Are there any performance/hidden advantages to the intermediate solution
over using gcroot?

Thanks

Russell

[Ioannis Vranos]

Tomas Restrepo (MVP) wrote:

std::vector<B utton^> MyVector

or will it be

{namespace}:: {vector_class}< Button^> MyVector;

where {namespace} and {vector_class} are yet to be announced?

Potentially, both. The second scenario is what they are trying to enable for
Whidbey, but the first one, which would support full type unification
(managed and unmanaged mixed seamlessly) is something they are looking at
post-whidbey

I hope I got it right, Ronald ;)

But the second has not anything to do with the C++ standard library, and
we talking about standard library containers and algorithms working with
handles (at least).


Regards,

Ioannis Vranos