In article <1993Aug26.192534.7958@vedge.com> hendrik@vedge.com
(Hendrik Boom) writes:

|> pabloh@hpwala.wal.hp.com (Pablo Halpern) writes:

|> : unit (or source file).  Most compilers implement this by calling all static
|> : constructors before calling main().  However, if one static constructor
|> : referres to another static object, most implementations break down (I'm not
|> : sure if the standard addresses this, either).

|> This is exactly what is at issue here.  Neither "most implementations"
|> nor the ARM address this issue, except that in commentary, the ARM
|> exhorts you to pity the poor compiler and not use *truly* circular cases.

|> But it leaved things quite ambiguoous about cross-module references with
|> static initializers.

This is one point where the ARM is not really ambiguous; section 3.4:
"The initialization of nonlocal static objects in a translation unit
is done before the first use of any functin or object defined in that
translation unit. ... No further order is imposed on the
initialization of objects from different translation units."   This
seems to be a clear statement that you cannot count on the order in
any way.

Although not ambiguous, there are two problems with this statement:

1. It cannot be implemented.  In particular, if a function or object
defined in one translation unit is used in the constructor of a static
object in another translation unit, it is possible that even this rule
will result in circular dependancies.  I believe that the most
widespread interpretation is that "first use" actually means "first
use after the call to 'main'," but I can find no text to support this.

2. It is not sufficient.  No one I know is happy with the rule.  The
problem here is that until now, no one has proposed a better one.
--
James Kanze                             email: kanze@us-es.sel.de
GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                   -- Beratung in industrieller Datenverarbeitung

In article <hopps.745774710@mmm.com>, hopps@yellow.mmm.com (Kevin J Hopps)
writes:
...
|> Would it be possible for the language could at least guarantee that static
|> objects will not be used before their constructors are called?  Would that
|> be impossible to implement?

That is already in the standard.  I don't have the ARM in front of me, but
it says something to the effect that the constructor for a static object is
called prior the the first use of any static object in the same compilation
unit (or source file).  Most compilers implement this by calling all static
constructors before calling main().  However, if one static constructor
referres to another static object, most implementations break down (I'm not
sure if the standard addresses this, either).
--

- Pablo

-------------------------------------------------------------------------
Pablo Halpern          Permanent: (508) 435-5274   phalpern@world.std.com
                       Thru 3/94: (508) 659-4639   pabloh@wal.hp.com
-------------------------------------------------------------------------

pabloh@hpwala.wal.hp.com (Pablo Halpern) writes:

: unit (or source file).  Most compilers implement this by calling all static
: constructors before calling main().  However, if one static constructor
: referres to another static object, most implementations break down (I'm not
: sure if the standard addresses this, either).

This is exactly what is at issue here.  Neither "most implementations"
nor the ARM address this issue, except that in commentary, the ARM
exhorts you to pity the poor compiler and not use *truly* circular cases.

But it leaved things quite ambiguoous about cross-module references with
static initializers.

: --
:
: - Pablo
:
: -------------------------------------------------------------------------
: Pablo Halpern          Permanent: (508) 435-5274   phalpern@world.std.com
:                        Thru 3/94: (508) 659-4639   pabloh@wal.hp.com
: -------------------------------------------------------------------------
--
-------------------------------------------------------
Try one or more of the following addresses to reply.
at work: hendrik@vedge.com,  iros1!vedge!hendrik
at home: uunet!ozrout!topoi!hendrik

Well, actually, I am using static objects, lots of them, and their constructors
do a lot of memory allocations.  And I wanted to know if on a code like this:

SomeClass1 obj1;
SomeClass2 obj2;
SomeClass3 obj3;

it is warantied that the constructors will be called on the same order.
Actually I am using Borland C++3.1 in which it does, and I would like to know
if it is a standard feature. If so: I would be nice to use this code to set the
new handler before the allocations:

class HandlerClass
{
   HandlerClass() { set_new_handler(myhandler); };
};

HandlerClass dummy;
SomeClass obj1;
SomeClass obj2;
SomeClass obj3;

With this, my new handler would be installed before the other constructors are
called.

I use something like this, and on a multiple file project, a dummy could be
declare on each .obj to inshure that the stuff works.

      Luis Longeri H
      llongeri@vangogh.die.udec.cl

rfg@netcom.com (Ronald F. Guilmette) writes:

>In article <hopps.745510839@mmm.com> kjhopps@mmm.com writes:
>>
>>Does the standard address multi-threaded programs at all?

