Why is it impossible to have a __value class instance variable in a __nogc
class when it is possible to have a built-in type instance variable in a
__nogc class ?
__value class X { int a; };
__nogc class Y { X b; int c;}; // compiler error
__nogc class Y { int c;}; // OK
15  1363 
It _would_ be possible to allow this if the value type does not directly or
indirectly contain any ref types. But the language design made the choice to
simplify this by not allowing any cases.
Ronald Laeremans
Visual C++ team
"Edward Diener" <ed******@tropicsoft.com> wrote in message
news:u2**************@TK2MSFTNGP09.phx.gbl... Why is it impossible to have a __value class instance variable in a __nogc
class when it is possible to have a built-in type instance variable in a
__nogc class ?
__value class X { int a; };
__nogc class Y { X b; int c;}; // compiler error
__nogc class Y { int c;}; // OK
Hi Ronald, It _would_ be possible to allow this if the value type does not directly
or indirectly contain any ref types. But the language design made the choice
to simplify this by not allowing any cases.
Alas, this isn't entirely true, as this simple example shows:
#using <mscorlib.dll>
using namespace System;
using namespace System::Runtime::InteropServices;
[ StructLayout(LayoutType::Sequential) ]
__value struct X { int a; };
__nogc class Y { X x; int c; };
So, obviously, the rule is not quite as simple as reyected in all cases.
AFAIK, the rules are closer to this: It is allowed iif:
- X has no members of ref types
- X has explicitly been declared as sequential layout (which should be
unnecessary, actually)
- X is declared in the same assembly as Y (or maybe the same translation
unit? haven't checked that in detail).
But yes, for all intented purposes, one should consider this as forbidden ;)
--
Tomas Restrepo to****@mvps.org
Ronald Laeremans [MSFT] wrote: It _would_ be possible to allow this if the value type does not
directly or indirectly contain any ref types. But the language design
made the choice to simplify this by not allowing any cases.
I can understand the rule against having any ref types but I don't
understand the simplifying choice. I have found it often valuable in mixed
mode MC++ development for the __nogc class to have a fairly simple __value
object as a member of the class. It is disappointing that this is not
allowed especially as built-in types are __value classes themselves and
__nogc classes can, of course, have a built-in object.
Ronald Laeremans
Visual C++ team
"Edward Diener" <ed******@tropicsoft.com> wrote in message
news:u2**************@TK2MSFTNGP09.phx.gbl... Why is it impossible to have a __value class instance variable in a
__nogc class when it is possible to have a built-in type instance
variable in a __nogc class ?
__value class X { int a; };
__nogc class Y { X b; int c;}; // compiler error
__nogc class Y { int c;}; // OK
Tomas Restrepo (MVP) wrote: Hi Ronald, It _would_ be possible to allow this if the value type does not
directly or indirectly contain any ref types. But the language
design made the choice to simplify this by not allowing any cases.
Alas, this isn't entirely true, as this simple example shows:
#using <mscorlib.dll>
using namespace System;
using namespace System::Runtime::InteropServices;
[ StructLayout(LayoutType::Sequential) ]
__value struct X { int a; };
__nogc class Y { X x; int c; };
So, obviously, the rule is not quite as simple as reyected in all
cases. AFAIK, the rules are closer to this: It is allowed iif:
Thanks for the following clarification. I did find the discusssion about
this in Mr. Grimes' book pp. 107-108 when I looked again. Evidently I had
forgotten about this when I asked the question.
- X has no members of ref types
- X has explicitly been declared as sequential layout (which
should be unnecessary, actually)
It is unnecessary in VC 7.1 and it is my error in thinking that it was
necessary.
- X is declared in the same assembly as Y (or maybe the same
translation unit? haven't checked that in detail).
In the same assembly I believe. Richard Grimes points out in his book that
this is because of a bug in Visual C++. This is the case which occured in my
code which led me to believe that the restriction existed.
But yes, for all intented purposes, one should consider this as
forbidden ;)
Evidently the intent was to allow it in VC++ 7.1 but not in VC 7. However
the cross-assembly bug which Mr. Grimes' mentions does not allow it in VC++
7.1 also when the __value class and the __nogc type are in different
assemblies. Also in my testing, while I can embed a __value class in a
__nogc type within the same assembly, I can not embed a __value enum in a
__nogc type in the same assembly, which is really anomalous.
My suggestion is that this really neeeds to be cleaned up and that the VC++
compiler should allow __value classes/structs/enums to be embedded in a
__nogc class as long as the former does not have a __gc instance.
Hi Edward, I can understand the rule against having any ref types but I don't
understand the simplifying choice.
I think he might've meant simplifying it for the compiler development, not
necessarily the end user ;)
It ain't exactly all that trivial to check, since the check would need to be
recursive (remember Ronald pointed out it applied to direct _and_ indirect
containment of handles to managed ref types), so there are a few ugly cases
that would need to be cared for, making things more complex than necessary.
Then again, it's just mho, I might be just missing the point ;)
--
Tomas Restrepo to****@mvps.org
Yes, we let some stuff slip through. I was simplifying the simplification.
;-)
Ronald
"Tomas Restrepo (MVP)" <to****@mvps.org> wrote in message
news:On**************@TK2MSFTNGP09.phx.gbl... Hi Ronald, It _would_ be possible to allow this if the value type does not directly or indirectly contain any ref types. But the language design made the
choice to simplify this by not allowing any cases.
Alas, this isn't entirely true, as this simple example shows:
#using <mscorlib.dll>
using namespace System;
using namespace System::Runtime::InteropServices;
[ StructLayout(LayoutType::Sequential) ]
__value struct X { int a; };
__nogc class Y { X x; int c; };
So, obviously, the rule is not quite as simple as reyected in all cases.
AFAIK, the rules are closer to this: It is allowed iif:
- X has no members of ref types
- X has explicitly been declared as sequential layout (which should be
unnecessary, actually)
- X is declared in the same assembly as Y (or maybe the same
translation unit? haven't checked that in detail).
But yes, for all intented purposes, one should consider this as forbidden
;) --
Tomas Restrepo
to****@mvps.org
We are working on alternate ways to address this in the next release. I
don't think we have a final resolution yet on exactly what that will be.
Ronald
"Edward Diener" <ed******@tropicsoft.com> wrote in message
news:el****************@TK2MSFTNGP10.phx.gbl... Ronald Laeremans [MSFT] wrote: It _would_ be possible to allow this if the value type does not
directly or indirectly contain any ref types. But the language design
made the choice to simplify this by not allowing any cases.
I can understand the rule against having any ref types but I don't
understand the simplifying choice. I have found it often valuable in mixed
mode MC++ development for the __nogc class to have a fairly simple __value
object as a member of the class. It is disappointing that this is not
allowed especially as built-in types are __value classes themselves and
__nogc classes can, of course, have a built-in object.
Ronald Laeremans
Visual C++ team
"Edward Diener" <ed******@tropicsoft.com> wrote in message
news:u2**************@TK2MSFTNGP09.phx.gbl... Why is it impossible to have a __value class instance variable in a
__nogc class when it is possible to have a built-in type instance
variable in a __nogc class ?
__value class X { int a; };
__nogc class Y { X b; int c;}; // compiler error
__nogc class Y { int c;}; // OK
Some additional background:
The restriction of it needing to be in the same assembly of the current rule
is because we do not read metadata for private members, and so a ref type
could be hiding there.
And the restriction of needing sequential or explicit layout is because the
CLR decision to have all value types have sequential layout by default came
pretty late in the 7.0 cycle. We didn't consider any of this important
enough to revisit for 7.1.
Ronald
"Tomas Restrepo (MVP)" <to****@mvps.org> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl... Hi Edward,
I can understand the rule against having any ref types but I don't
understand the simplifying choice.
I think he might've meant simplifying it for the compiler development, not
necessarily the end user ;)
It ain't exactly all that trivial to check, since the check would need to
be recursive (remember Ronald pointed out it applied to direct _and_ indirect
containment of handles to managed ref types), so there are a few ugly
cases that would need to be cared for, making things more complex than
necessary.
Then again, it's just mho, I might be just missing the point ;)
--
Tomas Restrepo
to****@mvps.org
Ronald Laeremans [MSFT] wrote: Some additional background:
The restriction of it needing to be in the same assembly of the
current rule is because we do not read metadata for private members,
and so a ref type could be hiding there.
I understand this, but the metadata for private members is generated, is it
not, so when the compiler sees an embedded __value type in a __nogc type
which exists in another assembly, it could read it ( and on recursively if
necessary ). Of course for non-embedded value types in a __nogc type it
doesn't need to do so.
And the restriction of needing sequential or explicit layout is
because the CLR decision to have all value types have sequential
layout by default came pretty late in the 7.0 cycle. We didn't
consider any of this important enough to revisit for 7.1.
This one seems easier. Since the default is sequential layout for value
types, the compiler should automatically know this. But in 7.1 it actually
does according to my tests as long as the value type is in the same
assembly, or did I miss something ?
Ronald
"Tomas Restrepo (MVP)" <to****@mvps.org> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl... Hi Edward,
I can understand the rule against having any ref types but I don't
understand the simplifying choice.
I think he might've meant simplifying it for the compiler
development, not necessarily the end user ;)
It ain't exactly all that trivial to check, since the check would
need to be recursive (remember Ronald pointed out it applied to
direct _and_ indirect containment of handles to managed ref types),
so there are a few ugly cases that would need to be cared for,
making things more complex than necessary.
Then again, it's just mho, I might be just missing the point ;)
--
Tomas Restrepo
to****@mvps.org
Ronald Laeremans [MSFT] wrote: Some additional background:
The restriction of it needing to be in the same assembly of the
current rule is because we do not read metadata for private members,
and so a ref type could be hiding there.
And the restriction of needing sequential or explicit layout is
because the CLR decision to have all value types have sequential
layout by default came pretty late in the 7.0 cycle. We didn't
consider any of this important enough to revisit for 7.1.
Why does a restriction also apply to variables of __value enum embedded in
__nogc types ? Clearly these follow neither the first explanation above,
about hidden ref types nor the second about sequential layout. Yet if I try
to embed a __value enum variable in a __nogc class the compiler gives me an
error saying that I can not do it.
Ronald
"Tomas Restrepo (MVP)" <to****@mvps.org> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl... Hi Edward,
I can understand the rule against having any ref types but I don't
understand the simplifying choice.
I think he might've meant simplifying it for the compiler
development, not necessarily the end user ;)
It ain't exactly all that trivial to check, since the check would
need to be recursive (remember Ronald pointed out it applied to
direct _and_ indirect containment of handles to managed ref types),
so there are a few ugly cases that would need to be cared for,
making things more complex than necessary.
Then again, it's just mho, I might be just missing the point ;)
--
Tomas Restrepo
to****@mvps.org
Probably because we special cased value types and forgot about value enum
types.
Ronald
"Edward Diener" <ed******@tropicsoft.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl... Ronald Laeremans [MSFT] wrote: Some additional background:
The restriction of it needing to be in the same assembly of the
current rule is because we do not read metadata for private members,
and so a ref type could be hiding there.
And the restriction of needing sequential or explicit layout is
because the CLR decision to have all value types have sequential
layout by default came pretty late in the 7.0 cycle. We didn't
consider any of this important enough to revisit for 7.1.
Why does a restriction also apply to variables of __value enum embedded in
__nogc types ? Clearly these follow neither the first explanation above,
about hidden ref types nor the second about sequential layout. Yet if I
try to embed a __value enum variable in a __nogc class the compiler gives me
an error saying that I can not do it.
Ronald
"Tomas Restrepo (MVP)" <to****@mvps.org> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl... Hi Edward,
I can understand the rule against having any ref types but I don't
understand the simplifying choice.
I think he might've meant simplifying it for the compiler
development, not necessarily the end user ;)
It ain't exactly all that trivial to check, since the check would
need to be recursive (remember Ronald pointed out it applied to
direct _and_ indirect containment of handles to managed ref types),
so there are a few ugly cases that would need to be cared for,
making things more complex than necessary.
Then again, it's just mho, I might be just missing the point ;)
--
Tomas Restrepo
to****@mvps.org
Yes, it could read the private meta data. I was just saying that we did not.
And we might have addressed the second issue in 7.1. My best recollection
was that we didn't.
Trying to find the edges of this might end up being frustrating though.
Ronald
"Edward Diener" <ed******@tropicsoft.com> wrote in message
news:e0**************@TK2MSFTNGP11.phx.gbl... Ronald Laeremans [MSFT] wrote: Some additional background:
The restriction of it needing to be in the same assembly of the
current rule is because we do not read metadata for private members,
and so a ref type could be hiding there.
I understand this, but the metadata for private members is generated, is
it not, so when the compiler sees an embedded __value type in a __nogc type
which exists in another assembly, it could read it ( and on recursively if
necessary ). Of course for non-embedded value types in a __nogc type it
doesn't need to do so.
And the restriction of needing sequential or explicit layout is
because the CLR decision to have all value types have sequential
layout by default came pretty late in the 7.0 cycle. We didn't
consider any of this important enough to revisit for 7.1.
This one seems easier. Since the default is sequential layout for value
types, the compiler should automatically know this. But in 7.1 it actually
does according to my tests as long as the value type is in the same
assembly, or did I miss something ?
Ronald
"Tomas Restrepo (MVP)" <to****@mvps.org> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl... Hi Edward,
I can understand the rule against having any ref types but I don't
understand the simplifying choice.
I think he might've meant simplifying it for the compiler
development, not necessarily the end user ;)
It ain't exactly all that trivial to check, since the check would
need to be recursive (remember Ronald pointed out it applied to
direct _and_ indirect containment of handles to managed ref types),
so there are a few ugly cases that would need to be cared for,
making things more complex than necessary.
Then again, it's just mho, I might be just missing the point ;)
--
Tomas Restrepo
to****@mvps.org
Ronald Laeremans [MSFT] wrote: Probably because we special cased value types and forgot about value
enum types.
Programmers, like elephants, never forget <g> .
I hope I have given enough for you to think about and fix in the next
release regarding this area.
Ronald
"Edward Diener" <ed******@tropicsoft.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl... Ronald Laeremans [MSFT] wrote: Some additional background:
The restriction of it needing to be in the same assembly of the
current rule is because we do not read metadata for private members,
and so a ref type could be hiding there.
And the restriction of needing sequential or explicit layout is
because the CLR decision to have all value types have sequential
layout by default came pretty late in the 7.0 cycle. We didn't
consider any of this important enough to revisit for 7.1.
Why does a restriction also apply to variables of __value enum
embedded in __nogc types ? Clearly these follow neither the first
explanation above, about hidden ref types nor the second about
sequential layout. Yet if I try to embed a __value enum variable in
a __nogc class the compiler gives me an error saying that I can not
do it.
Ronald
"Tomas Restrepo (MVP)" <to****@mvps.org> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...
Hi Edward,
> I can understand the rule against having any ref types but I don't
> understand the simplifying choice.
I think he might've meant simplifying it for the compiler
development, not necessarily the end user ;)
It ain't exactly all that trivial to check, since the check would
need to be recursive (remember Ronald pointed out it applied to
direct _and_ indirect containment of handles to managed ref types),
so there are a few ugly cases that would need to be cared for,
making things more complex than necessary.
Then again, it's just mho, I might be just missing the point ;)
--
Tomas Restrepo
to****@mvps.org
Ronald Laeremans [MSFT] wrote: Yes, it could read the private meta data. I was just saying that we
did not.
And we might have addressed the second issue in 7.1. My best
recollection was that we didn't.
Trying to find the edges of this might end up being frustrating
though.
Seems pretty clearcut to me, at least what should be done, to make it easier
to use __nogc and __value types together. A difficult issue should never be
an excuse for not being creative enough. Please revisit this issue for the
next release and fix the inconsistencies. Thank you !
Ronald
"Edward Diener" <ed******@tropicsoft.com> wrote in message
news:e0**************@TK2MSFTNGP11.phx.gbl... Ronald Laeremans [MSFT] wrote: Some additional background:
The restriction of it needing to be in the same assembly of the
current rule is because we do not read metadata for private members,
and so a ref type could be hiding there.
I understand this, but the metadata for private members is
generated, is it not, so when the compiler sees an embedded __value
type in a __nogc type which exists in another assembly, it could
read it ( and on recursively if necessary ). Of course for
non-embedded value types in a __nogc type it doesn't need to do so.
And the restriction of needing sequential or explicit layout is
because the CLR decision to have all value types have sequential
layout by default came pretty late in the 7.0 cycle. We didn't
consider any of this important enough to revisit for 7.1.
This one seems easier. Since the default is sequential layout for
value types, the compiler should automatically know this. But in 7.1
it actually does according to my tests as long as the value type is
in the same assembly, or did I miss something ?
Ronald
"Tomas Restrepo (MVP)" <to****@mvps.org> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...
Hi Edward,
> I can understand the rule against having any ref types but I don't
> understand the simplifying choice.
I think he might've meant simplifying it for the compiler
development, not necessarily the end user ;)
It ain't exactly all that trivial to check, since the check would
need to be recursive (remember Ronald pointed out it applied to
direct _and_ indirect containment of handles to managed ref types),
so there are a few ugly cases that would need to be cared for,
making things more complex than necessary.
Then again, it's just mho, I might be just missing the point ;)
--
Tomas Restrepo
to****@mvps.org
Hi Edward,
As I said in another reply, the solution for Whidbey is probably going to be
along different lines altogether than what we have for 7.x altogether, and
it isn't settled enough yet so I can't comment on the new design for that
part here.
Ronald
"Edward Diener" <ed******@tropicsoft.com> wrote in message
news:O3**************@TK2MSFTNGP09.phx.gbl... Ronald Laeremans [MSFT] wrote: Probably because we special cased value types and forgot about value
enum types.
Programmers, like elephants, never forget <g> .
I hope I have given enough for you to think about and fix in the next
release regarding this area.
Ronald
"Edward Diener" <ed******@tropicsoft.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl... Ronald Laeremans [MSFT] wrote:
Some additional background:
The restriction of it needing to be in the same assembly of the
current rule is because we do not read metadata for private members,
and so a ref type could be hiding there.
And the restriction of needing sequential or explicit layout is
because the CLR decision to have all value types have sequential
layout by default came pretty late in the 7.0 cycle. We didn't
consider any of this important enough to revisit for 7.1.
Why does a restriction also apply to variables of __value enum
embedded in __nogc types ? Clearly these follow neither the first
explanation above, about hidden ref types nor the second about
sequential layout. Yet if I try to embed a __value enum variable in
a __nogc class the compiler gives me an error saying that I can not
do it.
Ronald
"Tomas Restrepo (MVP)" <to****@mvps.org> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...
> Hi Edward,
>
>> I can understand the rule against having any ref types but I don't
>> understand the simplifying choice.
>
> I think he might've meant simplifying it for the compiler
> development, not necessarily the end user ;)
> It ain't exactly all that trivial to check, since the check would
> need to be recursive (remember Ronald pointed out it applied to
> direct _and_ indirect containment of handles to managed ref types),
> so there are a few ugly cases that would need to be cared for,
> making things more complex than necessary.
>
> Then again, it's just mho, I might be just missing the point ;)
> --
> Tomas Restrepo
> to****@mvps.org
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Edward Diener |
last post by:
Is there a way to override the default processing of the assignment operator
for one's own __value types ? I realize I can program my own Assign method,
and provide that for end-users of my class,...
|
by: Edward Diener |
last post by:
I have a __value class which uses some legacy C++ code. So I wrapped the
legacy C++ code in another __nogc class and have a pointer to that class as
a member of my __value class. When the __value...
|
by: Edward Diener |
last post by:
If a __value class with an event is put into an assembly, and a __gc class
in another assembly attempts to attach its own event handler to the __value
class's event of an embedded object of the...
|
by: Edward Diener |
last post by:
Why is there a prohibition of instantiating __value type enums and classes
within __nogc classes ? After all __value types are not managed by the GC
and built-in __value types, such as 'int', are...
|
by: Edward Diener |
last post by:
I want to share a __nogc classes between different assemblies. For __gc
classes, one only needs to declare the class public in order to be able to
do this. Is there a way to share a __nogc class so...
|
by: mccoyn |
last post by:
I have a class exported in a dll that has member variables I wish to access. When I do it I get an error C2039: 'myVar' : is not a member of myClass
Here is an example of what my code looks like...
|
by: Marcus Kwok |
last post by:
I have been reading through the ManagedExtensionsSpec.doc file and I
thought something was not clear.
If I have a __value class (really a __value struct but that shouldn't
make a difference) and...
|
by: razilon |
last post by:
Hi,
I've written a managed class that makes use of stl vectors of a few
unmanaged structs for data handling/manipulation, but I'm getting a few
very strange errors. I get an
"Unhandled...
|
by: mschuck |
last post by:
Here is the scenario I'm trying to make work.
I've got 2 managed C++ classes, each of which wrappes an unmanaged C++
class, kind of like so:
__nogc class UnmanagedClassA
{
public:
void...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
| |
