We help IT Professionals succeed at work.

We've partnered with Certified Experts, Carl Webster and Richard Faulkner, to bring you a podcast all about Citrix Workspace, moving to the cloud, and analytics & intelligence. Episode 2 coming soon!Listen Now

x

const objects calling destructor

fatimao
fatimao asked
on
Medium Priority
480 Views
Last Modified: 2008-03-04
hi,
    i have come across a strange problem, causing conflict in concepts.

    It is known that a const object can only call const functions with the exception of constructors and destructors which are called only once and automatically. But i experienced that we can also call the destructor explicitly (c++) :?, but that violates the const object concept as we can call destuctor with it and can do any thing in the function.

   On net the only reason i found for allowing explicit destructor call is to clear the memory, but we can write some memory clean function, as we do initialization functions corresponding to initialization constuctors !!! i am not satisfied with this argument.

  so my question is why explicit call of destructor is allowed? and how is justifies the const obj concept?

  hope i can get some better reasoning from here. really looking forward for replies.

regards
fa
Comment
Watch Question

Not the solution you were looking for? Getting a personalized solution is easy.

Ask the Experts
efn
Commented:
As the links provided by rajeev_devin explain, the explicit destructor call is allowed as the counterpart of placement new, to make it possible to destroy an object without necessarily releasing its storage.  It's true that one could write a different function to do this, but then if the object were to be used without placement new, there would be two functions that do the same thing, which would be undesirable.  Since the concept of a destructor function that destroys an object was already defined, it was logically consistent to use the same function to do the same job in the placement new case.

The designers of the language had two choices about attempts to call the destructor of a constant object:  they could allow it or not.  If they didn't allow it, all constant objects could never be destroyed and would hang around indefinitely.  If they did allow it, a sufficiently deranged programmer could write code that would destroy a constant object.  They decided that the second case was the lesser evil.  Requiring all constant objects to have indefinite lifetimes would be both inconvenient and inefficient.  For that matter, to be consistent, you would also have to forbid running the constructors of constant objects, because they too change object content, so you could never create a constant object in the first place.  So on the whole, it is most practical to exclude construction and destruction from the class of operations that are not allowed on constant objects.
Do not think of constructors & distructors as an ordinary member functions. These are special member functions, one initializes and other deinitializes.
Any object can call distructor explicitly, irrespective to whether it is a const or a non const.
I do not find any strange thing in const object calling distructor explicitly.
If you have a problem with,
1. const obj calling distructor, let me tell you a basic thing any thing created has to be destroyed so distructor call is a must.
2. const obj calling distructor explicitly, here objects are allowed for this.

All the best
Prashant Sabnekar
Access more of Experts Exchange with a free account
Thanks for using Experts Exchange.

Create a free account to continue.

Limited access with a free account allows you to:

  • View three pieces of content (articles, solutions, posts, and videos)
  • Ask the experts questions (counted toward content limit)
  • Customize your dashboard and profile

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

OR

Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.