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.
25  1440 
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
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(); }
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;
}
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.
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.
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
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.
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!
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
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
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??
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.
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.
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.
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.
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.
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 ?
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.
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.
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...
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.
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?
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.
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
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 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: mjm |
last post by:
Folks,
Stroustrup indicates that returning by value can be faster than
returning by reference but gives no details as to the size of the
returned object up to which this holds.
My question is...
|
by: Derek |
last post by:
Some authors advocate returning const objects:
const Point operator+(const Point&, const Point&);
^^^^^
Returning a const object prevents some bad code from compiling:
Point a, b, c;
(a +...
|
by: Fraser Ross |
last post by:
I need to know the syntax for writing a reference of an array. I haven't
seen it done often. I have a class with a member array and I want a member
function to return an reference to it. ...
|
by: Materialised |
last post by:
I am writing a simple function to initialise 3 variables to pesudo
random numbers.
I have a function which is as follows
int randomise( int x, int y, intz)
{
srand((unsigned)time(NULL));
x...
|
by: wonderboy |
last post by:
Hey guys,
I have a simple question. Suppose we have the following
functions:-
//-----My code starts here
char* f1(char* s)
{
char* temp="Hi";
return temp;
|
by: Randy |
last post by:
Hello,
I have a web service in which I'm doing a query to an Access database and
returning the resulting XML data when I do the return from the service...
public string AOS_Data(string sql)
{...
|
by: Faustino Dina |
last post by:
Hi,
The following code is from an article published in Informit.com at
http://www.informit.com/guides/content.asp?g=dotnet&seqNum=142. The problem
is the author says it is not a good idea to...
|
by: I.M. !Knuth |
last post by:
Hi. I'm more-or-less a C newbie. I thought I had pointers under control until
I started goofing around with this:
...
|
by: EvilOldGit |
last post by:
const Thing &operator++(int)
{
Thing temp = *this;
operator++();
return temp;
}
Is this code robust ?
I get a compiler warning about returning a reference to a a local,
which I guess is...
|
by: pauldepstein |
last post by:
Below is posted from a link for Stanford students in computer
science.
QUOTE BEGINS HERE
Because of the risk of misuse, some experts recommend never returning
a
reference from a function or...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| |
