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 "correctness" 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]

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.

 

[=?iso-8859-1?q?Stephan_Br=F6nnimann?=]

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 "correctness" 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.

 

[CBFalconer]

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.

 

[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]

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 "constructor" (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(the_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(the_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(struct s *sp) {
...
free((char*)(sp->name));
free(sp);
}

 

[CBFalconer]

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.

 

[CBFalconer]

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.

 

[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

 

[Keith Thompson]

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

Your original post was off-topic in comp.lang.c because it was about
C++, not because it was about "const correctness".

I haven't redirected followups on this article, but please be cautious
in posting; cross-posting to comp.lang.c and comp.lang.c++ is rarely
appropriate.

If you want to discuss const correctness in the context of C, feel
free to do so. Just start a new thread.

Please post followups with proper quoting and attributions, or don't
bother posting at all. You recently posted a followup quoting
something I wrote, but you didn't mention that I wrote it. That's
considered rude (as is overriding followups).

I just did a search using groups.google.com, and found 450 occurrences
of the following advice in this newsgroup:

If you want to post a followup via groups.google.com, 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.

and I don't think that even counts CBFalconer's use of it as his
signature.

Pay attention.

 

[Dave Thompson]

On Mon, 18 Jul 2005 08:34:06 -0400, Eric Sosman

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

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

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

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

No good way. Technically you could do:
free ( strchr (sp->name, sp->name[0]) )
or if you hadn't made sure it was a valid string
free ( memchr (sp->name, sp->name[0], 1) );
but I (emphatically) don't recommend it.

- David.Thompson1 at worldnet.att.net