By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
455,905 Members | 1,293 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 455,905 IT Pros & Developers. It's quick & easy.

new returning 0

P: n/a
It is my understanding that this behavior has long been deprecated and
is not standard. That is the creation of an array of objects using new
returning 0 instead of throwing an exception. I'm not the one dealing
with the code but I told that person he might expect an exception and
thus sent him on a wild goose chase. Where did I go wrong?

As far as I know there's no override of operator new. There's no
(std::nothrow). Compiler is msvc++ 8.
May 30 '07 #1
Share this Question
Share on Google+
25 Replies


P: n/a
Noah Roberts wrote:
It is my understanding that this behavior has long been deprecated and
is not standard. That is the creation of an array of objects using
new returning 0 instead of throwing an exception. I'm not the one
dealing with the code but I told that person he might expect an
exception and thus sent him on a wild goose chase. Where did I go
wrong?
Some old compilers didn't have the proper implementation of 'new'...
As far as I know there's no override of operator new. There's no
(std::nothrow). Compiler is msvc++ 8.
Huh? I think it's answered in the FAQ 5.8...

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
May 30 '07 #2

P: n/a
Noah Roberts wrote:
It is my understanding that this behavior has long been deprecated and
is not standard. That is the creation of an array of objects using new
returning 0 instead of throwing an exception. I'm not the one dealing
with the code but I told that person he might expect an exception and
thus sent him on a wild goose chase. Where did I go wrong?

As far as I know there's no override of operator new. There's no
(std::nothrow). Compiler is msvc++ 8.
1. you can override 'operator new'
2. there is std::nothrow

Returning 0 from new is a convenience feature imo. For the past 10
years, people have been writing code like
if( !(x = new classA) ){ handle_new_error(); }
May 30 '07 #3

P: n/a
Noah Roberts wrote:
It is my understanding that this behavior has long been deprecated and
is not standard. That is the creation of an array of objects using new
returning 0 instead of throwing an exception. I'm not the one dealing
with the code but I told that person he might expect an exception and
thus sent him on a wild goose chase. Where did I go wrong?

As far as I know there's no override of operator new. There's no
(std::nothrow). Compiler is msvc++ 8.
std::nothrow is defined in <new>

#include <new>
#include <stdexcept>
#include <iostream>
#include <ostream>

int main()
{
int *pint = 0;
try
{
pint = new int[10];
}
catch (std::bad_alloc& e)
{
std::cout << "new failed: "
<< e.what()
<< std::endl;
}

delete[] pint;

pint = new(std::nothrow) int[10];
if (!pint)
{
std::cout << "new(std::nothrow) failed" << std::endl;
}
delete[] pint;

return 0;
}
May 30 '07 #4

P: n/a
Noah Roberts wrote:
It is my understanding that this behavior has long been deprecated and
is not standard. That is the creation of an array of objects using new
returning 0 instead of throwing an exception. I'm not the one dealing
with the code but I told that person he might expect an exception and
thus sent him on a wild goose chase. Where did I go wrong?

As far as I know there's no override of operator new. There's no
(std::nothrow). Compiler is msvc++ 8.
What I mean is that the code is not using std::nothrow nor is it
overriding operator new, so these are not the reasons why new is
returning 0.
May 30 '07 #5

P: n/a
Victor Bazarov wrote:
Noah Roberts wrote:
>It is my understanding that this behavior has long been deprecated and
is not standard. That is the creation of an array of objects using
new returning 0 instead of throwing an exception. I'm not the one
dealing with the code but I told that person he might expect an
exception and thus sent him on a wild goose chase. Where did I go
wrong?

Some old compilers didn't have the proper implementation of 'new'...
Yeah, msvc++ 8 isn't exactly old.
>
>As far as I know there's no override of operator new. There's no
(std::nothrow). Compiler is msvc++ 8.

Huh? I think it's answered in the FAQ 5.8...
I don't see it. I think you're mistaken.
May 30 '07 #6

P: n/a
Noah Roberts wrote:
Victor Bazarov wrote:
>Noah Roberts wrote:
>>It is my understanding that this behavior has long been deprecated and
is not standard. That is the creation of an array of objects using
new returning 0 instead of throwing an exception. I'm not the one
dealing with the code but I told that person he might expect an
exception and thus sent him on a wild goose chase. Where did I go
wrong?

