Why does x.ToString() throw an error if x == null?

On Wed, 27 Aug 2008 23:04:23 -0700, Michael C <mikec@nospam.com> wrote:

> "Peter Duniho" <NpOeStPeAdM@nnowslpianmk.com> wrote in message
> newsp.ugks72158jd0ej@petes-computer.local...
>> That's only partly true. For virtual methods, it _does_ have to raise
>> an
>> exception.
>
> No, it can do whatever the designers decide it can do.

You should probably learn a little more about virtual methods (functions)
(particularly as they are implemented in langauges like C++, C#, VB.NET
and Java) before you make any more claims like that. Here's a decent
place to start:
http://en.wikipedia.org/wiki/Virtual_table

> They could have
> called the ToString method if they had wanted to. Possibly there are
> disadvantages but say it is not possible is just plain wrong.

No, it's exactly right. By definition, a virtual method needs an
instance. The run-time can't just go picking arbitrary methods to call
when there's a null reference, and the compiler doesn't emit enough
information for the run-time to know what the static typing of the
variable was.

> [...]
> Oh yes it can stoopid.

Ah, right. I forgot that when you run out of words, you start calling
people names. That really helps you look credible.

Pete

"Peter Duniho" <NpOeStPeAdM@nnowslpianmk.com> wrote in message
newsp.ugk20myx8jd0ej@petes-computer.local...
> You only find me "very negative and unpleasant" because you tend to post
> things that don't make sense, which I then find myself correcting. It's
> unfortunate that you don't handle disagreement and critique any better
> than you do. Suffice to say, I don't go out of my way to upset you; you
> just take it upon yourself to interpret things that way.

Possibly you are unaware of how you come across. This post is the perfect
example, I was just throwing out a suggestion that was kindof tongue in
cheek but you got out of your way to shoot the idea down. The funny thing is
there a real valid points you could have brought up you didn't and most of
what you did post was rubbish.

> Witness the fact that in spite of me not writing anything significantly
> different from what Alberto's written, you've already got that big chip
> sitting up on your shoulder. You're just itching for a fight.

No, I'm just going by your past posts.

> If that's true, then the term "global" is meaningless. If the word can't
> be used to distinguish one kind of method from another, what's the point
> of using it?

It's just a simple point I was making that under the hood every function is
a global function. The fact that you feel the need to argue even this says
something.

> That said, using more widely accepted definitions of "global", it's not
> true at all that "every function under the hood is global". The word
> "global" refers to identifiers that require no qualification in order to
> be resolved. It doesn't even make sense to talk about "global" with
> respect to "under the hood", because "global" is an artifact of the
> higher-level language being used.

You're arguing crap again peter. This is a minor issue not worth getting
into a debate about. In assembler all functions are global.

> In C#, there are no globals. Period. Everything requires qualification,
> being contained at a minimum inside a class that's inside a namespace.

Wow, who would have thought.

> No. If you were talking about C++, that would not be far from the truth.
> But for managed code, the run-time is a lot more involved, while the C#
> compiler leaves these things to the run-time. The C# compiler isn't
> "tricking us" about anything.

<sigh> This is why I generally avoid having a conversation with you.

> I suggest you take a look at the code generated by the C# compiler. You
> would find it educational.

Many thanks peter, I will take that into account.

> In C#? Yes, there is. The C# compiler has no control over the rules the
> run-time imposes.

Whatever, MS could have done it.

> Even more generally, you simply cannot call a virtual method without an
> instance. You couldn't even do what you're talking about in plain,
> unmanaged C++. If you still think you can call a virtual method without
> an instance, I encourage you to post the C++ code that would do so.

If MS wanted to do it they could. They could just use the VTable for the
type.

> Um, no. That's far from obvious. Even aside from the inconsistency issue
> I pointed out, the fact is that you need to decide when you design the
> language: are you going to use static typing or polymorphism to decide
> which method to call?
>
> If you use static typing, then the compiler gets to decide which method to
> call, and that has to be based on the type of the variable used. That
> means that in the first example I gave, "obj.ToString()" is going to call
> Object.ToString() even though the type of the instance is actually
> String. Whether you like it or not, that's completely contrary to the
> whole point of making ToString() virtual in the first place. Which means
> that the language might as well not have virtual members.

Rubbish.

> Now, one can certainly design a language without virtual members. But
> that's not C#, nor is it any other widely used OOP language. Virtual
> members are a major component of what makes OOP so powerful.

That is rubbish. I don't even know where you come up with this stuff. Adding
this feature would not require removing virtuals.

> So, maybe you decide you'd rather use polymorphism to decide which method
> to call. That means that you need to look at the actual instance to
> decide which method to call. But to do that, you need an instance and of
> course instances exist only at run-time so the compiler cannot be involved
> in making the decision at all.
>
> So which is it going to be? Cripple the OOP language? Or disallow
> calling of virtual methods with a null reference?

Rubbish.

> Alberto already posted it. Was there something about that you had trouble
> understanding?

I didn't think you would be able to answer than one.

Michael

"Peter Duniho" <NpOeStPeAdM@nnowslpianmk.com> wrote in message
newsp.ugk3macd8jd0ej@petes-computer.local...
> You should probably learn a little more about virtual methods (functions)
> (particularly as they are implemented in langauges like C++, C#, VB.NET
> and Java) before you make any more claims like that. Here's a decent
> place to start:
> http://en.wikipedia.org/wiki/Virtual_table

I know how virtual methods work.

> No, it's exactly right. By definition, a virtual method needs an
> instance. The run-time can't just go picking arbitrary methods to call
> when there's a null reference, and the compiler doesn't emit enough
> information for the run-time to know what the static typing of the
> variable was.

For a null value they can whatever they (MS) like. They could have made it
work like an extension method. The funny thing I find is that you bring up a
load of crap that makes no sense and ignore the one big arguement I was
expecting. Basically implementing this feature would require every
underlying method to check for null which would be a big overhead when this
feature wouldn't be used all that often.
>
>> [...]
>> Oh yes it can stoopid.
>
> Ah, right. I forgot that when you run out of words, you start calling
> people names. That really helps you look credible.

You really don't have a clue how you come across do you peter? From your
previous posts I have absolutely zero respect for you. Your rather subtle in
attempting to belittle those you speak to when it comes to the crunch you
can claim ignorance. Take your very first response to this post above
suggesting I read wiki. This is a subtle way of saying "you're stupid" but
something you fully intended and something you do in most of your posts.
Perhaps you should go learn some people skills.

Michael

Dang guys! Be nice! Christmas is right around the corner and we all want him
to bring us more RAM and a Service Pack, don't we?



"Michael C" wrote:

> "Peter Duniho" <NpOeStPeAdM@nnowslpianmk.com> wrote in message
> newsp.ugk3macd8jd0ej@petes-computer.local...
> > You should probably learn a little more about virtual methods (functions)
> > (particularly as they are implemented in langauges like C++, C#, VB.NET
> > and Java) before you make any more claims like that. Here's a decent
> > place to start:
> > http://en.wikipedia.org/wiki/Virtual_table
>
> I know how virtual methods work.
>
> > No, it's exactly right. By definition, a virtual method needs an
> > instance. The run-time can't just go picking arbitrary methods to call
> > when there's a null reference, and the compiler doesn't emit enough
> > information for the run-time to know what the static typing of the
> > variable was.
>
> For a null value they can whatever they (MS) like. They could have made it
> work like an extension method. The funny thing I find is that you bring up a
> load of crap that makes no sense and ignore the one big arguement I was
> expecting. Basically implementing this feature would require every
> underlying method to check for null which would be a big overhead when this
> feature wouldn't be used all that often.
> >
> >> [...]
> >> Oh yes it can stoopid.
> >
> > Ah, right. I forgot that when you run out of words, you start calling
> > people names. That really helps you look credible.
>
> You really don't have a clue how you come across do you peter? From your
> previous posts I have absolutely zero respect for you. Your rather subtle in
> attempting to belittle those you speak to when it comes to the crunch you
> can claim ignorance. Take your very first response to this post above
> suggesting I read wiki. This is a subtle way of saying "you're stupid" but
> something you fully intended and something you do in most of your posts.
> Perhaps you should go learn some people skills.
>
> Michael
>
>
>

