I wanted to look into this C# and XNA malarkey so downloaded the free 
express edition of C# and XNA from MS.  Yes I know this should go in a blog 
but I don't have one and don't plan to write much like this.

Firstly, the code auto-complete and general "text editor" part of the IDE is 
amazing, a big step forward from the C++ Express edition I had been using. 
The auto-complete list remembers multiple things at multiple levels that you 
have typed before and jumps to them first as you type, this saves *a lot* of 
time when you have lots of "using" statements (ie the auto-complete list is 
quite long).  Also it seems to dynamically compile (or at least parse 
somehow) your code in realtime, if you mis-spell a variable or use one 
without initialising it, it gets underlined in red the same spelling 
mistakes do in Word.  You can then either hover over the error or look in 
the error list window to see what's up *very useful*.  Warning are 
underlined in green, things like unused variables.

There is some basic code refactoring built in which is pretty handy.  You 
can select some lines of code and tell it to pull it out in its own 
function, parameters and return values will be handled automatically.  You 
can do the same by just typing in a call to a non-existant function (which 
will get underlined in red), then clicking to tell it to make the definition 
for that function.  Also if you rename one occurrence of a variable 
manually, it will get the little "option box" next to it that lets you 
rename all other occurrences of it automatically - nice.

About the actual language of C#, I've never used any really expert features 
of C++ so can only give a basic comparison, but essentially C# is *way* 
easier to program and much less prone to mistakes.  Maybe part of the reason 
why is that you can instantly see if you've made a mistake.  For example I 
didn't know the syntax for declaring an array, yet after a few seconds of 
trial and error I got something that worked based on what I knew about 
C++.net (would have taken longer to open up help and search for array). 
Also no need for any pointers or *'s and &'s dotted about, all handled for 
you.  If you want to pass a variable by reference to a function then just 
write "ref" before it, very simple.

Also if you are using multiple source files this is very much simplified in 
C#.  In C++ you need to mess about with #includes and hacks to stop files 
being included more than once when referenced from multiple source files - 
not with C#, no need for any include statement, if it's in the project you 
have access to it.  There is also no concept of "order" when files are 
included, every file has visibility of every other source file, so you don't 
get circular reference problems.  The same applies within files, so you can 
write:

struct Line { Point n1 , Point n2 }
struct Point { int x , int y }

And this is fine.

One little niggle I had to start with was that when you define a class, you 
need to write the code for all the methods of that class in the definition 
too (in C++ I would usually put the actual method code in a separate file). 
Actually after a few days of coding it doesn't really bother me now, I got 
into the habit of "collapsing" the code in the IDE using the +/- icon so 
that there is just a list of methods.  If you want to view or edit the code 
for a certain method you can just expand it temporarily.  I'm even 
contemplating that this is actually a better way to manage classes than 
always having two separate files for each class that must be kept in sync 
(eg to add an extra parameter to a function you always have to change it in 
both files).

I've just started to dig the surface of XNA, but it seems to me to be 
basically DirectX.net, which is not a bad thing.  I got a simple 2D and then 
3D program up and running in very little time, I'd say maybe 4 or 5 times 
quicker than I ever managed with C++ and DirectX.  XNA programs can also be 
built to run on the xbox - it almost makes me want to get one just so I can 
play some game I wrote on a console!  There's a whole host of cool build 
tools, like automatically converting images, fonts and mesh data into 
optimal formats at compile time - this is genius.

Post a reply to this message

scott wrote:

> I've just started to dig the surface of XNA, but it seems to me to be 
> basically DirectX.net, which is not a bad thing.  I got a simple 2D and 
> then 3D program up and running in very little time, I'd say maybe 4 or 5 
> times quicker than I ever managed with C++ and DirectX.

I'm just impressed that somebody could write a program with C++ and 
DirectX and 1. have it actually work and 2. have it to something nontrivial.

I'm sure you remember my first C++ program. That was a trivial console 
application, and it *still* took miles of code. And it didn't even make 
any low-level system calls such as DirectX...

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> I'm just impressed that somebody could write a program with C++ and 
> DirectX and 1. have it actually work and 2. have it to something nontrivial.

  I'm not surprised you are impressed by such things.

> I'm sure you remember my first C++ program. That was a trivial console 
> application, and it *still* took miles of code. And it didn't even make 
> any low-level system calls such as DirectX...

  You simply refuse to actually learn how to program properly in C++ even
if some people try to teach you. I believe you do that on purpose (because
if you actually learned to program efficiently in C++, you would have to
redact some of your stances and opinions about the language). It's not that
you can't understand C++, it's that you won't.

-- 
                                                          - Warp

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> One little niggle I had to start with was that when you define a class, you 
> need to write the code for all the methods of that class in the definition 
> too (in C++ I would usually put the actual method code in a separate file). 
> Actually after a few days of coding it doesn't really bother me now, I got 
> into the habit of "collapsing" the code in the IDE using the +/- icon so 
> that there is just a list of methods.  If you want to view or edit the code 
> for a certain method you can just expand it temporarily.  I'm even 
> contemplating that this is actually a better way to manage classes than 
> always having two separate files for each class that must be kept in sync 
> (eg to add an extra parameter to a function you always have to change it in 
> both files).

  You can do pretty much the same thing in C++, by implementing the methods