Some old compilers didn't have the proper implementation of 'new'...

Yeah, msvc++ 8 isn't exactly old.
>>
>>As far as I know there's no override of operator new. There's no
(std::nothrow). Compiler is msvc++ 8.

Huh? I think it's answered in the FAQ 5.8...

I don't see it. I think you're mistaken.
Victor meant that if your code doesn't work as you expect (and it
obviously doesn't) and you ask a question about that, you have to follow
the guideline of the FAQ 5.8. Of course, in this case this translates
to: "post the code that does not work".

Regards,

Zeppe
May 30 '07 #7

P: n/a
Zeppe wrote:
Noah Roberts wrote:
>Victor Bazarov wrote:
>>Noah Roberts wrote:
It is my understanding that this behavior has long been deprecated and
is not standard. That is the creation of an array of objects using
new returning 0 instead of throwing an exception. I'm not the one
dealing with the code but I told that person he might expect an
exception and thus sent him on a wild goose chase. Where did I go
wrong?

Some old compilers didn't have the proper implementation of 'new'...

Yeah, msvc++ 8 isn't exactly old.
>>>
As far as I know there's no override of operator new. There's no
(std::nothrow). Compiler is msvc++ 8.

Huh? I think it's answered in the FAQ 5.8...

I don't see it. I think you're mistaken.

Victor meant that if your code doesn't work as you expect (and it
obviously doesn't) and you ask a question about that, you have to follow
the guideline of the FAQ 5.8. Of course, in this case this translates
to: "post the code that does not work".
Yeah, not exactly applicable in cases like this and I'm not finding
pedantic nonsense very helpful, sorry.

If you can't answer the question, don't answer the question.
May 30 '07 #8

P: n/a
Noah Roberts wrote:
[..]

If you can't answer the question, don't answer the question.
You've earned a position in my killfile for the second time!
Welcome back, Noah!
May 30 '07 #9

P: n/a
On Wed, 30 May 2007 09:37:14 -0700, Noah Roberts wrote:
Noah Roberts wrote:
>It is my understanding that this behavior has long been deprecated and
is not standard. That is the creation of an array of objects using new
returning 0 instead of throwing an exception. I'm not the one dealing
with the code but I told that person he might expect an exception and
thus sent him on a wild goose chase. Where did I go wrong?

As far as I know there's no override of operator new. There's no
(std::nothrow). Compiler is msvc++ 8.

What I mean is that the code is not using std::nothrow nor is it
overriding operator new, so these are not the reasons why new is
returning 0.
Right. Your original post was unclear. Just to get it straight, you are
saying that in some instances new (array version, not using std::nothrow,
not overridden) is not throwing an exception, but rather returning 0.

The only thing I can think of is that perhaps the compiler is being
invoked with some strange switch leading to non-standard behaviour.

A minimal example demonstrating the problem might be useful - perhaps
someone with the same compiler might be able to cast some light (and of
course creating minimal examples frequently throws up the answer).

--
Lionel B
May 30 '07 #10

P: n/a
Noah Roberts wrote:
Zeppe wrote:
>Victor meant that if your code doesn't work as you expect (and it
obviously doesn't) and you ask a question about that, you have to
follow the guideline of the FAQ 5.8. Of course, in this case this
translates to: "post the code that does not work".

Yeah, not exactly applicable in cases like this and I'm not finding
pedantic nonsense very helpful, sorry.

If you can't answer the question, don't answer the question.
Ok, a less pedantic nonsense, then: given that my vc8 throws bad_alloc,
or your vc8 is different from mine, or you are talkin bullshit. I dunno
why, but i guess the latter.

bye

Zeppe
May 30 '07 #11

P: n/a
Victor Bazarov wrote:
Noah Roberts wrote:
>[..]

If you can't answer the question, don't answer the question.

You've earned a position in my killfile for the second time!
Welcome back, Noah!

yay!!! Does this mean I don't have to put up with your inane replies
anymore??
May 30 '07 #12

