473,729 Members | 2,261 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Packing for __nogc classes

Is the packing alignment of __nogc classes stored as part of the assembly ?
I think it must as the compiler, when referencing the assembly, could not
know how the original data is packed otherwise. Yet, in my understanding,
attributes are only __gc and __value class specific and do not apply to
__nogc classes. Is this correct ? If so, how is the packing alignment of
__nogc classes stored ?
Nov 17 '05 #1
18 2042
Its stored in a jam jar in the cupboard.
"Edward Diener" <ed******@tropi csoft.com> wrote in message
news:OP******** ******@TK2MSFTN GP11.phx.gbl...
Is the packing alignment of __nogc classes stored as part of the assembly ? I think it must as the compiler, when referencing the assembly, could not
know how the original data is packed otherwise. Yet, in my understanding,
attributes are only __gc and __value class specific and do not apply to
__nogc classes. Is this correct ? If so, how is the packing alignment of
__nogc classes stored ?

Nov 17 '05 #2
.. wrote:
Its stored in a jam jar in the cupboard.

Along with the Java coffee no doubt.

"Edward Diener" <ed******@tropi csoft.com> wrote in message
news:OP******** ******@TK2MSFTN GP11.phx.gbl...
Is the packing alignment of __nogc classes stored as part of the
assembly ? I think it must as the compiler, when referencing the
assembly, could not know how the original data is packed otherwise.
Yet, in my understanding, attributes are only __gc and __value class
specific and do not apply to __nogc classes. Is this correct ? If
so, how is the packing alignment of __nogc classes stored ?

Nov 17 '05 #3
Hi Edward,
Is the packing alignment of __nogc classes stored as part of the assembly ? I think it must as the compiler, when referencing the assembly, could not
know how the original data is packed otherwise. Yet, in my understanding,
attributes are only __gc and __value class specific and do not apply to
__nogc classes. Is this correct ? If so, how is the packing alignment of
__nogc classes stored ?


Well, I don't think the packing is actually stored. When the compiler
creates metadata (very basic metadata indeed) for __nogc classes, it does so
by creating them as opaque value types, which means basically it creates
them as value types containing no members, and only basic information on
layout and size.

Here's an example of one such __nogc class represented:

..class private sequential ansi sealed A
extends [mscorlib]System.ValueTyp e
{
.pack 1
.size 12
} // end of class A

Notice the .pack and .size directives, which tell the runtime how to pack
the type and size of the type.

AFAIK, the compiler will *always* mark __nogc types with .pack 1, even if
actual packing is different. However, the compiler *will* adjust the .size
directive so that it reflects the real size of the object in memory
according to it's packing. In this case, I was trying with a class contaning
an int, a char and another int, with packing set to 4. If I set it to 1,
then the code would've said ".size 9", and so on.

--
Tomas Restrepo
to****@mvps.org
Nov 17 '05 #4
Is there good resources on runtime design, Im aware of compiler design but
not about managed runtime design.

"Tomas Restrepo (MVP)" <to****@mvps.or g> wrote in message
news:Oa******** ******@tk2msftn gp13.phx.gbl...
Hi Edward,
Is the packing alignment of __nogc classes stored as part of the assembly
?
I think it must as the compiler, when referencing the assembly, could
not know how the original data is packed otherwise. Yet, in my understanding, attributes are only __gc and __value class specific and do not apply to
__nogc classes. Is this correct ? If so, how is the packing alignment of
__nogc classes stored ?


Well, I don't think the packing is actually stored. When the compiler
creates metadata (very basic metadata indeed) for __nogc classes, it does

so by creating them as opaque value types, which means basically it creates
them as value types containing no members, and only basic information on
layout and size.

Here's an example of one such __nogc class represented:

.class private sequential ansi sealed A
extends [mscorlib]System.ValueTyp e
{
.pack 1
.size 12
} // end of class A

Notice the .pack and .size directives, which tell the runtime how to pack
the type and size of the type.

AFAIK, the compiler will *always* mark __nogc types with .pack 1, even if
actual packing is different. However, the compiler *will* adjust the .size
directive so that it reflects the real size of the object in memory
according to it's packing. In this case, I was trying with a class contaning an int, a char and another int, with packing set to 4. If I set it to 1,
then the code would've said ".size 9", and so on.

--
Tomas Restrepo
to****@mvps.org

