mutable data structures

[Markus.Elfring]

The C++ language specification provides the key word "mutable" that is
not available in the C99 standard.
Will it be imported to reduce any incompatibilities?
http://david.tribble.com/text/cdiffs...99-cpp-keyword
http://www.inf.uni-konstanz.de/~kueh...html#faq-18.13

Regards,
Markus

[Chris Hills]

In article <11**********************@g49g2000cwa.googlegroups .com>,
Ma************@web.de writes

The C++ language specification provides the key word "mutable" that is
not available in the C99 standard.
Will it be imported to reduce any incompatibilities?

I doubt it. why would C want to change simply to reduce incompatibilitys
with C++?

As it is most compilers do not support C99 (OK one claims to support it)
but the vast majority of C compilers are still at C90+ a few bits. SO
even if mutable and other C++ things are put into the C0* standard there
is no guarantee that it will be implemented.

You will get the companies who produce C/C++ compilers who will do it
but those that produce just C compilers will probably not unless their
customers start clamouring for it in a way they have not be asking for
C99.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[Chris Croughton]

On 10 Jul 2005 04:41:53 -0700, Ma************@web.de
<Ma************@web.de> wrote:

The C++ language specification provides the key word "mutable" that is
not available in the C99 standard.
Will it be imported to reduce any incompatibilities?
http://david.tribble.com/text/cdiffs...99-cpp-keyword
http://www.inf.uni-konstanz.de/~kueh...html#faq-18.13

Why should C provide it? It makes sense in C++ because you can have
member functions which operate on a 'const' object but which need to
alter data private to that object (so to external view nothing has
changed, but some internal data has been altered), but in C all fields
are public anyway so I don't see how it would be useful.

For instance, having a 'mutable' member would preclude the structure
being put into read-only memory (when delared as const), which would be
a definite disadvantage for many embedded systems.

It isn't a goal of C to remain compatible with C++ or of C++ to remain
compatible with C (for instance it would be useful to have long long and
the sized arithmetic types in C++) except via the extern "C" linkage.

Chris C

[Joe Wright]

Ma************@web.de wrote:

The C++ language specification provides the key word "mutable" that is
not available in the C99 standard.
Will it be imported to reduce any incompatibilities?
http://david.tribble.com/text/cdiffs...99-cpp-keyword
http://www.inf.uni-konstanz.de/~kueh...html#faq-18.13

Regards,
Markus

There is no effort that I know of by either the C community nor the C++
community to make the two languages more compatible. In designing C++ BS
started with familiar C and built his own new language. As time goes on
and the two languages evolve, new features of one might find their way
into the other. This is not about compatibility.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Markus.Elfring]

Chris Croughton schrieb:

On 10 Jul 2005 04:41:53 -0700, Ma************@web.de
<Ma************@web.de> wrote:

The C++ language specification provides the key word "mutable" that is
not available in the C99 standard.
Will it be imported to reduce any incompatibilities?
http://david.tribble.com/text/cdiffs...99-cpp-keyword
http://www.inf.uni-konstanz.de/~kueh...html#faq-18.13
Why should C provide it? It makes sense in C++ because you can have
member functions which operate on a 'const' object but which need to
alter data private to that object (so to external view nothing has
changed, but some internal data has been altered), but in C all fields
are public anyway so I don't see how it would be useful.

Public accessibility and visibility does not affect the constant state
of an attribute.
Would you like to be able to specify that a data field can never be
const and must always be writeable?

For instance, having a 'mutable' member would preclude the structure
being put into read-only memory (when delared as const), which would be
a definite disadvantage for many embedded systems.

Can you imagine that any data like cached values must not be stored
into write-protected memory?
Do you try to cast the constness away in such environments?

Regards,
Markus

[Markus.Elfring]

> There is no effort that I know of by either the C community nor the C++

community to make the two languages more compatible. In designing C++ BS
started with familiar C and built his own new language. As time goes on
and the two languages evolve, new features of one might find their way
into the other. This is not about compatibility.

I would like to see more cooperation in feature addition.

Regards,
Markus

[Richard Bos]

