C / C++ / MFC

Re: Path to system directories

6-Sep-04 20:14

GetWindowsDirectory and GetSystemDirectory do the job, surprisingly enough Poke tongue | ;-P

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo

David Crow7-Sep-04 3:00

David Crow

7-Sep-04 3:00

Imtiaz Murtaza wrote:
Can you tell me that how can i get the path of windows directory and windows system directory.

You can also check out SHGetFolderPath(CSIDL_WINDOWS) and SHGetFolderPath(CSIDL_SYSTEM).

Imtiaz Murtaza wrote:
What is the meaning of %system% ??

It depends on the context in which it is used. In the case of environment variables, the '%' means it's an expandable value.

"When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen

C++ question.

WREY6-Sep-04 19:53

6-Sep-04 19:53

I'll appreciate any insight, suggestion, or answer to the following problem. Thanks.

I have these two classes, one obtaining data from the other.

class First
{
public:
... // etc.
struct Node
{
short nodeCnt;
... // various other types
} *(*pNode)[7];
...
Second* pSec;
};

==============================

class Second
{
public:
... // etc.
First::Node* (*pNode)[7];
void TransferData(First* pFirst);
...
};

==============================

In the ".cpp" file for 'First', I have a 'DoSomething()' function.

void First::DoSomething()
{
...
pSec->TransferData(this);
...
}

==============================

In the ".cpp" file for 'Second', here is the definition of 'TransferData'.

void Second::TransferData(First* pFirst)
{
...
First::Node* (*pNd)[7] = pFirst->pNode;
... // start transferring data from First::Node to members of class Second.
}

Later in another function for class 'Second', the program crashes.

===============================

void Second::AnotherFunction()
{
short i, nbrOfNodes;
for(i=0; i<limit; ++i)
{
nbrOfNodes = (*(*pNd+i))->nodeCnt; // *** program crashes here !!!
...
}
}

===============================

I can't understand why the program crashes at the place it does, because I have been able to successfully access data from the 'Node' array before, and it didn't crash.

AAMOF, one of those earlier times was in the function 'TransferData' itself, when I had used the same statement:

nbrOfNodes = (*(*pNd+i))->nodeCnt;

inside a different 'for' statement, and it didn't crash.

No, I didn't delete any pointers, nor did I overshot the array boundary, or anything like that. The program crashed the very first time through the loop.

William

Fortes in fide et opere!

Joaquín M López Muñoz6-Sep-04 20:08

6-Sep-04 20:08

struct Node
{
short nodeCnt;
... // various other types
} *(*pNode)[7];

This declares a pointer to an array of pointers to Node objects. How are you allocating memory for this data structure? I'd bet the problem lies there. Could you post the relevant code?

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo

WREY7-Sep-04 3:58

7-Sep-04 3:58

Thanks for replying. I appreciate it.

I can understand your concern about how allocation of memory was accomplished for the 'Node' structure, and was one of the many things I investigated myself. (I would be flabbergasted if it turns out to be that, and would definitely be something new for me.) Here it is:

pNode = (Node*(*)[7])calloc(7, sizeof(Node*));

The allocation of memory for the structure is done in 'class First' prior to creating the array.
========================================

After the data had been long created and subsequently transferred from one class to the other, I was able to successfully access the data in the class that received it, and work with it. But somewhere down the line when this other function (in the same class which received the data) was activated, that's when the crash occurred.

The receiving class obtained data from the array by way of the pointer to the array.

First::Node* (*pNd)[7] = pFirst->pNode;

"First::Node* (*pNd)[7]" is declared in the receiving class.
=========================================

What's bewildering is that earlier I was able to work with data (in the class which received it), but then afterwards the program crashed. (If memory allocation is the reason, I would be totally astounded; totally.)

Thanks for any assistance. I appreciate it.

Big Grin | :-D

William

Fortes in fide et opere!

Joaquín M López Muñoz7-Sep-04 4:13

7-Sep-04 4:13

Well, what you post is so fragmentary that I can only guess... The two member functions Second::TransferData and Second::AnotherFunction refer to a variable named pNd, but in the former member function that variable is local. Are you sure you're referring to the same thing in Second::AnotherFunction?

PS. I'm also curious as to how you've come up with such a weird design. Pointers to arrays of pointers being shared by different classes... OMG | :OMG:

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo

WREY7-Sep-04 4:47

7-Sep-04 4:47

The sample might be fragmentary, but it has continuity. I'm sorry if you lost out on it.

