|
|
C# from 0, when you know C++?
You really know more than you need to know in one sense.
Think of C++, but a lot of the differentiation is removed. C++ made simple.
For example, you don't separate namespaces by '::', but simply with a '.'
No difference between ref for value and pointer ('.' vs. '->') as everything is an object and it's always a pointer so, as a short-cut, it's always '.'.
The IJW nearly seamless slipping between managed and unmanaged is not so seamless (should you ever need to do it).
If you use C++.NET, then your most of the way there. Really, nearly everything's the same.
Now there's more to it than that, but MS was targeting the VB.NET users when the built this so they dumbed it down simplified it. VB.NET lived on, anyway.
Others might, or rather, are likely to disagree with the above.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
I'd disagree to an extent: they ripped C++ to bits when they first created C# and got rid of a lot of the "dangerous" stuff - memory leak causes and so on - to create a simpler language that was faster to develop with than native C++ as a result.
Since then, they have been layering on more complexity - some of it useful and justified, some of it badly abused. It's perhaps getting to the point where C# needs to be ripped apart and the same exercise done again (.NET Core would have been a good opportunity to do this)
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I was just drawing gross picture => JM said she was starting from '0'; with a C++ background that's really not the case. And if she uses C++.NET, even less so the case.
My real complaints about C# were twofold:
1) MS help seemed to emphasize C# at the expense of C++. Perhaps this has changed?
2) It hides from the user the subtle differences, such as between a namespace vs. class hierarchy. One could argue - so what? As as minimalist, however, I like to know what's what.
Fortunately, I've not had a project where any performance difference was a concern.
Would you, in your partial disagreement, agree that the syntax, at the basic level, is such that it's almost automatic that one knows C# if one know C++ (new layers of convolution notwithstanding)?
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
W∴ Balboos wrote: Would you, in your partial disagreement, agree that the syntax, at the basic level, is such that it's almost automatic that one knows C# if one know C++ (new layers of convolution notwithstanding)?
That's a difficult one, because moving from C++ to C# isn't necessarily as easy as you think it will be just by looking at the syntax.
I came up the COBOL -> FORTRAN -> Pascal -> Assembler => C -> C++ -> C# route, and it's the superficial similarities that throw you off: you expect to need pointers and they aren't there. Same for globals, and references, and all the little nuances that you get used to in C++. So you end up trying to use C# as a "retarded brother" to C++ instead of a separate language in it's own right that shares some syntax with C++. You are actually better off forgetting C++ completely when you learn C# I think.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
At least there's nothing you're forced to use. You can keep coding using a .NET 2.0 style even though you're developing against the latest library, and the latest language features are at your disposal--which you can choose to ignore. The way it's once been described to me is that it's all "syntactic sugar".
Or am I misinterpreting what you mean?
|
|
|
|
|
Yes you can - but not everyone else will, so you get a lot of lazy coders using var all the time for example and to hell with the poor sod who has to maintain it in six months time!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Of all the useless things that have been added to the language over the years, var isn't one of them. I've long been opposed to var myself, but these days, when I see I've used var in some of my older code, it generally means the exact type didn't matter to me back then, and it still shouldn't matter to me today.
Some will abuse it for sure. But it's got its use.
|
|
|
|
|
It has it's uses - you can;t do Linq without it - but when you get lazy f'wits using it on every variable definition it's a PITA for maintenance:
var i = 666; Is just lazy.
var p = ComplicatedFunctionInAnotherClass(long, list, of, parameters); Is lazy, stupid, and uncaring of maintenance or the poor sod who will have to do it.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
OriginalGriff wrote: t has it's uses - you can;t do Linq without it
Linq is itself too often used/abused when often it's really not necessary at all, it's backward syntax order is a PITA for those of us that work in multiple languages and later need to unravel some newbies 'I can do it all in one line' compound statements. I'd not loose a second sleep if it were removed entirely.
signature upgrading ... please wait.
|
|
|
|
|
I completely agree on the syntax - that's why I use the methods instead - but Linq does have some advantages over the "loads of loops" approach! 
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Agreed! Linq makes things easier to write, easier to maintain, easier to understand, and just makes code 'prettier'. I cannot stand ugly code!
|
|
|
|
|
Does linq make the code more readable to the next programmer who picks up your code? If the linq covers a simple loop with some decisions inside which will be easier for the next person who maintains the code? Writing code for an organization with multiple programmers and engineers, not only must your code perform what is intended without breaking, but must be as quickly understandable by the next person who pick up the code. Because, you can be sure that your code will change as the customer needs change.
|
|
|
|
|
I agree with using a var for what clearly should be an int. Or should it be a long? Or a 64-bit unsigned int?
As for your 'p' example--it all depends on what you do with it next. If you just need to hang on to it so you can eventually return it from the current function, or to pass it as a param to another function, then under those circumstances I'd say the exact type shouldn't matter to a reader.
|
|
|
|
|
The first example is OK. I as a maintaining programmer know that i will be an int of some sort. The second example, what is p? Do I have to look at the function or intellisense to figure it out? Do I need to look at the context of how p is used later? No to all of these. The professional engineer's job is to not only make the product work as expected but to also make it easier for the next engineer to pick up the work and take it to the next step. (It's in the IEEE code of ethics.) It would seem that is the difference between a programmer/code jockey and an engineer.
|
|
|
|
|
OriginalGriff wrote: C# needs to be ripped apart and the same exercise done again
Couldn't agree more. It's getting so bloated and ugly that it's starting to look like C++.
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson
Our heads are round so our thoughts can change direction - Francis Picabia
|
|
|
|
|
Actually, they simplified C++, as did Java. C++ was getting quite complicated and watching Bjarne Stroustrup running through the variations of template examples was enough to make your head swim. Both Java and C# are good attempts to simplify what C++ has become. Also, most people decided to take up C# because of the pointer problems with C++. Too many times, a raw pointer would be missed or deleted too soon and problems would arise. This was occurring in much larger programs. So, I am happy (so far) with C#.
|
|
|
|
|
I'd also agree on "C# in a Nutshell" by Joseph and Ben Albahari. If you ever really want to take a deep dive into C# and the CLR I highly recommend "CLR via C#" by Jeffrey Richter. In the meantime though, the Microsoft Docs on C#[^] are quite good to start off with 
|
|
|
|
|
Jon McKee wrote: "CLR via C#"
This book is awesome. Must read for an in depth understanding of C# on top of .net.
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson
Our heads are round so our thoughts can change direction - Francis Picabia
|
|
|
|
|
This is the best choice, especially if you're coming from native c++. You need to learn not just the c# language, but how to use it effectively on the .net platform. I also came from c++ to c# via this book.
|
|
|
|
|
Always read the spec. Anything else is wrong.
|
|
|
|
|
So you are wrong 
|
|
|
|
|
|
|
Programming in the key of C# by Charles Petzold is excellent, especially when coming from older C-family languages
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
