const-incorrect practice

[Markus.Elfring]

A couple of software provides const-incorrect programming interfaces. I
guess that it is possible to develop const-correct APIs/SDKs from the
beginning if a few basic design rules and patterns would be considered.
How difficult is it for beginners to make it right and to get used to
this kind of programming style?
How much do you need to fiddle with "const_cast " because the key word
"const" was forgotten for type specifiers in important cases by an API
designer?

It seems that there exist strong different opinions when this technique
becomes a valuable tool for the detection of security flaws and the
improvement of the overall source code quality. Does the experience
change over time to achieve a common sense?
Do developers and programmers need key/success stories like compiler
optimisations and error avoidance to give "correctnes s" a try and to
let it become a common practice?
Do you want to show that the maintenance effort is worth for the
implementation way of immutable data structures?
http://en.wikipedia.org/wiki/Const_correctness

Regards,
Markus

[Keith Thompson]

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

How much do you need to fiddle with "const_cast " because the key word
"const" was forgotten for type specifiers in important cases by an API
designer?

C has no "const_cast ". Followups redirected.

--
Keith Thompson (The_Other_Keit h) 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.

[Stephan Brönnimann]

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

A couple of software provides const-incorrect programming interfaces. I
guess that it is possible to develop const-correct APIs/SDKs from the
beginning if a few basic design rules and patterns would be considered.
How difficult is it for beginners to make it right and to get used to
this kind of programming style?
Not difficult at all:
Just define that unless needed all member functions are const,
and, with very few exceptions, do not allow the use of const_cast
and/or mutable.

There are a few situations how the const-correctness can be violated,
all of them returning non-const references or pointers
from const functions. E.g.,

class Class {
// constructor, copy, assigment, destructor ommitted.
public:
int& getInt() const
{
return *i_;
}
private:
int* i_;
};

void foo(const Class& c)
{
c.getInt() = 5;
}

will compile happily on most compilers.
How much do you need to fiddle with "const_cast " because the key word
"const" was forgotten for type specifiers in important cases by an API
designer?
I don't remember any case where I needed to const_cast because of an
API.

It seems that there exist strong different opinions when this technique
becomes a valuable tool for the detection of security flaws and the
improvement of the overall source code quality. Does the experience
change over time to achieve a common sense?
Do developers and programmers need key/success stories like compiler
optimisations and error avoidance to give "correctnes s" a try and to
let it become a common practice?
Do you want to show that the maintenance effort is worth for the
implementation way of immutable data structures?
http://en.wikipedia.org/wiki/Const_correctness
Not so much the maintenance effort. The big benefit comes when it is
about
problem hunting: If a function takes a const argument, there's no need
to follow the "path" of the argument through the function, provided
const_cast is not used.

Regards,
Markus

[CBFalconer]

Stephan Brönnimann wrote:

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

A couple of software provides const-incorrect programming interfaces. I
guess that it is possible to develop const-correct APIs/SDKs from the
beginning if a few basic design rules and patterns would be considered.
How difficult is it for beginners to make it right and to get used to
this kind of programming style?

Not difficult at all:
Just define that unless needed all member functions are const,
and, with very few exceptions, do not allow the use of const_cast
and/or mutable.

There are a few situations how the const-correctness can be violated,
all of them returning non-const references or pointers
from const functions. E.g.,

class Class {
// constructor, copy, assigment, destructor ommitted.
public:
int& getInt() const
{
return *i_;
}
private:
int* i_;

Please do not post this off-topic stuff to c.l.c.

--
"If you want to post a followup via groups.google.c om, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson

[Markus.Elfring]

> C has no "const_cast ". Followups redirected.

How often do you need to cast constness away?

[Markus.Elfring]

> Please do not post this off-topic stuff to c.l.c.

Are any use cases for the demonstration of "const correctness" really
"off-topic" to this discussion?

[Eric Sosman]

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

How often do you need to cast constness away?

Fairly frequently when writing encapsulated data
types in C. I'll have a struct like

struct s {
const char *name;
...
};

.... and a "constructo r" (I guess "factory method" might
be a better term for what we have in C) that does

struct s *sp = malloc(sizeof *sp);
sp->name = malloc(strlen(t he_name) + 1);
strcpy((char*)( sp->name), the_name);
...

Now, one doesn't actually "need" the const-removing
cast for this. A cast-less alternative can be written as

struct s *sp = malloc(sizeof *sp);
char *name = malloc(strlen(t he_name) + 1);
strcpy(name, the_name);
sp->name = name;
...

However, I see no way to avoid the cast in the
matching "destructor :"

void destroy_s(struc t s *sp) {
...
free((char*)(sp->name));
free(sp);
}

--
Eric Sosman
es*****@acm-dot-org.invalid

[CBFalconer]

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

C has no "const_cast ". Followups redirected.

How often do you need to cast constness away?

Why did you override the follow-up? Are you deliberately trying to
annoy the readers of c.l.c? Why did you remove the attributions?
You are showing many signs of being a troll.

--
Chuck F (cb********@yah oo.com) (cb********@wor ldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net> USE worldnet address!

[CBFalconer]

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

Please do not post this off-topic stuff to c.l.c.

Are any use cases for the demonstration of "const correctness"
really "off-topic" to this discussion?

Again deliberately overriding the preset follow-ups. Definitely a
troll. PLONK.

--
Chuck F (cb********@yah oo.com) (cb********@wor ldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net> USE worldnet address!

[Markus.Elfring]

> Why did you override the follow-up? Are you deliberately trying to

annoy the readers of c.l.c? Why did you remove the attributions?

I assumed that somebody from c.l.c++ want to share experiences for the
discussion.
Is there an updated consideration on topics like "What Value Does Const
Correctness Offer" from both groups possible?

Regards,
Markus