http://www.computerweekly.com/blogs/it-downtime-blog/2008/04/error-messages-you-never-want-1.html

:-)

-- 
I will be brief but not nearly so brief as Salvador Dali, who gave the
world's shortest speech. He said, "I will be so brief I am already
finished," then he sat down.

Post a reply to this message

Doctor John escribió:
>
http://www.computerweekly.com/blogs/it-downtime-blog/2008/04/error-messages-you-never-want-1.html

CodeProject has an interesting error message I stumbled upon a few times:

"Error Page Error. err...

Unfortunately it seems that our error handling page has, ironically, an 
error. It's going to be one of those days."

Post a reply to this message

Unfortunately, it has become common for programs to give messages such 
as "an unexpected error has occurred. Sorry."

[BTW, WTF is an *expected* error anyway??]

When I was at college, this would _never_ do. Programs are expected to 
"fail gracefully" - and they are expected to provide *meaningful* error 
condition descriptions. Any program that didn't would be harshly 
down-marked. The people at that college may not have known anything 
about Pascal, but they knew about program design! o_O

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

"Orchid XP v8" <voi### [at] devnull> wrote

> Unfortunately, it has become common for programs to give messages such
> as "an unexpected error has occurred. Sorry."
>
> [BTW, WTF is an *expected* error anyway??]

Actually, the above *is* an example of an expected error (the programmer put
that message in, didn't he?). Unexpected errors either go unnoticed or crash
the system.

> When I was at college, this would _never_ do. Programs are expected to
> "fail gracefully" - and they are expected to provide *meaningful* error
> condition descriptions.

Well, real life begins when college ends.

Post a reply to this message

>> When I was at college, this would _never_ do. Programs are expected to
>> "fail gracefully" - and they are expected to provide *meaningful* error
>> condition descriptions.
> 
> Well, real life begins when college ends.

Not necessarily. I'm still waiting for my "real" life to begin... :-/

BTW, irony: At college, we had a C compiler that used to give us all 
this error message, and to this day nobody knows what that message 
actually means. Including the tutors. Hmm. ;-)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 escribió:
> BTW, irony: At college, we had a C compiler that used to give us all 
> this error message, and to this day nobody knows what that message 
> actually means. Including the tutors. Hmm. ;-)

Yay for open source. You could have looked into the compiler code :)

Post a reply to this message

Orchid XP v8 <voi### [at] devnull> wrote:
> [BTW, WTF is an *expected* error anyway??]

  For example incorrect input, network connection problems, hardware
failures (such as inability to read from disc), etc. etc.

  Even seen eg. those 404 messages? That's an expected error which
sometimes happens.

  An unexpected error is something which shouldn't happen but happened
anyways (instead of the program crashing, the unexpected situation was
caught).

-- 
                                                          - Warp

Post a reply to this message

. wrote:
> "Orchid XP v8" <voi### [at] devnull> wrote

> > Unfortunately, it has become common for programs to give messages such
> > as "an unexpected error has occurred. Sorry."
> >
> > [BTW, WTF is an *expected* error anyway??]