in the class declaration. Of course this is recommended only for small
classes. With large classes you'll end up with a megaclass which will be
hard to understand and maintain, so it will cause more trouble than it's
worth.

  While not very common, sometimes classes become quite large, not necessarily
in the amount of public member functions and private member variables, but
in the sheer amount of code required to implement the class. It becomes even
larger if the class has inner classes and other such types. These inner
classes have to be implemented somewhere as well, naturally.

  Sometimes it's useful to be able to separate the implementation of such a
big class into two or even more files. I have done that in practice with
some such classes. This can happen when the class is more like a big module
(which has to be instantiated, perhaps several times, so a simple namespace
won't do) which has quite a large amount of functionality inside (even if
its public interface is relatively small).

  For example in one work project I had such a class-module. Internally the
functionality of the class could be divided into separate, more or less
independent parts. Thus it was only logical and natural to implement those
parts in separate files (thus I had one header file and several source files),
which kept the individual source files under manageable sizes. Also inner
classes could be implemented in their own separate files, which helped in
lessening the amount of clutter in the "main" source file for the class.

  At the university here they had the rule of thumb that 1000 lines of code
is a good upper limit for a single source file (of course this is a very
soft limit). I have tried to obey that rule of thumb, and I have found it
a rather sound advice. If source files grow significantly larger than that
(eg. 2000 lines or more), they become quite hard to manage.

-- 
                                                          - Warp

Post a reply to this message

scott wrote:
> There is some basic code refactoring built in which is pretty handy.  

The only problem with code refactoring is that it really does have to 
recompile the code, which means it can't refactor code that doesn't compile. 
If you have a half-finished function you're typing in, and you realize you 
want to convert something in the middle of an earlier function into a 
stand-alone method, you have to clean up what you're working on enough to do 
that.

Unless they've fixed that since last I looked.


-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

Warp wrote:
>   Sometimes it's useful to be able to separate the implementation of such a
> big class into two or even more files.

Be aware C# can do this. It's what they mean by "partial classes". I'm 
pretty sure it was originally intended to separate boiler-plate generated 
code from real code you write yourself, but it works for big classes too.

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

> The only problem with code refactoring is that it really does have to 
> recompile the code, which means it can't refactor code that doesn't 
> compile. If you have a half-finished function you're typing in, and you 
> realize you want to convert something in the middle of an earlier function 
> into a stand-alone method, you have to clean up what you're working on 
> enough to do that.
>
> Unless they've fixed that since last I looked.

They seem to have fixed that, I tried what you said and it worked fine.

Post a reply to this message

>  You can do pretty much the same thing in C++, by implementing the methods
> in the class declaration. Of course this is recommended only for small
> classes. With large classes you'll end up with a megaclass which will be
> hard to understand and maintain, so it will cause more trouble than it's
> worth.

Yes, this had always been my mentality with C++ too, in fact it was very 
rare I would put any actual code in the class declaration file.  With C# 
though it kind of forces you to do this (I don't know whether it's possible 
not to), which at first I thought was terrible, but once I got used to 
"collapsing" the code with the little +/- icons in the margin, I think it 
works really well.  You can have multiple levels of the collapse tree and 
define your own collapse regions in the code if you want (so if you had 
several methods implemented all relating to one part, you could collapse all 
these together).  The result is that the source file *looks* like simply the 
class declaration, but when you need to you can expand any part to see the 
actual code.

If I went back to using C++ for something, I might be tempted to do this 
too.  I wonder if the Visual C++ Express edition IDE is the same as the C# 
one?  Maybe I just have an old version of the C++ one that doesn't contain 
some of the newer features.

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> which at first I thought was terrible, but once I got used to 
> "collapsing" the code with the little +/- icons in the margin, I think it 
> works really well.

  I'm not completely convinced by having the need of a specialized source
editor in order to understand the source code better. If you ever need to
develop the source in some environment where you don't have that editor
with those fancy features, you are going to find yourself wading through
thousands and thousands of lines of code.

  Things like code block collapsing and code coloring are definitely
helpful, but IMO good-quality code shouldn't rely on those editing features
in order to keep itself understandable and maintainable. You never know
when you will have the need to understand the code in an environment
which lacks those features.

-- 
                                                          - Warp

Post a reply to this message

"scott" <sco### [at] scottcom> wrote in message 
news:4acf4330$1@news.povray.org...
> [...]
> One little niggle I had to start with was that when you define a class, 
> you need to write the code for all the methods of that class in the 
> definition too (in C++ I would usually put the actual method code in a 
> separate file). [...]

In the .NET environment, you could do it that way by writing an interface, 
then implementing the interface in a class definition. I wouldn't recommend 
doing that just to make C# behave like C++, though. C# is great at what it 
does, and C++ is great at what it does, but they're really two different 
languages. C# is a front end for the .NET CLR, and is made so that C and C++ 
programmers have a familiar way in to that environment. C++ is for 
programming down to the bare metal, and hopefully always will be.

I use .NET languages when I need to quickly make input modules. You still 
can't beat C++ for performance, though. :)

Post a reply to this message