Re: mfc pitfalls

I see no callbacks in MFC. I see event notifications being routed to handlers; I see
virtual methods being invoked; but I see no callbacks. There is a very low-level callback
mechanism used to deliver window messages, but it is about as relevant as assembly code to
the architecture of an MFC application. Callbacks as a paradigm involve explicitly
passing pointers to functions around, and as far as I can tell in most MFC apps that
happens so far under the floor that we never see it. That's why we use higher-level
models such as event handlers, and don't worry about the implementation. Things happen
asynchronously and handlers are invoked, but even the tables that have function pointers
are formalized and they are all compile-time static data. Sure, virtual methods look like
callbacks also, but again their function pointers are handled by mechanisms that hide the
detail from the programmer.

Why do you assume that there is a single processor? We've had hyperthreading for years,
and I had a quad processor a decade ago. Multiprocessors are now going to be standard.
This is like saying "the oxcart is good enough because I don't have good roads" while
being surrounded by the Interstate Highway System on all sides. Spending effort and
adding complexity to guarantee that performance can never improve with the addition of
processing power means your application is not scalable. More processing power does not
improve its performance.

What are the "new ways" of splitting a computation? OpenMP? Right. Go look at in detail
to realize how bad it can be. It has some serious performance problems lurking in it, but
they are disguised by the superficial simplicity of the architecture (I've single-stepped
through OpenMP code, and it is a fascinating exercise).

Your experience just emphasizes one of my other principles: "Never worry about optimizing
lines of code unless you know what lines need to be optimized. Optimizing lines of code
generally produces single-digit percentage performance improvements. Optimizing the
architecture of your program can buy orders of magnitude improvement. Always look for the
architectural issues first". What you said was you redesigned the architecture and got
massive improvement. This is a typical experience.

Note also that the embedded world, with its need for real-time response, is a different
world than the world of MFC apps. I get a lot of former-embedded programmers in my
courses, and I tell them that one of the paradigm shifts is that microseconds no longer
matter. If they do, then Windows is the wrong platform. I've done embedded work, and the
premises and requirements are both quite different from building Windows apps. Building
an embedded system like I build a Windows app would be a Really Bad Idea. Building a
Windows app like I used to build embedded systems would be an Equally Bad Idea. The other
place I lurk is in device drivers, which are a halfway house between the two models. These
are different worlds in many ways, and it would be incorrect to apply the rules and
premises of one of them as a basis of design or implementation in one of the others.

With respect to the original topic, an MFC app that was built using explicit callbacks or
which passed function pointers around would be something to be distinctly scared about.
The only function pointers should be managed in some way, such as with the Properties page
of VS, or via virtual methods, so they are never really evident to the programmer.

On Fri, 02 Feb 2007 15:28:35 GMT, "jmarc" <jmarc@xxxxxxxxxxxxxxxxxxxxx> wrote:

Re-implementation of a methods IS the new way of
use of Callbacks.. And in all good OO apps, there
a plenty of that!

In most MFC apps, you are writing code in that kind
of Callbaks..


"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
news:pnb5s215dc6v0lhdtrn3p4a1lpqrr71ead@xxxxxxxxxx
I;m not sure what "new way" requires callbacks; in fact, callbacks are
usually considered
a bad idea. virtual methods usually work better than callbacks for most
designs, and
ActiveX (for all my complaints about it as a Web technology) was designed
to elminate the
need for callbacks-as-callbacks using instead a more rigorous notion of
event
notification.

I would actually be scared of any project that thought callbacks were a
way of life. The
result is usually an unmanageable mess. Languages like Ada recognized
this and there was
no syntax in the design for function pointers.

I'm curious why you avoid threads. I wouldn't know how to write an
interesting system
without them. What good is having an n-way multiprocessor if your only
mechanism is to
use a single thread. When everyone else has their multiple oxen pulling
their carts,
being vastly more efficient, getting everything done faster, the
single-threaded approach
is clearly a dead-end paradigm, and should be considered only in rare and
simple cases.
Otherwise, I get no benefit from spending money on concurrency. Sure, I
can run more apps
without major interference between them, but suppose I only have *one* app
that matters? I
want it to get maximum throughput.

