parser stack overflow, program too complex eroor C1026

[Peteroid]

Apparently there is a limit to how complex a single header file with a huge
class definition in it can be. The source to one of my header files is at a
point that it compiles and runs fine, until I add one more line to it, and I
then get this compiler error:

fatal error C1026: parser stack overflow, program too complex
This diagnostic occurred in the compiler generated function 'void
My_Class::Dispose(bool)'

Has this happened to anyone else? Is there a way to increase the 'parser
stack'? Is this a bug, or is there a limit to complexity for a single class
and/or header file?

[==P==]

[Carl Daniel [VC++ MVP]]

Peteroid wrote:

Apparently there is a limit to how complex a single header file with
a huge class definition in it can be. The source to one of my header
files is at a point that it compiles and runs fine, until I add one
more line to it, and I then get this compiler error:

fatal error C1026: parser stack overflow, program too complex
This diagnostic occurred in the compiler generated function 'void
My_Class::Dispose(bool)'

Has this happened to anyone else? Is there a way to increase the
'parser stack'? Is this a bug, or is there a limit to complexity for
a single class and/or header file?

AFIAK, there's no way to increase the limit, but I've never heard of anyone
hitting this limit before.

Is this a large class written entirely inline?

-cd

[Carl Daniel [VC++ MVP]]

Peteroid wrote:

Yes, it is entirely in-line. But I've reduced it down to a pretty
small source file that independently causes problem attached (see
instructions at top of source file in commented NOTE)...

That's a pretty small repro alright! You might want to contact PSS, or at
the very least open a bug report at
http://lab.msdn.microsoft.com/productfeedback

-cd

[Peteroid]

Already have bug reported it! hehe

Note the NEWER upload, even leaner, absolutely symbolic (my other other
post)... :)

[==P==]

"Carl Daniel [VC++ MVP]" <cp*****************************@mvps.org.nospam >
wrote in message news:eC**************@TK2MSFTNGP14.phx.gbl...

Peteroid wrote:

Yes, it is entirely in-line. But I've reduced it down to a pretty
small source file that independently causes problem attached (see
instructions at top of source file in commented NOTE)...

That's a pretty small repro alright! You might want to contact PSS, or at
the very least open a bug report at
http://lab.msdn.microsoft.com/productfeedback

-cd

[Peteroid]

Here is bug report I filed:

http://lab.msdn.microsoft.com/Produc...0-44bd02f398c6

[==P==]

"Carl Daniel [VC++ MVP]" <cp*****************************@mvps.org.nospam >
wrote in message news:eC**************@TK2MSFTNGP14.phx.gbl...

Peteroid wrote:

Yes, it is entirely in-line. But I've reduced it down to a pretty
small source file that independently causes problem attached (see
instructions at top of source file in commented NOTE)...

That's a pretty small repro alright! You might want to contact PSS, or at
the very least open a bug report at
http://lab.msdn.microsoft.com/productfeedback

-cd

[Vince Yuan]

Hi Perteroid,
I changed
OAP_Branch m_Root ;
to
OAP_Branch^ m_Root ;

Compiler accecpted your code.

And another way is to change
ref class OAP_Branch
to
value class OAP_Branch

Hope this helps.
--
Vince

[Peteroid]

Vince,

Thanks for the reply!

The class file in question isn't one with a value class. I removed all the
code and got the class file down to one that generates the problem. The
original class file has over 2300 lines in it!

Also, I don't want to use pointers, I want to use stack semantics. And it
works for stack semantics up to a point, but add one more line, and the
compiler generates an error it shouldn't.

In other words, this isn't me trying to get my code to work, this is me
pointing out a compiler bug! : )

[==P==]

"Vince Yuan" <sh*******@citiz.net> wrote in message
news:O2*************@tk2msftngp13.phx.gbl...

Hi Perteroid,
I changed
OAP_Branch m_Root ;
to
OAP_Branch^ m_Root ;

Compiler accecpted your code.

And another way is to change
ref class OAP_Branch
to
value class OAP_Branch

Hope this helps.
--
Vince

[Peter Oliphant]

Hi Vince,

However, you present a way I might be able to keep working. I could change
my members to pointers, and if that allows it to compile, then I can keep
working! So thanks again!

[==P==]

"Vince Yuan" <sh*******@citiz.net> wrote in message
news:O2*************@tk2msftngp13.phx.gbl...

Hi Perteroid,
I changed
OAP_Branch m_Root ;
to
OAP_Branch^ m_Root ;

Compiler accecpted your code.

And another way is to change
ref class OAP_Branch
to
value class OAP_Branch

Hope this helps.
--
Vince

[Peter Oliphant]

This version is probably as close to as minimal a source file that can be
that causes error c1026:

//-----------------------------
#pragma once
//
// NOTE: At bottom are two source lines for m_XXX, and m_YYY. if you comment
them both
// out this will compile. If you un-comment one you get first level error,
un-comment
// both you get a second level error (you'll see).
//
// WORKAROUND: Change enough stack semantic members to pointers.
// [courtesy of Vince Yuan]
//

ref class My_Class_A
{
public:
My_Class_A() {}
~My_Class_A() {}
} ;

ref class My_Class_B
{
public:

My_Class_B() {}
~My_Class_B() {}

My_Class_A m_Root ;
My_Class_A m_Inunt ;
My_Class_A m_0_Is ;
My_Class_A m_1_Is ;
My_Class_A m_2_Is ;
My_Class_A m_L_NT ;
My_Class_A m_L_NP ;
My_Class_A m_L_AD ;
My_Class_A m_L_O ;
My_Class_A m_3_Is ;
My_Class_A m_N_Is ;
My_Class_A m_Ount ;
My_Class_A m_0_Os ;
My_Class_A m_1_Os ;
My_Class_A m_2_Os ;
My_Class_A m_3_Os ;
My_Class_A m_N_Os ;
My_Class_A m_Loc ;
My_Class_A m_Ariic ;
My_Class_A m_y ;
My_Class_A m_pason ;
My_Class_A m_stt ;
My_Class_A m_veion ;
My_Class_A m_utode ;
My_Class_A m_puNode ;
My_Class_A m_Ma ;
My_Class_A m_Vaable ;
My_Class_A m_Spial ;
My_Class_A m_L_NND ;
My_Class_A m_L_NR ;
My_Class_A m_L_EU ;
My_Class_A m_C_int ;
My_Class_A m_C_long ;
My_Class_A m_C_float ;
My_Class_A m_C_double ;
My_Class_A m_C_ZO_float ;
My_Class_A m_C_ZO_double ;
My_Class_A m_C_ZO_char ;
My_Class_A m_C_ZO_string ;
My_Class_A m_L_NT_EQU ;
My_Class_A m_L_LFT ;
My_Class_A m_L_RGHT ;
My_Class_A m_L_NT_LEFT ;
My_Class_A m_L_NT_RHT ;
My_Class_A m_L_TUE ;
My_Class_A m_L_FLSE ;
My_Class_A m_L_IPIES ;
My_Class_A m_L_NT_IIS ;
My_Class_A m_L_IPED_BY ;
My_Class_A m_L_NT_IMED_BY ;
My_Class_A m_C_bool ;
My_Class_A m_C_bool_TRUE ;
My_Class_A m_C_bool_FALSE ;
My_Class_A m_C_OE ;
My_Class_A m_C_OE_int ;
My_Class_A m_O_long ;
My_Class_A m_O_float ;
My_Class_A m_O_double ;
My_Class_A m_O_char ;
My_Class_A m_O_string ;
My_Class_A m_O_uni ;
My_Class_A m_C_OE_long ;
My_Class_A m_C_OE_float ;
My_Class_A m_C_OE_double ;
My_Class_A m_C_OE_char ;
My_Class_A m_C_OE_string ;
My_Class_A m_O_bool ;
My_Class_A m_O_int ;
My_Class_A m_C_char ;
My_Class_A m_C_string ;
My_Class_A m_C_PI ;
My_Class_A m_C_ZO ;
My_Class_A m_C_ZO_int ;
My_Class_A m_C_ZO_long ;
My_Class_A m_Sp_DATE ;
My_Class_A m_Sp_TIME ;
My_Class_A m__DD ;
My_Class_A m__DD_int ;
My_Class_A m__DD_long ;
My_Class_A m__DD_float ;
My_Class_A m__ULT_float ;
My_Class_A m__ES_TN_double ;
My_Class_A m__ES_OR_ELS ;
My_Class_A m__ES_OR_ELS_int ;
My_Class_A m__ULT_long ;
My_Class_A m__ES_OR_ELS_float ;
My_Class_A m__ES_OR_ELS_double ;
My_Class_A m__RE_TN ;
My_Class_A m__RE_TN_int ;
My_Class_A m__ULT_double ;
My_Class_A m__ES_TN ;
My_Class_A m__ES_TN_int ;
My_Class_A m__ES_TN_long ;
My_Class_A m__UB_int ;
My_Class_A m__RE_TN_float ;
My_Class_A m__UAS_int ;
My_Class_A m__UAS_long ;
My_Class_A m__UAS_float ;
My_Class_A m__ES_TN_float ;
My_Class_A m__RE_TN_long ;
My_Class_A m__UAS_double ;
My_Class_A m__OT_ELS ;
My_Class_A m__OT_ELS_int ;
My_Class_A m__OT_ELS_long ;
My_Class_A m__OT_ELS_float ;
My_Class_A m__RE_TN_double ;
My_Class_A m__RE_OR_EALS ;
My_Class_A m__RE_OR_EALS_int ;
My_Class_A m__ES_OR_ELS_long ;
My_Class_A m__DD_double ;
My_Class_A m__DD_string ;
My_Class_A m__UB ;
My_Class_A m__UB_long ;
My_Class_A m__UB_float ;
My_Class_A m__UB_double ;
My_Class_A m__ULT ;
My_Class_A m__ULT_int ;
My_Class_A m__RE_OR_EALS_long ;
My_Class_A m__RE_OR_EALS_float ;
My_Class_A m__RE_OR_EALS_double ;
My_Class_A m__UAS ;
My_Class_A m__OT_ELS_double ;
My_Class_A m__IV ;
My_Class_A m__Izas ;

My_Class_A m_XXX ; /// add one to cause first level problem
****************************
My_Class_A m_YYY ; /// add both to cause second level problem
****************************
} ;
//----------------------------------------------
//----------------------------------------------

"Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
news:uC**************@TK2MSFTNGP11.phx.gbl...

Hi Vince,

However, you present a way I might be able to keep working. I could change
my members to pointers, and if that allows it to compile, then I can keep
working! So thanks again!

[==P==]

"Vince Yuan" <sh*******@citiz.net> wrote in message
news:O2*************@tk2msftngp13.phx.gbl...

Hi Perteroid,
I changed
OAP_Branch m_Root ;
to
OAP_Branch^ m_Root ;

Compiler accecpted your code.

And another way is to change
ref class OAP_Branch
to
value class OAP_Branch

Hope this helps.
--
Vince

[Peter Oliphant]

I have experimented with using more than one type of member to the
'offending' class. As such, I've reached this conclusion:

You cannot have more than 124 (user-defined?) stack semantic members, even
of mixed types, at the same time in one class.

I don't know if this applies only to 'ref' classes, or whether the fact I'm
using clr:/pure syntax is a factor. I have been able to re-create the
problem with deterministic 100% 'success' in both VS C++.NET Express 2005
and VS C++.NET 2005 PRO.

[==P==]

"Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
news:u%****************@TK2MSFTNGP12.phx.gbl...

This version is probably as close to as minimal a source file that can be
that causes error c1026:

//-----------------------------
#pragma once
//
// NOTE: At bottom are two source lines for m_XXX, and m_YYY. if you
comment them both
// out this will compile. If you un-comment one you get first level error,
un-comment
// both you get a second level error (you'll see).
//
// WORKAROUND: Change enough stack semantic members to pointers.
// [courtesy of Vince Yuan]
//

ref class My_Class_A
{
public:
My_Class_A() {}
~My_Class_A() {}
} ;

ref class My_Class_B
{
public:

My_Class_B() {}
~My_Class_B() {}

My_Class_A m_Root ;
My_Class_A m_Inunt ;
My_Class_A m_0_Is ;
My_Class_A m_1_Is ;
My_Class_A m_2_Is ;
My_Class_A m_L_NT ;
My_Class_A m_L_NP ;
My_Class_A m_L_AD ;
My_Class_A m_L_O ;
My_Class_A m_3_Is ;
My_Class_A m_N_Is ;
My_Class_A m_Ount ;
My_Class_A m_0_Os ;
My_Class_A m_1_Os ;
My_Class_A m_2_Os ;
My_Class_A m_3_Os ;
My_Class_A m_N_Os ;
My_Class_A m_Loc ;
My_Class_A m_Ariic ;
My_Class_A m_y ;
My_Class_A m_pason ;
My_Class_A m_stt ;
My_Class_A m_veion ;
My_Class_A m_utode ;
My_Class_A m_puNode ;
My_Class_A m_Ma ;
My_Class_A m_Vaable ;
My_Class_A m_Spial ;
My_Class_A m_L_NND ;
My_Class_A m_L_NR ;
My_Class_A m_L_EU ;
My_Class_A m_C_int ;
My_Class_A m_C_long ;
My_Class_A m_C_float ;
My_Class_A m_C_double ;
My_Class_A m_C_ZO_float ;
My_Class_A m_C_ZO_double ;
My_Class_A m_C_ZO_char ;
My_Class_A m_C_ZO_string ;
My_Class_A m_L_NT_EQU ;
My_Class_A m_L_LFT ;
My_Class_A m_L_RGHT ;
My_Class_A m_L_NT_LEFT ;
My_Class_A m_L_NT_RHT ;
My_Class_A m_L_TUE ;
My_Class_A m_L_FLSE ;
My_Class_A m_L_IPIES ;
My_Class_A m_L_NT_IIS ;
My_Class_A m_L_IPED_BY ;
My_Class_A m_L_NT_IMED_BY ;
My_Class_A m_C_bool ;
My_Class_A m_C_bool_TRUE ;
My_Class_A m_C_bool_FALSE ;
My_Class_A m_C_OE ;
My_Class_A m_C_OE_int ;
My_Class_A m_O_long ;
My_Class_A m_O_float ;
My_Class_A m_O_double ;
My_Class_A m_O_char ;
My_Class_A m_O_string ;
My_Class_A m_O_uni ;
My_Class_A m_C_OE_long ;
My_Class_A m_C_OE_float ;
My_Class_A m_C_OE_double ;
My_Class_A m_C_OE_char ;
My_Class_A m_C_OE_string ;
My_Class_A m_O_bool ;
My_Class_A m_O_int ;
My_Class_A m_C_char ;
My_Class_A m_C_string ;
My_Class_A m_C_PI ;
My_Class_A m_C_ZO ;
My_Class_A m_C_ZO_int ;
My_Class_A m_C_ZO_long ;
My_Class_A m_Sp_DATE ;
My_Class_A m_Sp_TIME ;
My_Class_A m__DD ;
My_Class_A m__DD_int ;
My_Class_A m__DD_long ;
My_Class_A m__DD_float ;
My_Class_A m__ULT_float ;
My_Class_A m__ES_TN_double ;
My_Class_A m__ES_OR_ELS ;
My_Class_A m__ES_OR_ELS_int ;
My_Class_A m__ULT_long ;
My_Class_A m__ES_OR_ELS_float ;
My_Class_A m__ES_OR_ELS_double ;
My_Class_A m__RE_TN ;
My_Class_A m__RE_TN_int ;
My_Class_A m__ULT_double ;
My_Class_A m__ES_TN ;
My_Class_A m__ES_TN_int ;
My_Class_A m__ES_TN_long ;
My_Class_A m__UB_int ;
My_Class_A m__RE_TN_float ;
My_Class_A m__UAS_int ;
My_Class_A m__UAS_long ;
My_Class_A m__UAS_float ;
My_Class_A m__ES_TN_float ;
My_Class_A m__RE_TN_long ;
My_Class_A m__UAS_double ;
My_Class_A m__OT_ELS ;
My_Class_A m__OT_ELS_int ;
My_Class_A m__OT_ELS_long ;
My_Class_A m__OT_ELS_float ;
My_Class_A m__RE_TN_double ;
My_Class_A m__RE_OR_EALS ;
My_Class_A m__RE_OR_EALS_int ;
My_Class_A m__ES_OR_ELS_long ;
My_Class_A m__DD_double ;
My_Class_A m__DD_string ;
My_Class_A m__UB ;
My_Class_A m__UB_long ;
My_Class_A m__UB_float ;
My_Class_A m__UB_double ;
My_Class_A m__ULT ;
My_Class_A m__ULT_int ;
My_Class_A m__RE_OR_EALS_long ;
My_Class_A m__RE_OR_EALS_float ;
My_Class_A m__RE_OR_EALS_double ;
My_Class_A m__UAS ;
My_Class_A m__OT_ELS_double ;
My_Class_A m__IV ;
My_Class_A m__Izas ;

My_Class_A m_XXX ; /// add one to cause first level problem
****************************
My_Class_A m_YYY ; /// add both to cause second level problem
****************************
} ;
//----------------------------------------------
//----------------------------------------------

"Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
news:uC**************@TK2MSFTNGP11.phx.gbl...

Hi Vince,

However, you present a way I might be able to keep working. I could
change my members to pointers, and if that allows it to compile, then I
can keep working! So thanks again!

[==P==]

"Vince Yuan" <sh*******@citiz.net> wrote in message
news:O2*************@tk2msftngp13.phx.gbl...

Hi Perteroid,
I changed
OAP_Branch m_Root ;
to
OAP_Branch^ m_Root ;

Compiler accecpted your code.

And another way is to change
ref class OAP_Branch
to
value class OAP_Branch

Hope this helps.
--
Vince

[Willy Denoyette [MVP]]

I don't thing it's due to the number of members, IMO the code
parser/generator has problems with the destructor (Dispose pattern), remove
the destructor and the problem goes away (tried with 240 members).

Willy.

"Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...

I have experimented with using more than one type of member to the
'offending' class. As such, I've reached this conclusion:

You cannot have more than 124 (user-defined?) stack semantic members, even
of mixed types, at the same time in one class.

I don't know if this applies only to 'ref' classes, or whether the fact
I'm using clr:/pure syntax is a factor. I have been able to re-create the
problem with deterministic 100% 'success' in both VS C++.NET Express 2005
and VS C++.NET 2005 PRO.

[==P==]

"Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
news:u%****************@TK2MSFTNGP12.phx.gbl...

This version is probably as close to as minimal a source file that can be
that causes error c1026:

//-----------------------------
#pragma once
//
// NOTE: At bottom are two source lines for m_XXX, and m_YYY. if you
comment them both
// out this will compile. If you un-comment one you get first level
error, un-comment
// both you get a second level error (you'll see).
//
// WORKAROUND: Change enough stack semantic members to pointers.
// [courtesy of Vince Yuan]
//

ref class My_Class_A
{
public:
My_Class_A() {}
~My_Class_A() {}
} ;

