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