Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #163822
| 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> |
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 | Next — Previous in thread | Next in thread | Find similar | Unroll 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