Re: parser stack overflow, program too complex eroor C1026

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

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" <poliphant@xxxxxxxxxxxxxxxx> wrote in message
news:enGZ5naBGHA.2668@xxxxxxxxxxxxxxxxxxxxxxx
> 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" <poliphant@xxxxxxxxxxxxxxxx> wrote in message
> news:eqNDmfaBGHA.3984@xxxxxxxxxxxxxxxxxxxxxxx
>> 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]" <willy.denoyette@xxxxxxxxxx> wrote in message
>> news:uINWcWaBGHA.3984@xxxxxxxxxxxxxxxxxxxxxxx
>>>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" <poliphant@xxxxxxxxxxxxxxxx> wrote in message
>>> news:%23YRLnCZBGHA.3896@xxxxxxxxxxxxxxxxxxxxxxx
>>>>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" <poliphant@xxxxxxxxxxxxxxxx> wrote in message
>>>> news:u%23IfYhYBGHA.3408@xxxxxxxxxxxxxxxxxxxxxxx
>>>>> 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" <poliphant@xxxxxxxxxxxxxxxx> wrote in message
>>>>> news:uC3jz0XBGHA.3536@xxxxxxxxxxxxxxxxxxxxxxx
>>>>>> 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" <shinebean@xxxxxxxxx> wrote in message
>>>>>> news:O2f053UBGHA.984@xxxxxxxxxxxxxxxxxxxxxxx
>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>


.

Relevant Pages

  • Re: Exception unwinding base destructor called - why?
    ... > as a kind of compiler independent, ... > unwinding mechanism is calling the destructor for the base class. ... Before the body of the Derived constructor can be invoked, ... as well as all members of Dervied too...). ...
    (comp.lang.cpp)
  • Re: parser stack overflow, program too complex eroor C1026
    ... of 124 members any one ref class can be responsible for destroying ... semantic members, and its this responsibility it seems to have an upper ... I never ever create a class without a destructor. ...
    (microsoft.public.dotnet.languages.vc)
  • Re: Interview: Dale Fuller and Blake Stone on Borland directions
    ... Will DeWitt Jr. ... And I suppose the compiler should know that the function returns a new ... Wouldn't this be handled by the initial destructor ... You must explicitly call all destructors of contained members. ...
    (borland.public.delphi.non-technical)
  • Re: parser stack overflow, program too complex eroor C1026
    ... But that doesn't mean there is no bug in the compiler. ... I never ever create a class without a destructor. ... >>remove the destructor and the problem goes away (tried with 240 members). ... >>> even of mixed types, at the same time in one class. ...
    (microsoft.public.dotnet.languages.vc)
  • Re: File conversion
    ... the appropriate changes to both record layouts, ... You would then have to do a detailed comparison of what fields the compiler found to correspond. ... Once you have done that, and proven that your COPY members are defined correctly, you're home free! ... future changes to the COPY members could blow you right out of the water.... ...
    (comp.lang.cobol)