ref class My_Class_B
{
public:

My_Class_B() {}
~My_Class_B() {}

My_Class_A m_Root ;
My_Class_A m_Inunt ;
My_Class_A m_0_Is ;
My_Class_A m_1_Is ;
My_Class_A m_2_Is ;
My_Class_A m_L_NT ;
My_Class_A m_L_NP ;
My_Class_A m_L_AD ;
My_Class_A m_L_O ;
My_Class_A m_3_Is ;
My_Class_A m_N_Is ;
My_Class_A m_Ount ;
My_Class_A m_0_Os ;
My_Class_A m_1_Os ;
My_Class_A m_2_Os ;
My_Class_A m_3_Os ;
My_Class_A m_N_Os ;
My_Class_A m_Loc ;
My_Class_A m_Ariic ;
My_Class_A m_y ;
My_Class_A m_pason ;
My_Class_A m_stt ;
My_Class_A m_veion ;
My_Class_A m_utode ;
My_Class_A m_puNode ;
My_Class_A m_Ma ;
My_Class_A m_Vaable ;
My_Class_A m_Spial ;
My_Class_A m_L_NND ;
My_Class_A m_L_NR ;
My_Class_A m_L_EU ;
My_Class_A m_C_int ;
My_Class_A m_C_long ;
My_Class_A m_C_float ;
My_Class_A m_C_double ;
My_Class_A m_C_ZO_float ;
My_Class_A m_C_ZO_double ;
My_Class_A m_C_ZO_char ;
My_Class_A m_C_ZO_string ;
My_Class_A m_L_NT_EQU ;
My_Class_A m_L_LFT ;
My_Class_A m_L_RGHT ;
My_Class_A m_L_NT_LEFT ;
My_Class_A m_L_NT_RHT ;
My_Class_A m_L_TUE ;
My_Class_A m_L_FLSE ;
My_Class_A m_L_IPIES ;
My_Class_A m_L_NT_IIS ;
My_Class_A m_L_IPED_BY ;
My_Class_A m_L_NT_IMED_BY ;
My_Class_A m_C_bool ;
My_Class_A m_C_bool_TRUE ;
My_Class_A m_C_bool_FALSE ;
My_Class_A m_C_OE ;
My_Class_A m_C_OE_int ;
My_Class_A m_O_long ;
My_Class_A m_O_float ;
My_Class_A m_O_double ;
My_Class_A m_O_char ;
My_Class_A m_O_string ;
My_Class_A m_O_uni ;
My_Class_A m_C_OE_long ;
My_Class_A m_C_OE_float ;
My_Class_A m_C_OE_double ;
My_Class_A m_C_OE_char ;
My_Class_A m_C_OE_string ;
My_Class_A m_O_bool ;
My_Class_A m_O_int ;
My_Class_A m_C_char ;
My_Class_A m_C_string ;
My_Class_A m_C_PI ;
My_Class_A m_C_ZO ;
My_Class_A m_C_ZO_int ;
My_Class_A m_C_ZO_long ;
My_Class_A m_Sp_DATE ;
My_Class_A m_Sp_TIME ;
My_Class_A m__DD ;
My_Class_A m__DD_int ;
My_Class_A m__DD_long ;
My_Class_A m__DD_float ;
My_Class_A m__ULT_float ;
My_Class_A m__ES_TN_double ;
My_Class_A m__ES_OR_ELS ;
My_Class_A m__ES_OR_ELS_int ;
My_Class_A m__ULT_long ;
My_Class_A m__ES_OR_ELS_float ;
My_Class_A m__ES_OR_ELS_double ;
My_Class_A m__RE_TN ;
My_Class_A m__RE_TN_int ;
My_Class_A m__ULT_double ;
My_Class_A m__ES_TN ;
My_Class_A m__ES_TN_int ;
My_Class_A m__ES_TN_long ;
My_Class_A m__UB_int ;
My_Class_A m__RE_TN_float ;
My_Class_A m__UAS_int ;
My_Class_A m__UAS_long ;
My_Class_A m__UAS_float ;
My_Class_A m__ES_TN_float ;
My_Class_A m__RE_TN_long ;
My_Class_A m__UAS_double ;
My_Class_A m__OT_ELS ;
My_Class_A m__OT_ELS_int ;
My_Class_A m__OT_ELS_long ;
My_Class_A m__OT_ELS_float ;
My_Class_A m__RE_TN_double ;
My_Class_A m__RE_OR_EALS ;
My_Class_A m__RE_OR_EALS_int ;
My_Class_A m__ES_OR_ELS_long ;
My_Class_A m__DD_double ;
My_Class_A m__DD_string ;
My_Class_A m__UB ;
My_Class_A m__UB_long ;
My_Class_A m__UB_float ;
My_Class_A m__UB_double ;
My_Class_A m__ULT ;
My_Class_A m__ULT_int ;
My_Class_A m__RE_OR_EALS_long ;
My_Class_A m__RE_OR_EALS_float ;
My_Class_A m__RE_OR_EALS_double ;
My_Class_A m__UAS ;
My_Class_A m__OT_ELS_double ;
My_Class_A m__IV ;
My_Class_A m__Izas ;

My_Class_A m_XXX ; /// add one to cause first level problem
****************************
My_Class_A m_YYY ; /// add both to cause second level problem
****************************
} ;
//----------------------------------------------
//----------------------------------------------

"Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
news:uC**************@TK2MSFTNGP11.phx.gbl...

Hi Vince,

However, you present a way I might be able to keep working. I could
change my members to pointers, and if that allows it to compile, then I
can keep working! So thanks again!

[==P==]

"Vince Yuan" <sh*******@citiz.net> wrote in message
news:O2*************@tk2msftngp13.phx.gbl...
Hi Perteroid,
I changed
OAP_Branch m_Root ;
to
OAP_Branch^ m_Root ;

Compiler accecpted your code.

And another way is to change
ref class OAP_Branch
to
value class OAP_Branch

Hope this helps.
--
Vince

[Peter Oliphant]

Willy,

Cool! I never ever create a class without a destructor. But my destructor is
code-less, so I guess it's ok to remove it based on what you said!!! Thanks!

[==P==]

"Willy Denoyette [MVP]" <wi*************@telenet.be> wrote in message
news:uI**************@TK2MSFTNGP14.phx.gbl...

I don't thing it's due to the number of members, IMO the code
parser/generator has problems with the destructor (Dispose pattern), remove
the destructor and the problem goes away (tried with 240 members).

Willy.

"Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...

I have experimented with using more than one type of member to the
'offending' class. As such, I've reached this conclusion:

You cannot have more than 124 (user-defined?) stack semantic members,
even of mixed types, at the same time in one class.

I don't know if this applies only to 'ref' classes, or whether the fact
I'm using clr:/pure syntax is a factor. I have been able to re-create the
problem with deterministic 100% 'success' in both VS C++.NET Express 2005
and VS C++.NET 2005 PRO.

[==P==]

"Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
news:u%****************@TK2MSFTNGP12.phx.gbl...

This version is probably as close to as minimal a source file that can
be that causes error c1026:

//-----------------------------
#pragma once
//
// NOTE: At bottom are two source lines for m_XXX, and m_YYY. if you
comment them both
// out this will compile. If you un-comment one you get first level
error, un-comment
// both you get a second level error (you'll see).
//
// WORKAROUND: Change enough stack semantic members to pointers.
// [courtesy of Vince Yuan]
//

ref class My_Class_A
{
public:
My_Class_A() {}
~My_Class_A() {}
} ;

ref class My_Class_B
{
public:

My_Class_B() {}
~My_Class_B() {}

My_Class_A m_Root ;
My_Class_A m_Inunt ;
My_Class_A m_0_Is ;
My_Class_A m_1_Is ;
My_Class_A m_2_Is ;
My_Class_A m_L_NT ;
My_Class_A m_L_NP ;
My_Class_A m_L_AD ;
My_Class_A m_L_O ;
My_Class_A m_3_Is ;
My_Class_A m_N_Is ;
My_Class_A m_Ount ;
My_Class_A m_0_Os ;
My_Class_A m_1_Os ;
My_Class_A m_2_Os ;
My_Class_A m_3_Os ;
My_Class_A m_N_Os ;
My_Class_A m_Loc ;
My_Class_A m_Ariic ;
My_Class_A m_y ;
My_Class_A m_pason ;
My_Class_A m_stt ;
My_Class_A m_veion ;
My_Class_A m_utode ;
My_Class_A m_puNode ;
My_Class_A m_Ma ;
My_Class_A m_Vaable ;
My_Class_A m_Spial ;
My_Class_A m_L_NND ;
My_Class_A m_L_NR ;
My_Class_A m_L_EU ;
My_Class_A m_C_int ;
My_Class_A m_C_long ;
My_Class_A m_C_float ;
My_Class_A m_C_double ;
My_Class_A m_C_ZO_float ;
My_Class_A m_C_ZO_double ;
My_Class_A m_C_ZO_char ;
My_Class_A m_C_ZO_string ;
My_Class_A m_L_NT_EQU ;
My_Class_A m_L_LFT ;
My_Class_A m_L_RGHT ;
My_Class_A m_L_NT_LEFT ;
My_Class_A m_L_NT_RHT ;
My_Class_A m_L_TUE ;
My_Class_A m_L_FLSE ;
My_Class_A m_L_IPIES ;
My_Class_A m_L_NT_IIS ;
My_Class_A m_L_IPED_BY ;
My_Class_A m_L_NT_IMED_BY ;
My_Class_A m_C_bool ;
My_Class_A m_C_bool_TRUE ;
My_Class_A m_C_bool_FALSE ;
My_Class_A m_C_OE ;
My_Class_A m_C_OE_int ;
My_Class_A m_O_long ;
My_Class_A m_O_float ;
My_Class_A m_O_double ;
My_Class_A m_O_char ;
My_Class_A m_O_string ;
My_Class_A m_O_uni ;
My_Class_A m_C_OE_long ;
My_Class_A m_C_OE_float ;
My_Class_A m_C_OE_double ;
My_Class_A m_C_OE_char ;
My_Class_A m_C_OE_string ;
My_Class_A m_O_bool ;
My_Class_A m_O_int ;
My_Class_A m_C_char ;
My_Class_A m_C_string ;
My_Class_A m_C_PI ;
My_Class_A m_C_ZO ;
My_Class_A m_C_ZO_int ;
My_Class_A m_C_ZO_long ;
My_Class_A m_Sp_DATE ;
My_Class_A m_Sp_TIME ;
My_Class_A m__DD ;
My_Class_A m__DD_int ;
My_Class_A m__DD_long ;
My_Class_A m__DD_float ;
My_Class_A m__ULT_float ;
My_Class_A m__ES_TN_double ;
My_Class_A m__ES_OR_ELS ;
My_Class_A m__ES_OR_ELS_int ;
My_Class_A m__ULT_long ;
My_Class_A m__ES_OR_ELS_float ;
My_Class_A m__ES_OR_ELS_double ;
My_Class_A m__RE_TN ;
My_Class_A m__RE_TN_int ;
My_Class_A m__ULT_double ;
My_Class_A m__ES_TN ;
My_Class_A m__ES_TN_int ;
My_Class_A m__ES_TN_long ;
My_Class_A m__UB_int ;
My_Class_A m__RE_TN_float ;
My_Class_A m__UAS_int ;
My_Class_A m__UAS_long ;
My_Class_A m__UAS_float ;
My_Class_A m__ES_TN_float ;
My_Class_A m__RE_TN_long ;
My_Class_A m__UAS_double ;
My_Class_A m__OT_ELS ;
My_Class_A m__OT_ELS_int ;
My_Class_A m__OT_ELS_long ;
My_Class_A m__OT_ELS_float ;
My_Class_A m__RE_TN_double ;
My_Class_A m__RE_OR_EALS ;
My_Class_A m__RE_OR_EALS_int ;
My_Class_A m__ES_OR_ELS_long ;
My_Class_A m__DD_double ;
My_Class_A m__DD_string ;
My_Class_A m__UB ;
My_Class_A m__UB_long ;
My_Class_A m__UB_float ;
My_Class_A m__UB_double ;
My_Class_A m__ULT ;
My_Class_A m__ULT_int ;
My_Class_A m__RE_OR_EALS_long ;
My_Class_A m__RE_OR_EALS_float ;
My_Class_A m__RE_OR_EALS_double ;
My_Class_A m__UAS ;
My_Class_A m__OT_ELS_double ;
My_Class_A m__IV ;
My_Class_A m__Izas ;

My_Class_A m_XXX ; /// add one to cause first level problem
****************************
My_Class_A m_YYY ; /// add both to cause second level problem
****************************
} ;
//----------------------------------------------
//----------------------------------------------

"Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
news:uC**************@TK2MSFTNGP11.phx.gbl...
Hi Vince,

However, you present a way I might be able to keep working. I could
change my members to pointers, and if that allows it to compile, then I
can keep working! So thanks again!

[==P==]

"Vince Yuan" <sh*******@citiz.net> wrote in message
news:O2*************@tk2msftngp13.phx.gbl...
> Hi Perteroid,
> I changed
> OAP_Branch m_Root ;
> to
> OAP_Branch^ m_Root ;
>
> Compiler accecpted your code.
>
> And another way is to change
> ref class OAP_Branch
> to
> value class OAP_Branch
>
> Hope this helps.
> --
> Vince
>
>
>

[Willy Denoyette [MVP]]

Peter,
Codeless destructors in C++/CLI are needless, you can safely remove them.
But that doesn't mean there is no bug in the compiler.

Willy.

"Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
news:eq**************@TK2MSFTNGP14.phx.gbl...

Willy,

Cool! I never ever create a class without a destructor. But my destructor
is code-less, so I guess it's ok to remove it based on what you said!!!
Thanks!

[==P==]

"Willy Denoyette [MVP]" <wi*************@telenet.be> wrote in message
news:uI**************@TK2MSFTNGP14.phx.gbl...

I don't thing it's due to the number of members, IMO the code
parser/generator has problems with the destructor (Dispose pattern),
remove the destructor and the problem goes away (tried with 240 members).

Willy.

"Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...

I have experimented with using more than one type of member to the
'offending' class. As such, I've reached this conclusion:

You cannot have more than 124 (user-defined?) stack semantic members,
even of mixed types, at the same time in one class.

I don't know if this applies only to 'ref' classes, or whether the fact
I'm using clr:/pure syntax is a factor. I have been able to re-create
the problem with deterministic 100% 'success' in both VS C++.NET Express
2005 and VS C++.NET 2005 PRO.

[==P==]

"Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
news:u%****************@TK2MSFTNGP12.phx.gbl...
This version is probably as close to as minimal a source file that can
be that causes error c1026:

//-----------------------------
#pragma once
//
// NOTE: At bottom are two source lines for m_XXX, and m_YYY. if you
comment them both
// out this will compile. If you un-comment one you get first level
error, un-comment
// both you get a second level error (you'll see).
//
// WORKAROUND: Change enough stack semantic members to pointers.
// [courtesy of Vince Yuan]
//

ref class My_Class_A
{
public:
My_Class_A() {}
~My_Class_A() {}
} ;

ref class My_Class_B
{
public:

My_Class_B() {}
~My_Class_B() {}

My_Class_A m_Root ;
My_Class_A m_Inunt ;
My_Class_A m_0_Is ;
My_Class_A m_1_Is ;
My_Class_A m_2_Is ;
My_Class_A m_L_NT ;
My_Class_A m_L_NP ;
My_Class_A m_L_AD ;
My_Class_A m_L_O ;
My_Class_A m_3_Is ;
My_Class_A m_N_Is ;
My_Class_A m_Ount ;
My_Class_A m_0_Os ;
My_Class_A m_1_Os ;
My_Class_A m_2_Os ;
My_Class_A m_3_Os ;
My_Class_A m_N_Os ;
My_Class_A m_Loc ;
My_Class_A m_Ariic ;
My_Class_A m_y ;
My_Class_A m_pason ;
My_Class_A m_stt ;
My_Class_A m_veion ;
My_Class_A m_utode ;
My_Class_A m_puNode ;
My_Class_A m_Ma ;
My_Class_A m_Vaable ;
My_Class_A m_Spial ;
My_Class_A m_L_NND ;
My_Class_A m_L_NR ;
My_Class_A m_L_EU ;
My_Class_A m_C_int ;
My_Class_A m_C_long ;
My_Class_A m_C_float ;
My_Class_A m_C_double ;
My_Class_A m_C_ZO_float ;
My_Class_A m_C_ZO_double ;
My_Class_A m_C_ZO_char ;
My_Class_A m_C_ZO_string ;
My_Class_A m_L_NT_EQU ;
My_Class_A m_L_LFT ;
My_Class_A m_L_RGHT ;
My_Class_A m_L_NT_LEFT ;
My_Class_A m_L_NT_RHT ;
My_Class_A m_L_TUE ;
My_Class_A m_L_FLSE ;
My_Class_A m_L_IPIES ;
My_Class_A m_L_NT_IIS ;
My_Class_A m_L_IPED_BY ;
My_Class_A m_L_NT_IMED_BY ;
My_Class_A m_C_bool ;
My_Class_A m_C_bool_TRUE ;
My_Class_A m_C_bool_FALSE ;
My_Class_A m_C_OE ;
My_Class_A m_C_OE_int ;
My_Class_A m_O_long ;
My_Class_A m_O_float ;
My_Class_A m_O_double ;
My_Class_A m_O_char ;
My_Class_A m_O_string ;
My_Class_A m_O_uni ;
My_Class_A m_C_OE_long ;
My_Class_A m_C_OE_float ;
My_Class_A m_C_OE_double ;
My_Class_A m_C_OE_char ;
My_Class_A m_C_OE_string ;
My_Class_A m_O_bool ;
My_Class_A m_O_int ;
My_Class_A m_C_char ;
My_Class_A m_C_string ;
My_Class_A m_C_PI ;
My_Class_A m_C_ZO ;
My_Class_A m_C_ZO_int ;
My_Class_A m_C_ZO_long ;
My_Class_A m_Sp_DATE ;
My_Class_A m_Sp_TIME ;
My_Class_A m__DD ;
My_Class_A m__DD_int ;
My_Class_A m__DD_long ;
My_Class_A m__DD_float ;
My_Class_A m__ULT_float ;
My_Class_A m__ES_TN_double ;
My_Class_A m__ES_OR_ELS ;
My_Class_A m__ES_OR_ELS_int ;
My_Class_A m__ULT_long ;
My_Class_A m__ES_OR_ELS_float ;
My_Class_A m__ES_OR_ELS_double ;
My_Class_A m__RE_TN ;
My_Class_A m__RE_TN_int ;
My_Class_A m__ULT_double ;
My_Class_A m__ES_TN ;
My_Class_A m__ES_TN_int ;
My_Class_A m__ES_TN_long ;
My_Class_A m__UB_int ;
My_Class_A m__RE_TN_float ;
My_Class_A m__UAS_int ;
My_Class_A m__UAS_long ;
My_Class_A m__UAS_float ;
My_Class_A m__ES_TN_float ;
My_Class_A m__RE_TN_long ;
My_Class_A m__UAS_double ;
My_Class_A m__OT_ELS ;
My_Class_A m__OT_ELS_int ;
My_Class_A m__OT_ELS_long ;
My_Class_A m__OT_ELS_float ;
My_Class_A m__RE_TN_double ;
My_Class_A m__RE_OR_EALS ;
My_Class_A m__RE_OR_EALS_int ;
My_Class_A m__ES_OR_ELS_long ;
My_Class_A m__DD_double ;
My_Class_A m__DD_string ;
My_Class_A m__UB ;
My_Class_A m__UB_long ;
My_Class_A m__UB_float ;
My_Class_A m__UB_double ;
My_Class_A m__ULT ;
My_Class_A m__ULT_int ;
My_Class_A m__RE_OR_EALS_long ;
My_Class_A m__RE_OR_EALS_float ;
My_Class_A m__RE_OR_EALS_double ;
My_Class_A m__UAS ;
My_Class_A m__OT_ELS_double ;
My_Class_A m__IV ;
My_Class_A m__Izas ;

My_Class_A m_XXX ; /// add one to cause first level problem
****************************
My_Class_A m_YYY ; /// add both to cause second level problem
****************************
} ;
//----------------------------------------------
//----------------------------------------------

"Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
news:uC**************@TK2MSFTNGP11.phx.gbl...
> Hi Vince,
>
> However, you present a way I might be able to keep working. I could
> change my members to pointers, and if that allows it to compile, then
> I can keep working! So thanks again!
>
> [==P==]
>
> "Vince Yuan" <sh*******@citiz.net> wrote in message
> news:O2*************@tk2msftngp13.phx.gbl...
>> Hi Perteroid,
>> I changed
>> OAP_Branch m_Root ;
>> to
>> OAP_Branch^ m_Root ;
>>
>> Compiler accecpted your code.
>>
>> And another way is to change
>> ref class OAP_Branch
>> to
>> value class OAP_Branch
>>
>> Hope this helps.
>> --
>> Vince
>>
>>
>>
>
>

