Having said that, IEnumerable is a pretty bloody simple interface, and something similar could easily be whipped up outside of .NET.
SO …
Of all that C# development going on today …
How much of the work involves making interfaces (COM or otherwise) that allow the C# code to interoperate with existing native C++ code?
Hehe, I always used to pronounce it “hash”. As in “they really made a hash of C”. But then I actually started programming in C# and discovered that it’s a very nice language.
But you could argue that “hash” more correct. The symbol for “sharp” is actually “♯”, not “#”.
Financial companies use a lot of VB because of its integration with Excel.
And they use a lot of Excel because…
Gives the Quattro Pro salute and runs for cover
You probably already knew this, but Microsoft is of course aware of that:
Frequently Asked Questions About Visual C# .NET 2002 (microsoft.com)
I saw this example of a CIL program on wikipedia.org:
http://en.wikibooks.org/wiki/Transwiki:List_of_hello_world_programs#CIL
Does anyone write in CIL directly? (like old-fashioned system programmers would sometimes write a program in assembly code in the 1980s?)
I’ve never written in CIL directly, but I have experimented with dynamic assembly generation using the System.Reflection.Emit namespace, which involves emitting CIL statements. It’s pretty fun, but I wouldn’t want to do too much of it. You have to go through a lot of crap to do even the most simple stuff, and the the OpCodes class is pretty daunting. Most of my emitted methods were along the lines of “push this, this and this onto the stack and call this pre-existing method”, with the pre-existing method doing the actual processing (much like that Hello World program, in fact).
I know of a few people who specialize in compiler optimization who write a bit of CIL code, for testing purposes. This is mostly used to see how optimizations like out-of-order execution deal with the code. Writing anything significant in raw CIL looks to me like writing anything significant in raw assembly language, but without the good parts.
I should probably mention why one might want to dynamically generate assemblies. If you want to perform some kind of operation on an arbitrary type (which might not even exist yet), you might need to use reflection to get to the metadata. But reflection is slooooow, so if you’re performing the operation all the time it could really drag things down. So instead, you reflect the type just once, use the metadata to generate an assembly, and cache that assembly.
The XmlSerializer class is the perfect example of this. When you first create an XML Serializer for a specific type, the class reflects that type to determine its public properties, and reflects those properties’ types to find their public properties, and so on down the line until it reaches the basic types that can be converted directly to/from text. Then it generates an assembly for serializing and deserializing the type graph to/from XML, and reuses that assembly every time you need to serialize/deserialize that type again.
I have to work in C++, C#, Java, VB, and about a dozen flavors of scripting languages. C# with the .NET framework is by far superior to any of them for Windows development. Especially with .NET 3.0, with WPF, WCF, and other high-powered frameworks. You can be fabulously productive in C# when you really get going with it. C++ requires too much programmer effort just to do boilerplate stuff like memory management and interface construction. C# encourages good programming habits. The code is easy to read and understand.
Our organization is transitioning to C# in every place where it is possible to do so.
I’ve mentioned this in another thread, but those of you who are programming with .NET simply must add .NET Reflector to your arsenal. It lets you decompile and browse the source of existing assemblies effortlessly. Yes, I know that viewing the implementation details of classes flies right in the face of the fundamental principles of object-oriented programming, but it’s just so damn useful! And the readability of the generated code never fails to astound me.
I often find myself using poorly-documented third-party libraries, or I simply can’t be bothered bringing up the documentation. So I Alt-Tab to Reflector and browse to the appropriate class, and more often than not the source code answers whatever questions I had. It’s also useful if you ever ask yourself reasonable questions like “is the List<T> class implemented as an array list or a linked list?” And finally, you can learn a hell of a lot from simply browsing through the .NET core libraries and seeing how they do things.
Sorry about the advertisement. I’m not affiliated with Reflector in any way; I’m just an enthusiastic user. And it’s free, dammit!
No, as shown in this thread. And as another example, my company develops a LOT of very high-end software as a side business, and for internal use (primarily internal use) and it’s all in C++. We’re talking everything from 10,000-line small apps to 50M+ line monsters here.
People have been predicting “the death of C++” for as long as they’ve been predicting “teh deth of teh internets.” Typically when someone makes a blanket statement like you’ve reported, they’re just projecting their personal feelings into an authoritative statement.
I doubt that C++ will die the death of a thousand pinpricks or anything, but C# does finally offer a realistic alternative for creating real windowed apps. Java seems to have finally become viable for creating a professional looking GUI, but you’d be better off to use C# + .NET for 90% of everything. And previous to Java, the only thing to kind of make windows in was VB, and outside of making thrown-together windowed apps, VB is rather pointless and will most likely remain so. So while as there may have been people yearning for the death of C++, and thus predicting it, there’s not been anything to swap in as a replacement. Now there is.
Oh. My. God.
As someone who just took a job whose main task seems to be working with poorly-documented third-party libraries, you have just made my life SO MUCH BETTER.
MBossa, you are my fav person today!
Umm, what about MFC? With Visual C++ you can design windows and Visual C++ will generate a lot of code for you. Then you can insert you extra stuff.
And classes for most common interface items (buttons, listboxes, etc)
Brian
FANTASTIC response and info, thanks!
I’m particularly interested in scientific computing, and tried searching for
[term] scientific numerical
in Google, and got this comparison where [term] =:
c 12400000
c++ 939000
java 999000
c# 215000
php 1080000*
(“visual basic” OR "visualbasic) 262000
python 670000
ruby 340000
perl 451000
The first 20 php hits all had “.php” as the last characters in the web site name, so it’s probably a fluke.
True, but compared to C#.NET, MFC is a real pain in the butt even with Visual Studio.
The point in my post was that outside of C++ there hasn’t been any other language with a proper ability to create professional looking windows. Your post is just reinforcing that C++ could indeed do that.
Though, from everything I’ve ever read, MFC supposedly blows monkey balls. I always just used the Win32 API and created my own objects that referenced it internally.
coughDelphicough
And besides that, if you’re accessing raw APIs how is C++ any better than Python, Perl, C, Pascal or even Fortran at allowing you to create professional looking windows?