Re: [C++] c'tors & d'tors

"AngleWyrm" <anglewyrm_idontreadspamthankyou@xxxxxxxxx> wrote in
news:doSdnVhcq4iK2a_anZ2dnUVZ_oesnZ2d@xxxxxxxxxxx:


yes, because I want to be able to re-initialize the class when
necessary. There are actually a couple constructors: default, and one
with a filename parameter and an execute flag (which defaults to
false).

I don't know exactly what you are doing, obviously, but I would look at
using an open()/close() sort of paradigm and have your constructor
initialize everything so that the the object is in the "closed" state
much like std::ostream does.

Normally, I prefer a model where when the object is constructed, it is
ready to go until it is destructed. I think this is generally more
reusable and exception safe. For example:

for (i = 0; i < 10; ++i)
{
Object o(i);
o.dosomething();
}

Should actually be more efficient than:

Object o;

for (i = 0; i < 10; ++i)
{
o.Use(i);
o.dosomething();
o.Finish();
}

(Use and Finish could be named constructor and destructor, but I think
it keeps object lifetime clearer if you reserve those terms for that
usage.)

The only time you might get a win in the second scenario would be if
Object allocated some buffer that could be reused. Even then it may
prove to not be more efficient, only profiling can tell for sure.



I tried calling ~foo() directly and it crashed. A little research
showed this is a no-no:
http://www.parashift.com/c++-faq-lite/dtors.html#faq-11.5 says in
part: "But you can get really bad results from calling a destructor
on the same object a second time!"

The problem with directly calling the destructor is that the destructor
will get called again when the object is destroyed (either via delete or
when the scope exits and the stack unwinds.) You can write the
destructor to be immune to this, but I think it is better to separate
object lifetime and object reinitialization anyway.


Um. Bad programmer, baaad. Maybe the ~foo() function also calls the
memory de-allocation routine? I haven't tried calling a constructor
explicitly, but I imagine that problems would appear there as well.


No, ~foo won't deallocate foo, but it will invoke the destructors on all
your member variables and some deallocation can occur there. Directly
invoking the destructor is best pair with inplace allocation. That is,
you can have:

char buf[5000];

Foo * pFoo = new (buf) Foo();

Which would create a Foo in the memory allocated to buf. You could then

pFoo->~Foo();

to clean up the object. This is a lot to keep track of in general, but
there are sometimes cases where this is required.


If you don't mind meandering a bit, I tried something that I was
surprised worked at all: Before main, I declared global class
variables, and all kinds of stuff can be executed in their
constructors. Is there some specific things that cannot be done in a
constructor before main?



No, nothing that can't be done. Should be done? That is another
question. Object initialization rules can get complicated in larger
projects and globals in general can be a dependency nightmare.

joe


.

Relevant Pages

  • Re: Unusual usage of IUknown
    ... ptA = new A; ... calling V constructor, szData=V ... calling A destructor, szData=A ...
    (microsoft.public.vc.language)
  • Re: Unusual usage of IUknown
    ... char * szData; ... calling V constructor, szData=V ... calling A destructor, szData=A ...
    (microsoft.public.vc.language)
  • Re: cant establish connection to Domino Server
    ... In Constructor of CABProvider ... WINAPI OpenServiceProfileSection ... In Destructor of CNotesExchExt ... AllocateAndCopyString ...
    (microsoft.public.outlook.interop)
  • Re: Shutdown order
    ... Thomas Mlynarczyk wrote: ... Where am *I* calling the destructor in my code? ... Like a constructor, you ...
    (comp.lang.php)
  • Re: Any experience with "The Last One"?
    ... In this International Standard, the examples, the notes, the ... xconstructor ... xdestructor ...
    (comp.lang.c)