::std sometimes needed, sometimes not

[Marcin Vorbrodt]

Hi there. How come when in one file i unclude <cmath> i need to use
std::tan(...), and in another file i include <cassert> and std::assert fails
to compile. Nowhere in my code i do using namespace std; Seams like some
things in my header files are in std namespace and some are not. Is that
correct, or is my compiler (mingw, 3.2 i think) horribly broken? :o)

Thanx,
Martin

[Alf P. Steinbach]

Re: ::std sometimes needed, sometimes not

On Mon, 15 Sep 2003 20:41:01 -0400, "Marcin Vorbrodt" <mvorbro@eos.nc su.edu> wrote:
[color=blue]
>Hi there. How come when in one file i unclude <cmath> i need to use
>std::tan(... ), and in another file i include <cassert> and std::assert fails
>to compile.[/color]

That's because assert is a macro. It doesn't live in a namespace; no
macro does. That's one problem with macros; the nice thing about them
is that they can pick up things like line number and so on.

[color=blue]
>Nowhere in my code i do using namespace std; Seams like some
>things in my header files are in std namespace and some are not. Is that
>correct[/color]

Yes, but there are only a handful or so of standard macros.

[color=blue]
>or is my compiler (mingw, 3.2 i think) horribly broken? :o)[/color]

Wrt. to some other things, yes, but it's still a very good compiler.

[Marcin Vorbrodt]

Re: ::std sometimes needed, sometimes not

OK, so is there a "C++" way of doing assert? A standard C++ class/template
or something that does assert? Also, is there a C++ alternative to <cmath>?

Thanx,
Martin


"Alf P. Steinbach" <alfps@start.no > wrote in message
news:3f665e75.3 03052046@News.C IS.DFN.DE...[color=blue]
> On Mon, 15 Sep 2003 20:41:01 -0400, "Marcin Vorbrodt"[/color]
<mvorbro@eos.nc su.edu> wrote:[color=blue]
>[color=green]
> >Hi there. How come when in one file i unclude <cmath> i need to use
> >std::tan(... ), and in another file i include <cassert> and std::assert[/color][/color]
fails[color=blue][color=green]
> >to compile.[/color]
>
> That's because assert is a macro. It doesn't live in a namespace; no
> macro does. That's one problem with macros; the nice thing about them
> is that they can pick up things like line number and so on.
>
>[color=green]
> >Nowhere in my code i do using namespace std; Seams like some
> >things in my header files are in std namespace and some are not. Is that
> >correct[/color]
>
> Yes, but there are only a handful or so of standard macros.
>
>[color=green]
> >or is my compiler (mingw, 3.2 i think) horribly broken? :o)[/color]
>
> Wrt. to some other things, yes, but it's still a very good compiler.
>[/color]

[Kevin Goodsell]

Re: ::std sometimes needed, sometimes not

Marcin Vorbrodt wrote:
[color=blue]
> OK, so is there a "C++" way of doing assert? A standard C++ class/template
> or something that does assert? Also, is there a C++ alternative to <cmath>?
>[/color]

Please don't top-post here. Read section 5 of the FAQ for posting
guidelines:

http://www.parashift.com/c++-faq-lite/

C++ doesn't have anything assert-like built in (other than assert), but
you could certainly create something, probably using an exception class
to carry the information about the error. Stroustrup has an example of
this somewhere, IIRC. Probably in "The C++ Programming Language".

<cmath> *is* the C++ alternative.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

[llewelly]

Re: ::std sometimes needed, sometimes not

Kevin Goodsell <usenet1.spamfr ee.fusion@never box.com> writes:
[color=blue]
> Marcin Vorbrodt wrote:
>[color=green]
> > OK, so is there a "C++" way of doing assert? A standard C++ class/template
> > or something that does assert? Also, is there a C++ alternative to <cmath>?
> >[/color]
>
> Please don't top-post here. Read section 5 of the FAQ for posting
> guidelines:
>
> http://www.parashift.com/c++-faq-lite/
>
> C++ doesn't have anything assert-like built in (other than assert),
> but you could certainly create something, probably using an exception
> class to carry the information about the error.[/color]

Before you write code signaling a programmer error with an exception,
read this thread on assert versus exceptions:

http://groups.google.com/groups?threadm=d6652001.0308290615.39d8d931@posting.google.com

or:

http://tinyurl.com/nhp7

[color=blue]
> Stroustrup has an
> example of this somewhere, IIRC. Probably in "The C++ Programming
> Language".[/color]
[snip]

He does. However, other experts have since argued that is generally
bad advice.

[Kevin Goodsell]

Re: ::std sometimes needed, sometimes not

llewelly wrote:
[color=blue]
>
>
> Before you write code signaling a programmer error with an exception,
> read this thread on assert versus exceptions:
>
> http://groups.google.com/groups?thre...ing.google.com
> or:
> http://tinyurl.com/nhp7[/color]

I don't know if you were talking specifically about the particular
message that link goes to, but I don't think I could disagree more with
this point:

- You definitely do NOT want to throw an exception in case of a
contract violation. It is very, very rare, if ever, that this is
correct. The program is incorrect, and you abort.

The fact that every function can potentially throw an exception
makes writing exception safe code pratically impossible.

A lot of people seem to want exceptions anyway:-). To keep them
happy, I would suggest some sort of callback, which the user can
replace. By default, the code should abort. If the user replaces
it with something which will throw, his code probably will not work
when the exception occurs. But since that's what he wanted...

This sounds like someone who doesn't understand exceptions to me.
[color=blue]
>
>[color=green]
>>Stroustrup has an
>>example of this somewhere, IIRC. Probably in "The C++ Programming
>>Language".[/color]
>
> [snip]
>
> He does. However, other experts have since argued that is generally
> bad advice.[/color]

Reference? Without reading the opposing argument, I'm very likely to
side with Stroustrup over some generic, unnamed "experts".

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

[Gianni Mariani]

Re: ::std sometimes needed, sometimes not

Kevin Goodsell wrote:[color=blue]
> llewelly wrote:[/color]

...
[color=blue]
>
>

> - You definitely do NOT want to throw an exception in case of a
> contract violation. It is very, very rare, if ever, that this is
> correct. The program is incorrect, and you abort.
>
> The fact that every function can potentially throw an exception
> makes writing exception safe code pratically impossible.
>
> A lot of people seem to want exceptions anyway:-). To keep them
> happy, I would suggest some sort of callback, which the user can
> replace. By default, the code should abort. If the user replaces
> it with something which will throw, his code probably will not work
> when the exception occurs. But since that's what he wanted...
>

>
> This sounds like someone who doesn't understand exceptions to me.
>[/color]

OK - time for some friendly debate.

I'll state that I use exceptions very rarely and hardly ever in
production code.

I actually agree the the quote 100% because I have done exactly that and
found that it is a very acceptable paradigm for developing solid and
easily maintainable code.

I have found that exceptions leed to sloppy code by less experienced
programmers and even some more experienced guys as well.

However, I'm open to suggestions. I'm only 90% conviced they're next to
useless. OK OK OK. In some rare circumstances I can see that they are
an acceptable alternative. In a test framework, I designed, throwing an
exception was a way to indicate a test failure, abort()ing was
unsatisfactory since it meant that other tests would have not been able
to run in that particular framework.

[Jonathan Mcdougall]

Re: ::std sometimes needed, sometimes not

>>

[color=blue][color=green]
>> - You definitely do NOT want to throw an exception in case of a
>> contract violation. It is very, very rare, if ever, that this is
>> correct. The program is incorrect, and you abort.
>>
>> The fact that every function can potentially throw an exception
>> makes writing exception safe code pratically impossible.
>>
>> A lot of people seem to want exceptions anyway:-). To keep them
>> happy, I would suggest some sort of callback, which the user can
>> replace. By default, the code should abort. If the user replaces
>> it with something which will throw, his code probably will not work
>> when the exception occurs. But since that's what he wanted...
>>

>>
>> This sounds like someone who doesn't understand exceptions to me.[/color][/color]
[color=blue]
>However, I'm open to suggestions. I'm only 90% conviced they're next to
>useless. OK OK OK. In some rare circumstances I can see that they are
>an acceptable alternative. In a test framework, I designed, throwing an
>exception was a way to indicate a test failure, abort()ing was
>unsatisfacto ry since it meant that other tests would have not been able
>to run in that particular framework.[/color]

