Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Globals initialization using templates

Reply
Thread Tools

Globals initialization using templates

 
 
amparikh@gmail.com
Guest
Posts: n/a
 
      11-16-2006

Gianni Mariani wrote:
> http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
> > Gianni Mariani wrote:
> >> red floyd wrote:
> >>
> >>> // missing destructor
> >>> // this is necessary in case T manages some kind of resource.
> >>> ~Globals()
> >>> {
> >>> impl->T::~T();
> >>> }
> >> That's not clearly the right thing. impl is a static and so it does not
> >> necessarily need destruction from a memory leaking perspective.

> >
> > impl might be static....but it might be holding a pointer to an object
> > T which might be holding up stuff. Therefore you need to call the T's
> > destructor.
> >

>
> That would mean that impl will point to unallocated memory if used like
> this:
>
>
> Globals<Type>()->X(); // ok works first time
> Globals<Type>()->Y(); // oops - broken this time


I dont understand this code above....
But you need some kind of descurtion on a refcount basis....

 
Reply With Quote
 
 
 
 
Gianni Mariani
Guest
Posts: n/a
 
      11-17-2006
red floyd wrote:
> Gianni Mariani wrote:
>> red floyd wrote:
>>
>>> // missing destructor
>>> // this is necessary in case T manages some kind of resource.
>>> ~Globals()
>>> {
>>> impl->T::~T();
>>> }

>>
>> That's not clearly the right thing. impl is a static and so it does
>> not necessarily need destruction from a memory leaking perspective.

>
> Who said anything about memory? T could be a type that manages a
> resource that could conceivably live beyond the lifetime of the program,
> e.g. a SysV Semaphore.
>
> When the program ends, Global<my_semaphore_manager_class> should bloody
> well call the destructor for the my_semaphore_manager_class object it
> created in impl, so that it can release the resource it holds.
>


We have no idea what this is used for. Clearly there is no destructor
and possibly for good reason. Saying it "should bloody well" have one
is making many assumptions that may not be valid.

 
Reply With Quote
 
 
 
 
red floyd
Guest
Posts: n/a
 
      11-17-2006
Gianni Mariani wrote:
> red floyd wrote:
>> Gianni Mariani wrote:
>>> red floyd wrote:
>>>
>>>> // missing destructor
>>>> // this is necessary in case T manages some kind of resource.
>>>> ~Globals()
>>>> {
>>>> impl->T::~T();
>>>> }
>>>
>>> That's not clearly the right thing. impl is a static and so it does
>>> not necessarily need destruction from a memory leaking perspective.

>>
>> Who said anything about memory? T could be a type that manages a
>> resource that could conceivably live beyond the lifetime of the
>> program, e.g. a SysV Semaphore.
>>
>> When the program ends, Global<my_semaphore_manager_class> should
>> bloody well call the destructor for the my_semaphore_manager_class
>> object it created in impl, so that it can release the resource it holds.
>>

>
> We have no idea what this is used for. Clearly there is no destructor
> and possibly for good reason. Saying it "should bloody well" have one
> is making many assumptions that may not be valid.
>


Exactly. We have no idea what this is used for. Therefore is should
behave properly in the case where the template parameter has a
non-trivial destructor.
 
Reply With Quote
 
Gianni Mariani
Guest
Posts: n/a
 
      11-17-2006
red floyd wrote:
....
> Exactly. We have no idea what this is used for. Therefore is should
> behave properly in the case where the template parameter has a
> non-trivial destructor.


Can you make a logical argument why is "requires" a destructor making no
assumptions ?
 
Reply With Quote
 
red floyd
Guest
Posts: n/a
 
      11-17-2006
Gianni Mariani wrote:
> red floyd wrote:
> ...
>> Exactly. We have no idea what this is used for. Therefore is should
>> behave properly in the case where the template parameter has a
>> non-trivial destructor.

>
> Can you make a logical argument why is "requires" a destructor making no
> assumptions ?


Because if T has a trivial destructor, then no harm is done by invoking
its destructor. If T has a non-trivial destructor, then failure to
invoke it can cause problems. Therefore, the destructor should be invoked.
 
Reply With Quote
 
Gianni Mariani
Guest
Posts: n/a
 
      11-17-2006
red floyd wrote:
....
>
> Because if T has a trivial destructor, then no harm is done by invoking
> its destructor.


I don't think "no harm" is entirely clear. I'm not suggesting this is
good code, but there have been badly designed systems where I have
needed to not call the destructor on system exit because bad things
would in fact happen. Hence, as a generalization, I don't think "no
harm" is supportable.

> ... If T has a non-trivial destructor, then failure to
> invoke it can cause problems. Therefore, the destructor should be invoked.


Not all non-trivial destructors (for globals) need to be called. The
operating system does a much more efficient cleanup on exit than a

e.g. this code (brain dump - not checked)

#include <vector>


std::vector<int> * foo = new std::vector<int>(10000000);

int main()
{
}

will not delete the object pointed to by foo, however on all popular
operating systems (I don't talk about embedded ones), this code is well
behaved.

In general, you can't really bargain on global destructors being called
anyway because there are ways of termination that do not call the final
cleanup routines (memory fault, power failure, failure to catch
exception, memory depletion, unresovable page faults etc just to mention
some). So if your code truly depends on global destructors to be
called, you're in for trouble.

For example, if your code uses temporary files, you may want to "lock"
the file and on startup, cleanup all unlocked temporary files. You
could do the same for all persistent OS objects.

So the point is, your generalization is clearly incorrect. While it is
"preferable" to have destructors of global objects called, it is
certainly not required all the time and it certainly cannot be depended
on all the time.

All generalizations are wrong.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
initialization of array as a member using the initialization list aaragon C++ 2 11-02-2008 04:57 PM
how to Specializations of function Templates or Overloading Function templates with Templates ? recover C++ 2 07-25-2006 02:55 AM
Default Initialization Vs. Value Initialization JKop C++ 10 09-22-2004 07:26 PM
Templates templates templates JKop C++ 3 07-21-2004 11:44 AM
using templates in templates John Harrison C++ 8 07-31-2003 12:00 PM



Advertisments