anyway, maybe this is really a newbie question. Does C# produced "real" executables? I mean, not an intermediate "custom assembly language" construct that can be seen using ILDASM. What I mean by "real" executables is real x86 binary executable code. Note that I'm a newbie in .NET. I'm very much concerned about "inadvertently" giving out my code if C# doesn't produce a real x86 binary code, since I've been playing with ILDASM and Visual Basic .NET last year and I'm not impressed since ILDASM can reveal the overall structure of the code (along with it's classes, etc.). Eventhough we can use an obfuscator to "protect" the code it doesn't help that much. I've tried it and I can assure you :)

Quote:Original post by Pinczakko
anyway, maybe this is really a newbie question. Does C# produced "real" executables?

ngen.exe can be used to generate native images. It comes with the framework (Windows\Microsoft.NET\version-goes-here\ngen.exe)

Quote:Original post by Coder
ngen.exe can be used to generate native images. It comes with the framework (Windows\Microsoft.NET\version-goes-here\ngen.exe)

haven't known that yet, still newbie ;). A very valuable information. Thank you very much Coder :)

I may be a little late to join this conversation, but here I go anyway.

I used to use C++ and now I am a pure C# enthusiast.

We all know about the hit to C# performance over C++. It is obvious it will never be as fast due to it's nature. The question is at what point does that hit become trivial compared to the overall speed of the systems. personally, I think we are past that.

Every once in awhile you get into situations where the GC gives you a little slow down, it's true. However, there _IS_ an unsafe mode for C#. You can write unmanaged code with it if you must. Also, it might be 1/2 as many lines for normal code over C++ but when it comes to many APIs, like DirectX, it's easily 1/4th the lines, maybe more. And we NEVER have to play with memory. No new-ing an array then memcpy-ing over values, no deleting, no keeping track of everything. Memory is almost as bad as keeping track of shared items in a multithreaded environment. The speed you gain when writing source in C# in DirectX is almost unbelievable. I believe as it settles (it keeps changing a lot right now which is really annoying), many businesses are going to realize that.

The Xbox 360 has 4 processing cores, the PS3 has what? 7? PCs will follow in time. I think we can spare a little for a GC and pump out still gorgeous games much faster.

This is programming, there are ALWAYS tradeoffs.

There are too many posts on this thread, that I've not read them all, but after reading about 25% of them, I've seen no mention of a few very important points:

c# is only going to run on Windows (and maybe the xbox) right? If anyone wants to write something portable to run on unix/linux, ps2 or gcube, c# wont be portable will it?

Personally, I'm only writing for the PC at this time, but I'm old school c++ and don't believe in another language to deal with memory management. Especially if you want to build an app that does a lot of database or string manipulation. I’ve found with java that it’s very inefficient at string manipulation. If you are writing server side code, it might run fine with one or two clients connecting and testing it, but put 100 or a thousand clients on it, and you might quickly find that the inefficient memory management kills you. If you want to have control over when a memory buffer is REUSED (in java it often flags an existing area for garbage collections and allocated a new area) and RELEASED (meaning give me back the resources NOW, not when it decided to) then java isn’t a good selection, and I assume neither is c#. If you are writing a single user app, you might never see it, but I’ve seen it a lot in the business world when we get thousands of uses trying to hit a server side app.

I've heard a lot of people comment that c# is easier to read and easier to debug and creates cleaner code. Quite frankly that's a bunch of _rap. Any experienced programmer knows, you either write good code or bad code, and if you're writing bad code in c++ you'll probably write bad code in c#. That’s actually one of my other big pet peeves is that too many companies have gone java or c# because it’s suppose to be easier, but what I’ve really seen is that bad programmers have an easier time hiding their mistakes in languages like c# and java. I’m not saying they’re all bad, so please don’t attack me. I’m just saying a lot of people go to these languages for the wrong reasons. It’s like learning to crawl before you learn to walk. If you’re not good at c++ you might not be good at the others because you need to understand what the system is doing in order to write healthy, stable, reliable and efficient code. A lot of my friends are business developers. They know c, some know c++ and most know java. But none of them know assembly, and I don’t think 5% of them truly understand how the computer deals with memory management (under the covers), I/O, interrupts, etc… Yeah you might be able to code something cool in c# or java, but if you really want to excel and differentiate yourself from another average Joe you need to understand the internals, no matter what language you use. Once you have that though, you’ll find your c++ code is healthier and more stable, and less error prone then you once thought.

If you got this far, I appreciate your interest in what I have to say. I just have one last comment:

Whether you are using java, c#, c, c++ or even perl/php, you need to plan what you are doing. The only reason c# or java seem like less code is that the libraries being used do more wrapping. Microsoft provided MFC, which most of us think is _rap. However, there are a lot of 3rd party libraries for c++ that provide the same efficiencies and are ported across platforms:

http://www.trumphurst.com/cpplibs/cpplibs.phtml


Thanks, and what ever language you choose, just remember to have fun, and enjoy yourself. The best high for a programmer is getting the nasty bug fixed or that really cool new feature to work, so have fun and keep it light.

Quote:Original post by QuadMV
c# is only going to run on Windows (and maybe the xbox) right? If anyone wants to write something portable to run on unix/linux, ps2 or gcube, c# wont be portable will it?

C# can run on other platforms thanks to Mono and dotGNU.

Quote:Personally, I'm only writing for the PC at this time, but I'm old school c++ and don't believe in another language to deal with memory management.

- Well, I believe. Performance measurements have shown that garbage collected languages can perform well enough - and that's more than enough in a lot of cases.

- You can probably write faster and more memory efficient code in assembly, but you don't.

- C# allows unsafe code.

Quote:Especially if you want to build an app that does a lot of database or string manipulation. I’ve found with java that it’s very inefficient at string manipulation. If you are writing server side code, it might run fine with one or two clients connecting and testing it, but put 100 or a thousand clients on it, and you might quickly find that the inefficient memory management kills you.

I'm not a Java programmer (so take this with a grain of salt):
What you describe suggests bad code, not a bad platform. For example, a programmer might not know about StringBuilder's and thus impair his application's performance. I don't think a broad "Java is very inefficient at string manipulation" is correct. I'd think that if it were, Sun would've improved the situation.

Quote:If you want to have control over when a memory buffer is REUSED (in java it often flags an existing area for garbage collections and allocated a new area) and RELEASED (meaning give me back the resources NOW, not when it decided to) then java isn’t a good selection, and I assume neither is c#. If you are writing a single user app, you might never see it, but I’ve seen it a lot in the business world when we get thousands of uses trying to hit a server side app.

- You can control the garbage collector in C# if you want, but if you don't know what you're doing you'll end up slowing your application.

- This does not apply to 'client' applications (i.e. games)

Quote:I've heard a lot of people comment that c# is easier to read and easier to debug and creates cleaner code. Quite frankly that's a bunch of _rap. Any experienced programmer knows, you either write good code or bad code, and if you're writing bad code in c++ you'll probably write bad code in c#.

No. I'm not a C++ wizard or anything, I've been coding in it for a good time (~5 years) and I can say that any experienced programmer knows that good C# code is much easier to read than good C++ code.

C# is simply elegantly designed. It learns from the mistake of its predecessors - it's only natural that it's cleaner. C++ has a lot of hellish syntax and semantics, especially when templates come into play.

Quote:That’s actually one of my other big pet peeves is that too many companies have gone java or c# because it’s suppose to be easier, but what I’ve really seen is that bad programmers have an easier time hiding their mistakes in languages like c# and java.

It's not supposed to be easier, it *is* easier, and the gains are easily measurable.

Quote:I’m just saying a lot of people go to these languages for the wrong reasons.

Agreed.

Quote:It’s like learning to crawl before you learn to walk. If you’re not good at c++ you might not be good at the others because you need to understand what the system is doing in order to write healthy, stable, reliable and efficient code.

C++ is a horrible language for beginners. Horrible. Computer organization and architecture is one thing, and programming concepts are another thing. C++ requires you to teach both. In the programming domain, it has 3 paradigms. It has a lot of unclear syntax. C++ is hard.

Quote:A lot of my friends are business developers. They know c, some know c++ and most know java. But none of them know assembly, and I don’t think 5% of them truly understand how the computer deals with memory management (under the covers), I/O, interrupts, etc… Yeah you might be able to code something cool in c# or java, but if you really want to excel and differentiate yourself from another average Joe you need to understand the internals, no matter what language you use. Once you have that though, you’ll find your c++ code is healthier and more stable, and less error prone then you once thought.

Agreed, but once you have done that, you'll find that your C# code is much healthier, more stable and less error prone than your healthier, more stable and less error prone C++ code.

Quote:However, there are a lot of 3rd party libraries for c++ that provide the same efficiencies and are ported across platforms:

http://www.trumphurst.com/cpplibs/cpplibs.phtml

And unfortunately, they are not consistent. Each library comes with its own set of conventions and constraints, has a different level of documentation, and might even use a different programming paradigm.