peterchen - Professional Profile

extern "C" _InterlockedIncrement(LPLONG lpAddend);
extern "C" _InterlockedDecrement(LPLONG lpAddend);
 
#pragma intrinsic(_InterlockedIncrement, _InterlockedDecrement)

As response to a question how to learn C++ and become a "pro", "not only using DOS commands, but also MFC"

The following is a roadmap to "Mastering C++" - how I would teach it.
Some people might want to reorder the list which is fine with me - it all
depends on the teacher and the tools.

Chapter (I) Learning the language

1. basic language: type system, control structures, functions, scope.
2. basic concepts: programming style, structuring your program using
   functions, the difference between contract, declaration and implementation
3. language: pointers.
   
   pointer arithmetic, referencing, dereferencing, pointers vs. references,
   pointer to pointer, adress of pointer, allocating raw memory, etc.
   
   If you didn't succeed with (3): learn pointers
   
   If you don't get it the third time, give up. Really. I am serious.*
4. debugging. assert, trace, using a debugger, distrusting yourself,
   acquiring some programming style.
5. language: Function overloading.
6. language: classes. Member functions, constructor, destructor
7. concepts: encapsulation, simple object design, encapsulating state
8. lanuage: learn exceptions ^**
9. repeat concepts: good programming style, contract vs. declaration
   vs. implementation
10. concepts: inheritance, polymorphy
11. concepts: "enhanced" object design with the new knowledge
    (exceptions and polymorphy)
12. language: some refined points
    
    const-correctness, default constructor, copy constructor vs. assignment
    operator, how to make a class behave like a built in type (but skip operator
    overloading)
13. language: templates: function templates, class templates, template
    specialization,
14. get an introduction on the STL (standard template library, which
    makes the biggest part of the C++ run time library)
15. language: ok, now, just as sugar, operator overloading, and how to
    make types truly act like built-ins
16. libraries: refine your knowledge on the STL
    
     

NOW you are ready to leave the console window

Chapter (II) ...but also MFC

1. Windows API basics: This helps understanding some of the
   mumbo-jumbo and awkwardnesses in the MFC much better
   
   Event Driven Programming, Windows, Window Handles, Window Messages
   
   (you can omit *creating* windows here, since this is a painful task made much
   easier by frameworks - but the rest is important to understand and makes
   working with the MFC easier).
   
   GDI, standard controls etc.
2. Do the MFC "Scribble" tutorial, just following the main path (up to
   "printing" or so). Don't try to understand everything, just get a feeling for
   the "flow".
3. Do the "Scribble" tutorial again, this time exploring the background
   explanations etc.
   
    

Chapter (II) Become a Pro

1. Notice that, once you are here, you are the last remaining person on earth
   doing MFC
2. Learn enhanced concepts: Exception Safety, Patterns etc. and all the fine
   parts I have forgotten above
3. Learn "Industry Power" stuff: Automated Tests, Version Control,
   Finalizing, and everything that belongs to running a larger project.

<b>Warning:</b> this course is a pain. In the ass, in the back, in your
fingers, everywhere. Yet, it's IMO one of the shorter routes to a pro. To be
true, you could start with th MFC stuff pretty much after (I)-(j), but this
makes you only half-a-programmer, and you might acquire some misfeats that are
hard to get rid of later.



The order of the list itself clearly shows some drawbacks of the C++ language,
namely, the position of exceptions, and especially the STLBoth are standard
tools that should be introduced much earlier, but require good understanding of
the basic language features.





*) I pretty much agree with the thought that understanding pointers
needs a certain "wiring" of the brain. All other stuff in C++ can be learned
by a decently intelligent person. Pointers are different, you either get them,
or you don't. If you can't do pointers, C++ will be a pain all the
time.



**) that's really late, to late. They are an important tool for error
handling - and people should learn it as early as possible. However, it
doesn't make much sense wihtout a good grasp on scope and code flow. I would
do exceptions right after (b), but books/courses don't do it without classes.

// ---- .h  -------
// when this header is included from a .cpp file, you have both the C++ and C API available
// including from a .c file gives you the C API only
// C++ API declarations
#ifdef __cplusplus   // compiled as C++ ==>
class CFoo 
{
  public:
    int Foo() { return ... };
    static CFoo * CreateInstance() { return new CFoo; }
};
 
#endif               // <== compiled as C++

// C API declarations
#ifdef __cplusplus   
extern "C" { // when compiling with C++, we explicitely say this has "C" linkage ==> 
#endif
void * FooCreate();
int FoFoo(void *);
#ifdef __cplusplus
} // extern "C"  // <== C linkage ends here 

#endif
 
// ---- .cpp ----------
// this file implements both the C++ and C API
// normal C++ implementation - in this example nothing, cause it's all in the header

// Now, implementing the functions with C linkage
// note that, though the functions are declared "extern "C", you can call C++ stuff
extern "C" void * FooCreate() { return (void *) CFoo::CreateInstance(); }
extern "C" int FooFoo(void * f) { return ((CFoo *)f)->Foo(); }