Ma************@web.de wrote:

There is no effort that I know of by either the C community nor the C++
community to make the two languages more compatible. In designing C++ BS
started with familiar C and built his own new language. As time goes on
and the two languages evolve, new features of one might find their way
into the other. This is not about compatibility.

I would like to see more cooperation in feature addition.

I would like not to see unnecessary keywords added to C. Being 79%
incompatible with C++ rather than 80% is not a goal that makes sense.

Richard

[Chris Croughton]

On 11 Jul 2005 05:59:02 -0700, Ma************@web.de
<Ma************@web.de> wrote:

Chris Croughton schrieb:

On 10 Jul 2005 04:41:53 -0700, Ma************@web.de
<Ma************@web.de> wrote:

> The C++ language specification provides the key word "mutable" that is
> not available in the C99 standard.
> Will it be imported to reduce any incompatibilities?
> http://david.tribble.com/text/cdiffs...99-cpp-keyword
> http://www.inf.uni-konstanz.de/~kueh...html#faq-18.13
Why should C provide it? It makes sense in C++ because you can have
member functions which operate on a 'const' object but which need to
alter data private to that object (so to external view nothing has
changed, but some internal data has been altered), but in C all fields
are public anyway so I don't see how it would be useful.

Public accessibility and visibility does not affect the constant state
of an attribute.
Would you like to be able to specify that a data field can never be
const and must always be writeable?

No, I see no need for it in C. As I said, in C++ there is more need for
it, and it is normally kept protected from user visibility.

For instance, having a 'mutable' member would preclude the structure
being put into read-only memory (when delared as const), which would be
a definite disadvantage for many embedded systems.

Can you imagine that any data like cached values must not be stored
into write-protected memory?

Huh? If it's modifiable it can't be in write-protected memory,
obviously.
Do you try to cast the constness away in such environments?

I don't cast constness away in any environments (except for certain
broken interfaces, and that's been so long ago that I've forgotten why
we had to do that, something to do with a callback which was specified
as const incorrectly).

Chris C

[Chris Croughton]

On 11 Jul 2005 05:59:02 -0700, Ma************@web.de
<Ma************@web.de> wrote:

There is no effort that I know of by either the C community nor the C++
community to make the two languages more compatible. In designing C++ BS
started with familiar C and built his own new language. As time goes on
and the two languages evolve, new features of one might find their way
into the other. This is not about compatibility.

I would like to see more cooperation in feature addition.

Indeed, I would like to see several things in C propagated into C++. In
particular long long and the named-width types in stdint.h. However,
propagating features just because they are there is not a good plan.

Chris C

[Chris Hills]

In article <42****************@news.xs4all.nl>, Richard Bos
<rl*@hoekstra-uitgeverij.nl> writes

Ma************@web.de wrote:

> There is no effort that I know of by either the C community nor the C++
> community to make the two languages more compatible. In designing C++ BS
> started with familiar C and built his own new language. As time goes on
> and the two languages evolve, new features of one might find their way
> into the other. This is not about compatibility.

I would like to see more cooperation in feature addition.

I would like not to see unnecessary keywords added to C. Being 79%
incompatible with C++ rather than 80% is not a goal that makes sense.

Richard

I agree the C and C++ are separate languages that share a common
ancestor.

C and C++ are likely to develop on separate directions for differing
reasons. For those people who need to interface to C or use C libraries
I suggest that they port the C code to a C subset of C++ that their C++
compiler supports.

Then write and maintain all the "c" with the C++ compiler.

Eventually that hybrid language c/C++ will die out.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[Chris Hills]

In article <sl******************@ccserver.keris.net>, Chris Croughton
<ch***@keristor.net> writes

On 11 Jul 2005 05:59:02 -0700, Ma************@web.de
<Ma************@web.de> wrote:

There is no effort that I know of by either the C community nor the C++
community to make the two languages more compatible. In designing C++ BS
started with familiar C and built his own new language. As time goes on
and the two languages evolve, new features of one might find their way
into the other. This is not about compatibility.

I would like to see more cooperation in feature addition.

