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

>  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.

Yes that's a good argument for not always using those features in general, 
but for me personally I don't think my C#.net/XNA code will ever be opened 
in anything other than the MS IDE :-)

Post a reply to this message

Warp wrote:
>   I'm not completely convinced by having the need of a specialized source
> editor in order to understand the source code better. 

You are perfectly welcome to write a second bit of source code and maintain 
it in sync with the main file when using C# also. ;-)

> 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.

It's really not a problem. I actually find it easier to find things in C# 
than in C++, exactly because I know where to look. If I want to see how 
alpha::beta is implemented, I know where to find it and I know what search 
string to put in. In C++, I'm lucky if I can figure out what header file 
it's in, let alone where in the class heirarchies it is.

That's one thing I'm finding about trying to figure out this huge 
undocumented code base I'm working with - it's almost impossible to actually 
track down where the f'ing code *is*. There's way too many things like

typedef enum {
   ... 300 lines of enums ...
} TYaddaBlow;

OK, now go grep thru half a million lines of code looking for that 
declaration to figure out what the possible values for the enum are. Don't 
forget that the same name is defined in three different layers of the 
architecture, so even when you find it, you need to read the 2000-character 
gcc line to try to figure out which .h file containing the declaration gets 
included first, so you know which enum definition that particular source 
file is using.  </rant>

>   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.

Then you generate the header docs from the source code and you're good to 
go. There's no reason to make maintaining two files a manual process. On the 
other hand, if you *want* to do so, you certainly can.

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

Post a reply to this message

scott wrote:
>> 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.

Kewl. I remember reading someone's paper about how they figured out (for 
example) which brace you had intended to close in something with the wrong 
number of closing braces. It was a novel approach to incremental parsing.

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

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Then you generate the header docs from the source code and you're good to 
> go.

  Not everything in a source file is supposed to be part of the public
interface.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Then you generate the header docs from the source code and you're good to 
>> go.
> 
>   Not everything in a source file is supposed to be part of the public
> interface.

Ah, but it *is*, in C++.[1]  In C#, you can tell it to leave the private 
functions out of the generated documentation altogether. :)


[1] Which, incidentally, I find highly annoying when it's time to add a 
helper function to a class to split up a big file, and I have to go declare 
this completely private class in a different file *and* recompile everything 
that uses the class, even tho I've just said "nobody outside the class is 
allowed to use this anyway."  But that's a minor annoyance, just part of the 
job, compared to the *CRAP* I'm dealing with lately in this code base. :-)

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

Post a reply to this message

On Mon, 12 Oct 2009 18:50:12 +0200, Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
>>    Not everything in a source file is supposed to be part of the
>> public interface.
>
> Ah, but it *is*, in C++.[1]

No.


> In C#, you can tell it to leave the private functions out of the
> generated documentation altogether.

There is no reason why a C++-capable version of "it" could not do the same.



-- 
FE

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> > Darren New <dne### [at] sanrrcom> wrote:
> >> Then you generate the header docs from the source code and you're good to 
> >> go.
> > 
> >   Not everything in a source file is supposed to be part of the public
> > interface.

> Ah, but it *is*, in C++.[1]

  What do you mean? Ever heard of the nameless namespace? Everything in
a nameless namespace is local to that source file and definitely not part
of the public interface of that module. (In fact, there's no way of
accessing anything inside a nameless namespace from another source file.)

  Also an inner class doesn't have to be declared in the public interface
(only its name has to be pre-declared, but that's not very helpful from
the outside).

  (In fact, even an inner class in the *public* interface of a class
doesn't have to be declared. It will work as a completely opaque type
from the outside in that case. I think this is an even more important
case where you *don't* want that inner class to become public, except
as an incomplete type, ie. "in type name only".)

>  In C#, you can tell it to leave the private 
> functions out of the generated documentation altogether. :)

  Btw, I really don't see a lot of difference between fancy source editor
features and a public interface generator. In both cases you need some fancy
external program to help you clarify the source code.

-- 
                                                          - Warp

Post a reply to this message

Fredrik Eriksson wrote:
> On Mon, 12 Oct 2009 18:50:12 +0200, Darren New <dne### [at] sanrrcom> wrote:
>> Warp wrote:
>>>    Not everything in a source file is supposed to be part of the
>>> public interface.
>>
>> Ah, but it *is*, in C++.[1]
> 
> No.