Nov 17 '05 #5
Tomas Restrepo (MVP) wrote:
Hi Edward,
Is the packing alignment of __nogc classes stored as part of the
assembly ? I think it must as the compiler, when referencing the
assembly, could not know how the original data is packed otherwise.
Yet, in my understanding, attributes are only __gc and __value class
specific and do not apply to __nogc classes. Is this correct ? If
so, how is the packing alignment of __nogc classes stored ?
Well, I don't think the packing is actually stored. When the compiler
creates metadata (very basic metadata indeed) for __nogc classes, it
does so by creating them as opaque value types, which means basically
it creates them as value types containing no members, and only basic
information on layout and size.

Here's an example of one such __nogc class represented:

.class private sequential ansi sealed A
extends [mscorlib]System.ValueTyp e
{
.pack 1
.size 12
} // end of class A

Notice the .pack and .size directives, which tell the runtime how to
pack the type and size of the type.


Is this from the assembly itself ? If so, it looks like the assembly is
storing a .pack directive.

AFAIK, the compiler will *always* mark __nogc types with .pack 1,
even if actual packing is different.
This is strange. Suppose I need a different packing for __nogc classes to
correspond to some already created data structure. How do I tell the
compiler to change the packing. In non-CLR code I would use "#pragma pack".
Is this still accepted in __nogc classes in a CLR assembly ? If it is, why
does the compiler ignore it and always insert a .pack 1 directive ?
However, the compiler *will*
adjust the .size directive so that it reflects the real size of the
object in memory according to it's packing. In this case, I was
trying with a class contaning an int, a char and another int, with
packing set to 4. If I set it to 1, then the code would've said
".size 9", and so on.


Your explanation has confused me. Could you please be clearer as to:

1) whether there is a way to set the packing size for __nogc classes.
2) what that way is.
3) whether or not the end-user changing the packing from the IDE affects the
packing for __nogc classes if no specific packing has been set via 1) or 2).

The reason for this post has to do with a potential common problem pre-.NET
having to do with packing of classes/structures. If the programmer/creator
of a struct/class does not specifically set a packing size, via the #pragma
pack directive, when the compiler saw the header file it would apply
whatever the packing was in the IDE ( or command-line ). This could lead to
ABI problems if a library was built with a particular packing for a
class/structure and the end-user of that library decided to change the
global packing in the IDE ( or command-line ) to some other value. The
solution to this problem was for the programmer/creator to set the packing
for the class.structure in the header file for the class/structure via
"#pragma pack". Then the compiler would honor this directive by overriding
the end-user's global packing for that particular class/struct and all would
be well with no ABI problem occurring. Every 3rd party implementation which
distributed C++ header files/library would of course use the "#pragma pack"
method to assure that no ABI problem would occur.

I wanted to make sure that this would work properly with .NET C++ components
with __nogc classes. I am, of course, assuming that __gc and __value classes
store their packing as part of the metadata. My problem is that I want to be
assured that for __nogc classes that the end-user changing the global
packing will not affect the way the compiler/linker access data and
alignment in __nogc classes. Since __nogc ( and __gc and __value ) classes
in assemblies have no header file, I can only think that the packing used
when the assembly is built is somehow picked up and correctly used no matter
what the global packing in the IDE ( or command-line ) happens to be. If
this is the case, I will not worry about putting "#pragma pack" around my
__nogc classes since I don't need to change the default packing for __nogc
classes.
Nov 17 '05 #6
Edward Diener wrote:
The reason for this post has to do with a potential common problem pre-.NET
having to do with packing of classes/structures. If the programmer/creator
of a struct/class does not specifically set a packing size, via the #pragma
pack directive, when the compiler saw the header file it would apply
whatever the packing was in the IDE ( or command-line ). This could lead to
ABI problems if a library was built with a particular packing for a
class/structure and the end-user of that library decided to change the
global packing in the IDE ( or command-line ) to some other value. The
solution to this problem was for the programmer/creator to set the packing
for the class.structure in the header file for the class/structure via
"#pragma pack". Then the compiler would honor this directive by overriding
the end-user's global packing for that particular class/struct and all would
be well with no ABI problem occurring. Every 3rd party implementation which
distributed C++ header files/library would of course use the "#pragma pack"
method to assure that no ABI problem would occur.