P: n/a
Lionel B wrote:
On Wed, 30 May 2007 09:37:14 -0700, Noah Roberts wrote:
>Noah Roberts wrote:
>>It is my understanding that this behavior has long been deprecated and
is not standard. That is the creation of an array of objects using new
returning 0 instead of throwing an exception. I'm not the one dealing
with the code but I told that person he might expect an exception and
thus sent him on a wild goose chase. Where did I go wrong?

As far as I know there's no override of operator new. There's no
(std::nothrow). Compiler is msvc++ 8.
What I mean is that the code is not using std::nothrow nor is it
overriding operator new, so these are not the reasons why new is
returning 0.

Right. Your original post was unclear. Just to get it straight, you are
saying that in some instances new (array version, not using std::nothrow,
not overridden) is not throwing an exception, but rather returning 0.

The only thing I can think of is that perhaps the compiler is being
invoked with some strange switch leading to non-standard behaviour.
That's my thought too but I can't find it.
>
A minimal example demonstrating the problem might be useful - perhaps
someone with the same compiler might be able to cast some light (and of
course creating minimal examples frequently throws up the answer).
Such a sample cannot be created. Not without knowing how to do so; of
course, I've only spent 4 hours trying. All versions, even those with
exceptions turned off, throw a bad_alloc.

Once I know how to create the problem I can solve it by reversing that
creation in the problem program.
May 30 '07 #13

P: n/a
Noah Roberts wrote:
Lionel B wrote:
>A minimal example demonstrating the problem might be useful - perhaps
someone with the same compiler might be able to cast some light (and
of course creating minimal examples frequently throws up the answer).

Such a sample cannot be created. Not without knowing how to do so; of
course, I've only spent 4 hours trying. All versions, even those with
exceptions turned off, throw a bad_alloc.

Once I know how to create the problem I can solve it by reversing that
creation in the problem program.
More on my attempt to solve the problem or even recreate it:

The program that is doing this uses a DLL that is allocating the memory.
I don't know if being a DLL has anything to do with it or not because
I've tried going down that road as well. One thing for certain, the
problem program is calling a non-standard operator new (size_t, int,
char const*, int) inside of dbgnew.cpp. I can't get my small version to
call this function.

I think I'm treading too far into implementation specific behavior to
get much help here (especially with the police population) but maybe
someone has seen this, maybe not.
May 30 '07 #14

P: n/a
Noah Roberts wrote:
Noah Roberts wrote:
>Lionel B wrote:
>>A minimal example demonstrating the problem might be useful - perhaps
someone with the same compiler might be able to cast some light (and
of course creating minimal examples frequently throws up the answer).

Such a sample cannot be created. Not without knowing how to do so; of
course, I've only spent 4 hours trying. All versions, even those with
exceptions turned off, throw a bad_alloc.

Once I know how to create the problem I can solve it by reversing that
creation in the problem program.

More on my attempt to solve the problem or even recreate it:

The program that is doing this uses a DLL that is allocating the memory.
I don't know if being a DLL has anything to do with it or not because
I've tried going down that road as well. One thing for certain, the
problem program is calling a non-standard operator new (size_t, int,
char const*, int) inside of dbgnew.cpp. I can't get my small version to
call this function.

I think I'm treading too far into implementation specific behavior to
get much help here (especially with the police population) but maybe
someone has seen this, maybe not.
I got a repro on the problem. I now know the cause and can do something
about it. Someone was being clever.
May 30 '07 #15

P: n/a
Noah Roberts wrote:
I got a repro on the problem. I now know the cause and can do something
about it. Someone was being clever.
And? I am curious to what actually happened.

- J.
May 31 '07 #16

P: n/a
Jacek Dziedzic wrote:
Noah Roberts wrote:
>I got a repro on the problem. I now know the cause and can do
something about it. Someone was being clever.

And? I am curious to what actually happened.
The MSVC++ library has this funky "debug" new that has the previously
described signature. It is called something like so:

new(_NEWBLOCK, size, __FILE__, __LINE__) object;

I don't know if that's the real thing but it's the general idea.

Someone was being clever, had defined a macro for that and then done this:

#define new DEBUG_NEW

So all the calls to new in the source where doing some stupid
non-standard, compiler specific, allocation call that acts like
pre-exception new and returns 0. It dawned on me what was going on
right after I posted the entry just before saying I figured it out and
it only took a bit to verify.