> Actually, the above *is* an example of an expected error (the programmer put
> that message in, didn't he?). Unexpected errors either go unnoticed or crash
> the system.

  Wrong. Unexpected errors are things which should never happen, and if
they do the indicate a bug in the program.
  Typical example:

switch(something)
{
 case A: ...
 case B: ...
 ...

 default:
    error("Unexpected error happened.");
    // This should never happen because all possible cases were dealt above.
    // If we ever get here, it's a clear sign of a bug in the program.
}

-- 
                                                          - Warp

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message
news:481a2348@news.povray.org...
> . wrote:
> > "Orchid XP v8" <voi### [at] devnull> wrote

> > > Unfortunately, it has become common for programs to give messages such
> > > as "an unexpected error has occurred. Sorry."
> > >
> > > [BTW, WTF is an *expected* error anyway??]

> > Actually, the above *is* an example of an expected error (the programmer
put
> > that message in, didn't he?). Unexpected errors either go unnoticed or
crash
> > the system.

>  Wrong. Unexpected errors are things which should never happen, and if
>  they do

Want to rephrase that? <g>

> the indicate a bug in the program.
>   Typical example:
>
> switch(something)
> {
>  case A: ...
>  case B: ...
>  ...
>
>  default:
>     error("Unexpected error happened.");
>     // This should never happen because all possible cases were dealt
above.
>     // If we ever get here, it's a clear sign of a bug in the program.
> }

No, the error is either expected, but programmer shows bad form (ie, the
programmer anticipates "illegal" input but doesn't check it at the procedure
entry, and instead does it inside program logic) or a pointless exercise, as
in:

If ((X=True)=True)=True Then ... //just making sure!...

or

If X=4 Then
   ...
Else if X<>4 Then
  ...
Else
  Exception()..

Sure, QM, if nothing else, tells us that there are no guarantees, but it's
pointless to expect an error where it cannot logically be, or raise
exceptions in places that cannot logically be reached. Conversely, under
abnormal circumstances, all opcodes are suspect.

I agree, however, that "unexpected errors" are bugs.

PS. Yes, I know, some programming languages are perverse enough that the
code above makes sense.

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message
news:481a22ae@news.povray.org...
> Orchid XP v8 <voi### [at] devnull> wrote:
> > [BTW, WTF is an *expected* error anyway??]

>   For example incorrect input, network connection problems, hardware
> failures (such as inability to read from disc), etc. etc.
>
>   Even seen eg. those 404 messages? That's an expected error which
> sometimes happens.

404 is not an error on the part of the server but a perfectly well defined
and normal response. If I ask you for a glass of wine and you tell me
there's no wine, that doesn't indiate an error on your part. An error would
be if you tell me "green" in response to the question "what colour is
wine?". One cannot even say it's an error on part of the client - it depends
on context. If the client is, say, purposefully sending a bunch of random or
semi random requests (maybe DOS attack), then it's not in error when
requesting nonexistant pages. Programmers call responses like 404 errors out
of sloppiness or laziness.

Post a reply to this message

On Thu, 01 May 2008 17:30:35 +0100, Doctor John wrote:

> http://www.computerweekly.com/blogs/it-downtime-blog/2008/04/error-
messages-you-never-want-1.html
> 
> :-)

I still prefer the one I got from Windows + a biometric scanner (during 
GINA login):  "An error occurred:  The operation was successful".  Oh, 
and it wouldn't log me in (I wish I could've gotten a screenshot)

Jim

Post a reply to this message

On Thu, 01 May 2008 19:27:54 +0100, Orchid XP v8 wrote:

> [BTW, WTF is an *expected* error anyway??]

In eDirectory, it's not uncommon to see -601 errors (object not found) in 
a number of circumstances, and in some of those circumstances, the error 
is expected (such as a user mistypes their username).

Jim

Post a reply to this message

>> BTW, irony: At college, we had a C compiler that used to give us all 
>> this error message, and to this day nobody knows what that message 
>> actually means. Including the tutors. Hmm. ;-)
> 
> Yay for open source. You could have looked into the compiler code :)

Nah. Today I can just ask Warp what it means. ;-)

Hey Warp, what does it mean when you call printf() and the compiler says 
"suspicious pointer conversion"?

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Hey Warp, what does it mean when you call printf() and the compiler says 
> "suspicious pointer conversion"?

  Difficult to say without seeing the actual code.

-- 
                                                          - Warp

Post a reply to this message

Jim Henderson wrote:

> I still prefer the one I got from Windows + a biometric scanner (during 
> GINA login):  "An error occurred:  The operation was successful".  Oh, 
> and it wouldn't log me in (I wish I could've gotten a screenshot)

Well *clearly* a Windows operation being successful would indicate an 
error; Windows operations are designed to _fail_. ;-)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Warp wrote:
> Invisible <voi### [at] devnull> wrote:
>> Hey Warp, what does it mean when you call printf() and the compiler says 
>> "suspicious pointer conversion"?
> 
>   Difficult to say without seeing the actual code.

OK, well obviously 10 years later I don't still have it. All I can 
remember is that *loads* of people used to get this error. And it always 
seemed to involve printf().