[Peter Oliphant]

So, I guess this means the real problem is that the new syntax has a limit
of 124 members any one ref class can be responsible for destroying
deterministically!

This is probably why pointers don't cause a problem: the responsibility for
destroying pointer type constructed instances is in the hands of the GC in a
non-deterministic way, or the programmer via manual means. This is in
contrast to the class itself being responsible for destruction of its stack
semantic members, and its this responsibility it seems to have an upper
limit of 124...

[==P==]

"Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
news:eq**************@TK2MSFTNGP14.phx.gbl...

Willy,

Cool! I never ever create a class without a destructor. But my destructor
is code-less, so I guess it's ok to remove it based on what you said!!!
Thanks!

[==P==]

"Willy Denoyette [MVP]" <wi*************@telenet.be> wrote in message
news:uI**************@TK2MSFTNGP14.phx.gbl...

I don't thing it's due to the number of members, IMO the code
parser/generator has problems with the destructor (Dispose pattern),
remove the destructor and the problem goes away (tried with 240 members).

Willy.

"Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...

I have experimented with using more than one type of member to the
'offending' class. As such, I've reached this conclusion:

You cannot have more than 124 (user-defined?) stack semantic members,
even of mixed types, at the same time in one class.

I don't know if this applies only to 'ref' classes, or whether the fact
I'm using clr:/pure syntax is a factor. I have been able to re-create
the problem with deterministic 100% 'success' in both VS C++.NET Express
2005 and VS C++.NET 2005 PRO.

[==P==]

"Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
news:u%****************@TK2MSFTNGP12.phx.gbl...
This version is probably as close to as minimal a source file that can
be that causes error c1026:

//-----------------------------
#pragma once
//
// NOTE: At bottom are two source lines for m_XXX, and m_YYY. if you
comment them both
// out this will compile. If you un-comment one you get first level
error, un-comment
// both you get a second level error (you'll see).
//
// WORKAROUND: Change enough stack semantic members to pointers.
// [courtesy of Vince Yuan]
//

ref class My_Class_A
{
public:
My_Class_A() {}
~My_Class_A() {}
} ;

ref class My_Class_B
{
public:

My_Class_B() {}
~My_Class_B() {}

My_Class_A m_Root ;
My_Class_A m_Inunt ;
My_Class_A m_0_Is ;
My_Class_A m_1_Is ;
My_Class_A m_2_Is ;
My_Class_A m_L_NT ;
My_Class_A m_L_NP ;
My_Class_A m_L_AD ;
My_Class_A m_L_O ;
My_Class_A m_3_Is ;
My_Class_A m_N_Is ;
My_Class_A m_Ount ;
My_Class_A m_0_Os ;
My_Class_A m_1_Os ;
My_Class_A m_2_Os ;
My_Class_A m_3_Os ;
My_Class_A m_N_Os ;
My_Class_A m_Loc ;
My_Class_A m_Ariic ;
My_Class_A m_y ;
My_Class_A m_pason ;
My_Class_A m_stt ;
My_Class_A m_veion ;
My_Class_A m_utode ;
My_Class_A m_puNode ;
My_Class_A m_Ma ;
My_Class_A m_Vaable ;
My_Class_A m_Spial ;
My_Class_A m_L_NND ;
My_Class_A m_L_NR ;
My_Class_A m_L_EU ;
My_Class_A m_C_int ;
My_Class_A m_C_long ;
My_Class_A m_C_float ;
My_Class_A m_C_double ;
My_Class_A m_C_ZO_float ;
My_Class_A m_C_ZO_double ;
My_Class_A m_C_ZO_char ;
My_Class_A m_C_ZO_string ;
My_Class_A m_L_NT_EQU ;
My_Class_A m_L_LFT ;
My_Class_A m_L_RGHT ;
My_Class_A m_L_NT_LEFT ;
My_Class_A m_L_NT_RHT ;
My_Class_A m_L_TUE ;
My_Class_A m_L_FLSE ;
My_Class_A m_L_IPIES ;
My_Class_A m_L_NT_IIS ;
My_Class_A m_L_IPED_BY ;
My_Class_A m_L_NT_IMED_BY ;
My_Class_A m_C_bool ;
My_Class_A m_C_bool_TRUE ;
My_Class_A m_C_bool_FALSE ;
My_Class_A m_C_OE ;
My_Class_A m_C_OE_int ;
My_Class_A m_O_long ;
My_Class_A m_O_float ;
My_Class_A m_O_double ;
My_Class_A m_O_char ;
My_Class_A m_O_string ;
My_Class_A m_O_uni ;
My_Class_A m_C_OE_long ;
My_Class_A m_C_OE_float ;
My_Class_A m_C_OE_double ;
My_Class_A m_C_OE_char ;
My_Class_A m_C_OE_string ;
My_Class_A m_O_bool ;
My_Class_A m_O_int ;
My_Class_A m_C_char ;
My_Class_A m_C_string ;
My_Class_A m_C_PI ;
My_Class_A m_C_ZO ;
My_Class_A m_C_ZO_int ;
My_Class_A m_C_ZO_long ;
My_Class_A m_Sp_DATE ;
My_Class_A m_Sp_TIME ;
My_Class_A m__DD ;
My_Class_A m__DD_int ;
My_Class_A m__DD_long ;
My_Class_A m__DD_float ;
My_Class_A m__ULT_float ;
My_Class_A m__ES_TN_double ;
My_Class_A m__ES_OR_ELS ;
My_Class_A m__ES_OR_ELS_int ;
My_Class_A m__ULT_long ;
My_Class_A m__ES_OR_ELS_float ;
My_Class_A m__ES_OR_ELS_double ;
My_Class_A m__RE_TN ;
My_Class_A m__RE_TN_int ;
My_Class_A m__ULT_double ;
My_Class_A m__ES_TN ;
My_Class_A m__ES_TN_int ;
My_Class_A m__ES_TN_long ;
My_Class_A m__UB_int ;
My_Class_A m__RE_TN_float ;
My_Class_A m__UAS_int ;
My_Class_A m__UAS_long ;
My_Class_A m__UAS_float ;
My_Class_A m__ES_TN_float ;
My_Class_A m__RE_TN_long ;
My_Class_A m__UAS_double ;
My_Class_A m__OT_ELS ;
My_Class_A m__OT_ELS_int ;
My_Class_A m__OT_ELS_long ;
My_Class_A m__OT_ELS_float ;
My_Class_A m__RE_TN_double ;
My_Class_A m__RE_OR_EALS ;
My_Class_A m__RE_OR_EALS_int ;
My_Class_A m__ES_OR_ELS_long ;
My_Class_A m__DD_double ;
My_Class_A m__DD_string ;
My_Class_A m__UB ;
My_Class_A m__UB_long ;
My_Class_A m__UB_float ;
My_Class_A m__UB_double ;
My_Class_A m__ULT ;
My_Class_A m__ULT_int ;
My_Class_A m__RE_OR_EALS_long ;
My_Class_A m__RE_OR_EALS_float ;
My_Class_A m__RE_OR_EALS_double ;
My_Class_A m__UAS ;
My_Class_A m__OT_ELS_double ;
My_Class_A m__IV ;
My_Class_A m__Izas ;

My_Class_A m_XXX ; /// add one to cause first level problem
****************************
My_Class_A m_YYY ; /// add both to cause second level problem
****************************
} ;
//----------------------------------------------
//----------------------------------------------

"Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
news:uC**************@TK2MSFTNGP11.phx.gbl...
> Hi Vince,
>
> However, you present a way I might be able to keep working. I could
> change my members to pointers, and if that allows it to compile, then
> I can keep working! So thanks again!
>
> [==P==]
>
> "Vince Yuan" <sh*******@citiz.net> wrote in message
> news:O2*************@tk2msftngp13.phx.gbl...
>> Hi Perteroid,
>> I changed
>> OAP_Branch m_Root ;
>> to
>> OAP_Branch^ m_Root ;
>>
>> Compiler accecpted your code.
>>
>> And another way is to change
>> ref class OAP_Branch
>> to
>> value class OAP_Branch
>>
>> Hope this helps.
>> --
>> Vince
>>
>>
>>
>
>

[Willy Denoyette [MVP]]

