C / C++ / MFC

jblau31-Dec-05 21:23

jblau

31-Dec-05 21:23

wow, I am surprised at how many people responded, thanks everyone!

Here is some more information which might allow you guys to set me straight.

I am using Visual Studio.net 2003
The type of project that I opened is a "Windows Form Application (.Net)"
(so I don't know if that means that I am using "Normal" or "Managed" C++ ?)

My code is something like this:

void LoadLists()
{
Hashtable *hashSelectedItems = new Hashtable;

......(code working with the hashtable)

delete hashSelectedItems;
hashSelectedItems = NULL;
}

When I try to build the project, I get this error message: error C3841: illegal delete expression: managed type 'System::Collections::Hashtable' does not have a destructor defined

I'm thinking that perhaps it is, as one of you mentioned, being automatically managed, but I'm not certain.
It was my impression that if I wanted to use a Managed object I would specifiy so in the declaration, for example, in declaring an array, if I wanted it to be a managed array I would declare it like so: int c __gc[] = new int __gc[12]; but if I didn't want it Managed, I would leave out the __gc part.

************So given all of this, what do I need to know about declaring Hashtables without leaving any memory leaks?
Thanks,
Jody Blau

John R. Shaw31-Dec-05 22:22

John R. Shaw

31-Dec-05 22:22

I do not work with managed any thing, but I can tell you where you made a mistake. Do not allocate an object and delete an object in the same function, unless you have to. Instead you should just declare it as a stack object and let it clean up after its self.

void LoadLists()
{
    Hashtable hashSelectedItems;
    ......(code working with the hashtable)
}

The above code does not require a delete, becuase no new was called. The 'hashSelectedItems' variable is on the stack and will clean up after its self when the function returns.

INTP
Every thing is relative...

Gary R. Wheeler1-Jan-06 1:51

Gary R. Wheeler

1-Jan-06 1:51

John R. Shaw wrote:
Do not allocate an object and delete an object in the same function, unless you have to

Why? That's a perfectly normal thing to do, especially when the object in question has some runtime-determined characteristic (e.g. a non-trivial constructor). It's appropriate if you don't need the object for the entire life of the function. Also, if the object is large, you tend to get better working set behavior if you allocate it from the heap rather than the stack.

Software Zen: delete this;

Fold With Us![^]

John R. Shaw1-Jan-06 9:02

John R. Shaw

1-Jan-06 9:02

Gary R. Wheeler wrote:
Why?

It is like doing this:
char* buffer = new char[32];
when you should be doing this:
char buffer[32];

The allocation in this case is not a normal thing to do.

Another example:

class MyClass
{
   int n1,n2;
public:
   // member operations
   ......
};
// function using class
void MyFunc1()
{
   // this makes no since (sizeof(MyClass) is only 8 bytes)
   MyClass* mc = new MyClass;
   ......
   delete mc;
}
// function using class
void MyFunc2()
{
   // this makes more since
   MyClass mc;
   ......
}

Gary R. Wheeler wrote:
It's appropriate if you don't need the object for the entire life of the function.

Insted of allocating it, you can use scoping. The pratice of using scoping to limit an objects life time is common and is used in the MFC library its self.

void MyFunc()
{
   ......
   {
      MyClass mc;
      ......
   } // class is destoyed automatically here
   ......
}

When you allocate unnecessarily, you introduce one more factor that can go wrong.

INTP
Every thing is relative...

Prakash Nadar1-Jan-06 4:25

1-Jan-06 4:25

check http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemcollectionshashtableclasstopic.asp[^] how the hashtable is used.

-Prakash

Re: Hashtables--One More Follow Up

Michael Dunn1-Jan-06 8:07

Michael Dunn

1-Jan-06 8:07

jblau wrote:
illegal delete expression: managed type 'System::Collections::Hashtable' does not have a destructor defined

OK, that shows that you're creating a managed object. Don't delete it, the CLR garbage collector will take care of that for you. The reason you don't need __gc in the declaration is the compiler infers it from the context - Hashtable is a managed object so __gc is the only possibility.
Yes, this is confusing and it's the main reason why the MC++ syntax was replaced with C++/CLI in VC8.

--Mike--
Visual C++ MVP Cool | :cool:

LINKS~! Ericahist | PimpFish | CP SearchBar v3.0 | C++ Forum FAQ
"That probably would've sounded more commanding if I wasn't wearing my yummy sushi pajamas."
-- Buffy

jblau1-Jan-06 9:49

jblau

1-Jan-06 9:49

Thanks for all of the helpful information.

As I understand it now, the way my project is setup, the hashtable is a managed object, so I can't delete it mannualy, (as I get errors when I try).

So my follow up question is this: If I store an object that was declared with a NEW, and store it in the hashtable, do I need to go back through the hashtable and delete those objects, or does the managed code do that as well?

Example:
MyObject *tempObject = new MyObject;
Hashtable *hashObjects = new Hashtable;

hashObjects->Add(key, tempObject);

So if I store several tempObjects in my hashtable, do I need to traverse through the hashtable and DELETE the tempObjects, or does the garbage collector handle this as well as the hashtable itself?

If I do need to delete them, will a call to hashObjects->clear(); delete the objects?

Thanks,

Jody Blau

-- modified at 15:53 Sunday 1st January, 2006

Re: Hashtables--One More Follow Up

Prakash Nadar1-Jan-06 17:44

CButton displayes dark edge after first click

1-Jan-06 17:44

Try posting this as a new question in the forum so that others can also look at it.

-Prakash

spiritofklanawa31-Dec-05 14:23

spiritofklanawa

31-Dec-05 14:23

I create a button at runtime using CButton.Create() function. The button looks fine until it is clicked the first time. From then on the black rectangle around the button becomes slightly wider and does not go away with releasing the button.

It's cosmetic problem only, subtle but annoying nevertheless.

I suspect it's something to do with window-style and extended-window-style but I had no success so far.

Thanks in advance for your suggestions. Sigh | :sigh:

spiritofklanawa

Prakash Nadar31-Dec-05 16:55

31-Dec-05 16:55

Could it be focus rectangle drawn to the Button, Did you try taking the focus off the button, like pressing the Tab button.

-Prakash

dipuks31-Dec-05 16:58

dipuks

31-Dec-05 16:58

If you are trying to use a push button, then make sure you put style as BS_PUSHBUTTON.

You can also try, SetState(FALSE);, which will remove any highlighting

Michael Dunn31-Dec-05 19:06

Michael Dunn

31-Dec-05 19:06

The extra-dark border marks the default button. If more than one button has the BS_DEFPUSHBUTTON style, that will muck up the dialog manager and buttons will be drawn incorrectly.

--Mike--
Visual C++ MVP Cool | :cool:

LINKS~! Ericahist | PimpFish | CP SearchBar v3.0 | C++ Forum FAQ
Laugh it up, fuzzball.

How to add new thread to CDialog

spiritofklanawa10-Jan-06 6:29

spiritofklanawa

10-Jan-06 6:29

that was it ! I just added a line of code in the BN_CLICKED message handler to remove the "BS_DEFPUSHBUTTON" style. The trouble was that multiple buttons showed this dark outline which looked goofy.

Thanks

dipuks31-Dec-05 11:09

dipuks

31-Dec-05 11:09

I have a MFC MDI App, to which i have added new CDialog. Now when i pop-up the new dialog from MDI and use the controls in it, it will be using the main thread of the MDI App.
I wanted to make this new dialog run on a new thread, so that all controls in it will run on new thread and the MDI will have its main thread always free from dialog. Can anyone tell me how to do this?
Thanks

Re: How to add new thread to CDialog

Prakash Nadar31-Dec-05 16:52