Prev: Silly question regarding Radio Buttons
Next: Does anyone copyright or patent their applications?
From: John H. on 18 May 2010 18:39
Dear all,

I have ever so often shot myself in the foot with MFC macros like
BEGIN_MESSAGE_MAP
IMPLEMENT_DYNCREATE

and more. The point is that all of these macros take your class and
parent-class as parameters.
If during development your class hierarchy changes and you forget to
update those macros, things can go wrong in just about any way. Some
cruel and some very subtle.
Now, what I am about is the subtle errors that arise when changing
things like your class hierarchy, because the errors that arise might
be hard to notice and even harder to find (it has already taken me
days to track down this type of issues several times)

This said there should be a way to maintain consistency with these
macros some way. I know the best way would probably be to put away
with MFC altogether since it is seriously aging and there are better
tools around these days, but for those of us still busy with legacy-
applications life would be seriously easier with any help on this
topic.
I'd be curious if anyone has found a way to deal with this
consistency-
problem.

Thanks in advance,
Pelle.
From: Joseph M. Newcomer on 18 May 2010 20:42
See below...
On Tue, 18 May 2010 15:39:59 -0700 (PDT), "John H." <oldman_fromthec(a)yahoo.com> wrote:

>Dear all,
>
>I have ever so often shot myself in the foot with MFC macros like
>BEGIN_MESSAGE_MAP
>IMPLEMENT_DYNCREATE
>
>and more. The point is that all of these macros take your class and
>parent-class as parameters.
>If during development your class hierarchy changes and you forget to
>update those macros, things can go wrong in just about any way. Some
>cruel and some very subtle.
****
Yes. I love the use of "cruel" to describe this.

If we wanted some good tools, one which would automatically insert a class in the
derivation hierarchy would be really useful
****
>Now, what I am about is the subtle errors that arise when changing
>things like your class hierarchy, because the errors that arise might
>be hard to notice and even harder to find (it has already taken me
>days to track down this type of issues several times)
****
THe only Good News here is that once you've seen it, it is usually easy to recognize the
second time. I still me this kind of error, but since I know what the manifestations are,
I can spot it quickly. But the first time, it took me many hours.
***
>
>This said there should be a way to maintain consistency with these
>macros some way. I know the best way would probably be to put away
>with MFC altogether since it is seriously aging and there are better
>tools around these days, but for those of us still busy with legacy-
>applications life would be seriously easier with any help on this
>topic.
****
I agree. Something like a Perl script that cross-checked everything could be written, but
it is really sad that there is no other way to do the checking.
****
>I'd be curious if anyone has found a way to deal with this
>consistency-
>problem.
****
Short of being careful, I have not chosen to write a tool that double-checks the
hierarchy, although I have a pretty good idea how I'd do it. I just don't make this error
often enough any longer to justify the effort.
joe
****
>
>Thanks in advance,
>Pelle.
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: David Ching on 18 May 2010 21:51
"John H." <oldman_fromthec(a)yahoo.com> wrote in message
news:d9693833-714a-4ee7-ac7d-0c34510977f0(a)m21g2000vbr.googlegroups.com...
> If during development your class hierarchy changes and you forget to
> update those macros, things can go wrong in just about any way.
....
> I'd be curious if anyone has found a way to deal with this
> consistency-problem.
>

After being burned a few times, I just do a Search+Replace of <old parent
class> with <new parent class> in both the .h and .cpp.

You can also use a macro such as:

#define MyClass_ParentClass CWnd

class MyClass : public MyClass_ParentClass
{
};

This is ugly and doesn't read well, however.

-- David



From: Pelle on 21 May 2010 14:19
Hello all,

I just wanted to say thanks to those who have responded.
The class-name-macro does look ugly, but if it helps, I might as well
be willing to try. I'll be thinking about it.
Also I hope that spotting those errors really becomes more easy with
time. I think it does, but if you don't encounter them for a while,
you might be back to the starting point.

Any ways - have a nice weekend!

Regards,
Pelle.
 | 
Pages: 1
Prev: Silly question regarding Radio Buttons
Next: Does anyone copyright or patent their applications?