OK, I'll grant you that you were talking about the bodies of the functions 
also. My bad. :-)

>> In C#, you can tell it to leave the private functions out of the
>> generated documentation altogether.
> 
> There is no reason why a C++-capable version of "it" could not do the same.

Sure. But people are discussing .h files, where there's no such option in 
C++. In C, you could make the function static, but that's not the same thing 
for a C++ method.  Obviously you could write a tool that works almost as 
well for sufficiently well-organized C++ code as works for C#, but then 
you'd be complaining you might not have that tool elsewhere. :-)

-- 
   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:
>   What do you mean? Ever heard of the nameless namespace? Everything in
> a nameless namespace is local to that source file and definitely not part
> of the public interface of that module. (In fact, there's no way of
> accessing anything inside a nameless namespace from another source file.)

You can't make a private method on a class without exposing that in the 
header, can you?  (If so, I've been doing it wrong. :-)

>   Also an inner class doesn't have to be declared in the public interface
> (only its name has to be pre-declared, but that's not very helpful from
> the outside).

You're still exposing its existance in the header file, meaning you get to 
recompile stuff, for example. 0

>   Btw, I really don't see a lot of difference between fancy source editor
> features and a public interface generator. In both cases you need some fancy
> external program to help you clarify the source code.

You don't need such a tool in C# any more than you need a tool to generate 
the .h files for you in C++.

However, since C# makes the "makefile" structure part of the language, it's 
possible to write tools that extract equivalent documentation from C# that 
you can't as easily write in a portable way for C++.  I.e., even if you have 
a complete C++ parser, now you need a whole lot of extra stuff to understand 
*which* header files go with *which* source files when you're trying to 
parse C++.

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

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> >   What do you mean? Ever heard of the nameless namespace? Everything in
> > a nameless namespace is local to that source file and definitely not part
> > of the public interface of that module. (In fact, there's no way of
> > accessing anything inside a nameless namespace from another source file.)

> You can't make a private method on a class without exposing that in the 
> header, can you?  (If so, I've been doing it wrong. :-)

  That's your argument for dismissing all the private types, functions and
data that can be specified in a source file (and which don't belong to the
header file)?

> >   Also an inner class doesn't have to be declared in the public interface
> > (only its name has to be pre-declared, but that's not very helpful from
> > the outside).

> You're still exposing its existance in the header file, meaning you get to 
> recompile stuff, for example. 0

  I don't understand that sentence.

> However, since C# makes the "makefile" structure part of the language, it's 
> possible to write tools that extract equivalent documentation from C# that 
> you can't as easily write in a portable way for C++.  I.e., even if you have 
> a complete C++ parser, now you need a whole lot of extra stuff to understand 
> *which* header files go with *which* source files when you're trying to 
> parse C++.

  I'm not completely following what you are saying.

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Sure. But people are discussing .h files, where there's no such option in 
> C++. In C, you could make the function static, but that's not the same thing 
> for a C++ method.

  How would you suggest having support for implementing private functions for
a class without having to declare them in the class declaration *and* without
opening the private parts of the class to any external code that wishes to
access it?

  Assume you could do this in C++:

//-----------------------------------------------
// HeaderFile.hh
class MyClass
{
 public:
    void some_public_function();

 private:
    some_private_data;
};
//-----------------------------------------------

//-----------------------------------------------
// HeaderFile.cc
#include "HeaderFile.hh"

void MyClass::some_public_function() { ... }

// Add a new private function to MyClass:
void MyClass::a_private_function()
{
    // Access some_private_data here
}
//-----------------------------------------------

  Hey, that's great. I can add new private functions to MyClass without
having to modify the declaration of the class nor the header file. Cool.

  Except for one problem:

//-----------------------------------------------
// SomeOtherFile.cc
#include "HeaderFile.hh"

void MyClass::bypass_privacy()
{
    // Access some_private_data here
}
//-----------------------------------------------

  Now you have opened your entire class for anyone to access from anywhere
without restriction, making your public/private distinction completely
meaningless.

  (You might find that ok, but most OO programmers don't, including most of
the people who know about these things.)

  The solution to this is to specify the private functions in the class
declaration.

  If you don't care about privacy, then put everything in the public section
of the class and write all the formerly private functions in a nameless
namespace inside the source file. That way you don't have to add anything
to the header file if you want to add a new private function.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   That's your argument for dismissing all the private types, functions and
> data that can be specified in a source file (and which don't belong to the
> header file)?

Maybe that's just the crap I've run into myself. :-)

>> However, since C# makes the "makefile" structure part of the language, it's 
>> possible to write tools that extract equivalent documentation from C# that 
>> you can't as easily write in a portable way for C++.  I.e., even if you have 
>> a complete C++ parser, now you need a whole lot of extra stuff to understand 
>> *which* header files go with *which* source files when you're trying to 
>> parse C++.
> 
>   I'm not completely following what you are saying.

I'm saying that the argument seems to be "C++ header files are better, 
because it's not mixed in with the implementation stuff."  When I point out 
that you can get documentation out of C# that's just like C++ header files, 
people point out you need a tool to do that.

That's an incorrect assertion. You don't need a tool to make that 
documentation any more than you need a tool to make C++ header files. C++ 
header files aren't better because they're C++, but because they're manually 
constructed and maintained. If they aren't manually constructed and 
maintained, then you need a tool to do that just like you do for C++.

And the tool for C++ will have a harder time of it, *because* there's no 
indication of any compilation units bigger than a .cpp file, and so on. 
I.e. you can't just give a pile of C++ source files to a tool and have it 
understand the code without having it figure out and understand all the 
compiler command lines as well. (This goes for C as well, of course.)

I can give you all the source code I'm working on, and there's no way you 
could ever figure out how to compile it without trying to compile and run it 
against each set of header files to see what works, for example. That's not 
the case with C#, because there's a file in a standard format that serves 
the purpose of a makefile and which the libraries already have tools to deal 
with.



-- 
   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:
> Darren New <dne### [at] sanrrcom> wrote:
>> Sure. But people are discussing .h files, where there's no such option in 
>> C++. In C, you could make the function static, but that's not the same thing 
>> for a C++ method.
> 
>   How would you suggest having support for implementing private functions for
> a class without having to declare them in the class declaration *and* without
> opening the private parts of the class to any external code that wishes to
> access it?

I don't know. C# does it by not having header files.  I'm not saying C++'s 
solution is a bad one per se.  (*I* don't like it as much, but that doesn't 
mean it's *bad* universally.)

I'm merely pointing out that it's hypocritical to claim that it's better to 
*have* to maintain something manually because then you're not dependent on a 
tool to maintain it.

>   The solution to this is to specify the private functions in the class
> declaration.

Or not have class declarations at all.  If you define it private, then it's 
private. You don't need to declare it at all, public or private.

>   If you don't care about privacy, then put everything in the public section
> of the class and write all the formerly private functions in a nameless
> namespace inside the source file.

That doesn't work for instance methods, does it?  An instance method 
actually has to be a member of the class in the class declaration, yes? (I'm 
just double-checking I understand that part.)

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

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> I don't know. C# does it by not having header files.

  Well, nothing stops you from implementing everything *in* the class
declaration in C++. (Well, except if you want to keep some degree of
modularity.)

> I'm merely pointing out that it's hypocritical to claim that it's better to 
> *have* to maintain something manually because then you're not dependent on a 
> tool to maintain it.

  I don't see separate declarations and implementations as such a big problem
as you seem to.

> >   The solution to this is to specify the private functions in the class
> > declaration.

> Or not have class declarations at all.  If you define it private, then it's 
> private. You don't need to declare it at all, public or private.

  How do you stop someone from adding a new private function to your class
from the outside, then?

> >   If you don't care about privacy, then put everything in the public section
> > of the class and write all the formerly private functions in a nameless
> > namespace inside the source file.

> That doesn't work for instance methods, does it?  An instance method 
> actually has to be a member of the class in the class declaration, yes? (I'm 
> just double-checking I understand that part.)

  Well, if everything is public, what do you need private methods for?
Private methods are only for access, but if access is already completely
open, then there's no need for private methods. You can replace them with
local functions (ie. local to the compilation unit, ie. in a nameless
namespace).

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> I don't know. C# does it by not having header files.
> 
>   Well, nothing stops you from implementing everything *in* the class
> declaration in C++. (Well, except if you want to keep some degree of
> modularity.)

Right.

>> I'm merely pointing out that it's hypocritical to claim that it's better to 
>> *have* to maintain something manually because then you're not dependent on a 
>> tool to maintain it.
> 
>   I don't see separate declarations and implementations as such a big problem
> as you seem to.

I don't either. I'm just pointing out that it's silly to say not *having* to 
do that is a *problem.*  I'm not bashing C++. I'm saying it's silly to say 
that C++ is superior in the aspect that it *makes* you manually maintain a 
separate file with the information in it that C# programs can generate 
automatically. At least because you can *also* maintain that information 
manually in C#.

>   How do you stop someone from adding a new private function to your class
> from the outside, then?

Because you have to compile all the parts of the class at the same time in 
C#. If you're *really* worried about it, you sign the result. :-)

>> That doesn't work for instance methods, does it?  An instance method 
>> actually has to be a member of the class in the class declaration, yes? (I'm 
>> just double-checking I understand that part.)
> 
>   Well, if everything is public, what do you need private methods for?

Where did I say everything is public?  I just said that the private methods 
wind up being visible in the public "interface" file in C++.  Again, I was 
just commenting in terms of people complaining there was too much "visible" 
in the C# way of doing things.

> You can replace them with
> local functions (ie. local to the compilation unit, ie. in a nameless
> namespace).

Hmm. But you don't get a "this" pointer, right? You need to start being 
explicit about everything that OO is supposed to make implicit, like 
accessing member variables from inside the function and all?

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

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Where did I say everything is public?  I just said that the private methods 
> wind up being visible in the public "interface" file in C++.  Again, I was 
> just commenting in terms of people complaining there was too much "visible" 
> in the C# way of doing things.

  A header file is not really a "public interface". It's just a source code
file like any other. The "public interface" of a class is what you put
inside the "public" section of the class. Whatever there might be in the
"private" section is there purely for technical reasons, and you shouldn't
concern yourself about it and consider it effectively hidden (at least if
you want to maintain good OOD).

  Yes, a class declaration cannot be split into two or more parts in C++
(for technical reasons), but that doesn't make the private part any more
"public".

  There are other programming languages (such as Objective-C) where you
can split the class declaration into two, putting one part in a header
file and the other in the source file, but that's because the way objects
are implemented allows that (at the cost of speed and memory efficiency).

> > You can replace them with
> > local functions (ie. local to the compilation unit, ie. in a nameless
> > namespace).

> Hmm. But you don't get a "this" pointer, right? You need to start being 
> explicit about everything that OO is supposed to make implicit, like 
> accessing member variables from inside the function and all?

  The 'this' pointer is passed implicitly to member functions by the
compiler. If you decide to make it a local function instead, you'll have
to pass the object pointer explicitly as a function parameter. Otherwise
there isn't too much of a difference, just a small difference in syntax.

  (The real difference between private member functions and local
functions is access scope.)

-- 
                                                          - Warp

Post a reply to this message

Darren New wrote:
> Warp wrote:
>>   What do you mean? Ever heard of the nameless namespace? Everything in
>> a nameless namespace is local to that source file and definitely not part
>> of the public interface of that module. (In fact, there's no way of
>> accessing anything inside a nameless namespace from another source file.)
> 
> You can't make a private method on a class without exposing that in the
> header, can you?  (If so, I've been doing it wrong. :-)

Actually, you can. COM does it. But you end up making all public methods
virtual, and a feature of C++ over C# is that you have the choice not to
make everything virtual :)

Post a reply to this message

Warp wrote:
>   A header file is not really a "public interface". It's just a source code
> file like any other. The "public interface" of a class is what you put
> inside the "public" section of the class. Whatever there might be in the
> "private" section is there purely for technical reasons, and you shouldn't
> concern yourself about it and consider it effectively hidden (at least if
> you want to maintain good OOD).

Right. If you're talking about C# being too "cluttered" in its declarations 
(because they're technically in the class body, all one file sort of thing), 
then the fact that you have to visually skip the private sections of the 
class header I think would have to be accounted for in the "ease of use of 
using a .h file for documentation" arguments.

> but that doesn't make the private part any more "public".

Only if you're looking at the ergonomics of using a .h file as documentation.

>   The 'this' pointer is passed implicitly to member functions by the
> compiler. If you decide to make it a local function instead, you'll have
> to pass the object pointer explicitly as a function parameter. Otherwise
> there isn't too much of a difference, just a small difference in syntax.

Good!  I understood that right. :-)

>   (The real difference between private member functions and local
> functions is access scope.)

Yeah, I guess that's true too. :-)

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

Post a reply to this message

Nicolas Alvarez wrote:
> Actually, you can. COM does it. But you end up making all public methods
> virtual, and a feature of C++ over C# is that you have the choice not to
> make everything virtual :)

Not everything in C# is virtual either, if you don't declare it virtual.

You're thinking of Eiffel or something.

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

Post a reply to this message

Darren New wrote:
> Nicolas Alvarez wrote:
>> Actually, you can. COM does it. But you end up making all public methods
>> virtual, and a feature of C++ over C# is that you have the choice not to
>> make everything virtual :)
> 
> Not everything in C# is virtual either, if you don't declare it virtual.
> 
> You're thinking of Eiffel or something.

