...
The disadvantage of the second approach is that you have to add some extra information to the class definition, and you have to add some extra project defines to each and every APP (or hand coded project) that uses the class DLL, and if you get any of this wrong your app will almost surely GPF. The advantage is that if you make a change to the class that doesn't affect any of is existing exports, you don't need to recompile all the apps that use that class. You just drop in the new DLL.
An ABC example
Here's a typical ABC class header:
...
Info |
---|
I've only touched on two uses of the |
A better way
The DCL uses what I like to think is a much better way. It's certainly a lot simpler and less error-prone.
...
Now there's just one equate that needs to be added to a project, and it only needs to be added if you actually want to compile the classes; otherwise it's assumed that you're using the classes as compiled into the DCL DLL.
The easiest way
It's still a hassle typing in LINK and DLL attributes when creating a class for the first time. Or it used to be. I now use John Hickey's brilliant ClarionLive! Class Creator, part of the ClarionLive utilities pack. Just set up a set of INC and CLW base class files, and Clive (as I like to call him) will do the rest. Fantastic!
Summary
For years I've found the DLL
and LINK
attributes to be a huge pain, and on more than one occasion I've either forgotten to add them or added them incorrectly, with predictably ugly results.
...