C++ standard library facilities & .NET 
Author Message
 C++ standard library facilities & .NET

Is it possible in VC++ .NET to use the standard library containers inside
.NET code? For example to use a
vector<MenuItem *> inside a form. All my efforts failed.

--
Ioannis

* Programming pages: http://www.*-*-*.com/
* Alternative URL: http://www.*-*-*.com/



Sat, 20 Aug 2005 14:23:13 GMT  
 C++ standard library facilities & .NET

Quote:

>Is it possible in VC++ .NET to use the standard library containers inside
>.NET code? For example to use a
>vector<MenuItem *> inside a form. All my efforts failed.

I think the trick is to #include <vcclr.h> and use gcroot, e.g.

 vector< gcroot<MenuItem*> >

The gcroot template allows an unmanaged class to contain __gc pointers.

--
Doug Harrison
Microsoft MVP - Visual C++



Sat, 20 Aug 2005 14:41:36 GMT  
 C++ standard library facilities & .NET


Quote:

> >Is it possible in VC++ .NET to use the standard library containers inside
> >.NET code? For example to use a
> >vector<MenuItem *> inside a form. All my efforts failed.

> I think the trick is to #include <vcclr.h> and use gcroot, e.g.

>  vector< gcroot<MenuItem*> >

> The gcroot template allows an unmanaged class to contain __gc pointers.

Unfortunately it is for use inside unmanaged classes. I want to use standard
library containers inside managed classes. But let me guess. MS wants to
lock us in its platform, right?

--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL: http://run.to/noicys



Sun, 21 Aug 2005 00:25:55 GMT  
 C++ standard library facilities & .NET

Quote:




>> >Is it possible in VC++ .NET to use the standard library containers inside
>> >.NET code? For example to use a
>> >vector<MenuItem *> inside a form. All my efforts failed.

>> I think the trick is to #include <vcclr.h> and use gcroot, e.g.

>>  vector< gcroot<MenuItem*> >

>> The gcroot template allows an unmanaged class to contain __gc pointers.

>Unfortunately it is for use inside unmanaged classes. I want to use standard
>library containers inside managed classes.

Right, sorry. You could however store a pointer to the vector and assume
explicit lifetime management for it in your managed class. This means
creating it in your ctor and deleting it in your dtor (finalizer).

--
Doug Harrison
Microsoft MVP - Visual C++



Sun, 21 Aug 2005 04:24:34 GMT  
 C++ standard library facilities & .NET


Quote:

> Right, sorry. You could however store a pointer to the vector and assume
> explicit lifetime management for it in your managed class. This means
> creating it in your ctor and deleting it in your dtor (finalizer).

It finally arrived. So i repost properly:

I do not understand what you mean. I placed

either a vector<MenuItem *>menuitems;

as a private member and made the constructor

CppForm():menuitems(3)
{
 // ...
 }

and it did not compile

or vector<MenuItem *> *menuitems

and made the constructor
{
 menuitems=new vector<MenuItem *>(3);
 // ...

Quote:
}

and still did not accept it.  So if you cannot use the standard library, it
means we have to learn other containers etc. However the benefit of the
standard library is that wherever you go you have vector, list, valarray,
... and you have not to learn similar containers but different in every
platform (the same applies and for the algorithms). How excellent it would
be if MS did it the right way! But can we expect that?...

--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL: http://run.to/noicys



Sun, 21 Aug 2005 12:46:39 GMT  
 C++ standard library facilities & .NET

????:Re: C++ standard library facilities & .NET

View this article only
?????? ?????????:microsoft.public.dotnet.languages.vc
??????????:2003-03-04 12:26:56 PST

Quote:




>> >Is it possible in VC++ .NET to use the standard library containers
inside
>> >.NET code? For example to use a
>> >vector<MenuItem *> inside a form. All my efforts failed.

>> I think the trick is to #include <vcclr.h> and use gcroot, e.g.

>>  vector< gcroot<MenuItem*> >

>> The gcroot template allows an unmanaged class to contain __gc pointers.

