4

I am learning some COM code and the following code puzzled me.

    STDMETHODIMP _(ULONG) ComCar::Release() 
    { 
      if(--m_refCount==0)
       {
         delete this; // how could this "suicide" deletion be possible? 
         return 0;
       }
      return m_refCount; 
    } 

Yes. this is the similar code from here. And there I askes about how could a memeber method delete its belonging object. Now I am thinking about these 2 scenarios.

1- If I define a class without making an instance of it. Would any data related to this type exist in runtime?

2- If I only make 1 instance of the class and make the very single object commit suicide via the above code. After the object is deleted, where could the object's methods stay? Or am I paying too much attention to the encapsulation illusion?

I am wondering whether class methods are first name-mangled and then stored in the code/text segment of the program without regard to the existence of any object of its type. So the class methods exist as long as you define them.

Community
  • 1
  • 1
smwikipedia
  • 61,609
  • 92
  • 309
  • 482

2 Answers2

2

1- If I define a class without making an instance of it. Would this type exist in runtime?

Edit post OP's edit and gnud's comment:

A class is an user defined type. The type will be available as will be a float type even if you don't use any float in your code. The type information will be present. Particularly as gnud points out, if this is an abstract base class, you'd not be able to create any objects of that type but have derived class objects. The base class's member information will be suitably copied/updated to the derived class objects (provided you have appropriate ctors defined of course).

2- If I only make 1 instance of the class and make the very single object commit suicide via the above code. After the object is deleted, where could the method stay?

Methods are portions of executable code. Class objects have a table of all member function pointers. This table is updated when the object is created to point to the appropriate region of the binary. When the object is deleted, the binary remains, without a way to access it.

Edit: More on delete this which is perfectly legal: This is FAQ 16.15. Further, note that this is useful only in very few instances -- a reference counted object is one such (as you show in your code).

dirkgently
  • 108,024
  • 16
  • 131
  • 187
  • Generally (i.e. on most implementations), a class type object only has a pointer to a function table (the "vtable") if it is polymorphic (i.e., it has one or more virtual functions). For non-polymorphic class types, no table of function pointers is necessary. – James McNellis Feb 24 '10 at 02:35
  • Your answer to `1` isn't always true - if the class has virtual methods a vtable might be present in memory at runtime. But you won't be able to use it for anything :) – gnud Feb 24 '10 at 02:37
  • @James McNellis: Yes, true. In the non-virtual case, the `this` pointer is implicitly passed around and all we have is an ordinary function in the garb of members. However, the case in point is COM's `IUknown::Release` and I preferred to stick to the more general case. Thanks for bringing this up! – dirkgently Feb 24 '10 at 02:38
  • @gnud: I hadn't noticed that the question was subtly modified. – dirkgently Feb 24 '10 at 02:44
  • @dirkgently: I've a doubt. You stated that "classes don't exist @ runtime". I know that the class functions will be nothing but normal static functions @ runtime, which will be allowed to access class private members (since private/public/protected is all compile-time). So what about the class variables? I mean they should be clubbed-up? – legends2k Feb 24 '10 at 02:45
  • 1
    A lot of confusion on that part -- see my updated post. Also, static member variables are akin to namespace scope globals whereas non-static ones are instance specific. You can access the static member variables even without creating instances but not non-static ones. – dirkgently Feb 24 '10 at 02:51
  • Oh yeah! They're global vars, so that you don't need a object to access them, referring them with the class name (namespace) will do. Now I get it. +1 :) – legends2k Feb 24 '10 at 02:56
2

The code for a member function is associated with the class, not with an instance of the class. There's one copy of the code, regardless of how many instances are created (zero, one, a million, whatever.) Doing delete this; destroys an instance, but it doesn't do anything at all to the code for the class's member functions.

1: The this pointer only exists in a non-static member function, so that code won't compile unless it's part of such a function. It must be called on an instance. If there's nothing in the program that creates an instance of the class, there's nothing that calls the function, but the code for the function still exists at runtime; it just doesn't get executed.

2: Class methods are stored in the program's text segment, not its data segment, as you guessed. They remain there for the lifetime of the program. (In fact, the text segment is typically read-only and cannot be modified at runtime.)

Wyzard
  • 33,849
  • 3
  • 67
  • 87