Use the DECLARE_SERIAL macro in an.h module, and then include that module in all.cpp modules that need access to objects of this class. If DECLARE_SERIAL is included in the class declaration, then IMPLEMENT_SERIAL must be included in the class implementation. CObject supports object serialization. One of the MFC’s great feature, which allows to store and retrieve the object’s current state. To enable this feature in our code: We must add DECLARE_SERIAL macro into our class declaration. IMPLEMENT_SERIAL macro must be added into class implementation file. And override the Serialize member function. Serialization: Making a Serializable Class. The DECLARE_SERIAL macro is required in the declaration of. MFC requires a default constructor when it re.

1. Declare Serial Mfc

DECLARE_DYNCREATE provides exactly the same feature of DECLARE_DYNAMIC along with its dynamic object creation ability. Then why should anyone use DECLARE_DYNAMIC instead of DECLARE_DYNCREATE?

2 Answers

The macros are documented to provide different functionality.

DECLARE_DYNAMIC:

Adds the ability to access run-time information about an object's class when deriving a class from CObject.

This provides the functionality for introspection, similar to RTTI (Run-Time Type Information) provided by C++. An application can query a CObject-derived class instance for its run-time type through the associated CRuntimeClass Structure. It is useful in situations where you need to check that an object is of a particular type, or has a specific base class type. The examples at CObject::IsKindOf should give you a good idea.

DECLARE_DYNCREATE:

Enables objects of CObject-derived classes to be created dynamically at run time.

This macro enables dynamic creation of class instances at run-time. The functionality is provided through the class factory method CRuntimeClass::CreateObject. It can be used when you need to create class instances at run-time based on the class type's string representation. An example would be a customizable GUI, that is built from an initialization file.

Both features are implemented through the same CRuntimeClass Structure, which may lead to the conclusion that they can be used interchangeably. In fact, code that uses an inappropriate macro will compile just fine, and expose the desired run-time behavior. The difference is purely semantic: The macros convey different intentions, and should be used according to the desired features, to communicate developer intent.

There's also a third related macro, DECLARE_SERIAL:

Generates the C++ header code necessary for a CObject-derived class that can be serialized.

It enables serialization of respective CObject-derived class instances, for example to a file, memory stream, or network socket. Since the deserialization process requires dynamic creation of objects from the serialized stream, it includes the functionality of DECLARE_DYNCREATE.

Put together, the following list should help you pick the right macro for your specific scenarios:

1. Use DECLARE_DYNAMIC if your code needs to retrieve an object's run-time type.
2. Use DECLARE_DYNCREATE if, in addition, you need to dynamically create class instances based on the type's string representation.
3. Use DECLARE_SERIAL if, in addition, you need to provide serialization support.

You're asking 'why buy a Phillips screwdriver when I own a flathead?' The answer is that you should use the tool that suits your needs: if you need to drive only flathead screws, don't buy a Phillips driver. Otherwise, buy one.

If you need the features provided by DECLARE_DYNCREATE (e.g. because you're creating a view that's auto-created by the framework when a document is opened) then you should use DECLARE_DYNCREATE and if you don't and DECLARE_DYNAMIC works, you should use it.

Declare Serial Mfc