> ...
>Of course, the first order question has to be "What would it mean for the
>C++ standard to `address' multi-threaded programs?"

The standard might address questions like:
    * What is to happen when an exception is thrown in one thread and not
      caught in that thread?  Does the thread die or does the entire
      program die?  Or does something else happen?
    * does set_new_handler set the handler for all threads or for the
      current thread?
--
Kevin J. Hopps   e-mail: kjhopps@mmm.com
3M Company   phone: (612) 737-3300
3M Center, Bldg. 235-3B-16 fax: (612) 737-2700
St. Paul, MN 55144-1000

rilbe@elixir.e.kth.se (Leif Rilbe) writes:

>In article <hopps.745510839@mmm.com> kjhopps@mmm.com writes:

>>My original problem was: how do I get my new handler installed before
>>any calls to new (given the possibility of static objects calling new)?
>>If you can answer that in a way different from my proposal, I'm all in
>>favor of avoiding a global.

>I think a solution would be to allow the programmer to specify functions that
>should be called at program startup, before any static objects are constructed.

This would be a viable alternative.

Another alternative would be to have the language specify the order of
calling static constructors.  This would allow the definition of a special
static object which installed the proper new handler right away.
--
Kevin J. Hopps   e-mail: kjhopps@mmm.com
3M Company   phone: (612) 737-3300
3M Center, Bldg. 235-3B-16 fax: (612) 737-2700
St. Paul, MN 55144-1000

llongeri@vangogh.die.udec.cl.die.udec.cl (Luis Longeri) writes:

>Well, actually, I am using static objects, lots of them, and their constructors
>do a lot of memory allocations.  And I wanted to know if on a code like this:

>SomeClass1 obj1;
>SomeClass2 obj2;
>SomeClass3 obj3;

>it is warantied that the constructors will be called on the same order.
>Actually I am using Borland C++3.1 in which it does, and I would like to know
>if it is a standard feature. If so: I would be nice to use this code to set the
>new handler before the allocations:

>class HandlerClass
>{
>   HandlerClass() { set_new_handler(myhandler); };
>};

>HandlerClass dummy;
>SomeClass obj1;
>SomeClass obj2;
>SomeClass obj3;

>With this, my new handler would be installed before the other constructors are
>called.

This works if you have access to the source and feel like taking the time
to add these dummies everywhere.  The trouble comes with linking files
which may contain static objects you don't even know about.

As I mentioned in a previous post, this problem could be alleviated by
having the standard define some kind of ordering scheme which would allow
programmers to determine how static constructors will be called.  I don't
have a good idea on how to do this.  Perhaps that's because it's too hard,
and that's why the language doesn't specify the ordering.

As I think more about it, all this probably wouldn't work.  After all,
if I want my static constructor to be called first, and I link with
a 3rd party lib that needs to have its static constructor called first,
somebody has to lose...

Would it be possible for the language could at least guarantee that static
objects will not be used before their constructors are called?  Would that
be impossible to implement?
--
Kevin J. Hopps   e-mail: kjhopps@mmm.com
3M Company   phone: (612) 737-3300
3M Center, Bldg. 235-3B-16 fax: (612) 737-2700
St. Paul, MN 55144-1000

In article <hopps.745774710@mmm.com>, hopps@yellow.mmm.com (Kevin J Hopps) writes:
> Would it be possible for the language could at least guarantee that static
> objects will not be used before their constructors are called?  Would that
> be impossible to implement?

No, not impossible, but it does require some sort of "program data base"
maintained by the compiler, or else a lot of support from the linker.

One way to do this is for the compiler to record, with each object file,
the names of extern objects and functions referenced by that file.  (It
need record only those objects whose type is a class with a constructor;
but it must record all extern functions, since those functions might in
turn reference a statically-constructed object.)  It also needs to record
the names of all file-level objects constructed in each object file.  Come
link time, a pre-linker can look at all the names referenced and
constructed by each object file, and sort them topologically.

This mechanism can occasionally fail due to cycles in the graph.  Often,
these cycles are not *real* dependencies, so the user must intervene.  This
brings us back to having some mechanism whereby the user can specify in
what order the static constructors should be done.

User-specified ordering would need to be a statement like "this must be
constructed before that", rather than something like "this must be
constructed first".

--
Bill Leonard
Harris Computer Systems Division
2101 W. Cypress Creek Road
Fort Lauderdale, FL  33309
bill@ssd.csd.harris.com

These opinions and statements are my own and do not reflect the opinions or
positions of Harris Corporation.

------------------------------------------------------------------------------
C M R ducks?
M R not ducks!
O S M R 2 ducks!  C M wangs?
L I B, M R ducks!
------------------------------------------------------------------------------

In article <hopps.745774167@mmm.com> kjhopps@mmm.com writes:
>rfg@netcom.com (Ronald F. Guilmette) writes:
>>Of course, the first order question has to be "What would it mean for the
>>C++ standard to `address' multi-threaded programs?"
>
>The standard might address questions like:
>    * What is to happen when an exception is thrown in one thread and not
>      caught in that thread?  Does the thread die or does the entire
>      program die?  Or does something else happen?

