Hello Jim,

I was unable to prevent myself from this remark :)

Jim Schram wrote:
>
> At 10:54 AM -0800 2002/02/22, Dave Carrigan wrote:
> >Jim Schram <schram@...> writes:
> >
> >> Your code *does* declare a structure containing a BitmapType
> > > structure, who's individual field definitions are not known without
> > > #defining ALLOW_ACCESS_TO_INTERNALS_OF_BITMAPS. The compiler needs to
> >> know the BitmapType structure's size information, to compute the size
> >> of a _record, and thus ultimately the size of a GraphicsRecord class.
> >
> >No, it *does not*, it declares a *pointer* to a structure containing a
> >BitmapType structure.
>
> Sorry Dave, but you still seem to be missing the very point the compiler is
alerting you to.
>
> Let's say p is a pointer to a _record. The compiler requires knowledge
> of the size of the object pointed to by p (in order to support
> operations such as p++, or declaring an instance of _record on the
> stack, etc.). It does not matter whether or not you actually perform
> such an operation anywhere in the code, the compiler still needs to know
> the size of _record. Since BitmapType is a incomplete structure definition,
> the size of _record is unknown, and so the compiler is warning you about that.

No, standard C++ compiler *should not* know the size of the object or
the structure in order to declare the pointer to its instance, only its
*existence*. For example, following code should be compiled by any
ANSI/ISO C++ compiler (actually, I don't know if CW compiles this, since
I don't use it):

struct _record;

class GraphicsRecord {
private:
const _record * data;

The knowledge about size of the object is needed *only* when one really
tries to perform some operation on it: create new instance, declare
static or stack instance, declare new container type for it etc. What
Dave does, it *declares* the container - struct _record. Whenever
compiler finds declaration of new type:

const struct _record {
UInt16 flags;
BitmapType bitmap;
};

it required that all contained typed have to be *completely* defined at
that point:

> It *does not matter* if you're only declaring/using a pointer to such
> a structure... the fact that you are declaring a structure which contains,
> as a member field, a BitmapType structure is the reason your code fails
> without ALLOW_ACCESS_TO_INTERNALS_OF_BITMAPS defined. I'm not sure how
> much clearer I can explain this. It's Ben's point and mine.

Yes! It's the reason of the warning. The declaration of the pointer
seems to have nothing with it.

My suggestion is to put forward declaration in header and actual
declaration in CPP file and compile the latest with #define
ALLOW_ACCESS_TO_INTERNALS_OF_BITMAPS.

> >I was using a perfectly legitimate technique
> >that's been broken by Palm's attempt to enforce data abstraction beyond
> >what C can really provide. I'm not saying that the attempt was a bad
> >idea, but it will break some legitimate code in the process. However, as
> >I said before, I can work around that at the expense of making my code a
> >little less clear (and already have, in fact).
>
> I disagree that it's a "perfectly legitimate technique" but that is
unimportant.
> We agree on the result, but disagree on the rationality behind it(?) Fine...
> whatever... you've worked around the problem, so this discussion has degraded
> into little more than an exercise in C linguistics.
>
> Best Regards,
>
> Jim Schram
> PalmSource Inc.
> Partner Engineering

WBR,
--
Alexander Horoshilov

--
For information on using the Palm Developer Forums, or to unsubscribe, please
see http://www.palmos.com/dev/tech/support/forums/