Re: What MFC Objects Can't be created on the Stack?

One thing Microsoft has not been very good about is quality of documentation. When I was
writing Win32 Programming, I found hundreds of bugs in the low-level API; the MFC
documentation isn't any more detailed than the API documentation. So you have to realize
that the high level reflects the low level.

I've worked on a couple projects that required truly complete documentation. It cost far
more to produce the documentation than to produce the code. How detailed should the
documentation be? For example, should it include performance data or not? Should it
describe every boundary condition situation? Should it explain what happens in periods of
resource shortage? Should it specify precise resource consumption? And will all of this
have to be updated on the next release of the product?

While you don't "need" the source, you have been asking a lot of questions that are
answered by the source. However, they are also answered in the documentation, if you know
where to look. One of the problems is that there are insufficient cross-links from the
methods to the discussion of what is going on. So often the source is the most direct
answer.
joe

On Tue, 8 Aug 2006 10:37:10 -0500, "Peter Olcott" <olcott@xxxxxxx> wrote:


"Ajay Kalra" <ajaykalra@xxxxxxxxx> wrote in message
news:1155050506.203374.128880@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Except that this violates the most fundamental precept of good software
engineering. The contents of the black box should always be irrelevant. If
you
have to understand the internals of the black box productivity drops ten-fold
or
more.

You dont need to look at the source. Its your choice. You can go over
the tutorials and develop your apps. It helps to have source for most
to have a better understanding, but its not a requirement, especially
for beginners.

My point was that if it was designed optimally it should not help to have the
source. If it does help to have the source then the design is not nearly as
transparent as it should be.


---
Ajay


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

Relevant Pages

  • Re: Documentation
    ... use noweb (a lit programming tool). ... Like like to have documentation at both levels. ... and don't like to put high level stuff in the comments ...
    (comp.lang.lisp)
  • Re: Do you have a Knowledge Officer?
    ... completed with no time allotted to update documentation. ... Every line of code can be traced back through a Detailed Design and High Level ... test results all the way to a User Acceptance Test. ...
    (comp.lang.cobol)
  • Re: New to MuPad
    ... The issue is that although a high level overview of the ... are given in the standard library documentation. ... Prev by Date: ...
    (sci.math.symbolic)
  • Re: New to MuPad
    ... I become overwelmed when I look at the documentation of them. ... The issue is that although a high level overview of the ... Other than that, I'd certainly be glad to try and answer specific questions, but a general introduction beyond the Axioms, Categories, and Domains paper I do not currently have. ... Christopher Creutzig. ...
    (sci.math.symbolic)
Quantcast