Maybe Java.

Post a reply to this message

I forgot to add one thing: executable code size.

I wrote a little app that uses C# and DirectX, just a simple physics-based 
"game" with a few connected bodies controlled by the keyboard and an RK4 
integrator.  The result is drawn on the screen in a window.  The generated 
.exe is 23KB - I couldn't believe it and had to copy it to my other PC to 
check it actually worked.  Nowadays I guess it doesn't matter if your file 
is 23KB or 2.3MB, but still I thought it was cool how small it was.

Post a reply to this message

scott wrote:
> The generated .exe is 23KB - I couldn't believe it and had to copy it to
> my other PC to check it actually worked.

Why wouldn't it work? Because it is a 23KB app but actually depending on a
huge library on your PC where most of the code would be?

Guess what, it is, and the other PC had it as well ;)

Post a reply to this message

>> The generated .exe is 23KB - I couldn't believe it and had to copy it to
>> my other PC to check it actually worked.
>
> Why wouldn't it work?

IME (from Borland and older MS C++ compilers) when a compiler generates a 
GUI-based .exe as small as that something is usually missing that nobody 
without the compiler would have installed.

> Because it is a 23KB app but actually depending on a
> huge library on your PC where most of the code would be?
>
> Guess what, it is, and the other PC had it as well ;)

