DM> MSVC 5 should be okay by now, I'd think.  Maybe if you were using
DM> version 1.3  or something I could see some issues, but even that ...
DM> I  was doing this stuff on MSVC 1.41 without issues.  At 
DM> least, not these issues :-)

You talked about only 16-bit compilers.  Is anybody still doing 16-bit 
development (other than some specialized, embedded systems)?

NH> class ClassB
NH> {
NH> private:
NH>    ClassAptr abc;

NH> public:
NH>    ClassB();
NH>    ClassB(ClassAptr);
NH> };

NH> #endif


NH> File:  b.cpp

NH> #include "ClassA.h"
NH> #include "ClassB.h"

NH> ClassB::ClassB()
NH> {
NH> }


NH> ClassB::ClassB( ClassAptr aaa )
NH> {
NH>    abc = aaa;
NH> }

DM> Again, nothing fundamentally wrong, but try:

DM> ClassB::ClassB( ClassAptr aaa ) :
DM>     abc(aaa)
DM> {
DM> }

I'm completely unfamiliar with this notation when used in a constructor.  
Does this mean that the programmer will ultimately be responsible for 
making a constructor specifically for this situation?

DM> A couple reasons: a) there are some anal-retentives on c.l.c++ who
DM> will flame  you for your style because b) this style is faster
DM> (fewer  runtime cycles).  The difference is that yours initialises 
DM> abc with the default constructor (which, for a pointer, is 
DM> a no-op, really) and then uses the assignment operator to 
DM> copy the pointer.  Mine will use the constructor that takes 
DM> ClassAptr as its parameter - initialise in a single step.  
DM> In practice, with built-in types (pointers, int, char, 
DM> etc), there's no difference, but you'll still get flames :->

NH> File:  test.cpp

NH> int  main()
NH> {
NH> }

DM> I don't see any fundamental differences between this (which 
DM> compiles) and the original (which doesn't).  I would then 
DM> have to make the awesome leap of logic that the problem is 
DM> rooted elsewhere ;->

Awesome? :->

þ CMPQwk 1.42 999

--- Maximus/2 3.01