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