I'm sure in the "old days" I was generating several MB .exe files to be 
redistributed, now it seems finally they are putting *just* the code you 
wrote in the .exe, and everything else is assumed to be installed already 
(ie the .net runtime).  It makes it much more efficient to distribute, 
especially when there are frequent updates.

Post a reply to this message

scott wrote:
>>> The generated .exe is 23KB - I couldn't believe it and had to copy it to
>>> my other PC to check it actually worked.
>>
>> Why wouldn't it work?
> 
> IME (from Borland and older MS C++ compilers) when a compiler generates a
> GUI-based .exe as small as that something is usually missing that nobody
> without the compiler would have installed.
> 
>> Because it is a 23KB app but actually depending on a
>> huge library on your PC where most of the code would be?
>>
>> Guess what, it is, and the other PC had it as well ;)
> 
> I'm sure in the "old days" I was generating several MB .exe files to be
> redistributed, now it seems finally they are putting *just* the code you
> wrote in the .exe, and everything else is assumed to be installed already
> (ie the .net runtime).  It makes it much more efficient to distribute,
> especially when there are frequent updates.

I don't see the difference. Before, you needed the Borland Runtime. Now you
need .NET.

Post a reply to this message

> I don't see the difference. Before, you needed the Borland Runtime. Now 
> you
> need .NET.

