By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
457,734 Members | 832 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 457,734 IT Pros & Developers. It's quick & easy.

mutable data structures

P: n/a
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

Nov 15 '05 #1
Share this Question
Share on Google+
18 Replies


P: n/a
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 \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Nov 15 '05 #2

P: n/a
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
Nov 15 '05 #3

P: n/a
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 ---
Nov 15 '05 #4

P: n/a


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

Nov 15 '05 #5

P: n/a
> 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

Nov 15 '05 #6

P: n/a
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
Nov 15 '05 #7

P: n/a
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
Nov 15 '05 #8

P: n/a
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
Nov 15 '05 #9

P: n/a
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 \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Nov 15 '05 #10

P: n/a
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 \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Nov 15 '05 #11

P: n/a
> 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

Nov 15 '05 #12

P: n/a
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.
Nov 15 '05 #13

P: n/a
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
Nov 15 '05 #14

P: n/a
> 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

Nov 15 '05 #15

P: n/a
> 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

Nov 15 '05 #16

P: n/a
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
Nov 15 '05 #17

P: n/a
> 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

Nov 15 '05 #18

P: n/a
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.
Nov 15 '05 #19

This discussion thread is closed

Replies have been disabled for this discussion.