I use exceptions primarily for signaling constructor failure, since it
is the only way. Do you have a workaround or you assume your ctors
always succeed ? :)

Jonathan

[Gianni Mariani]

Re: ::std sometimes needed, sometimes not

Jonathan Mcdougall wrote:[color=blue][color=green][color=darkred]
>>>

>>> - You definitely do NOT want to throw an exception in case of a
>>> contract violation. It is very, very rare, if ever, that this is
>>> correct. The program is incorrect, and you abort.
>>>
>>> The fact that every function can potentially throw an exception
>>> makes writing exception safe code pratically impossible.
>>>
>>> A lot of people seem to want exceptions anyway:-). To keep them
>>> happy, I would suggest some sort of callback, which the user can
>>> replace. By default, the code should abort. If the user replaces
>>> it with something which will throw, his code probably will not work
>>> when the exception occurs. But since that's what he wanted...
>>>

>>>
>>>This sounds like someone who doesn't understand exceptions to me.[/color][/color]
>
>[color=green]
>>However, I'm open to suggestions. I'm only 90% conviced they're next to
>>useless. OK OK OK. In some rare circumstances I can see that they are
>>an acceptable alternative. In a test framework, I designed, throwing an
>>exception was a way to indicate a test failure, abort()ing was
>>unsatisfactor y since it meant that other tests would have not been able
>>to run in that particular framework.[/color]
>
>
> I use exceptions primarily for signaling constructor failure, since it
> is the only way. Do you have a workaround or you assume your ctors
> always succeed ? :)
>[/color]

Very few contructors I create fail. bad_alloc is a given but I usually
have bigger problems than bad_alloc exceptions. (I think I have yet to
see a bad_alloc exception thrown in a production environment) With most
systems now allowing you to overcommit on memory, you're more likely to
get an access violation/segmentation fault when memory is depleted.

I'll give you that one, but I think it's rare and hence letting it abort
may be a suitable alternative most of the time.

Anything else ?

[Jonathan Mcdougall]

Re: ::std sometimes needed, sometimes not

>>>However, I'm open to suggestions. I'm only 90% conviced they're next to[color=blue][color=green][color=darkred]
>>>useless. OK OK OK. In some rare circumstances I can see that they are
>>>an acceptable alternative. In a test framework, I designed, throwing an
>>>exception was a way to indicate a test failure, abort()ing was
>>>unsatisfacto ry since it meant that other tests would have not been able
>>>to run in that particular framework.[/color]
>>
>>
>> I use exceptions primarily for signaling constructor failure, since it
>> is the only way. Do you have a workaround or you assume your ctors
>> always succeed ? :)
>>[/color]
>
>Very few contructors I create fail.[/color]

That's what I thought :)
[color=blue]
>bad_alloc is a given but I usually
>have bigger problems than bad_alloc exceptions.[/color]

And you usually abort on these problems?
[color=blue]
>(I think I have yet to
>see a bad_alloc exception thrown in a production environment)[/color]

Happens often when you try to run recent software on old machines,
believe me :)
[color=blue]
>With most
>systems now allowing you to overcommit on memory, you're more likely to
>get an access violation/segmentation fault when memory is depleted.[/color]

Mmm.. I didn't know that.
[color=blue]
>I'll give you that one, but I think it's rare and hence letting it abort
>may be a suitable alternative most of the time.[/color]

I think aborting is never a suitable alternative. Letting a catchable
exception propagate is imho bad programming. Trying something else
(or the same thing), warning the user, asking to save.. you know..
user-friendly programming. Nothing frustrates me more than a program
terminating without warning.

I long believed my programs would never fail as others do, but now I
try to do "preventive programming".

I understand there are problems you just cannot foresee or even solve
during runtime, but I try to do as much as possible to prevent my
applications from crashing.


Jonathan

[Gianni Mariani]

Re: ::std sometimes needed, sometimes not

Jonathan Mcdougall wrote:
....[color=blue]
> And you usually abort on these problems?[/color]

Yep.
[color=blue][color=green]
>>(I think I have yet to
>>see a bad_alloc exception thrown in a production environment)[/color]
>
>
> Happens often when you try to run recent software on old machines,
> believe me :)[/color]