Even with thousand of threads in one application, the task will not being
achive faster,
or more processing done, if your platform just have one CPU.

With the arrival of multi-core platform, this is different. Obivously more
work can
be done.. But the system can spread itself thousand of task (apps) over
those core.

For a single app, if you want to process more data, or being faster, sure it
have
to be split over more than a single CPU. But there are new ways coming to
split
a single thread application over many CPU.

The future of OS with many CPU core is to achive the GUI related code in a
separate
thread. And the apps I already built will work just fine...

jmarc...


As I tell my students, "if you need to do something long, use a thread.
If you need to do
lots of things, use many threads." There are design criteria, such as if
the maximum
number of feasiable threads is larger than the number of processors, then
you can actually
lose efficiency, but if the threads can block, then you need more threads
than processors.
Multithreading also simplifies a lot of architecture, and in fact
eliminates the need for
callbacks in some cases. I would never use callback I/O for asynchronous
I/O, for
example. It is far too complex. But I'll spin off a thread without a
second thought,
just to simplify the logic and keep the GUI alive.

Sure I effectively don't use blocking I/Os. I prefer the use of old avoided
pooling method
in my OO design. Simply because all does not have to be micro-second timed.

I already redesing a distributed embeded application written in full
standard C code.
The new desing was an exaustive OO aproach with bunchs of virtual method.
On the exact same hardware, the result was an application that run 10 times
faster!
Each node had only one cpu and had to support up to 7 comm links with the
others.

It is not a tehory, it is a fact. I saw it working well, and being very
reliable!



So I fail to see how good design precludes threading; on the contrary, I
believe modern
good design *exploits* concurrency. The art is to do so as simply as
possible. So the
"positive-handoff protocol" is, for example, better than using
synchronization. Queues
are good models for interthread communication. "The best synchronization
is NO
synchronization" is one of my design principles: that is, do not design
threads that
require a lot of synchronization; make them independent entities that
touch each other as
little as possible with synchronization primitives. Synchronization is
required where
threads touch. And like mechanical systems, where things touch, they
generate heat and
waste energy. Queues turn out to form virtually friction-free mechanisms
for these
situations, especially if you know how to do them efficiently. You can do
VERY good OO
design and use threads at practically zero cost.

Given you have only one thread to do everything, how do you keep the GUI
alive?
PeekMessage? Alternatively, you piece out the work and handle the little
pieces one at a
time during the idle time? Do you at least use fibers? Shades of Win16!
I cerntainly
don't want to waste a lot of effort producing code I stopped writing
around 1993 (that's
fourteen years ago!), that runs with the same performance as fourteen
years ago except
scaled by the processor speed. Why is having a single thread be the
bottleneck to all
performance a good design methodology? If I'm running on an 8-way
multiprocessor, I want
to use as much computing power as I can get my hands on to minimize the
turnaround time on
a transaction. I'm not going to sacrifice the quality of the user
experience to some
silly design principle of single-threading.

Just remember, the begin of this newsgroup thread, was about MFC apps.
Now if you talk about of multi-processing, co-processing and distributed
applications
and heteroge environment, we may talk otherwise..

Friendly,

jmarc..

joe

On Fri, 02 Feb 2007 01:31:20 GMT, "jmarc" <jmarc@xxxxxxxxxxxxxxxxxxxxx>
wrote:

Just fews comments..

- I didn't say you should write down
a specs document to give to your outsource.
Talking in few words may help a lot
to get what you want.

- Data flow (flowcharts) is one of the UML diagrams
defined. Indeed, it not the most used. We should
use only diagrams that are usefull to be elaboreated,
in the goal to explain the design we have done to the
next programmer that will work with the source code.

UML goal is also to elaborate a right and powerful
design of a small or a very huge applications, as the
implementation will go fast and with minimum error.
(design should comes before implementation.. right?)

What really matter are data structure diagrams to show the relationships
of the
information. This is ultimately the only thing that matters....

Just fine!! And UML is the right way to describe relationships!

UML and OO coding are not religious. I just see
them as tools..! I also write programs for long time, but not
as much as you... I begin in 1973, and the biggest workstation
application I work on in 1995 had 2 and half billion lines of code,
using over 60 different services on the server.
But sure, many of us had used to much cut and paste in that code.
and bunch of very discrete bugs to find out in the tests phase...

- Now, programming in OO environment requires new
thinking of the design. The new way of programming fill
a very huge place to Callbacks (every reimplemented func
are just those), that it become impossible to follow the code
like we done in the past with a just fine Structured app.

OO programming doesn't prone using cut and paste aproach
in the code (despite template that I tried to avoid). And
over a year and half, I average over 110 lines of code per day,
efficient in the final release, comprising tested time and bugfree..
.. and full comments along in the code as well !

- Now, using OO techniques and a good desing, I
also able to avoid the use of threads in my applications.
Whatever I have to manage communications with many
services at same time, and keeping GUI still operating!

jmarc..



"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
news:r1l4s2ppl9gc4e2rcaocrr5gannlj8qbd6@xxxxxxxxxx

On Thu, 01 Feb 2007 19:32:52 GMT, "jmarc" <jmarc@xxxxxxxxxxxxxxxxxxxxx>
wrote:

There are many styles of programming.
Each may vary a lot from one to another,
but not because one or the other is badly
implemented.
****
But there are practices that are just wrong. You should see some of the
outsourced device
drivers I've had to review! Pure crap, written by people who should not
be allowed to
program, let alone deliver products. So there ARE bad styles of
programming, and they are
very obviously bad.
****