Most people have the .net runtime, whereas most people do not have the 
Borland runtime.

It's like the difference between sending someone an obscure document format 
(and telling them where to get the reader from) or just sending them a PDF. 
Technically you need a reader too for PDF, but almost everyone has it 
already, so it's much more convenient.

Post a reply to this message

>> I don't see the difference. Before, you needed the Borland Runtime. 
>> Now you need .NET.
> 
> Most people have the .net runtime, whereas most people do not have the 
> Borland runtime.
> 
> It's like the difference between sending someone an obscure document 
> format (and telling them where to get the reader from) or just sending 
> them a PDF. Technically you need a reader too for PDF, but almost 
> everyone has it already, so it's much more convenient.

Where does this "everybody has the .NET runtime" myth come from?

My PC didn't have the .NET runtime. (If I hadn't installed VisualStudio, 
it still wouldn't have it.) My brand new Vista laptop still doesn't have 
the .NET runtime. My mum's PC doesn't have the .NET runtime. My 
grandparents' PC doesn't have the .NET runtime. My dad's two Windows PCs 
don't have the .NET runtime. And the 35 PCs at work didn't have the .NET 
runtime either until we rolled out some app which actually needed it. 
(We deployed it via Windows Update Server.)

So who is this "everybody" who already has the .NET runtime then?

