Standard library and managed objects

  • Thread starter Thread starter Ioannis Vranos
  • Start date Start date
I

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>buttonArray; // ?





Regards,

Ioannis Vranos
 
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
 
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<gcroot<Button^> > buttonArray;

Cheers

Russell
 
Russell said:
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<gcroot<Button^> > buttonArray;
Click to expand...


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
 
"an STL library working with managed objects".

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

Ronald
 
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
 
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<Button^> MyVector

or will it be

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

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

Thanks

Russell
 
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<Button^> MyVector

or will it be

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

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

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 said:
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 ;)
Click to expand...

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<gcroot<Button^> > rather than a new class even if the
'interface' is common.

I'm already used to using

std::vector<boost::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
 
Tomas said:
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 ;)
Click to expand...



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
 
Hi Russell,
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<gcroot<Button^> > rather than a new class even if the
'interface' is common.
Click to expand...

Well, I believe it could be. I'm not sure exactly what the new library would
contain, but one could fairly safely assumme that it would be highly tuned
towards providing correct supports for several .NET specific idioms and
programming issues... that is, consider things like the GC model, value vs.
reference types, resource-management (IDiposable support) and so on....
 
Tomas said:
Well, I believe it could be. I'm not sure exactly what the new library would
contain, but one could fairly safely assumme that it would be highly tuned
towards providing correct supports for several .NET specific idioms and
programming issues... that is, consider things like the GC model, value vs.
reference types, resource-management (IDiposable support) and so on....
Click to expand...

I guess the IDisposable would be a big winner for cleanup. I'd
forgotten about that as I'm fairly new to managed stuff (coming from
Borland's VCL).

Thanks

Russell
 
You should not consider that an intermediate step. Even with full type
unification, objects that don't cross the boundary (between GC collected and
native) will have significantly superior performance than mixed objects (or
mixing the type of the collection with the type of contained object).

We cannot do magic, both worlds still play by separate rules. E.g. a mixed
type will have a separate managed and native part and pointers going both
ways. Creating an instance will require both a gc heap allocation and a C++
heap allocation. For std::containers, the overhead of a handle for each
contained object and the indirection through the handle for each operation
on an element is also not free.

We definitely could not fit the full unification support in the current
release, but apart from that, the fact that we will have significant amount
of real world code written both by external VC customers and inside
Microsoft will significantly benefit the eventual implementation of the
unification support and a good understanding of when it will be appropriate
to use which features. Of course premature optimization is never worthwhile,
but an understanding that some of the support will have associated costs
will still be essential IMO.

Specifically for our managed object implementation of STL type collections,
we expect it to be extremely close to the C++ standard, however there are a
few requirements on the std::collections that could not be met (or could not
be met in an implementation where other things like performance and perhaps
even verifiability are also priorities). I do think that supporting the
containers, iterators, algorithms style collections for .net types in an
ideal way is gong to add significant value.

I hope this post also addresses Ioannis' comments later in the thread.

Ronald
 
Ronald said:
You should not consider that an intermediate step. Even with full type
unification, objects that don't cross the boundary (between GC collected and
native) will have significantly superior performance than mixed objects (or
mixing the type of the collection with the type of contained object).

We cannot do magic, both worlds still play by separate rules. E.g. a mixed
type will have a separate managed and native part and pointers going both
ways. Creating an instance will require both a gc heap allocation and a C++
heap allocation. For std::containers, the overhead of a handle for each
contained object and the indirection through the handle for each operation
on an element is also not free.

We definitely could not fit the full unification support in the current
release, but apart from that, the fact that we will have significant amount
of real world code written both by external VC customers and inside
Microsoft will significantly benefit the eventual implementation of the
unification support and a good understanding of when it will be appropriate
to use which features. Of course premature optimization is never worthwhile,
but an understanding that some of the support will have associated costs
will still be essential IMO.

Specifically for our managed object implementation of STL type collections,
we expect it to be extremely close to the C++ standard, however there are a
few requirements on the std::collections that could not be met (or could not
be met in an implementation where other things like performance and perhaps
even verifiability are also priorities). I do think that supporting the
containers, iterators, algorithms style collections for .net types in an
ideal way is gong to add significant value.

I hope this post also addresses Ioannis' comments later in the thread.
Click to expand...


That is a good approach indeed. However, for STL facilities which will
not be implemented yet to support handles explicitly, making the
compiler to understand that when ^ is met in a template instantiation,
to use gcroot implicitly, instead of requiring us to write that ugly
stuff would be a significant improvement (and a simple thing I think).






Regards,

Ioannis Vranos
 
Back
Top