Fed up with the problems involved in writing operators new, I suggested
that a type storage_for<Foo>, representing uninitialized storage
suitable for Foo, would ease the difficulties.

I wrote:
> There would be implicit conversions from Foo* to storage_for<Foo>*
> and from Foo& to storage_for<Foo>&; these could be reversed with a
> static_cast.

Salters <salters@lucent.com> objected:
> Not only do the static_casts break invariants, but the implicit
> conversions would do that, too. The invariant broken is that
> Foo* may point to memory that no longer is a Foo. What happens
> with void f(storage_for<Foo> * arg1)? It could conceivably clobber
> arg1 (Imagine what happens if new(arg1) throws).

You're right; in that, for example, this code:

    void f( storage_for<Foo> *arg1 )
       {
        new (arg1) Foo(17);
       }

    void g()
       {
        Foo x( 12 );
        f( &x );
       }

The destructor of x is not called before the new-expression ends
its lifetime.  While unusual, this is defined behavior (see 3.8,
[basic.life]).

The same defined behavior happens in this function:

    void f( Foo *arg1 )
      {
       new (arg1) Foo(17);
      }

On the other hand, while this unfortunate function is legal:

    void f( Foo *arg1 )
      {
       new (arg1) int(17);
      }

under my proposal, this function would produce a compile-time error:

    void f( storage_for<Foo> *arg1 )
      {
       new (arg1) int(17);
      }

So I don't see how invariants are harmed by the introduction
of storage_for.  The language already leaves lifetime management
to the programmer when placement new and explicit destructors
are used.

                                                --Lisa Lippincott


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Lisa Lippincott wrote:
>
> Fed up with the problems involved in writing operators new, I suggested
> that a type storage_for<Foo>, representing uninitialized storage
> suitable for Foo, would ease the difficulties.

> I wrote:
> > There would be implicit conversions from Foo* to storage_for<Foo>*
> > and from Foo& to storage_for<Foo>&; these could be reversed with a
> > static_cast.

> Salters <salters@lucent.com> responded:
> > This would of course break type invariants. In C++, it is possible to
> > get memory with the properties demanded:

> > Foo *foo = new foo;
> > storage_Foo* = (~(*foo),foo);

> Well, yes, the static_casts would break type invariants; that's what
> casting does.  The implicit conversions wouldn't break any invariants,
> since the only invariant of storage_for<Foo> is "you can allocate
> a Foo there using placement new."

Not only do the static_casts break invariants, but the implicit
conversions would do that, too. The invariant broken is that
Foo* may point to memory that no longer is a Foo. What happens
with void f(storage_for<Foo> * arg1)? It could conceivably clobber
arg1 (Imagine what happens if new(arg1) throws). Now, if this is
an implicit conversion we could call f like f(&myFoo), and end up
with a broken myFoo. The invariant established by the constructor
exists until the destructor is called, which is why my solution is
valid. You can't demand that the destuctor is called as part of
the implicit conversion.

> And while you can get suitable unitialized storage by constructing
> and then explicitly destroying an object of type Foo (which I assume
> is what you meant to write), that hardly seems like an efficient way
> to go about it.

Efficient, not really. But it is allowed. Usually, you will operate
on *foo, before recycling the memory. If so, the efficieny is no
concern. The question is here, how much can you change in Foo?
That heavily influences what you should do.

Michiel Salters


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Fed up with the problems involved in writing operators new, I suggested
that a type storage_for<Foo>, representing uninitialized storage
suitable for Foo, would ease the difficulties.

I wrote:
> There would be implicit conversions from Foo* to storage_for<Foo>*
> and from Foo& to storage_for<Foo>&; these could be reversed with a
> static_cast.

Salters <salters@lucent.com> responded:
> This would of course break type invariants. In C++, it is possible to
> get memory with the properties demanded:
>
> Foo *foo = new foo;
> storage_Foo* = (~(*foo),foo);

Well, yes, the static_casts would break type invariants; that's what
casting does.  The implicit conversions wouldn't break any invariants,
since the only invariant of storage_for<Foo> is "you can allocate
a Foo there using placement new."

And while you can get suitable unitialized storage by constructing
and then explicitly destroying an object of type Foo (which I assume
is what you meant to write), that hardly seems like an efficient way
to go about it.

Bubt I didn't explain how the static_casts would be useful.  Apart
from maintaining the definition "standard conversions can be (mostly)
reversed by static_casts," judicious use would allow one to build
type-safe classes which act like

         arrays of objects which are not default-constructed, and

         discriminated unions of objects which have constructors
         and destructors.