>Unfortunately it is for use inside unmanaged classes. I want to use
standard
>library containers inside managed classes.

Right, sorry. You could however store a pointer to the vector and assume
explicit lifetime management for it in your managed class. This means
creating it in your ctor and deleting it in your dtor (finalizer).

--
Doug Harrison
Microsoft MVP - Visual C++

==> That message strangely never arrived at my usenet server and i saw it at
google. Anyway.
==> I do not understand what you mean. I placed

either a vector<MenuItem *>menuitems;

as a private member and made the constructor

CppForm():menuitems(3)
{
 // ...
 }

and it did not compile

or vector<MenuItem *> *menuitems

and made the constructor
{
 menuitems=new vector<MenuItem *>(3);
 // ...

Quote:
}

and still did not accept it.  So if you cannot use the standard library, it
means we have to learn other containers etc. However the benefit of the
standard library is that wherever you go you have vector, list, valarray,
... and you have not to learn similar containers but different in every
platform (the same applies and for the algorithms). How excellent it would
be if MS did it the right way! But can we expect that?...

--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL: http://run.to/noicys



Sun, 21 Aug 2005 12:44:50 GMT  
 C++ standard library facilities & .NET

Quote:



>> Right, sorry. You could however store a pointer to the vector and assume
>> explicit lifetime management for it in your managed class. This means
>> creating it in your ctor and deleting it in your dtor (finalizer).

>It finally arrived. So i repost properly:

>I do not understand what you mean. I placed

>either a vector<MenuItem *>menuitems;

>as a private member and made the constructor

>CppForm():menuitems(3)
>{
> // ...
> }

>and it did not compile

>or vector<MenuItem *> *menuitems

>and made the constructor
>{
> menuitems=new vector<MenuItem *>(3);
> // ...
>}

>and still did not accept it.

You have to use gcroot to get the vector to store __gc pointers, and the
managed class which owns the vector has to store a pointer to the vector.
This is more or less what I had in mind:

// c.cpp

#using <mscorlib.dll>
using namespace System;

#include <vcclr.h>

#include <vector>

__gc class X
{
public:

   explicit X(int x)
   :  x_(x)
   {
   }

   void print()
   {
      Console::WriteLine(S"X::print = {0}", __box(x_));
   }

   int x_;

Quote:
};

__gc class Y
{
public:

   typedef std::vector< gcroot<X*> > VecT;

   Y()
   :  v(new VecT)
   {
      v->push_back(new X(0));
      (*v)[0]->print();
      v->push_back(new X(1));
      (*v)[1]->print();
   }

   ~Y()
   {
      Console::WriteLine(S"Deleting v");
      delete v;
   }

   VecT* v;

Quote:
};

int main()
{
   new Y;

Quote:
}

// end c.cpp

E>cl /GX /GR /Zc:forScope /Zc:wchar_t /W3 /clr c.cpp
Microsoft (R) C/C++ Optimizing Compiler Version 13.10.2292 for .NET
Framework
Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.

c.cpp
Microsoft (R) Incremental Linker Version 7.10.2292
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:c.exe
c.obj

E>c
X::print = 0
X::print = 1
Deleting v

So, it pretty much works. You basically take three hits. First, there's the
loss of convenience in having to use VecT*. Instead of saying v[0], you have
to say (*v)[0]. Second, you're storing gcroot<T*>, not T, which makes it a
little more complicated to use algorithms which operate on T. For example,
you'd have to write a custom operator< for gcroot<T*> to std::sort your
vector. Third, there's the efficiency hit in using gcroot, which in most
cases, I expect, can be ignored.

Quote:
>So if you cannot use the standard library, it
>means we have to learn other containers etc. However the benefit of the
>standard library is that wherever you go you have vector, list, valarray,
>... and you have not to learn similar containers but different in every
>platform (the same applies and for the algorithms). How excellent it would
>be if MS did it the right way! But can we expect that?...

