Howdy,

Why is it OK to create a function in XNA C# without declaring it? (Sorry for the question)

Thanks..

I'd ask that question the other way around:

Why does C require you to duplicate information about every function in header files as well as in your main .cpp sources? (this is both laborious to do, plus error prone if you get the information slightly different in the two places)

The answer is that in the 1970's, computers were very slow. Compilers didn't have the horsepower to examine all your soure code at the same time, so they relied on the programmer to manually break it up into pieces, and give the compiler just enough information about each piece that it would be able to compile them separately, then link the results together in a second step.

C# is designed for modern computers, which are quite a bit faster than the ones C was built for. These days it is entirely feasible for the compiler to examine an entire program in one piece, so there is no need for the programmer to manually duplicate information from one place to another.

1. So it's not XNA that 'allows' me to have non-declared functions, it's C#?

 

2. What about C++? What are the pros and cons of C++ vs. C#? ( I ask this because I do C++ as well)

blargmob:

1. So it's not XNA that 'allows' me to have non-declared functions, it's C#?

2. What about C++? What are the pros and cons of C++ vs. C#? ( I ask this because I do C++ as well)

1: XNA is just a framework. C# is the language, and the syntax of C# is the same no matter what framework(s) you might be using.

2: That's holy war territory for sure. Google will turn up many articles, for instance this one is at the top of the search results: http://blogs.msdn.com/ericgu/archive/2005/01/26/360879.aspx

Great Thanks!

I'm ok with holy wars....so I'll briefly answer.

C++ has the pro of giving you access to do whatever you want.
C++ has the con of giving you access to do whatever you want.

By whatever you want I mean do stuff with pointers, delete stuff whenever you feel like it. It is very powerful to choose to do exactly what you want, when you want.

Technically you can do these things in C# in unsafe mode, but for this topic we'll not pretend there are no pointers in C#.

The lack of pointers to some is considered a bad thing, because they believe it removes the power to do what you want. Only if what you want is to manipulate things unsafely. By making everything 'safe' and preventing pointers from being deleted that may point to something still in use somewhere else, it makes the program much easier to create without creating pointer related bugs.

This is just one aspect of the languages. Although some of the things I love about C# are really in the IDE, not just the language.

• The fact it brings up what it thinks you want to type is completely awesome and lets me code faster.
• Also the intellisense 99% of the time works, where in C++ occassionally it won't pop up at all. 
• It is easy to summarize anything which will then appear in the intellisense it great. Regions are great for organization. 
• The override, abstract, and sealed keywords are nice. There are probably many more, but those are my favorite ones that C++ is missing.
• The fact I do not have to prototype functions is great.
• The order in which I declare things doesn't matter anymore.
• Everything in classes make things more Object oriented which I'm all about as well.

Alright, that is enough for now. I don't expect a holy war out of this, but if it must be fought.....

Wow, this is likely to start a 10-page thread.  Guess I better go sharpen my sword, clean my body armor, and prepare for the next crusade... :)


In all seriousness, not having to declare function prototypes is just a part of the C# language, nothing more.  I don't feel that its for better or for worse (C/C++ prototypes have their purposes), its just different.


Comparing C++ to C# is like comparing apples to oranges in many ways.  Both have different strengths and weaknesses, and the choice as to which is "better" is a combination of programmer preference and project details.  It's impossible to make blanket statements like "C++ is better because X" or "C# is better because Y."

Though just remember you're on a .NET board... so you'll probably get a lot of "C# pwns C++!1!!111" comments, with very little in the way of (true) supporting facts, mainly because you *cannot* make blanket statements about languages without precise context.  :)

ShawMishrak:

In all seriousness, not having to declare function prototypes is just a part of the C# language, nothing more.  I don't feel that its for better or for worse (C/C++ prototypes have their purposes), its just different.

Comparing C++ to C# is like comparing apples to oranges in many ways.  Both have different strengths and weaknesses, and the choice as to which is "better" is a combination of programmer preference and project details.  It's impossible to make blanket statements like "C++ is better because X" or "C# is better because Y."

I agree with your second paragraph completely... all languages have their own pros and cons.  But as for your first paragraph, I think that the need for function prototypes in C++ falls almost completely in the con category.  Its only pro is that it provides backwards compatibility with C, which was one of the languages major design goals (and one of the main reasons it has been as successful as it is).

If it weren't for the separation of specification and implementation into header and body files in C/C++, I wouldn't have to fix problems like this one!

Tom

I wouldn't completely agree with that. Having a separate function declaration to definition allows you to, for example, provide people with just the header and the lib, and they can use your code without the slightest knowledge of how it works - data hiding in the truest sense!