I think that's backwards. The real solution is to never use /Zp but instead
use #pragma pack on structs only as necessary. If you expect everybody to
use #pragma pack in order to write /Zp-neutral headers, you've effectively
made #pragma pack part of the language, which is, to put it mildly, not a
good thing. I'd personally like to see /Zp abolished, and I'd like #pragma
pack to generate warnings when its effects penetrate #includes, both coming
or going. An exception to this latter rule could be made for the
<pshpackN.h> and <poppack.h> Windows headers. BTW, the Windows headers are
not all /Zp-neutral.

--
Doug Harrison
Microsoft MVP - Visual C++
Nov 17 '05 #7
Hi Edward,
Is this from the assembly itself ? If so, it looks like the assembly is
storing a .pack directive.
Yes, it's part of the actual managed metadata in the assembly.
AFAIK, the compiler will *always* mark __nogc types with .pack 1,
even if actual packing is different.


This is strange. Suppose I need a different packing for __nogc classes to
correspond to some already created data structure.


Wouldn't be a problem. I already explained how the compiler deals with it:
by telling the runtime the actual size of objects of that type, which
already takes into account packing. See, the .pack directive in managed
metadata serves to tell the runtime when laying out a type how to organize
members. Since __nogc classes are opaque to the runtime, really, there are
no members the runtime can lay out, so the compíler "fools" it by telling it
the actual size of the resulting object so that the runtime can reserve the
memory correctly on the stack or as part as a __gc type.
How do I tell the
compiler to change the packing.
For __nogc type, same way you always have (#pragma pack).
Your explanation has confused me. Could you please be clearer as to:

1) whether there is a way to set the packing size for __nogc classes.
Yes, see above.
2) what that way is. Again, see above.
3) whether or not the end-user changing the packing from the IDE affects the packing for __nogc classes if no specific packing has been set via 1) or

2).

See above, Keep in mind, though, that AFAICS, managed metadata is probably
NOT enough for the compiler to "guess" what the original packing of the
__nogc type is, which is where having the original header file defining it
helps :)

--
Tomas Restrepo
to****@mvps.org
Nov 17 '05 #8
Doug Harrison [MVP] wrote:
Edward Diener wrote:
The reason for this post has to do with a potential common problem
pre-.NET having to do with packing of classes/structures. If the
programmer/creator of a struct/class does not specifically set a
packing size, via the #pragma pack directive, when the compiler saw
the header file it would apply whatever the packing was in the IDE (
or command-line ). This could lead to ABI problems if a library was
built with a particular packing for a class/structure and the
end-user of that library decided to change the global packing in the
IDE ( or command-line ) to some other value. The solution to this
problem was for the programmer/creator to set the packing for the
class.structure in the header file for the class/structure via
"#pragma pack". Then the compiler would honor this directive by
overriding the end-user's global packing for that particular
class/struct and all would be well with no ABI problem occurring.
Every 3rd party implementation which distributed C++ header
files/library would of course use the "#pragma pack" method to
assure that no ABI problem would occur.


I think that's backwards. The real solution is to never use /Zp but
instead use #pragma pack on structs only as necessary. If you expect
everybody to use #pragma pack in order to write /Zp-neutral headers,
you've effectively made #pragma pack part of the language, which is,
to put it mildly, not a good thing. I'd personally like to see /Zp
abolished, and I'd like #pragma pack to generate warnings when its
effects penetrate #includes, both coming or going. An exception to
this latter rule could be made for the <pshpackN.h> and <poppack.h>
Windows headers. BTW, the Windows headers are not all /Zp-neutral.


I create a 3rd party header and library. I build it with packing set to 8
which is the default. I don't use #pragma pack around my classes as you
suggest. I distribute it ands the end-user sets his /Zp to 4 when including
my header file. Guess what ? My library is broken.

However, if I had used #pragma pack(push,8) prior to my class definition in
the header file and #pragma pack(pop) after my class definition in the
header file, everything works fine no matter what the end-user does. And you
are telling me that you think that is backward ?

As far as abolishing /Zp, how in the world do you expect programmers to set
packing, or perhaps you don't. If they have a data structure which requires
packing of 1, but they must use the deafult packing of 8, I guess they are
just out of luck, huh ?