Well, MS has said many times that C++ is a very important language in the
.NET universe. Since the initial release of VC7, which focused largely on
making VC work in both the managed and unmanaged worlds, even in the same
program (no small feat, BTW), MS has applied significant resources to make
the upcoming VC Everett release one of the most C++ Standard conformant
compilers on the market. It's no secret that MS has hired a couple of very
well-known C++ guys in the last couple of years. And it should be obvious
the VC team has increased its presence greatly in this group and others. So
I think some very good things have been happening in the VC++ world over the
past few years. As for what the future may hold, here's a Google search on
what the MS guys have been talking about:

http://groups.google.com/groups?q=future+MSFT+group%3Amicrosoft.publi...

--
Doug Harrison
Microsoft MVP - Visual C++



Sun, 21 Aug 2005 15:48:27 GMT  
 C++ standard library facilities & .NET


Quote:

> You have to use gcroot to get the vector to store __gc pointers, and the
> managed class which owns the vector has to store a pointer to the vector.
> This is more or less what I had in mind:

Ok i admit, it was my mistake. Did not use the (*myitems)[i] notion.

Quote:

> So, it pretty much works. You basically take three hits. First, there's
the
> loss of convenience in having to use VecT*. Instead of saying v[0], you
have
> to say (*v)[0]. Second, you're storing gcroot<T*>, not T, which makes it a
> little more complicated to use algorithms which operate on T. For example,
> you'd have to write a custom operator< for gcroot<T*> to std::sort your
> vector. Third, there's the efficiency hit in using gcroot, which in most
> cases, I expect, can be ignored.

==> It would be very nice if this "casting" to gcroot would not be needed in
the future. A first approach would be to make the "casting" to gcroot<T *>
implicit when a __gc type is passed as a template argument to an unmanaged
type and a template algorithm. Or something better.

Quote:
> Well, MS has said many times that C++ is a very important language in the
> .NET universe. Since the initial release of VC7, which focused largely on
> making VC work in both the managed and unmanaged worlds, even in the same
> program (no small feat, BTW), MS has applied significant resources to make
> the upcoming VC Everett release one of the most C++ Standard conformant
> compilers on the market. It's no secret that MS has hired a couple of very
> well-known C++ guys in the last couple of years. And it should be obvious
> the VC team has increased its presence greatly in this group and others.
So
> I think some very good things have been happening in the VC++ world over
the
> past few years. As for what the future may hold, here's a Google search on
> what the MS guys have been talking about:

==> Sorry for my "aggressiveness", i just have the impression for sometime
that MS many times behaves as if it has an "inferiority complex". That is
although it provides very good technology and IS a monopoly (which can be
good), it behaves as if its products are worse than the competition and it
tries to cheat. Well it may have been the case for some areas sometime in
the past, but now it is not, so there is no reason for such behaviour now
that it has become large and successfull. Its products are *good* & dominate
the market and i wonder for example why it has "insulted" Linux for example
in the past, that "it is a disease" or whatever, tries to use proprietary
protocols as if its products are not good and is afraid of Linux, or BeOS
for example. If it used standardised protocols it wouldn't lose any
customer. Lets get serious, proprietary protocols is what leads to
domination of Windows or functionality? I do not know, MS behaves as if it
has a perfect body with a hydrocephalic head.

That said when we will see a true RAD in VC++?

--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL: http://run.to/noicys



Mon, 22 Aug 2005 03:18:03 GMT  
 C++ standard library facilities & .NET
There is one more hit. Your unmanaged heap can be exhausted faster that you
might think it should. If you don't explicitly delete your managed objects
they can sit there forever taking a small bit of managed heap and a huge
chunk of unmanaged one. This is not a problem for C++ programs - everybody
knows how to manage shared resources. However if you expose your objects to
other application written in say VB you are in trouble. You have to make
your objects disposable. But even that doesn't solve all the problems. You
cannot control client code and if your methods return a new object somebody
can create a temporary: foo.Method().OtherMethod() - oops, should be Dim bar
as Bar: bar = foo.Method(): bar.OtherMethod(): bar.Dispose(). Yuck... I
wander why destructors are not supported on __value types?