Currently, neither of these is possible in C++ without using dynamic
allocation.  (They're possible in C because C doesn't distinguish
between initialized and uninitialized memory.)  If anyone wants me
to post code for these classes, let me know.


I wrote:
> Placement and member operators new would be allowed to return
> storage_for<Foo>* rather than void*...

Salters replied:
> Placement new should of course not return uninitialized memory, did
> you mean "take as an argument"?

I think we're running into the usual new-terminology problem.  All
operators new should return pointers to uninitialized memory; no
new-expressions should return pointers to uninitialized memory.


I wrote:
> For general purpose allocation, there's the thornier problem of
> "storage suitably aligned for any type."  I'll leave that for another
> day.

Salters asked:
> Isn't that guaranteed for the retrun of new char [sizeof(AnyType)] ?

Yes it is.  But as the standard stands, any operator new that I write
must return a pointer to storage suitably aligned for any type.  The
only pointers that the standard guarantees will be so aligned are
the ones returned from the built-in operators new or malloc/calloc.
That makes it difficult to write a nontrivial portable operator new.

This problem even arises with the built-in placement new operator,
and it's about as simple as you can get.  If you pass in a pointer
which isn't aligned for any type, it will violate paragraph 2 of 3.7.3.1
[basic.stc.dynamic.allocation].

                                                   --Lisa Lippincott


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 13 Aug 99 17:25:27 GMT, Valentin Bonnard
<Bonnard.V@wanadoo.fr> wrote:

>> #define NEW new (dmalloc, __FILE__, __LINE__)
>> #define new NEW
>
>A lengthy way to write:
>
>#define new new (dmalloc, __FILE__, __LINE__)
>
>which shows that he doesn't even understand the
>preprocessor.

I guess I don't understand the preprocessor either.  I thought
that these were different.  Could you please point out where in
the standard it says that the second defines the macro NEW?

The first allows one to #undef new and still use the debugging
version as NEW.  The second does not.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Lisa Lippincott wrote:
>
> blargg <postmast.root.admi.gov@iname.com> wrote:
> > With constructors and destructors, simply allocating memory and saying
> > "this memory is now a Foo" with a simple cast was not enough. Also, the
> > type hole (void* to anything) was there. Operator new filled this hole,
> > and allowed a way to put an object into raw memory.
> Thereby triggering the following rant...
>
> While I'm quite fond of the way constructors and destructors work, C
> does have a facility that C++ lost in this transition.  In C, we have a
> name for "uninitialized storage suitable for Foo" -- we call it "Foo."

Which works because C structs do not really support invariants. You can't
have all data private.

> Whenever I've gotten down to the level of writing operators new, I've
> been disappointed with C++'s limitations in dealing with uninitialized
> storage.  In particular, I've often wished for a type storage_for<Foo>
> to fill this gap.

> Here's how it would work: storage_for<Foo> would have the same size and
> alignment as Foo.  It would have public default and copy constructors,
> a copy assignment operator, and a destructor, none of which have any
> effect.

> There would be implicit conversions from Foo* to storage_for<Foo>*
> and from Foo& to storage_for<Foo>&; these could be reversed with a
> static_cast.

This would of course break type invariants. In C++, it is possible to
get memory with the properties demanded:

Foo *foo = new foo;
storage_Foo* = (~(*foo),foo);

because the destuctors puts the object in a state where no invariant
needs to be maintained, so the memory can be used as raw memory with
the correct alignment. Of course, the only sensible thing we can do
with foo is to put a Foo back there. We do not really know if the
alignment of foo is suitable for anything else but chars (I'm not 100%
sure about this, though)

> Placement and member operators new would be allowed to return
> storage_for<Foo>* rather than void*; such operators could only be used
> to allocate objects of exact type Foo, and (unlike ordinary allocation
> functions) need only return storage suitably aligned for Foo.

Placement new should of course not return uninitialized memory, did
you mean "take as an argument"?

> I think that this change would make working with type-specific allocation
> both easier and safer.  For general purpose allocation, there's the
> thornier problem of "storage suitably aligned for any type."  I'll
> leave that for another day.

Isn't that guaranteed for the retrun of new char [sizeof(AnyType)] ?

Michiel Salters


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

William H. Bloodworth wrote:

> Hello,

> Would anyone (Bjarne preferably) care to comment the information presented on C++ memory
> allocation at this location:  http://www.pdos.lcs.mit.edu/~dm/c++-new.html ?

> Thank you,

> William Bloodworth

The author isn't familiar enough with C++ to pass judgement:

"Except for automatic variables, operator new is the only way
 to call an object's constructor in C++. "

Wrong. The trivial omission is that he missed globals, the more
serious problem is that he does not know the difference between
operator new and a new-expression. Being unaware of the
distinction makes judging "new" (operator new or new-expression?)
seem ludicrous.

Further on, he describes a memory arena, basically an allocator
that will free all allocated memory at destruction. He then
"proves" that it is not necessary to call delete. Again, that
delete calls destructors, besides freeing memory is lost on him.
The fact that these arena's are by design unsuited for C++ is
in no way I can see a disadvantage of C++, rather they are a problem
of the designer of the arena. It is possible to write bad code
in any language.

Clearly knowing of the existence of placement new, he then tackles
the problem of casting the void* return of malloc to a T* with the
use of macros. This is of course the correct use of placment new,
which does not have the disadvantages his solution has.

After going to great lengths to show what problems placement new
causes when applied to the wrong places, he then shows what problems
occur when placement new is not applied in the right places. Again,
this can't be taken as a critique of C++.

Of course, the author continues his rant by showing the problems
macros introduce in C++. Actually, he shows the problems by showing
the problems introduced when trying to roll your own debugging macros
when you are not familiar with the language.

After defining

#define NEW new (dmalloc, __FILE__, __LINE__)
#define new NEW

class bar {
  /* ... */
 public:
  void *opreator new (size_t);
  void operator delete (void *, size_t);
  /* ... */
};

void
f ()
{
  bar *bp = new bar;
  delete bp;
}

he complains that the "new bar " expands to something like
new (dmalloc, "sodifficult.cpp",23) bar, which he claims
calls the global new. Clearly, he has not compiled this code,
with the typo in operator new. Furthermore, he also didn't
think what happens to the new keyword in class bar. Furthermore,
he should know better than to redefine "new" using macros.

He then tries to show how smart he is by adding a function New that
does not offer "disadvantages". Never mind the fact that the debug
new he proposed also fails for his example.

He shows of his wits by trying to enumerate all built-in types. Even
for someone only knowing C, this idea is ridiculous. He missed all
pointers, int*, int**, int***, etc. Having missed an infinite number
of simple types, he then proceeds to show another example of his
approach: you can't allocate arrays of non-simple types.

Since he "needs" the debug support his simple macro did not give
him, he now adds a macro which should give him debugging information.
However, this shows the problem with his approach. He allows for other
memory allocation schemes then the one he provided, yet they do need
to derive from one of his classes. Compare that to operator new;
that is not restricted in this way.

The most critical oversight is that the authos seems to be unaware of
the Standard Library, in particulat container allocators.

Moral of the story

When a programing language doesn't seem to support some necessary operation,
one shouldn't simply add new function for that specific operation.
Instead, one should ask, "How can I learn the language better so
I don't have to kludge around?" The answer may be a much simpler, cleaner,
and more powerful set of mechanisms than the one tailored for a specific
problem.

C++ needed a way to perform type-safe memory allocation. Such a scheme could not
have been implemented entirely as a library function, certainly not without
incurring
run-time penalties. Most certainly, such solutions would also invalidate
invariants,
set up by constructors.  Support for this would in any way complicate compilers,
with
little or no tangible benefits. Any solution chosen would  focus on cooperation
with
standard containers - as current allocator schemes do.

Instead, David Mazieres introduced a macro New, a disgusting piece of macro
trickery,
with a syntax inadequate for the job, which suffers from many problem, not the
least
of which that it does not work. It also does not offer placement syntax, or
cooperation
with C++'s exception scheme.

The design of operator new shows insight in C++, thoughtful consideration and a
lot of effort
The design of macro New shows a lack of insight in, and limited use of C++,
combined
with no knowledge of fundamental OO concepts like class invariants.

No contest.

Michiel Salters
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Salters wrote:
>
> William H. Bloodworth wrote:

> > Would anyone (Bjarne preferably) care to comment the information presented on C++ memory
> > allocation at this location:  http://www.pdos.lcs.mit.edu/~dm/c++-new.html ?

> The author isn't familiar enough with C++ to pass judgement:

