|
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 Bitmap s 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
|
|
|
|
|
I don't remember exactly why we decided not to have const locals. It might have been that the CLR didn't want the complexity, or that we didn't want the language complexity.
On the static method issue, we found it weird that in C++ you could write something that *looked like* a method invocation but was really a static function call, or you could write it the other way. We also don't like having two ways of doing things.
|
|
|
|
|
Yes, I agree. I remember seeing an example in Java illustrating why it was good practice to use the static method format rather than the instance method (which, as in C++, is allowable in Java). Using the instance method format made the code very confusing. I'm pretty sure if the Java guys were designing Java again they would go for the C# approach.
Kevin
|
|
|
|
|
Kevin McFarlane wrote:
I'm pretty sure if the Java guys were designing Java again they would go for the C# approach.
Isn't it funny - Java is old enough now that it's designers must endure what Stroustrup has had since Java came out. I dunno how many interviews I have read where they ask him if he wishes he'd written C++ more like Java. I take my hat off to him for his measured and mature responses to this question. I hope the Java developers take a leaf out of his book.
Christian
come on all you MS suckups, defend your sugar-daddy now. - Chris Losinger - 11/07/2002
|
|
|
|
|
Christian,
I've seen one or two of these interviews too and he makes some good points. (Java enthusiasts can be fanatics. I hope that doesn't happen to C#ers!) You have to look at where languages are coming from, their design criteria, problem situations, etc., before you can properly assess them. Though, we all tend to have favourable or unfavourable first impressions. Having said that it seems that all language designers are especially biased towards their own languages and can be over the top on occasion.
In my case, although I have likes and dislikes, I've found that most mainstream languages have been palatable. For example, out of this list there's only one that I truly detest:
C, C++, Java, C#, Delphi, Pascal, Eiffel, Perl, Python, JavaScript, VB.
And that's Perl.
Kevin
|
|
|
|
|
Eric Gunnerson (msft) wrote:
I don't remember exactly why we decided not to have const locals. It might have been that the CLR didn't want the complexity, or that we didn't want the language complexity.
With all due respect, I don't see either of those as valid reasons to disallow me from creating constants as an aid to clarity and bulletproofing my code. Am I right in also thinking I cannot pass paramters into functions as const ? I was reading the Richter book on the bus and I was left with the impression that I cannot const reference types or my own value types at *all* ???
Eric Gunnerson (msft) wrote:
On the static method issue,
I guess it depends on how you look at it. I find it wierd to be using an instance of an object and have to chop and change between the object name and the instance name to use different methods.
Christian
come on all you MS suckups, defend your sugar-daddy now. - Chris Losinger - 11/07/2002
|
|
|
|
|
it's a "valid reason" because language simplicity is a highly desirable feature in itself.
many c++ people are just not willing to give up feature x or y for the sake of simplicity. some see simplicity as marketing spin for not including their favorite feature.
however, many of us are glad that all this extra syntax and rules have been discarded.
|
|
|
|
|
Andy Smith wrote:
however, many of us are glad that all this extra syntax and rules have been discarded
I guess there is a place for programmers too stupid to learn a lot of syntax. If you can't appreciate the usefulness of const in C++, you're free not to use it, but my problem is that many of those dumbed down programmers may well work on my C# code, and I have one less way of protecting it from them.
If Microsoft wanted to move away from a lot of the useful stuff in C++ for some reason, they did themselves a disservice by making C# look so much like C++ that the missing features are blatantly obvious. I don't bag out Python for not having features in C++, but C# is MODELED on C++, so why get rid of so much good stuff ?
Christian
come on all you MS suckups, defend your sugar-daddy now. - Chris Losinger - 11/07/2002
|
|
|
|
|
you didn't need to resort to insults. My appreciation for simplicity and elegance does not indicate that I am stupid nor a danger to your code.
now that I have seen how you react to those who dare have a differing opinion, I don't think i'm going to waste my time on you anymore.
|
|
|
|
|
Andy Smith wrote:
you didn't need to resort to insults.
I didn't. I was very careful to word what I said in the third person.
Andy Smith wrote:
My appreciation for simplicity and elegance does not indicate that I am stupid nor a danger to your code.
I didn't say either of those things, I was talking in general. By the way, Eric from Microsoft responded on this thread and said that the C# design team agrees with my original comment, that you need to cast too much in C#, and that the reason const is not supported in the manner I describe is because it was too much work to support it in the CLR. I find it hilarious that Microsoft could not be bothered, and people come along and congratulate them on the elegance of their design.
Andy Smith wrote:
now that I have seen how you react to those who dare have a differing opinion, I don't think i'm going to waste my time on you anymore.
Well, if you want to be grumpy, that is up to you. I was having a hell of a day when we spoke, so it's possible I was more brusque than I would have liked, but I remember being careful to word my opinion in general so that it was not a personal attack, and I'm sorry if I failed in that regard. My opinion is unchanged, but it is not meant to be taken as my opinion of you, rather my opinion of the design of C# in regard to constant values.
Christian
come on all you MS suckups, defend your sugar-daddy now. - Chris Losinger - 11/07/2002
|
|
|
|
|
Christian Graus wrote:
I guess there is a place for programmers too stupid to learn a lot of syntax.
It's not so much having a lot of syntax but having syntax of poor readability. I'm primarily a C/C++ developer but when I go back from C# or Java to reading C++ code it looks very painful. Complicated syntax tends to obscure important concepts and certainly makes it more difficult than should be the case for newcomers to OO. (Look up The C++ Critique and the book, Objects Unencapsulated both by Ian Joyner.)
I don't think that wanting clear and simple syntax makes one stupid. Some of the brightest guys in the industry, Bertrand Meyer and Guido van Rossum, agree on the desirability of this. Programmers should be free to focus on concepts and problem-solving, rather than being bamboozled by syntax. Having said that, C/C++ is still a model of clarity compared to the appalling Perl.
Christian Graus wrote:
If you can't appreciate the usefulness of const in C++, you're free not to use it
I agree with you on the usefulness of const and I'm not sure why C++ seems to be alone here. However, in the case of C# it appears to be due to complications in having .NET be multi-language.
Christian Graus wrote:
If Microsoft wanted to move away from a lot of the useful stuff in C++ for some reason, they did themselves a disservice by making C# look so much like C++ that the missing features are blatantly obvious. I don't bag out Python for not having features in C++, but C# is MODELED on C++, so why get rid of so much good stuff ?
I think that Java went overboard in discarding useful features from C++. C# has done a better job in this regard. However, if we take your argument seriously, one might as well ask why C# was not made identical to C++?
OTOH, it's good to raise the question of why C# and Java use C-style syntax when they are substantially different languages? Technically, they ought to have adopted new syntaxes. But, economically, given that both languages wanted to attract C/C++ developers, it made sense to use a syntax that is familiar to them. Undoubtedly, they would have been less appealing if they'd used a new syntax. (Though, I think professional programmers should be more mature about these things, especially if a new syntax is clearer.)
However, I am in sympathy with you in the following respect:
1. C++ is a complex language with often complex, or at least unclear, syntax.
2. Prospective competitor languages to C++, such as Java and C#, react against the complexity of C++ by focusing on removing the complexity.
3. Because the complexity of C++ often obscures important concepts the focus on reducing complexity occasionally ends up removing some of those important concepts.
Now, I think that C# has been much more careful in this respect than Java. Apart from the lack of generics I don't miss much from C++. And it seems as though .Net has been designed with generics in mind. I can see that it would have been quite tough to get it there in the first release, especially given the multi-language paradigm of .Net. However, generics is clearly a very important concept and it is not a good reason for not including it that it's implemented in a complex manner in C++.
Kevin
|
|
|
|
|