Path: csiph.com!usenet.pasdenom.info!aioe.org!.POSTED!not-for-mail
From: Walter Banks <walter@bytecraft.com>
Newsgroups: comp.std.c
Subject: Re: Structure Packing.
Date: Tue, 12 Jun 2012 17:44:17 -0400
Organization: Aioe.org NNTP Server
Lines: 54
Message-ID: <4FD7B831.8B6BBEB9@bytecraft.com>
References: <12b3df42-f6a0-4411-a5e5-136900f8255b@googlegroups.com> <jqovin$9sr$1@dont-email.me> <4FD6ABFA.72F52C75@bytecraft.com> <jr7fpp$eti$1@dont-email.me> <4FD7659E.89172310@bytecraft.com> <a3p9irFkgbU1@mid.dfncis.de> <4FD79328.A040F7B8@bytecraft.com> <jr88ej$qan$1@dont-email.me>
NNTP-Posting-Host: vzsz4WkfwlCfToy3fCjPkQ.user.speranza.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Complaints-To: abuse@aioe.org
X-Mailer: Mozilla 4.79 [en]C-CCK-MCD NSCPCD479  (Windows NT 5.0; U)
X-Accept-Language: en
X-Notice: Filtered by postfilter v. 0.8.2
Xref: csiph.com comp.std.c:1375



Eric Sosman wrote:

> > The current implementation allocates next fit for each structure element.
> >
> > As the day goes on I am getting convinced that it is a bad idea.
>
>      Perhaps structs are not the right tool for the job?  Instead of
>
>         struct {
>             unsigned char flag;
>             double value;
>         } data[1000];
>
> ... you might do better to write
>
>         unsigned char data_flag[1000];
>         double data_value[1000];
>
> ("Parallel arrays" were bread-and-butter for languages that didn't
> have struct-like things, but seem to have fallen into disuse.  The
> struct is a great help, but it is not the only way to skin cats.)

My job is to take what our customers write in their application
code and optimize within their expectations and the standards
documents.

This whole question started to show itself with a piece of customer
code that has a large struct array with about 25 % of the ram
space un-used. This specific customer is happy by moving two lines
and saving (as it turns out) all of his hole space.

This conversation a few days ago started me looking into
how far I could push the envelope from the compiler end.
to just make the problem go away.

From a customer point of view there isn't an easy way to
identify the solution to the problem without knowing a quite
a bit about both this specific hardware and the C compiler
constraints allocating struct space. There are several data
types involved. It is information a programmer should not
need to know at that level of detail for most routine applications

Having the compiler make an intelligent suggestion is a
workable solution. If there is any message in this thread it is
don't even consider messing with standards and conventions.

w..



w..