In the beginning of 2011, I attended a C# seminar where the lecturer said something like the following: "In the future, I expect more tools like ReSharper and CodeRush to emerge because Microsoft has released #something#. This means that you no longer need to write your own C# compiler from scratch".
Unfortunately, I didn't catch what #something# is. Do you have any suggestions? (I've tried to mail the lecturer, but he didn't reply.)
EDIT: Maybe he said "C# parser", not "C# compiler".
Probably referring to the rumors that C# 5.0 will include a "compiler as a service" which will make it easy to compile arbitrary C# (and presumably other languages) code through a simple, efficient, method call, with all the supporting AST support that is integral to products such as ReSharper and CodeRush.
Must be compiler as service, already available in Mono - http://www.mono-project.com/CSharp_Compiler
Related
I know it might not be worth it but just for education purposes I want to know if there is a way to inject your own keywords to .NET languages.
For example I thought it's good to have C++ asm keyword in C#.
Remember I'm not talking about how to implement asm keyword but a general way to add keyword to C#.
My imagined code :
asm{
mov ax,1
add ax,4
}
So is there a way to achieve this ?
The answers which cover implementing keyword{ } suits enough for this question.
This isn't possible at the moment. However, there's a Microsoft project in development called Roslyn that can be summarised as "the compiler as a service." It allows you, amongst other things, to extend or modify the behaviour of the compiler through an API.
When Roslyn becomes available, I believe this should be something that (with caution!) is quite doable.
You can use whatever tools you would like to pre-process your code before sending it to the C# compiler. For example, you might use VS macros to do the pre-processing, mapping a given syntax that you invented into something that does compile into C# code, possibly generating an error if there is a problem. If VS macros aren't powerful enough for you then you can always use your own IDE that does whatever you code it to do to the text before sending it to the compiler.
There is no built in support in the compiler for specifying your own keywords/syntax; you would need to handle it entirely independent of the compiler.
Unfortunately this is not possible. You can't extend or alter the languages in any way.
You could in some obscure way use PostSharp to read and parse strings and transform them to custom code at compile time (a pre processor). But you would not get very happy with that, as it is very error prone and you won't get any kind of intellisense or code completion for your magic strings.
According to MSDN keywords are predefined and cannot be altered. So you can't add any, because you would need to tell the compiler how to handle them. Insofar, no you can't.
Sorry for what seems like it's likely covered in a FAQ/blog somewhere, but my Google-fu is apparently weak. :(
There's a handful of things that the debugging experience in VS 2010 lacks that seems like they're likely to be fixed during VS 11 (at least, IMHO), but it's been hard for me to tell whether they're really on 'the list' or not.
Some that come to mind:
edit-and-continue with 64-bit console apps (only works with 32-bit console apps in 2010)
edit-and-continue with Silverlight 5
watch (and immediate?) expressions with lambdas / anon delegates
edit-and-continue being ok with edits to methods that contain lambdas
As of the Developer Preview version, VS11...
edit-and-continue with 64-bit console apps STILL ARE NOT SUPPORTED
watch (and immediate?) expressions with lambdas / anon delegates STILL ARE NOT SUPPORTED
edit-and-continue being ok with edits to methods that contain lambdas STILL ARE NOT SUPPORTED
edit-and-continue with Silverlight 5 (I DON'T KNOW)
Don't let any of this stuff put you off, however. There are plenty of new features in VS11, and there's still a year before it's released anyway. Who knows? They might decide to add support for one of these.
Also, by the way, it is very unlikely that they will support Edit and Continue with lambdas / LINQ / anon delegates in the future. Why? Well, it has to do with the way that these language constructs are converted to IL. They may seem simple in a CS language file, but even the most basic lambda expression (something like i => i + 1) is actually converted into a hidden class at compile-time. This goes beyond the scope of Edit and Continue. If you're interested, create a very simple program that uses lambdas or delegates, compile it, and open it up in .NET Reflector. (http://www.reflector.net/. You can get a 30 day trial if you don't want to buy it.) Select the language as "IL" and try to make sense of it!
The prior issue was closed (deferred) so please vote for a new issue asking/begging for 64bit EditAndContinue (EnC) in 11.
https://connect.microsoft.com/VisualStudio/feedback/details/736684/edit-and-continue-is-not-supported-when-debugging-a-64-bit-application
Beta is just released [http://www.microsoft.com/visualstudio/11/en-us] and
edit-and-continue with 64-bit console apps STILL ARE NOT SUPPORTED
Think it should be supported? I do!, go make your vote count:
https://connect.microsoft.com/VisualStudio/feedback/details/559582/need-c-edit-and-continue-on-x64-native-mode
Throughout this site I commonly see people answer questions with such answers as "it works like that because the compiler replaces [thing] with [other thing]", so my question is, how do people know/learn this? Where can I learn these things?
The most definitive source for how the C# compiler interprets code is the C# language spec.
http://www.microsoft.com/download/en/details.aspx?id=7029
Also the following blogs provide a lot of more insight into the C# language. Mandatory reading for anyone who wants to become an expert in the language
http://blogs.msdn.com/b/ericlippert/
http://msmvps.com/blogs/jon_skeet/
One technique is to compile your code, and then decompile it using tools such as ILSpy. Using such a tool, you can view the raw IL and see for yourself what the compiler produces.
In addition to the other answers, I'd like to mention that LINQPad is my favorite tool for inspecting IL for quick snippets.
You can type a snippet of code, and immediately see the IL.
It's by far the easiest tool to use, and you can make changes and see the results instantly.
In addition to checking the Intermediate Language and reading the language specification, please allow me to add "CLR via C#" by Jeffrey Richter. Microsoft Press Library of Congress Control Number: 2009943026. This reference is amazing, and goes into complete detail on what's happening under the covers.
Niklaus Wirth's book Compiler Construction (PDF) is an introduction to the theory and the techniques of compiler construction. It gives you a general idea of what a compiler is and what it does.
Strange question but my boss is a touch old school and has insisted in our coding standards that we do not use C# shorthands for system types, he likes us to use the full system name. He likes things to be verbose and I happily comply with the standard.
However, something which after several months has started to grate on me is the fact that visual studio does not like to comply with the standard when completing code. So if I type:
KeyValuePair<Int32, Object> MyValue = new
Visual studio will finish the rest with:
KeyValuePair<int,object>
This is even worse when implementing an interface or abstract class.
This is a minor inconveniance but one none the less and I was wondering whether in the plethora of VS options there was one to force using the full System type names.
I believe that this can be solved use something like Re-Sharper but unfortunately there's no way I'm getting a license.
EDIT
Yes he despises the use of the var keyword. I should have stated his actual reasoning, it's because we mostly develop in C# but there is a high probability of needing to write in C and objective C so he does not want us to become too reliant upon CLR shorthands and he also says it would cause less pain when porting code which to a degree makes sense to me. His main aim with this is to avoid type mis matches with types such as Int16, Int32 & Int64 but as we are following a standard he prefers String over string. In all fairness, he is a very good coder if not a touch old school but his knowledge of things under the hood is vastly greater than mine and 90% of devs that I know, coming from a gaming background I guess makes you appreciate the finer points a touch more. I've always been spoilt with a nice managed .NET framework.
Many Thanks
Paul
My research indicates this is not possible. Maybe in a future version of Visual Studio...
I've been hearing/reading a lot about the new language enhancements for C# 4. I'm a little curious if these same enhancements are also going to be applied to VB as well, or what. Does anyone know where I can get some insight here? With all the new changes happening to C#, it seems like there will very little reason left to be using VB unless you happen to like the syntax. Are there enhancements that MS isn't making to VB this time that are getting included in C#, or visa versa?
I'd actually overlook the dismissal of VB.Net by Lou Franco. Checkout Panopticon Central:
http://www.panopticoncentral.net/archive/2008/10/31/24803.aspx
http://www.panopticoncentral.net/archive/2008/10/29/24764.aspx
For example:
Then Lucian did a really wonderful
demo of VB 10.0, which is shipping in
Visual Studio 2010. He showed (IIRC)
the following features that should be
familiar to the readers of this blog:
array literals, collection
initializers, automatic properties,
implicit line continuations, statement
lambdas, generic variance, and a
feature that embeds primary interop
assembly types in your assembly so you
don’t have to deploy the PIA. I may
have missed some, so check out the
video when it’s posted!
Some of the changes to C# (e.g Named Optional Parameters) were already in VB. The main strength of VB.NET over C# was Office/COM integration, and the new C# is addressing that.
If you need to target an older .NET version, VB.NET will still be the one to use if you need these features.
Something still missing from C# that vb.net has had a little while: xml literals. But this isn't exactly new.