Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c > #163822

Re: About struct fields that are assigned once and never changed again

From James Kuyper <jameskuyper@alumni.caltech.edu>
Newsgroups comp.lang.c
Subject Re: About struct fields that are assigned once and never changed again
Date 2021-12-13 12:09 -0500
Organization A noiseless patient Spider
Message-ID <sp7uo8$spv$2@dont-email.me> (permalink)
References <56b509db-c5ba-4020-b1e4-6250d41a706cn@googlegroups.com>

Show all headers | View raw


On 12/13/21 5:49 AM, Oğuz wrote:
> I have an array of structs as follows:
> 
> struct {
> struct {
> int value;
> bool in_use;
> } values[MAX_INPUTS_SIZE];
> size_t size;
> } inputs;
> 
> and a function that initializes it with user-supplied data. After the function is run, nothing in the program alters `inputs.size' or `inputs.values[N].value'. Now I have two questions about this that I can't answer myself:
> i) Is there a way to treat size and value fields as `const' outside that function?

Sort-of. What you can do is use access functions to give a const
interface to the data, with the file containing the initialization
routine and access functions being the only place which has non-const
access to the data. The key to making this work is to declaring an
opaque struct type for use outside of that, with those functions being
the only ones that know the actual struct layout:

mystruct.h:
#ifndef H_MYSTRUCT
    #define H_MYSTRUCT

    struct mystruct;

    int get_value(const struct mystruct*, size_t);
    size_t get_size(const struct mystruct*);
    const struct mystruct *initialize_mystruct
        (size_t size, int[static size]);
#endif

mystruct.c:
#include <stdbool.h>
#include <stdlib.h>
#include <string.h>
#include "mystruct.h"

// Since this approach requires that mystruct objects be dynamically
// allocated, I decided to save some space by moving size to the
// beginning, allowing values to be a flexible array member. As a result
// you don't have to impose any arbitrary upper limit on the size;
// you're  limited only by the amount of availale memory. You don't have
// to do this.

struct mystruct {
    size_t size;
    struct {
        int value;
        bool in_use;
    } values[];
};

int get_value(const struct mystruct *inputs, size_t index)
{
    // I'm not sure how you want to use in_use, but it should probably
    // have some role to play in this function.

    if(inputs == NULL || index >= inputs->size)
    {
         // Error handling
         return 0;
    }
    return inputs->values[index].value;
}

size_t get_size(const struct mystruct *inputs)
{
    if(inputs == NULL)
    {
        // Error handling
        return 0;
    }
    return inputs->size;
}

const struct mystruct *initialize_mystruct(size_t size, int values[size])
{
    struct mystruct *inputs = malloc(sizeof(*inputs) +
        size * sizeof(inputs->values[0]));
    if(inputs == NULL)
    {
        // Error handling
        return NULL;
    }
    inputs->size = size;
    memcpy(inputs->values, values, size*sizeof(values[0]));
    for(size_t val=0; val<size; val++)
        inputs->values[val].in_use = false;
    return inputs;
}

The above code compiles on my desktop without error messages, but I have
not tested it. My apologies for any errors I might have made.

Note that the members of mystruct are completely unknown outside of
mystruct.c, and code outside of mystruct.c never sees anything other
than const-qualified pointers to struct mystruct.

> ii) If there is, would it make any difference performance-wise? Would it allow the compiler to optimize more?

I wouldn't expect major benefits from this approach other than making
the contents of struct mystruct inaccessible.

Back to comp.lang.c | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

About struct fields that are assigned once and never changed again Oğuz <oguzismailuysal@gmail.com> - 2021-12-13 02:49 -0800
  Re: About struct fields that are assigned once and never changed again Oğuz <oguzismailuysal@gmail.com> - 2021-12-13 02:50 -0800
  Re: About struct fields that are assigned once and never changed again Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-12-13 03:05 -0800
  Re: About struct fields that are assigned once and never changed again David Brown <david.brown@hesbynett.no> - 2021-12-13 12:12 +0100
    Re: About struct fields that are assigned once and never changed again Oğuz <oguzismailuysal@gmail.com> - 2021-12-13 09:01 -0800
      Re: About struct fields that are assigned once and never changed again David Brown <david.brown@hesbynett.no> - 2021-12-13 18:37 +0100
      Re: About struct fields that are assigned once and never changed again scott@slp53.sl.home (Scott Lurndal) - 2021-12-13 18:06 +0000
  Re: About struct fields that are assigned once and never changed again Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-12-13 16:12 +0000
  Re: About struct fields that are assigned once and never changed again James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-12-13 12:09 -0500
  Re: About struct fields that are assigned once and never changed again Guillaume <message@bottle.org> - 2021-12-13 19:15 +0100
    Re: About struct fields that are assigned once and never changed again James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-12-13 13:25 -0500
  Re: About struct fields that are assigned once and never changed again Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-12-15 00:25 -0800
    Re: About struct fields that are assigned once and never changed again Oğuz <oguzismailuysal@gmail.com> - 2021-12-15 12:38 +0300

csiph-web