Hmm. I have developed software that ran on thousands of machines and
other problems were reported, but out of memory errors were not among them.

[color=blue]
>
>[color=green]
>>With most
>>systems now allowing you to overcommit on memory, you're more likely to
>>get an access violation/segmentation fault when memory is depleted.[/color]
>
>
> Mmm.. I didn't know that.[/color]

I may have overstated that a bit, but I have seen this.
[color=blue]
>
>[color=green]
>>I'll give you that one, but I think it's rare and hence letting it abort
>>may be a suitable alternative most of the time.[/color]
>
>
> I think aborting is never a suitable alternative. Letting a catchable
> exception propagate is imho bad programming.[/color]


On some systems (Unix) you get a nice big fat core file pointing you to
the code and the reason for the fault. Sounds like a wonderful
alternative to me !

.... Trying something else[color=blue]
> (or the same thing), warning the user, asking to save.. you know..
> user-friendly programming. Nothing frustrates me more than a program
> terminating without warning.[/color]

Sometimes there are more important features. If you can solve the
problem with a memory upgrade, it's often cheaper than complicating your
code.
[color=blue]
>
> I long believed my programs would never fail as others do, but now I
> try to do "preventive programming".
>
> I understand there are problems you just cannot foresee or even solve
> during runtime, but I try to do as much as possible to prevent my
> applications from crashing.[/color]

Not letting them happen in the first place is the key.

There are ways to guarentee that you can't get a bad_alloc but it
requires knowing before-hand what you're going to need - essentially
pre-allocating the memory.

Seems like alot of trouble for not alot of gain.

If I'm not mistaken, it sounds like we may have a different bias but we
agree on the problem.

[Kevin Goodsell]

Re: ::std sometimes needed, sometimes not

Gianni Mariani wrote:[color=blue]
> Kevin Goodsell wrote:[color=green]
>>
>>

>> - You definitely do NOT want to throw an exception in case of a
>> contract violation. It is very, very rare, if ever, that this is
>> correct. The program is incorrect, and you abort.
>>
>> The fact that every function can potentially throw an exception
>> makes writing exception safe code pratically impossible.
>>
>> A lot of people seem to want exceptions anyway:-). To keep them
>> happy, I would suggest some sort of callback, which the user can
>> replace. By default, the code should abort. If the user replaces
>> it with something which will throw, his code probably will not work
>> when the exception occurs. But since that's what he wanted...
>>

>>
>> This sounds like someone who doesn't understand exceptions to me.
>>[/color]
>
> OK - time for some friendly debate.
>
> I'll state that I use exceptions very rarely and hardly ever in
> production code.
>
> I actually agree the the quote 100% because I have done exactly that and
> found that it is a very acceptable paradigm for developing solid and
> easily maintainable code.[/color]

