Darren New schrieb:
> clipka wrote:
>> Fun fact about structs in C++: They /are/ classes. Only major 
>> difference (IIRC) being that their members default to "public:".
> 
> That much I knew already. But I don't know if C structs are C++ structs 
> for sure. :-)

Well, C structs are fully compatible to C++ structs, aren't they? You 
can link a C++ program against any C library; and you can compile a C 
library with a C++ compiler, and still link it to a C program. So...?

Post a reply to this message

clipka wrote:
> Well, C structs are fully compatible to C++ structs, aren't they?

Aren't they?  That's what I understood the intent to be, but I'm not sure I 
ever looked it up definitively. :-) Good to know.

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

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Classes only start to really diverge from classic C structs when you go 
> for stuff like virtual methods or multiple inheritance. In the former 
> case there'll be a few hidden data members that C++ will automatically 
> add, while in the latter case... heck, I have not the slightest clue :-)

  Firstly, C++ structs are enormously different from C structs in that C++
structs are, in fact, C++ classes. The *only* difference between a struct
and a class is default accessibility of members (iow. if access rights are
not specified, members will be by default private in a class but public in
a struct). This means that you can add a whole lot of things to a C++ struct
which you cannot to a C struct, such as constructors, a destructor, assignment
and other operators, member functions, and public/protected/private access
right specifiers.

  But secondly, if you *inherit* from a C-style struct (POD), this base
part will still be a basic struct even if you use things like virtual
methods or multiple inheritance in the derived class. In other words,
if something expects a pointer to an object of the struct type, you can
pass it a pointer to an object of the derived type and it will work just
fine. The inherited class using things like virtual functions and multiple
inheritance does not affect the base struct part.

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> I'll have to look at this again (and 
> look up some syntax to see what "x::y : z" means :-)

  That might surprise many beginner and mid-level C++ programmers, but
there's nothing special going on there. You can pre-declare an inner
class and declare it later. The "x::y" part simply means "class y inside
class x". And the ": z" part means, of course, inheritance from z.

  In other words, this is perfectly valid (and quite handy):

class A
{
    class B;
    ...
};

class A::B
{
    ...
};

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> I'll have to look at this again (and 
>> look up some syntax to see what "x::y : z" means :-)
> 
>   That might surprise many beginner and mid-level C++ programmers, but
> there's nothing special going on there.

Oh! OK. Heh. I don't think I've ever had the pleasure of needing or using 
inner classes before, in any language, so it didn't leap out at me.

Oh! And A::B means class B inside class A, not class A inside class B. Wow, 
that confused me for a bit.

I see that. Yes, that could work cleanly, if I wanted to redeclare every 
function exported by DirectFB. Easier to kludge it in *this* case, but I'll 
remember the trick for another time where I'm writing actual production 
code. :-)

(Indeed, I'm doing the same thing with the "Player" vs "Player_private" 
except I'm not making it an inner class. I'll have to think if that would 
help anything.)


-- 
   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:
> The inherited class using things like virtual functions and multiple
> inheritance does not affect the base struct part.

Cool. Not even C# manages that. (You can't put virtual methods on a value 
class.) Another win for C++ MI.

-- 
   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:
> Oh! OK. Heh. I don't think I've ever had the pleasure of needing or using 
> inner classes before, in any language, so it didn't leap out at me.

  Why not? It aids in limiting the visibility of types, and thus increases
modularity. If a class uses a helper class which is completely exclusive
to that class (and might even be a friend), then it makes sense that the
helper class is defined as a private inner class.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Darren New <dne### [at] sanrrcom> wrote:
> > Oh! OK. Heh. I don't think I've ever had the pleasure of needing or using 
> > inner classes before, in any language, so it didn't leap out at me.

>   Why not? It aids in limiting the visibility of types, and thus increases
> modularity. If a class uses a helper class which is completely exclusive
> to that class (and might even be a friend), then it makes sense that the
> helper class is defined as a private inner class.

  Forgot to mention practical examples.

  Ever wondered what, for example, std::list<int>::iterator is? Well,
surprisise surprise, it's an inner class inside std::list<int>. It's so
related to std::list that it makes a lot of sense to make it an inner class.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Oh! OK. Heh. I don't think I've ever had the pleasure of needing or using 
>> inner classes before, in any language, so it didn't leap out at me.
> 
>   Why not? 

I just haven't needed it. In languages where there's specific header files 
(i.e., C and C++), I don't include the header file for the child class. In 
languages where there's specific support for the concept (C#) I use the 
internal visibility. I haven't done much in Java since they invented inner 
classes, but those aren't really "invisible" so much as obsfucated anyway, 
so there didn't seem to be a benefit there either.

I.e., everyone already has modular visibility controls, so putting it inside 
a class rather than a namespace didn't seem worthwhile.

> It aids in limiting the visibility of types, and thus increases
> modularity. If a class uses a helper class which is completely exclusive
> to that class (and might even be a friend), then it makes sense that the
> helper class is defined as a private inner class.


Yes it does. I didn't say it was bad. I just said I never found the need to 
use one. The existent mechanisms were already sufficient.


-- 
   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:
> Yes it does. I didn't say it was bad. I just said I never found the need 
> to use one. The existent mechanisms were already sufficient.

Altho your point of a public class with an embedded iterator is a good one. 
I even expect C# uses embedded classes to implement that in the libraries, 
now that you mention it. Of course, the name isn't exposed outside the class 
in any way, so it's hard to tell without reading actual source code. 
Instead, there's a call called "getEnumerator" or something on the 
collection that returns something that inherits the Enumerator interface or 
some such. You don't directly instantiate an iterator, but rather ask the 
class for one.

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

Post a reply to this message