As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm trying to find a least-resistance path from C# to C++, and while I feel I handle C# pretty well after two solid years, I'm still not sure I've gotten the "groove" of C++, despite numerous attempts.
Are there any particular books or websites that might be suitable for this transition?
About two years ago, I made the switch from C# to C++ (after 10 years of writing java). The most useful book for me was Bruce Eckel's Thinking in C++ [AMZN]. You can also read the book online at Eckel's website. It's a well-written book--the kind you can read in bed--that's also useful as a keyboard-side reference. It assumes a significant level of comfort with OO and general programming concepts.
Stroustrup [AMZN] is invaluable as a reference, but basically impenetrable unless you're trying to answer a very specific question--and even then, it's a struggle. I haven't cracked my K&R [AMZN] in a few years. I don't think it's got much value as a C++ reference. Myers' Effective C++ [AMZN] (and, once you get there, Effective STL [AMZN]) are fantastic books. They're very specific, though (e.g., "36. Design functor classes for pass-by-value"), and hence not as useful as Eckel for making the transition.
My experience writing C++ after many years writing managed languages has been great. C++ is a hundred times more expressive than C#, and extremely satisfying to write--where it's warranted. On the other hand, on the rare occasions when I still get to write C#, I'm always amazed by how quickly and succinctly I can get things done.
Anyway, Eckel's Effective C++ can help you make the transition. There's a second volume that's good, but not as good. Stick with the original.
Good luck!
I recommend The C++ Programming language by Bjarne Stroustrup. It's not a suitable book for new programmers, but I found it quite effective as programmer who was experienced in other languages and didn't want to waste too much time with learning how while loops work. It's a dense but quite comprehensive book.
I suggest you to read The C++ Programming Language book (written by Bjarne Stroustrup). It may not be the best book to begin with, but it is definitely on you should read, sooner or later.
Anything written by Meyers, recommended by same, or written by Sutter.
Accelerated C++ by Koenig (Edit: and Moo.)
They are fundamentally very different beasts so there is no least resistance path between. However I recommend you to read http://www.phpcompiler.org/doc/virtualinheritance.html beforehand in case you ever need a non-trivial inheritance. It can save you a few headaches.
The C++ Programming Language by Bjarne Stroustrup is a must read. Effective C++ (Scott Meyers) is another book I found helpful.
And to balance all this, read the C++ FQA ( http://yosefk.com/c++fqa/ ) - while not a book, it's a valuable resource, and I wish I had access to it when I was getting started with C++. Just don't let it discourage you.
I found Lippman et al's "C++ Primer: 4th edition" to be excellent. It emphasizes STL usage, best practices, and auto_ptr usage from the very first. I went from a Java position to a C++ assignment, and it was really excellent.
As a pure reference, Josuttis's "The C++ Standard Library" was STL at its best (and worst...the guy really doesn't pull punches)
Lastly, Meyer's Effective C++, as others have said is a must-read for the "gotchas" inherent in C++
This is a list of books that are recommended by the folks over in #C++ EFNet: http://rafb.net/efnet_cpp/books/
I'd consider [K&R](http://en.wikipedia.org/wiki/The_C_Programming_Language_(book)) a prerequisite for C++. Perhaps the best thing about C++ is that it's a better C.
And of course, Stroustrup (as suggested by Mladen Jankovic) is a must read.
My two standard books are "Object-Oriented Programming in C++", Third Edition, by Robert LaFore, published by The Waite Group, and "C++ from the Ground Up" by Herbert Shildt, published by Osborne McGraw-Hill.
You should read one of the other books posted, but then also The Design & Evolution of C++. It helps you to get inside the head of what the language is trying to do.
Related
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
In what areas might the use of F# be more appropriate than C#?
I'm anticipating giving a presentation at the local .Net user group about F#. And I'm anticipating the "Why should I look into F#?" question from the audience. I know most of the stuff that can be done in F# can be done in C# too--so I'm looking for things that can be done easily in F# that are really hard to do in C# (e. g. pattern matching). And if there are already good answers to this question, please just link them in comments and I'll close this up. I did see a few things but if there's already a question that addresses this I didn't find it.
By the way, if any of the moderators want to mark this community wiki please feel free; this seems more like a survey question to me anyway.
Since F# is a functional language, it should be far easier to implement a domain-specific language in it.
One of a main concept is asyncrounus calls in F#, also F# uses immutable variables so concurrency is easy.
see http://research.microsoft.com/apps/pubs/default.aspx?id=147194
and http://research.microsoft.com/apps/pubs/default.aspx?id=79947 and other Don Syme articles. may be there are other differences, but I think gathering them here is just doing your homework.
i would say
Asynchronous programming.
Units of measure
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I've been working with C# and more generally the .Net framework for a couple of years now. I often heard about the similarity between C# & the Java language and would like to learn more about the second one.
Have you got any specific advice to learn Java when coming from C# ?
Any common errors a C# programmer would do when starting Java ?
Any documentation showing the habits you can keep and the ones you must change (still in a C# to Java optic, so something a bit more specific then a C# vs Java comparison) ?
Well, while C# and Java are superficially alike there are a number of small differences that might bite you. Generally I think the opposite direction—going from Java to C#—is less problematic. This is mainly due to C# being a more complex language so you might find many simplifications from common Java patterns but the other way around might be a little painful.
Things to look out for (partial list, not guaranteed to be exhaustive):
Different ...
Naming conventions. In Java only type names start with a capital letter (i. e. PascalCase), everything else uses camelCase. Not very hard to adhere to, though.
Also interfaces generally don't start with I. On the other hand you have to implement them with a different keyword. Doesn't really help in the middle of the code, though.
Class library :-)
While obvious, this has been the thing I spent most time on when learning a language. When dealing with a known paradigm the syntax differences are quickly sorted out, but getting to know the standard library / class library / framework takes some time in some cases :-)
Patterns. Well, not quite, it's still the same stuff. But C# supports some patterns at the language level, while you still have to implement them yourself in Java. No events, but the Observer pattern (very prevalent in Swing—whenever you see a Listener, you know what to do :-))
Exception handling. Java has so-called checked exceptions which means that an exception must either be caught or declared upwards. Usually this means that you have
catch (SomeException ex) {
ex.printStackTrace();
}
pretty often in your code1 :-)
Types. While .NET has normal objects and value types, they both are objects and support methods, properties, &c. Java has a dichotomy of primitive types, such as int, float, char, &c. and classes such as String. Doesn't matter much since they implemented auto-boxing, but sometimes it's still annoying to wrap int in Integer.
Polymorphism: All Java methods are virtual by default whereas c# methods are not.
Minor syntactic differences.
foreach (a in b) → for (a : b)
Different access keywords. Things like internal and protected internal don't exist. But unqualified members are visible to other classes in the same package (sort of internal, but then again not quite).
String comparison isn't done with == in Java. You have to use .equals(). While in C# == on strings is value equality, in Java == is always reference equality.
No ...
Properties. In Java this is generally done with the Foo getFoo()/void setFoo(Foo foo) pattern which C# generates silently behind your back when using properties but you have to do it explicitly in Java. Generally, to keep the language itself simpler many things in Java are just conventions. Still, most of the time you're better off adhering to them :-)
Operator overloading. Deemed a hazard to the righteous programmer they weren't implemented for fear of abuse. Don't need them too often anyway, not even in C#, but sometimes they are nice and then you're missing something.
Indexers. You always have to access list items through myList.get(5) instead of the array-like syntax myList[5]. Just a mild inconvenience, though.
LINQ (though there exist implementations2 but it's not as nicely integrated), or lambda functions3 (no delegates anyway, but anonymous classes), extension methods, or partial classes (yes, that's a painful one when dealing with Swing, unless you're very disciplined), and a few more things.
Multidimensional arrays. You can use jagged arrays (arrays of arrays), buttrue multidimensionality isn't there.
Generics are compile-time only, at runtime only Objects remain. Also wildcards in generics can be hard to resolve sometimes when the compiler complains about all of the four ? in your generics having different types. (Though to be fair: That was a case where I would have needed type information at runtime anyway so I reverted back to Objects).
General advice: Grab a friend with Java experience and let him glance over your code. While he probably can't tell you everything you should take care of when you directly ask him that question, he can spot strange things in code just fine and notify you of that. This has greatly helped me learning Java (although I learned Java first and then C#, so it might be different).
1 Yes, I know many catch blocks look different, but still, this is probably the archetypical one and not even that rare.
2 Quaere, JaQue, JaQu, Querydsl
3 There's lambdaj, though. Thanks for pointing that out, Esko.
I honestly think the biggest hurdle for many C# developers trying to learn Java is learning a new IDE. Visual Studio is great, and when you're coding in C# for a long period of time, you get used to it. When having to move over to Eclipse or Netbeans, you suddenly feel lost. How do I set a breakpoint? Where's the immediate window? How do I create a windows app? etc etc... I know this sounds crazy, but I'm telling you, people get very attached to their IDE's and have a tough time getting used to new ones...
Languages themselves are pretty similar, sans few keywords and Java lacking some features C# programmers got used to (properties, using, reified (non-type-erased) generics).
The main problem here is knowledge of frameworks, of which there are thousands for Java.
The main language is fine. Getting to know the libraries will be one thing which takes time. If you're doing web-applications, there is a LOT to learn... equivalent technologies to WCF and ASP.net.
You don't say what kind of area you work in... desktop, server, or web-server?
Biggest difference between C# and Java : In Java, all methods are virtual. Hence the reason why tools such as NUnit and such came from the Java world.
To be honest, if you're a competent C# programmer I don't believe there's much you do need to know apart from packaging and deployment of applications.
Here's a good link http://en.wikipedia.org/wiki/Comparison_of_Java_and_C_Sharp
The biggest thing you need to learn is how to Greenspun C#'s functional style features in Java. For example, you can expect to make a lot of interfaces with only one method to get around Java's lack of lambda functions and delegates.
I honestly recommend Java in a Nutshell. Most Java/any_other_lang introduction books are for totally novice readers explaining the concept of a loop for pages and recursion for a chapter... You can start writing Java programs within two days with this book. Of course it will take you a long time to understand what is going on under the hood and how to use all the available framework. But once the language itself is mastered, it is easy to get along even with google only resources.
Although, this is the other way around, I found the following link to be quite useful for comparing Java and C#.
C# From a Java Developer's Perspective
I made a transition from Java to C# and back to Java again. I think syntactically they are very similar and most of the trouble I had was learning the .NET APIs and learning how to use them effectively. Many times I was using 'syntactic sugar', writing my code as if it was in Java and then translating it to C#. I spent a lot of time on Microsoft's website reading and learning about the APIs which was a huge help.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I recently applied for a developer position and the director there asked me to send some samples of code.
How should I approach this? Once, I sent a sample of code that I wrote for myself to a company and they didn't get back. This time, I want to be prepared and send appropriate samples. I want to know what I should send them, create a sample website/code it and send a link along with code files, or create a sample project, or some other approach.
I cannot send code that I have written for my previous and current employer, so I'm not sure what to send.
They asked for C#, HTML, CSS, JS, SProcs, triggers samples, so I thought: would it be nice if I create a project that includes all the above and send it to them, or should I send individual samples?
You've pretty much answered your own question. Why not create a project including all of the above? Small games are fun to write and you can demonstrate a lot of knowledge by creating one. Websites are good too, if you want to demonstrate things like good UI design and dynamic HTML and scripting knowledge.
It's essentially your portfolio to demonstrate what you're capable of, so apply all your knowledge. This includes not just what the program does but also how it does it -- good choice of algorithms, code architecture, proper naming of variables and appropriate comments, etc.
You can write code that's of just as high quality as what you'd create for an employer -- higher, in fact, since you have complete control over the methodology and standards used. Install one of the free revision control systems (git, mercurial, subversion etc), use bugzilla to track your bugs and todo list, and write a full suite of unit tests. Produce professional documentation and demo screenshots.
Yeah, that's a lot of work. But I can guarantee you that if such a project crossed my hiring desk, I'd have you in for an interview in a hot minute.
I've been in this situation before, and I usually just refuse to send them the code samples.
The reason is this: when I work for an employer, I'm working professionally, and the employer has exclusive rights to all the code. If I tried to copy the code and send it to another potential employer, I'm at risk of major intellectual property theft. On the other hand, if I create some code for my own use, it is by definition amateur code (even if produced by a professional), and doesn't have the same level of project management stricture, test stricture, etc., and is therefore not representative at all of my professional coding skills.
Companies that ask for this are effectively asking for the impossible. I find it best to point this out to them.
I'd take something I already worked on - preferably three-tier including sprocs, etc., and factor out anything of a sensitive nature. If it's something you wrote yourself then you will be comfortable discussing it and able to show the breadth of your knowledge - that's what will land you the job. A complete project shows that you know how everything fits together. One more thing: if they ask you where you go to find good code samples, do not immediately say Google: tell them you would look in their code base ;-)
Besides what you send them (a project, a website), I suggest you also give some thought as to what you want to convey with it, and give a written introduction to the sample: why you think it's an interesting piece of code? What does it showcase? What pieces are you proud of? What were the challenges?
They should be able to figure that out themselves, but there is no harm in helping people see what you want them to see...
WHen I intervoiew people I often ask them to give me some code. Usually I asked them to code infront of me though but I guess my point would be the same if the send it to me. I don't look at what they've done (the functionality) but how they've done it. What design principles guide their work. How tidy is the code. What's their test strategy. Have they used any patterns and if so are they used in a well thought way. Depending on the language I'd look for specific aspects of the language. In c++ I'd love to see them be capable of using template specialization elegantly (E.g. for traits/policies) in c#3.0 I'd look for propper use of lambda expressions, generics, LINQ I'd be looking for both correct use as well as over use.
Hope it gave you an idea of what kind of scrutiny you might be put through
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
A very open question. I've been programming in C# for the
past 5 months doing small projects that I completed
successfully.
Today I went to an interview for a C# role. The 1st question
was 'Tell me about boxing'. Given my experience I had no
idea what the guy meant. Needless to say the interview
didn't go that well. Others questions were 'why isn't it
recommended to use an ArrayList of int', 'tell me what you
know about threading', etc.
I don't really want this to happen again so I'm planning to
spend some time reading (and practising) more on C#. I
understand that the best way of learning is by coding but
coding wouldn't have really helped me answer the question
about 'boxing' for example.
I'm not asking you to answer the above technical questions.
In fact, I know now their answer as I went straight to
Google after the interview and it's how I realised that my
C# knowledge is somewhat limited.
My question is: in your opinion, which knowledge should any
C# developer have? Ideally it would be better if you could
categorize it (Basic knowledge anyone should have without
exception, Advanced knowledge, Expert knowledge etc). No need
to go into details. Doing research on whatever you list will
be a good exercise for me.
I would expect someone going for a professional C# job to know about:
Generics and generic collections
Interfaces (general)
Interfaces (specific), namely -
IDisposable: how it's integrated into the language and why
IEnumerable: including common extension methods, iterator blocks, and deferred execution
Overview of serialization in .Net (maybe not have done it, but understand what it is and know where to look in the namespace heirarchy and documentation)
Overview of Xml in .Net (same as serialization)
Overview of threading concepts (same as xml/serialization). Bonus points for understanding why most thread-safe collections aren't.
Have used anonymous delegates / lambdas in at least one project, and therefore also have a basic idea about closures.
Comfortable explaining some basic concepts from at least one of winforms, wpf, webforms, or MVC
Be able to answer some easy questions on specific common classes in the .Net BCL: namely from System.Data (think parameterized queries!) and System.IO (filestreams, path).
Garbage collection: when should you call GC.Collect (hint: pretty much never) and why
Here is a good list: What Great .NET Developers Ought To Know.
My personal experience from a long time ago when I was in school.
I went to see my father at work in a bank. At that time, most of his day was taking care of accounts and making sure every thing worked. What I saw was he was trying to tally/calculate large numbers and calculating(basic additions/multiplications...).
After noticing him, I asked him: Dad, if all you have to do is basic additions and multiplications, why bother to study till graduation?
His response was : While you don't have to use all the knowledge you have acquired, that knowledge would help you make learned decisions.
Coming to your question: While you dont have to use the entire set of concepts, knowing that they exist would help you make good decisions while you code.
My suggestion along with the others posted would be to try and spend some time on stackoverflow every day.
Good luck.
A good interviewer isn't going to grill you on trivia. That's why we have Google. A good interviewer is going to find areas you don't know, and ask you questions there, as that's the best place to find out how you react when confronted with something you don't have down pat.
The best advice I can give for interviews is to not worry about the technical trivia too much. Instead, in an interview, focus on problem-solving skills. If you don't know something, don't try to hide it, just admit it. If you think you know, it's okay to say "I'm not sure, but I think it's this." And don't get flummoxed either - at that point, usually the interviewer will give you a hint. This is not just giving you the answer, it's another part of the test - to see if, given a nudge in the right direction, you can extrapolate from there.
For the boxing/ArrayList/int questions, if I was interviewing and you didn't understand boxing, I'd give you a basic description of what boxing did. Then I'd ask you, knowing what I just told you, why you might think using ints in an ArrayList might be a bad idea.
One thing that will go far in any interview is focusing on the requirements, the desired result, and boundary conditions or edge cases. As most programming interview questions fall into the "write this method" category, make sure you get the following correct:
1) The inputs to the method
2) The expected output of the method
3) Boundary and edge cases.
This sounds ridiculously basic, but it's amazing how many developers, even ones with experience, don't bother thinking through these things. Code solves a problem - if you don't understand the problem correctly, you can't solve it correctly.
I would have to say that if an interviewer can be fooled into thinking someone has more .NET / C# experience by he or she visiting a webpage, then the interviewer is failing. I've interviewed a number of people myself, and I really like the approach of giving them some easy to understand problem to solve, and asking them to write some code on a white board. Even if they've memorized the answers to every question on Scott Hanselman's blog, I would learn a lot about how comfortable they are in the language, as well as how they go about problem solving. I'm looking for a developer, not a partner for Trivial Pursuit, .NET Developer Edition.
That said, keeping up with blogs like Hanselman's is a fantastic way to keep up with the jargon. You could code C# in a vacuum for years, fully understand the advantage of a strongly-typed List<int> over ArrayList, but never actually use the term "boxing". But it's much more time consuming in an interview to ask, "Describe the advantage of iterating through a List<int> instead of an ArrayList of int," than it is to ask, "Tell me about boxing." Plus, actually researching the answers to Hanselman's .NET interview questions (especially if you explore the details and ask "Why?") will make you a better developer. So by all means, keeping reading Hanselman.
And one more note... If I ask someone whether a String is a reference type or a value type, and they simply say "Hmmm... Reference type," I'm not going to be nearly as happy as I would if the response was, "Hmmm... Reference type, but that's an interesting question." "Why is that?", I say... "Because string is implemented so that the string is immutable, allowing you to do things with it like safely use it as a hash key. Or pass it to a method, knowing the value cannot be changed. So in a way, strings can act a lot like value types..." And that would be a great conversation, leading me to ask, "So tell me more about why hash keys should be immutable..."
It's not just the difference between answering a 50/50 question correctly and all the additional information in the second answer. Having an intelligent conversation with a interviewee leads me to think I'll have intelligent conversations like that on a regular basis once the interviewee becomes my coworker. And that's something I'm definitely looking for.
Also depends on the role. If this was advertised as a jnr role then a threading question is a little tough...sometimes agencies/employers have unrealistic expectations.
A similar thing happened to my significant other taking a driving test. The state trooper said, "make a roundabout" and she didn't know what he was talking about. Both of us think a roundabout is a type of road layout with a big circle, not a u-turn as the instructor meant. So I know what you mean.
Programming job interviews vary wildly. Some people think you can't really judge a programmer well in an interview and are willing to give anyone who makes a good impression a chance. Others are grueling things which only those overqualified for the position would pass, and you will probably be suprised how often you get a call back from those.
This is something I have been pondering myself a lot lately. Using C# plenty but not sure what I am missing.
I ordered
Microsoft® .NET Framework Application Development Foundation
Which covers a lot of ground related to C#
Also looking at C# in Depth
Read some of this already. Has some great information from a high quality author.
In depth is on sale too via Jon Skeet's blog
When we talk about the .NET world the CLR is what everything we do depends on.
What is the minimum knowledge of CLR a .NET programmer must have to be a good programmer?
Can you give me one/many you think is/are the most important subjects:
GC?, AppDomain?, Threads?, Processes?, Assemblies/Fusion?
I will very much appreciate if you post a links to articles, blogs, books or other on the topic where more information could be found.
Update: I noticed from some of comments that my question was not clear to some. When I say CLR I don't mean .Net Framework. It is NOT about memorizing .NET libraries, it is rather to understand how does the execution environment (in which those libraries live on runtime) work.
My question was directly inspired by John Robbins the author of "Debugging Applications for Microsoft® .NET" book (which I recommend) and colleague of here cited Jeffrey Richter at Wintellect. In one of introductory chapters he is saying that "...any .NET programmer should know what is probing and how assemblies are loaded into runtime". Do you think there are other such things?
Last Update: After having read first 5 chapters of "CLR via C#" I must say to anyone reading this. If you haven't allready, read this book!
Most of those are way deeper than the kind of thing many developers fall down on in my experience. Most misunderstood (and important) aspects in my experience:
Value types vs reference types
Variables vs objects
Pass by ref vs pass by value
Delegates and events
Distinguishing between language, runtime and framework
Boxing
Garbage collection
On the "variables vs objects" front, here are three statements about the code
string x = "hello";
(Very bad) x is a string with 5 letters
(Slightly better) x is a reference to a string with 5 letters
(Correct) The value of x is a reference to a string with 5 letters
Obviously the first two are okay in "casual" conversation, but only if everyone involved understands the real situation.
A great programmer cannot be measured by the quantity of things he knows about the CLR. Sure it's a nice beginning, but he must also know OOP/D/A and a lot of other things like Design Patterns, Best Practices, O/RM concepts etc.
Fact is I'd say a "great .Net programmer" doesn't necessary need to know much about the CLR at all as long as he has great knowledge about general programming theory and concepts...
I would rather hire a "great Java developer" with great general knowledge and experience in Java for a .Net job then a "master" in .Net that have little experience and thinks O/RM is a stock ticker and stored procedures are a great way to "abstract away the database"...
I've seen professional teachers in .Net completely fail in doing really simple things without breaking their backs due to lack of "general knowledge" while they at the same time "know everything" there is to know about .Net and the CLR...
Updated: reading the relevant parts of the book CLR via C# by Jeffrey Richter..this book can be a good reference..
Should know about Memory Management, Delegates
Jon's answer seems to be pretty complete to me (plus delegates) but I think what fundamentally seperates a good programmer from an average one is answering the why questions rather than the how. It's great to know how garbage collections works and how value types and reference types work, but it's a whole other level to understand when to use a value type vs. reference type. It's the difference between speaking in a language vs. giving a speech in a language (it's all about how we apply the knowledge we have and how we arrive at those decisions).
Jon's answer is good. Those are all fairly basic but important areas that a lot of developers do not have a good understanding of. I think knowing the difference between value and reference types ties in to a basic understanding of how the GC in .NET behaves, but, more importantly, a good understanding of the Dispose pattern is important.
The rest of the areas you mention are either very deep knowledge about the CLR itself or more advanced concepts that aren't widely used (yet). [.NET 4.0 will start to change some of that with the introduction of the parallel extensions and MEF.]
One thing that can be really tricky to grasp is deferred execution and the likes.
How do you explain how a method that returns an IEnumerable works? What does a delegate really do? things like that.