I also remember that several people found that when you run their 
compiled program, it dumps many, many pages of gibberish to the console, 
and beeps repeatedly, until [if you're lucky] it would randomly stop. 
Presumably this is because you gave printf() an int when it was 
expecting a char*, and it's now printing out the contents of the 
machine's RAM until it happens upon a zero octet... (The deeps are due 
to the 0x07 BEL characters.)

I presume this doesn't work on a protected-mode OS?

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> I presume this doesn't work on a protected-mode OS?

  Well, the program has some memory allocated for itself, so if the pointer
happens to point to such memory, it will print gibberish. If it points to
unallocated memory you get a segmentation fault.

  The C++ version of printing to stdout (or to a stream) is much safer
from this point of view. (While you *can* make it behave the same way,
it's much harder to do so accidentally.)

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Invisible <voi### [at] devnull> wrote:
>> I presume this doesn't work on a protected-mode OS?
> 
>   Well, the program has some memory allocated for itself, so if the pointer
> happens to point to such memory, it will print gibberish. If it points to
> unallocated memory you get a segmentation fault.

Right. Thought so...

>   The C++ version of printing to stdout (or to a stream) is much safer
> from this point of view. (While you *can* make it behave the same way,
> it's much harder to do so accidentally.)

I don't really know C++, but from what little I've seen printing *looks* 
safer...


OOC, how does C do argument passing? [I'm puzzled as to why it's 
possible for a function with variable arguments to exist.]

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> I don't really know C++, but from what little I've seen printing *looks* 
> safer...

  It's more modular too. For example, assume you have abstracted away
a type like this:

typedef int MyType;

  And somewhere else in the code you have something like:

MyType value = something;
printf("The value is: %i\n", value);

  That 'printf' assumes the type is an integer. What happens if you later
change the type? For example like:

typedef double MyType;

  What happens is that the printf breaks horribly and will print gibberish.

  That won't happen using the C++ style:

MyType value = something;
std::cout << "The value is: " << value << "\n";

  Now if the value type changes the output will still be correct.

> OOC, how does C do argument passing? [I'm puzzled as to why it's 
> possible for a function with variable arguments to exist.]

  The C standard (and consequently the C++ standard) defines a special
mechanism for passing a variable amount of arguments to a function.
Simply put, you can declare a function like:

void foo(...);

and then you can call it like:

foo(any, amount, of, arguments, you, want);

  Of course C being C, there's no way for the function to know how many
arguments were passed and what was their type. printf() solves this with
the format string given as first parameter. (And its problem is, of course,
that it simply trusts that the amount and type of the arguments corresponds
to the given format string.)

  The C standard defines special macros which can be used inside foo() to
retrieve the given arguments.

  From the compiler's point of view the implementation of this is rather
simple: All the function parameters are pushed onto the stack, and then
the foo() function simply pops them from the stack. But as I said, there's
no type checking nor anything. It's all just "raw". (But it's not like
there wouldn't be *any* advantage at all in this: The advantage is, of
course, that it's quite fast and memory-efficient to do it this way.)

-- 
                                                          - Warp

Post a reply to this message

On Fri, 02 May 2008 09:02:45 +0100, Invisible wrote:

> Jim Henderson wrote:
> 
>> I still prefer the one I got from Windows + a biometric scanner (during
>> GINA login):  "An error occurred:  The operation was successful".  Oh,
>> and it wouldn't log me in (I wish I could've gotten a screenshot)
> 
> Well *clearly* a Windows operation being successful would indicate an
> error; Windows operations are designed to _fail_. ;-)

That was my thinking; the MS consultants who were there were absolutely 
beside themselves trying to figure out what was going on.

Jim

Post a reply to this message

Warp wrote:
>   From the compiler's point of view the implementation of this is rather
> simple: All the function parameters are pushed onto the stack, and then
> the foo() function simply pops them from the stack. 

Well, technically, the foo() function indexes into the stack (with a 
compiler-provided macro to move the stack pointer into a pointer 
variable, basically), and then whoever called foo() has to pop the 
arguments. Which is one reason you don't see many "ret N" instructions 
in compiled C code - the callee never knows how many arguments the 
caller pushed.  (Altho you'd think that's something the compiler could 
optimize if you didn't have a variable numbers of arguments for a 
particular function.)

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

