thoughts about BIC

[Lubos Lunak]

On Mon 8. April 2002 13:57, Michael Matz wrote:
> Hi,
>
> On Sat, 30 Mar 2002, Lubos Lunak wrote:
> > On Fri 29. March 2002 15:01, Rolf Magnus wrote:
> > > I was wondering if adding member variables always is BIC. Sure, it
> > > changes the size of the object (and if you don't append them to the
> > > end, the layout), but where is this size needed? AFAIK only on creation
> > > of the object, because the system needs to know how much storage to get
> > > for it. But if the allocation of storage is only done in the library
> > > that contains the class (e.g. for singletons or objects that are only
> > > created through a factory), this should not matter, right? So can
> > > member variables be added to such a class without making it BIC (if you
> > > don't let inline methods access them of course)?
>
> No, it's BIC also in other ways...

 and these ways are ... ?

>
> >  If you
> >
> >  - prevent others from creating instances of the class(no public
> > constructor, including copy ctor)
> >  - prevent others from subclassing it(not even a protected constructor)
> >  - prevent others from direct access to any data member(you should have
> > all data members at least protected: anyway), including inlines
>
> ... if an instance of such a class A is a member of another class B,
> extending A will break B by moving it's members just as if you added a
> member variable in the middle of B.  Yes, it's a special case of the above
> non-instanceability.

 But as you say, this is 1) in the list above, so it's no problem.

-- 
 Lubos Lunak
 llunak at suse.cz ; l.lunak at kde.org
 http://dforce.sh.cvut.cz/~seli