|
what compiler are you using (VC 6, VC7)?
|
|
|
|
|
|
then I need to see full cpp file compilation of which gives an error
|
|
|
|
|
I have an array of structs and the size is [1] so there are 2 places in the array.
Is there anyway that I can make an array with the size of [0] so there will only be 1 instance in it?
thanks,
sj
|
|
|
|
|
Yes when you create an array of size [1] there is only one place in the array, Array[0].
[EDIT]
In a array of size 1 you may not use Array[1].
[/EDIT]
John
|
|
|
|
|
OK, thanks
sj
|
|
|
|
|
The same is true in the general case an array of size N you can index only N elements 0 .. N-1.
John
|
|
|
|
|
|
If you want an array with size 1, do:
struct foo
{
int x[1];
}; An array of size 1 is legal, although not entirely useful.
--Mike--
"So where does that leave us? Well, it leaves us right back where we started, only more confused than before." -- Matt Gullett
Ericahist | Homepage | RightClick-Encrypt | 1ClickPicGrabber
|
|
|
|
|
Michael Dunn wrote:
An array of size 1 is legal, although not entirely useful.
I was thinking the same thing. A int data type would hold the same data that an array of size 1 would hold. Or even a pointer to an int would do the same thing. I am curios to know, why would someone need an array of size 1?
// Afterall, I realized that even my comment lines have bugs
When one cannot invent, one must at least improve (in bed).-My latest fortune cookie
|
|
|
|
|
Toni78 wrote:
I am curios to know, why would someone need an array of size 1?
Some structures are designed to be a header for a larger data structure. Take this for example
typedef struct
{
UINT nDataSize;
BYTE bData[1];
} MyPacket; Since the data can be of any length (given by nDataSize), we can't specify the size of the array. Therefore, when allocating memory, we just go
MyPacket *packet = (MyPacket*)malloc(nDataLength+sizeof(UINT));
packet->nDataSize = nDataLength; We now have a block of data where the first UINT is the nDataSize field, and the rest is the bData field. We can access it as bData[0] through bData[nDataSize-1] , even though the definition is only of size 1, because we have allocated memory that follows the small structure.
Hope this explains it a bit more
Ryan
Being little and getting pushed around by big guys all my life I guess I compensate by pushing electrons and holes around. What a bully I am, but I do enjoy making subatomic particles hop at my bidding - Roger Wright (2nd April 2003, The Lounge)
Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late - John Nichol "Point Of Impact"
|
|
|
|
|
Ryan Binns wrote:
Hope this explains it a bit more
Yes it does, thank you.
// Afterall, I realized that even my comment lines have bugs
When one cannot invent, one must at least improve (in bed).-My latest fortune cookie
|
|
|
|
|
Hello,
This maybe a dumb question.. Is there an easy way to pull the app version?
Whoever said nothing's impossible never tried slamming a revolving door!
|
|
|
|
|
I assume you are looking for Version info from resource file.
The following is a huck we come up with:
VS_FIXEDFILEINFO* GetVerInfo()
{
HRSRC hrc = ::FindResource(0, MAKEINTRESOURCE(VS_VERSION_INFO), RT_VERSION);
if(hrc)
{
HGLOBAL hResData = ::LoadResource(0, hrc);
if(!hResData)
return 0;
LPVOID pRes = LockResource(hResData);
if(!pRes)
return 0;
UINT unSize = sizeof(VS_FIXEDFILEINFO);
TCHAR szSubBlock[] = "\\";
VOID* pData = 0;
if(::VerQueryValue(pRes, szSubBlock,
&pData, &unSize))
return reinterpret_cast<VS_FIXEDFILEINFO*>(pData);
}
return 0;
}
|
|
|
|
|
Thanks.. I'll give that a shot..
Whoever said nothing's impossible never tried slamming a revolving door!
|
|
|
|
|
Thanks, worked like a champ..
Rob
Whoever said nothing's impossible never tried slamming a revolving door!
|
|
|
|
|
I am using try{}catch(...) handlers extensively to handle all types of exceptions that are thrown.
In particular, I am catching hardware exceptions such as access violations and so on.
How can I find out exactly what hardware exception occurred within the catch(...) handler?
Do I have to use SEH to do this?
|
|
|
|
|
Does std::exception::what() help you? Or do you need to differtiate the exception objects at runtime and react on their type? Then typeid may help you (look for RTTI in MSDN)to determine the type of the exception-object you caught.
But maybe you simply can replace the catch(...) with a list of catches for the exception classes you need.
My opinions may have changed, but not the fact that I am right.
|
|
|
|
|
|
DaGlynn wrote:
Do I have to use SEH to do this?
according to the docs, yes.
You can use GetExceptionInformation() to do that - but this can be called only insode the __except() filter
"Der Geist des Kriegers ist erwacht / Ich hab die Macht" StS
sighist | Agile Programming | doxygen
|
|
|
|
|
Within a class I need to have an object in the heap. Within the constructor I make a new object and I can access the data members. When I try to access them in different member functions however I get memory access errors. I call the delete in the destructor, and not before. I'm not sure what is wrong.
|
|
|
|
|
Could you post your code?
|
|
|
|
|
|
Here's your problem:
In CParticleEngine::init(int nParticles) you have the following line:
CParticle *m_pParticles = new CParticle[nParticles];
Change it to m_pParticles = new CParticle[nParticles]; and your code will work. By declaring the m_pParticles variable again in the init() function, you have made a new variable that only has scope in the init() function, and happens to be named the same as your member variable m_pParticles. Thus the member variable never gets assigned, and you (rightfully) get memory errors when you later try and delete it.
--Dean
|
|
|
|
|
Excellent. Thanks a bunch!
|
|
|
|