Jim Henderson wrote:
> That was my thinking; the MS consultants who were there were absolutely 
> beside themselves trying to figure out what was going on.

FWIW, that usually happens when a function returns an error indication 
but doesn't set the secondary information that says what error it was. 
Or, in C terminology, the function returned -1 but didn't assign 
anything to errno.   Yet one more reason to dislike C. :-)

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

On Fri, 02 May 2008 09:53:59 -0700, Darren New wrote:

> Jim Henderson wrote:
>> That was my thinking; the MS consultants who were there were absolutely
>> beside themselves trying to figure out what was going on.
> 
> FWIW, that usually happens when a function returns an error indication
> but doesn't set the secondary information that says what error it was.
> Or, in C terminology, the function returned -1 but didn't assign
> anything to errno.   Yet one more reason to dislike C. :-)

Oh, yes, I do know that side of the coding - but that didn't make it any 
less funny, especially to see the MS consultants (and I'm not saying 
"Consultants who consult on Microsoft technologies", but "Microsoft 
Consulting") try to figure that one out. :-)

Jim

Post a reply to this message

"Jim Henderson" <nos### [at] nospamcom> wrote in message
news:481b5695@news.povray.org...
> On Fri, 02 May 2008 09:53:59 -0700, Darren New wrote:

> (and I'm not saying
> "Consultants who consult on Microsoft technologies", but "Microsoft
> Consulting")

I've worked with some guys from MCS before. Some are really good. Others are
.... not so good. (to put it politely)

Post a reply to this message

Invisible wrote:
> Jim Henderson wrote:
> 
>> I still prefer the one I got from Windows + a biometric scanner 
>> (during GINA login):  "An error occurred:  The operation was 
>> successful".  Oh, and it wouldn't log me in (I wish I could've gotten 
>> a screenshot)
> 
> Well *clearly* a Windows operation being successful would indicate an 
> error; Windows operations are designed to _fail_. ;-)
> 
My interpretation was that because an error occurred the process could 
not validated your login, hence it should not log you in and indeed it 
was successful at not letting you in. In my opinion it is thus a 
correct, though slightly confusing, message.

Post a reply to this message

On Fri, 02 May 2008 20:23:38 +0200, Gail Shaw wrote:

> "Jim Henderson" <nos### [at] nospamcom> wrote in message
> news:481b5695@news.povray.org...
>> On Fri, 02 May 2008 09:53:59 -0700, Darren New wrote:
> 
>> (and I'm not saying
>> "Consultants who consult on Microsoft technologies", but "Microsoft
>> Consulting")
> 
> I've worked with some guys from MCS before. Some are really good. Others
> are .... not so good. (to put it politely)

The guys I worked with were pretty good - and they did appreciate the 
humour of the situation. :-)

Jim

Post a reply to this message

On Fri, 02 May 2008 21:17:36 +0200, andrel wrote:

> Invisible wrote:
>> Jim Henderson wrote:
>> 
>>> I still prefer the one I got from Windows + a biometric scanner
>>> (during GINA login):  "An error occurred:  The operation was
>>> successful".  Oh, and it wouldn't log me in (I wish I could've gotten
>>> a screenshot)
>> 
>> Well *clearly* a Windows operation being successful would indicate an
>> error; Windows operations are designed to _fail_. ;-)
>> 
> My interpretation was that because an error occurred the process could
> not validated your login, hence it should not log you in and indeed it
> was successful at not letting you in. In my opinion it is thus a
> correct, though slightly confusing, message.

That's possible - Digital Persona (whose stuff we were using) had 
absolutely no idea what the issue was.  We ended up rebuilding the 
machine - it borked things up so badly that even booting in safe mode 
didn't work (ISTR we ended up with no ability to login at all even in 
safe mode).

Jim

Post a reply to this message

Invisible wrote:
> Jim Henderson wrote:
> 
>> I still prefer the one I got from Windows + a biometric scanner 
>> (during GINA login): "An error occurred: The operation was 
>> successful". Oh, and it wouldn't log me in (I wish I could've gotten a 
>> screenshot)
> 
> Well *clearly* a Windows operation being successful would indicate an 
> error; Windows operations are designed to _fail_. ;-)
> 