You should have defined the programming
style you want, or those you'l be easy with
afterward, before contracting the outsource.
*****
Writing a specification of what is forbidden (e.g., my "n Habits of
Highly
Defective
Windows Programs" might be a good start) is also important.
*****

A source code may be very well implemented,
but hard to be understood by someone who
don't know much about MFC tricks.
*****
What is scarier is the programs which show the programmer did not have a
clue as to how
MFC works. The code is not only hard to understand, it is hard to
understand because it
is wrong. But it is so hard to understand that only someone really
familiar with MFC can
see that it is written by someone totally clueless and that ti doesn't
actually work. Or
worse still, gives the temporary illusion of working but fails to lock
thread-shared
variables, properly free memory, or any of a dozen blunders.
*****

Finally, my opinion is that you should be
able to understand the design of the imple-
mentation the outsouce have been followed.

To achive that, I really think the outsource
should be able to provide you at least few
UML diagrams.
****
UML diagrams are often used as a substitute for thinking, and definitely
as a substitute
for proper design. My experience in this has been fairly consistent.
I've seen code
delivered with massive UML diagrams that accurately reflect what the
code
does;
unfortunately, the code is wrong, so the UML diagrams are wrong. But
they
are impressive,
and they satisfy someone's requirement that the code have UML diagrams.

When I was first learning to program, back in 1963, we were told that
flowcharts were
essential. You wrote your flowchart and all you had to do was translate
it to code. The
flowcharts fell into three categories: (a) high-level diagrams which we
would now call
'workflow diagrams' but which had nothing to do with actual coding (b)
detailed code-level
flowcharts that, once coding started, became irrelevant and obsolete and
(c) detailed
flowcharts built from the code, which accurately reflected every error
in
the code.

Ten years later, I was asked to give a talk at a local college about
professional
programming. One student asked me about flowcharts. I pointed out that
I
hadn't done one
in at least seven years, and that they were an intellectual crutch that
rarely had any
value, and they were largely a waste of time and effort beyond your
first
year of
programming. This so thoroughly pissed off the professor, who treated
flowcharts as a
religious experience, that I was pointedly never invited back. But I
can
now say that I
haven't done a flowchart, except some high-level decision trees for
teaching, in about
four decades. I see UML as being the modern substitute for flowcharts.

Last year someone sent me a question about one of the programs on my Web
site. He wanted
the DFDs. I had no idea what a DFD was. I had to do a google search.
It
turns out it
was a flowchart. I explained that I would not waste time writing one of
these for a
trivial 15,000-line program, and for larger programs (those in the range
of
100,000-200,000 lines) there was no point in wasting time with them
because of the large
scale. My message: they're useless for small programs, and they're
useless for large
programs, so what good are they, exactly?

What really matter are data structure diagrams to show the relationships
of the
information. This is ultimately the only thing that matters.
Flowcharts
don't help
because they describe process, not information. But I got a program
back
after five
years, and it was full of "ASCII art" of the data structures; without
that, I could not
possibly have added all the new features they wanted.

UML, at least the forms I've seen, define either high-level dataflow
diagrams (not overly
useful for programming) or pretend to do detailed analysis...in one
case,
analyzing the 18
possible states of the state machine (we came up with around 40 states
necessary to
represent the problem, but since they'd analyzed "all possible states"
the
code handled
them perfectly. All the bugs were in the states they didn't analyze!
But
since there
were UML diagrams everyone knew the code was perfect...)

Well-designed and well-implemented code usually doesn't need UML
diagrams
(which we tend
to refer to as "software voodoo")
****
... all the class he does implement should be
covered somewhere..

For my part, I also like controling all the
graphical resource ID numbers defined in
a project, and their naming, at all time
during the implementation.

It might be surprising, but I also avoid the
use of warning popup, and never use
Try and Catch method. I try to build
applications to stay up and running all
the possible time.
*****
Designing apps that never use popups is an interesting challenge, and
I've
done it a
couple times. Alas, the file dialog, which in an intelligent world
would
be an ActiveX
control embedded in a dialog, is a real pain. I should be able to do
any
of the "standard
dialogs" just by embedding the associated control in whatever window you
want. I had to
create my own file dialog, a real pain to get right. I made it a tabbed
dialog page in
the master program.
****

I highly prefer using a Logger in my framework,
(all situation should be handle), along with a
good Tracer that can be unlock to catch
problems in the field later, if any still undiscovered
during the test phase.
****
Take a look at my Logging ListBox control ... it appears in every
serious
app I write.
****

.. At least.. Uncommented code might be
a very good hint about that outsource!

jmarc..


"telepet9" <telepet9@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:32AD356D-F048-4798-9CF6-DA5709CCD092@xxxxxxxxxxxxxxxx
Hi,
I need to review code from our outsourcing.
I have some experience with MFC but not to the extant that I can
easilly
identify potential problems.
So, can you give me some pointers on what from your experience should
be
avoided while programming using MFC. ( We trying to make the
outsourcing
to
provide us code that will be easy to maintain/debug )
Thank you in advance.

Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.

Relevant Pages

  • Re: mfc pitfalls
    ... In most MFC apps, you are writing code in that kind ... virtual methods usually work better than callbacks for most ... no syntax in the design for function pointers. ... programming in OO environment requires new ...
    (microsoft.public.vc.mfc)
  • Re: nested include and preprocessor issues
    ... I have never had to have a dialog have a pointer to a parent class, after a decade of MFC ... When I was programming without MFC, a dialog knew nothing about any variables ... >The variables holding this information are in my CDialog and how can I save ... >Here is the design of my app ...
    (microsoft.public.vc.mfc)
  • Re: mfc pitfalls
    ... There are design criteria, ... Data flow (flowcharts) is one of the UML diagrams ... programming in OO environment requires new ...
    (microsoft.public.vc.mfc)
  • The most popular A- Z, CAx, CAD, CAM, CAE, electronics, EDA, LSI, PCB, FPGA, VHDL, & Other D
    ... Nauticus Early Design ... programming of sheet metal cutting and punching machines. ... Lantek Expert II.1 Lantek Expert Cut Oxifuel/Plasma ... Rockwell Allen Bradley Programming Software, RSLogix 5, RSLogix 500, ...
    (alt.fan.harry-potter)
  • Re: OT- building a lightwave website
    ... Im assuming that you are more of the design angle. ... Programming isnt SUPPOSED to mean anything to you! ... ps..all that slicing in photoshop, ... figure out how to convert it into a website. ...
    (comp.graphics.apps.lightwave)