I was hoping that figuring this out might solve the underlying
allocation problem but no such luck. We just know why it wasn't
behaving as the standard describes.
May 31 '07 #17

P: n/a
Noah Roberts wrote:
....
I was hoping that figuring this out might solve the underlying
allocation problem but no such luck. We just know why it wasn't
behaving as the standard describes.
I assume now you see bad_alloc exceptions and you don't know why ?
Maybe a corrupted heap ?
May 31 '07 #18

P: n/a
Gianni Mariani wrote:
Noah Roberts wrote:
...
>I was hoping that figuring this out might solve the underlying
allocation problem but no such luck. We just know why it wasn't
behaving as the standard describes.

I assume now you see bad_alloc exceptions and you don't know why ? Maybe
a corrupted heap ?
Could be. The developer that made that code was the same one that
insisted on using char* instead of strings and vectors. The same one
that dictated to the whole team that we where not to use exceptions.
The same one that didn't like templates and the STL because they're,
"slow and bloated." The same one that adhered strictly to the NIH paradigm.

We were all quite upset to see him go.

I think they're giving up on it; my involvement kind of ended when I
discovered why it wasn't doing what I said it should be doing. It only
happens in some obscure condition under this weird test when running on
windows 2000 in a VM. We don't expect that to come up a whole lot with
our customer use patterns. Something to fix later when we're screwing
with that program again...something that might get fixed just by slowly
changing code to use more reasonable coding standards.
May 31 '07 #19

P: n/a
Noah Roberts wrote:
Gianni Mariani wrote:
....
>I assume now you see bad_alloc exceptions and you don't know why ?
Maybe a corrupted heap ?
....
>
I think they're giving up on it; my involvement kind of ended when I
discovered why it wasn't doing what I said it should be doing. It only
happens in some obscure condition under this weird test when running on
windows 2000 in a VM.
That's probably still a bug in the application code that will bite you
on your first deployment to a paying customer.
... We don't expect that to come up a whole lot with
our customer use patterns. Something to fix later when we're screwing
with that program again...something that might get fixed just by slowly
changing code to use more reasonable coding standards.
Exceptions are kind of special in that I don't often see them used
correctly. Often programmers use it as a return value passing mechanism
rather than "fixing" the interfaces.

Exceptions in C++ could be much better - the nothrow semantics for
example could be compile-time enforced. Debugging with exceptions can
be non-trivial because you loose the context of the exception - this
needs the programmer to log much more information in the case of an
exception.

Exceptions are also used often where and abort should be. A coding
error should be terminal - i.e. stop the process and dump a core file
yet many developers throw an exception hoping to recover only further
exacerbating the problems. Classic case - I use a CAD program, when it
dies, it tries to save the work in progress only to often end up
corrupting the previously saved version.

While template phobia and not using constructors correctly are valid
criticisms, a healthy dose of reality check of use of exceptions is
something that needs to be evaluated more closely.

Jun 1 '07 #20

P: n/a
Gianni Mariani wrote:
Noah Roberts wrote:
>Gianni Mariani wrote:
...
>>I assume now you see bad_alloc exceptions and you don't know why ?
Maybe a corrupted heap ?
...
>>
I think they're giving up on it; my involvement kind of ended when I
discovered why it wasn't doing what I said it should be doing. It
only happens in some obscure condition under this weird test when
running on windows 2000 in a VM.

That's probably still a bug in the application code that will bite you
on your first deployment to a paying customer.
Yeah, if it wasn't already out there we would probably try harder. It's
already been on the market for many months though and nothing so...
Jun 1 '07 #21

P: n/a
Gianni Mariani wrote:
While template phobia and not using constructors correctly are valid
criticisms, a healthy dose of reality check of use of exceptions is
something that needs to be evaluated more closely.
Yeah, so you create a reasonable coding policy regarding them. Saying,
"We don't use exceptions," isn't reasonable. Especially when the
reasoning is, "Because they are slow." They are a part of the language
and used HEAVILY by the standard library. It isn't reasonable to just
ignore them.

We now have years worth of code that has absolutely no exception safety
at all.

I agree that they are often misused, but there are also many great
places from which to learn to use them reasonably.