thanks,
v



Quote:



> >> Right, sorry. You could however store a pointer to the vector and
assume
> >> explicit lifetime management for it in your managed class. This means
> >> creating it in your ctor and deleting it in your dtor (finalizer).

> >It finally arrived. So i repost properly:

> >I do not understand what you mean. I placed

> >either a vector<MenuItem *>menuitems;

> >as a private member and made the constructor

> >CppForm():menuitems(3)
> >{
> > // ...
> > }

> >and it did not compile

> >or vector<MenuItem *> *menuitems

> >and made the constructor
> >{
> > menuitems=new vector<MenuItem *>(3);
> > // ...
> >}

> >and still did not accept it.

> You have to use gcroot to get the vector to store __gc pointers, and the
> managed class which owns the vector has to store a pointer to the vector.
> This is more or less what I had in mind:

> // c.cpp

> #using <mscorlib.dll>
> using namespace System;

> #include <vcclr.h>

> #include <vector>

> __gc class X
> {
> public:

>    explicit X(int x)
>    :  x_(x)
>    {
>    }

>    void print()
>    {
>       Console::WriteLine(S"X::print = {0}", __box(x_));
>    }

>    int x_;
> };

> __gc class Y
> {
> public:

>    typedef std::vector< gcroot<X*> > VecT;

>    Y()
>    :  v(new VecT)
>    {
>       v->push_back(new X(0));
>       (*v)[0]->print();
>       v->push_back(new X(1));
>       (*v)[1]->print();
>    }

>    ~Y()
>    {
>       Console::WriteLine(S"Deleting v");
>       delete v;
>    }

>    VecT* v;
> };

> int main()
> {
>    new Y;
> }

> // end c.cpp

> E>cl /GX /GR /Zc:forScope /Zc:wchar_t /W3 /clr c.cpp
> Microsoft (R) C/C++ Optimizing Compiler Version 13.10.2292 for .NET
> Framework
> Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.

> c.cpp
> Microsoft (R) Incremental Linker Version 7.10.2292
> Copyright (C) Microsoft Corporation.  All rights reserved.

> /out:c.exe
> c.obj

> E>c
> X::print = 0
> X::print = 1
> Deleting v

> So, it pretty much works. You basically take three hits. First, there's
the
> loss of convenience in having to use VecT*. Instead of saying v[0], you
have
> to say (*v)[0]. Second, you're storing gcroot<T*>, not T, which makes it a
> little more complicated to use algorithms which operate on T. For example,
> you'd have to write a custom operator< for gcroot<T*> to std::sort your
> vector. Third, there's the efficiency hit in using gcroot, which in most
> cases, I expect, can be ignored.

> >So if you cannot use the standard library, it
> >means we have to learn other containers etc. However the benefit of the
> >standard library is that wherever you go you have vector, list, valarray,
> >... and you have not to learn similar containers but different in every
> >platform (the same applies and for the algorithms). How excellent it
would
> >be if MS did it the right way! But can we expect that?...

> Well, MS has said many times that C++ is a very important language in the
> .NET universe. Since the initial release of VC7, which focused largely on
> making VC work in both the managed and unmanaged worlds, even in the same
> program (no small feat, BTW), MS has applied significant resources to make
> the upcoming VC Everett release one of the most C++ Standard conformant
> compilers on the market. It's no secret that MS has hired a couple of very
> well-known C++ guys in the last couple of years. And it should be obvious
> the VC team has increased its presence greatly in this group and others.
So
> I think some very good things have been happening in the VC++ world over
the
> past few years. As for what the future may hold, here's a Google search on
> what the MS guys have been talking about:

http://groups.google.com/groups?q=future+MSFT+group%3Amicrosoft.publi...
t.languages.vc

- Show quoted text -

Quote:

> --
> Doug Harrison
> Microsoft MVP - Visual C++



Mon, 22 Aug 2005 04:13:31 GMT  
 C++ standard library facilities & .NET
