|
Rama Krishna wrote:
I meant to say that I don't see any problems with compiler not accepting it.
I'm sorry to inform you that my compiler still does not accept the assignment of a variable to a new, const value.
Rama Krishna wrote:
You need to get over C+ mentality. there ain't no const variables only const constants.
I still have no idea what this means. Could you please help me out here ? Are you saying I am doing it wrong, or just being cute about my use of the term 'const variable' ?
Christian
come on all you MS suckups, defend your sugar-daddy now. - Chris Losinger - 11/07/2002
|
|
|
|
|
|
Nishant S wrote:
I thought you could in C#
Nope.
class Myclass
{
static public string Myfunction()
{
return "C# can be pretty dumb at times";
}
}
Myclass s;
System.MessageBox.Show(s.Myfunction()); // No way, no how.
This will NOT work. Nor can I do this:
class Myclass
{
static public string Myfunction()
{
return "C# can be pretty dumb at times";
}
public string Myfunction()
{
return "C# can be pretty dumb at times";
}
}
as it will (correctly IMO) not compile. So if I want to provide some methods as static because they do not need any internal state access, and could be more useful if they could be accessed that way, my users cannot access them from an instance of my class.
That SUCKS.
Christian
Christian
come on all you MS suckups, defend your sugar-daddy now. - Chris Losinger - 11/07/2002
|
|
|
|
|
statics belong to the Type, not the Instance.
therefore, static methods use the Type instead of the Instance for their context.
Why do you see this as a problem?
|
|
|
|
|
Because it's counter intuitive. I've given Nish a more detailed response, if you're interested.
Christian
come on all you MS suckups, defend your sugar-daddy now. - Chris Losinger - 11/07/2002
|
|
|
|
|
Christian Graus wrote:
System.MessageBox.Show(s.Myfunction()); // No way, no how.
That's wrong usage anyway. The static method is a class method and not an instance method
Instead of s.MyFunction you *must* use MyClass.Myfunction and I think that is the right way of doing it
Nish
Author of the romantic comedy
Summer Love and Some more Cricket [New Win]
Review by Shog9
Click here for review[NW]
|
|
|
|
|
Nishant S wrote:
That's wrong usage anyway. The static method is a class method and not an instance method
DAmmit Nish, that is my whole POINT !!!!
Nishant S wrote:
Instead of s.MyFunction you *must* use MyClass.Myfunction and I think that is the right way of doing it
Why ? I'll settle for one good reason that an instance of a class cannot know about methods that exist once and once only for all instances of that class.
In C++, I can do exactly what I just said, and it makes sense. A class can have a private static member, for example. I answered a question on comp.lang.c++ this morning where someone had a class called Actor and wanted to keep a list of actors visible to instances of Actor internally. A private static list is the way to go. In C#, a static that is also private is invisible to EVERYONE. It is simply counterintuitive, if a method I am writing can be written as static, for my users to have to type in the name of the class instead of the name of a class instance. They should be able to do both, that is the point of the thing. How is a class instance unable to see methods in the class because they are common to all instances of it ? Dumb, dumb, dumb.
Have you not used static in C++ ? Have you used it particularly in C# ?
Christian
come on all you MS suckups, defend your sugar-daddy now. - Chris Losinger - 11/07/2002
|
|
|
|
|
Christian Graus wrote:
I'll settle for one good reason that an instance of a class cannot know about methods that exist once and once only for all instances of that class.
Its not that they don't know about them; but why make it look like you are making an instance method call when it is a static method call?
Christian Graus wrote:
In C#, a static that is also private is invisible to EVERYONE.
No it isn't, it is visible to that class
class Foo {
private static int bar = 0;
private static void IncBar()
{
bar++;
}
public void DoSomething()
{
Foo.IncBar();
Foo.bar++;
}
}Compiles just fine.
Now I'm going to throw something out which I've told many people before. No matter the language I've always heard complaints about it not having feature x from language y. This isn't language y, if you keep going back to wanting it to be language y you are are just going to infuriate yourself because it isn't. I've now said it for 3 languages (FORTRAN, Java, and C#) and its been true in every one of those cases.
Christian Graus wrote:
It is simply counterintuitive, if a method I am writing can be written as static, for my users to have to type in the name of the class instead of the name of a class instance.
How is it counterintuitive? The method doesn't belong to an instance of the class, I think it is counterintuitive to code a static method call like it was an instance method.
All of the critics have lambasted VB for doing too many things for the developer on the language level, making them lazy. Oddly enough C++ does the same things but no one says a thing! While we were working on the screensaver I think it is safe to say your biggest complaint was that you had to cast everything. Now we have a framework where a bad cast isn't going to ruin anything because the cast will throw an exception if it can't be made. I see that as a good thing. In fact it is close to the dynamic_cast of C++, a better match would be the as statement
IMO it is BAD to not be explicit about what you are doing. Anyone with experience coming from VB will know the problems caused by not being explicit. Maybe its time the VB people teach the C++ people a thing or two  .
BTW, if I sound mad its not because of you nor anyone else from CP. My dad is insisting on opening up some security problems on our webserver, but since he pays the bill for it I have no say in the matter. That and he is completely unorganized so the root directory looks like crap 
James
"Java is free - and worth every penny." - Christian Graus
|
|
|
|
|
James T. Johnson wrote:
Its not that they don't know about them; but why make it look like you are making an instance method call when it is a static method call?
Because it's more intuitive to the user of the class ?
James T. Johnson wrote:
Compiles just fine.
Apparently. 
James T. Johnson wrote:
This isn't language y, if you keep going back to wanting it to be language y you are are just going to infuriate yourself because it isn't.
That's fair, and more to the point, if I try to make C# behave like C++, I will miss out on cool stuff in C#. For example, I am getting into reflection and finding it very cool. But given that C# is clearly modelled at least in part on C++, it's reasonable to ask why this change was made, the syntax looks like C++ but behaves differently, so I assume they thought they had a good reason. I'm still waiting to hear it.
James T. Johnson wrote:
How is it counterintuitive? The method doesn't belong to an instance of the class, I think it is counterintuitive to code a static method call like it was an instance method.
I have a method I want to add to an XML wrapper class I am writing. It takes an XML node and goes through it's children looking for a text node. If it finds one, it returns the value. It's called GetText. I decided to make it static because it does not rely on the internal state of the class, but I imagine someone using an instance of the class to do other things would like to be able to type
myinstance.GetText(myinstance.FindNode("/XML/node/mynode"));
Being forced to remember what is a static method and what is not when all the methods are being used together to manipulate XML does not seem to me like a highly evolved thing to do. It's simply an annoyance.
James T. Johnson wrote:
All of the critics have lambasted VB for doing too many things for the developer on the language level, making them lazy. Oddly enough C++ does the same things but no one says a thing!
Like what ?
James T. Johnson wrote:
While we were working on the screensaver I think it is safe to say your biggest complaint was that you had to cast everything. Now we have a framework where a bad cast isn't going to ruin anything because the cast will throw an exception if it can't be made. I see that as a good thing. In fact it is close to the dynamic_cast of C++, a better match would be the as statement
I am reading the Richter book and now that I understand the as and is keywords, I think I like the C# model better than I did, but I still hate the fact that C# forces me to cast so much, especially in the case of the Clone method, containers, and using values supported in C# but not the CLR, like ( from memory ) short.
Christian
come on all you MS suckups, defend your sugar-daddy now. - Chris Losinger - 11/07/2002
|
|
|
|
|
Christian Graus wrote:
Like what ?
For one all the implicit casting, or at least judging by your comments about C# requiring so much casting I'm getting the impression that you rarely have to cast in C++.
But with having a strongly typed system, casting isn't the great evil it once was. You can't cast between types willy-nilly like you could with C so it isn't a bad thing to cast.
Implicit casting was the big language feature that everyone hated; I can't think of what my other issue was now. It probably had to do with static methods but that doesn't make much sense now. A lot of your casting issues could probably be done away with once generics are implemented [which reminds me I need to redownload CollectionGen  ], or if you used MC++.
James
"Java is free - and worth every penny." - Christian Graus
|
|
|
|
|
James T. Johnson wrote:
I'm getting the impression that you rarely have to cast in C++.
Not so, but if I put a structure into a C++ container, I don't have to cast to pull it out. If I try to put an int into an unsigned char, I will get a warning rather than an error, if I have an object which has a clone method, it will return an instance of that object. Casting can happen in C++, but in C# it quickly becomes tiresome that it is ALWAYS assumed I am an idiot, or the language itself is too dumb to know what an object is when it should.
James T. Johnson wrote:
But with having a strongly typed system, casting isn't the great evil it once was. You can't cast between types willy-nilly like you could with C so it isn't a bad thing to cast.
That much may be true, my complaint is that it is tiresome and ugly.
James T. Johnson wrote:
A lot of your casting issues could probably be done away with once generics are implemented
Yes, I have high hopes for C# once it impliments generics, which are vital IMO to any modern language.
James T. Johnson wrote:
which reminds me I need to redownload CollectionGen
I could never make that work.
James T. Johnson wrote:
or if you used MC++.
Now you're REALLY swearing at me !!! :P
Christian
come on all you MS suckups, defend your sugar-daddy now. - Chris Losinger - 11/07/2002
|
|
|
|
|
Christian Graus wrote:
if I put a structure into a C++ container, I don't have to cast to pull it out.
This is more from having generics; not a language feature (I guess it is now but when the books I learned from were made they suggested staying away from STL  ). If you made the equivalent C# collections in C++ you would be casting to go from void* to whatever type.
Christian Graus wrote:
if I have an object which has a clone method, it will return an instance of that object.
This is the framework imposing its contract again. Depending on who designed the class that implements IClone(able?) you could have a strongly-typed version available. This is the same principle that ICollection works on (or is it IList?), the contract says there is an indexer that returns an object; but the class can also expose a strongly-typed version.
public class Foo : ICloneable
{
object ICloneable.Clone()
{
return Clone();
}
public Foo Clone()
{
Foo newFoo = new Foo();
return newFoo;
}
}Here you get the generic Clone() method if you specifically ask for the ICloneable interface; if you call the class' public Clone() method you get one that is strongly-typed. Strongly-typed collection classes should use the same technique so that they can correctly implement ICollection, IList, etc... I think this is my favor C# specific feature
Christian Graus wrote:
in C# it quickly becomes tiresome that it is ALWAYS assumed I am an idiot, or the language itself is too dumb to know what an object is when it should.
It just stops you from being lazy  Casting should only be required when it is unknown at compile time what type is returned (usually when you are dealing with methods that return object). In some cases generics could help that; but in others returning an object really is the only usage because it could be of any type *cough* void* *cough*.
Christian Graus wrote:
I could never make that work.
The first time I tried to use it I couldn't either; I haven't had problems since then. Maybe you should give it another shot? 
Christian Graus wrote:
Now you're REALLY swearing at me !!!
At least you could use some template classes to get away from casting so much Somewhere on my hard drive I have a prototype for a template class to wrap ArrayList Unfortunately it doesn't help you in C# 
James
"Java is free - and worth every penny." - Christian Graus
|
|
|
|
|
James T. Johnson wrote:
when the books I learned from were made they suggested staying away from STL
Really ? How long ago ? That just seems like idiocy to me.
James T. Johnson wrote:
If you made the equivalent C# collections in C++ you would be casting to go from void* to whatever type.
Actually they used macros to create class factories. There was always a facility to create containers. But you're right, it's C$ woeful lack of generics that is the problem here.
James T. Johnson wrote:
I think this is my favor C# specific feature
Why does the GDI+ Bitmap not use it, I wonder ?
James T. Johnson wrote:
It just stops you from being lazy
And I'm supposed to be happy about this ? :P
James T. Johnson wrote:
Casting should only be required when it is unknown at compile time what type is returned
It is often needed because of numeric types of differing size as well.
James T. Johnson wrote:
Maybe you should give it another shot?
Perhaps. Partial template specialisation in C++ is still not here, so who knows how long C# generics will be ?
Thanks for taking the time to explain all of this to an old C++ hack. I still don't agree totally, but you certainly have once again helped just by letting me vent at you ( as you also did in the screensaver days ).
BTW how are you finding the memory leak detector ?
Christian
come on all you MS suckups, defend your sugar-daddy now. - Chris Losinger - 11/07/2002
|
|
|
|
|
Christian Graus wrote:
Why does the GDI+ Bitmap not use it, I wonder ?
The 0-parameter version is inherited by the Image class which gives a return of object; but the GDI+ version of Image returns Image*. Perhaps the System.Drawing namespace was completed before the C# designers had thought to allow interface implementation to be done specifically?
There are two overloads to the Clone method which both return Bitmaps so those could be possible uses there.
Christian Graus wrote:
It is often needed because of numeric types of differing size as well.
True; I think this should be a warning instead of an error as well. But at least it doesn't do the conversion silently
Christian Graus wrote:
Partial template specialisation in C++
Can you explain what that is? I've seen it mentioned so many times but no explaination has ever been given
Christian Graus wrote:
who knows how long C# generics will be ?
From what was said before on the DOTNET lists there is supposed to be an interim release which adds this and CodeDOM support for MC++; but who knows if it'll get done in time.
Christian Graus wrote:
BTW how are you finding the memory leak detector ?
I haven't had a chance to use it yet; I've been in-between projects and working with Tom and Nish to get ready for writing our book. I have tried to keep up to date with the new releases as they come out.
I may get around to using it when I start my next project
James
"Java is free - and worth every penny." - Christian Graus
|
|
|
|
|
James T. Johnson wrote:
True; I think this should be a warning instead of an error as well. But at least it doesn't do the conversion silently
So we agree - the C++ way is better ( a warning, depending on the warning level set in the compiler )
James T. Johnson wrote:
Can you explain what that is? I've seen it mentioned so many times but no explaination has ever been given
A template allows you to specify a type, and essentially becomes a class factory. If I have a class that has two templated parameters, I could specialise that class by writing a version where both are int, so that this version is used if int is passed in. Partial template specialisation means I have more than one templated parameter and I specify what I want to happen if only ONE of them is a particular value, regardless of what the other value is.
James T. Johnson wrote:
I haven't had a chance to use it yet;
Me either, I've fired it up, but not found the time to really play with it. I'm writing a magazine article on C#/XML, and it's slow going.
Christian
come on all you MS suckups, defend your sugar-daddy now. - Chris Losinger - 11/07/2002
|
|
|
|
|
Intel's compiler supports partial specialization.
|
|
|
|
|
Christian Graus wrote:
Perhaps. Partial template specialisation in C++ is still not here, so who knows how long C# generics will be ?
If you're really desperate try Eiffel .NET, which supports templates right now. Pretty expensive though.
Kevin
|
|
|
|
|
Christian Graus wrote:
I am reading the Richter book and now that I understand the as and is keywords, I think I like the C# model better than I did, but I still hate the fact that C# forces me to cast so much, especially in the case of the Clone method, containers, and using values supported in C# but not the CLR, like ( from memory ) short.
The C# design team also thinks it forces you to cast too much.
|
|
|
|
|
Cool - hopfully that means it will change in the future, I'm guessing when generics arrive ?
Christian
come on all you MS suckups, defend your sugar-daddy now. - Chris Losinger - 11/07/2002
|
|
|
|
|
Christian Graus wrote:
Why ? I'll settle for one good reason
I doubt you will ever find a reason that you agree is sufficiently "good".
many people, myself and the designers of the c# language included, find it more correct and intuitive that a static belongs to the Type and not the Instance.
Apparently you will not accept that.
There is no other reason than thinking that that is the correct way to make consumers of the class member explicitly know the context and reprocussions of their using that member.
as for private statics being invisible in c#, that is simply untrue. I've use private static variables myself.
|
|
|
|
|
Andy Smith wrote:
many people, myself and the designers of the c# language included, find it more correct and intuitive that a static belongs to the Type and not the Instance.
Apparently you will not accept that.
No, because it benefits no-one but language lawyers, and makes using a class with static members less intuitive than in C++.
Andy Smith wrote:
There is no other reason than thinking that that is the correct way to make consumers of the class member explicitly know the context and reprocussions of their using that member.
So you're saying I'm not allowed to define a member function unless it alters the state of the underlying instance ?
Andy Smith wrote:
as for private statics being invisible in c#, that is simply untrue. I've use private static variables myself.
Well, given other design issues in C#, it was not an unreasonable guess.
Christian
come on all you MS suckups, defend your sugar-daddy now. - Chris Losinger - 11/07/2002
|
|
|
|
|
Christian Graus wrote:
Myclass s;
System.MessageBox.Show(s.Myfunction()); // No way, no how.
This I find odd. This type of code would work correctly in Java. I'm surprised that it doesn't work that way in C#
Christian Graus wrote:
class Myclass
{
static public string Myfunction()
{
return "C# can be pretty dumb at times";
}
public string Myfunction()
{
return "C# can be pretty dumb at times";
}
}
Why do you see this as a problem. The compiler must be able to differentiate between a method at runtime and making this legal would add some abiguity to it. For instance.
<br />
MyClass s = new MyClass();<br />
s.MyFunction();<br />
In this case, which would be called? The static or the instance method?
Jared
jparsons@jparsons.org
www.prism.gatech.edu/~gte477n
|
|
|
|
|
jparsons wrote:
I'm surprised that it doesn't work that way in C#
Me too !!!
jparsons wrote:
Why do you see this as a problem.
The compiler will not accept it. I don't see the problem, the compiler does.
jparsons wrote:
In this case, which would be called? The static or the instance method?
The compiler won't allow both to exist.
Christian
come on all you MS suckups, defend your sugar-daddy now. - Chris Losinger - 11/07/2002
|
|
|
|
|
Christian Graus wrote:
That SUCKS.
Even Stourstrup recommends you not to use static members thru' instance of a class. So I think it is perfectly ok that the language doesnot allow you to do that.
In fact I don't remember accessing static members through instances in the class ever. Though it is allowed I never do that.
Step back, rub your eyes, take a deep breath, stretch a bit, and reflect on the relative importance of CP, CG, the age / travel time sustained by supposedly 'fresh' cheese curds, and Life in General. - Shog9
|
|
|
|
|
Rama Krishna wrote:
In fact I don't remember accessing static members through instances in the class ever. Though it is allowed I never do that.
I did this a lot until a student of mine submitted the following code to me in Java.
<br />
SomeClass s = null;<br />
s.SomeStaticMethod()<br />
This code will work fine under Java. it doesn't throw any exceptions. After seeing this I stopped using static members through instnaces. Too nasty.
Jared
jparsons@jparsons.org
www.prism.gatech.edu/~gte477n
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
