const integers

[Serve Laurijssen]

Theres a certain style of coding that uses const as much as possible.
Like

const int foo(const int a, const int b)
{
const int retval = pow(a, b);
return retval;
}

one argument to use code like this is that compilers can theoretically
optimize better.
Is that true? I thought that was only with pointers?

[lovecreatesbeauty]

Serve Laurijssen wrote:

const int foo(const int a, const int b)
{
const int retval = pow(a, b);
return retval;
}

I read an article and it prefers the following style.

const int foo(int a, int b){
cosnt aa = a;
cosnt bb = b;
int retval;

/*...*/

retval = pow(aa, bb);
return retval;
}

[lovecreatesbeauty]

lovecreatesbeauty wrote:

cosnt aa = a;
cosnt bb = b;

sorry, the code will be better with the changes,

cosnt int ca = a;
cosnt int cb = b;

[Giorgio Silvestri]

"lovecreatesbeauty" <lo***************@gmail.comha scritto nel messaggio
news:11*********************@s13g2000cwa.googlegro ups.com...

lovecreatesbeauty wrote:

cosnt aa = a;
cosnt bb = b;

sorry, the code will be better with the changes,

cosnt int ca = a;
cosnt int cb = b;

better:
const int ca = a;
const int cb = b;

:-)

Giorgio Silvestri

[Giorgio Silvestri]

"Giorgio Silvestri" <gi**************@libero.itha scritto nel messaggio
news:Dk********************@twister1.libero.it...

>
"lovecreatesbeauty" <lo***************@gmail.comha scritto nel messaggio
news:11*********************@s13g2000cwa.googlegro ups.com...

lovecreatesbeauty wrote:

cosnt aa = a;
cosnt bb = b;

sorry, the code will be better with the changes,

cosnt int ca = a;
cosnt int cb = b;

better:
const int ca = a;
const int cb = b;

Or with:

#define cosnt const

Giorgio Silvestri

[Frederick Gotham]

Serve Laurijssen posted:

Theres a certain style of coding that uses const as much as possible.

I myself have that style -- but with one exception: Return types.

Anything returned from a function is going to be an R-value in anyway, so
there's no need to add redundant words.

Here would be a sample function of mine:

int Func(int const a, int const b)
{
return a + b;
}
--

Frederick Gotham

[Jack Klein]

On Sun, 23 Jul 2006 16:22:41 +0200, "Serve Laurijssen" <se*@n.tk>
wrote in comp.lang.c:

Theres a certain style of coding that uses const as much as possible.
Like

const int foo(const int a, const int b)
{
const int retval = pow(a, b);
return retval;
}

one argument to use code like this is that compilers can theoretically
optimize better.
Is that true? I thought that was only with pointers?

A function argument, or a local automatic variable, cannot be changed
without the compiler's knowledge unless its address is passed to a
function. So even rudimentary data flow analysis would permit any
optimizations on such a variable with or without the const qualifier.

Some programmers like to use const on function arguments like this as
a reminder that they don't intend to change them. Perhaps down near
the end of the function, they expect them to have the original passed
value. Example:

int foo(const int a, const int b)
{
/* do stuff using current value of a and b */
/* finally... */
ret = pow(a, b);
return ret;
}

Now if they accidentally modify a or b before they get to the final
expression that uses them, the compiler will issue a diagnostic for a
constraint violation.

I rarely try to argue with someone who adds minimal extra typing to
catch errors in their code, but I don't care much for this idea
myself. If the function is large enough that you could modify a or b
and not be seen on a single display screen in the editor at the point
where the value is used later, the function is too large and effort
would better be spent splitting it up.

As for putting a const qualifier on a returned object, that's pretty
useless. You can return a non-const object from a function that
returns a const object, and you can assign a const object returned
from a function to a non-const object in the caller. I don't see how
it achieves anything at all.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Keith Thompson]

"Serve Laurijssen" <se*@n.tkwrites:

Theres a certain style of coding that uses const as much as possible.
Like

const int foo(const int a, const int b)
{
const int retval = pow(a, b);
return retval;
}

one argument to use code like this is that compilers can theoretically
optimize better.
Is that true? I thought that was only with pointers?

<OT>

One of my radical language design ideas is to make all declared
objects const by default. If you want to be able to modify an
object's value, you'd need to explicitly qualify it with, say, "var".

Thus:

int x = 10;
var int y = 20;
x ++; /* error */
y ++; /* ok */

I suspect that most declared objects actually don't change in value
once they're initialized. If my suspicion is correct, the result
would be safer code.

