7

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?

Adrian Mole
  • 49,934
  • 160
  • 51
  • 83
  • 7
    The downvotes are undue. The particularities of the implementation are an understandable source of confusion. This is someone trying to learn to do the right thing. If you believe this is not a good question, simply don't upvote it. – IInspectable Jan 11 '15 at 12:26
  • 2
    This is an excellent, specific question. It's highly likely that the downvoters are not people who actually use and program using Visual C++ - but simply StackOverflow scavengers, as most of us StackOverflow folks who actually work for a living have become so accustomed to over the years. – Dan Nissenbaum Jun 19 '16 at 18:20
  • 1
    See, for example, this nearly identical question: http://stackoverflow.com/questions/733717/difference-between-declare-dynamic-and-declare-dyncreate. That question is from 2009, with a good handful of upvotes, and no downvotes. It's not a coincidence that the question is from 2009, with no downvotes. In 2009, the swarms of StackOverflow downvote and close-vote scavengers had not yet arrived on the scene. – Dan Nissenbaum Jun 19 '16 at 19:27

2 Answers2

16

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.
IInspectable
  • 46,945
  • 8
  • 85
  • 181
  • 2
    Also note that if you use `DECLARE_DYNCREATE` in the header file, you must be certain to match this with `IMPLEMENT_DYNCREATE` in the source file. (Ditto for the others.) – Dan Nissenbaum Jun 19 '16 at 20:05
0

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.

Nik Bougalis
  • 10,495
  • 1
  • 21
  • 37