I don't think that library code should ever unilaterally abort the
program. Besides that, doing so causes objects to go undestructed,
leading to resource leaks (sure, most modern desktop systems clean up
when the process terminates, but you can't count on that in portable code).

I don't understand why you would prefer aborting to throwing an
exception anyway. What's the worst case for throwing an exception? It's
not caught, and the program aborts. So by aborting instead of throwing,
you're ensuring that you always get the worst case.
[color=blue]
>
> I have found that exceptions leed to sloppy code by less experienced
> programmers and even some more experienced guys as well.
>
> However, I'm open to suggestions. I'm only 90% conviced they're next to
> useless. OK OK OK. In some rare circumstances I can see that they are
> an acceptable alternative. In a test framework, I designed, throwing an
> exception was a way to indicate a test failure, abort()ing was
> unsatisfactory since it meant that other tests would have not been able
> to run in that particular framework.[/color]

Well, I have to admit that I don't have a lot of experience actually
using exception handling, but I like it a lot. I find that it makes code
considerably easier to write, and less cluttered. During development of
a library, I just catch everything in main and print the what() string.
That way when I run a quick test I get a nice little report of what went
wrong (if anything). In a program using the library I just catch
wherever is most appropriate.

I don't know what else to even say about it. It makes things so simple I
can't imagine why you wouldn't want to use it. I hate having to
constantly check return values for errors. Speaking of sloppy
programming, how often do people forget to check return values? It's a
bit harder to ignore an exception, and easier to track down the
resulting problem if you do. Ignore a return value and your program may
limp along in an undefined state for a while before crashing in some
other part of the program. With an uncaught exception it's immediate,
and the debugger can show you where it was thrown from.

I might have to ask you to explain to me what's so bad about exceptions. :-/

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

[Jerry Coffin]

Re: ::std sometimes needed, sometimes not

In article <jrv9b.4832$UN4 .245@newsread3. news.pas.earthl ink.net>,
usenet1.spamfre e.fusion@neverb ox.com says...

[ commenting on a quote from James Kanze ... ]
[color=blue]
> This sounds like someone who doesn't understand exceptions to me.[/color]

Others would disagree. Just for example, Herb Sutter (author of
Exceptional C++, More Exceptional C++ and an upcoming and TTBOMK, as yet
unnamed book on exceptions) lists James Kanze as "guru" here:

http://www.gotw.ca/gotw/056.htm

[ ... ]
[color=blue]
> Reference? Without reading the opposing argument, I'm very likely to
> side with Stroustrup over some generic, unnamed "experts".[/color]

I'm not sure of the arguments in question either, but if James Kanze is
among those making the argument, I'd guess that at the very least, it's
worth studying in detail. Herb Sutter isn't the only one who names or
acknowledges him either -- he is, for example, listed in the
acknowledgement s of a number of books I have handy, including (for one
example) _C++ In a Nutshell_, from O'Reilly and Associates (who
generally aren't disposed toward publishing really bad books anyway).

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Jerry Coffin]

Re: ::std sometimes needed, sometimes not

In article <Cqx9b.4983$UN4 .681@newsread3. news.pas.earthl ink.net>,
usenet1.spamfre e.fusion@neverb ox.com says...

[ ... ]
[color=blue]
> I don't understand why you would prefer aborting to throwing an
> exception anyway. What's the worst case for throwing an exception? It's
> not caught, and the program aborts. So by aborting instead of throwing,
> you're ensuring that you always get the worst case.[/color]

A contrast violation means there is something wrong with the code (i.e.
a bug) that has been found and noted, and needs to be fixed.

In this case, aborting is a LONG ways from being the worst case. Quite
the contrary: the worst case is that the problem is allowed to continue
unnoticed for some arbitrary period of time -- almost inevitably, the
longer a bug persists, the more difficult and expensive it is to fix.
Therefore, when you DO find what you're sure is a bug in some code, the
best case is to ensure that it fails as quickly, dependably and
spectacularly as possible, so it will be fixed as soon as possible
instead of being allowed to persist.

The problem with throwing an exception in a case like this is that it's
all too easy (and common) for somebody to do something like this:

int main(int argc, char **argv) {
do {
try {
return real_main(argc, char **argv);
}
catch(...) {
std::cerr<<"Som e problem -- retrying\n";
}
} while(1);
return 0; // never really executes
}

In fact, almost any instance of "catch(...) " can cover up an almost
arbitrary collection of problems that the library designer is TRYING to
make sure get noticed.

One way to avoid that is to abort instead of throwing an exception -- as
long as you're sure that what you've got is a bug in the code, and not
something from which recovery is reasonable, abort() is a better option
precisely because it prevents any other part of the code from covering
up the problem.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Attila Feher]

Re: ::std sometimes needed, sometimes not

Jerry Coffin wrote:[color=blue]
> In article <jrv9b.4832$UN4 .245@newsread3. news.pas.earthl ink.net>,
> usenet1.spamfre e.fusion@neverb ox.com says...
>
> [ commenting on a quote from James Kanze ... ]
>[color=green]
>> This sounds like someone who doesn't understand exceptions to me.[/color]
>
> Others would disagree. Just for example, Herb Sutter (author of
> Exceptional C++, More Exceptional C++ and an upcoming and TTBOMK, as
> yet unnamed book on exceptions) lists James Kanze as "guru" here:[/color]

James is a guru. A practical one. So some of his advice is not about how
to do things in a perfect world where all compilers are conforming to the
standard, but how to do things in the real world. He is a top consultant
and rather a pragmatic, real-world guy than a language lawyer. It is worth
to listen to him.

--
Attila aka WW