On Thu, 28 Aug 2008 01:10:02 -0700, Michael C <mikec@nospam.com> wrote:

> [...]
>> Even more generally, you simply cannot call a virtual method without an
>> instance. You couldn't even do what you're talking about in plain,
>> unmanaged C++. If you still think you can call a virtual method without
>> an instance, I encourage you to post the C++ code that would do so.
>
> If MS wanted to do it they could. They could just use the VTable for the
> type.

And where would they get the v-table? If it's to work without an actual
instance, it would have to come from the static typing. And if the
compiler is using the static typing to obtain the v-table, what's the
point of having a v-table at all?

You can write the word "rubbish" as many times as you like. It doesn't
actually _demonstrate_ anything except your lack of understanding about
how virtual method calls work.

> [...]
>> Alberto already posted it. Was there something about that you had
>> trouble
>> understanding?
>
> I didn't think you would be able to answer than one.

Try me. If you didn't understand Alberto's post, I'm happy to try to
help. But you have to ask the question first. There's no point in me
just copying and pasting what he posted, given that you failed to
understand it the first time. You need to elaborate on what it was that
confused you.

All that said, the real issue here is that the .NET designers decided to
not allow null "this" references for _any_ instance member. You'd have to
ask them if you want their exact reasons, but the fact is that null "this"
references causes bugs in more situations than in which it's helpful.
It's extremely useful for an instance member to be able to assume that
"this" is non-null, and so that's the rule .NET imposes.

In your specific example, it wouldn't even be possible. It's unfortunate
that you don't understand why. But in the end, it's a moot point: even
for non-virtual members, there's a reason for why a null "this" reference
isn't allowed.

Pete

On Thu, 28 Aug 2008 01:17:30 -0700, Michael C <mikec@nospam.com> wrote:

> "Peter Duniho" <NpOeStPeAdM@nnowslpianmk.com> wrote in message
> newsp.ugk3macd8jd0ej@petes-computer.local...
>> You should probably learn a little more about virtual methods
>> (functions)
>> (particularly as they are implemented in langauges like C++, C#, VB.NET
>> and Java) before you make any more claims like that. Here's a decent
>> place to start:
>> http://en.wikipedia.org/wiki/Virtual_table
>
> I know how virtual methods work.

Be that as it may, you haven't been demonstrating that here.

> [...]
>>> [...]
>>> Oh yes it can stoopid.
>>
>> Ah, right. I forgot that when you run out of words, you start calling
>> people names. That really helps you look credible.
>
> You really don't have a clue how you come across do you peter?

This coming from the person who resorts to name-calling?

> From your
> previous posts I have absolutely zero respect for you.

Frankly, you seem to have zero respect for anyone. Why should I be
concerned about whether you have respect for me?

> Your rather subtle in
> attempting to belittle those you speak to when it comes to the crunch you
> can claim ignorance.

That's not even a grammatically valid sentence. But regardless, if I'm so
"subtle" in "attempting to belittle", what makes you think you can make
the claim that that's even what I'm doing?

If you feel belittled, it's simply because you wrote something wrong that
needed correcting, but can't deal with it. I certainly didn't set out
with the intention to make you feel belittled.

> Take your very first response to this post above
> suggesting I read wiki. This is a subtle way of saying "you're stupid"

It's a not-so-subtle way of saying "you should learn about this first".
That's hardly the same thing as calling you "stupid".

> but
> something you fully intended and something you do in most of your posts.
> Perhaps you should go learn some people skills.

I have people skills. They just don't involve candy-coating corrections
for people who are more interested in causing a ruckus and insulting
others than in learning something new. You need to get used to the idea
that it's possible for you to be wrong and for someone to point that out
without it reflecting poorly on you at all, never mind be a case of that
someone "belittling" you.

Everyone's wrong some times. It's how one deals with being wrong that
defines what kind of person they are. So far, you're not doing so well.

When you've figured all that out, you'll find yourself getting offended
much less often. In the meantime, I think about as much actual
information has been presented in this thread as could be. I've explained
the errors in your assertions and the design more generally. You can
continue the pissing match on your own if you like.

Pete