Indeed, I would like to see several things in C propagated into C++. In
particular long long and the named-width types in stdint.h. However,
propagating features just because they are there is not a good plan.

Chris C

We agree for once ( I won't let it happen again :-)
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[Markus.Elfring]

> Huh? If it's modifiable it can't be in write-protected memory,

obviously.

What do you do if a few mutable elements are embedded into a larger
constant data structure?

Regards,
Markus

[Keith Thompson]

Ma************@web.de writes:

Huh? If it's modifiable it can't be in write-protected memory,
obviously.

What do you do if a few mutable elements are embedded into a larger
constant data structure?

If a data structure has mutable elements, it's not constant, and you
can't put it in write-protected memory -- unless the mutable elements
are disjoint.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Chris Croughton]

On 12 Jul 2005 05:00:45 -0700, Ma************@web.de
<Ma************@web.de> wrote:

Huh? If it's modifiable it can't be in write-protected memory,
obviously.

What do you do if a few mutable elements are embedded into a larger
constant data structure?

If an element can be changed then the structure isn't constant. Simple,
really.

Chris C

[Markus.Elfring]

> If a data structure has mutable elements, it's not constant, and you

can't put it in write-protected memory -- unless the mutable elements
are disjoint.

Do you distinguish between logical and physical constness?

Regards,
Markus

[Markus.Elfring]

> If a data structure has mutable elements, it's not constant, and you

can't put it in write-protected memory -- unless the mutable elements
are disjoint.

Do you distinguish between logical and physical constness?

Regards,
Markus

[Lawrence Kirby]

On Wed, 13 Jul 2005 05:38:05 -0700, Markus.Elfring wrote:

If a data structure has mutable elements, it's not constant, and you
can't put it in write-protected memory -- unless the mutable elements
are disjoint.

Do you distinguish between logical and physical constness?

In the context of whether a structure can be placed in write-protected
memory only physical constness matters. Logical constness is more natural
in the context of encapsulation provided e.g. by C++ classes because you
can hide the non-const bits and present an interface that appears const.
Of course you can do similar things in C, it is a question of how much
this helps in a normal/natural C coding style, whatever that is.

If you want to add mutable to C argue in terms of what value it would add
to the C language, not in terms of compatibility with C++ (although what
I'm replying to here doesn't do that).

Lawrence

[Markus.Elfring]

> If you want to add mutable to C argue in terms of what value it would add

to the C language, not in terms of compatibility with C++ (although what
I'm replying to here doesn't do that).

I would like to benefit from the capability to distinguish between
logical and physical constness in all data.
Is C++ the only (object-oriented) language that allows to specify that
something can never be constant?

Other (scripting) languages know only mutable/writeable structures by
default. Dynamic checks must be added there to make them appear like
"const" or "read-only".

Regards,
Markus

[Michael Mair]

Ma************@web.de wrote:

If you want to add mutable to C argue in terms of what value it would add
to the C language, not in terms of compatibility with C++ (although what
I'm replying to here doesn't do that).

I would like to benefit from the capability to distinguish between
logical and physical constness in all data.
Is C++ the only (object-oriented) language that allows to specify that
something can never be constant?

Other (scripting) languages know only mutable/writeable structures by
default. Dynamic checks must be added there to make them appear like
"const" or "read-only".

You can fake mutable to a certain degree.
Consider using indirection or const struct within struct (or, if
you must, casting away (const) depending on some flag or hard-coded).
Another possibility is creating appropriate interfaces which get
passed the structures (or pointers to them) as a whole as const and
non-const pointers to the mutable parts. If need be, you even can wrap
that up in some super-structure:
struct super
{
const struct payload *pc;
/* mutable list */
flagtype *internalstuff;
countertype *hiddencounter;
...
};
or, more generally,
struct gen_super {
const struct {unsigned char dummy;} *const_struct;
void *mutables;
}
with appropriate casting (note that pointers to struct types always
have the same size, representation and alignment requirements, so
casting from the dummy struct* type to the desired struct type pointer
is only evil to a limited degree).

However, I am not aware of any straightforward all-purpose pattern
for this.
Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.