Some features of the CsharpLanguage
Some things that sound neat:
Limited operator overloading in some respects - you can't overload == without !=, or < without >, for example. I would consider this a GoodThing, myself, but YourMileageMayVary.
- everything is an object (including the primitives!) (although the compiler can/will determine when it's best to use a native primitive)
- multi-dimensional array support
- dynamic class loading
- operator overloading
- built-in security model. Depends whether it actually provides any meaningful security.
- attributes, ability to attach metadata to just about anything
- parameter arrays
In some but not all respects... optional parameters, while allowed in VB.NET and VB 6, are not in C# - which can give you some rather awkward issues when calling one from the other.
- structs are held and passed by value (on stack?? yep)
- supports conditional compilation
- true and false are both keyword and boolean literal
- a foreach statement
- "delegates" are a language feature.
- will be better than VB ... is better than VB
MS address this issue, and others like it, with the CLS (Common Language Specification). It is a set of conventions to follow when writing classes that will be used from other languages. If you ask it to (by applying certain Attributes to your class) the C# compiler will verify that you comply with the CLS. See http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconwritingcls-compliantcode.asp
Ish. While you can register the (public) objects in a DotNet assembly as COM objects by running the appropriate utility, this doesn't happen by default. Also, if you want to control things like the ProgId, GUID (GloballyUniqueIdentifier), or whatever, you have to explicitly insert attributes to make it happen.
Actually, dotNet is not the same as COM, every C# object is indeed a language independent entity in the dotNet runtime world, but it is not a COM object.
- with C#, every object is automatically a COM object
#line isn't new -- C has had it for decades...
Heated good/bad debates surround these features:
- supports the MicrosoftDotNet standard of Reflection/Reflection-Emit
- attribute based programming allows definition of custom attributes that are applied to a compiled entity and can be interpreted during both run-time and compile-time
- new pre-processor directives:
- #line - lets you modify the compiler?s line number and (optionally) the file name output for errors and warnings.
- #region/endregion - used to group sections of code that will have the ability to be collapsed/expanded in the VisualStudioSeven UI.
How do you mean? C# compiles to IL which is just-in-time compiled, as other DotNet languages do. I'm not aware of any C# compiler that produces native code. And while a .NET assembly is not a one-.class-file-per-class arrangement as Java is, it is platform-independent.
(Technically, the platform-independent IL and metadata is wrapped in a PE file which possibly contains a Win32-specific 'stub', but the code it contains is entirely platform independent.
- It uses a preprocessor
- not really - the 'preprocessor' directives are parsed by the compiler, they're just designed (and named) to be familiar to c/c++ programmers.
- Compiles to platform native executable (without second step)
- Doesn't compile to platform independent ".class"-like file
Some folks feel these things are sad:
- Lots of attempts to remove 'unnecessary' brackets. Dangling else is solved by using the nearest corresponding if.
- There is no distinction between caught and uncaught exceptions
- switch statements follow the "no-fall-through" mechanism.
- switch statements can also be applied to strings (case-sensitive)
- properties are supported, i.e., what looks like a variable assignment or access in client code can have get and set methods associated with it. (please answer the PropertiesInCsharpQuestion)
- the addition of all of the unsigned types doesn't look like a win, but when you discover that the only implicit conversions are those which preserve information, it looks okay.
- You can turn on or off overflow checking for arithmetic operations in a block. Don't know if this propagates to the methods that are called in that block
- Inside a specially marked code block, developers are allowed to use pointers and traditional C/C++ features such as manually managed memory and pointer arithmetic (these blocks are called unsafe)
Doesn't exist yet, but is apparently planned for future versions. (Hopefully as some clean form of generic, rather than templates.) -- AlistairYoung, as are the above italicized interpolations
Here's a weird feature:
- has C++ style NameSpaces
- break and continue can't have a label.
- Event handlers are less general than anonymous classes ''there is no event handler, there are delegates, which are first class multicast functions, arguably better than anonymous classes, and definitely better in version 2.0 when anonymous delegates(lambda expressions) are released.
- no covariant return types
- Provides large primitive data types and overflow checking constructs, but does not appear to convert to unbounded representations.
- the name resolution rules look too involved, although there are some interesting features wrt. interfaces. it's a versioning feature, something java doesn't have.
- methods are not virtual by default. also a feature
- no template-like mechanism (or did I miss something?) version 2.0
See http://www.artima.com/intv/nonvirtual.html for some discussion of what's meant by versioning. Basically its all about the ability for some classes (e.g. ones in shared libraries) to be able to be upgraded without breaking other classes that rely on them.
- Par. 1.17 says "Versioning is an after-thought in most languages, but not in C#". Chapter 18, "Versioning", consists of a single, very blank, page.
Okay, so everything's an object.
If that were true, the number 5 and the string "xyzzy" would have methods.
and they do
, where (-5.abs) and ("xyzzy".length) are valid expressions that do just what they look like they do.
Nick, it is true. While the Int32 struct (what -5 would be typed as by default) doesn't have an Abs method (that's on the Math class), it does have some other methods, one of which is Format. The following C# works just as you describe:
"xyzzy".Length // length of a the string
100.Format("c", null) // formats the Int32 to a currency string
// using default system locale
Still, not EVERYTHING is an object. For example, a class in C# is not an object (though there may be objects that wrap classes).
This is simply a question, not a correction. Having watched the development of C++, with the large number of people, public discussion, man-hours, real-world deployments... that's a language I like (my bias). I'm skeptical of a language that was created by a single development team (*anyone's* development team - Sun, MS) in a vacuum, or with small focus groups. Is this the position of a well-grounded skeptic or am I just whining that closed development sucks
Sounds reasonable to me, and I rather like Java. (Don't know about C#) -- EricHerman
entirely developed C# by themselves. Other groups have been involved in the process, though Microsoft ran the show and made the other groups sign NDAs. While the process could have been a lot more open, it certainly wasn't entirely in secret. As MS is handing over C# to ECMA, future growth will be more open.
[From one perspective C# and Java are iterations in the refinement process of C++. Although each was written by a small group, they build on the work of other small groups.]
Remember also that C++ started out as an in-house preprocessor for C. Languages tend to oscillate between proprietary and public development; each has its advantages and flaws.
One very nice feature of C# that wasn't mentioned is that C# makes it rather easy to attach CustomMetaData
to things like object data or classes. This makes it very easy to customize the behavior of your application when using MetaProgramming
. -- JesseJones
Minor question: just how are non-virtual methods a feature? I'll concede any day they take a bit less time to bind, but I always viewed compile-time function binding as little more than a way of making an OO model behave in a way that's unnatural. Objects should act as what they are, not what we think they should/might be, or am I wrong here? If compile-time binding is desired, there should've been a mechanism for doing that explicitly, not the other way around. But then again, I'd suspect marketing aims to make the language as similar to C++ no matter what had their role to play too. -- DavidVallner?
(Biting his way through OO newbiedom.)
C# 3.0 has AnonymousFunction
s that can be read at run-time as "expression trees". In the upcoming ASP.NET MVC framework, an application is that a link can be specified as a lambda calling the method in the appropriate controller; the lambda is read and converted into a URL for the appropriate controller, method and parameters.
Lambda breaks edit-and-continue for the entire method, wasting so much time that it should nearly always be avoided.