Congratulation ! You have apparently been able to read this
text up to the end. (I haven't.)

> "Except for automatic variables, operator new is the only way
>  to call an object's constructor in C++. "
>
> Wrong. The trivial omission is that he missed globals,

and temporaries created explicitly (ex T (1, "a")),
ctor-init-member-list...

> #define NEW new (dmalloc, __FILE__, __LINE__)
> #define new NEW

A lengthy way to write:

#define new new (dmalloc, __FILE__, __LINE__)

which shows that he doesn't even understand the
preprocessor.

> No contest.

I strongly advise that Bjarne do _not_ loose time on
this rant, except perhaps for fun.

When reading such ``why C++ is bad'' descriptions,
I often^Walways discover that the author doesn't have
any clue about C++, how to use it, that it has evolved
since the ARM. It's funny, because there are possible
critics against C++ but I never see them anywhere.

--

Valentin Bonnard
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <37b445e8.82613572@news.airmail.net>, whbloodworth@usa.net wrote:

> Hello,
>
> Would anyone (Bjarne preferably) care to comment the information
presented on C++ memory
> allocation at this location:  http://www.pdos.lcs.mit.edu/~dm/c++-new.html ?

I think it's best summed up at the end:

> Moral of the story
>
> When a programing language doesn't support some necessary operation, one
> shouldn't simply add new syntax for that specific operation. Instead, one
> should ask, "How can I ammend the language to make this operation
> implementable in a standard library?" The answer may be a much simpler,
> cleaner, and more powerful set of mechanisms than the one tailored for a
> specific problem.

And when one is criticizing a feature of a language, they shouldn't ask
"What would have been the ideal choice, given no constraints?". Instead,
they should study its history and learn from it.

> C++ needed a way to perform type-safe memory allocation. Such a scheme
> could have been implemented entirely as a library function, given the
> right support. Such support might have included ways to infer whether
> classes have destructors at compile time, support for calling constructors
> directly and even taking their addresses, and more. These features might
> even have been useful in more contexts than memory allocation.

I think new and delete were added very early in the language. At that
time, I don't think there were the funds (people, money) to add these
ambitious features. Would you rather have had that attempted on C++ then
and have it not exist today (because it was too complex, and lead to more
complexities that killed the language)?

> Instead, Stroustrup introduced operator new, a disgusting piece of syntax
> inadequate for the job. After many complaints, new's functionality was
> finally extended to include per-class operator new[] and placement new,
> still an imperfect solution.

How I see it, this all centers around a feature that was added to the
language for type-safety: constructors (and destructors). Technically it
was also needed for setting up the vtable, but that isn't the main issue.
With constructors and destructors, simply allocating memory and saying
"this memory is now a Foo" with a simple cast was not enough. Also, the
type hole (void* to anything) was there. Operator new filled this hole,
and allowed a way to put an object into raw memory.

If you don't want to use this feature, then you don't have to (except for
correctly placing objects to insure their vtable is set up).

Perhaps it could have been done better if templates and exceptions existed
at the time, but there are lots of things in C++ that could be done
better. It would be nice if we had all the time in the world (and then
some) for every decision, had all the funds we needed to try all possible
choices, and didn't have to worry about compatibility (responsibility). I
admire C++ for finding a good balance between this idealistic place and
practical programming.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Valentin Bonnard wrote:
>
> > #define NEW new (dmalloc, __FILE__, __LINE__)
> > #define new NEW
>
> A lengthy way to write:
>
> #define new new (dmalloc, __FILE__, __LINE__)
>
> which shows that he doesn't even understand the
> preprocessor.
>

He's probably been reading Microsoft's headers -- that's one of the
dirty tricks that MFC uses.

--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

blargg <postmast.root.admi.gov@iname.com> wrote:
> With constructors and destructors, simply allocating memory and saying
> "this memory is now a Foo" with a simple cast was not enough. Also, the
> type hole (void* to anything) was there. Operator new filled this hole,
> and allowed a way to put an object into raw memory.
Thereby triggering the following rant...

While I'm quite fond of the way constructors and destructors work, C
does have a facility that C++ lost in this transition.  In C, we have a
name for "uninitialized storage suitable for Foo" -- we call it "Foo."

Whenever I've gotten down to the level of writing operators new, I've
been disappointed with C++'s limitations in dealing with uninitialized
storage.  In particular, I've often wished for a type storage_for<Foo>
to fill this gap.

Here's how it would work: storage_for<Foo> would have the same size and
alignment as Foo.  It would have public default and copy constructors,
a copy assignment operator, and a destructor, none of which have any
effect.

There would be implicit conversions from Foo* to storage_for<Foo>*
and from Foo& to storage_for<Foo>&; these could be reversed with a
static_cast.

Placement and member operators new would be allowed to return
storage_for<Foo>* rather than void*; such operators could only be used
to allocate objects of exact type Foo, and (unlike ordinary allocation
functions) need only return storage suitably aligned for Foo.

Placement and member operators delete would be required to take a
parameter of storage_for<Foo>* rather than void* if the corresponding
operator new returns storage_for<Foo>*.  I think that all instances
of using such an operator to deallocate an object that does not have
exact type Foo could be caught at compile time.

Finally, these function templates would be added to <memory>:

   template < typename T >
   storage_for<T> *operator new( size_t, storage_for<T> *p ) throw()
      { return p; }

   template < typename T >
   void operator delete( storage_for<T> *, storage_for<T> * ) throw()
      {}

I think that this change would make working with type-specific allocation
both easier and safer.  For general purpose allocation, there's the
thornier problem of "storage suitably aligned for any type."  I'll
leave that for another day.

                                                --Lisa Lippincott
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <newscache$13cegf$tti$1@firewall.thermoteknix.co.uk>, "Ken
Hagan" <K.Hagan@thermoteknix.co.uk> wrote:

> Certainly. The author appears to understand why C++ does things
> differently.

At first it seemed that he was unfamiliar with C++, but after seeing all
the template stuff, I at least could tell that he had some familiarity
with the language, though obviously not enough common sense :-)

