I have read countless blogs, posts and StackOverflow questions about the new features of C# 4.0. Even new WPF 4.0 features have started to come out in the open. What I could not find and will like to know:
What are the major changes to CLR 4.0 from a C#/WPF developer perspective?
What are the major changes to CLR 4.0 as a whole?
I think, internally, most changes are for the new dynamic languages and parallel programming. But are there any other major improvements? Because language improvements are just that, language improvements. You just need the new compiler and those features can be used with a lower version of .Net, apart from version 1.0/1.1 (at least most of them can be used).
And if the above features are the only ones, only for these features the version is changed to 4.0, which I think is 4.0 because of being based on .Net 4.0 version (i.e. after 1.0/1.1, 2.0 & 3.0/3.5). Is the version increment justified?
Edited:
As Pavel Minaev pointed out in the comments, even those two features are CLR independent. There were speed and other improvements in 3.0 and 3.5 also. So why the version increment?
One new CLR thing that I know about is a form of structural typing for interfaces, structs and delegates for the sake of NoPIA support - basically, it lets runtime treat distinct types with equivalent definitions as if they were the same - so if two assemblies A and B each have a COM-imported interface IFoo declared in them, with the same IID and same members, runtime will treat them as equivalent types; so if there's an instance some class Foo implementing [A]IFoo, you can cast it to [B]IFoo, and the cast will work.
One other thing is the ability to host several CLR versions side-by-side in a single process. You cannot host 1.x and 2.0 in one process, for example, but you can host 2.0 and 4.0. The main benefit for this is the ability to load plugins written for either CLR version concurrently.
One minor bit is that a few more exceptions have become uncatchable like StackOverflowException was in 2.0 - you cannot catch AccessViolationException anymore, for example.
Also, here is a PowerPoint presentation on CLR 4.0 from PDC 2008. It might be a bit dated now, but most stuff that's mentioned there seems to be in the betas.
There are a huge number of changes.
In the CLR itself, there are a few changes. The garbage collector is being changed to support concurrent collection of gen0/1 and gen2 in workstation mode. Also, there are some changes in how security is implemented. The parallel framework changes some of the CLR's implementation of the threadpool (which is not entirely managed, but part of the runtime itself). Also, there are some changes to the type system, mostly related to the new PIA COM support.
The biggest changes are probably more library/framework changes, rather than CLR changes. such as the integration of the DLR into the framework, and the new dynamic type. In terms of framework, you have the reactive framework, parallel library extensions, code contracts, tuple support, and lots of small changes (ie: Enum.TryParse, Lazy<T>, and tons of other small, but nice, improvements).
I don't believe there are any new IL instructions. The new CLR has improvements to things like inlining and garbage collection which do the same job as the 2.0 CLR, but better. A virtual machine (such as the CLR or JVM) is an abstract concept with multiple possible implementations. I believe CLR 4.0 is the same abstract machine as in CLR 2.0, just with an improved implementation.
Even the new dynamic stuff is just a compiler trick with new APIs (unlike in Java where it's being proposed as a new opcode.)
If I'm wrong about this, I'd love to know!
For each release documentation teams create "What's new" documents.
Here is the one for C# 4.0 Beta2: What's New in Visual C# 2010
And here is the one for .NET Framework 4.0 Beta2: What's New in the .NET Framework Version 4
These are the most complete lists of changes you can find.
Many core interface and delegate types in the CLR have been updated in support of generic covariance and contravariance. For example, IEnumerable<T> has been changed to IEnumerable<out T>.
Here are the Changes in CLR 4.0
New security model
Garbage collector improvements
Improved thread pool for TPL
Improved production diagnostics
Generic covariance and contravariance
Type system changes for PIA COM support
New GAC
I tried looking at some of the new C# stuff in Reflector, to see if there's anything new down under:
dynamic types are translated to objects, via compiler magic, which adds library calls to handle runtime binding.
Optional parameters are handled via the compiler. If you call Foo(int x = 5), without specifying a value for x, you'll see the call as Foo(5) in Reflector.
So I guess the changes are nothing you can easily spot (like generic support in CLR 2.0).
Related
Wiithout wanting to create an open ended question....
F# is currently absent from the Windows 8 dev preview. There is a mapping layer in WinRT that wraps core objects into CLR objects for C# / VB or through other mappings for different languages.
Given that this model does not force languages through the CLR, my question as a functional programming novice is: Is this any benefit to F# (having a direct mapping to WinRT without the CLR layer could further reduce mutability, more native list types) or would it make sense to have a more purely functional language join the ecosystem and leave F# where it is (bearing in mind that interoperability is no longer restricted to CLR languages)
If anybody creates a pure functional mapping for WinRT, that would be quite interesting. However, there is no single right way of doing functional library for something (just like there is no single right way of doing object-oriented library).
The great thing about F# is that you can easily write your own functional wrapper over the underlying (imperative) API. For WinRT, this means that we can easily implement different functional approaches to WinRT programming, without having to write any COM-based mappings.
I’m writing a small application based on FParsec.
Today, I’m looking for an opportunity to make a version for Compact Framework.
Apparently, it is not that simple to build FParsec sources for .NET CF. The FParsecCS library has unsafe code and some references to the types that are not available in CF. Namely, System.Collections.Generic.HashSet, System.Text.DecoderFallbackException, and more.
I’m wondering if there’s any way to make it built. Obviously, I’m trying not to alter the code as it would be hard to update when further versions of FParsec released.
I don’t really care about performance. If there is a generic CharStream that can be used instead of high-performance one you have, that would be quite sufficient.
Thank you for your help.
I don’t have any experience with .NET CF and never tried to make FParsec run on it. However, there’s a Silverlight version of FParsec, which might be a good starting point for a port to .NET CF. The Silverlight version builds on the LOW_TRUST version of FParsec, which doesn’t use any "unsafe" code. Hopefully, the stream size limitation of the LOW_TRUST version won’t be an issue for your application.
The easiest way to deal with the HashSet dependency probably is to implement you own simple HashSet type (based on a Dictionary) that implements the few methods that FParsec actually uses for its error handling. If the DecoderFallbackException is not supported, you can just comment out the respective exception handlers.
If you track your changes with HG, it shouldn’t be difficult to merge in updates to FParsec. Depending on how extensive the changes for .NET CF are, I could also include them in the main source tree for another conditional compiler symbol.
Is there any framework or code generator for data access in Delphi based on layered architecture?
Delphi has already Multi-Tier / Layered architecture available since early versions. You were never limited to RAD components.
DataSnap is certainly the de-facto standard version of building such applications. See e.g. this article from Embarcadero.
Other Service-Based frameworks written on Delphi are available (DataAbstract,
RemObjects, KBMMw, Midware, WST, Synopse, Spring).
ORM framework are a good way of creating multi-tier separated applications (e.g. InstantObjects, DObject, tiOPF, GFramewok, Bold, Synopse, hcOPF, DelphiORM..). Some of them even allow to build Services above ORM. See for instance our Open source framework.
You can have a look at the various Object Persistence Frameworks out on the market. We have been using tiOPF for some years and are very happy with it. Although it has a very steep learning curve.
There are others available as well, like hcOPF
Summarization:
Please check the knowledgeable comments below.
==============================================================
I have seen the term of managed types mentioned in quite a few stackoverflow Delphi topics. For example, it is mentioned in topics of correctly initializing/finalizing. However, when I google managed types, it seems most links are related to C++, or .NET. For example, see the MSDN page. Could some one help to comment what are managed types defined in Delphi? Given that Delphi for POSIX/MacOS is being born, are managed types specific to Windows? Thanks for your effort and time in advance!
PS: Topics of correctly initializing/finalizing:
Which variables are initialized when in Delphi?
Are delphi variables initialized with a value by default?
How should I free an array of objects in a Delphi 7 destructor?
In Delphi 2009 do I need to free variant arrays?
In the context of Delphi, managed types are those types for whom the Delphi Compiler automatically generates lifecycle management code. This includes:
Strings
Open Dynamic Arrays
Records containing other managed types
Interfaces
(later edit) Anonymous methods
(later edit) Variants
Because managed types in the Delphi context are defined in terms of what the Delphi compiler generates, they're delphi-specific.
In the .NET world the developer doesn't need to manage the lifecycle of allocated memory because .NET provides an automatic mechanism for doing this: The Garbage Collector. But .NET includes the ability to work with things outside the CLR (example: using native DLL's that don't target the CLR). That code is usually called unamanged and unsafe.
In the context of .NET managed relates to what the CLR automatically manages, so that's .NET specific term!
See Barry Kelly's answer to a releated thread.
Since managed types are a language feature there shouldn't be significant changes on Mac OS et al.
I need to return objects from a DLL made in Delphi, to an app made in Delphi, too. The objective is to do a subsystem that can be modify in the future without to modify the main app. So, I imagine developing the subsystem in a DLL is a (good??) idea... i am programming in Windows XP, Delphi 7. I did read DLLs only return basic data type, but there must to be a way to do that...
Best regards.
I prefer to apply COM to such a model, which allows you to create external "objects" which you then can direct from within your application. Creating COM objects in Delphi is extremely simple, use your ActiveX creation methods to create an ActiveX library and then create COM objects. You then use the interface unit in your main application, and when you CoCreate an instance of the object it loads the appropriate DLL. The only tricky part of this is that your com objects must be registered on the system to function properly... which in the Win7/Vista world requires elevated access... although once this is done, it is seamless.
The BEST way is to use a COM wrapper as suggested by skamradt.
It is possible, but not a good idea to pass object references as pointers to DLL's. Refer particularly to Peter Haas's comments.
If you do pass an object from a Delphi DLL to a Delphi app you will have the following problems:
You must use the same version of Delphi for the app and DLL.
Both app and DLL MUST have the same implementation of the object - or at least identical layout of all fields in the class - OK if you are using standard objects such as TStringList.
You should use shared memory or runtime packages, otherwise you will get weird access violations.
I have had to maintain code where this was done - it was nightmarish as you couldn't change classes without a lot of re-compiling.
You can use interfaces and most of your problems, wrt compiler/rtl versions or even other languages just go away.
Delphi's interfaces are always IUnknown-compatible, which makes them compatible with most OO-enabled languages on Windows.
One thing to keep in mind, though: Don't use AnyString, stick to WideString, which is the Stringtype used by COM.
A platform- and language independent way could be to exchange serialized objects.
It has a performance impact, but it has advantages too: the DLL works without modifications with other languages and platforms like .Net or Java (via JNA Java Native Access). It does not depend on any special features of the operating system so it can as well be used on Linux or MacOS if you compile the library with Free Pascal.
For the serialization, you could use JSON or XML. There are open source libraries for Delphi, for example SuperObject and OmniXML.