To be clear: explicit delete doesn't release managed objects but forces call
of destructor on them.



Quote:
> There is one more hit. Your unmanaged heap can be exhausted faster that
you
> might think it should. If you don't explicitly delete your managed objects
> they can sit there forever taking a small bit of managed heap and a huge
> chunk of unmanaged one. This is not a problem for C++ programs - everybody
> knows how to manage shared resources. However if you expose your objects
to
> other application written in say VB you are in trouble. You have to make
> your objects disposable. But even that doesn't solve all the problems. You
> cannot control client code and if your methods return a new object
somebody
> can create a temporary: foo.Method().OtherMethod() - oops, should be Dim
bar
> as Bar: bar = foo.Method(): bar.OtherMethod(): bar.Dispose(). Yuck... I
> wander why destructors are not supported on __value types?

> thanks,
> v






> > >> Right, sorry. You could however store a pointer to the vector and
> assume
> > >> explicit lifetime management for it in your managed class. This means
> > >> creating it in your ctor and deleting it in your dtor (finalizer).

> > >It finally arrived. So i repost properly:

> > >I do not understand what you mean. I placed

> > >either a vector<MenuItem *>menuitems;

> > >as a private member and made the constructor

> > >CppForm():menuitems(3)
> > >{
> > > // ...
> > > }

> > >and it did not compile

> > >or vector<MenuItem *> *menuitems

> > >and made the constructor
> > >{
> > > menuitems=new vector<MenuItem *>(3);
> > > // ...
> > >}

> > >and still did not accept it.

> > You have to use gcroot to get the vector to store __gc pointers, and the
> > managed class which owns the vector has to store a pointer to the
vector.
> > This is more or less what I had in mind:

> > // c.cpp

> > #using <mscorlib.dll>
> > using namespace System;

> > #include <vcclr.h>

> > #include <vector>

> > __gc class X
> > {
> > public:

> >    explicit X(int x)
> >    :  x_(x)
> >    {
> >    }

> >    void print()
> >    {
> >       Console::WriteLine(S"X::print = {0}", __box(x_));
> >    }

> >    int x_;
> > };

> > __gc class Y
> > {
> > public:

> >    typedef std::vector< gcroot<X*> > VecT;

> >    Y()
> >    :  v(new VecT)
> >    {
> >       v->push_back(new X(0));
> >       (*v)[0]->print();
> >       v->push_back(new X(1));
> >       (*v)[1]->print();
> >    }

> >    ~Y()
> >    {
> >       Console::WriteLine(S"Deleting v");
> >       delete v;
> >    }

> >    VecT* v;
> > };

> > int main()
> > {
> >    new Y;
> > }

> > // end c.cpp

> > E>cl /GX /GR /Zc:forScope /Zc:wchar_t /W3 /clr c.cpp
> > Microsoft (R) C/C++ Optimizing Compiler Version 13.10.2292 for .NET
> > Framework
> > Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.

> > c.cpp
> > Microsoft (R) Incremental Linker Version 7.10.2292
> > Copyright (C) Microsoft Corporation.  All rights reserved.

> > /out:c.exe
> > c.obj

> > E>c
> > X::print = 0
> > X::print = 1
> > Deleting v

> > So, it pretty much works. You basically take three hits. First, there's
> the
> > loss of convenience in having to use VecT*. Instead of saying v[0], you
> have
> > to say (*v)[0]. Second, you're storing gcroot<T*>, not T, which makes it
a
> > little more complicated to use algorithms which operate on T. For
example,
> > you'd have to write a custom operator< for gcroot<T*> to std::sort your
> > vector. Third, there's the efficiency hit in using gcroot, which in most
> > cases, I expect, can be ignored.

> > >So if you cannot use the standard library, it
> > >means we have to learn other containers etc. However the benefit of the
> > >standard library is that wherever you go you have vector, list,
valarray,
> > >... and you have not to learn similar containers but different in every
> > >platform (the same applies and for the algorithms). How excellent it
> would
> > >be if MS did it the right way! But can we expect that?...

