If have a stupid question (ie I couldn''t find an answer for it ): If I allocate new instance of a class, will this instance get destroyed automatically at program termination ? Or do I have to explicitly destroy it using delete. Thx in advance - Sleepwalker

Hi there,

if you explicitly new a class like this:

class CSomeClass {};

CSomeClass* someClass = new CSomeClass();

then you have to delete it explicitly like this;

delete someClass; someClass = NULL;

Setting the pointer to NULL isn''t neccesary but it is good programming practice;

If you do not new a class (not doing it of the heap but statically) like this:

CSomeClass someClass = CSomeClass();

Then the class will be destroyed automatically when it goes out of scope. So no need to worry there.

Jaap Suter



Mmmm, I''ll have to think of one.

s9801758 made a good point there. It''s always safe to assign a pointer NULL after everytime it is deleted. If it is not, it''s called a stray pointer and can be quite the kick in the balls to your program! However, this is the exception to the assing-the-pointer-to-null rule, so... um... yah

s9801758- when you assigned the instance someClass to CSomeClass, did you assign someClass to a new CSomeClass constructor? I''m asking because classes don''t have the parenthesis at the ends- but constructors do (they usually have the same name). This is kind of confusing for me, so can you or anyone else clear that up?

> s9801758

Mmmm, I suppose i do have a shitty nick. It''s my student number and easy to remember . Why not use my own name? I don''t know.

> s9801758- when you assigned the instance someClass to
> CSomeClass, did you assign someClass to a new CSomeClass
> constructor? I''m asking because classes don''t have the
> parenthesis at the ends- but constructors do (they
> usually have the same name). This is kind of confusing
> for me, so can you or anyone else clear that up?

I''m not sure what you mean. When you see CSomeClass() (with parenthesis) i mean the constructor. And when you see them without I mean the class name itself. Note that I only used the default constructor in the example code.

I believe however that visualC allows three ways to instantiate a static object.

1. CSomeClass someClass;
2. CSomeClass someClass = CSomeClass();
3. CSomeClass someClass();

In the first case I believe that the default constructor is automatically used if you don''t do it explicitly but I''m not entirely sure about this one.

The second case is the official way to do it and I see no reason not do it this way.

The third case is allowed by VisualC++ but not on GCC (i believe) and personally it''s not a favourite of mine .

I''m not sure whether this answer is what you were looking for. If not then I''m sorry. Could you then please ask again?

Thanks,

Jaap Suter





Mmmm, I''ll have to think of one.

No offense to previous posters, but i think you missed the actual question. He wanted to know if the memory was removed at program termination. The answer is yes, atleast on a windows system, i''m not sure about linux/unix, but it has a fairly full featured virtual memory system so i would say yes.

"That which the flame does not consume...consumes the flame. "

I believe that the removal of any locally allocated memory (of the heap or for whatever else) has nothing to do with the operating system. Local variables are allocated on the stack and automatically removed when you exit the function. At least that''s what I heard.

The only memory that isn''t removed automatically is the memory that you explicitly new and do not delete.

Mmmm, I''ll have to think of one.

It doesn''t matter what operating system you''re running in. Anything you allocate with new will be returned to the system when your program exits. I assume Sleepwalker is worried about memory leaks having an impact beyond the scope of his program... don''t worry, it can''t happen. (Although you still should try and find any such leaks, on general principle.)

s9801758,
As for creating local class variables and calling the default constructor... why NOT use method 1? I don''t go around writing:

int x = int();

Why should classes be any different. (Then again, maybe you do write that.) More importantly, if VC6 accepts method 3:

SomeClass y();

It''s flat out incorrect. The reason that GCC (and any other conforming compiler) won''t like your code if you do that, is that you''re declaring a function named y, which takes no arguments, and returns a variable of type SomeClass. It''s one of the very odd (and very frustrating) inconsistencies in the grammar of the language. Nonetheless, it is the rule, so you should not try and explicitly call the default constructor like that.

-Brian

> It doesn''t matter what operating system you''re running in.
> SNIPPED ( see above post )
> on general principle.)

You are absolutely right!!

> s9801758,
> As for creating local class variables and calling the
> default constructor... why NOT use method 1? I don''t go
> around writing:
> int x = int();

Yeah, but although bjarn (soustroup or something) wanted your own datatypes to act the same as builtin types there are still some fundamental differences between them. That''s why I like to make a distinction between them. And I do:

int x = 0; // Which is basically a default constructor;

> Why should classes be any different.

Because they are different. The method only works with default constructors and not with parameters. That''s another difference.

> (Then again, maybe you do write that.)

No,

> More importantly, if VC6 accepts method 3:

> SomeClass y();

> It''s flat out incorrect. The reason that GCC (and
> any other conforming compiler) won''t like your code
> if you do that, is that you''re declaring a function
> named y, which takes no arguments, and returns a
> variable of type SomeClass. It''s one of the very
> odd (and very frustrating) inconsistencies in
> the grammar of the language.

Jep,

> Nonetheless, it is the rule, so you should not try and
> explicitly call the default constructor like that.

I disagree with you on this one. I also explicitly initialize my integers to zero. Then why not calling the default constructors explicitly?

ANyway, you are still right on C++''s quirks.

Jaap Suter

Mmmm, I''ll have to think of one.

I think you misunderstood my last statement. When I said you shouldn''t try and call the default constructor like that, I was referring to:

SomeClass x();

I have no problem with you writing:

SomeClass x = SomeClass();

That can improve readability in some sense. (And initializing your integers to 0 is ok, too.) I think we agree, in general, I just didn''t want people trying to do your third method, which has a totally different meaning.

-Brian

You''re right!!



Jaap Suter

Mmmm, I''ll have to think of one.