What Programming Language to use for Win Apps?

[malebolgia]

Now that I have some free time I'd like to start making some applications for Windows. Since I've never created an application for Windows before I'm not sure what language to use. I'm thinking of learning .Net, but again I'm not sure. Any input would be appreciated.

 

[Fryguy8]

.NET is probably what you want to get started with. C# in particular.

 

[malebolgia]

.NET is probably what you want to get started with. C# in particular.

Can I use C# to create buttons and stuff?

 

[HorsePunchKid]

I know very little about C#, but after visiting this handy link and clicking around a bit, I can safely say that yes, it can be used to create buttons and stuff.

 

[Whatsisname]

i'd say learn C++ and MFC. That way if you ever get bored of windows applications you'll still know how to program in a flexible language used to create lots of shit. Or if you want to switch to GTK so you can make cross platform applications, etc.

 

[Xipher]

Well, C# is one of the newer ones, but C++ is pretty tried and true. GTK can be crossplatform, although you might also look into wxWidgets as well, which actually can use GTK on linux, but will use the native winidows library when compiled on Win32.

Also, yes C# can do gui.

 

[HJB417]

.net!

 

[malebolgia]

i'd say learn C++ and MFC. That way if you ever get bored of windows applications you'll still know how to program in a flexible language used to create lots of shit. Or if you want to switch to GTK so you can make cross platform applications, etc.

What's MFC?

 

[Lord of Shadows]

Microsoft Foundation Classes, buy a book. You will need to have a basic understanding of c++ classes to get anything done.

http://www.amazon.com/exec/obidos/t...102-6587900-6257709?v=glance&s=books&n=507846

You can read the first page or so of this to get an idea about what it will be like.

 

[Fryguy8]

.NET is the future and it's much easier to use than win32.

 

[doh]

C#

It's just easier to start with what will obsolete old methods.

 

[Cobalt2112]

But, don't all languages in .Net ultimately lead to the same thing? The CLR ??

So they all run just as fast, it just your preference in how to program? Also, one of those WizBang languages may be neat to know, but can you get a REAL job using it? I work at fortune 500 manufacturer and don't see anything else but WebSphere, VB, VB.NET, C++, Cobol, KSH, Perl. Ohh yeah... brush up on your SQL (either PL*SQL or T*SQL) ... sorry and dont want to start a flame, but My*SQL is not found in too many enterprises, just mickey mouse shops that cant afford real DBMS like Oracle or SQL Server.

Just my thoughts, don't flame me!

 

[The Bryophyte]

C++ is fairly ubiquitous but using it proficiently for gui's is no beginner's task. VB is really easy, to the point where it almost feels like cheating, but you pay for it in the flexibility and power of the language. I know COBOL...it is hell. Please don't learn it. I want it to die.

 

[K_ris]

.NET is the future and it's much easier to use than win32.

