Path: csiph.com!fu-berlin.de!uni-berlin.de!news.dfncis.de!not-for-mail From: =?UTF-8?Q?Hans-Bernhard_Br=c3=b6ker?= Newsgroups: comp.arch.embedded Subject: Re: Using C preproc to uniquely identify structure members Date: Sat, 10 Apr 2021 23:16:09 +0200 Lines: 53 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: news.dfncis.de 6dT7Dh+MC66wqqlFo5NJtQsNsUxdTK2JIIie2fM7HYueHhxoyP33YvJzDm Cancel-Lock: sha1:DwpIMOW//w+4eMM/iO0cUmkp2oI= User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 In-Reply-To: Content-Language: en-US Xref: csiph.com comp.arch.embedded:30433 Am 10.04.2021 um 19:51 schrieb John Speth: > I could use some advice for a problem that I've had on my mind for > years. I'm looking for a black box function that will examine a memory > block of a known structure and output a list of IDs that point to any > members that have changed. The key flaw in that plan, as executed so far, is that you're trying to use a native C struct for this job. Arbitrary data of varying amount and composition doesn't live comfortably in such a rigidly structured format. Among others, forget about ever loading a piece of memory stored by a programming referring to one definition of that struct and having it interpreted sensibly by a program referring to a changed definition. C structs are not at all meant for such work. This is a job for a low-level type of database, or at the very least something like a tagged record-based data file. > There is such a large number of members that my quest is to > automate as much as possible the ID and comparison operations. Automate what: the work of doing the actual comparison, or the work of creating/updating the code that does the comparison? > Not > automating would require the programmer to redo the comparison I don't see a re-do, just an update to the existing comparison. > #define    MEMBER(t,v) t v; size_t size_ ## v; size_t id_ ## v > > typedef struct > { >   MEMBER(int,i); >   MEMBER(char,c); >   MEMBER(float,f); > } STRUCT; This design also violates an important principle: do not mix constant and variable data in the same structure. This is even more important in smallish, bare-metal embedded work, where you want the constants to actually be in (flash) PROM, not waste space in RAM. Worse than that, they wouldn't even contribute to the solution of the actual problem. If these data remain strictly inside a realm of executable code using the exact same definition of that struct (on binary compatible platforms), you don't need the extra fields for anything. If they can cross the boundary of that realm, having those elements doesn't help with the actual problem --- you then need a proper interface specification, which will _not_ be a C struct definition, for the transfer of those data, and serialization/deserialization functions to handle the translation between internal and external formats.