Personally, I think it'd be useful to be able to throw an exception
from one thread that will be raised in the context of another thread.
Unfortunately, this would probably be dependent on the underlying
threads model, which shouldn't be part of the C++ standard.

   greg

--
Greg Brail ------------------ Citibank -------------------- gjb@fig.citib.com

In article <hopps.744644675@mmm.com> kjhopps@mmm.com writes:
>I think the mechanism for altering the new handler is the problem.  I can
>suggest an interface which seems to solve the problem.  Let the language
>advertise a global variable:
>
>    extern void (*new_handler)();

OH NOT!  NOT ANOTHER GLOBAL VARIABLE!  (Isn't `errno' bad enough?)

Ever heard of multi-threading?

--

-- Ronald F. Guilmette ------------------------------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

rfg@netcom.com (Ronald F. Guilmette) writes:

>In article <hopps.744644675@mmm.com> kjhopps@mmm.com writes:
>>I think the mechanism for altering the new handler is the problem.  I can
>>suggest an interface which seems to solve the problem.  Let the language
>>advertise a global variable:
>>
>>    extern void (*new_handler)();

>OH NOT!  NOT ANOTHER GLOBAL VARIABLE!  (Isn't `errno' bad enough?)

>Ever heard of multi-threading?

Also, at least in Solaris, when writing a MT app, "errno" is not a
global at all.  There is a local copy for each thread.
--
Kevin J. Hopps   e-mail: kjhopps@mmm.com
3M Company   phone: (612) 737-3300
3M Center, Bldg. 235-3B-16 fax: (612) 737-2700
St. Paul, MN 55144-1000

rfg@netcom.com (Ronald F. Guilmette) writes:

>In article <hopps.744644675@mmm.com> kjhopps@mmm.com writes:
>>I think the mechanism for altering the new handler is the problem.  I can
>>suggest an interface which seems to solve the problem.  Let the language
>>advertise a global variable:
>>
>>    extern void (*new_handler)();

>OH NOT!  NOT ANOTHER GLOBAL VARIABLE!  (Isn't `errno' bad enough?)

>Ever heard of multi-threading?

Yes, actually.  Admittedly, I hadn't thought of how this might affect
code which alters the new handler as a matter of course throughout the
life of the program.

My original problem was: how do I get my new handler installed before
any calls to new (given the possibility of static objects calling new)?
If you can answer that in a way different from my proposal, I'm all in
favor of avoiding a global.

Some questions also occur to me:

What fraction of the implementations of set_new_handler out there do
you suppose use a single static variable to hold the function address?

Does the standard address multi-threaded programs at all?

Wouldn't an implementation of set_new_handler that affected the new
handler for only the current thread be in violation of the standard?
--
Kevin J. Hopps   e-mail: kjhopps@mmm.com
3M Company   phone: (612) 737-3300
3M Center, Bldg. 235-3B-16 fax: (612) 737-2700
St. Paul, MN 55144-1000

In article <hopps.745510839@mmm.com> kjhopps@mmm.com writes:
>
>Does the standard address multi-threaded programs at all?

I don't really know the answer to this question.  Hopefully, some current
member(s) of X3J16 will chime in at this point.

(As far as I know, X3J16 has been too bust with other things to think much
about multi-threading yet.)