It's easier but not the "future" in the way it sounds like you ment it. It's true more and more applications will be created in it for windows, especially in longhorn (explorer.exe will be rewritten in .Net from what I've heard) and it might be a future in windows but don't expect it to pick up on other platforms. C# is standardized so it can be used on any platform, the only thing is Microsoft and Mono are the only 2 compilers for the language. Microsoft's is Windows only and Mono works kind of and works somewhat on windows and linux.

C++ and then C++0X will still remain one of the most used languages. No one is going to switch to .Net for game development, process intensive applications, or even OSes. Plus many companies have a code base already written in C++. it would be counter productive to rewrite in a slower language tied into a framework.

Plus the fact that it can be decompiled and you can get almost the exact source code makes other parts of the software development sector stay away from it.

But, don't all languages in .Net ultimately lead to the same thing? The CLR ??

So they all run just as fast, it just your preference in how to program?

You'd think they would run as fast. That's logical but the truth is that they don't. I've seen countless benchmarks and I've even created applications in VB.Net and C#.Net with identical code and the C# with IO and other things is faster. I was actually able to cut off seconds on a process in one of my applications by converting to C# from VB. For some reason C# is able to optimize the MSIL code better than VB. Again I'm not sure why but C# is usually fast, especially in IO.

 

[Steel Chicken]

.NET

VB is slightly easier than C#
C# is easier than C++

C# is the best blend of ease of use and capabilities

 

[malebolgia]

The extent of my programming knowledge is C and some Java (command line stuff, no GUIs). I think I'll give C# a try, but I'm not sure what book to get. Any suggestions?

 

[K_ris]

The extent of my programming knowledge is C and some Java (command line stuff, no GUIs). I think I'll give C# a try, but I'm not sure what book to get. Any suggestions?

If you're looking to create games with it, C# and game programming: a beginners guide is pretty good. Other than that I'm not sure (I learned it mostly because I had a VB.Net book and I knew C++ so it was an easy transition)

 

[malebolgia]

If you're looking to create games with it, C# and game programming: a beginners guide is pretty good. Other than that I'm not sure (I learned it mostly because I had a VB.Net book and I knew C++ so it was an easy transition)

I'll probably create games with it in the future, but for right now I'd like to create some applications (random projects I want to get out of the way).

 

[mikeblas]

Microsoft Foundation Classes, buy a book. You will need to have a basic understanding of c++ classes to get anything done.

Of course, I would rather see him buy this book.

 

[KRiTiKuL FX]

... the only thing is Microsoft and Mono are the only 2 compilers for the language. Microsoft's is Windows only and Mono works kind of and works somewhat on windows and linux.
...

Not anymore. Mainsoft Grasshopper is a VS.Net plugin that compiles code that works on Linux and other servers that run Tomcat. Yes, it's based off of Mono, but if I read their site correctly, it has a few more features than Mono.

 

[mikeblas]

.NET is the future and it's much easier to use than win32.

It's also substantially slower than using the API directly. Hopefully, this gets fixed soon, and .NET 2.0 makes some progress. But for now, the .NET framework is observably slower than apps which are coded against Win32 directly.

 

[Conker]

C++ is pretty easy to learn when you get the hang of remembering the codes.

 

[K_ris]

It's also substantially slower than using the API directly. Hopefully, this gets fixed soon, and .NET 2.0 makes some progress. But for now, the .NET framework is observably slower than apps which are coded against Win32 directly.

The main reason is because the apps are compiled on demand. This won't change so don't expect them to speed up that much if any. Now as processor speed increases this may not even matter in several years

 

[[MS]]

It's also substantially slower than using the API directly. Hopefully, this gets fixed soon, and .NET 2.0 makes some progress. But for now, the .NET framework is observably slower than apps which are coded against Win32 directly.

I find this to be more related to application design than anything else. A while back for a minor programming challenge I went about creating an optimizing an application to submit. The final design of the application took a couple hours to code in C# (which I did first), and another 12 hours to do in C++ (which I did second). This was after days of prior versions that were used to find the best design and all optimizations I could find. They both contained the same optimizations, except that the C++ version managed it's memory allocation itself rather than depending on the CRT's "new\delete" methods of allocating and freeing memory. It did this because the program was optimized to break a larger problem down into smaller chunks that would fit exactly with a 4KB memory page, and so managing it's own memory wasn't bad, and ultimately got and extra half a percent or so over the built in functionality

Time wise, the C# version scaled slightly better than the C++ version (but they were within 1% - 2%.
Memory wise, the C# version had an additional overhead of ~2.3 MB, and scaled slightly worse than the C++ version within 2% - 3% So for problem that took 250MB for the C++ version, the C# version took around 260MB.

In the grand scheme of things they were both very close performance. I was able to get the C++ version to be a little bit better when it came to memory, but it required a lot of extra work and was then requiring the win32 APIs directly to do the memory allocations.

 

[mikeblas]

The main reason is because the apps are compiled on demand. This won't change so don't expect them to speed up that much if any. Now as processor speed increases this may not even matter in several years

Apps don't have to be compiled on demand: you can NGEN them.

The main reason that .NET framework applications are slower than Win32-direct applications is that the .NET framework adds at least a few layers of indirection between the Win32 API and the application. The application ends up going through these layers, where redundant work is sometimes done, to get to the same job done.

Interop and pInvoke are always there, and have a non-zero cost. The framework may offer a less-than-optimal implementation, or might provide a very thick wrapper over the desired functionality. These last two things are where the big costs are.

The final design of the application took a couple hours to code in C# (which I did first), and another 12 hours to do in C++ (which I did second).

These numbers are interesting, but without your code (and lots of other information) they're really meaningless.

For example, how much C++ experience did you have? How well do you know the Win32 API? What C++ libraries did you try to use (or end up using)? How much (and what parts) of the Win32 API and .NET Framework did the application need? Was the workload I/O bound, or CPU bound? How much so? Multithreaded? GUI, or a console app? Or a web service, or something else?

And so on.

Only having a 2.3 meg difference in working set (which is what I assume you mean by "memory wise") is very suprising. "Hello World" for a C# app is about 6 megs larger in C# than in C++, last I looked (about a year ago, when .NET 1.1 was still new).

Note that I'm only applying this assertion to the .NET framework itself, here. If you use WinForms, your application will be visibly slower, and there's not going to be much you can do about it until WinForms improves. If you use other parts of the framework, you're in a similar boat: you're betting your perf (and stability) on someone else's code -- code that you can't even look at yourself. Sometimes, it's a reasonable bet; the SqlServer client seems pretty performant and usable, as long as you're not trying to do anything too aggressive. For other applications, like classic "thick client" stuff, it's not much fun at all.

C# compiles pretty well, even when it's just JITted. There's problems here and there (comparing GUIDs is one that recently bit me) but if you're just executing your own code and not relying on the frameworks, you're not in bad shape. And that's not what I'm talking about here.

The funny thing is, though, there aren't many interesting applications you can write without needing the frameworks to talk to the world outside of your application. A program for a programming contest probably doesn't have much in common with a shipping, GUI-based utility in a commercial application.

 

[aringail]

Java!!!

*ducks and runs for cover*

If you get a good IDE like Eclipse it will do alot of the work for you. It even has a gui editor that's marginally better than a root canal Which is still better than and MFC GUI editor I have used.

Plus it would work okay on a Mac/PC/Unix if you want it to.

Please nobody say Java is slow for gui's. It's not. Eclipse is actually written in Java, and so is Limewire. I have never thought of them as slow. I have also seen dozens of custom apps at various companies that work really well. I know the inevitable "java suxors" or the always charming "java is slow like ass" comments are on their way, but I thought I would throw the suggestion up for you.

 

[[MS]]

Apps don't have to be compiled on demand: you can NGEN them.

The main reason that .NET framework applications are slower than Win32-direct applications is that the .NET framework adds at least a few layers of indirection between the Win32 API and the application. The application ends up going through these layers, where redundant work is sometimes done, to get to the same job done.

Interop and pInvoke are always there, and have a non-zero cost. The framework may offer a less-than-optimal implementation, or might provide a very thick wrapper over the desired functionality. These last two things are where the big costs are.

Correct. Your initial statements were fairly broad, so my response was on that same level of detail. There is some cost involved in COM interop, and to a lesser degree platform invokes. So if an application is making a large number of calls into external components, the overhead increase. If not a lot of calls were being made into external components, the overhead is a non-issue. So it’s very much dependent on the application in question.

These numbers are interesting, but without your code (and lots of other information) they're really meaningless.

For example, how much C++ experience did you have?
How well do you know the Win32 API?
What C++ libraries did you try to use (or end up using)?
How much (and what parts) of the Win32 API and .NET Framework did the application need?
Was the workload I/O bound, or CPU bound?
How much so? Multithreaded?
GUI, or a console app?
Or a web service, or something else?

And so on.

8 years, on and off.
Moderate, though that didn’t come into play for the application, only a subset of the memory management APIs were needed.
Don’t remember the exact dependencies, it was a couple years ago.
The required sections were quite limited, in both cases.
CPU bound, and for large problems memory bound.
Though fluid simulation would normally lend itself to parallelism, the particular requirements in this case required a single threaded approach (ugh).
App had very limited output by default, because of the overhead; GUI representation of the algorithm could be enabled, but there was no requirement for it.
The app was basically a simulation for a fluid flow problem, not requiring any communication other than initial problem parameters.

Only having a 2.3 meg difference in working set (which is what I assume you mean by "memory wise") is very suprising. "Hello World" for a C# app is about 6 megs larger in C# than in C++, last I looked (about a year ago, when .NET 1.1 was still new).

Yes, working set.

IIRC, for the minimum model size in the app, C# came up to something like 5.7MB and C++ came out to 3.4MB. Most of the size, in both cases, is the loaded modules. Less that 100K was data I think. If your working set is 6MB larger, you must be using\loading libraries that mine was not since just your diff is more that the total mine required.

Note that I'm only applying this assertion to the .NET framework itself, here. If you use WinForms, your application will be visibly slower, and there's not going to be much you can do about it until WinForms improves. If you use other parts of the framework, you're in a similar boat: you're betting your perf (and stability) on someone else's code -- code that you can't even look at yourself. Sometimes, it's a reasonable bet; the SqlServer client seems pretty performant and usable, as long as you're not trying to do anything too aggressive. For other applications, like classic "thick client" stuff, it's not much fun at all.

C# compiles pretty well, even when it's just JITted. There's problems here and there (comparing GUIDs is one that recently bit me) but if you're just executing your own code and not relying on the frameworks, you're not in bad shape. And that's not what I'm talking about here.

Well, it’s hard for me to respond to specific issues you highlight since I’m not familiar with much of the code within the runtime itself. However I’d agree with the premise that there is always room for improvement.

On the flip side though, C++ apps will seldom improve themselves when a new CPU comes out. There are cases where a .NET app will perform much better on a P4 than a P3, due to a couple instructions that were introduced on the new chip.

The funny thing is, though, there aren't many interesting applications you can write without needing the frameworks to talk to the world outside of your application. A program for a programming contest probably doesn't have much in common with a shipping, GUI-based utility in a commercial application.

There are a wide range of applications, some GUI, some web, some services, some command line, some none of the above. Absolutely my application in question had little to do with anything based on a heavy duty GUI, however it was pretty similar in style and requirements to many data mining applications I’ve worked on, where the bulk of the work isn’t reflected in any sort of GUI. In most of the tools\apps I write, the latency to the backend DB (or sometimes the DB itself) are usually the bottlenecks.

 

[mikeblas]

So if an application is making a large number of calls into external components, the overhead increase. If not a lot of calls were being made into external components, the overhead is a non-issue. So it’s very much dependent on the application in question.

That's correct.

The problem is, the operating system is an external component as far as .NET is concerned. If you write a C++ program and you want to call CreateFile(), you call CreateFile(). If you write a .NET program and you want to create a file, you call something that does some stuff, thinks about it, wads up an interop call, and only then does it call the CreateFile() API. On the way back, the results from CreateFile() are massaged and transformed, and then your program finally gets control again.

For a simple API like CreateFile(), it's a bunch of overhead. It's not that bad, and maybe you don't call CreateFile() lots. But for a GUI-based application, interaction with the operating system happens whenever a message is sent or received by the application. And since Windows provides an event-based API for its GUI, interaction with the "external components" happens constantly.

On top of it is the dubious WinForms implementation, which is far thicker and than it probably needs to be -- particularly given the properties of the platform where it's implemented; this expensive interop activity, and you start having train wrecks.

Moderate, though that didn’t come into play for the application, only a subset of the memory management APIs were needed.
The required sections were quite limited, in both cases.

Sounds like you wrote a console application. That let you avoid WinForms, which is by far and away the most lethargic section of the .NET Framework.

IIRC, for the minimum model size in the app, C# came up to something like 5.7MB and C++ came out to 3.4MB. Most of the size, in both cases, is the loaded modules. Less that 100K was data I think. If your working set is 6MB larger, you must be using\loading libraries that mine was not since just your diff is more that the total mine required.

I just coded "Hello World" with native C++ and C# using Visual C++ 7.0. The workingset for the C++ version was 524 kilobytes. The working set for the managed version is 4832 kilobytes.

That the managed version has a workingset more than nine times the size of the native version demonstrates the code granularity problem that managed code suffers. When I build a C++ program, it gets linked. The linker carefully figures out what code from which libraries I need, and takes it. It discards anything that I don't use.

In managed languages, this operation doesn't happen in the same way. If I touch any part of any library, I end up getting the whole library in my workingset!

On the flip side though, C++ apps will seldom improve themselves when a new CPU comes out. There are cases where a .NET app will perform much better on a P4 than a P3, due to a couple instructions that were introduced on the new chip.

As far as I'm concerned, this "feature" is cause for alarm, not celebration. If I'm going to ship an application that recompiles itself when a new .NET build is installed, or when it detects a new processor architecture, how can I test it? Compiler bugs do happen; I'd rather compile once in my lab, and then test on different architectures without changing my bits than have the bits change in the field when it's too late for me to test them.

Further, I think it's overly optomistic to expect that code generation in the field is going to change enough whe n a idfferent processor is detected to make a substantial difference in execution time. Small differences? Sure -- but my point is that I don't feel like the risk is outweighed by the reward.

Absolutely my application in question had little to do with anything based on a heavy duty GUI, however it was pretty similar in style and requirements to many data mining applications I’ve worked on, where the bulk of the work isn’t reflected in any sort of GUI. In most of the tools\apps I write, the latency to the backend DB (or sometimes the DB itself) are usually the bottlenecks.

If it didn't have a GUI, I might be tempted to call it a tool rather than an application. I think you noticed less severe problems with performance and working set because you weren't using the .NET Framework extensively. Only using memory management APIs means that you didn't even read files, draw a window, or generate output!

The more you stay away from the frameworks, the more you're just using the language. Managed code generally isn't that bad; it's within 10% of native code for execution speed. It does have glaringly bad granularity problems, though, and that affects working set and startup time adversely. The problems I'm talking about (and I thought I had been very specific in explaining this) involve using the framework.

So how does this relate to the original poster's question? I'm not convinced that learning .NET-based languages is a good idea because the tools and platforms need to change in order to improve the problems that I'm tlaking about here. Is learning a shaky platform really the right call?

The OP wants a langauge "to use for Win Apps". Follow-up from the OP shows that means GUI-based stuff, and GUI-based applications demonstrate managed code performance at its worst.

Certainly, there are lots of advantages to managed code and the .NET frameworks. Lots of people think those benefits outweigh the problems, but I don't think that I'm one of them.

 

[[MS]]

I just coded "Hello World" with native C++ and C# using Visual C++ 7.0. The workingset for the C++ version was 524 kilobytes. The working set for the managed version is 4832 kilobytes.

But crt libraries are not the only thing using memory. In my case it would seem that for the minimum problem size, the difference was much smaller that the hello world case. I can only assume that for hello world, a few platform libraries are not being loaded for C++ that I was using

That the managed version has a workingset more than nine times the size of the native version demonstrates the code granularity problem that managed code suffers. When I build a C++ program, it gets linked. The linker carefully figures out what code from which libraries I need, and takes it. It discards anything that I don't use.

In managed languages, this operation doesn't happen in the same way. If I touch any part of any library, I end up getting the whole library in my workingset!

In managed code the basic building block is the Assembly. This has advantages and disadvantages. For example, it allows CAS while not affected performance much in most cases. I gather that you’d rather go without the advantages and disadvantages and keep to C++ and static linking, that’s completely valid as well. There’s advantages and disadvantages doing that as well. We just have different priorities I guess.

As far as I'm concerned, this "feature" is cause for alarm, not celebration. If I'm going to ship an application that recompiles itself when a new .NET build is installed, or when it detects a new processor architecture, how can I test it? Compiler bugs do happen; I'd rather compile once in my lab, and then test on different architectures without changing my bits than have the bits change in the field when it's too late for me to test them.

Further, I think it's overly optomistic to expect that code generation in the field is going to change enough whe n a idfferent processor is detected to make a substantial difference in execution time. Small differences? Sure -- but my point is that I don't feel like the risk is outweighed by the reward.

The case I was thinking of was one where, to get the CLI spec’ed behavior, one JIT instruction for a certain type of floating point conversion was resolving to ~20 native instructions on anything earlier than a P4. At that time a new SSE instruction was made available that generated the exact same results as what the spec called for (provably identical), but with a single native instruction. Overall, performance for that conversion went up by an order of magnitude.

The JIT guys are very careful about their work and improvements though, and they receive direct help and guidance from Intel on such matters. As you say, causing a back-compat issue in the JIT would a large issue (akin to causing a back-compat issue in a common win32 API during servicing), and so they are very careful and do a lot of testing on even the most minute things. If JIT broke in a scenario (or a common win32 API broke, for comparison), that’s something that would have to fixed asap by our servicing guys.

The more you stay away from the frameworks, the more you're just using the language. Managed code generally isn't that bad; it's within 10% of native code for execution speed. It does have glaringly bad granularity problems, though, and that affects working set and startup time adversely. The problems I'm talking about (and I thought I had been very specific in explaining this) involve using the framework.

Ah, that’s part of why we seem to be in disagreement. I consider languages to be specifications only, anyone can write a C# compiler. I consider the Microsoft C#, VB, and JSC compilers (as well as the IL), to be part of the framework since they are tightly coupled. The actual command like executables are pretty much just wrappers around library objects which implement the compilers, libraries that are also exposed in different ways, like ICodeCompiler, CodeDom, and the VSA engines, which are also parts of the framework.

Certainly, there are lots of advantages to managed code and the .NET frameworks. Lots of people think those benefits outweigh the problems, but I don't think that I'm one of them.

And thus the difference of opinion between us. I’ve never had issues with the BCLs or loader being the bottleneck in my apps (yes, GUI apps ). We obviously have different requirements.

 

[nuclearfly]

Java!!!

*ducks and runs for cover*

Second!!

*ducks and runs for cover*

 

[mikeblas]

In managed code the basic building block is the Assembly. This has advantages and disadvantages. For example, it allows CAS while not affected performance much in most cases. I gather that you’d rather go without the advantages and disadvantages and keep to C++ and static linking, that’s completely valid as well. There’s advantages and disadvantages doing that as well. We just have different priorities I guess.

What is CAS in this context? The only thing I can bind it to is "column address strobe", and that's obviously not what you're talking about.

I think the real reason we're in disagreement is that you're in denial about the disadvantages. I can't guess why you haven't seen them; failing to measure them accurately or aggressively, maybe. Or not having to ship otherwise good code which is hamstrung by the weaknesses of the .NET platform.

But, indeed: I'd much rather pay as I go for whatever library I'm using instead of buying into the whole thing, at great cost, if I even look at it sideways. This is a disadvantage that I think is very severe.

If JIT broke in a scenario (or a common win32 API broke, for comparison), that’s something that would have to fixed asap by our servicing guys.

It's great that they're careful. But they're also not doing any of the work: It's up to me, myself, to test my application against their new releases, against new platforms, in whichever combinations my customers are likely to encounter. It has to be that way with the model they've implemented, as they don't have my code.

Can every development organization in the world, from small-fry shareware guy, through a successful ISV, to a large Fortune 100 company with substantial in-house IT staff, afford to do that testing for each release of .NET? For each new hardware platform which might trigger a different in-field compilation?

I consider the Microsoft C#, VB, and JSC compilers (as well as the IL), to be part of the framework since they are tightly coupled. The actual command like executables are pretty much just wrappers around library objects which implement the compilers, [...]

I can't understand how seeing the implementation compiler as a part of the framework is consequential. I'm talking about runtime behaviour of executables, not the tools.

And thus the difference of opinion between us. I’ve never had issues with the BCLs or loader being the bottleneck in my apps (yes, GUI apps ). We obviously have different requirements.

Yep: I require that my applications load quickly, paint fast, and aren't lethargic in response when navigating between windows. I can't imagine how you've failed to notice these problems in WinForms applications -- try rewriting CALC.EXE, for example. You don't have to worry about the functionality. Just draw the Scientific View form in the designer and run it. It'll paint in about twice the time as the native CALC.EXE. And take substantially more memory to do so, even though you've implemented none of the application's logic!

Say I'm just learning to program. Writing something like CALC (though, simpler) might not be a bad first project, right? Would you really want to go through all that trouble to end up with something that's wicked-slow?

 

[HJB417]

I'm confident [MS] is fully aware of the disadvantages of the .NET framework. He probably chooses to use it because the advantages outweigh the disadvantages.

ansi c++
1) managed code runs faster
2) I'm in control of memory allocation
3) c++ has covariant returns

