That's exactly what I know from using the language rather than reading the
spec's...
I also tried to explain that, but it does not seem to reach goal... <g>



Walter wrote:

> My understanding is that it is not standard C. In a practical sense, the compiler cannot generate code to step through an array with variable sized elements with a fixed sized pointer arithmetic. Adjusting all the element sizes upwards to match the largest size would be an extension to the language. You can achieve the same effect in standard C by putting a dimension in the [] that is large enough.
>
> C really is rather limited in how you can lay out and initialize data structures.
>
> "Mark Evans" <mevans@zyvex.com> wrote in message news:1103_990462843@evans...
> >
> > Again, missing the point.  Of course there are other ways to do this task.
> The point is that this *specific* way does not work, even though it is proper C, and that may indicate
> > a compiler bug.
> >
> > Maybe the C standard leaves this sort of thing as
> "implementation-specific" in which case the compiler could do anything.  On the other hand, maybe it spells out what the
> > compiler should do.  I'm not the expert but am curious to know.
> >
> > In my thinking what the compiler should do is normalize the element sizes
> to accomodate the largest one.
> >
> > Mark
> >
> >
> > On Fri, 18 May 2001 14:42:26 -0700, "Walter" <walter@digitalmars.com>
> wrote:
> > > The code has an array of variable sized structs. You can't step through
> that
> > > with a fixed increment size. Instead, try doing it as an array of
> pointers
> > > to variable sized structs.
> > >
> > > Mark Evans wrote in message <1103_990215032@evans>...
> > > >
> > > >Thanks Jan but I that's missing the point of the exercise.  In C it is
> > > always possible to use numberless brackets when you supply the
> initializers.
> > > What I need to know is whether this
> > > >problem qualifies as a bug in Digital Mars.
> > > >
> > > >The only alternative is that it may turn out my construction is not
> proper
> > > C in some obscure technical sense.  If so, then I am unaware of the
> fact.
> > > In any case the code passes the compiler
> > > >and therefore should work.
> > > >
> > > >Mark
> > > >
> > > >
> > > >On Fri, 18 May 2001 14:55:25 -0400, Jan Knepper <jan@smartsoft.cc>
> wrote:
> > > >> Mark Evans wrote:
> > > >>
> > > >> > // Simultaneously declare and init table
> > > >> > struct
> > > >> > {
> > > >> >     TypeCode                key;
> > > >> >     TypeCode                value[];
> > > >>
> > > >> I am not *completely* sure, but my first guess is this would have to
> be
> > > something like:
> > > >> TypeCode        value [ 16 ];
> > > >>
> > > >> Don't worry, be Kneppie!
> > > >> Jan
> > > >>
> > > >>
> > > >
> > > >
> > >
> > >
> >
> >

I will let the matter rest since I am giving the impression of a novice C programmer.  Actually I have worked with C for 13 years.  I know how arrays and pointers work -- sized, unsized, void, and otherwise.

What the compiler should do in this situation is probably open for debate, but clearly there are better ways to do it than what Digital Mars does now.  I think that letting the compiler figure out the largest value[] size is very reasonable and I bet it's even in the C standard.

Thank you for the conversation.

Mark


On Mon, 21 May 2001 13:03:28 -0400, Jan Knepper <jan@smartsoft.cc> wrote:
> Mark,
> 
> I think you should read Walter's messages as well.
> I do not know whether or not it is a compiler bug, a missing piece in the compiler implementation or may be even something missing in the C or C++ standards.
> 
> Since C isn't BASIC I don't think the compiler should normalize the element size to accomodate the largest one. Actually as I wrote earlier, the element of your particular example is
> a POINTER. A POINTER is a defined size and points to something which could be either 1 element of the defined type or more of which the compiler has no knowledge.
> 
> This is basically why I gave you the other example.
> TypeCode    value [];
> is basically the same thing as:
> TypeCode    *value;
> 
> Which is something completely different than:
> TypeCode        value [ 16 ];
> 
> HTH
> 
> Jan
> 
> 
> 
> Mark Evans wrote:
> 
> > Again, missing the point.  Of course there are other ways to do this task.  The point is that this *specific* way does not work, even though it is proper C, and that may indicate
> > a compiler bug.
> >
> > Maybe the C standard leaves this sort of thing as "implementation-specific" in which case the compiler could do anything.  On the other hand, maybe it spells out what the
> > compiler should do.  I'm not the expert but am curious to know.
> >
> > In my thinking what the compiler should do is normalize the element sizes to accomodate the largest one.
> >
> > Mark
> >
> > On Fri, 18 May 2001 14:42:26 -0700, "Walter" <walter@digitalmars.com> wrote:
> > > The code has an array of variable sized structs. You can't step through that with a fixed increment size. Instead, try doing it as an array of pointers to variable sized structs.
> > >
> > > Mark Evans wrote in message <1103_990215032@evans>...
> > > >
> > > >Thanks Jan but I that's missing the point of the exercise.  In C it is
> > > always possible to use numberless brackets when you supply the initializers. What I need to know is whether this
> > > >problem qualifies as a bug in Digital Mars.
> > > >
> > > >The only alternative is that it may turn out my construction is not proper
> > > C in some obscure technical sense.  If so, then I am unaware of the fact. In any case the code passes the compiler
> > > >and therefore should work.
> > > >
> > > >Mark
> > > >
> > > >
> > > >On Fri, 18 May 2001 14:55:25 -0400, Jan Knepper <jan@smartsoft.cc> wrote:
> > > >> Mark Evans wrote:
> > > >>
> > > >> > // Simultaneously declare and init table
> > > >> > struct
> > > >> > {
> > > >> >     TypeCode                key;
> > > >> >     TypeCode                value[];
> > > >>
> > > >> I am not *completely* sure, but my first guess is this would have to be
> > > something like:
> > > >> TypeCode        value [ 16 ];
> > > >>
> > > >> Don't worry, be Kneppie!
> > > >> Jan
> > > >>
> > > >>
> > > >
> > > >
> > >
> > >
> 

> What the compiler should do in this situation is probably open for debate, but clearly there are better ways to do it than what Digital Mars does now.

Which compiler did in this case what you expected it to do?

Jan