> > Well, MS has said many times that C++ is a very important language in
the
> > .NET universe. Since the initial release of VC7, which focused largely
on
> > making VC work in both the managed and unmanaged worlds, even in the
same
> > program (no small feat, BTW), MS has applied significant resources to
make
> > the upcoming VC Everett release one of the most C++ Standard conformant
> > compilers on the market. It's no secret that MS has hired a couple of
very
> > well-known C++ guys in the last couple of years. And it should be
obvious
> > the VC team has increased its presence greatly in this group and others.
> So
> > I think some very good things have been happening in the VC++ world over
> the
> > past few years. As for what the future may hold, here's a Google search
on
> > what the MS guys have been talking about:

http://groups.google.com/groups?q=future+MSFT+group%3Amicrosoft.publi...

- Show quoted text -

Quote:
> t.languages.vc

> > --
> > Doug Harrison
> > Microsoft MVP - Visual C++



Mon, 22 Aug 2005 04:50:35 GMT  
 C++ standard library facilities & .NET


Quote:
> To be clear: explicit delete doesn't release managed objects but forces
call
> of destructor on them.



> > There is one more hit. Your unmanaged heap can be exhausted faster that
> you
> > might think it should. If you don't explicitly delete your managed
objects
> > they can sit there forever taking a small bit of managed heap and a huge
> > chunk of unmanaged one. This is not a problem for C++ programs -
everybody
> > knows how to manage shared resources. However if you expose your objects
> to
> > other application written in say VB you are in trouble. You have to make
> > your objects disposable. But even that doesn't solve all the problems.
You
> > cannot control client code and if your methods return a new object
> somebody
> > can create a temporary: foo.Method().OtherMethod() - oops, should be Dim
> bar
> > as Bar: bar = foo.Method(): bar.OtherMethod(): bar.Dispose(). Yuck... I
> > wander why destructors are not supported on __value types?

> > thanks,
> > v

I did not understand well. You mean that since the destructor (finalizer)
may be called whenever, we will occupy unmanaged heap? Well without knowing
the CLR internals i assume than when the GC engine needs space and kills an
unused managed object (for example a form containing std::vector), the
destructor/finalizer will contain the appropriate delete s for the unmanaged
ones so all the object occupied memory will be freed. The way that i view
it, it should work even when such a __gc object is inherited/used in VB code
(i am not talking about returning unmanaged objects on the free store from a
member function).

If someone knows more it will be great.

However i did not understand your phrase "To be clear: explicit delete
doesn't release managed objects but forces call
of destructor on them.".

--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL: http://run.to/noicys



Mon, 22 Aug 2005 15:49:12 GMT  
 C++ standard library facilities & .NET
inline:

Quote:

in

> > > There is one more hit. Your unmanaged heap can be exhausted faster
that
> > you
> > > might think it should. If you don't explicitly delete your managed
> objects
> > > they can sit there forever taking a small bit of managed heap and a
huge
> > > chunk of unmanaged one. This is not a problem for C++ programs -
> everybody
> > > knows how to manage shared resources. However if you expose your
objects
> > to
> > > other application written in say VB you are in trouble. You have to
make
> > > your objects disposable. But even that doesn't solve all the problems.
> You
> > > cannot control client code and if your methods return a new object
> > somebody
> > > can create a temporary: foo.Method().OtherMethod() - oops, should be
Dim
> > bar
> > > as Bar: bar = foo.Method(): bar.OtherMethod(): bar.Dispose(). Yuck...
I
> > > wander why destructors are not supported on __value types?

> > > thanks,
> > > v

> I did not understand well. You mean that since the destructor (finalizer)
> may be called whenever, we will occupy unmanaged heap? Well without
knowing
> the CLR internals i assume than when the GC engine needs space and kills
an
> unused managed object (for example a form containing std::vector), the
> destructor/finalizer will contain the appropriate delete s for the
unmanaged
> ones so all the object occupied memory will be freed. The way that i view
> it, it should work even when such a __gc object is inherited/used in VB
code
> (i am not talking about returning unmanaged objects on the free store from
a
> member function).