You are way off base, sir, and have chosen to make a silly comment for some
reason I can't even begin to guess.
Nov 17 '05 #9
Edward Diener wrote:
Doug Harrison [MVP] wrote:
Edward Diener wrote:
The reason for this post has to do with a potential common problem
pre-.NET having to do with packing of classes/structures. If the
programmer/creator of a struct/class does not specifically set a
packing size, via the #pragma pack directive, when the compiler saw
the header file it would apply whatever the packing was in the IDE (
or command-line ). This could lead to ABI problems if a library was
built with a particular packing for a class/structure and the
end-user of that library decided to change the global packing in the
IDE ( or command-line ) to some other value. The solution to this
problem was for the programmer/creator to set the packing for the
class.structure in the header file for the class/structure via
"#pragma pack". Then the compiler would honor this directive by
overriding the end-user's global packing for that particular
class/struct and all would be well with no ABI problem occurring.
Every 3rd party implementation which distributed C++ header
files/library would of course use the "#pragma pack" method to
assure that no ABI problem would occur.
I think that's backwards. The real solution is to never use /Zp but
instead use #pragma pack on structs only as necessary. If you expect
everybody to use #pragma pack in order to write /Zp-neutral headers,
you've effectively made #pragma pack part of the language, which is,
to put it mildly, not a good thing. I'd personally like to see /Zp
abolished, and I'd like #pragma pack to generate warnings when its
effects penetrate #includes, both coming or going. An exception to
this latter rule could be made for the <pshpackN.h> and <poppack.h>
Windows headers. BTW, the Windows headers are not all /Zp-neutral.


I create a 3rd party header and library. I build it with packing set to 8
which is the default. I don't use #pragma pack around my classes as you
suggest. I distribute it ands the end-user sets his /Zp to 4 when including
my header file. Guess what ? My library is broken.


So is <windows.h>. So are any number of other headers which don't use
#pragma pack. The mistake is the user's for changing the default packing,
not the library author's for failing to use a #pragma (non-standard by
definition) to control something outside the language definition.
However, if I had used #pragma pack(push,8) prior to my class definition in
the header file and #pragma pack(pop) after my class definition in the
header file, everything works fine no matter what the end-user does. And you
are telling me that you think that is backward ?
Completely backwards. I explained why in my last message, which is quoted in
full above.
As far as abolishing /Zp, how in the world do you expect programmers to set
packing, or perhaps you don't. If they have a data structure which requires
packing of 1, but they must use the deafult packing of 8, I guess they are
just out of luck, huh ?
Like I said in my last message, they should use #pragma pack to establish
non-default packing on the structs that require it.
You are way off base, sir, and have chosen to make a silly comment for some
reason I can't even begin to guess.


You might want to consider dialing the rudeness back a few notches and
thinking about things a bit more carefully before replying.

--
Doug Harrison
Microsoft MVP - Visual C++
Nov 17 '05 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

0
1074
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 allowed inside __nogc classes as the type of fields. Yet when I try to instantiate a __value enum or __value class inside of a __nogc class, the compiler gives me error C3265. I am looking for the reason for this restriction.
15
1389
by: Edward Diener | last post by:
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
3
2279
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 that I can access its members from different assemblies ? Should I just use __declspec(dllexport) and __declspec(dllimport) or is there a different way ?
2
1297
by: J | last post by:
Compiling a straight C++ module under VC++ 7 would seem to autogen an 'IJW' type .NET module, even if the module has standard VC++ syntax. I'm assuming that the 'unmanaged' flag would have no further affect on this code. Nor would __nogc. Correct? Or are there subtle further differences? Are there recommended references that sort this type of thing out in precise detail?
0
913
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 I want a non-variable-size array of them, are there any advantages/disadvantages to using a __gc array versus a __nogc array? Section 4.5.3 (__gc and __nogc Keywords and Arrays) says:
1
1652
by: QbProg | last post by:
Hello, what I'm saying here is about VS 2005 WITHOUT service pack. I have two DLL projects, with EXACTLY the same project preferences and settings. Both have alignment set to "default", it should be 8. Surpise number one: In project B I include a file of project A in this way #include <FILE_FROM_A.h>
0
8924
marktang
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, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look ! Part I. Meaning of...
0
8763
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 effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
0
9428
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. Here is my compilation command: g++-12 -std=c++20 -Wnarrowing bit_field.cpp Here is the code in...
0
8155
agi2029
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, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
1
6722
isladogs
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 presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
0
6026
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert into image. Globals.ThisAddIn.Application.ActiveDocument.Select();...
0
4797
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
2
2689
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.
3
2165
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.