Of course, such a radical change would be inappropriate for C, and I'd
strongly oppose it if there were any chance of it being taken
seriously. But designers of new languages might want to consider it.

</OT>

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

[spibou]

Keith Thompson wrote:

<OT>

One of my radical language design ideas is to make all declared
objects const by default. If you want to be able to modify an
object's value, you'd need to explicitly qualify it with, say, "var".

Thus:

int x = 10;
var int y = 20;
x ++; /* error */
y ++; /* ok */

I suspect that most declared objects actually don't change in value
once they're initialized. If my suspicion is correct, the result
would be safer code.

Of course, such a radical change would be inappropriate for C, and I'd
strongly oppose it if there were any chance of it being taken
seriously. But designers of new languages might want to consider it.

</OT>

Isn't the same result achieved by declaring x as a macro ?
For example
#define x 10
in C. Most languages will have a similar construct and if the
programmer intends for the value to remain constant he/she
will pick that construct instead of one which allows for the value
to be changed. So how is your proposal different ?

Spiros Bousbouras

[Keith Thompson]

sp****@gmail.com writes:

Keith Thompson wrote:

><OT>

One of my radical language design ideas is to make all declared
objects const by default. If you want to be able to modify an
object's value, you'd need to explicitly qualify it with, say, "var".

Thus:

int x = 10;
var int y = 20;
x ++; /* error */
y ++; /* ok */

I suspect that most declared objects actually don't change in value
once they're initialized. If my suspicion is correct, the result
would be safer code.

Of course, such a radical change would be inappropriate for C, and I'd
strongly oppose it if there were any chance of it being taken
seriously. But designers of new languages might want to consider it.

</OT>

Isn't the same result achieved by declaring x as a macro ?
For example
#define x 10
in C. Most languages will have a similar construct and if the
programmer intends for the value to remain constant he/she
will pick that construct instead of one which allows for the value
to be changed. So how is your proposal different ?

In my (not very serious) proposal, objects would be read-only by
default, not necessarily constant in the sense of being computable
during compilation.

For example:

printf("Continue? ");
fflush(stdout);
int c = getchar();
if (c == 'y') {
...
}

In my hypothetical language, any attempt to modify c after
initializing it would be illegal, unless it's qualified with "var".

The problem this tries to address is that many objects are declared as
variables (without "const") even though they're never actually
modified.

(Again, I absolutely am not advocating making this change to C.)

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

[Mark McIntyre]

On Sun, 23 Jul 2006 20:05:55 GMT, in comp.lang.c , Keith Thompson
<ks***@mib.orgwrote:

><OT>

One of my radical language design ideas is to make all declared
objects const by default. If you want to be able to modify an
object's value, you'd need to explicitly qualify it with, say, "var".

Interesting, though fairly annoying. I find that the vast bulk of
variables I declare are.

>I suspect that most declared objects actually don't change in value
once they're initialized.

I'd be pretty surprised. Certainly its not my experience.

>If my suspicion is correct, the result
would be safer code.

I'm fairly unconvinced that lack of constness makes code 'unsafe'.

>...designers of new languages might want to consider it.

I have to say, I can't see why one would want to have variables which
were by default not variable. Why not use constants for that? :-)
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Keith Thompson]

Mark McIntyre <ma**********@spamcop.netwrites:

On Sun, 23 Jul 2006 20:05:55 GMT, in comp.lang.c , Keith Thompson
<ks***@mib.orgwrote:

>><OT>
One of my radical language design ideas is to make all declared
objects const by default. If you want to be able to modify an
object's value, you'd need to explicitly qualify it with, say, "var".

Interesting, though fairly annoying. I find that the vast bulk of
variables I declare are.

>>I suspect that most declared objects actually don't change in value
once they're initialized.

I'd be pretty surprised. Certainly its not my experience.

You may well be right; I haven't done any kind of in-depth study.

>>If my suspicion is correct, the result
would be safer code.

I'm fairly unconvinced that lack of constness makes code 'unsafe'.

Consider something like this:

char *s = "hello";
some_func(s);

If some_func() modified the string pointed to by s, the code is
unsafe. If s were a pointer to const char, this would be caught at
the point of the call.

>>...designers of new languages might want to consider it.

I have to say, I can't see why one would want to have variables which
were by default not variable. Why not use constants for that? :-)

I've added an "OT:" tag to the subject header. If this discussion
continues, we might want to take it to comp.lang.misc.

It's an idea I had some years ago in the context of a different
language, one that's more flexible than C in how objects can be
initialized (Ada).