Of course, the first order question has to be "What would it mean for the
C++ standard to `address' multi-threaded programs?"

I (for one) have only a vague notion of what it would mean for the standard
to "address" multi-threading.  Certainly, you'd like to have it specified
that the entire standard C++ library is reentrant (to the extent that that's
possible), but what else is involved?  Perhaps something needs to be said
about exceptions, and how they are implemented.  And perhaps there are other
issues beyond that.  I don't really know.

(Oh yea... And don't forget that it will ALWAYS be possible for people to
write C++ functions which are NOT reentrant, so at best, all the standard
could do would be to say that if you follow this rule and that rule and
that rule, then, and only then, the result of compiling your code should
be reentrant object code.)

--

-- Ronald F. Guilmette ------------------------------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

In article <hopps.745510839@mmm.com> kjhopps@mmm.com writes:

(stuff deleted...)

>My original problem was: how do I get my new handler installed before
>any calls to new (given the possibility of static objects calling new)?
>If you can answer that in a way different from my proposal, I'm all in
>favor of avoiding a global.

(more stuff deleted...)

>Kevin J. Hopps   e-mail: kjhopps@mmm.com
>3M Company   phone: (612) 737-3300
>3M Center, Bldg. 235-3B-16 fax: (612) 737-2700
>St. Paul, MN 55144-1000

I think a solution would be to allow the programmer to specify functions that
should be called at program startup, before any static objects are constructed.

I use Borland's C++ compiler and it has a "#pragma startup" directive that
lets me specify functions that should be called at program startup, before
main is called. I don't know if the functions are called before or after
the construction of static objects, though. Anyway, something along these
lines would provide a solution to your problem, I think.

(PS, I don't think a saw your proposal in its entirety so I might have
misunderstood something. )

--
 Leif Rilbe            | "Do it tomorrow, you've made enough mistakes today."
 rilbe@e.kth.se        |
 rilbe@speech.kth.se   |

In article <hopps.744908739@mmm.com>, Kevin J Hopps <kjhopps@mmm.com> wrote:
>pete@borland.com (Pete Becker) writes:
>
>>In article <hopps.744644675@mmm.com>, Kevin J Hopps <kjhopps@mmm.com> wrote:
>>>The function set_new_handler is the sole mechanism for implementing
>>>a user-defined handler.  Given this, and given the fact that the language
>>>does not allow me to predict the calling order of the constructors for
>>>static objects in different modules, how can I know that my new handler
>>>is in place before any calls to new?
>>>
>>>If there is a convenient way for me to ensure this, let me know.
>
>> C++ programmers seem to be in love with the idea of doing all sorts
>>of things in constructors for static objects, despite the problems that they
>>run into when they try to do them. Seems to me that we should be much more
>>circumspect about doing things in constructors of static objects.  Just
>>because it's legal doesn't mean you have to do it.
>> -- Pete
>
>Are you saying that
>    1) static objects should be avoided?
 No.
>    2) calling new in a constructor should be avoided?
 No.
>    3) calling new in a constructor for a static object should be avoided?
 No.
>

 Doing things in static constructers that depend on other things
having already been done is dangerous. Don't do it. If you have so little
memory that you're in danger of running out of memory during initialization
of static objects your program doesn't have a prayer of working. Needing to
have a new-handler installed prior to initialization of static members seems
to me to indicate a major design flaw in the program, not a defect in the
language.
 -- Pete

In article <1993Aug6.174154.3800@borland.com>, pete@borland.com (Pete Becker) writes:
|> In article <hopps.744644675@mmm.com>, Kevin J Hopps <kjhopps@mmm.com> wrote:
|> >The function set_new_handler is the sole mechanism for implementing
|> >a user-defined handler.  Given this, and given the fact that the language
|> >does not allow me to predict the calling order of the constructors for
|> >static objects in different modules, how can I know that my new handler
|> >is in place before any calls to new?
|> >
|> >If there is a convenient way for me to ensure this, let me know.
|>
|>  C++ programmers seem to be in love with the idea of doing all sorts
|> of things in constructors for static objects, despite the problems that they
|> run into when they try to do them. ...

That is not the issue here (at least I do not think so).  For instance,
many existing libraries, such as the iostream library, do things with
static objects, some of which probably use new to allocate internal
data.

Now, suppose that for my application it is absolutely vital that I have
control over the handling of *all* allocation failures, including those
in standard libraries.  How do I set the new handler *before* the static
constructors in the standard libraries?  *This* is the issue, and the
source of the problem - it occurs even if I, myself, do nothing with
static objects.


Hmm, this brings up another issue - I may want to catch, and handle,
*all* exceptions thrown, even those thrown before main().  There is
no place to put a try block for that, and the default handler for
uncaught exceptions exits, which may be wrong.  So the same mechanism
for changing the handler globally needs to be provided for the
uncaught exception handler.

--
sarima@teradata.com   (formerly tdatirv!sarima)
  or
Stanley.Friesen@ElSegundoCA.ncr.com

The peace of God be with you.

In article <3083@tdbunews.teradata.com>,
Stan Friesen <swf@elsegundoca.ncr.com> wrote:
>
>Now, suppose that for my application it is absolutely vital that I have
>control over the handling of *all* allocation failures, including those
>in standard libraries.  How do I set the new handler *before* the static
>constructors in the standard libraries?  *This* is the issue, and the
>source of the problem - it occurs even if I, myself, do nothing with
>static objects.
>

 Being able to force installation of a new-handler won't solve this
problem. There's not much that's useful that you can do in it, other than
posting some sort of message telling the user that there's not enough memory
to run.
 The solution is to design the application so that it does not depend
on constructors for static objects.
 Take those textbooks that give their readers the "problem" of writing a
program that displays "Hello, world" without any code in main() and burn them.
They encourage bad habits.
 -- Pete

In article <1993Aug9.173949.26687@borland.com> pete@borland.com (Pete
Becker) writes:

|>  Doing things in static constructers that depend on other things
|> having already been done is dangerous. Don't do it. If you have so little
|> memory that you're in danger of running out of memory during initialization
|> of static objects your program doesn't have a prayer of working. Needing to
|> have a new-handler installed prior to initialization of static members seems
|> to me to indicate a major design flaw in the program, not a defect in the
|> language.

This depends on what the default new handler does.  It is impossible
to say that your program won't run out of memory during
initialization; this depends on what the user is doing in *other*
windows on the system, how many background jobs are running, how much
swap space is configured...

Originally, with the default new handler in place, operator new
returned NULL.  If you are not testing this returned value for every
call to new in a constructor, your program will probably core dump if
it runs out of memory in the initialization phase.  I do not consider
"segmentation violation" a clear error message to tell the user there
is not enough memory to even start his program.

My own personal preference would be an error message ("insufficient
memory"), and exit.  But I can live with an exception *if* the system
will display some sort of reasonably error message if the exception is
not caught.  ("Unexpected exception", or even "unexpected xalloc
exception" is no better than "segment violation.")
--
James Kanze                             email: kanze@us-es.sel.de
GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                   -- Beratung in industrieller Datenverarbeitung

In article <3083@tdbunews.teradata.COM> swf@tools3teradata.com (Stan
Friesen) writes:

|> In article <1993Aug6.174154.3800@borland.com>, pete@borland.com (Pete Becker) writes:
|> |> In article <hopps.744644675@mmm.com>, Kevin J Hopps <kjhopps@mmm.com> wrote:
|> |> >The function set_new_handler is the sole mechanism for implementing
|> |> >a user-defined handler.  Given this, and given the fact that the language
|> |> >does not allow me to predict the calling order of the constructors for
|> |> >static objects in different modules, how can I know that my new handler
|> |> >is in place before any calls to new?
|> |> >
|> |> >If there is a convenient way for me to ensure this, let me know.
|> |>
|> |>  C++ programmers seem to be in love with the idea of doing all sorts
|> |> of things in constructors for static objects, despite the problems that they
|> |> run into when they try to do them. ...

|> That is not the issue here (at least I do not think so).  For instance,
|> many existing libraries, such as the iostream library, do things with
|> static objects, some of which probably use new to allocate internal
|> data.

|> Now, suppose that for my application it is absolutely vital that I have
|> control over the handling of *all* allocation failures, including those
|> in standard libraries.  How do I set the new handler *before* the static
|> constructors in the standard libraries?  *This* is the issue, and the
|> source of the problem - it occurs even if I, myself, do nothing with
|> static objects.

Have you tried replacing ::operator new and ::operator delete?  Your
versions can always call malloc and free for the actual memory
management, and do whatever you like if no memory is present (except
that if they return, they must either return a valid pointer, or
NULL).
--
James Kanze                             email: kanze@us-es.sel.de
GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                   -- Beratung in industrieller Datenverarbeitung

pete@borland.com (Pete Becker) writes:

>In article <3083@tdbunews.teradata.com>,
>Stan Friesen <swf@elsegundoca.ncr.com> wrote:
>>
>>Now, suppose that for my application it is absolutely vital that I have
>>control over the handling of *all* allocation failures, including those
>>in standard libraries.  How do I set the new handler *before* the static
>>constructors in the standard libraries? ...
>>

> Being able to force installation of a new-handler won't solve this
>problem. There's not much that's useful that you can do in it, other than
>posting some sort of message telling the user that there's not enough memory
>to run.

I disagree with you.  If Mr. Friesen says that it is vital that he has
control over the handling of *all* allocation failures, I'm inclined to
take his word for it rather than to second-guess him.  Perhaps there *is*
something useful to be done in *his* execution environment.

In AIX, for example, the way the kernel gets more memory for one process is
to start killing others.  A "creative" new handler might do something
similar :-)

> The solution is to design the application so that it does not depend
>on constructors for static objects.

This is the *work-around* only if the language does not allow link-time
setting of the new handler.  Further, I agree with Mr. Friesen's previous
post regarding the outermost exception handling.

> Take those textbooks that give their readers the "problem" of writing a
>program that displays "Hello, world" without any code in main() and burn them.
>They encourage bad habits.
> -- Pete

There are many language features which are dangerous if not used properly.
This is the nature of a very sharp knife -- you can do fine work, or cut
off your finger.  Rather than force people to use a blunt instrument, I
favor teaching them how to use the sharp one.

How do you feel about Ada? :-)
--
Kevin J. Hopps   e-mail: kjhopps@mmm.com
3M Company   phone: (612) 737-3300
3M Center, Bldg. 235-3B-16 fax: (612) 737-2700
St. Paul, MN 55144-1000

The function set_new_handler is the sole mechanism for implementing
a user-defined handler.  Given this, and given the fact that the language
does not allow me to predict the calling order of the constructors for
static objects in different modules, how can I know that my new handler
is in place before any calls to new?

If there is a convenient way for me to ensure this, let me know.  Otherwise
I think the mechanism for altering the new handler is the problem.  I can
suggest an interface which seems to solve the problem.  Let the language
advertise a global variable:

    extern void (*new_handler)();

And have the library contain one file with only the new_handler pointer
in it.  Then, if there is to be a default new handler for the language,
let the library also contain a separate file which contains the handler,
and advertise it so that I can change back to the default at run time
if I want to.

Now if in my application I want to have a different >default< new handler,
all I have to do is define in some source file:
    void (*new_handler)() = my_new_handler;

Then the proper default new handler is set at link time.
--
Kevin J. Hopps   e-mail: kjhopps@mmm.com
3M Company   phone: (612) 737-3300
3M Center, Bldg. 235-3B-16 fax: (612) 737-2700
St. Paul, MN 55144-1000

In article <hopps.744644675@mmm.com>, Kevin J Hopps <kjhopps@mmm.com> wrote:
>The function set_new_handler is the sole mechanism for implementing
>a user-defined handler.  Given this, and given the fact that the language
>does not allow me to predict the calling order of the constructors for
>static objects in different modules, how can I know that my new handler
>is in place before any calls to new?
>
>If there is a convenient way for me to ensure this, let me know.

 C++ programmers seem to be in love with the idea of doing all sorts
of things in constructors for static objects, despite the problems that they
run into when they try to do them. Seems to me that we should be much more
circumspect about doing things in constructors of static objects.  Just
because it's legal doesn't mean you have to do it.
 -- Pete

pete@borland.com (Pete Becker) writes:

>In article <hopps.744644675@mmm.com>, Kevin J Hopps <kjhopps@mmm.com> wrote:
>>The function set_new_handler is the sole mechanism for implementing
>>a user-defined handler.  Given this, and given the fact that the language
>>does not allow me to predict the calling order of the constructors for
>>static objects in different modules, how can I know that my new handler
>>is in place before any calls to new?
>>
>>If there is a convenient way for me to ensure this, let me know.

> C++ programmers seem to be in love with the idea of doing all sorts
>of things in constructors for static objects, despite the problems that they
>run into when they try to do them. Seems to me that we should be much more
>circumspect about doing things in constructors of static objects.  Just
>because it's legal doesn't mean you have to do it.
> -- Pete

Are you saying that
    1) static objects should be avoided?
    2) calling new in a constructor should be avoided?
    3) calling new in a constructor for a static object should be avoided?

If implementation is truly separate from implementation, then item 3 is not
a practical policy.  One who defines a static object will not know if it's
constructor calls new.  One who implements a class will not know if
somebody will define a static instance of it.

If item 3 is the goal, then I think full adherence to either 1 or 2 is
necessary.  Would you advocate that?
--
Kevin J. Hopps   e-mail: kjhopps@mmm.com
3M Company   phone: (612) 737-3300
3M Center, Bldg. 235-3B-16 fax: (612) 737-2700
St. Paul, MN 55144-1000