Accessing child class interfaces from a static DLL without EXPORT_C

[LavanyaSpm]

Hi,
While building a static interface DLL, I have a base class defined as -

class CTestBase : public CBase
{
public:
// new functions
IMPORT_C static CTestBase * NewL();
IMPORT_C virtual TInt GetChildID() = 0;
IMPORT_C virtual ~CTestBase ();
}

class CTestChild : public CTestBase
{
static CTestChild * NewL();
~CChildMapTp();
TInt GetChildID();
TInt GetServiceId();
}

//CTestBase.cpp

EXPORT_C CTestBase * NewL()
{
//returns child instance
CTestChild* self = CTestChild::NewL();
return self;
}

//CTestChild.cpp
//Implements NewL() and other functions...but does not EXPORT_C any of them

TInt CTestChild::GetChildID()
{

}

TInt CTestChild::GetServiceId()
{

}
//Application using the DLL
MainUseDLL()
{
CTestChild* iChild = (CTestChild*)CTestBase::NewL();

iChild ->GetChildID() ; //Works as it has Import_C in the base class.

iChild->GetServiceId() ; //Gives linker error undefined GetSrviceId..
}

My question is, since I have the pointer to the child object, as per C++ i should be able to call GetServiceId(). but does not work unless i EXPORT_C it. I did see that the def files were updated with GetSrviceId only after Exporting it in the child class.

Is this the expected behavior? Do we need to export the additional interfaces in child class too to get access to the child class interface from an application using the DLL?

In Windows we are able to access the child class interface without dll exporting them. Does the behavior differ in Symbian?

[laa-laa]

For calling a function you need the function address. In your case, there are two kinds of address resolution: 1) static linking 2) dynamic resolution through a virtual table.

GetChildID() is declared virtual in the base class and therefore it is (implicitly) virtual in derived classes as well. That's why you can call it on the derived class object, since the address can be taken fron the vtable which is populated during object construction.

GetServiceId() is not virtual nor exported so you cannot call it outside the DLL. The toolchain only creates the import library for static linking for symbols you explicitly export. Since you're not exporting this function, you cannot link against it statically.

Lauri

[LavanyaSpm]

Thanks laa-laa, your explanation really helped.

I tried adding the virtual keyword to GetServiceId() in the child class and I can call the DLL function without exporting.

But I have some more questions now-
I am left with 2 options to expose the GetServiceId() interface to the application.

1. Use the virtual keyword or 2. EXPORT_C the interface.

I am trying to understand the difference between the two approaches.

1 . One point i guess is as you mentioned , virtual -> run time resolution and EXPORT_C would involve static linking with the import library. What more am i missing?

Now that I wish to export the interface in the child class also, to be called by the
application, not quite sure which is the correct approach.

From what i understand, virtual should be used in the inheritance hierarchy. So if the child class is not going to be used for further derivation, does adding virtual actually mean the right usage of the virtual concept in C++?..I would be doing it just to export the interface in the DLL. So is adding an EXPORT_C to the child class interface the correct way?

What are the factors i need to consider before deciding on the approach to be taken?

[laa-laa]

The virtual keyword means that the function can be overridden in subclasses. Technically, this is achieved with the vtable construct. The vtable is a table of function pointers automatically generated by the compiler. Subclass constructors can overwrite pointers in this table. Calling a virtual function carries a slight execution time overhead of one additional layer of indirection and of course the space overhead of the function pointer itself (on current Symbian OS systems, 4 bytes per virtual function).

Static linking is cheaper in both size and execution time. The function to call is resolved at link time and its address is resolved when the binary is loaded.

So, use static linking if you can. Use virtual functions if you must.

If you want to prevent classes outside the DLL from deriving from your class, declare your class with the NONSHARABLE_CLASS macro. In practice it prevents the export of vtable and runtime type information (on ARM ABI).

Lauri

[LavanyaSpm]

Thanks Lauri for all the information. Yes, will go with virtual only if needed in the inheritance hierarchy! And ya as you pointed out, i need to use the NONSHARABLE_CLASS macro in my DLL.