Darren New <dne### [at] sanrrcom> wrote:
> The restrictions are why people call them "references" instead of 
> "pointers", just like you call them "pointers" instead of "addresses" 
> because they can only point to one type of object. I.e., you can have an 
> integer and a float at the same address, but you can't have one pointer 
> that points to either of those.

  Actually you can:

    union IntegerOrFloat
    {
        int i;
        float f;
    };

    IntegerOrFloat* ptr = whatever;

;)

> >>  The language doesn't allow class prototypes, and claims this is 
> >> a benefit because "header files aren't necessary."
> > 
> >   This sounds like a hindrance to modularity. I assume that you can't
> > have types, functions and variables which are local to a compilation unit
> > and are completely invisible to the outside?

> Sure you can. C# has the same public/private/protected/<mumble> that C++ 
> has. With the added advantage that private variables really are private.

  The point was not whether it has public and private sections, but
whether you can implement something the class uses somewhere else than
in the class declaration, completely invisible to the rest of the program.

> >   This removes clutter from the AClass definition.

> In C#, you don't have to do anything like that. You declare AClass as 
> public, AClass::Inner as private, and you're done. You don't have to 
> pick different files to put them in to enforce who gets to see them.

  That was not my point. My point was that it's nice that I can put some
implementations in a separate file, which reduces the clutter of the
class declaration.

  In some cases I have even implemented one class in two files because
the implementation was so massive (even though the public interface of
the class was rather small). This helps keeping source code files smaller
and more manageable.

-- 
                                                          - Warp

Post a reply to this message