In Ada, there are two kinds of objects: variables and constants.
Objects are the same as in C. Constants are objects declared with the
"constant" keyword, much like "const" in C. Variables are
non-constant objects.

My experience in Ada was that objects very commonly were initialized
to some desired value, and that value was never changed over the
lifetime of the object. I tried to declare objects with "constant"
whenever possible, giving a hint both to the compiler and to the
reader that they weren't going to change after the initial
declaration. My vague impression was that this was the case more
often than not, and that making objects constant by default might be
an improvement.

This may be less true for C than for Ada, for various reasons.

If I see a reference to an object, I can look at its declaration to
get more information about it. If it's declared const, I know that
the value at the point of reference is the same as the value in the
initializer. If it isn't, I have to understand the execution of the
program to figure out whether it might have been modified (and so does
the compiler, but that's a secondary issue).

Here's a trivial example: a swap routine:

void swap_int(int *x, int *y)
{
int tmp = *x;
*x = *y;
*y = tmp;
}

tmp is never modified after its initialization, but how many C
programmers would bother to declare it const?

In general, I tend to think that making the default more restrictive,
while allowing it to be relaxed explicitly, tends to make for cleaner
and safer code. YMMV.

To return to something vaguely approaching topicality, I suppose I'm
advocating more use of "const" for objects that don't change after
they're initialized.

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

[Frederick Gotham]

Keith Thompson posted:

if (c == 'y')

I'd get rid of the "==" for equality, and "=" for assignment.

--

Frederick Gotham

[Gordon Burditt]

> if (c == 'y')

>

I'd get rid of the "==" for equality, and "=" for assignment.

What would you suggest as a replacement?

'y' =: c;
for assignment, and
if (c :=: 'y') { ...
for equality?

Gordon L. Burditt

[Keith Thompson]

go***********@burditt.org (Gordon Burditt) writes:

>> if (c == 'y')

I'd get rid of the "==" for equality, and "=" for assignment.

What would you suggest as a replacement?

'y' =: c;
for assignment, and
if (c :=: 'y') { ...
for equality?

Frederick Gotham <fg*******@SPAM.comwrote the "I'd get rid of" line
above. The "if (c == 'y')" is quoted from something I wrote.

Gordon, please let us know when you've gotten more complaints for
snipping attributions than you claim to have gotten in the past for
including them. Or just stop being offensively rude and acknowledge
the people you're quoting. Would it help if I threatened a lawsuit?

If I were designing a new language from scratch, I'd probably use ":="
for assignment and "=" for equality. There are other possibilities,
of course, but the one thing I'd avoid is using a symbol for
assignment that other languages (and ordinary mathematical notation)
use for equality, at least in a language where both can be used in the
same context.

I might also consider ":=" for assignment and "==" for comparison,
leaving the bare "=" unused.

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

[lovecreatesbeauty]

Keith Thompson wrote:

One of my radical language design ideas is to make all declared
objects const by default. If you want to be able to modify an
object's value, you'd need to explicitly qualify it with, say, "var".

Thus:

int x = 10;
var int y = 20;
x ++; /* error */
y ++; /* ok */

This does not sound like a good idea.

I suspect that most declared objects actually don't change in value
once they're initialized. If my suspicion is correct, the result
would be safer code.

Does not any object have an initial value (a determinate value or a
random one) at the point of time of their definition?

[Keith Thompson]

"lovecreatesbeauty" <lo***************@gmail.comwrites:

Keith Thompson wrote:

>One of my radical language design ideas is to make all declared
objects const by default. If you want to be able to modify an
object's value, you'd need to explicitly qualify it with, say, "var".

Thus:

int x = 10;
var int y = 20;
x ++; /* error */
y ++; /* ok */

This does not sound like a good idea.

You could be right.

>I suspect that most declared objects actually don't change in value
once they're initialized. If my suspicion is correct, the result
would be safer code.

Does not any object have an initial value (a determinate value or a
random one) at the point of time of their definition?

An automatic (local) object with no explicit initializer has an
indeterminate value. A hypothetical language that incorporated my
suggestion would probably have to require any non-var object to have
an explicit initializer.

(I had assumed that C required an initializer for a const object, but
apparently it doesn't. For example, this:
const int x;
appears to be legal.)

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

[Gordon Burditt]

>>> if (c == 'y')

>>>

I'd get rid of the "==" for equality, and "=" for assignment.

What would you suggest as a replacement?

'y' =: c;
for assignment, and
if (c :=: 'y') { ...
for equality?

Frederick Gotham <fg*******@SPAM.comwrote the "I'd get rid of" line
above. The "if (c == 'y')" is quoted from something I wrote.

Gordon, please let us know when you've gotten more complaints for
snipping attributions than you claim to have gotten in the past for
including them. Or just stop being offensively rude and acknowledge
the people you're quoting. Would it help if I threatened a lawsuit?

Misattribution is far worse than being rude. (So are libel, slander,
genocide, and spamming.) Even the possibility of misattribution
is far worse than being rude, and people in this newsgroup regularly
get it wrong and draw complaints about it. Speaking of rude, so
is posting an article that consists entirely of discussions of
attributions, top-posting, Google, trolls, and topicality.

The attribution cabal has raised the bar on correct attibutions
high enough that I have no chance of getting it right consistently:
just not deleting the attributions and letting my newsreader do its
thing with the attributions is NOT sufficient, contrary to prior
claims of some of them, and several complaints of misattribution
not involving any post of mine in the last couple of months have
been due to this. And getting attributions right requires that the
attributions in the article I'm replying to are right, something
which doesn't always hold true.

This is USENET. There is no identity here, so the whole idea that
attributions (or even From: lines) are worth reading seems pretty
silly.

If I were designing a new language from scratch, I'd probably use ":="

for assignment and "=" for equality. There are other possibilities,
of course, but the one thing I'd avoid is using a symbol for
assignment that other languages (and ordinary mathematical notation)
use for equality, at least in a language where both can be used in the
same context.

I might also consider ":=" for assignment and "==" for comparison,

leaving the bare "=" unused.

This I consider a better choice, since a bare = now has two common
meanings, equality in mathematics and assignment in quite a few
programming languages including C.

Gordon L. Burditt

[Keith Thompson]

go***********@burditt.org (Gordon Burditt) writes:

I wrote:

>>Gordon, please let us know when you've gotten more complaints for
snipping attributions than you claim to have gotten in the past for
including them. Or just stop being offensively rude and acknowledge
the people you're quoting. Would it help if I threatened a lawsuit?

Misattribution is far worse than being rude.

Not really.

(So are libel, slander,
genocide, and spamming.) Even the possibility of misattribution
is far worse than being rude, and people in this newsgroup regularly
get it wrong and draw complaints about it.

I rarely see such a problem here, and any complaints about it have
been mild and responded to quickly. Serious complaints would occur
only if a misattribution were deliberate, but I don't recall ever
seeing such a thing here. There have been some cases of deliberately
altered quotations; the offenders where thoroughly flamed.

There have been some cases, and some complaints, about people who have
deleted deeply quoted text without deleting the corresponding
attribution line. This is a minor mistake, and avoiding it just
requires a little attention. Most of us get it right 99% of the time,
and getting it wrong isn't that much of a problem.

Speaking of rude, so
is posting an article that consists entirely of discussions of
attributions, top-posting, Google, trolls, and topicality.

Which I have not done here -- but in any case, meta-discussions about
topicality are, by convention, considered to be topical.

The attribution cabal has raised the bar on correct attibutions
high enough that I have no chance of getting it right consistently:
just not deleting the attributions and letting my newsreader do its
thing with the attributions is NOT sufficient, contrary to prior
claims of some of them, and several complaints of misattribution
not involving any post of mine in the last couple of months have
been due to this. And getting attributions right requires that the
attributions in the article I'm replying to are right, something
which doesn't always hold true.

You exaggerate.

If you quote another article with incorrect attributions, nobody is
going to blame you for the previous poster's error.

This is USENET. There is no identity here, so the whole idea that
attributions (or even From: lines) are worth reading seems pretty
silly.

Nonsense. We know each other by our names (real or not) and by our
posting histories. There are some people here I take more seriously
than others.

If you're going to base your decision on the number of complaints,
note that I'm not the only one who finds your posting style offensive
-- and hardly anyone has seriously defended you.

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

[Richard Heathfield]

Gordon Burditt quoted Keith Thompson as saying:
<snip>

>>
Gordon, please let us know when you've gotten more complaints for
snipping attributions than you claim to have gotten in the past for
including them. Or just stop being offensively rude and acknowledge
the people you're quoting. Would it help if I threatened a lawsuit?

but failed to attribute it.

Gordon Burditt replied:

Misattribution is far worse than being rude.

Lack of attribution /is/ misattribution, so please stop doing it.

<snip>

Even the possibility of misattribution is far worse than being rude,

Failing to attribute constitutes incorrect attribution.

and people in this newsgroup regularly
get it wrong and draw complaints about it.

Consider this a complaint at your failure to get attributions right.

Speaking of rude, so is posting an article that consists entirely
of discussions of attributions, top-posting, Google, trolls, and
topicality.

If you attributed correctly, we wouldn't be discussing it, would we?

The attribution cabal

There is no cabal. This is widely known.

has raised the bar on correct attibutions
high enough that I have no chance of getting it right consistently:

You are getting it /wrong/ consistently.

<snip>

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Flash Gordon]

Richard Heathfield wrote:

<snip Gordon Burditt failing to attribute correctly>

>Even the possibility of misattribution is far worse than being rude,

Failing to attribute constitutes incorrect attribution.

This is another complaint. I agree with everything Richard Heathfield
and Keith Thompson have said on this topic.
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc

[jaysome]

On Mon, 24 Jul 2006 01:27:55 GMT, Keith Thompson <ks***@mib.org>
wrote:

[snip]

>If I were designing a new language from scratch, I'd probably use ":="
for assignment and "=" for equality.

Which is what Ada uses. Having used both Ada and C extensively, I
agree with you. Making such a change would break some code, but not in
a universal way. Some like to do this:

while ((EOF != (ch = getc(f))) && ('\n' != ch)) {

while others like to do this:

ch = getc(f);
while ( (ch != EOF) && (ch != '\n') )
{

One would break, one wouldn't.

--
jay

[Ian Collins]

Richard Heathfield wrote:

Gordon Burditt quoted Keith Thompson as saying:
<snip>

>>>Gordon, please let us know when you've gotten more complaints for
snipping attributions than you claim to have gotten in the past for
including them. Or just stop being offensively rude and acknowledge
the people you're quoting. Would it help if I threatened a lawsuit?

but failed to attribute it.

Gordon Burditt replied:

>>Misattribution is far worse than being rude.

Lack of attribution /is/ misattribution, so please stop doing it.

<snip>

>>Even the possibility of misattribution is far worse than being rude,

Failing to attribute constitutes incorrect attribution.

>>and people in this newsgroup regularly
get it wrong and draw complaints about it.

Consider this a complaint at your failure to get attributions right.

This is yet another complaint. Attributions are important, not just here
but elsewhere on Usenet.

I also agree with everything Richard Heathfield and Keith Thompson have
said on this topic.

--
Ian Collins.

[Keith Thompson]

jaysome <ja*****@spamcop.netwrites:

On Mon, 24 Jul 2006 01:27:55 GMT, Keith Thompson <ks***@mib.org>
wrote:

[snip]

>>If I were designing a new language from scratch, I'd probably use ":="
for assignment and "=" for equality.

Which is what Ada uses. Having used both Ada and C extensively, I
agree with you. Making such a change would break some code, but not in
a universal way. Some like to do this:

while ((EOF != (ch = getc(f))) && ('\n' != ch)) {

while others like to do this:

ch = getc(f);
while ( (ch != EOF) && (ch != '\n') )
{

One would break, one wouldn't.

I think you missed my point. I was talking using ":=" rather than "="
for assignment, and "=" rather than "==" for equality. Based on your
examples, I think you're talking not treating assignments as
expressions, but as a kind of statement (something Ada also does).
That change, assuming we keep the "=" symbol for assignment, would
break your first example but not your second.

For the record, I would strongly oppose making either change to C.
Making assignments illegal in expressions would break a great deal of
C source code that's currently perfectly valid; changing such code, in
addition to being a waste of time, would undoubtedly introduce bugs.
Making "=" denote equality rather than comparison would *quietly*
break almost every C program in existence; it would continue to
compile, but would stop working.

As I said, these are things I'd consider doing if I were designing a
new language from scratch. (Don't worry, folks, I don't have any
plans to do so.)

<OT>
Well, that's not *quite* true. I did invent the "99" language
for www.99-bottles-of-beer.net.
</OT>

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

[Mark McIntyre]

On Sun, 23 Jul 2006 23:28:50 GMT, in comp.lang.c , Keith Thompson
<ks***@mib.orgwrote:

>Mark McIntyre <ma**********@spamcop.netwrites:

>>
I'm fairly unconvinced that lack of constness makes code 'unsafe'.

Consider something like this:

char *s = "hello";
some_func(s);

If some_func() modified the string pointed to by s, the code is
unsafe. If s were a pointer to const char, this would be caught at
the point of the call.

Mhm, indeed. Mind you thats a fairly unusual example, since strings
are the only data type with a subclass which is secretly constant. Its
harder to get that sort of error with doubles or ints.

>I have to say, I can't see why one would want to have variables which
were by default not variable. Why not use constants for that? :-)

I've added an "OT:" tag to the subject header. If this discussion
continues, we might want to take it to comp.lang.misc.

Indeed, you're right, lets drop it.

>Here's a trivial example: a swap routine:

void swap_int(int *x, int *y)
{
int tmp = *x;
*x = *y;
*y = tmp;
}

tmp is never modified after its initialization, but how many C
programmers would bother to declare it const?

Very few I expect. But then its not *really* a constant - consider:

swap(p, q);
swap(r,s);

I guess the point is that its dangerous to generalise :-)

>To return to something vaguely approaching topicality, I suppose I'm
advocating more use of "const" for objects that don't change after
they're initialized.

Can't argue with that.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Mark McIntyre]

On Mon, 24 Jul 2006 04:04:48 +0000, in comp.lang.c , Richard
Heathfield <in*****@invalid.invalidwrote:

>
You are getting it /wrong/ consistently.

For the record, I agree with Richard.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Keith Thompson]

Mark McIntyre <ma**********@spamcop.netwrites:

On Sun, 23 Jul 2006 23:28:50 GMT, in comp.lang.c , Keith Thompson
<ks***@mib.orgwrote:

[...]

>>I've added an "OT:" tag to the subject header. If this discussion
continues, we might want to take it to comp.lang.misc.

Indeed, you're right, lets drop it.

I'm dropping the discussion of the hypothetical language change, but
....

>>Here's a trivial example: a swap routine:

void swap_int(int *x, int *y)
{
int tmp = *x;
*x = *y;
*y = tmp;
}

tmp is never modified after its initialization, but how many C
programmers would bother to declare it const?

Very few I expect. But then its not *really* a constant - consider:

swap(p, q);
swap(r,s);

It's certainly not constant (in the sense used by the C standard), but
it certainly is, or could be, const, i.e., read-only. The object
"tmp" doesn't have its value modified after its initialization. The
two calls to swap() create two distinct objects, both called "tmp".

You could change
int tmp = *x;
to
const int tmp = *x;
and the compiler wouldn't complain.

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

[Michael Wojcik]

In article <ln************@nuthaus.mib.org>, Keith Thompson <ks***@mib.orgwrites:

<OT>

One of my radical language design ideas is to make all declared
objects const by default. If you want to be able to modify an
object's value, you'd need to explicitly qualify it with, say, "var".

...

Of course, such a radical change would be inappropriate for C, and I'd
strongly oppose it if there were any chance of it being taken
seriously. But designers of new languages might want to consider it.

</OT>

Sheer liberalism, I call it. In Erlang, for example, all "variables"
are const; their values can never change once they've been assigned.
Now that's a bit of rigor.

Of course, Erlang is designed for writing programs that are largely
correct and free of bugs, which makes it unsuitable for general
software development.

--
Michael Wojcik mi************@microfocus.com

Most people believe that anything that is true is true for a reason.
These theorems show that some things are true for no reason at all,
i.e., accidentally, or at random. -- G J Chaitin

[Jack Klein]

On Mon, 24 Jul 2006 01:13:00 -0000, go***********@burditt.org (Gordon
Burditt) wrote in comp.lang.c:
[yet another reply without attribution or a proper signature line]

Your persistent rudeness is getting very tiresome.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Jack Klein]

On Mon, 24 Jul 2006 02:27:36 -0000, go***********@burditt.org (Gordon
Burditt) wrote in comp.lang.c:

[snip]

The attribution cabal has raised the bar on correct attibutions
high enough that I have no chance of getting it right consistently:
just not deleting the attributions and letting my newsreader do its
thing with the attributions is NOT sufficient, contrary to prior
claims of some of them

[snip]

Perhaps you need a better newsreader? And how does your attribution
phobia excuse failure to use a proper signature delimiter?

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Richard Bos]

mw*****@newsguy.com (Michael Wojcik) wrote:

In article <ln************@nuthaus.mib.org>, Keith Thompson <ks***@mib.orgwrites:

<OT>

One of my radical language design ideas is to make all declared
objects const by default. If you want to be able to modify an
object's value, you'd need to explicitly qualify it with, say, "var".

Sheer liberalism, I call it. In Erlang, for example, all "variables"
are const; their values can never change once they've been assigned.
Now that's a bit of rigor.

Must make it really... interesting... to write a useful summation loop.

Richard

[Richard Heathfield]

Richard Bos said:

mw*****@newsguy.com (Michael Wojcik) wrote:

>In article <ln************@nuthaus.mib.org>, Keith Thompson
<ks***@mib.orgwrites:

<OT>

One of my radical language design ideas is to make all declared
objects const by default. If you want to be able to modify an
object's value, you'd need to explicitly qualify it with, say, "var".

>Sheer liberalism, I call it. In Erlang, for example, all "variables"
are const; their values can never change once they've been assigned.
Now that's a bit of rigor.

Must make it really... interesting... to write a useful summation loop.

Hardly. Here it is in C:

unsigned long sum(unsigned long *p, size_t n)
{
return (n 1) ? (sum(p, n / 2) +
sum(p + n / 2, n / 2) +
((n % 2) ? p[n - 1] : 0))
: p[0];
}

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Chris Dollin]

Richard Bos wrote:

mw*****@newsguy.com (Michael Wojcik) wrote:

>In article <ln************@nuthaus.mib.org>, Keith Thompson <ks***@mib.orgwrites:

<OT>

One of my radical language design ideas is to make all declared
objects const by default. If you want to be able to modify an
object's value, you'd need to explicitly qualify it with, say, "var".

>Sheer liberalism, I call it. In Erlang, for example, all "variables"
are const; their values can never change once they've been assigned.
Now that's a bit of rigor.

Must make it really... interesting... to write a useful summation loop.

What are these "loops" of which you speak?

[OK, I admit it, I haven't looked to see if Erlang has loops. But, you
know, it might not: loops are just a combination of syntactic sugar
and an optimisation feature of imperative languages.]

--
Chris "seeker" Dollin
This .signature temporarily left blank.

[Richard Bos]

Chris Dollin <ch**********@hp.comwrote:

Richard Bos wrote:

mw*****@newsguy.com (Michael Wojcik) wrote:

In article <ln************@nuthaus.mib.org>, Keith Thompson <ks***@mib.orgwrites:
<OT>

One of my radical language design ideas is to make all declared
objects const by default. If you want to be able to modify an
object's value, you'd need to explicitly qualify it with, say, "var".

Sheer liberalism, I call it. In Erlang, for example, all "variables"
are const; their values can never change once they've been assigned.
Now that's a bit of rigor.

Must make it really... interesting... to write a useful summation loop.

What are these "loops" of which you speak?

[OK, I admit it, I haven't looked to see if Erlang has loops. But, you
know, it might not: loops are just a combination of syntactic sugar
and an optimisation feature of imperative languages.]

Well, Erlang might be a strictly functional language, in which case it
does indeed not have loops. But then, I stand by my comment; I find
writing code that is both legible and efficient in strictly functional
languages definitely interesting, in the Chinese-proverb sense.

Richard

[Chris Dollin]

Richard Bos wrote:

Chris Dollin <ch**********@hp.comwrote:

>Richard Bos wrote:

Must make it really... interesting... to write a useful summation loop.

What are these "loops" of which you speak?

[OK, I admit it, I haven't looked to see if Erlang has loops. But, you
know, it might not: loops are just a combination of syntactic sugar
and an optimisation feature of imperative languages.]

Well, Erlang might be a strictly functional language, in which case it
does indeed not have loops. But then, I stand by my comment; I find
writing code that is both legible and efficient in strictly functional
languages definitely interesting, in the Chinese-proverb sense.

If I remember correctly, Erlang isn't strictly functional - it has
state, although you can write a lot of stuff without it. (The same
is true of ML.)

Functional languages will be efficient competitors with imperative
languages (of which OO languages are a subset) in the near future.

Whether this is the same near future that holds commercial fusion
power and the paperless office I wouldn't like to say.

--
Chris "still functional after all these years" Dollin
"Who do you serve, and who do you trust?" /Crusade/

[Tak-Shing Chan]

On Tue, 25 Jul 2006, Chris Dollin wrote:

Richard Bos wrote:

>mw*****@newsguy.com (Michael Wojcik) wrote:

>>In article <ln************@nuthaus.mib.org>, Keith Thompson <ks***@mib.orgwrites:
<OT>

One of my radical language design ideas is to make all declared
objects const by default. If you want to be able to modify an
object's value, you'd need to explicitly qualify it with, say, "var".

>>Sheer liberalism, I call it. In Erlang, for example, all "variables"
are const; their values can never change once they've been assigned.
Now that's a bit of rigor.

Must make it really... interesting... to write a useful summation loop.

What are these "loops" of which you speak?

[OK, I admit it, I haven't looked to see if Erlang has loops. But, you
know, it might not: loops are just a combination of syntactic sugar
and an optimisation feature of imperative languages.]

One can certainly write such a summation ``loop'' by
recursion:

#include <stdio.h>

int f(const int *x) {
return (*x != EOF) ? *x + f(x + 1) : 0;
}

int main(void) {
const int a[] = {1, 2, 3, EOF}, b[] = {4, 5, 6, EOF};
printf("The sum of a is %d.\n", f(a));
printf("The sum of b is %d.\n", f(b));
return 0;
}

Note that all objects above are not modifiable.

Tak-Shing

[Michael Wojcik]

In article <44*****************@news.xs4all.nl>, rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:

mw*****@newsguy.com (Michael Wojcik) wrote:

Sheer liberalism, I call it. In Erlang, for example, all "variables"
are const; their values can never change once they've been assigned.
Now that's a bit of rigor.

Must make it really... interesting... to write a useful summation loop.

Interesting is in the eye of the beholder, I suppose, but:

sum([]) -0;
sum([First | Rest]) -First + sum(Rest).

Erlang's a functional language, so looping is typically implemented
with recursion. If you prefer the tail-recursive version:

sum_r([], N) -N;
sum_r([First | Rest], N) -sum_r(Rest, First + N).
sum(List) -sum_r(List, 0).

NB. I actually know very little about Erlang - I've just read some
docs and played around with it a bit. Those two seem to work, though.

--
Michael Wojcik mi************@microfocus.com

Couldn't "scotomisation" be defined as the removal from one's kernel
of any code belonging to the Santa Cruz Operation, Caldera, or their
heirs and assigns? -- "skotizo"

[Keith Thompson]

Chris Dollin <ch**********@hp.comwrites:
[...]

Functional languages will be efficient competitors with imperative
languages (of which OO languages are a subset) in the near future.

Whether this is the same near future that holds commercial fusion
power and the paperless office I wouldn't like to say.

Good news: We've instituted a paperless office policy.

Bad news: We're starting wih the restrooms.

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

[Mark McIntyre]

Following up my own post, I was most interested to notice an article
on The Register dated today, dealing with this very topic and indeed
discussing and advocating some of the same solutions. Methinks theres
a secret journo amongst us...

http://www.regdeveloper.co.uk/2006/0...tants_are_not/

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Frederick Gotham]

