Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
i am preparing for my finals and came across this question:
Learn about the reflection mechanisms of Java, C# and Prolog, all of
which allow
a program to inspect and reason about its own symbol table at run time. How
complete are these mechanisms? (For example, can a program inspect symbols that
aren’t currently in scope?) What is reflection good for? What uses should be
considered good or bad programming practice?
Why is this question asked in terms of symbol table? Can i write the same solution that i write in terms of classes and objects like mentioned in this SO question:
What is reflection and why is it useful?
I think of reflection as the basic tool to do metaprogramming.
This turns out to be a declarative way to solve (a kind of) problems.
Sometime, instead of building a solution, can be useful to write something that allow to describe the problem space. That is, see if your problem can be restated in a more practical language.
You see, we treat languages as components of algorithms, like data. Then we can exchange components between languages.
Practically, an example of interesting Java/Prolog reflection is JPL
Some time ago I found useful - and performant - C# reflection. United to emit package allows to produce compiled code.
Prolog use reflection in seamless ways: for instance DCGs are really a 'simple' rewrite of declared rules.
I've started a project that I hope I will take me to Prolog controlling Qt interface,
of course Qt reflection plays a fundamental role.
edit About your question on symbol tables: symbol is an extremely general term. Also all languages have a concept of symbols, (maybe) differently aggregated. That's the core of languages. Then the question is perfectly posed in very general terms, just to check your understanding of these basic language concepts.
The "symbol table" is just an internal concept that is needed for "reflection" to do what it does: the ability of a program to examine itself at runtime and do something dynamically with that. (be aware about the diff between - introspection vs. reflection).
So if you understand what reflection is good for, how it is implemented in your target platform (Java, C# etc.), and what might be the limitations, you should be able to answer all those questions I suppose.
Think about the symbol table as just an "implementation detail" of a platform/runtime. According to the question above I don't think they expect you to know exactly how this is implemented.
I'd suggest you to read the following pages to get an idea of reflection in the corresponding language:
JAVA
C#
Prolog - Search for 'Reflection'
After Reading those you shold see similarities of the methods.
To be honest, I've never worked with reflection in Prolog, but the docs should guide you through.
The symobl table is used by the reflection mechanisms to look the things up.
See here for a description of symbol tables.
Those resources should give you an idea on how to answer your questions
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.
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
This question already has answers here:
Questions every good .NET developer should be able to answer? [closed]
(25 answers)
Closed 2 years ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
Sure, we all have written tons of C# code. So walking into an interview for a .NET job should be a no-brainer, right? And then you read some stackoverflow posts and it hits you: You don't know squat!
Remember that site with the cram sessions to go through, before taking an exam? I think stackoverflow could be used to make a sorted (voting) list of topics to know about.
Please only put one topic per post.
Please also add some information about the topic. Links, reference material etc.
EDIT: I guess some of you misunderstood the reason for the post - I'm hoping to generate a list of stuff to know about .NET, a sort of cram session that can be reviewed by everyone on the planet to regularly review. This should help us all remember arcane stuff we never really use.
They are likely going to ask you questions that are based more on Object Oriented Design and Programming more than questions that are explicitly geared towards C#. So if you can explain abstraction, polymorphism, interfaces, etc. You should be good to go.
Reference vs value types.
Know your delegates. Every .Net interview I've been on has asked me about delegates. Know why they exist, know how to declare them, and how to consume them, understand what multicast delegate is. Understand how to use a multicast delegate when one of the handlers throws an exception. Know what the compiler does with a delegate. Understand how delegates can give you "automatic" asynchronous APIs. Get familiar with the newer more convenient generic delegates - Action and Func.
Bonus: delegates vs events. What are the differences? When would you use one over the other?
Generics.
(also - don't try to cram and pass yourself off as an expert on something. A good interviewer will figure that out very, very quickly.)
I don't see how this question is valuable to your situation. The result of this question is going to be 30 posts listing features of the C# language.
I think you need to refine your question by giving us a hint about what type of job you are applying for. Or your skill set level or what areas your familiar with. Otherwise this post won't really contain a valuable answer.
EDIT
[OP] That (30 posts listing features of the C# language) is precisely what I am after
Then I suggest the C# language spec. http://msdn.microsoft.com/en-us/vcsharp/aa336809.aspx
ScottHa has two great lists of interview questions:
ASP.NET Interview Questions
What Great .NET Developers Ought To Know
Reflection. and the power of custom attributes in reflection.
Stack vs Heap: What goes where, what caused a StackOverflowException and what causes an OutOfMemoryException.
Generics, why generic lists are prefered rather then arraylist or hashtable. Performance issues and strongly typed added by the way.
Bonus: benefits of generic non-collection types. Why would one use these? How?
I hope the job interview is about coding itself. c# is just a syntax of programming. To be sure read about some specific C# things like reference vs value types
I'd start by looking at the latest c# enhancements. Also, it really depends on what type of job it is as there are a lot of things an ASP.Net developer won't know about Winforms and vice versa.
Assuming asp.net, I've been asked the following in interviews over the past 18 months:
Page Life Cycle
Generics
Interfaces / basic OO design
SQL; e.g. joins, updates, inserts,
etc. Also, how to use DataReader and
sqlcommand.
LINQ syntax; not because anyone is really using this, rather because they read about it.
Web Services ( asmx and wcf )
basic html / css
Session strategies for single server
/ load balanced
Differences between gridview,
repeater, etc.
What I've found is that most .net "web" dev's don't know diddly about sql or html. If you can prove you know more than just how to "drag and drop" controls on a web form then you're already better than 90% of the guys you'll run into.
If you've been writing code in one discipline (.NET in this case) that long, you should have a pretty standard answer to the technical questions that you don't know:
Q: So, what do you know about [technobabble]
A: Well, I haven't used that particular aspect in my previous projects, however, I have a small Volkswagen full of on-line resources that I check for answers like that. In other words, if I don't know it, I know where I can learn about it.
Optional addendum: "And here's an example of me dooing just that when I had a project that required [technobabble-2]..."
You know, if you just plummet through the ECMA-334 specification you should be all set. That's the language... but in away, you'll still be limited by your knowledge of the framework and that's experience. Hard earned experience.
OOPS Concepts
ADO.NET
Session mgmt and Caching
SQL Server distributed transactions
management
New features in .NET 2.0
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.