I actually saw a couple of programming languages designed around that 
concept.  One of them was termed "quantum", in that any operation in it 
had a 90% chance of success, and a 10% chance of alternative behavior.

The other language was designed such that all program logic was 
controlled through purposefully causing errors.

I don't remember the name of either language, but I'm sure others here do.

...Chambers
www.pacificwebguy.com

Post a reply to this message

Warp wrote:

>  default:
>     error("Unexpected error happened.");
>     // This should never happen because all possible cases were dealt above.
>     // If we ever get here, it's a clear sign of a bug in the program.

or of memory corruption. :-)

Where I work, most default cases mean: "stop the train".

--
Jonathan.

Post a reply to this message

Warp wrote:
> MyType value = something;
> std::cout << "The value is: " << value << "\n";

Here's something I've been wondering about that. Say you have your own 
type, and you want a set of flags like hex/oct/decimal or setfill or 
something like that. I.e., you want to be able to say

std::cout << prettyprintindent(4) << myvalue << "\n";

Where does the "4" there get stored? And how can you make it so that 
(say) passing -1 puts back what it was before the previous call for the 
same stream? It would seem that you'd need some sort of data structure 
mapping streams to pretty print indent levels, yes? And no automated way 
of cleaning that up with a destructor?

What am I missing here?




Incidentally, I've seen the problem with printf that you're talking 
about here solved by doing something like this:

typedef long MyInt;
#define MyIntPrintf "%l"

Then, you write something like
   MyInt counter;
   printf("I counted " MyIntPrintf " instances\n", counter);
so it's really not that much harder to change, if at all.

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

Darren New wrote:
> Warp wrote:
>> MyType value = something;
>> std::cout << "The value is: " << value << "\n";
> 
> Here's something I've been wondering about that. Say you have your own 
> type, and you want a set of flags like hex/oct/decimal or setfill or 
> something like that. I.e., you want to be able to say
> 
> std::cout << prettyprintindent(4) << myvalue << "\n";
> 
> Where does the "4" there get stored? And how can you make it so that 
> (say) passing -1 puts back what it was before the previous call for the 
> same stream? It would seem that you'd need some sort of data structure 
> mapping streams to pretty print indent levels, yes? And no automated way 
> of cleaning that up with a destructor?
> 
> What am I missing here?

I believe you would create a separate class which inherits from OStream, 
and give it a data member to store the 4 in.  You would then define the 
function prettyprintindent(int) to return your subclass.  Since it 
inherits, it can still be used like a regular OStream.

...Chambers

Post a reply to this message

On Sun, 04 May 2008 03:39:20 +0200, Darren New <dne### [at] sanrrcom> wrote:
> Here's something I've been wondering about that. Say you have your own
  

> type, and you want a set of flags like hex/oct/decimal or setfill or  

> something like that. I.e., you want to be able to say
>
> std::cout << prettyprintindent(4) << myvalue << "\n";
>
> Where does the "4" there get stored?

Did you not ask this once before?

http://groups.google.com/group/comp.lang.c++.moderated/search?q=custom
+stream+manipulator

Also, look up 'ios::xalloc'.



> And how can you make it so that (say) passing -1 puts back what it was
  

> before the previous call for the same stream?

http://www.boost.org/doc/libs/1_35_0/libs/io/doc/ios_state.html#user_sav
ers

Perhaps not exactly what you meant, but doing it this way avoids resourc
e  

management issues.


> It would seem that you'd need some sort of data structure mapping stre
ams
> to pretty print indent levels, yes? And no automated way of cleaning t
hat
> up with a destructor?

If you impose a fixed (and relatively small) limit on the history size, 
 

you could store all the relevant information in the stream itself. For  

automatic cleanup of arbitrary amounts of per-stream data, I think you  

might need to use custom streams.


-- 

FE

Post a reply to this message

Ben Chambers wrote:
> I believe you would create a separate class which inherits from OStream, 
> and give it a data member to store the 4 in.  You would then define the 
> function prettyprintindent(int) to return your subclass.  Since it 
> inherits, it can still be used like a regular OStream.