Saving to the original, as in your example, is just poor practice.
Never overwrite the original when your program is in an undefinable
state. I would qualify during a crash as an undefinable state.
Jun 1 '07 #22

P: n/a
On May 30, 2:14 pm, "Victor Bazarov" <v.Abaza...@comAcast.netwrote:
Noah Roberts wrote:
[..]
If you can't answer the question, don't answer the question.

You've earned a position in my killfile for the second time!
Welcome back, Noah!
huh?! how a user could be 'killed' TWICE?

Jun 1 '07 #23

P: n/a
Diego Martins wrote:
On May 30, 2:14 pm, "Victor Bazarov" <v.Abaza...@comAcast.netwrote:
>Noah Roberts wrote:
>>[..]
If you can't answer the question, don't answer the question.
You've earned a position in my killfile for the second time!
Welcome back, Noah!

huh?! how a user could be 'killed' TWICE?
I recursively re-spawn I guess.
Jun 1 '07 #24

P: n/a
Diego Martins <jo********@gmail.comwrote:
On May 30, 2:14 pm, "Victor Bazarov" <v.Abaza...@comAcast.netwrote:
>Noah Roberts wrote:
[..]
If you can't answer the question, don't answer the question.

You've earned a position in my killfile for the second time!
Welcome back, Noah!

huh?! how a user could be 'killed' TWICE?
Some newsreaders allow you to add a person to the killfile for only a
set amount of time (e.g., 30 or 60 days) as well as indefinitely.

--
Marcus Kwok
Replace 'invalid' with 'net' to reply
Jun 1 '07 #25

P: n/a
On Fri, 01 Jun 2007 10:19:50 +1000, Gianni Mariani wrote:
Noah Roberts wrote:
>Gianni Mariani wrote:
...
>>I assume now you see bad_alloc exceptions and you don't know why ?
Maybe a corrupted heap ?
...
>>
I think they're giving up on it; my involvement kind of ended when I
discovered why it wasn't doing what I said it should be doing. It only
happens in some obscure condition under this weird test when running on
windows 2000 in a VM.

That's probably still a bug in the application code that will bite you
on your first deployment to a paying customer.
>... We don't expect that to come up a whole lot with our customer use
patterns. Something to fix later when we're screwing with that program
again...something that might get fixed just by slowly changing code to
use more reasonable coding standards.

Exceptions are kind of special in that I don't often see them used
correctly. Often programmers use it as a return value passing mechanism
rather than "fixing" the interfaces.

Exceptions in C++ could be much better - the nothrow semantics for
example could be compile-time enforced. Debugging with exceptions can
be non-trivial because you loose the context of the exception - this
needs the programmer to log much more information in the case of an
exception.

Exceptions are also used often where and abort should be. A coding
error should be terminal - i.e. stop the process and dump a core file
yet many developers throw an exception hoping to recover only further
exacerbating the problems. Classic case - I use a CAD program, when it
dies, it tries to save the work in progress only to often end up
corrupting the previously saved version.
Agreed totally. My understanding is that exceptions should best (only?)
be used when there is a possibility of recovering from the "exceptional"
condition - where "recovering" might sometimes mean "exit gracefully with
a meaningful error message".

As a case in point, I once had to write dynamic library code that would
be called from a third-party program (a Matlab-alike number cruncher) for
a fairly critical production system. My code could not afford to abort in
the case eg. of being called incorrectly from the third-party system, as
this would bomb out the entire third-party system. Rather, it had to
return an error code and a meaningful error message. By far the easiest
way to achieve this was via exceptions.

For my "personal" code - i.e. code which is not intended for use/
development by others - I frequently turn off exception handling via a
compiler switch which has the basic effect of passing all (eg. STL)
exceptions to a default handler which simply aborts the program (not
particularly gracefully...). The motivation is not so much for efficiency
reasons (although I write scientific code for which speed is frequently
an issue) but rather that I can't afford the time overhead of coding up
meaningful exception handling for code that I am enthusiastically hacking
on ;-)
While template phobia and not using constructors correctly are valid
criticisms, a healthy dose of reality check of use of exceptions is
something that needs to be evaluated more closely.
--
Lionel B
Jun 4 '07 #26

This discussion thread is closed

Replies have been disabled for this discussion.