> However, he believes that type safety isn't important and
> that you can't build a debugging allocator in C++.

In his comment about void*:

>> Such implicit casts were probably viewed as a hole in the type system.

"viewed as a hole" as if he doesn't view this as a hole in the type
system. Holes in the type system are ways of violating the type system
without being explicit (i.e. a cast). void* to any pointer type certainly
seems to be a hole to me!

>> In
>> general, Stroustrup deprecates any use void * for something other than
>> "low-level software," because he feels that with C++'s protection
>> mechanisms all pointers should be typed.

"he feels" C++ is statically typed. Foo* -> void* is safe. The other way
around isn't. There is nothing wrong with an untyped pointer (void*), and
it is certainly allowed in C++. How could you have a truely untyped
pointer? If it's untyped, how can it have a type (a pointer)? :-)   And
how would that be different than void*? Would you be able to dereference
it, and have the compiler read your mind as to what type for that to
resolve to? heh

> The first is at very
> least, contentious. The second is definitely false.

Well, the debugging allocator also doesn't necessarily provide all the
information you need anyway!

    void f( void* p ) {
        free( p );
    }

f is called throughout the software system. We have a double free in f (as
provided by our debugging free). Oops, all we know is that we are in f.
Useless. We need a stack trace. System-specific. Doesn't need any language
support (just debugger support).

Anyway, in C++, we wouldn't likely be using bare pointers to anything (for
ownership, that is). We are most likely using smart pointers, making
memory leaks very rare.

> He concludes with
> a wish that the tight binding between new and constructor invocation
> should be broken. Presumably none of his classes have significant
> invariants, or internal state.

In most of those cases, the things he wanted to achieve could be
implemented with a simple helper function. i.e.

    new (arena) Foo( arena );

    Foo* new_Foo( Arena& arena ) {
        return new (arena) Foo( arena );
    }

He seems to want yet another feature added that allows some sort of common
arguments that are given to both operator new and the constructor.

He says that if an object is allocated in an arena, it can't allocate any
of its own freestore objects in the arena, since it doesn't know about it.
This is a general issue, and can be solved in many ways. One is to have a
"current pool" that is set globally. Another is to have some sort of
lookup mechanism that allows objects to be allocated in the same pool (and
even near the same memory) as some other object.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hello,

Would anyone (Bjarne preferably) care to comment the information presented on C++ memory
allocation at this location:  http://www.pdos.lcs.mit.edu/~dm/c++-new.html ?

Thank you,

William Bloodworth

=====================================================================
= Great Achievement REQUIRES Great Effort.
=
= William H. Bloodworth - whbloodworth@usa."net"        ICQ: 21901934
=
= Software Engineer && "Acting" Consultant Manager - The Maxim Group
=====================================================================
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Certainly. The author appears to understand why C++ does things
differently. However, he believes that type safety isn't important and
that you can't build a debugging allocator in C++. The first is at very
least, contentious. The second is definitely false. He concludes with
a wish that the tight binding between new and constructor invocation
should be broken. Presumably none of his classes have significant
invariants, or internal state.

My guess is that this was written by a student who hasn't done any
real programming yet.

William H. Bloodworth wrote in message
<37b445e8.82613572@news.airmail.net>...
>Hello,
>
>Would anyone (Bjarne preferably) care to comment the information presented
on C++ memory
>allocation at this location:  http://www.pdos.lcs.mit.edu/~dm/c++-new.html
?
>
>Thank you,
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]