🚀 go-pugleaf

>>>>> On 30 Nov 1995 17:09:36 GMT, dak <pierreba@poster.cae.ca> said:

    dak> B. Usage
    dak> --------

    dak> Usage of the new operators are multiples. The first is the possibility to
    dak> distinguish between stack-allocated, static-heap and dynamic-heap

Actually instead of adding to new, I'd be inclined to say we need
different ``constructor classes'' (maybe even ``destructor
classes''). That is, static constructors, automatic constructors and
dynamic constructors. One could even try cooking up a reasonable
subsumption relationship between the three to avoid breaking existing
code. 

For example,

	class A {
	public:
	 static A(int); // will be called for objects of A that 
                        // reside on .data (data segment)
	 automatic A(int); // will be called for objects of A that
                           // reside on stack segment
	 dynamic A(int); // will be called for objects of A that 
                         // are allocated using new. 

	};

(Oops that should be "auto" instead of "automatic"... never used it.) 

Combine this with `explicit' and it becomes `funny' :-)


    dak> variables.  Many programs need that capability, notably when related to
    dak> smart pointers and garbage collection. Another usage (the one which
    dak> prompted me to write this) would be in the context of OODBMS. The
    dak> ability to communicate with the server and take different actions depending
    dak> on the location of the variable can dramatically improve the performance
    dak> of some operations.

I believe that the (sort of) general case is one of letting an object
grab certain interesting things that were passed to new and stay
knowledgeable about them.

This would be possible if there were some "function signature prefix
matching" between all the arguments that were passed to new and a
constructor of that class whose first few arguments matched it:

	class A {
        public:
           A(int) { .. } // ordinary constructor
           A(Allocator* al, int) { .. } // allocated on some heap
        // ..
        };

Now, 

	A a(5); 

        // object `a' would know that it was allocated either on the
        // stack or .data or it was allocated using plain new. 


	class FancyHeap : public Allocator { ... };

	FancyHeap* heap = new FancyHeap(..);

	A* pa = new (heap) A(5); // this calls A::A(Allocator*, int)

	class ForeignHeap { ... };

	ForeignHeap* heap = new ForeignHeap(..);

	A* pa = new (heap) A(5); // error: heap does not match any
                                 // prefix argument in the constructor

The last example shows that a class can control what kind of heaps its
objects can be allocated in. 

Since that would break code and as a matter of fact, force root
classes (atleast for allocators and such), one could say, if there is
a match in the arguments passed to new and the first few arguments of
a constructor, then that would be called else the effect would be as
it is now. That would make the last example call the A::A(int)
constructor, without flagging a compile-time error. 

What happens if the new arguments match the constructor and there is a
mismatch in the actual constructor arguments? Ah... there's the
hornet's nest. 

I'm not trying to say this SHOULD be in the language or anything. But
I don't see why it shouldn't be :-) (The basic question: how would all
these things be possible without an extension?)

-- 
Peace.... +<:-)

Anil


---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]