🚀 go-pugleaf

Hi netters I'm having a slight portability problem which is this

class	base { /* stuff */ }
class	derv : public base { /* more stuff */ }

const	derv	array[2] = { { /* 0th element */ }, { /* 1st element */ } };

(I may have got this slightly wrong doing it from memory but, it is obvious
(I hope) that I'm trying to set up an array of constants) derv has the appropriate
constructor which uses a constructor in base) Now this all works fine with Borland C++
but when I try with DEC C++ (VAX/VMS) it fails, it seems that Borland gives me:

	for (i = 0; i < number_of_elements; i++) {
		derv(/* this = &array[i] */ /* constant stuff */);	// 'clever' constreuctor
	}
or equivalent done at compile time, DEC C++ does something more like:

	for (i = 0; i < number_of_elements; i++) {
		derv(/* this = &array[i]);			// default constructor
		derv(/* this = &temp */ /* constant stuff */);	// clever constructor
		derv(/* this = &array[i], */ temp);		// copy constructor
	}

I deduce this from the fact that if I make the default and copy constructors visible
(i.e. not private) the thing will compile. I also deduce that one of three things is
wrong:

	1)	I've done something silly and Borland C++ is just being kind to a moron
	2)	DEC C++ is stupid since it's method is not only much less efficient it also
		makes my code much more involved as each derv in my application gets immeadiately
		places on a queue somewhere so I have to destruct both the default constructed
		and temp ones or my queue has 3 * too many members
	3)	DEC C++ is right (i.e. doing what is to be expected) in which case the ARM is wrong
		since surely Borland is doing what one would expect? (Hence my post to comp.std.c++)

Anyone out there got an anwer?
		thanks Rod.