Post a reply to this message

> Where does this "everybody has the .NET runtime" myth come from?

The only people who don't have it are those that still have XP, have not 
installed all the Windows Upates, and have never installed a program that 
needed the .net runtime.  It can't be that many compared to the number of 
people without the Borland runtime :-)

> My brand new Vista laptop still doesn't have the .NET runtime.

Did you uninstall it somehow? Vista comes with .net 3.0.

Post a reply to this message

>> Where does this "everybody has the .NET runtime" myth come from?
> 
> The only people who don't have it are those that still have XP, have not 
> installed all the Windows Upates, and have never installed a program 
> that needed the .net runtime.  It can't be that many compared to the 
> number of people without the Borland runtime :-)

I would think the number of people with the .NET runtime *is* far, far 
larger than the Borland runtime. But still, I've yet to come across any 
PCs which have the .NET runtime "already". All the machines at work had 
to have it added, and my PC at home only has it because VS requires it 
for some reason.

I'm also pretty certain that the .NET runtime is *not* automatically 
installed by Windows Update. You can _request_ it from Windows Update, 
but it's listed as "optional software" rather than a required update. 
(Of course, updates to any version of the runtime you've already 
installed get added automatically. But not the runtime itself.)

And what do you mean "still have XP"? Last time I checked, virtually 
*everybody* is "still" using XP. (Except for the tiny few who bought a 
new PC recently.)

>> My brand new Vista laptop still doesn't have the .NET runtime.
> 
> Did you uninstall it somehow? Vista comes with .net 3.0.

I rephrase: The .NET runtime is not listed in add/remove programs. I 
presumed this to mean it isn't installed.

Post a reply to this message

> I'm also pretty certain that the .NET runtime is *not* automatically 
> installed by Windows Update. You can _request_ it from Windows Update, but 
> it's listed as "optional software" rather than a required update. (Of 
> course, updates to any version of the runtime you've already installed get 
> added automatically. But not the runtime itself.)

Oh ok I hadn't checked what category it came under, I just remember seeing 
it on my XP box a long time ago.

> And what do you mean "still have XP"? Last time I checked, virtually 
> *everybody* is "still" using XP. (Except for the tiny few who bought a new 
> PC recently.)

Recently I've seen a lot of people show up with Vista laptops, I guess most 
people get them replaced every few years so it's not surprising.  Anyway I 
kind of meant the original un-updated XP, the service pack updates include 
.net anyway.

BTW, according to Wikipedia 22% use Vista and 68% use XP, and you can guess 
which way both those numbers are heading...

> I rephrase: The .NET runtime is not listed in add/remove programs. I 
> presumed this to mean it isn't installed.

Ah ok, yes it *is* installed, but I assume you cannot uninstall it (because 
presumably some parts of Vista were written to make use of it).

Post a reply to this message

> Anyway I kind of meant the original un-updated XP, the service pack 
> updates include .net anyway.

I'm pretty sure this is incorrect too. The Windows Update server had to 
install SP3, reboot the PC and then install the .NET framework - which 
doesn't like a lot of sense if SP3 *includes* it.

> BTW, according to Wikipedia 22% use Vista and 68% use XP, and you can 
> guess which way both those numbers are heading...