No, I don't think so. The problem is not a runtime issue, it's a compiler
issue. Or it's a compiler limitation or it's a compiler bug, if it's the
former (which I don't think it is), it should be documented, if it's the
latter it should (preferably) be corrected. Anyway, we'll have to wait to
see MSFT response to the filed bug report.

Willy.

"Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
news:en**************@TK2MSFTNGP14.phx.gbl...

So, I guess this means the real problem is that the new syntax has a limit
of 124 members any one ref class can be responsible for destroying
deterministically!

This is probably why pointers don't cause a problem: the responsibility
for destroying pointer type constructed instances is in the hands of the
GC in a non-deterministic way, or the programmer via manual means. This is
in contrast to the class itself being responsible for destruction of its
stack semantic members, and its this responsibility it seems to have an
upper limit of 124...

[==P==]

"Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
news:eq**************@TK2MSFTNGP14.phx.gbl...

Willy,

Cool! I never ever create a class without a destructor. But my destructor
is code-less, so I guess it's ok to remove it based on what you said!!!
Thanks!

[==P==]

"Willy Denoyette [MVP]" <wi*************@telenet.be> wrote in message
news:uI**************@TK2MSFTNGP14.phx.gbl...

I don't thing it's due to the number of members, IMO the code
parser/generator has problems with the destructor (Dispose pattern),
remove the destructor and the problem goes away (tried with 240 members).

Willy.

"Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...
I have experimented with using more than one type of member to the
'offending' class. As such, I've reached this conclusion:

You cannot have more than 124 (user-defined?) stack semantic members,
even of mixed types, at the same time in one class.

I don't know if this applies only to 'ref' classes, or whether the fact
I'm using clr:/pure syntax is a factor. I have been able to re-create
the problem with deterministic 100% 'success' in both VS C++.NET
Express 2005 and VS C++.NET 2005 PRO.

[==P==]

"Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
news:u%****************@TK2MSFTNGP12.phx.gbl...
> This version is probably as close to as minimal a source file that can
> be that causes error c1026:
>
> //-----------------------------
> #pragma once
> //
> // NOTE: At bottom are two source lines for m_XXX, and m_YYY. if you
> comment them both
> // out this will compile. If you un-comment one you get first level
> error, un-comment
> // both you get a second level error (you'll see).
> //
> // WORKAROUND: Change enough stack semantic members to pointers.
> // [courtesy of Vince Yuan]
> //
>
> ref class My_Class_A
> {
> public:
> My_Class_A() {}
> ~My_Class_A() {}
> } ;
>
> ref class My_Class_B
> {
> public:
>
> My_Class_B() {}
> ~My_Class_B() {}
>
> My_Class_A m_Root ;
> My_Class_A m_Inunt ;
> My_Class_A m_0_Is ;
> My_Class_A m_1_Is ;
> My_Class_A m_2_Is ;
> My_Class_A m_L_NT ;
> My_Class_A m_L_NP ;
> My_Class_A m_L_AD ;
> My_Class_A m_L_O ;
> My_Class_A m_3_Is ;
> My_Class_A m_N_Is ;
> My_Class_A m_Ount ;
> My_Class_A m_0_Os ;
> My_Class_A m_1_Os ;
> My_Class_A m_2_Os ;
> My_Class_A m_3_Os ;
> My_Class_A m_N_Os ;
> My_Class_A m_Loc ;
> My_Class_A m_Ariic ;
> My_Class_A m_y ;
> My_Class_A m_pason ;
> My_Class_A m_stt ;
> My_Class_A m_veion ;
> My_Class_A m_utode ;
> My_Class_A m_puNode ;
> My_Class_A m_Ma ;
> My_Class_A m_Vaable ;
> My_Class_A m_Spial ;
> My_Class_A m_L_NND ;
> My_Class_A m_L_NR ;
> My_Class_A m_L_EU ;
> My_Class_A m_C_int ;
> My_Class_A m_C_long ;
> My_Class_A m_C_float ;
> My_Class_A m_C_double ;
> My_Class_A m_C_ZO_float ;
> My_Class_A m_C_ZO_double ;
> My_Class_A m_C_ZO_char ;
> My_Class_A m_C_ZO_string ;
> My_Class_A m_L_NT_EQU ;
> My_Class_A m_L_LFT ;
> My_Class_A m_L_RGHT ;
> My_Class_A m_L_NT_LEFT ;
> My_Class_A m_L_NT_RHT ;
> My_Class_A m_L_TUE ;
> My_Class_A m_L_FLSE ;
> My_Class_A m_L_IPIES ;
> My_Class_A m_L_NT_IIS ;
> My_Class_A m_L_IPED_BY ;
> My_Class_A m_L_NT_IMED_BY ;
> My_Class_A m_C_bool ;
> My_Class_A m_C_bool_TRUE ;
> My_Class_A m_C_bool_FALSE ;
> My_Class_A m_C_OE ;
> My_Class_A m_C_OE_int ;
> My_Class_A m_O_long ;
> My_Class_A m_O_float ;
> My_Class_A m_O_double ;
> My_Class_A m_O_char ;
> My_Class_A m_O_string ;
> My_Class_A m_O_uni ;
> My_Class_A m_C_OE_long ;
> My_Class_A m_C_OE_float ;
> My_Class_A m_C_OE_double ;
> My_Class_A m_C_OE_char ;
> My_Class_A m_C_OE_string ;
> My_Class_A m_O_bool ;
> My_Class_A m_O_int ;
> My_Class_A m_C_char ;
> My_Class_A m_C_string ;
> My_Class_A m_C_PI ;
> My_Class_A m_C_ZO ;
> My_Class_A m_C_ZO_int ;
> My_Class_A m_C_ZO_long ;
> My_Class_A m_Sp_DATE ;
> My_Class_A m_Sp_TIME ;
> My_Class_A m__DD ;
> My_Class_A m__DD_int ;
> My_Class_A m__DD_long ;
> My_Class_A m__DD_float ;
> My_Class_A m__ULT_float ;
> My_Class_A m__ES_TN_double ;
> My_Class_A m__ES_OR_ELS ;
> My_Class_A m__ES_OR_ELS_int ;
> My_Class_A m__ULT_long ;
> My_Class_A m__ES_OR_ELS_float ;
> My_Class_A m__ES_OR_ELS_double ;
> My_Class_A m__RE_TN ;
> My_Class_A m__RE_TN_int ;
> My_Class_A m__ULT_double ;
> My_Class_A m__ES_TN ;
> My_Class_A m__ES_TN_int ;
> My_Class_A m__ES_TN_long ;
> My_Class_A m__UB_int ;
> My_Class_A m__RE_TN_float ;
> My_Class_A m__UAS_int ;
> My_Class_A m__UAS_long ;
> My_Class_A m__UAS_float ;
> My_Class_A m__ES_TN_float ;
> My_Class_A m__RE_TN_long ;
> My_Class_A m__UAS_double ;
> My_Class_A m__OT_ELS ;
> My_Class_A m__OT_ELS_int ;
> My_Class_A m__OT_ELS_long ;
> My_Class_A m__OT_ELS_float ;
> My_Class_A m__RE_TN_double ;
> My_Class_A m__RE_OR_EALS ;
> My_Class_A m__RE_OR_EALS_int ;
> My_Class_A m__ES_OR_ELS_long ;
> My_Class_A m__DD_double ;
> My_Class_A m__DD_string ;
> My_Class_A m__UB ;
> My_Class_A m__UB_long ;
> My_Class_A m__UB_float ;
> My_Class_A m__UB_double ;
> My_Class_A m__ULT ;
> My_Class_A m__ULT_int ;
> My_Class_A m__RE_OR_EALS_long ;
> My_Class_A m__RE_OR_EALS_float ;
> My_Class_A m__RE_OR_EALS_double ;
> My_Class_A m__UAS ;
> My_Class_A m__OT_ELS_double ;
> My_Class_A m__IV ;
> My_Class_A m__Izas ;
>
> My_Class_A m_XXX ; /// add one to cause first level problem
> ****************************
> My_Class_A m_YYY ; /// add both to cause second level problem
> ****************************
> } ;
> //----------------------------------------------
> //----------------------------------------------
>
> "Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
> news:uC**************@TK2MSFTNGP11.phx.gbl...
>> Hi Vince,
>>
>> However, you present a way I might be able to keep working. I could
>> change my members to pointers, and if that allows it to compile, then
>> I can keep working! So thanks again!
>>
>> [==P==]
>>
>> "Vince Yuan" <sh*******@citiz.net> wrote in message
>> news:O2*************@tk2msftngp13.phx.gbl...
>>> Hi Perteroid,
>>> I changed
>>> OAP_Branch m_Root ;
>>> to
>>> OAP_Branch^ m_Root ;
>>>
>>> Compiler accecpted your code.
>>>
>>> And another way is to change
>>> ref class OAP_Branch
>>> to
>>> value class OAP_Branch
>>>
>>> Hope this helps.
>>> --
>>> Vince
>>>
>>>
>>>
>>
>>
>
>

[Peter Oliphant]

Good point. I was viewing it from a 'run' point of view. Now I'm thinking as
it compiles it keeps track of how it must do destruction, and if the number
of things it needs to keep track of to destroy gets too big, it can't handle
it. Although 124 seems like kind of a small number to me... : )

I totally agree with you on the 'document or correct' point of view...

Yeah, I'd like to see the response from MFST too. This could be the cause of
a few things. I'm basing this on the fact that it was this same source file
that was generating my "IntelliSense Updating..."-takes-forever problem...

[==P==]

"Willy Denoyette [MVP]" <wi*************@telenet.be> wrote in message
news:Ob*************@TK2MSFTNGP15.phx.gbl...