This is correct. I am talking about other problem: if your managed objects
take little space and unmanaged objects controlled by managed ones take a
lot of space, the unmanaged heap can be exhausted and yet there might be no
reson for GC to collect dead managed objects because there is a lot of free
space in the managed heap. So the next attempt to create unmanaged object
will fail because there is no more room in the unmanaged heap even though
the memory in the unmanaged heap belongs to dead objects. That is if you
don't delete managed objects explicetly. You cannot however explicitly
delete objects from VB - you have to make objects disposable, which means
implementing IDisposable, and explicitly Dispose() them.

Quote:

> If someone knows more it will be great.

> However i did not understand your phrase "To be clear: explicit delete
> doesn't release managed objects but forces call
> of destructor on them.".

If you explicitly "delete SomeMangedObject;" ~SomeManagedObject() is called
immediately (destroying unmanaged object in our case and therefore releasing
memory in the unmanaged heap), but the object (more like empty shell of it)
resides in the memory afterwards until GC collects it.

thanks,
v



Tue, 23 Aug 2005 09:26:53 GMT  
 C++ standard library facilities & .NET


Quote:

> This is correct. I am talking about other problem: if your managed objects
> take little space and unmanaged objects controlled by managed ones take a
> lot of space, the unmanaged heap can be exhausted and yet there might be
no
> reson for GC to collect dead managed objects because there is a lot of
free
> space in the managed heap. So the next attempt to create unmanaged object
> will fail because there is no more room in the unmanaged heap even though
> the memory in the unmanaged heap belongs to dead objects. That is if you
> don't delete managed objects explicetly.

I did not know that there are separate managed and managed heaps. However
the regular language rules apply, if there is not available memory on the
free store an std::bad_alloc is thrown. So memory failures can be handled in
the usual way.

Have you any idea how much is the "unmanaged heap" in comparison to the
"managed" one?

Quote:
> You cannot however explicitly
> delete objects from VB - you have to make objects disposable, which means
> implementing IDisposable, and explicitly Dispose() them.

Isn't there any Finalize() there?

--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL: http://run.to/noicys



Tue, 23 Aug 2005 20:00:49 GMT  
 C++ standard library facilities & .NET

Quote:

> Have you any idea how much is the "unmanaged heap" in comparison to
> the "managed" one?

They both compete for the same memory at the OS level - there's no preset
limit on either, nor hard-wired relationship between their sizes.

-cd



Tue, 23 Aug 2005 22:42:39 GMT  
 C++ standard library facilities & .NET

Quote:
> I did not know that there are separate managed and managed heaps. However
> the regular language rules apply, if there is not available memory on the
> free store an std::bad_alloc is thrown. So memory failures can be handled
in
> the usual way.

Right, you can handle that, so what? You still have a bunch of memory
occupied by dead objects. Yes, you can force GC and hope it releases the
memory or have a method to release the memory explicitely. Either way is far
from elegancy of RAII.

Quote:
> Isn't there any Finalize() there?

Finalize() is protected - you cannot call it in client code.

thanks,
v



Wed, 24 Aug 2005 03:18:15 GMT  
 
 [ 18 post ]  Go to page: [1] [2]

 Relevant Pages 

1. C++ .NET V7, standard C++ library, ODBC - conflict

2. UNICODE & C++ standard library

3. Standard c++ library and old iostream library in the same program

4. Standard c++ library and old iostream library in the same program

5. Standard C++ Library and old iostream libraries in VC++ 4.2

6. Standard c++ library and old iostream library in the same program

7. Visuals C# .NET Standard Edition doesn't include Class Library Project Template

8. ANSI C standard library & other ?s

9. Q: Standard Libraries & the link processes

10. Multithreading and Standard C++ Library

11. Using Standard C++ Library

12. Standard C++ library question

 

 
Powered by phpBB® Forum Software