Yes, I expect Vista usage to increase over time. (Or will it? Maybe 
everybody will just move to Windows 7?) My point is *today* few people 
use it.

>> I rephrase: The .NET runtime is not listed in add/remove programs. I 
>> presumed this to mean it isn't installed.
> 
> Ah ok, yes it *is* installed, but I assume you cannot uninstall it 
> (because presumably some parts of Vista were written to make use of it).

Interesting. So it's installed but just not listed? Is there a 
scientific way to confirm this?

I should have realised eventually I would have no choice in the matter...

Post a reply to this message

"Invisible" <voi### [at] devnull> wrote in message 
news:4adc6da2$1@news.povray.org...
>
> Interesting. So it's installed but just not listed? Is there a scientific 
> way to confirm this?
>

Look in Control Panel under Administrative Tools. If you have any of the 
.NET frameworks installed, there should be an icon (or more) for it there. 
IIRC, the only thing you'll see in Add/Remove programs is the service packs, 
if any, that you have installed for the frameworks.

Post a reply to this message

On Mon, 19 Oct 2009 15:46:08 +0200, Invisible <voi### [at] devnull> wrote:
>
> Interesting. So it's installed but just not listed? Is there a  
> scientific way to confirm this?

Check your "Windows\Microsoft.NET\Framework" folder (and "Framework64" if  
applicable). Each installed .NET version has its own subfolder there.

Alternatively, just run Windows Update and see which ones you have not yet  
installed.



-- 
FE

Post a reply to this message

> I'm pretty sure this is incorrect too. The Windows Update server had to 
> install SP3, reboot the PC and then install the .NET framework - which 
> doesn't like a lot of sense if SP3 *includes* it.

Oh ok, I don't remember so I might be wrong, I thought I read that from XP 
SP2 onwards .net was included.  Might the SP install just have deferred the 
installation of .net until after the reboot?

> Yes, I expect Vista usage to increase over time. (Or will it? Maybe 
> everybody will just move to Windows 7?)

I assume Windows 7 will include .net, so the % of machines with .net 
installed should continue to rise.

Post a reply to this message

>> I'm pretty sure this is incorrect too. The Windows Update server had 
>> to install SP3, reboot the PC and then install the .NET framework - 
>> which doesn't like a lot of sense if SP3 *includes* it.
> 
> Oh ok, I don't remember so I might be wrong, I thought I read that from 
> XP SP2 onwards .net was included.  Might the SP install just have 
> deferred the installation of .net until after the reboot?

Nope. I sometimes have to do this manually if WUS doesn't work for some 
reason, and just installing SP3 is insufficient. No amount of rebooting 
helps. You have to also manually install the .NET framework, which is a 
seperate [240 MB] download.

>> Yes, I expect Vista usage to increase over time. (Or will it? Maybe 
>> everybody will just move to Windows 7?)
> 
> I assume Windows 7 will include .net, so the % of machines with .net 
> installed should continue to rise.

Oh, sure. I meant will Windows Vista continue to increase once Windows 7 
is out. ;-)

Post a reply to this message

> Oh, sure. I meant will Windows Vista continue to increase once Windows 7 
> is out. ;-)

Probably, for a while.  Especially in large companies there is always a big 
delay between a new OS being released and that OS starting to be used.  From 
my experience a lot of places are starting to roll out Vista on new 
machines, I suspect that trend will continue for at least another year or so 
until they have tested Windows 7 sufficiently.

Post a reply to this message

scott wrote:
>> Oh, sure. I meant will Windows Vista continue to increase once Windows 
>> 7 is out. ;-)
> 
> Probably, for a while.  Especially in large companies there is always a 
> big delay between a new OS being released and that OS starting to be 
> used.  From my experience a lot of places are starting to roll out Vista 
> on new machines, I suspect that trend will continue for at least another 
> year or so until they have tested Windows 7 sufficiently.

Certainly the company I work for has vowed to not even touch Vista. They 
were going to wait 3 years, but not I think they're looking at going 
straight to Windows 7.

Weird really. As soon as a new server OS comes out, they can't install 
it fast enough. But desktop OS, they tend to wait until it's a few years 
old before even testing it.

Post a reply to this message