Is there some way to adjust the warning level and other compiler flags so that the c# compiler is 1) not so darned finnicky about expressions using mixed floating point and integer types and 2) actually performs automatic conversions more correctly than it does, like a 'C++' compiler
some feedback on this also --
requiring explicit casts in so many situations is all downside, as far as I am concerned:
Its very time consuming having to add all the (float) casts required now, and the casts make the code much harder to read. I find I code far more errors than I would otherwise because of the visual distractions added by all the parens and code bloat. The necessary study to get the parenthesis balanced correctly also gives me headaches. Please change this ASAP, by the way, to a more traditional style of automatically doing these simple convernsions -- i've never seen a compiler require so much explicit specification before -- i used to have a co-worker who liked to use the epression "that's what computers are for" whenever he'd notice me doing things at too low a level, and I think his point applies here...
MS, MVP feedback, question: casts / conversions -- some way to automate?
Rob Claisse
oh, sorry, that should be
int n = 6;
float fpt = 2.5F;
int result = (int)(n.f() * fpt);
a bit like .ToString(). This, I think, might be cleaner and easier.
Also, just to avoid misunderstanding, i do like c# very much. For some reason, when programming with it, my projects seem to go much more smoothly, with many fewer problems....I only learned recently that the 'genius' behind its creation is the same guy who used to work at Borland on Delphi and Turbo Pascal. When I heard that i thought to myself, hmm, no wonder I like c# -- i programmed in the aforementioned borland languages for many years...I am however greatfull that c# programs do not have to be written upside down :->
RC
Ujoshi
Thanks Christian, i appreciate your support on this one. By the way, are you the person who wrote several articles for Code project on Image Processing If so, thanks for those also, which have been helpful to me on a project i am doing now...
RC
Stephany Young
*blush* yep - those articles are mine. I'm glad you've found them helpful.
subink
Dear Mads,
thanks for the reply -- i appreciate your points about safeguarding the style of the language and encourage you in that. But I still disagree about all the casting required to do these conversions. One thing that occurred to me (and this is a rather half-baked thought) is that it might be better, if you insist on a very explicit approach, to have the System.IntXX data types have a method that returns a floating point equivelent of themselves, something like
int n = 6;
float fpt = 2.5;
int result = n.f() * fpt;
a bit like .ToString(). This, I think, might be cleaner and easier.
ChrisBuhi
No, I don't believe so. C# is definately too 'picky' in what it casts, but this is by design. I agree with your comments.
Mark Edgerton
Hey RC,
In fact you might even argue that one should write:
int n = 6;
float fpt = 2.5F;
int result = (n.f() * fpt).i();
At the heart of the problem may be the fact that explicit conversions and type casts share the same syntax in C# - and the C-based languages we build on. Whereas type casts are truly a language feature that deserves its own syntax, one could easily argue that conversions are more a kind of method calls and should have according syntax.
Given that we followed our predecessors down the road of a "cast" syntax for conversions, and even allow user-defined conversions using the same syntax, I think it is probably cleaner that we stick to that approach consistently. If we were redesigning a language from scratch I would agree with you that one should seriously consider separating type casts and conversions, and maybe not have specific conversion syntax at all.
Let's return to this point when we do the next language! :-)
Cheers,
Mads
JamiePe
Hey "Man" - thanks for your comments!
I am sorry that you find our conversion rules too pedantic. Actually, we do not get a lot of feedback agreeing with you, on the contrary a lot of people are generally happy that we help them catch more subtle errors than many other languages.
In the end, though, it comes down to a matter of style. If you know what you are doing, some of it is bound to get in your way. But for the majority of cases more explicit code is better, making it easier to read and maintain the code. The initial amount of typing is rarely the decisive factor in the overall "usability" of a piece of code.
Adding a switch to make the compiler less pedantic would essentially create a new "dialect" of C#, which is a slippery slope. We already took one step down it with the unsafe mode, but that has a clear use case. Adding more dimensions of optional language features would be highly confusing.
So I am afraid I have to disappoint you a little here - the "finnickiness" dial of C# is one we are very conscious about, and we are confident that it is currently set at the best level - for this language.
Hope you still enjoy the rest of your C# experience - hurry up and get that arithmetic shoved away in helper methods!
Thanks again,
Mads