Michael C wrote:
> "jp2msft" <jp2msft@discussions.microsoft.com> wrote in message
> news:8D2A44C2-94FA-428F-A3A2-1F077B844B0D@microsoft.com...
>> Even if you declare an object, it doesn't really exist yet until you
>> have initialized it and the compiler has not set aside any space for
>> it.
>
> The bulk of the object does exist even before you declare the object.
> Generally the actual code will be greater than the object itself (in
> size) and all of the code exists and is ready to call before an
> instance is created.
>
>> To say, "Look at the space for this object that I have not created
>> yet and tell me what it says" would naturally throw an error.
>
> There is no reason calling a function on a null object *has* to raise
> an exception, the designers of C# just designed it that way. They
> actually needed to put an extra check in to stop it working.
> Basically when you call, say, object.ToString you end up calling a
> global function ToString where the pointer to the object is passed
> in, ie
> x.ToString();
>
> translates to (under the hood of course)
>
> public static string ToString(object* pObject)
> {
> //convert pObject to sring
> }
>
> I'm sure it's more complicated than that but that's the basic idea.

No, it's not really even all that close. And the devil is in the details.

The actual call x.ToString(), being virtual, ends up looking like it was
generated by something like this:

(*g_types[x->typetag].Methods['ToString'])(x);

unless the JIT hasn't compiled the MSIL into machine language yet, in which
case it does that before calling the function.

The actual function called depends on the actual run-time type of the
instance passed in. The run-time type is encoded in the first four bytes
(on x86) of each ref-typed object instance. The first four bytes of the
object instance referred to by null.... do you see the problem now? No
instance implies no type tag which implies no way to select the "right"
ToString implementation.

> The compiler does the null check before the static function is called
> but there is no reason that it needs to. It can easily call the
> static ToString function and let that function decide whether to
> allow nulls or not.
> Michael

Oh, and just for grins, I can provide example code where x == null but
x.ToString() succeeds. Hint: !object.ReferenceEquals(x, null)

"Peter Duniho" <NpOeStPeAdM@nnowslpianmk.com> wrote in message
newsp.uglrbbpc8jd0ej@petes-computer.local...

I was going to reply to your individual replies but I thought 1 single
response would be better. The idea that you could call functions on a null
object was a kind of tongue in cheek "what if" kind of post. It was not
something I took too seriously myself and I know full well it's not going to
become a reality. An appropriate adult response would have been along the
lines of "I think it has some use but the disadvantages outweigh the
advantages". Your response was somewhat different and *clearly* deliberately
negative. The simple fact is it would be possible for MS to implement this
and it would not require removing virtual methods from the languages. It
would really not be implemented because every function would need to check
if a null reference had been passed in (imagine having to do if this == null
everywhere) and this massive amount of extra work would outweigh the minor
gains.

With regards to your attempting to belittle me (don't confuse your attempts
with me actually feeling belittled). I said you attempt to do this in a
subtle way so you can deny it when called on and it this is exactly what
you've done. Sending people wiki links is a subtle way of telling them they
are stupid and you know full well this is true. The funny thing is nothing I
have said has been wrong yet plenty you've posted has been. Your claim that
we need to remove virtuals is incorrect and many of your other reasons this
couldn't be implemented are incorrect. If MS wanted to do this they could.
You claimed that the ToString function does not look like what I posted
(with a pointer to this being passed in) but when asked to provide the real
function you dodged.

Michael

On Aug 28, 6:58*am, "Peter Duniho" <NpOeStPe...@nnowslpianmk.com>
wrote:
> > the designers of C# just designed it that way.
>
> I believe that this is a run-time rule. *You can't call an instance method *
> on a null reference in C++/CLI either.

Not quite. The CLR allows one to call instance methods on null
receivers, so long as the call is not virtual (IL opcode "call" as
opposed to "callvirt"). The design decision for both C# and C++/CLI
was to use "callvirt" throughout, even for non-virtual methods,
precisely because it always does the null-check. But you can always
write your own IL which uses "call". Or you can use one of those
Delegate.CreateDelegate overloads which take an instance method and
expose its receiver as an explicit argument on the delegate, and then
pass null to that, in C# as well as any other .NET language

Of course, Object.ToString is virtual, so none of the above applies to
it.