"Earl Purple" <earlpurple@gmail.com> wrote in message
news:1138189878.377481.93090@z14g2000cwz.googlegro ups.com...[color=blue]
>
>
ypjofficial@indiatimes.com wrote:[color=green]
>> Hello all,
>>
>> I have written a class with many private data members.and i am putting
>> it in a separate dll file.
>> Now when i link that file while writing my main program
>> module,natuarally i have to use the header file of the class developed
>> by me to access its functionality.
>> so what should be there in the header file?
>> Only the public methods declaration / data members of that class or the
>> whole layout of the class along with its all private members?
>> (
>> IMO the private section restricts the accessibility of the class and
>> the user of the class is abstracted from the exact layout of the
>> class.So there should be no need to show the internal layout of my
>> class by putting the private variable inside the header file of that
>> class.
>> )[/color]
>[color=green]
>> I encountered severe crasing problem when I declare the class without
>> the private members in the header file? but everything works fine when
>> i put the exact layout of the class correctly inside the header file.
>> (i have defined all the public methods inside a separate cpp file with
>> the scope resolution operator)[/color]
>
> In a moment you'll probably get flamed with the old "C++ has no concept
> of dlls" (or shared objects or any other kind of loadable library).
>
> Anyway, when you are exporting a class you want to export the interface
> only. That means one of two things:
>
> - Use an abstract base class and a factory
> - Use a pImpl
>
> I don't know your knowledge of the language but basically they mean as
> follows:
>
> - Abstract base class: has at least one pure virtual method. In your
> case probably all of them will be pure virtual. Ensure you also have a
> virtual destructor.
> - Class factory: This will usually be an object but can be a function
> to generate instance of the class.
>
> Note that as the classes have to be allocated with "new", there will
> need to be a defined deleter. Your library should provide a deleter.[/color]
Or just define another "lifetime" mgr class wrapper for the object:
class MyClassInst // could derive from the MyClass interface also
{ // but then you'd have to provide forwarding
// methods to the implementation class.
MyClass* my_class;
public:
MyClassInst()
{
my_class = c_CreateMyClass(); // DLL exported create func
}
~MyClassInst()
{
c_DestroyMyClass(my_class); // DLL exported destroy func
}
operator MyClass*(){ return my_class; }
};
MyClassInst my_inst; // instantiate an instance of MyClass from DLL
[color=blue]
> (Again it can be a function or functior).[/color]
Or a class as above.
[color=blue]
> Then the library using the
> class must use the deleter to destroy the object. A boost::shared_ptr
> can take a deleter. Note that for a custom deleter, one option is to
> make this concrete (in a generic header) but have itself an abstract
> pointer. It invokes a method on the abstract pointer (when operator()
> is called) which at the same time should delete itself, so the deleter
> has the same life-span as the object.
>
> - The pImpl uses a "pointer to implementation" of a type that is only
> forwardly declared (but is known in the implementation of your library
> class). Your class will then forward all implementation to this pImpl
> class. Note that as a pImpl is a pointer, you have to overload the
> destructor, and handle also assignment and copy-construction (or
> disable them). This method has the advantage of allowing users to
> create a class directly without a factory (and therefore to be able to
> more eaily manage destroying them) and that these classes can also be
> created on the heap.[/color]
And provides a way to derive from classes when you don't have the source
code except for the interface header. (Gee, wouldn't some new C++ syntax
be narly in that scenario :)).
Ted
[ See
http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