No, I don't think so. The problem is not a runtime issue, it's a compiler
issue. Or it's a compiler limitation or it's a compiler bug, if it's the
former (which I don't think it is), it should be documented, if it's the
latter it should (preferably) be corrected. Anyway, we'll have to wait to
see MSFT response to the filed bug report.

Willy.

"Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
news:en**************@TK2MSFTNGP14.phx.gbl...

So, I guess this means the real problem is that the new syntax has a
limit of 124 members any one ref class can be responsible for destroying
deterministically!

This is probably why pointers don't cause a problem: the responsibility
for destroying pointer type constructed instances is in the hands of the
GC in a non-deterministic way, or the programmer via manual means. This
is in contrast to the class itself being responsible for destruction of
its stack semantic members, and its this responsibility it seems to have
an upper limit of 124...

[==P==]

"Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
news:eq**************@TK2MSFTNGP14.phx.gbl...

Willy,

Cool! I never ever create a class without a destructor. But my
destructor is code-less, so I guess it's ok to remove it based on what
you said!!! Thanks!

[==P==]

"Willy Denoyette [MVP]" <wi*************@telenet.be> wrote in message
news:uI**************@TK2MSFTNGP14.phx.gbl...
I don't thing it's due to the number of members, IMO the code
parser/generator has problems with the destructor (Dispose pattern),
remove the destructor and the problem goes away (tried with 240
members).

Willy.

"Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...
>I have experimented with using more than one type of member to the
>'offending' class. As such, I've reached this conclusion:
>
> You cannot have more than 124 (user-defined?) stack semantic members,
> even of mixed types, at the same time in one class.
>
> I don't know if this applies only to 'ref' classes, or whether the
> fact I'm using clr:/pure syntax is a factor. I have been able to
> re-create the problem with deterministic 100% 'success' in both VS
> C++.NET Express 2005 and VS C++.NET 2005 PRO.
>
> [==P==]
>
> "Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
> news:u%****************@TK2MSFTNGP12.phx.gbl...
>> This version is probably as close to as minimal a source file that
>> can be that causes error c1026:
>>
>> //-----------------------------
>> #pragma once
>> //
>> // NOTE: At bottom are two source lines for m_XXX, and m_YYY. if you
>> comment them both
>> // out this will compile. If you un-comment one you get first level
>> error, un-comment
>> // both you get a second level error (you'll see).
>> //
>> // WORKAROUND: Change enough stack semantic members to pointers.
>> // [courtesy of Vince Yuan]
>> //
>>
>> ref class My_Class_A
>> {
>> public:
>> My_Class_A() {}
>> ~My_Class_A() {}
>> } ;
>>
>> ref class My_Class_B
>> {
>> public:
>>
>> My_Class_B() {}
>> ~My_Class_B() {}
>>
>> My_Class_A m_Root ;
>> My_Class_A m_Inunt ;
>> My_Class_A m_0_Is ;
>> My_Class_A m_1_Is ;
>> My_Class_A m_2_Is ;
>> My_Class_A m_L_NT ;
>> My_Class_A m_L_NP ;
>> My_Class_A m_L_AD ;
>> My_Class_A m_L_O ;
>> My_Class_A m_3_Is ;
>> My_Class_A m_N_Is ;
>> My_Class_A m_Ount ;
>> My_Class_A m_0_Os ;
>> My_Class_A m_1_Os ;
>> My_Class_A m_2_Os ;
>> My_Class_A m_3_Os ;
>> My_Class_A m_N_Os ;
>> My_Class_A m_Loc ;
>> My_Class_A m_Ariic ;
>> My_Class_A m_y ;
>> My_Class_A m_pason ;
>> My_Class_A m_stt ;
>> My_Class_A m_veion ;
>> My_Class_A m_utode ;
>> My_Class_A m_puNode ;
>> My_Class_A m_Ma ;
>> My_Class_A m_Vaable ;
>> My_Class_A m_Spial ;
>> My_Class_A m_L_NND ;
>> My_Class_A m_L_NR ;
>> My_Class_A m_L_EU ;
>> My_Class_A m_C_int ;
>> My_Class_A m_C_long ;
>> My_Class_A m_C_float ;
>> My_Class_A m_C_double ;
>> My_Class_A m_C_ZO_float ;
>> My_Class_A m_C_ZO_double ;
>> My_Class_A m_C_ZO_char ;
>> My_Class_A m_C_ZO_string ;
>> My_Class_A m_L_NT_EQU ;
>> My_Class_A m_L_LFT ;
>> My_Class_A m_L_RGHT ;
>> My_Class_A m_L_NT_LEFT ;
>> My_Class_A m_L_NT_RHT ;
>> My_Class_A m_L_TUE ;
>> My_Class_A m_L_FLSE ;
>> My_Class_A m_L_IPIES ;
>> My_Class_A m_L_NT_IIS ;
>> My_Class_A m_L_IPED_BY ;
>> My_Class_A m_L_NT_IMED_BY ;
>> My_Class_A m_C_bool ;
>> My_Class_A m_C_bool_TRUE ;
>> My_Class_A m_C_bool_FALSE ;
>> My_Class_A m_C_OE ;
>> My_Class_A m_C_OE_int ;
>> My_Class_A m_O_long ;
>> My_Class_A m_O_float ;
>> My_Class_A m_O_double ;
>> My_Class_A m_O_char ;
>> My_Class_A m_O_string ;
>> My_Class_A m_O_uni ;
>> My_Class_A m_C_OE_long ;
>> My_Class_A m_C_OE_float ;
>> My_Class_A m_C_OE_double ;
>> My_Class_A m_C_OE_char ;
>> My_Class_A m_C_OE_string ;
>> My_Class_A m_O_bool ;
>> My_Class_A m_O_int ;
>> My_Class_A m_C_char ;
>> My_Class_A m_C_string ;
>> My_Class_A m_C_PI ;
>> My_Class_A m_C_ZO ;
>> My_Class_A m_C_ZO_int ;
>> My_Class_A m_C_ZO_long ;
>> My_Class_A m_Sp_DATE ;
>> My_Class_A m_Sp_TIME ;
>> My_Class_A m__DD ;
>> My_Class_A m__DD_int ;
>> My_Class_A m__DD_long ;
>> My_Class_A m__DD_float ;
>> My_Class_A m__ULT_float ;
>> My_Class_A m__ES_TN_double ;
>> My_Class_A m__ES_OR_ELS ;
>> My_Class_A m__ES_OR_ELS_int ;
>> My_Class_A m__ULT_long ;
>> My_Class_A m__ES_OR_ELS_float ;
>> My_Class_A m__ES_OR_ELS_double ;
>> My_Class_A m__RE_TN ;
>> My_Class_A m__RE_TN_int ;
>> My_Class_A m__ULT_double ;
>> My_Class_A m__ES_TN ;
>> My_Class_A m__ES_TN_int ;
>> My_Class_A m__ES_TN_long ;
>> My_Class_A m__UB_int ;
>> My_Class_A m__RE_TN_float ;
>> My_Class_A m__UAS_int ;
>> My_Class_A m__UAS_long ;
>> My_Class_A m__UAS_float ;
>> My_Class_A m__ES_TN_float ;
>> My_Class_A m__RE_TN_long ;
>> My_Class_A m__UAS_double ;
>> My_Class_A m__OT_ELS ;
>> My_Class_A m__OT_ELS_int ;
>> My_Class_A m__OT_ELS_long ;
>> My_Class_A m__OT_ELS_float ;
>> My_Class_A m__RE_TN_double ;
>> My_Class_A m__RE_OR_EALS ;
>> My_Class_A m__RE_OR_EALS_int ;
>> My_Class_A m__ES_OR_ELS_long ;
>> My_Class_A m__DD_double ;
>> My_Class_A m__DD_string ;
>> My_Class_A m__UB ;
>> My_Class_A m__UB_long ;
>> My_Class_A m__UB_float ;
>> My_Class_A m__UB_double ;
>> My_Class_A m__ULT ;
>> My_Class_A m__ULT_int ;
>> My_Class_A m__RE_OR_EALS_long ;
>> My_Class_A m__RE_OR_EALS_float ;
>> My_Class_A m__RE_OR_EALS_double ;
>> My_Class_A m__UAS ;
>> My_Class_A m__OT_ELS_double ;
>> My_Class_A m__IV ;
>> My_Class_A m__Izas ;
>>
>> My_Class_A m_XXX ; /// add one to cause first level problem
>> ****************************
>> My_Class_A m_YYY ; /// add both to cause second level problem
>> ****************************
>> } ;
>> //----------------------------------------------
>> //----------------------------------------------
>>
>> "Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
>> news:uC**************@TK2MSFTNGP11.phx.gbl...
>>> Hi Vince,
>>>
>>> However, you present a way I might be able to keep working. I could
>>> change my members to pointers, and if that allows it to compile,
>>> then I can keep working! So thanks again!
>>>
>>> [==P==]
>>>
>>> "Vince Yuan" <sh*******@citiz.net> wrote in message
>>> news:O2*************@tk2msftngp13.phx.gbl...
>>>> Hi Perteroid,
>>>> I changed
>>>> OAP_Branch m_Root ;
>>>> to
>>>> OAP_Branch^ m_Root ;
>>>>
>>>> Compiler accecpted your code.
>>>>
>>>> And another way is to change
>>>> ref class OAP_Branch
>>>> to
>>>> value class OAP_Branch
>>>>
>>>> Hope this helps.
>>>> --
>>>> Vince
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>

[Peter Oliphant]

PS - It might speed up the process if more people left validations. Here is
the bug link:

http://lab.msdn.microsoft.com/Produc...0-44bd02f398c6

Thanks!

[==P==]

"Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
news:%2****************@TK2MSFTNGP14.phx.gbl...

Good point. I was viewing it from a 'run' point of view. Now I'm thinking
as it compiles it keeps track of how it must do destruction, and if the
number of things it needs to keep track of to destroy gets too big, it
can't handle it. Although 124 seems like kind of a small number to me...
: )

I totally agree with you on the 'document or correct' point of view...

Yeah, I'd like to see the response from MFST too. This could be the cause
of a few things. I'm basing this on the fact that it was this same source
file that was generating my "IntelliSense Updating..."-takes-forever
problem...

[==P==]

"Willy Denoyette [MVP]" <wi*************@telenet.be> wrote in message
news:Ob*************@TK2MSFTNGP15.phx.gbl...

