fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes:

|>  >I can live with the status quo.
|>
|>  Sure, just don't redefine the global operator new!

I don't when I'm working at the customer site; he can afford Purify:-).

In fact, in my posting, I almost added a statement to the effect that of
course, the redefined global operator new is never used in deliverable
code, but only for test purposes.

(This isn't strictly true.  At one customer site, they had a performance
problem, and there were literally hundreds of classes allocating small,
fixed size blocks.  The correct solution would have been to fix all of
the classes, but they basically said that they wanted a miracle, and I
had a week to do it in.  I overloaded global operator new to catch the
special cases, and they got their miracle.  But I think that this is
more an argument against doing it in general; if the application had
required a special global operator new, I might not have been able to
perform the miracle.)

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

dacut@henry.ece.cmu.edu (David A. Cuthbert) writes:

|>  #include <malloc>
|>  #include <new>
|>  #include <iostream>
|>
|>  void *  operator new(size_t bytesReq) {
|>   cerr << "Requesting " << bytesReq << " bytes" << endl;
|>   return malloc(bytesReq);
|>  }

Generally speaking, I suspect that the above function will result in an
infinite recursion in most implementations, and I believe that it should
be illegal.  (No point in making things overly difficult for the
implementor without reason.)

Still, I'm curious to know what passage in the current draft makes it
illegal.  I'm not aware of one.

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

James Kanze  <james-albert.kanze@vx.cit.alcatel.fr> wrote:
>dacut@henry.ece.cmu.edu (David A. Cuthbert) writes:
>
>|>  #include <malloc>
>|>  #include <new>
>|>  #include <iostream>
>|>
>|>  void *  operator new(size_t bytesReq) {
>|>   cerr << "Requesting " << bytesReq << " bytes" << endl;
>|>   return malloc(bytesReq);
>|>  }
>
>Generally speaking, I suspect that the above function will result in an
>infinite recursion in most implementations, and I believe that it should
>be illegal.  (No point in making things overly difficult for the
>implementor without reason.)

I'll agree that it should be illegal, but it doesn't have to do with
infinite recursion.  It's just that cerr isn't initialized.  &cerr is
some random piece of memory at the first call.  Using cerr doesn't
allocate space for it, just as using any other object (global or
otherwise) doesn't allocate space for them.

>Still, I'm curious to know what passage in the current draft makes it
>illegal.  I'm not aware of one.

My guess would be something along the lines of not guaranteeing the
order of construction for global objects.  In fact, I can't think of a
way to make this legal; not even:

bool  cerrInitialized = false;

void *  operator new(size_t bytesReq) {
     if(cerrInitialized)
          cerr << "Requesting " << bytesReq << endl;
     return malloc(bytesReq);
}

int main() {
     cerrInitialized = true;
     ....
     cerrInitialized = false;
     return 0;
}

I wouldn't be surprised if this works.  It is certainly non-portable,
though.
--
David A. Cuthbert (henry.ece.cmu.edu!dacut)
Graduate Student, Electrical and Computer Engineering
Data Storage Systems Center, Carnegie Mellon University
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

James Kanze <james-albert.kanze@vx.cit.alcatel.fr> writes:

>dacut@henry.ece.cmu.edu (David A. Cuthbert) writes:
>
>|>  #include <malloc>
>|>  #include <new>
>|>  #include <iostream>
>|>
>|>  void *  operator new(size_t bytesReq) {
>|>   cerr << "Requesting " << bytesReq << " bytes" << endl;
>|>   return malloc(bytesReq);
>|>  }
>
>Generally speaking, I suspect that the above function will result in an
>infinite recursion in most implementations, and I believe that it should
>be illegal.  (No point in making things overly difficult for the
>implementor without reason.)
>
>Still, I'm curious to know what passage in the current draft makes it
>illegal.  I'm not aware of one.

The current draft does not make it "illegal".  However, the semantics
are not specified either.  The current draft does not specify whether
or not `operator <<' will call `operator new'.  Whether or not it does
depends on the implementation.  If it does, then the result will be
infinite recursion, and so you will probably overflow the resource
limits of the implementation, and then all bets are off.

Summary: the status quo in the DWP is fine.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes:

|>  James Kanze <james-albert.kanze@vx.cit.alcatel.fr> writes:
|>
|>  >dacut@henry.ece.cmu.edu (David A. Cuthbert) writes:
|>  >
|>  >|>  #include <malloc>
|>  >|>  #include <new>
|>  >|>  #include <iostream>
|>  >|>
|>  >|>  void *  operator new(size_t bytesReq) {
|>  >|>   cerr << "Requesting " << bytesReq << " bytes" << endl;
|>  >|>   return malloc(bytesReq);
|>  >|>  }
|>  >
|>  >Generally speaking, I suspect that the above function will result in an
|>  >infinite recursion in most implementations, and I believe that it should
|>  >be illegal.  (No point in making things overly difficult for the
|>  >implementor without reason.)
|>  >
|>  >Still, I'm curious to know what passage in the current draft makes it
|>  >illegal.  I'm not aware of one.
|>
|>  The current draft does not make it "illegal".  However, the semantics
|>  are not specified either.  The current draft does not specify whether
|>  or not `operator <<' will call `operator new'.  Whether or not it does
|>  depends on the implementation.  If it does, then the result will be
|>  infinite recursion, and so you will probably overflow the resource
|>  limits of the implementation, and then all bets are off.

OK.

If I interpret your statement correctly, you are saying that in the
absense of any specific words in the draft, an implementation is free to
use arbitrary library functions in its library implementation, except
when the draft specifically says otherwise (e.g.: malloc cannot use
operator new).

Thus, for example, the draft doesn't guarantee that memset won't call
operator new, so it is not specified whether a user defined operator new
which uses memset to initialize the allocated memory will work or not.
And the same reasoning you use for operator new applies to terminate, or
any other function the user can replace; are you saying that you are not
guaranteed to be able to use iostream in terminate or unexpected.

|>  Summary: the status quo in the DWP is fine.

Yes and no.  It's sort of like the -2^31 problem:-).

In practice, no implementation is going to use operator new in memset.
Even if the standard doesn't guarantee it, I wouldn't really consider
such a use non-portable.  It's certainly going to work on any
implementation that is generally useful.

The question of using iostream in terminate or unexpected is a bit more
delicate, but I suspect that market presure will ensure that it will
work, if nothing else.

On the other hand, I do think that there are significant grey areas as
to what functions really are safe in operator new, from a practical
point of view.  Today, for example, printf is probably safe on most
implementations, but it is not something I would count on in the
future.  Obviously, things like vector< T > and other containers are NOT
safe.  But what about sort?  find?

I can live with the status quo.  Practically, I suppose that the
functions in <string.h> are safe, and almost nothing else.  And to date,
I've not really needed much else.  Or at least not much else from what
one could reasonably expect.  (My debugging operator new uses both lists
and ostream.  But, IMHO, these are obviously unsafe: it uses its own
implementation of list, invasive, so that no allocation is needed, and
it has special handling to avoid recursion in the case of output.  On
the other hand, it DOES use memcpy, which is not guaranteed.)

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

James Kanze <james-albert.kanze@vx.cit.alcatel.fr> writes:

>fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes:
>
>|>  Summary: the status quo in the DWP is fine.
>
>Yes and no.

Agreed.  The status quo is fine for the example at the start of this
thread, but not for all examples.  The status quo in the DWP is not very
satisfactory for the operator new calls memset() example.

>... there are significant grey areas as
>to what functions really are safe in operator new, from a practical
>point of view.

Yes, agreed.

>I can live with the status quo.

Sure, just don't redefine the global operator new!

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]