stack overflow problem
in [MFC]
|
Prev: PropertyPage Buttons
Next: StringCchCopy question
From: Tony C. on 24 Apr 2010 17:24 On Sat, 24 Apr 2010 16:37:56 -0400, Hector Santos <sant9442(a)nospam.gmail.com> wrote: >You can try to dynamically allocate it in the constructor and >deallocate it in the destructor: > >class cAspectGrid : public CDialog >{ > .... >public: > CGridBox *pAspGrid; // make this pointer > .... >} > >// CONSTRUCTOR >cAspectGrid::cAspectGrid >{ > pAspGrid = new CGridBox[17*17]; >} > >// DESTRUCTOR >cAspectGrid::~cAspectGrid >{ > delete pAspGrid; >} > >Now, if you want to get a ROW and COLUMN view of the 17*17, use this >"GET" function: > >CGridBox * cAspectGrid::GridBox(int row, int col) >{ > // assuming base 0 for row and col > // add maybe ROW and COL checking > return pAspGrid[row*17+col]; >} > > >Now you can use it like so: > > GridBox(2,5)->Whatever I'll play with that Hector,,obviously I need a memory allocation tutorial or something. Thanks
From: Joseph M. Newcomer on 24 Apr 2010 18:26 Firs, you need to do the arithmetic. You have 17x17 = 289 objects. How big is each object? Then, you are probably declaring this on the stack, so you need to know how big your stack space requirement is, and how it compares to your stack. Given the horrible number of commas in the declaration lists, I'm not even going to bother counting bytes (never declare more than one variable in a declaration to achieve maximum readability: int x, y, z; // BAD int x; // GOOD int y; int x; Then you are declaring complex objects (COleDateTime) whose size you do not know at the moment, so you need to figure out how big they are. If the total is > 1MB then you are guaranteed stack overflow if you declare one of these on the stack. There are a couple solutions for this: 1. Don't declare big arrays of big objects on the stack 2. If you need big arrays of big objects, put them on the heap 2 follows naturally from 1. This is one of the few places you would ever need a 'new' and actually if you used std::vector you would not have to do anything special, because std::vector actually does allocate on the heap but frees everything up when you leave scope, so you don't have to do anything special to avoid storage leaks. By trying to combine the old-fashioned C declaration style for an array with a C++ program, you have failed to take advantage of the C++ language. So there is another rule 0. Stop thinking that you are programming in C, and learn to program in C++ All your problems stem from a desire to program using 1975 syntax in a 1965 language. This is 2010, and you should use 2010 syntax in a 2010 language. The way I would fix this is to follow rule 0, and record it to use modern programming technology. joe On Sat, 24 Apr 2010 14:33:14 -0500, Tony C. <me(a)here.com> wrote: > > > Hi, > > I have traced my problem to the following line of code which seems >to be causing a stack overflow problem: (see below) > >I'm declaring a multidimenstional array of CGridbox Objcts > >A CGridbox consists of 2 arrays of CApect Objects.. > >The code works fine when line is commented out. and breaks when put >back in... > >It appears that the object has problems upon creation.... > >the header file for the delcaration looks like: > >==Any ideas what I'm doing wrong??? > >Thanks very much in advance.... > >Tony C. > >================================================ >//CLASS ASPECTGRID = A DIALOG = "ASPECTGRID.H" >#pragma once >#include "CalcedChart.h" >#include "GridBox.h" >#include "Aspects.h" > > >// cAspectGrid dialog > > > > >class cAspectGrid : public CDialog >{ > DECLARE_DYNAMIC(cAspectGrid) > > >public: > cAspectGrid(CWnd* pParent = NULL); // standard constructor > virtual ~cAspectGrid(); > > //*********************************************************** > CGridBox AspGrid[17][17]; //<<<==============PROBLEM LINE ** > //*********************************************************** > >================================================== >//CLASS GRIDBOX >#pragma once >#include "Aspect.h" > >// CGridBox > >class CGridBox >{ > > >public: > CGridBox(); > virtual ~CGridBox(); > //Public colDeclAsp As New CAspectCollection > CAspect arrRegAsp[4]; > CAspect arrDecAsp[4]; > >protected: > >}; >================================================== >//CLASS ASPECT >#pragma once > > >// CAspect > >class CAspect >{ > > >public: > CAspect(); > virtual ~CAspect(); > CPlanet P1 , P2 ; > double dbDegr1, dbDiff; > CString strAspect1; > CStringW chGlyph1; > COleDateTime dtExact, dtCalc, dtStart, dtEnd; > int intSubType; // 1 = raw2raw 2 = ra2ra 3 = raw2ra 4= ra2raw > int intAspNo; // conj thru opp + parallel and contraparallel > CAspect& CAspect::operator=(const CAspect &A); > > > > > >protected: > >}; > > >================================================== Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Hector Santos on 24 Apr 2010 22:23 Tony C. wrote: >> CGridBox * cAspectGrid::GridBox(int row, int col) >> { >> // assuming base 0 for row and col >> // add maybe ROW and COL checking >> return pAspGrid[row*17+col]; >> } Small note: That should return the address: return &pAspGrid[row*17+col]; >> Now you can use it like so: >> >> GridBox(2,5)->Whatever > > > I'll play with that Hector,,obviously I need a > memory allocation tutorial or something. > > Thanks Yes, it is a good idea to learn about memory management, the basics of how its done, and to know when you need to use it - correctly. It will serve no justice to you to try to tell you all about it in one message. The internet is very rich with this information. Google research terms like: C++ Dynamic Memory Methods initializing dynamic class instance Memory Pools (more advanced) etc. There are many hits, there is this one: http://www.cplusplus.com/doc/tutorial/dynamic/ and a good one is one by Bruce Eckel, maybe getting his book "Thinking in C++" will be a good idea: http://smart2help.com/e-books/ticpp-2nd-ed-vol-one/Chapter13.html -- HLS
From: Tony C. on 24 Apr 2010 22:43 Thanks Very Much for the Info..! Tony C.
From: Woody on 25 Apr 2010 04:23
In addition to the other suggestions, sometimes stack oflo is caused by not allocating enough stack for legitimate code (as opposed to infinite recursion). You can check this quickly by increasing the stack for your app in Linker/System/Reserve. The default in XP32 is 1 MB, so try 10 MB and see if the symptoms go away. If so, then do the recommended arithmetic, so you know how much memory you need. |