>>>>> On 4 Jan 95 00:53:04 GMT, fjh@munta.cs.mu.OZ.AU (Fergus Henderson) said:

Fergus> ev@chorus.chorus.fr (Eric Valette) writes:

Fergus> According to the current ANSI/ISO C++ working draft, 3.6.4.1/4,
Fergus> if an allocation-function (a user-defined operator new or operator new [])
Fergus> returns a null pointer, the behaviour is implementation-defined.

I guess implementation defined means that people have been stuggling
quite heavily :-)

>If GCC is right can you give me a rationale for the proposal?

Fergus> Basically the idea is that (if you want to write portable code) you
Fergus> should throw an exception rather than returning a null pointer.

The problem I have whith this answer is that :
 - I have no idea of how exception will be implemeted
 - I'm using C++ in the context of an OS and thus I
 am not sure to be able to ever use exceptions.
 (BTW regarding the current discussion about GC in this
 news group, I also need to have a way to disable it although
 I agree itis very convenient for general purpose application)

Fergus> Nevertheless, even though gcc is right, and even though gcc produces
Fergus> more efficient code as a result of their decision, it would certainly
Fergus> be nice if gcc had a `-fallow_new_to_return_0' option.

Hope they are listening...We will nevertheless
continue to write the chorus kernel in C++.

Thanks for your time and happy new year.

--
   __
  /  `                    Eric Valette
 /--   __  o _.           Chorus Systemes
(___, / (_(_(__          6 avenue Gustave Eiffel
    F-78182, St-Quentin-en-Yvelines-Cedex

Tel: +33 (1) 30 64 82 00 Fax: +33 (1) 30 57 00 66
E-mail: ev@chorus.fr

In the embedded marked there is a growing interest for C++ as a C
replacement, and in this market user defined operator new are common and
may fail for all kernel internal data object as operator new is usually
just picking the first element in a dedicated free elem pool. So Given
the following example, what is the expected behavior?

class A {
 int a;
public:
 A(int v) {a = v;}
 ~A(){};
};

class B {
 int b;
public:
 B(int v) {b = v;}
 ~B(){}
};


class C {
 A Ainst;
 B Binst;
public:

 void *operator new (unsigned int) {return 0;}
 C(int a, int b);
 ~C() {}
};


main()
{
 C* ptrC = new C(1,2);
}

This programm crash using GCC 2.6.3 because C::C(1,2) is called with "this"
equal to 0. With Cfront 3.0.3 the program does not crash because C constructor
is NOT called. WHO IS RIGHT ? What is the expected behavior regarded to current
ANSI C++ dratft?

If GCC is right can you give me a rationale for the proposal? Is the behavior
for global operator new identical?

The problem I see are :
 - I cannot simply test this == 0  in C because B::B() is called
 before C::C() and furthermore in B::B() the value of this is sizeof(int)
 NOT 0.
 - Thus I must call C::operator new by hand and call explicitely
 the C constructor with the result but then the usage of user defined
 operator new is not transparent?


Anay remarks or sugestion are welcome,
Happy new year,

--
   __
  /  `                    Eric Valette
 /--   __  o _.           Chorus Systemes
(___, / (_(_(__          6 avenue Gustave Eiffel
    F-78182, St-Quentin-en-Yvelines-Cedex

Tel: +33 (1) 30 64 82 00 Fax: +33 (1) 30 57 00 66
E-mail: ev@chorus.fr

ev@chorus.chorus.fr (Eric Valette) writes:

>[...] Given the following example, what is the expected behavior?

[...classes A and B, with user-defined default constructors...]

>class C {
> A Ainst;
> B Binst;
>public:
> void *operator new (unsigned int) {return 0;}
> C(int a, int b);
> ~C() {}
>};
>
>main()
>{
> C* ptrC = new C(1,2);
>}
>
>This programm crash using GCC 2.6.3 because C::C(1,2) is called with "this"
>equal to 0. With Cfront 3.0.3 the program does not crash because C constructor
>is NOT called. WHO IS RIGHT ?

They are both right (but they both have to document the behaviour).

>What is the expected behavior regarded to current ANSI C++ dratft?

According to the current ANSI/ISO C++ working draft, 3.6.4.1/4,
if an allocation-function (a user-defined operator new or operator new [])
returns a null pointer, the behaviour is implementation-defined.

>If GCC is right can you give me a rationale for the proposal?

Basically the idea is that (if you want to write portable code) you
should throw an exception rather than returning a null pointer.

Nevertheless, even though gcc is right, and even though gcc produces
more efficient code as a result of their decision, it would certainly
be nice if gcc had a `-fallow_new_to_return_0' option.

>Is the behavior for global operator new identical?

Yes, if you provide a user-defined global operator new, then the
same rules apply, so the behaviour is implementation-defined
if your user-defined operator new returns a null pointer.
However the default global operator new will call the new_handler
if it can't allocate memory, and the default new_handler will throw
an exception.

--
Fergus Henderson - fjh@munta.cs.mu.oz.au