No, I don't think so. The problem is not a runtime issue, it's a compiler
issue. Or it's a compiler limitation or it's a compiler bug, if it's the
former (which I don't think it is), it should be documented, if it's the
latter it should (preferably) be corrected. Anyway, we'll have to wait to
see MSFT response to the filed bug report.

Willy.

"Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
news:en**************@TK2MSFTNGP14.phx.gbl...

So, I guess this means the real problem is that the new syntax has a
limit of 124 members any one ref class can be responsible for destroying
deterministically!

This is probably why pointers don't cause a problem: the responsibility
for destroying pointer type constructed instances is in the hands of the
GC in a non-deterministic way, or the programmer via manual means. This
is in contrast to the class itself being responsible for destruction of
its stack semantic members, and its this responsibility it seems to have
an upper limit of 124...

[==P==]

"Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
news:eq**************@TK2MSFTNGP14.phx.gbl...
Willy,

Cool! I never ever create a class without a destructor. But my
destructor is code-less, so I guess it's ok to remove it based on what
you said!!! Thanks!

[==P==]

"Willy Denoyette [MVP]" <wi*************@telenet.be> wrote in message
news:uI**************@TK2MSFTNGP14.phx.gbl...
>I don't thing it's due to the number of members, IMO the code
>parser/generator has problems with the destructor (Dispose pattern),
>remove the destructor and the problem goes away (tried with 240
>members).
>
> Willy.
>
>
>
>
>
> "Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
> news:%2****************@TK2MSFTNGP09.phx.gbl...
>>I have experimented with using more than one type of member to the
>>'offending' class. As such, I've reached this conclusion:
>>
>> You cannot have more than 124 (user-defined?) stack semantic members,
>> even of mixed types, at the same time in one class.
>>
>> I don't know if this applies only to 'ref' classes, or whether the
>> fact I'm using clr:/pure syntax is a factor. I have been able to
>> re-create the problem with deterministic 100% 'success' in both VS
>> C++.NET Express 2005 and VS C++.NET 2005 PRO.
>>
>> [==P==]
>>
>> "Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
>> news:u%****************@TK2MSFTNGP12.phx.gbl...
>>> This version is probably as close to as minimal a source file that
>>> can be that causes error c1026:
>>>
>>> //-----------------------------
>>> #pragma once
>>> //
>>> // NOTE: At bottom are two source lines for m_XXX, and m_YYY. if you
>>> comment them both
>>> // out this will compile. If you un-comment one you get first level
>>> error, un-comment
>>> // both you get a second level error (you'll see).
>>> //
>>> // WORKAROUND: Change enough stack semantic members to pointers.
>>> // [courtesy of Vince Yuan]
>>> //
>>>
>>> ref class My_Class_A
>>> {
>>> public:
>>> My_Class_A() {}
>>> ~My_Class_A() {}
>>> } ;
>>>
>>> ref class My_Class_B
>>> {
>>> public:
>>>
>>> My_Class_B() {}
>>> ~My_Class_B() {}
>>>
>>> My_Class_A m_Root ;
>>> My_Class_A m_Inunt ;
>>> My_Class_A m_0_Is ;
>>> My_Class_A m_1_Is ;
>>> My_Class_A m_2_Is ;
>>> My_Class_A m_L_NT ;
>>> My_Class_A m_L_NP ;
>>> My_Class_A m_L_AD ;
>>> My_Class_A m_L_O ;
>>> My_Class_A m_3_Is ;
>>> My_Class_A m_N_Is ;
>>> My_Class_A m_Ount ;
>>> My_Class_A m_0_Os ;
>>> My_Class_A m_1_Os ;
>>> My_Class_A m_2_Os ;
>>> My_Class_A m_3_Os ;
>>> My_Class_A m_N_Os ;
>>> My_Class_A m_Loc ;
>>> My_Class_A m_Ariic ;
>>> My_Class_A m_y ;
>>> My_Class_A m_pason ;
>>> My_Class_A m_stt ;
>>> My_Class_A m_veion ;
>>> My_Class_A m_utode ;
>>> My_Class_A m_puNode ;
>>> My_Class_A m_Ma ;
>>> My_Class_A m_Vaable ;
>>> My_Class_A m_Spial ;
>>> My_Class_A m_L_NND ;
>>> My_Class_A m_L_NR ;
>>> My_Class_A m_L_EU ;
>>> My_Class_A m_C_int ;
>>> My_Class_A m_C_long ;
>>> My_Class_A m_C_float ;
>>> My_Class_A m_C_double ;
>>> My_Class_A m_C_ZO_float ;
>>> My_Class_A m_C_ZO_double ;
>>> My_Class_A m_C_ZO_char ;
>>> My_Class_A m_C_ZO_string ;
>>> My_Class_A m_L_NT_EQU ;
>>> My_Class_A m_L_LFT ;
>>> My_Class_A m_L_RGHT ;
>>> My_Class_A m_L_NT_LEFT ;
>>> My_Class_A m_L_NT_RHT ;
>>> My_Class_A m_L_TUE ;
>>> My_Class_A m_L_FLSE ;
>>> My_Class_A m_L_IPIES ;
>>> My_Class_A m_L_NT_IIS ;
>>> My_Class_A m_L_IPED_BY ;
>>> My_Class_A m_L_NT_IMED_BY ;
>>> My_Class_A m_C_bool ;
>>> My_Class_A m_C_bool_TRUE ;
>>> My_Class_A m_C_bool_FALSE ;
>>> My_Class_A m_C_OE ;
>>> My_Class_A m_C_OE_int ;
>>> My_Class_A m_O_long ;
>>> My_Class_A m_O_float ;
>>> My_Class_A m_O_double ;
>>> My_Class_A m_O_char ;
>>> My_Class_A m_O_string ;
>>> My_Class_A m_O_uni ;
>>> My_Class_A m_C_OE_long ;
>>> My_Class_A m_C_OE_float ;
>>> My_Class_A m_C_OE_double ;
>>> My_Class_A m_C_OE_char ;
>>> My_Class_A m_C_OE_string ;
>>> My_Class_A m_O_bool ;
>>> My_Class_A m_O_int ;
>>> My_Class_A m_C_char ;
>>> My_Class_A m_C_string ;
>>> My_Class_A m_C_PI ;
>>> My_Class_A m_C_ZO ;
>>> My_Class_A m_C_ZO_int ;
>>> My_Class_A m_C_ZO_long ;
>>> My_Class_A m_Sp_DATE ;
>>> My_Class_A m_Sp_TIME ;
>>> My_Class_A m__DD ;
>>> My_Class_A m__DD_int ;
>>> My_Class_A m__DD_long ;
>>> My_Class_A m__DD_float ;
>>> My_Class_A m__ULT_float ;
>>> My_Class_A m__ES_TN_double ;
>>> My_Class_A m__ES_OR_ELS ;
>>> My_Class_A m__ES_OR_ELS_int ;
>>> My_Class_A m__ULT_long ;
>>> My_Class_A m__ES_OR_ELS_float ;
>>> My_Class_A m__ES_OR_ELS_double ;
>>> My_Class_A m__RE_TN ;
>>> My_Class_A m__RE_TN_int ;
>>> My_Class_A m__ULT_double ;
>>> My_Class_A m__ES_TN ;
>>> My_Class_A m__ES_TN_int ;
>>> My_Class_A m__ES_TN_long ;
>>> My_Class_A m__UB_int ;
>>> My_Class_A m__RE_TN_float ;
>>> My_Class_A m__UAS_int ;
>>> My_Class_A m__UAS_long ;
>>> My_Class_A m__UAS_float ;
>>> My_Class_A m__ES_TN_float ;
>>> My_Class_A m__RE_TN_long ;
>>> My_Class_A m__UAS_double ;
>>> My_Class_A m__OT_ELS ;
>>> My_Class_A m__OT_ELS_int ;
>>> My_Class_A m__OT_ELS_long ;
>>> My_Class_A m__OT_ELS_float ;
>>> My_Class_A m__RE_TN_double ;
>>> My_Class_A m__RE_OR_EALS ;
>>> My_Class_A m__RE_OR_EALS_int ;
>>> My_Class_A m__ES_OR_ELS_long ;
>>> My_Class_A m__DD_double ;
>>> My_Class_A m__DD_string ;
>>> My_Class_A m__UB ;
>>> My_Class_A m__UB_long ;
>>> My_Class_A m__UB_float ;
>>> My_Class_A m__UB_double ;
>>> My_Class_A m__ULT ;
>>> My_Class_A m__ULT_int ;
>>> My_Class_A m__RE_OR_EALS_long ;
>>> My_Class_A m__RE_OR_EALS_float ;
>>> My_Class_A m__RE_OR_EALS_double ;
>>> My_Class_A m__UAS ;
>>> My_Class_A m__OT_ELS_double ;
>>> My_Class_A m__IV ;
>>> My_Class_A m__Izas ;
>>>
>>> My_Class_A m_XXX ; /// add one to cause first level problem
>>> ****************************
>>> My_Class_A m_YYY ; /// add both to cause second level problem
>>> ****************************
>>> } ;
>>> //----------------------------------------------
>>> //----------------------------------------------
>>>
>>> "Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
>>> news:uC**************@TK2MSFTNGP11.phx.gbl...
>>>> Hi Vince,
>>>>
>>>> However, you present a way I might be able to keep working. I could
>>>> change my members to pointers, and if that allows it to compile,
>>>> then I can keep working! So thanks again!
>>>>
>>>> [==P==]
>>>>
>>>> "Vince Yuan" <sh*******@citiz.net> wrote in message
>>>> news:O2*************@tk2msftngp13.phx.gbl...
>>>>> Hi Perteroid,
>>>>> I changed
>>>>> OAP_Branch m_Root ;
>>>>> to
>>>>> OAP_Branch^ m_Root ;
>>>>>
>>>>> Compiler accecpted your code.
>>>>>
>>>>> And another way is to change
>>>>> ref class OAP_Branch
>>>>> to
>>>>> value class OAP_Branch
>>>>>
>>>>> Hope this helps.
>>>>> --
>>>>> Vince
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>

[Peter Oliphant]

>>That's a pretty small repro alright! You might want to contact PSS

I called PSS, and told them I had a bug to report. But they said I had to
send them the problem via U.S. Mail (i.e., stamp, envelope, etc.). Why would
one of the biggest companies involved with electronic communication ask me
to send bug reports via U.S. Mail (I will point out they never mentioned the
on-line bug report system on the phone)?

Plus, now I found a bug in the bug report system...lol! I found this one
trying to update my bug report from a different computer. Try leaving a 'New
Comment' at the bottom of a bug report page. Once you type in a comment and
hit Submit it will say the service is temporarily unavailable. It has been
temporarily unavailable now for weeks. I reported this as a bug in the bug
report system, but no reply yet.

How does one get MS's attention about something that is a fundamental
problem, such as the bug I found?

[==P==]

"Carl Daniel [VC++ MVP]" <cp*****************************@mvps.org.nospam >
wrote in message news:eC**************@TK2MSFTNGP14.phx.gbl...

Peteroid wrote:

Yes, it is entirely in-line. But I've reduced it down to a pretty
small source file that independently causes problem attached (see
instructions at top of source file in commented NOTE)...

That's a pretty small repro alright! You might want to contact PSS, or at
the very least open a bug report at
http://lab.msdn.microsoft.com/productfeedback

-cd

[David Lowndes]

>I called PSS, and told them I had a bug to report. But they said I had to

send them the problem via U.S. Mail
They weren't pulling your leg were they? :)

On the couple of occasions where I've needed to phone MS support
(albeit in from the UK), they've usually corresponded entirely via
email after the initial contact.
Plus, now I found a bug in the bug report system...lol! I found this one
trying to update my bug report from a different computer. Try leaving a 'New
Comment' at the bottom of a bug report page. Once you type in a comment and
hit Submit it will say the service is temporarily unavailable. It has been
temporarily unavailable now for weeks. I reported this as a bug in the bug
report system, but no reply yet.

It is something that relies on a web browser - so I don't expect too
much consistency. On my home machine I couldn't ever get access to my
Hotmail account - kept getting some passport error. Never had any
passport problems with other MS sites, and I could always access my
Hotmail account from any other computer!

Dave