![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible <voi### [at] dev null> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
scott <sco### [at] scott com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: scott
Subject: Re: Visual C# .net (and XNA) first impressions
Date: 12 Oct 2009 03:56:58
Message: <4ad2e14a@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
scott <sco### [at] scott com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Captain Jack
Subject: Re: Visual C# .net (and XNA) first impressions
Date: 12 Oct 2009 11:01:15
Message: <4ad344bb@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"scott" <sco### [at] scott com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |