With a mighty <5i7euq$cmg@engnews2.Eng.Sun.COM>,
firstname.lastname@example.org uttered these wise words...
> Wow, there's been quite a party going on over here on comp.lang.scheme!
Not just comp.lang.scheme...
[various arguments and your responses to them deleted]
[MFC code deleted]
While I'm reluctant to defend MFC and C++, I have a few comments to
> I'm not an MFC expert, so I asked someone else, whom I consider to be
> a good Windows programmer, to write this for me. Perhaps there is a
> shorter way than the code I included. However, the 6 lines above
I'm not MFC expert, either, nor do I wish to be one, but I have used
it enoigh to know that I wouldn't write such code to create a button
or two, using a particular font. Instead, I'd create a dialog
resource, and if I wanted to place it within part of a window, then
I'd make it a child of that window and size it accordingly.
> don't seem to be equivalent to the Tcl script. For example, there is
> no code to respond to the button press, and I believe additional code is
> needed to free resources when the button is deleted. Suppose that the
> MFC code I used is off by a factor of two, and that it really only takes
> 12 lines of C++ to duplicate the functionality of one line of Tcl. Doesn't
> that still illustrate my point?
I think it's off by more than a factor of two. The amount of code used
to implement your example, needn't reflect the complexity of the user
interface. IMHO that's what an interface builder is for.
I guess the large number of development tools with interface builders
and their popularity supports my view, but I'm not sure that numbers
are relevant to this thread - if they were, we'd all be talking about
something else. For what it's worth, it's one way of looking at it.
Meanwhile, the code to create this dialog is just a couple of function
calls (one to create the dialog window, another to place it), and the
event handling code may be maintained for you by Class Wizard, if you
use VC++. (Other C++ compilers may provide similar tools.)
Of course, there are MFC features that aren't so easy to use, as the
resource editor won't know about them (e.g. resizable windows).
Buttons are just to trivial for a fair contest. Add some more complex
features, and things should get rather more interesting! The exact
_choice_ of features may favour Tcl or MFC/C++, it's up to you.
In other words, Your Mileage May Vary. A contest between VB and Tcl
might be more realistic, as it seems to me that their strengths are
very similar. However, we're assuming that the code is for Windows. If
you do that, then you've made it easy for a Windows develop to play a
trump card - unless Tcl supports ActiveX (please say that it does!)
and all the other features specific to Win32.
You'd do better by playing Tcl's trump card, which is much greater
portability than VB and VC++ will ever have. Again, YMMV.
Now I have to wash my mouth out for "defending" MFC. ;)
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Programmer and Information Broker | London, UK
Please remove the "gubbish" if you want to email me.