Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Reset struct or class sections
33 views
Skip to first unread message
Rick C. Hodgin
Jun 30, 2018, 9:45:57 AM6/30/18
to
I have a common operation in my code where I need to reset everything
in a structure, except for portions of the structure header area that
contains something like unique ids, or linked list pointers (or a few
linked list pointers), etc.
Does anyone know of a way in C where I could easily reset portions of
the structure contents in a reliable way?
I'm thinking for CAlive to add new section {{..}} blocks, which can
be mismatched, but would allow sub-components within structures (and
classes in CAlive) to be identified and grouped together, allowing
for operations on those sub-groupings without explicit coding to do
so.
It would be something like this. Consider a definition of a strut
which contains section blocks in addition to normal member creation:
// Raw structure:
struct SExample
{
struct SLinkList ll1;
struct SLinkList ll2;
int a;
int b;
int c;
int d;
union {
int ei;
float ef;
}
float f;
float g;
float h;
};
// With section references:
struct SExample
{
section linklist {{
struct SLinkList ll1;
struct SLinkList ll2;
}} // Since this one is not nested, doesn't need closing
// "section linklist" text
section data {{
section integers {{
int a;
int b;
int c;
int d;
section floats {{
union {
int ei;
float ef;
}
section integers }}
float f;
float g;
float h;
section floats }}
section data }}
};
In this example, there are four sections defined:
linklist
data
integers
floats
Some sections overlap, but each one is defined within its {{ and }}
named range.
Having these sub-blocks within would allow access to the section
groups, including the feature I need which is to reset that portion
of the structure, yet without affecting the whole thing:
SExample e;
// Reset everything like normal
reset e; // Equivalent of memset(&e, 0, sizeof(e));
// Or only reset portions:
reset e.linklist; // memset() only the linklist {{..}} members
reset e.data; // memset() only the data {{..}} members
reset e.integers; // memset() only the integers {{..}} members
reset e.floats; // memset() only the floats {{..}} members
It would also allow sub-portions of structures to be passed by ref
or pointer, so they can be accessed as their sub-portion members,
but no more, as in:
// Definition
void my_function(SExample.floats* f)
{
// Access to the SExample.floats members here through f->
f->ef = 0.0f;
f->f = 0.0f;
f->g = 0.0f;
f->h = 0.0f;
}
Usage:
struct SExample e;
my_function(&e.floats);
Is there an existing way in C or C++ to do this?
--
Rick C. Hodgin
in a structure, except for portions of the structure header area that
contains something like unique ids, or linked list pointers (or a few
linked list pointers), etc.
Does anyone know of a way in C where I could easily reset portions of
the structure contents in a reliable way?
I'm thinking for CAlive to add new section {{..}} blocks, which can
be mismatched, but would allow sub-components within structures (and
classes in CAlive) to be identified and grouped together, allowing
for operations on those sub-groupings without explicit coding to do
so.
It would be something like this. Consider a definition of a strut
which contains section blocks in addition to normal member creation:
// Raw structure:
struct SExample
{
struct SLinkList ll1;
struct SLinkList ll2;
int a;
int b;
int c;
int d;
union {
int ei;
float ef;
}
float f;
float g;
float h;
};
// With section references:
struct SExample
{
section linklist {{
struct SLinkList ll1;
struct SLinkList ll2;
}} // Since this one is not nested, doesn't need closing
// "section linklist" text
section data {{
section integers {{
int a;
int b;
int c;
int d;
section floats {{
union {
int ei;
float ef;
}
section integers }}
float f;
float g;
float h;
section floats }}
section data }}
};
In this example, there are four sections defined:
linklist
data
integers
floats
Some sections overlap, but each one is defined within its {{ and }}
named range.
Having these sub-blocks within would allow access to the section
groups, including the feature I need which is to reset that portion
of the structure, yet without affecting the whole thing:
SExample e;
// Reset everything like normal
reset e; // Equivalent of memset(&e, 0, sizeof(e));
// Or only reset portions:
reset e.linklist; // memset() only the linklist {{..}} members
reset e.data; // memset() only the data {{..}} members
reset e.integers; // memset() only the integers {{..}} members
reset e.floats; // memset() only the floats {{..}} members
It would also allow sub-portions of structures to be passed by ref
or pointer, so they can be accessed as their sub-portion members,
but no more, as in:
// Definition
void my_function(SExample.floats* f)
{
// Access to the SExample.floats members here through f->
f->ef = 0.0f;
f->f = 0.0f;
f->g = 0.0f;
f->h = 0.0f;
}
Usage:
struct SExample e;
my_function(&e.floats);
Is there an existing way in C or C++ to do this?
--
Rick C. Hodgin
Bart
Jun 30, 2018, 1:34:32 PM6/30/18
to
On 30/06/2018 14:45, Rick C. Hodgin wrote:
> I have a common operation in my code where I need to reset everything
> in a structure, except for portions of the structure header area that
> contains something like unique ids, or linked list pointers (or a few
> linked list pointers), etc.
>
> Does anyone know of a way in C where I could easily reset portions of
> the structure contents in a reliable way?
I'm sure you know what C is capable of, which is very little. But as
> I have a common operation in my code where I need to reset everything
> in a structure, except for portions of the structure header area that
> contains something like unique ids, or linked list pointers (or a few
> linked list pointers), etc.
>
> Does anyone know of a way in C where I could easily reset portions of
> the structure contents in a reliable way?
you're posting to C++ too, again anything is possible.
> // With section references:
> struct SExample
> {
> section linklist {{
> struct SLinkList ll1;
> struct SLinkList ll2;
> }} // Since this one is not nested, doesn't need closing
> // "section linklist" text
>
> section data {{
> section integers {{
> int a;
> int b;
> int c;
> int d;
> section floats {{
> union {
> int ei;
> float ef;
> }
> section integers }}
> float f;
> float g;
> float h;
> section floats }}
> section data }}
> };
explains where you weren't able to use indentation more to show the
structure, which might be more like this:
section linklist {{
struct SLinkList ll1;
struct SLinkList ll2;
section data {{
section integers {{
int a;
int b;
int c;
int d;
section floats {{
union {
int ei;
float ef;
}
section integers }}
float f;
float g;
float h;
section floats }}
section data }}
};
frowned upon (look at HTML and XML which don't allow overlapping tag
scopes).
But here it's doubly bad because you already have a structuring
mechanism (nested, anonymous structs and unions) and you're
superimposing another one.
>
> In this example, there are four sections defined:
>
> linklist
> data
> integers
> floats
>
> Some sections overlap, but each one is defined within its {{ and }}
> named range.
>
> Having these sub-blocks within would allow access to the section
> groups, including the feature I need which is to reset that portion
> of the structure, yet without affecting the whole thing:
>
> SExample e;
>
> // Reset everything like normal
> reset e; // Equivalent of memset(&e, 0, sizeof(e));
>
> // Or only reset portions:
> reset e.linklist; // memset() only the linklist {{..}} members
> reset e.data; // memset() only the data {{..}} members
> reset e.integers; // memset() only the integers {{..}} members
> reset e.floats; // memset() only the floats {{..}} members
The most useful idea here is the 'reset' feature.
> In this example, there are four sections defined:
>
> linklist
> data
> integers
> floats
>
> Some sections overlap, but each one is defined within its {{ and }}
> named range.
>
> Having these sub-blocks within would allow access to the section
> groups, including the feature I need which is to reset that portion
> of the structure, yet without affecting the whole thing:
>
> SExample e;
>
> // Reset everything like normal
> reset e; // Equivalent of memset(&e, 0, sizeof(e));
>
> // Or only reset portions:
> reset e.linklist; // memset() only the linklist {{..}} members
> reset e.data; // memset() only the data {{..}} members
> reset e.integers; // memset() only the integers {{..}} members
> reset e.floats; // memset() only the floats {{..}} members
(I used to have something called 'clear' I think, which I might reinstate.)
But your problem here isn't zeroing memory, but imposing an unnatural
structuring over the data. I think if that is really necessary, there
are a number of ways of doing that in C.
For example, for 'floats' section, define a dummy struct with the same
layout, and then do manipulations with pointers.
Alternatively, make use of the fact that each element of your struct is
32 bits, and alias an array to it of which you can clear selected slices.
All a bit untidy, but not that much worse than your proposal, and not
requiring yet more obscure features.
--
bart
Rick C. Hodgin
Jun 30, 2018, 1:44:22 PM6/30/18
to
On 6/30/2018 1:34 PM, Bart wrote:
> On 30/06/2018 14:45, Rick C. Hodgin wrote:
>> I have a common operation in my code where I need to reset everything
>> in a structure, except for portions of the structure header area that
>> contains something like unique ids, or linked list pointers (or a few
>> linked list pointers), etc.
>>
>> Does anyone know of a way in C where I could easily reset portions of
>> the structure contents in a reliable way?
>
> I'm sure you know what C is capable of, which is very little. But as you're
> posting to C++ too, again anything is possible.
I know a lot about C, but I still learn new things all the time. I
> On 30/06/2018 14:45, Rick C. Hodgin wrote:
>> I have a common operation in my code where I need to reset everything
>> in a structure, except for portions of the structure header area that
>> contains something like unique ids, or linked list pointers (or a few
>> linked list pointers), etc.
>>
>> Does anyone know of a way in C where I could easily reset portions of
>> the structure contents in a reliable way?
>
> I'm sure you know what C is capable of, which is very little. But as you're
> posting to C++ too, again anything is possible.
learned recently that sprintf() returns the length of the string,
for example. Never knew that. Would've come in handy hundreds of
times over the decades.
> Alternatively, make use of the fact that each element of your struct is 32
> bits, and alias an array to it of which you can clear selected slices.
>
> All a bit untidy, but not that much worse than your proposal, and not
> requiring yet more obscure features.
--
Bart
Jun 30, 2018, 4:31:36 PM6/30/18
to
On 30/06/2018 18:44, Rick C. Hodgin wrote:
> On 6/30/2018 1:34 PM, Bart wrote:
>> On 30/06/2018 14:45, Rick C. Hodgin wrote:
>>> section integers {{
>>> int a;
>>> int b;
>>> int c;
>>> int d;
>>> section floats {{
>>> union {
>>> int ei;
>>> float ef;
>>> }
>>> section integers }}
>>> float f;
>>> float g;
>>> float h;
>>> section floats }}
> On 6/30/2018 1:34 PM, Bart wrote:
>> On 30/06/2018 14:45, Rick C. Hodgin wrote:
>>> section integers {{
>>> int a;
>>> int b;
>>> int c;
>>> int d;
>>> section floats {{
>>> union {
>>> int ei;
>>> float ef;
>>> }
>>> section integers }}
>>> float f;
>>> float g;
>>> float h;
>>> section floats }}
>> But your problem here isn't zeroing memory, but imposing an unnatural
>> structuring over the data. I think if that is really necessary, there
>> are a number of ways of doing that in C.
>>
>> For example, for 'floats' section, define a dummy struct with the same
>> layout, and then do manipulations with pointers.
>
> And the ei/ef union?
typedef struct {
>> structuring over the data. I think if that is really necessary, there
>> are a number of ways of doing that in C.
>>
>> For example, for 'floats' section, define a dummy struct with the same
>> layout, and then do manipulations with pointers.
>
> And the ei/ef union?
union {
int ei;
float ef;
}
int ei;
float ef;
}
float f;
float g;
float h;
} floats_section;
float g;
float h;
struct SExample X;
floats_section* X_floats = (void*)&X.ei;
memset(X_floats,0,sizeof (*X_floats));
--
bart
Rick C. Hodgin
Jun 30, 2018, 4:56:36 PM6/30/18
to
you allow a reset floats; and a reset integers; to reset the overlapping
portions?
Note: they overlap in the ++++ section below:
// With section references:
struct SExample
{
section linklist {{
struct SLinkList ll1;
struct SLinkList ll2;
}} // Since this one is not nested, doesn't need closing
// "section linklist" text
section data {{
int a; |
int b; |
int c; |
int d; |
========section floats {{========|======
int b; |
int c; |
int d; |
union { +++++++| |
int ei; +++++++| | overlapping data
float ef; +++++++| | between sections
} +++++++| |
--------section integers }}------- |
float f; |
float g; |
float h; |
========section floats }}===============
float g; |
float h; |
section data }}
};
--
Rick C. Hodgin
Bart
Jun 30, 2018, 6:17:52 PM6/30/18
to
everything in the floats section?
The simple way is to individually clear {a,b,c,d,ei/ef} or {ei/ef,f,g,h}.
Another way is to duplicate the layout of {a,b,c,d,ei/ef} and
{ei/ef,f,g,h} as I tried above (paying attention to alignments and
padding). This defines object layouts that match your two sections.
Another way is to divide your overlapping sections into three lots, each
of which may be wrapped in an anonymous struct: A, B, C where section
integers is {A, B}, and section floats is {B, C}. And A is {a,b,c,d}, B
is {ei/ef} and C is {f,g,h}.
Then you do reset A; reset B, or reset B; reset C.
I'm sure other people can came up with many ways of actually performing
the task.
But devising a scheme for arbitrary, overlapping overlays to be added as
a totally new language feature is quite hard to do, it will look ugly,
and it will be confusing.
If you want a more general approach within the current language, try this:
#define integers_sect a,f
#define floats_sect ei,i // dummy zero-size field after h
struct SExample X;
reset_section(&X,getoffsets(struct SExample,integers_sect));
where:
#define getoffsets(T,a,b) offsetof(T,a),offsetof(T,b)-offsetof(T,a)
This should yield 'x,y' where x is the start offset of the section, y is
the size in bytes. The reset_section call becomes:
reset_section(&X, 24, 16);
for example. (This can map to memset((char*)&X+24,0,16).)
I've no idea whether this would work, but this anyway has the problem of
needing a struct field one past the end of the 'section'.
But I think it won't appeal to you because the information that defines
the sections is defined outside, separately from the struct.
--
bart
Rick C. Hodgin
Jun 30, 2018, 6:45:15 PM6/30/18
to
On 06/30/2018 06:17 PM, Bart wrote:
> But devising a scheme for arbitrary, overlapping overlays to be added as
> a totally new language feature is quite hard to do, it will look ugly,
> and it will be confusing.
I devised it. And it's not ugly or confusing. With syntax highlighting
> But devising a scheme for arbitrary, overlapping overlays to be added as
> a totally new language feature is quite hard to do, it will look ugly,
> and it will be confusing.
applied there are color bars which differentiate each grouping, and the
section headers are hidden.
Have you ever noticed that (nearly?) every feature I suggest or propose
is criticized by you in your replies? It's a bad idea as I propose it,
or it doesn't add enough value to be useful, or its just clutters up
something, etc.?
I was asking for a way to already do this in C so I wouldn't have to
create one. But I do have a need for this ability, and it's not that
difficult to add to the compiler, and I can see it have great utility
when you stop and give the potential uses some thought.
--
Rick C. Hodgin
Chris M. Thomasson
Jun 30, 2018, 7:03:05 PM6/30/18
to
On 6/30/2018 6:45 AM, Rick C. Hodgin wrote:
> I have a common operation in my code where I need to reset everything
> in a structure, except for portions of the structure header area that
> contains something like unique ids, or linked list pointers (or a few
> linked list pointers), etc.
>
> Does anyone know of a way in C where I could easily reset portions of
> the structure contents in a reliable way?
[...]
> I have a common operation in my code where I need to reset everything
> in a structure, except for portions of the structure header area that
> contains something like unique ids, or linked list pointers (or a few
> linked list pointers), etc.
>
> Does anyone know of a way in C where I could easily reset portions of
> the structure contents in a reliable way?
quick pseudo-code
____________________________
struct part_0
{
int a;
};
struct part_1
{
short b;
};
struct parts
{
struct part_0 p0;
struct part_1 p1;
// other parts...
};
Alter a portion of the structure:
struct parts p = { { 12 }, { 34 } };
p.p1.b = 42;
____________________________
;^)
Rick C. Hodgin
Jun 30, 2018, 7:26:50 PM6/30/18
to
You have to reference struct components with additional naming steps,
and even if you make them anonymous you still can't have members which
overlap from one struct into the next.
> ;^)
:-(
--
Rick C. Hodgin
Bart
Jun 30, 2018, 7:55:42 PM6/30/18
to
On 30/06/2018 23:45, Rick C. Hodgin wrote:
> On 06/30/2018 06:17 PM, Bart wrote:
>> But devising a scheme for arbitrary, overlapping overlays to be added as
>> a totally new language feature is quite hard to do, it will look ugly,
>> and it will be confusing.
>
> I devised it. And it's not ugly or confusing. With syntax highlighting
> applied there are color bars which differentiate each grouping, and the
> section headers are hidden.
Effectively you're taking the elements of a struct, ignoring any
> On 06/30/2018 06:17 PM, Bart wrote:
>> But devising a scheme for arbitrary, overlapping overlays to be added as
>> a totally new language feature is quite hard to do, it will look ugly,
>> and it will be confusing.
>
> I devised it. And it's not ugly or confusing. With syntax highlighting
> applied there are color bars which differentiate each grouping, and the
> section headers are hidden.
existing nested structure, and treating it as a mixed-type array, with
sections defining random slices of that array.
Since you can't really have a mixed-type array, your are actually
superimposing multiple different structs - non-nested ones - on top of
arbitrary portions of a regular struct.
It sounds interesting but I'm struggling to think of a use which is not
better handled by redesigning the original struct to better suit the
requirements.
> Have you ever noticed that (nearly?) every feature I suggest or propose
> is criticized by you in your replies? It's a bad idea as I propose it,
> or it doesn't add enough value to be useful, or its just clutters up
> something, etc.?
of your proposals. I think new features should be kept to a minimum and
the ones that are added should be obviously useful without needing to
scratch your head wondering under what circumstances they might ever be
used.
> I was asking for a way to already do this in C so I wouldn't have to
> create one. But I do have a need for this ability, and it's not that
> difficult to add to the compiler, and I can see it have great utility
> when you stop and give the potential uses some thought.
something like a slice. That is, a span from field .a to field .b, where
a, b and the fields in-between can all be different types.
The declaration of the struct needs no extra annotations; and the same
struct can be sliced in different ways by different programs, if it is
shared. In fact, the slice can be applied to a struct declared in a
third party header.
(As for syntax, that would need some thought, but could be as simple as
X.(a,b) where X is a struct expression, and a,b are field names.)
--
bart
Chris M. Thomasson
Jun 30, 2018, 8:01:08 PM6/30/18
to
> and even if you make them anonymous you still can't have members which
> overlap from one struct into the next.
p.p1.b ?
Like trying to spread some sort of syntactic sugar all over the place?
What about the ants?
;^)
Rick C. Hodgin
Jul 1, 2018, 12:06:33 AM7/1/18
to
On 06/30/2018 07:55 PM, Bart wrote:
> On 30/06/2018 23:45, Rick C. Hodgin wrote:
>> On 06/30/2018 06:17 PM, Bart wrote:
>>> But devising a scheme for arbitrary, overlapping overlays to be added as
>>> a totally new language feature is quite hard to do, it will look ugly,
>>> and it will be confusing.
>>
>> I devised it. And it's not ugly or confusing. With syntax highlighting
>> applied there are color bars which differentiate each grouping, and the
>> section headers are hidden.
>
> Effectively you're taking the elements of a struct, ignoring any
> existing nested structure, and treating it as a mixed-type array, with
> sections defining random slices of that array.
>
> Since you can't really have a mixed-type array, your are actually
> superimposing multiple different structs - non-nested ones - on top of
> arbitrary portions of a regular struct.
>
> It sounds interesting but I'm struggling to think of a use which is not
> better handled by redesigning the original struct to better suit the
> requirements.
It allows you to send only portions of your parent object to external
> On 30/06/2018 23:45, Rick C. Hodgin wrote:
>> On 06/30/2018 06:17 PM, Bart wrote:
>>> But devising a scheme for arbitrary, overlapping overlays to be added as
>>> a totally new language feature is quite hard to do, it will look ugly,
>>> and it will be confusing.
>>
>> I devised it. And it's not ugly or confusing. With syntax highlighting
>> applied there are color bars which differentiate each grouping, and the
>> section headers are hidden.
>
> Effectively you're taking the elements of a struct, ignoring any
> existing nested structure, and treating it as a mixed-type array, with
> sections defining random slices of that array.
>
> Since you can't really have a mixed-type array, your are actually
> superimposing multiple different structs - non-nested ones - on top of
> arbitrary portions of a regular struct.
>
> It sounds interesting but I'm struggling to think of a use which is not
> better handled by redesigning the original struct to better suit the
> requirements.
things, making only those portions visible to it.
>> Have you ever noticed that (nearly?) every feature I suggest or propose
>> is criticized by you in your replies? It's a bad idea as I propose it,
>> or it doesn't add enough value to be useful, or its just clutters up
>> something, etc.?
>
> Maybe it's just me but I have a really hard time understanding the point
> of your proposals. I think new features should be kept to a minimum and
> the ones that are added should be obviously useful without needing to
> scratch your head wondering under what circumstances they might ever be
> used.
had some need to do something, and the tool wouldn't allow it to be
done, so I've gone to define it.
>> I was asking for a way to already do this in C so I wouldn't have to
>> create one. But I do have a need for this ability, and it's not that
>> difficult to add to the compiler, and I can see it have great utility
>> when you stop and give the potential uses some thought.
>
> If I really wanted something like that, I would probably implement it as
> something like a slice. That is, a span from field .a to field .b, where
> a, b and the fields in-between can all be different types.
could append single lines or multiple separate blocks.
It basically creates a protocol to allow sub-portions of the encap-
sulating object to be exposed externally.
> The declaration of the struct needs no extra annotations; and the same
> struct can be sliced in different ways by different programs, if it is
> shared. In fact, the slice can be applied to a struct declared in a
> third party header.
>
> (As for syntax, that would need some thought, but could be as simple as
> X.(a,b) where X is a struct expression, and a,b are field names.)
--
Rick C. Hodgin
Jul 1, 2018, 12:08:14 AM7/1/18
to
>> and even if you make them anonymous you still can't have members which
>> overlap from one struct into the next.
>
> Are you really that worried about the naming steps:
> p.p1.b ?
Worried? No. It's just ridiculous to force such a thing on people.
>> overlap from one struct into the next.
>
> Are you really that worried about the naming steps:
> p.p1.b ?
--
Rick C. Hodgin
Chris M. Thomasson
Jul 1, 2018, 12:58:46 AM7/1/18
to
they are referring to; It sure shaves off a lot of ambiguity. ;^)
Chris M. Thomasson
Jul 1, 2018, 12:59:59 AM7/1/18
to
the mix. Might have to see a dentist.
Chris M. Thomasson
Jul 1, 2018, 3:49:02 AM7/1/18
to
Chris M. Thomasson
Jul 1, 2018, 3:54:24 AM7/1/18
to
archives. And perhaps try to think of giving out some simple highly
experimental online compiler examples on how to use it in a very
experimental space.
Think producing an interactive tutorial, to go along with your highly
adaptive, user friendly and extraordinarily integrated debugger! I have
to admit walking through code in a GUI debugger before.... MSVC was
always a nice one, indeed. :^)
Chris M. Thomasson
Jul 2, 2018, 1:40:31 PM7/2/18
to
GUI HTML interface using just those two buttons. The user can hit pause
at any time during the execution of any CAlive program simply by
clicking the pause button. Heck you can build one from scratch using
pixels in an HTML5 canvas wrt very custom graphics and abilities that
native HTML5 UI tools simply cannot handle...
:^D
0 new messages