With regards to one variable being local to one class, and seemingly used in another, again I believed you missed seeing where the pointer from the first class was assigned to a pointer of similar declaration in the second class, and the array was accessed (in the second class) by the pointer declared in the second class. There is no contention nor misrepresentation of pointers occurring. If I said I was able to access the data while working in the second class, that ought to have cleared up any notion of pointer misrepresentation.

About the design being weird, do you have the patent to "Only These Designs Are Acceptable" type designs?

William

Fortes in fide et opere!

Joaquín M López Muñoz7-Sep-04 5:13

7-Sep-04 5:13

There is no contention nor misrepresentation of pointers occurring. If I said I was able to access the data while working in the second class, that ought to have cleared up any notion of pointer misrepresention.

Most likely, some misrepresentation is going on, as the program crashes after all. I mean, if the program was correct it wouldn't fail. So questioning every assumption is IMHO the way to find the bug. Do not take any naive question I might make in a defensive manner. A simple "no, it's not that" does suffice.

About the design being weird, do you have the patent to "Only These Designs Are Acceptable" type designs?

I haven't said the design is unacceptable, I've said it's weird. Surely you'll have a valid reason for having chosen this design --that's why I asked.

And then again, I'm not doing paid support or anything, I just hang round here at CP trying to help some other folks. If you feel I'm not your kind of helper, I'll be glad to move on to some other question in this forum.

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo

cmk7-Sep-04 2:23

cmk

7-Sep-04 2:23

>> nbrOfNodes = (*(*pNd+i))->nodeCnt;

pNd is a pointer to an array, *pNd+i will point to 'next array' i'm guessing you actually want 'next node in array pNd' in which case try :

nbrOfNodes = (*pNd)[i]->nodeCnt;

(i could be wrong, the code you give is fairly incomplete ... and it's 5:20am here - time for bed)

...cmk

Save the whales - collect the whole set

WREY7-Sep-04 4:20

7-Sep-04 4:20

My error! My error! My typographical error! I meant the following:

nbrOfNodes = (*(*(pNd+i)))->nodeCnt;

It's one of those things I constantly have to deal with, "the omitting of a pair of parentheses". You have very sharp eyes!! Thanks.

=================================

However, since the program has the correct number of parentheses (and it was my error the way I showed the expression), the original problem remains the same.

Big Grin | :-D

William

Fortes in fide et opere!

Joaquín M López Muñoz7-Sep-04 5:47

7-Sep-04 5:47

I'd say that

nbrOfNodes = (*(*(pNd+i)))->nodeCnt;

gets out of bounds, and that the correct expression is

nbrOfNodes = (*(*pNd+i))->nodeCnt;

For instance, the following complete program works OK (memory leaks aside)

#include <stdlib.h>
 
struct Node
{
  short nodeCnt;
} *(*pNode)[7];
 
int main()
{
  pNode = (Node*(*)[7])calloc(7, sizeof(Node*));
 
  for(int i=0;i<7;++i)
  {
    (*(*pNode+i))=0;
  }
  
  return 0;
}

while the following crashes

#include <stdlib.h>
 
struct Node
{
  short nodeCnt;
} *(*pNode)[7];
 
int main()
{
  pNode = (Node*(*)[7])calloc(7, sizeof(Node*));
 
  for(int i=0;i<7;++i)
  {
    (*(*(pNode+i)))=0;
  }
 
  return 0;
}

Could your problem be there?

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo

Found solution!!

WREY7-Sep-04 6:04

7-Sep-04 6:04

Found a solution!

Admittedly, it was my own fault! (Tunnel vision struck again. It's amazing what fresh air and a half hour break will do in clearing one's mind.)

I hate myself when I make these VERY STUPID MISTAKES!! I HATE IT!! I HATE IT!! I HATE IT!!

If I can only remember to assign NULL to a pointer after I have deleted it, I could avoid a lot of other problems.

D'Oh! | :doh:

William

Fortes in fide et opere!

WREY7-Sep-04 8:42

7-Sep-04 8:42

To clear up a lot of the confusion about when memory ought to be allocated and deallocated, I moved the allocation statement to the 'ctor' of the first class, and likewise deallocated the memory in its 'dtor'.

Astonishingly, when I run the program, I get a message about "Damaged block" just before the program terminates.

The program still runs fine, but it's never settling to your mind when you receive a message such as that.

I've tried using, "free(pNode);" to deallocate the memory, but when that didn't change a thing, I tried, "delete pNode;" and when that didn't make it better, I tried using a "for" statement in which I individually deleted the memory by using, "delete[] (*pNode)[7];", and that's where I am, because the message is still occurring.

Might you have any idea what would set matters right?

Thanks.

Smile | :)

William

Fortes in fide et opere!