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]

lovecreatesbeau ty 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]

"lovecreatesbea uty" <lo************ ***@gmail.comha scritto nel messaggio
news:11******** *************@s 13g2000cwa.goog legroups.com...

lovecreatesbeau ty 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******** ************@tw ister1.libero.i t...

>
"lovecreatesbea uty" <lo************ ***@gmail.comha scritto nel messaggio
news:11******** *************@s 13g2000cwa.goog legroups.com...

lovecreatesbeau ty 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.l earn.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_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.

[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.co m 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("Continu e? ");
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_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.