|
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
|
|
|
|
|
Kevin McFarlane wrote:
I don't think that wanting clear and simple syntax makes one stupid.
I don't disagree at all. I would be disappointed, for example, if macros made it into C#. They are always a source of ugliness and illegibility. The point at hand is that I believe const is a very useful keyword and that C# seems to have dumbed it down, according to Eric from Microsoft because it was too much work to get it to work in the manner I would like and most C++ programmers would expect.
Kevin McFarlane wrote:
However, in the case of C# it appears to be due to complications in having .NET be multi-language.
The thing is, there are things that the compiler enforces rather than the CLR. For example, the difference between ref and out. That being the case, why can't the compiler enforce const ? It just needs to see if an attempt is made to change the value.....
Kevin McFarlane wrote:
However, if we take your argument seriously, one might as well ask why C# was not made identical to C++?
Not at all - it adds many cool things, and takes away some dumb ones ( such as macros ). I think it suffers from 'everything is an object' at times, but I can live with that. I think you have to cast too much, Eric tells me the C# team agrees. I do think that const is a serious oversight though.
Kevin McFarlane wrote:
Undoubtedly, they would have been less appealing if they'd used a new syntax.
I think it makes the initial learning curve less, but being more similar yet not the same is the source of a lot of frustration. However, there is no point in change for changes sake, I think that's just the learning curve I am on, having all too little time to spend on C# at the moment.
Christian
come on all you MS suckups, defend your sugar-daddy now. - Chris Losinger - 11/07/2002
|
|
|
|
|
Christian Graus wrote:
I don't disagree at all. I would be disappointed, for example, if macros made it into C#. They are always a source of ugliness and illegibility.
Yes. I try to avoid them, though they have their uses, especially for substituting for repetitive (but simple) code constructs - not for type substitutions. See, for example, ny "Design by Contract in C++" article on the site.
Christian Graus wrote:
The point at hand is that I believe const is a very useful keyword and that C# seems to have dumbed it down, according to Eric from Microsoft because it was too much work to get it to work in the manner I would like and most C++ programmers would expect.
I too think const is a very useful keyword. And, in fact, when maintaining C++ code I always look for the coder's use of const to assess whether they are reasonably competent or not. I also apply this test when inspecting my own code and I'm often surprised!
Christian Graus wrote:
The thing is, there are things that the compiler enforces rather than the CLR. For example, the difference between ref and out. That being the case, why can't the compiler enforce const ? It just needs to see if an attempt is made to change the value.....
Good point.
Christian Graus wrote:
I think you have to cast too much, Eric tells me the C# team agrees. I do think that const is a serious oversight though.
I think MS could have been a bit more imaginative in mapping wider features onto a narrower .NET definition. For example, C# has unsigned but that is not CLS-compliant. So why not const? However, I'm still puzzled as to why C++ seems to be about the only OO language that has const.
I don't know if you've read Bertrand Meyer's .NET articles at Software Development Magazine but Eiffel has more-or-less managed to get all its more advanced features mapped successfully to .NET, as it currently stands.
For example, unlike MC++, Eiffel .NET supports multiple inheritance. It also supports generics, the only .NET language to do so (though does MC++ support generics?). The way MI has been implemented in Eiffel .NET is quite ingenious. You can see his articles at http://www.sdmagazine.com but you now have to register to view them. If you're interested I still have them in my "sent items" folder so I could mail them to you privately.
Christian Graus wrote:
I think it makes the initial learning curve less, but being more similar yet not the same is the source of a lot of frustration. However, there is no point in change for changes sake, I think that's just the learning curve I am on, having all too little time to spend on C# at the moment.
C# improves on C++ re: readability but I think it could still have been more comprehensive. However, this is a minor quibble.
There's been much talk about how VB6 -> VB .NET is a difficult transition because of similar syntax but different behaviour, etc. However, in my (admittedly limited ) excursions into VB .NET I don't see what the fuss is about.
Whereas, I actually think that switching back and forh between C++, C# and Java - as some are likely to do - is far more confusing. If you add C it's even worse!
Kevin
|
|
|
|
|
Christian Graus wrote:
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* ???
That is true. In C# you have const locals (I was wrong in my earlier statement), and const statics, but that's all. We don't have const parameters or const methods. I'm not sure how we'd support them in a multi-language environment without requiring all languages to implement them.
That's assuming we thought the value was worth the complexity, and I think the jury is out on that one.
|
|
|
|
|
Here is a thread for view
Clickety
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
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