.NET
1) I can created mixed mode dlls which gives me the best of both worlds
2) The BCL, where are my std c++ threads and sockets.
3) reflection
4) garbage collector

To know if the .NET framework is better than unamanaged code is determined by what it is you're trying to acomplish and in what amount of time.

Since the topic is on winapps though, using MFC of win32 will always? be more responsive than WinForms. In this case, I believe your trading speedy responsiveness for easier to manage source code. Though ,with efficient .net coding, one should be able to create almost as responsive winform apps. e.x.: I use sourcegear vault, and their gui client was a winforms app. I didn't even notice until a cowoker pointed it out, and I've been using the product for almost a year =/

 

[[MS]]

What is CAS in this context? The only thing I can bind it to is "column address strobe", and that's obviously not what you're talking about.

CAS = Code Access Security. One of the big advantages of the CLR is the security system, of which CAS is a primary part.

I think the real reason we're in disagreement is that you're in denial about the disadvantages. I can't guess why you haven't seen them; failing to measure them accurately or aggressively, maybe. Or not having to ship otherwise good code which is hamstrung by the weaknesses of the .NET platform.

But, indeed: I'd much rather pay as I go for whatever library I'm using instead of buying into the whole thing, at great cost, if I even look at it sideways. This is a disadvantage that I think is very severe.

I’m agreeing that there is additional memory overhead, and when doing interop\invokes there is some overhead, but obviously we disagree on the impact of those things. But then, I try not to spend my time arguing here, just offering help.

So as far as my experience goes:
I’ve never personally run into perf issue where the primary cause what the framework. Normally I find that my application design is not as optimal as it could be, or that outside issues such as DB latency\speed are the limiting factors. Interop with COM can definitely be limiting though, you might check out this for some guidelines that might help.

It's great that they're careful. But they're also not doing any of the work: It's up to me, myself, to test my application against their new releases, against new platforms, in whichever combinations my customers are likely to encounter. It has to be that way with the model they've implemented, as they don't have my code.

Can every development organization in the world, from small-fry shareware guy, through a successful ISV, to a large Fortune 100 company with substantial in-house IT staff, afford to do that testing for each release of .NET? For each new hardware platform which might trigger a different in-field compilation?

If it can be mathematically proven that x(a) == y(a) for all instances of a?

I can't understand how seeing the implementation compiler as a part of the framework is consequential. I'm talking about runtime behaviour of executables, not the tools.

Apologies then. I was specifically referring to a comment where you seemed to indicate that the languages were separate from the framework. I guess I misunderstood your intention.

Just to give a little more context about the app in question, it’s main limitations were in the speed of the algorithm and its use of available memory (for both C# and C++). So the comparison is mostly applicable to the performance of control flow statements, math operators, and the use of basic data structures such as trees, hash tables, bit arrays, ... etc.

So, very much different than the situation you have.

You might give this a read if you have time though:
http://msdn.microsoft.com/library/en-us/dnpag/html/scalenet.asp

It might give you some ideas on how to avoid\resolve some perf issues. If you do have specific issues that don’t seem to be known limitations though, feel free to email me. Though I don’t deal with the internals of the framework, I could likely get your concerns to someone that was familiar with the area.

 

[mikeblas]

In this case, I believe your trading speedy responsiveness for easier to manage source code.

It's hard for me to agree with this. C# doesn't let you split classes across files. Some more substantial things are missing, like type-safe collection classes. These things will get better over time. (I'm told a "partial" keyword will be added the next version of C#, and that will let a developer split a class aross files. And that "specializers" will give us template-like features and therefore type-safe collections.)

But for now, I'm not any more productive in C# than I am in C++. One of several reasons is that my C# code needs to use the .NET framework, and I have to spend lots of time fixing up performance issues that, had I been using C++, were directly under my control.

 

[HJB417]

If C# doesn't suite your needs, try c++.net.
c++ has the stl and c++.net provides you with the gcroot template, I wonder if you can mix the two together... store gcroots in a vector and stuff. templates are compiletime only but in .net 2.0, there will be generics which do runtime enforcement and there's a stl version for .net objects... stl.net

I think you should really take a look at managed c++, now know as cli c++ and how interop is performed with mixed mode dlls.

Now, I'm lost about the split files. does c++ allow this? I always put my declerations in my headers and my implementation in my source files. Do you mean having multiple cpp files implement functions defined in a single header? I doubt the c++.net compiler will do this but it's worth a try.

 

[mikeblas]

If C# doesn't suite your needs, try c++.net.

Microsoft barely supports MC++. There's presently no WinForms designer for it, for example.

but in .net 2.0, there will be generics which do runtime enforcement

Yeah. Whether you want it, or not! Why spend the overhead to check types on every modification of a collection for the situations where it could be done adequately at compile time?

does c++ allow this? [...] Do you mean having multiple cpp files implement functions defined in a single header?

Of course, C and C++ allow it. Yes; having a 180,000 byte, 4200-line C# file isn't exactly conducive to easy source management.

 

[HJB417]

Microsoft barely supports MC++. There's presently no WinForms designer for it, for example.

this was added in VS7.1 (vs.net 2003)

Yeah. Whether you want it, or not! Why spend the overhead to check types on every modification of a collection for the situations where it could be done adequately at compile time?

runtime checks because of reflection. a good read --> http://www.artima.com/intv/generics.html

Of course, C and C++ allow it. Yes; having a 180,000 byte, 4200-line C# file isn't exactly conducive to easy source management.

I can do this in c++.net too, and it compiled

MyBase.h

#using <mscorlib.dll>

using namespace System;

__gc class MyBase
{
public:
	MyBase();
	~MyBase();
};

MyBase1.cpp

#include "stdafx.h"
#include "MyBase.h"

#using <mscorlib.dll>

using namespace System;

MyBase::MyBase()
{
	Console::WriteLine("HELO");
}

MyBase2.cpp

#include "stdafx.h"
#include "MyBase.h"

#using <mscorlib.dll>

using namespace System;

MyBase::~MyBase()
{
	Console::WriteLine("GOOD BYE!");
}

 

[mikeblas]

this was added in VS7.1 (vs.net 2003)

That's great news. About three years too late for me, though.

runtime checks because of reflection.

Perfect! A feature I always have to pay for even though I don't use it or want it most of the time (reflection) is causing other inhibiting design decisions (less than necessary runtime checks). The slippery slope is hurting us.

So in a sense, C++ templates are actually untyped, or loosely typed.

What a curious assertion!

 

[Boypdp]

If you do go the line of C# and all the .NET, I will put in my two cents and suggest looking into ADO .NET at the same time.

 

[popirate]

C'mon Deren, all this time you've been spouting off about how good Microsoft is to its developers, you haven't even learned C#?