Re: [Gnash-dev] gtkglext, et al

[strk]

On Sun, Apr 23, 2006 at 03:39:22AM +0200, Bastiaan Jacques wrote:
> On Sunday 23 April 2006 02:21, strk wrote:
> > I've given a quick read of your patch. It surely looks more C++ then
> > it is, but maybe, if the import_info is really just an helper class
> > of Movie as comments say, it could be an all-privates with Movie as a 
> > friend.
> > What do others think ? 
> 
> Thanks for looking at the patch! The only difference I can think of, if I
> were to make the class a friend, is that the Movie class would be able to
> write-access the import_info class members. That doesn't seem like much of
> an issue though, and I suspect that the code will in fact be a little faster.
> 
> Although opinions tend to differ on the merits of using friend classes,
> I'll go with the friend option if there are no objections.

Please share your opinions about friends. I'm not a C++ expert myself.
Note that my primary concern is augmenting readability of code.
If a class is there for the sole purpose of being used by another
class I'd like it to not fall under my eyes until I actually read
implementation of the user class itself.
This doesn't have to do with friendship actually, but rather with
headers layout. Unfortunately, as far as The Movie class will have
a vector of import_info classes as a member, all users of that
Movie class will also need visibility of that helper class, in
order to proper destroy it at Movie destruction time.

I'm fighting with these issues in another project right now, and
I really think some general approach to this would really help both
understand the code and reduce build time. Unfortunately I don't 
have a ready solution yet. 

I guess this can be an incremental process, so let's don't worry
about an optimal solution now. Time is probably better spent in
documenting flows and classes. 

--strk;