Mark McIntyre posted:

>
Following up my own post, I was most interested to notice an article
on The Register dated today, dealing with this very topic and indeed
discussing and advocating some of the same solutions. Methinks theres
a secret journo amongst us...

http://www.regdeveloper.co.uk/2006/0...tants_are_not/

Not worth the paper it's printed on.

It's possible to invoke Undefined Behaviour in C++ -- one should accept that
before writing such an article.

--

Frederick Gotham

[Michael Wojcik]

In article <wg*******************@news.indigo.ie>, Frederick Gotham <fg*******@SPAM.comwrites:

Mark McIntyre posted:

http://www.regdeveloper.co.uk/2006/0...tants_are_not/

Not worth the paper it's printed on.

It's possible to invoke Undefined Behaviour in C++ -- one should accept that
before writing such an article.

You have entirely missed the point of the article, which is that
one particular expectation that some (particularly inexperienced)
programmers may have about C++ is unfounded; and that another
related expectation (regarding the mutability of constant strings)
was cultivated some time back but is now invalid in the environment
where it was once promoted.

These are important lessons. They may be ones you have already
learned, but that makes them no less important. This article conveys
them in a clear and succint manner; is it impossible that some reader
might thereby be informed?

The myth that all the world's a PC is pernicious, but not, perhaps,
as pernicious as the myth that all programmers are oneself.

--
Michael Wojcik mi************@microfocus.com

Proverbs for Paranoids, 2: The innocence of the creatures is in inverse
proportion to the immorality of the Master. -- Thomas Pynchon

[ena8t8si]

Mark McIntyre wrote:

On Sun, 23 Jul 2006 23:28:50 GMT, in comp.lang.c , Keith Thompson
<ks***@mib.orgwrote:

Mark McIntyre <ma**********@spamcop.netwrites:

>
I'm fairly unconvinced that lack of constness makes code 'unsafe'.

Consider something like this:

char *s = "hello";
some_func(s);

If some_func() modified the string pointed to by s, the code is
unsafe. If s were a pointer to const char, this would be caught at
the point of the call.

Mhm, indeed. Mind you thats a fairly unusual example, since strings
are the only data type with a subclass which is secretly constant. Its
harder to get that sort of error with doubles or ints.

That's because double/int literals are values and can't
be turned into objects (eg, by taking their address).
String literals are different because they are objects.
No one would complain if the type of 7 were const int
rather than int.