Re: Understanding different messages

Hi Ian,

Thank you for the info, I'm still a little confused.

In the first case I get an error when I want to override from one class
to the other

Warning 1       'Pipercove.Lcce.Projects.Resources.CPart.IgnoreCost'
hides inherited member 'Pipercove.Lcce.Projects.CResource.IgnoreCost'.
Use the new keyword if hiding was intended.
C:\share\Pipercove\PSA2\Pipercove.Lcce.Projects\Resources\CPart.cs
675     15      Pipercove.Lcce.Projects

And the other is similar yet different. I think the difference is that
the second case overrides a Microsoft class member.

Warning 2
'Pipercove.Lcce.Forms.TreeForms.SettingsUI.UCSystemDeploymentContent.Min
imumSize' hides inherited member
'System.Windows.Forms.Control.MinimumSize'. To make the current member
override that implementation, add the override keyword. Otherwise add
the new keyword.
C:\share\Pipercove\PSA2\Pipercove.Lcce.Forms\TreeForms\SettingsUI\UCSyst
emDeploymentContent.cs  144     15      Pipercove.Lcce.Forms

I'm surprised that I would need to put the override keyword everywhere
now.

I would appreciate your thoughts.
Regards
Mark
 

-----Original Message-----
From: Discussion relating to the specifics of the C# and Managed C++
languages [mailto:[email protected]] On Behalf Of Ian
Griffiths
Sent: Monday, 31 July 2006 1:47 AM
To: [email protected]
Subject: Re: [DOTNET-CX] Understanding different messages

The difference is that with CS0108 there is just one possible root
cause, whereas CS0114 is caused by either of two different problems, and
the compiler has no way of knowing which of the two it is. There's some
overlap because one of the two problems that can cause CS0114 happens to
be the same as the one problem that can cause CS0108.

The first possible problem is that you might have intended to override
an abstract or virtual function in the base class but accidentally left
off the 'override' keyword.

The second possible problem is that you didn't intend the function in
the derived class to be in any way related to the function of the same
name in the base class - you just have a naming collision between two
unrelated members.

CS0108 occurs when the problem is unambiguously the second one. If the
base member cannot be overridden (i.e., either it's not a function, or
it's a non-virtual function) then the compiler can know that the first
problem cannot apply - it has to be the second problem. Since the
compiler is able to give you a more precise explanation of the problem
in this situation you get this unambiguous warning. But if the member in
question is a virtual function, the compiler can't tell which of the two
problems is the root cause as both produce the same symptoms - it has to
give you the slightly more ambivalent message, CS0114.


If you're getting these in .NET 2.0 where you weren't previously getting
them in 1.1, that suggests that the problem is the second one - name
collisions with unrelated functions. (The compiler can't work this out
for itself because it has no knowledge of what changed between v1.1 and
v2.0 of the framework.)

This means that YOU SHOULD NOT OVERRIDE. If you wrote a function that
was not intended to override an existing function in the base class, and
you then go ahead and make that function override some new function
added in .NET 2.0 in the base class, you'll essentially be
brain-damaging that class - you'll be replacing part of its
functionality with some piece of logic that was never written with the
intention of being a replacement for whatever function it is now
overriding.


It's rather surprising that you're getting "a lot of messages of this
kind." For that to happen you would need to be doing two things:

 1) You'd need to derives lots of your own classes from classes defined
in the .NET Framework Class Libraries and
 2) You'd need to have an uncanny knack for picking function names in
your derived classes that match names Microsoft have added in V2.0 as
new members of existing classes.

Even if you think that (1) is a good idea (I don't but I'm aware some
people believe it to be a fine idea), you wouldn't expect to hit (2) all
that often. If you see one or two, that'd be not too big a deal. But to
see a lot suggests something fishy is going on. I'd want to look into
why you're seeing so many before working out how you're going to resolve
it.


The correct way to resolve this is to rename the relevant members so
that you no longer have naming collisions. You really don't want to be
in a situation where you have what looks like the same name for two
different things. (Technically they are two different names -
Base.method and Class.method as you point out. But in C# we don't
explicitly qualify method names except for static methods, so it's very
easy to end up calling the wrong one by accident.)

The ability to mark a method with 'new' lets you get rid of the warning,
but should be regarded as a stopgap. It's a bit like one of those cans
of 'get you home' filler gunk they give you in cars without spare tires
that let you patch up a tire in the event of a puncture: they offer a
messy but workable temporary solution, but you need to fix the problem
properly at the earliest possible opportunity.


--
Ian Griffiths



-----Original Message-----
From: Mark Gregory

I would like to know what is the difference between

CS0108 and CS0114

In my program upgrade to .Net 2.0 I get a lot of messages of this kind.

What happens if I choose to add new rather than override? Does this mean
that both the base method and the class method are active? I thought
this would be resolved by how the method is called?

Base.method
Class.method

Or if I choose override does this preclude any use of Base.method?

I'm a little confused by what is happening here.

===================================
This list is hosted by DevelopMentor(r)  http://www.develop.com

View archives and manage your subscription(s) at
http://discuss.develop.com

===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com