 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Languages / Managed C++ / July 2004Standard library and managed objects
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 > So to be more excited, will it be possible to use standard library > containers with handles in VC++ 2005/.NET 2.0 era? [quoted text clipped - 10 lines] > > Ioannis Vranos 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 > So to be more excited, will it be possible to use standard library > containers with handles in VC++ 2005/.NET 2.0 era? [quoted text clipped - 10 lines] > > Ioannis Vranos > 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; 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 >> 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 [quoted text clipped - 10 lines] > > Ioannis Vranos 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 > 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 [quoted text clipped - 20 lines] >> >> Ioannis Vranos 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 > This full type system unification is a potential feature of the next release > after 2005. [quoted text clipped - 5 lines] > > Ronald 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 [quoted text clipped - 10 lines] > > 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 ;)  SignatureTomas Restrepo tomasr@mvps.org 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<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 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. 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.... SignatureTomas Restrepo tomasr@mvps.org Tomas Restrepo (MVP) wrote: > 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.... 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 > Tomas Restrepo (MVP) wrote: >> [quoted text clipped - 26 lines] > > 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 [quoted text clipped - 26 lines] > > I hope this post also addresses Ioannis' comments later in the thread. 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 Tomas Restrepo (MVP) wrote: >>std::vector<Button^> MyVector >> [quoted text clipped - 10 lines] > > 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
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.