![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Jim Henderson" <nos### [at] nospam com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Fri, 02 May 2008 20:23:38 +0200, Gail Shaw wrote:
> "Jim Henderson" <nos### [at] nospam com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |