🚀 go-pugleaf

I'm in violent agreement when someone says arrays are lowlevel and
that their use should be discouraged. I'm certainly not talking about
making a change in the language just so that array objects could be
constructed differently. That wouldn't even be the last item in the
list of things I'd like to see in C++. 

>>>>> On 04 Dec 1995 22:38:45 GMT, martelli@cadlab.it (Alex Martelli)
said:

    Alex> Well, there's an old Usenet saying, known as Ugol's Law, that
    Alex> goes something like "If you ask if you're the only one -- you
    Alex> aren't".  But the fact that others feel like you does not imply,
    Alex> of necessity, that it makes sense:-).  Note, for example, how
    Alex> horribly having a link between placement-expression and ctor
    Alex> would work in the normal usage case that I outline above, where
    Alex> I have to use placement new over already-allocated memory (the
    Alex> normal kind, taking a void*) BUT I have to tell the object to
    Alex> use another allocator (the one that was originally used to
    Alex> get the raw-memory, in a *different* point from the placement
    Alex> expression I'm now using) for its own allocation purposes...!

Well... Doing non-default construction on a per-object basis for
arrays is ugly by itself. So, to me, this doesn't seem like a good
argument against implicit arguments being passed to constructors.

Let me rewind a li'l bit. 

Why was this syntax invented?

	X* ptr = new (allocator) X;

Because

	void* raw = allocator.alloc(sizeof(X)); 
	X* ptr = new (raw) X;

is clumsy (error prone?). 

(I find the former easier to read/write. But I'm not very sure if it
is just a question of one line vs two lines. I'd like to know what
y'all think about the importance of support for the former.)

If `X' does allocation for its members then there is no language
supported way for `X' to get the allocator. IMHO, that doesn't sound
too good.

1. It is none of the users' business to even think about how the
   constructor allocates memory (or whatever) for its members. 
2. He has already said where the object has to be allocated. 

(Things like:

	data_member_ptr = allocator_map[this]->alloc(...);

are not portable and might (I'm not sure) not be thread safe, 'cos
least of all the allocator_map has to be a global variable. Mr Paul
Wilson was talking about this kinda stuff.)

There is atleast one important advantage that I can see to having
support for this:

	X::X(implicit Allocator& al = nullAllocator, int args)
              // `implicit' is a new keyword ;-)
              // could be replaced by `from_new' or some such. 
           {
           }              

	X* xptr = new (allocator) X(5); // `allocator' becomes implicit
                                        // argument to constructor

	X xobject(5); // `nullAllocator' becomes implicit argument to
                      // constructor, indicating to the constructor
                      // that the object is not allocated on the
                      // heap. 

	X* xptr = new X(5); // `defaultSystemAllocator' becomes implicit
                            // argument to the constructor. 

This way, an object gets to know more about how it was created--
dynamic or on stack. That could give the object a chance to do
somethings more efficiently.

Without support for such implicit arguments, any class that follows
this kind of an allocation paradigm ( new (allocator) X(allocator); )
automatically outlaws itself from array support. 

Wouldn't this be a useful thing? Wouldn't this be a decent scheme--
simple to implement, orthogonal etc? I'm sure someone would've thought
about it and discarded it. I want to know WHY! 

TIA for digging into this with me. 



-- 
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. ]