 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] san rrcom> 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
|
|
| |
| |
|
|
|
|
| |
