|
messages wrote: Now my question is what's the best way to learn it?
Going through CP articles.
Here is an example[^]
|
|
|
|
|
Thanks for link
|
|
|
|
|
Pravarakhya wrote: Going through CP articles.
.. cant agree more!
Smile: A curve that can set a lot of things straight!
(\ /)
(O.o)
(><)
|
|
|
|
|
Only way to learn C# is:
1 Forget C++ use only the syntax
2 Read the conception of .Net Framework and C#
2 Learn more about event handling
3 Read some articles about databases and C#
4 Read 10 (beter 20) books for C#
That's it
You know C++. OK so, how many books you have reed to learn c++
Strahil Shorgov
|
|
|
|
|
Exactly I read two books for c++ and also read MSDN and studied example MSDN(I dont know but I think maybe C# is difficult than C++),however C# almost like C++ but I dont know why I couldnt learn it
|
|
|
|
|
messages wrote: I dont know but I think maybe C# is difficult than C++
Forget that and you'll learn C# in no time.
|
|
|
|
|
"I dont know but I think maybe C# is difficult than C++"
Wrong. C++ is difficult than C#.
However, I started with C++, but for me C# was easy to learn. C++ is more powerful than C#. But C# is more inteligent.
Try to start from begining. (Use "Hello World" program and so on).
Repead the steps that you used to lear C++
Strahil Shorgov
|
|
|
|
|
C# is a lot easier than C/C++;
If you are used to program in C++ with classes and STL then you won't have problems to learn C#, if you are used to mix C and C++ on your code then it will cost a little more.
In C# you forget about the pointers, basically everything is a pointer except of primitives but everything is managed internally and the GC take care of the memory release, basically it was borrowed the from a prototype language that never made it, I think is called “Java”, only you will use pointers on unsafe code when you need to work with the memory directly, which is not pretty common, if you know the framework usually almost always there is a way to have the same performance doing it with pure C#.
C# almost "force" you to use classes/inheritance/polymorphism/generics, so you will lose many vicious that probably you have from C/C++ and you will spend a lot more time thinking in the right pattern/design than spend time finding where the heck the memory leak is.
|
|
|
|
|
starcraft4ever wrote: C# almost "force" you to use classes/inheritance/polymorphism/generics
I still mourn the loss of multiple inheritance. 
|
|
|
|
|
I can't agree more...
Long time ago had a chat with some guys where they said that you can replace multiple inheritance with interfaces, where basically they didn't have a clue about how powerful multiple inheritance can be.
The problem with it is that is like "nuclear reaction" in the right hands is amazing, in the wrong hands will be over used and will create a complete chaos on the design/code.
In a language like C# where pointers are almost removed, keep multiple inheritance in C# is totally contradictory to make the language safer.
Anyway, I miss it too.
|
|
|
|
|
The problem is, they want C# to be idiot proof. They are more worried about how it can be misused, than concerned about how it would be used in the right hands. The switch statement is ample proof of this. As is generics. Both watered down versions of stuff that C++ allows to do so much more.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
"I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
|
|
|
|
|
I think having .NET as multi-language and interoperable was a design consideration. Though Eiffel managed to retain MI and still work and be interoperable on .NET.
|
|
|
|
|
I think it was a bug in the design and later they could not change it , many times I was really pissed when I tried to do.
switch(var)
{
case A:
do A;
case B:
do B;
break;
}
And it doesn't compile. 
|
|
|
|
|
It's not a 'bug', it was a deliberate decision to make C# easier to use ( because there's no way to accidentally fall through ). As an MVP, I've been in a position to talk to the language designers, that's what they told me.
I love C#, but I am also very much opposed to their design philosophies. They amount to telling me I am an idiot.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
"I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
|
|
|
|
|
Wow that's cool, you had the chance to talk with the language designers.
I guess that was a wonderful experience which I don't mind if you want to share. 
|
|
|
|
|
I also think that it's nuts to include an unsafe keyword in a supposedly-bulletproof language.
And as it comes up so often, I'd also like to see a simple keyword-based way of creating this kind of code:
public int Day{
get {
return day;
}
set {
day = value;
}
}
int day;
|
|
|
|
|
type in 'prop' and hit tab twice?? (VS2005) 
Dave
|
|
|
|
|
You live and learn. 
|
|
|
|
|
You can do that with refactoring, (couple clicks).
Right click on the variable declaration and => Refactor => Encapsulate Field
also could be nice if C# could do something like this;
public class a
{
private int mDay;
public property Day(mDay);
or
public property Day mDay;
or more directly in the declaration
private int mDay public property Day;
private int mDay expose public Day;
}
|
|
|
|
|
But that defeats the whole purpose. To be honest, when you're just writing public set/get methods, I think it's stupid to even bother with a property. It's just a waste of time.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
"I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
|
|
|
|
|
Yep, but I really dislike to make a private member as public.
I like to call my member with mXXX which in that case If I do that then my object will expose a variable mXXX which looks pretty bad.
Ofcourse as you know having a wrapper property to expose a variable allows you to expand the code behavior in the future and then the interface won't need to be changed as for example raise an event when the variable gets changed.
C# has many things that allows you to save code, if could exist something as I mention before, later if it needs to be expanded then replace the property declaration with a property body, so the property signature won't change.
In fact the compiler could detect a property declaration and replace it for a public/internal variable at compilation time, that could optimize the code too as long the property doesn't have a body.
Same case for example with anonymous methods, they allow you to save code and calls, but many people think they are ugly, but anyway they are there.
|
|
|
|
|
For most applications, having public fields is no problem. Don't blindly trust every FxCop rule.
Only if you require binary compatibility between versions of your library, you shouldn't have any public fields - not because there is any problems with public fields, but because you later might want to add raising an event to the setter and thus need a property.
What I really would like to see is a way to create attributes/something else that transforms the source code before compiling - so I could create my own way of generating repetitive code (e.g. for properties). Something like http://www.postsharp.org/, but it would have to run while compiling - before doesn't work because I would like to have type information available, after doesn't work because then I couldn't simply access the generated members.
|
|
|
|
|
|
messages wrote: maybe C# is difficult than C++),
Wrong
messages wrote: however C# almost like C++
Totally wrong. C# is like Java, it's nothing like C++
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
A 5 from me
Roswell
"Angelinos -- excuse me. There will be civility today."
Antonio VillaRaigosa
City Mayor, Los Angeles, CA
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