Which means you now have two instances pointing to the same stream?

std:cout << pretty(4) << myvalue;
std:cout << myvalue; // No longer pretty(4)?

yadda = (std:cout << pretty(4));
yadda << mine << yours;
// Now what do I do to clean up?

std:cout << pretty(4) << myprettyvalue << magic(15) << mymagicvalue;
// Looks like magic(15) has to understand "pretty" streams?

// Or even
std:cout << pretty(4) << myprettyvalue <<
   magic(15) << mymagicvalue
   << pretty(8) << myprettyvalue;

How many copies of the "pretty" value are going to be in the
thing returned by the final << operator?

Fredrik Eriksson wrote:
> Did you not ask this once before?

Yeah, but not I understand other things a bit better, so I'm trying to 
figure this one out again.  Those links you gave really don't answer the 
question, as they seem to be answering too-simple questions.

Ah, I begin to see. ios can allocate a word in each stream specific to 
your class.

> Also, look up 'ios::xalloc'.

Ok. It looks like it only works for one integer from one user-defined 
type at a time, and if you cast it to a pointer, it still doesn't get 
cleaned up when the stream goes out of scope, because there's no type 
information. Or am I misunderstanding that? If you allocate (say) a 
buffer or something for the stream, at what point does that buffer get 
cleaned up?

So it looks like the answer is either "you can't do this with standard 
streams" or "for very limited cases it's built into the stream class 
already".

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

On Sun, 04 May 2008 23:36:38 +0200, Darren New <dne### [at] sanrrcom> wrote:
>> Also, look up 'ios::xalloc'.
>
> Ok. It looks like it only works for one integer from one user-defined  
> type at a time,

The words allocated with 'ios::xalloc' are not related to any user-defined  
types. They have only whatever meaning you choose to give them.



> and if you cast it to a pointer, it still doesn't get cleaned up when  
> the stream goes out of scope,

Correct. The stream object itself neither knows nor cares what you store  
there.



> If you allocate (say) a buffer or something for the stream, at what  
> point does that buffer get cleaned up?

If you mean "automatically" then not at all.



> So it looks like the answer is either "you can't do this with standard  
> streams" or "for very limited cases it's built into the stream class  
> already".

Depending on your definition of "very limited", yes.



-- 
FE

Post a reply to this message

Fredrik Eriksson wrote:
> The words allocated with 'ios::xalloc' are not related to any 
> user-defined types. They have only whatever meaning you choose to give 
> them.

Right, OK.

>> and if you cast it to a pointer, it still doesn't get cleaned up when 
>> the stream goes out of scope,
> 
> Correct. The stream object itself neither knows nor cares what you store 
> there.

Yeah. I'd just been thinking about Warp's example earlier that needed 
"weak" references to actually not "leak" resources. I was trying to 
figure out how C++ handled it, if at all.

> If you mean "automatically" then not at all.

OK.

> Depending on your definition of "very limited", yes.

By "limited" I mean "for anything other than an integer, like say an 
instance of a user-defined class." :-)

Thanks for the clarification!

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Yeah. I'd just been thinking about Warp's example earlier that needed 
> "weak" references to actually not "leak" resources. I was trying to 
> figure out how C++ handled it, if at all.

  Stream manipulation flags are one thing which is shamefully bad designed
in C++, and I really don't understand what they were thinking of.

  A few flags are set only until the next output action which is affected
by that flag (after which it's automatically reset). However, the rest are
permanently set until they are explicitly reset. This means that these
flags can "leak". For example this may well happen:

std::cout << 10 << std::endl;
foo();
std::cout << 10 << std::endl;

  If foo() calls, for example, std::hex(std::cout), then what is printed is:

10
a

  foo() could alleviate this problem by storing the flags into a variable
at the beginning and then restoring those flogs when it ends, but as we
all know, functions can have surprising exit points. (It's still possible
to make sure that the flags are restored at any exit point by using the
destructor mechanism of C++, but it becomes a bit more laborious. I'm
actually surprised the standard library doesn't offer an class type for
this exact purpose...)

-- 
                                                          - Warp

Post a reply to this message