However, I'd agree that that's more or less coincidental, and in general the extra encapsulation that offers is more than outweighed by the fact that you have to type the same thing the same way in two different files (or even three, depending on the idioms you're using).

I still think C++ has it's uses - not least of which is the millions (billions?) of lines of existing code that already use it, and the fact that the overwhelming majority of games companies require you to be fluent in it - but having written C++ for getting on for 15 years now, I exclusively use C# when writing stuff for my own enjoyment and interest, and that be quite suggestive.

(That said, it's possible I'd like other languages if I tried them - I'd very much like to give Ruby and Haskell a look, for example. But a nice feature of C# is that the learning curve from C++ is practically flat, there's almost zero effort to switch from one to the other, and given that, I don't feel inclined to spend a lot of time learning something completely different).

Andy Patrick:

I still think C++ has it's uses - not least of which is the millions (billions?) of lines of existing code that already use it, and the fact that the overwhelming majority of games companies require you to be fluent in it - but having written C++ for getting on for 15 years now, I exclusively use C# when writing stuff for my own enjoyment and interest, and that be quite suggestive.

Yep, I agree.  And it's not just game companies that generally look for programmers fluent in C++, right now it's the closest thing to a de facto standard programming language across most industries.

I've been programming in C++ for over 10 years and, for the most part, I like it a lot.  But it does have a lot of gotchas, particularly for inexperienced programmers, that can be very frustrating.  And, like you, for my "fun" programming I use either C# or Java.

I and a couple other senior programmers at my company have talked a little about possibly using C# in our products.  Northrop Grumman is already using C# in an embedded product similar to ours.  The biggest problem is that it ties us to Microsoft-supported platforms, which is a hard sell in the embedded world, especially with the military.  But our last couple of projects have targed Xscale boards running Windows CE.  They would have been perfect guinea pigs for using C# and the .NET CF.  The only reason we stuck with C++ was to leverage the thousands of lines of C++ code we already had.

I'm going to keep looking for an opportunity to use C# in our products.  I am certain we can be more productive with it.  The only questions are whether that productivity can outweigh the loss of our existing code base and the loss of flexibility in hardware platforms.

Tom

 

SwampThingTom:

The biggest problem is that it ties us to Microsoft-supported platforms, which is a hard sell in the embedded world, especially with the military.

Is there no way to compile Mono for embedded devices that use Linux? Or are they using completely proprietary OSes?

Ctek has a nice-looking Linux-based product with their Axis System-on-a-Chip solution.  We're evaluating that now and the guy doing it is interested in seeing if he can get Mono running on it.

The embedded world used to be strictly proprietary OSes, with VxWorks being the closest thing to a "standard" that existed, but it has really opened up in the past couple of years.

Tom

Andy Patrick:

I wouldn't completely agree with that. Having a separate function declaration to definition allows you to, for example, provide people with just the header and the lib, and they can use your code without the slightest knowledge of how it works - data hiding in the truest sense!

I'm afraid I cannot agree with that, for two reasons:

A header file does not (or at least not usually) contain only the public interface. Especially for C++ code, you must resort to some awkward proxy object design patterns if you want to avoid including class implementation details in your public header. The vast majority of naturally written C++ code leaks a significant amount of supposedly non-public information in the headers, hidden only by using a "private:" keyword.

And more importantly: .NET can do this one better! For a native library, I must give you a header and lib (if you are statically linking), or a header plus lib plus DLL file (if you are dynamically linking). If I give you mismatched files, or you update one but forget to update the other, you get weird errors. But in .NET I can just give you a single assembly which combines the role of header, lib, and DLL. The file you give to the compiler when building your code is the same one that you link into your final program, and ship out to your end users. Dramatically fewer ways to get things wrong, and provides much stronger data hiding because the compiler (and related tools like the object browser and Intellisense engines in Visual Studio) will only show you exactly what things the author of the assembly declared as public.

Andy Patrick:

I still think C++ has it's uses

I absolutely agree. For instance a lot of the underlying implementation of the XNA Framework is in C++. I can't say I enjoy working on those parts as much as when I get to write C#, but there are some tasks that are simply better done in native code. I often console myself by saying I'm taking on the pain of writing native code so people who use our framework won't have to :-)

Andy Patrick:

(That said, it's possible I'd like other languages if I tried them - I'd very much like to give Ruby and Haskell a look, for example.

Learning new languages is fun. Even if you never use them for any serious programming projects, just the act of learning them tends to stretch your brain in interesting new directions that will make you a better programmer overall.

That said, I've been mearning to learn Haskell for years, but never got around to it :-)

I once wrote an XNA sample in Boo.
It was pretty cool actually, and the lack of curly braces and "simpler" syntax made programming XNA in Boo much fun. Too bad the compiler did produce some extremely slow code when it came to array handling, I hope they have fixed this in recent builds. :)

A header file does not (or at least not usually) contain only the public interface.

Not usually, perhaps, but can. It is not at all unusual for SDKs to be provided as libs and headers, and the headers simply contain an interface that, behind the scenes, is then derived from by the classes that do the real work. Take DirectX (at least, the XACT part of it for definite) for an obvious real-world example.

It's a minor point, though, as I'd overwhelmingly agree that it's much nicer to only have to write something once like in C#. Twice as in 'most' C++ is bad enough, but three times (code file + 'real' header + interface header) is a nightmare.

You make a good point about .NET assemblies though - I'm not that familiar with using them yet but thinking about it, you're completely right, they do hide implementation details very nicely.

It's just a shame (if sadly unavoidable) that XNA is MS-platform only. Every time I try to tell my boss "in five years we'll all be writing XNA all the time!" he reminds me "only if Sony and Nintendo get bought by Microsoft", and that seems somewhat unlikely.