Hi,

I'm litle confused by the const modifier, particularly when use const
char* or char*.
Some dude over here said it should be const char when you dont modify
it content inside the function, I read somewhere that it when you
won't modify after its initialization...

So when exactly do I use one or another? Is it *wrong* not use const
when I should?

thanks in advance.
Leonardo.

Leonardo Korndorfer wrote:
> Hi,
>
> I'm litle confused by the const modifier, particularly when use const
> char* or char*.
> Some dude over here said it should be const char when you dont modify
> it content inside the function, I read somewhere that it when you
> won't modify after its initialization...
>
Both.

> So when exactly do I use one or another? Is it *wrong* not use const
> when I should?
>
Not using const is only a problem when the object is a real constant,
like a string literal.

I other cases, const expresses an intent.

--
Ian Collins.

Leonardo Korndorfer wrote:

> Hi,
>
> I'm litle confused by the const modifier, particularly when use const
> char* or char*.
> Some dude over here said it should be const char when you dont modify
> it content inside the function,

Const qualifying a function parameter will the compiler diagnose
any attempt to modify the concerned object within the function.

> I read somewhere that it when you
> won't modify after its initialization...

The behaviour is the same here.

> So when exactly do I use one or another?

That depends on how the object will be used. If the object will only be
initialised and not modified thereafter then you can const qualify it's
declaration. If OTOH you want only certain functions to not modify an
array object, you can const qualify the relevant parameter. This way
other functions can still modify the array. An alternative is to wrap
the array inside a structure before passing it to the function. But
this will not you catch inadvertent modifications, which is the
main use of const.

> Is it *wrong* not use const
> when I should?

No. But it's ful to take advantage of language features to make your
job easier.

Ian Collins wrote:

> Leonardo Korndorfer wrote:
>> Hi,
>>
>> I'm litle confused by the const modifier, particularly when use const
>> char* or char*.
>> Some dude over here said it should be const char when you dont modify
>> it content inside the function, I read somewhere that it when you
>> won't modify after its initialization...
>>
> Both.
>
>> So when exactly do I use one or another? Is it *wrong* not use const
>> when I should?
>>
> Not using const is only a problem when the object is a real constant,
> like a string literal.

Are string literals "real constants", whatever that means? I thought you
were just supposed to pretend that they were constants, and treat them
as such, to prevent the wrath of UB.

santosh wrote:
> Ian Collins wrote:
>> Leonardo Korndorfer wrote:
>>> I'm litle confused by the const modifier, particularly when use const
>
> Are string literals "real constants", whatever that means? I thought you
> were just supposed to pretend that they were constants, and treat them
> as such, to prevent the wrath of UB.
>

Here, C's subtle goals for portability surface. Some memory pages are
marked read-only. Any attempted write to a read-only page by a user mode
program [contrasted with supervisor mode running the OS's kernel] will
result in an interrupt raised by the Memory Management Unit [MMU], the
part of the CPU that translates virtual addresses to physical addresses.
This interrupt notifies the kernel your program is behaving badly. The
default behavior in this case is an abrupt termination known as a "core
dump."

Executable files produced by modern linkers are partitioned into
segments. The ".data" segment is expected to be read-only and *may* be
mapped to a read-only page in virtual memory. Attempting to write it
results in the above behavior. This is the meaning of "real constant":
the hardware and OS will not permit you to write it after the loader
brings that segment into memory and protects the page. String literals
are typically placed in the ".data" segment, so treat them as "real
constants."

This differs somewhat from use of the 'const' keyword. When const is
used in a variable definition, the compiler typically attempts to infer
its value. If the compiler can guess the initial value at compile time,
and by definition the variable's value cannot change after
initialization, then it may optimize the value away. That is, replace
all instructions loading that variable with load-immediate instructions.
If you attempt to take the address of that variable, or the compiler
chooses not to get rid of it, it may place that value in the ".data"
segment again resulting in a "real constant."

You may implicitly cast a non-const to const. Depending on how you
structure your program, you may know that, by design, some function
should not have reason to modify its data. You may declare that data
const to express this fact. Because the compiler knows that nothing will
attempt to modify the data when the particular function is called, all
sorts of optimization trickery becomes possible. The function may be
executed concurrently with others, an OpenMP compiler may spawn separate
threads, VLIW compilers may issue multiple instructions with correct
knowledge that no data dependencies exist, and so on.

Given a constant variable, you may cast away the const property and then
write to it. This is only guaranteed to work if you are certain that the
variable was defined as nonconst. The following example illustrates the
difference between "real constant" and "not as constant as it seems."

void modify(const int *p_a) {
*((int *)p_a) = 7; // take life into own hands; hope caller
// knew what s/he was doing
}

int main() {
int a = 5;
const int b = 5;

modify(&a); // ok: passing the address of a non-const int

modify(&b); // bad: passing the address of a const int.
// Results undefined.

return 0;
}

The first call to modify() works because modify()'s body correctly
assumes that it has really received a pointer to a non-const int. The
second call is likely to fail because that assumption is incorrect.

The author of the modify() function is making some pretty bold
assumptions about the caller and is lying about it in its parameter
list. That's not advised.

Hope this clarifies things.

--
Andrew Kerr

In article <484461DE.8030603@gatech.edu>,
Andrew Kerr <arkerr@gatech.edu> wrote:

>Here, C's subtle goals for portability surface. Some memory pages are
>marked read-only. Any attempted write to a read-only page by a user mode
>program [contrasted with supervisor mode running the OS's kernel] will
>result in an interrupt raised by the Memory Management Unit [MMU], the
>part of the CPU that translates virtual addresses to physical addresses.
>This interrupt notifies the kernel your program is behaving badly.

These things are -commonly- true, but none of them are -necessarily-
true: it is valid for C to run on systems that function quite differently.

>The
>default behavior in this case is an abrupt termination known as a "core
>dump."

Is that a new behaviour in C99? I can't find any reference to it
in C89, not even in the Rationale.


>Executable files produced by modern linkers are partitioned into
>segments. The ".data" segment is expected to be read-only and *may* be
>mapped to a read-only page in virtual memory.

And for the systems that do not use "segments", or which do
not have a ".data" segment? Do you simply define those away as
not having "modern linkers" ?
--
"Eightly percent of the people in the world are fools and the
rest of us are in danger of contamination." -- Walter Matthau

"Leonardo Korndorfer" <leokorndorfer@gmail.com> wrote in message
> Hi,
>
> I'm litle confused by the const modifier, particularly when use const
> char* or char*.
> Some dude over here said it should be const char when you dont modify
> it content inside the function, I read somewhere that it when you
> won't modify after its initialization...
>
> So when exactly do I use one or another? Is it *wrong* not use const
> when I should?
>
Use const when you don't modify the string (or other thing pointed to)
within the function. constness only applies within the function's scope.
Outside the variables can be modified, and in fact usually are modified.
Only rarely is data provided in read-only arrays typed into the program
directly.

There's a bit of debate about the virtues of const. One problem is const
poisoning. Once a pointer becomes const, everything it touches has to be
const. Another problem is that constness applies only to the object directly
pointed to. However frequently structures contain other pointers, and you
want to const them as well.
So it is not exactly wrong to avoid const. Personally I try to keep it to a
minimum. However if I am writing code to publish on my website const will
usually be included for a constant pointer parameter that the user provides.
If the pointer parameter is returned by another function in the same file,
however, I usually won't declare it const.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm


--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Malcolm McLean wrote:
>
> "Leonardo Korndorfer" <leokorndorfer@gmail.com> wrote in message
>> Hi,
>>
>> I'm litle confused by the const modifier, particularly when use const
>> char* or char*.
>> Some dude over here said it should be const char when you dont modify
>> it content inside the function, I read somewhere that it when you
>> won't modify after its initialization...
>>
>> So when exactly do I use one or another? Is it *wrong* not use const
>> when I should?
>>
> Use const when you don't modify the string (or other thing pointed to)
> within the function. constness only applies within the function's scope.
> Outside the variables can be modified, and in fact usually are modified.
> Only rarely is data provided in read-only arrays typed into the program
> directly.

If this means something, I think it must mean something wrong.
A const-qualified object is const-qualified, period, whether it is
in or out of scope. An attempt to modify a const-qualified object
by name or via a const-qualified pointer requires the compiler to
issue a diagnostic; an attempt to modify it by other means yields
undefined behavior. Scope has naught to do with it.

> There's a bit of debate about the virtues of const. One problem is const
> poisoning. Once a pointer becomes const, everything it touches has to be
> const.

Perhaps you should explain what you mean by "touches." If
you mean "points at," the claim is wrong: It is entirely all
right for a pointer-to-const-Thing to point at a Thing that is
not const-qualified.

> Another problem is that constness applies only to the object
> directly pointed to. However frequently structures contain other
> pointers, and you want to const them as well.

What do you mean by "to const?" Is it anything like
"to int" or "to static?"

> So it is not exactly wrong to avoid const. Personally I try to keep it
> to a minimum.

I almost never use `restrict', because my grasp of precisely
what it means appears to equal your grasp of `const'. We both
steer clear of what we don't comprehend.

> However if I am writing code to publish on my website
> const will usually be included for a constant pointer parameter that the
> user provides. If the pointer parameter is returned by another function
> in the same file, however, I usually won't declare it const.

This may be an accurate description of your habits, but I
can't see any reason for using or not using `const' based on
which translation unit a function inhabits.

--
Eric Sosman
esosman@ieee-dot-org.invalid

On Jun 2, 8:11pm, Leonardo Korndorfer <leokorndor...@gmail.com>
wrote:

> So when exactly do I use one or another? Is it *wrong* not use const
> when I should?


My motto is to use const WHENEVER you can... unless the const is
redudant. The one sole example of it being redundant -- that I'm aware
of -- is its use in casts:

printf("%d",(int const)x);

Other than that one sole example, I use const EVERYWHERE that I can.

Here's how variable definitions work in C:

Type variable_name;

An example would be:

int val;

If you want the variable to be const, then you add const to the
_type_; it doesn't matter whether you put it first or second, these
two are identical:

int const val = 5;
const int val = 5;

Now, if you want to turn a variable into a pointer, then you add an
asterisk to the variable's _name_:

int *val;

If you want the pointer to be const, then you add const to the _name_,
and it always goes AFTER the asterisk:

int *const val;

From there, you can add constness to the "pointed-to type" by adding
const to the type name. Again, it doesn't matter whether the const
comes before or after the type name:

int const *const val;
const int *const val;

A few random examples would be:

int *const val;
const int *val;
int const *val;
int *val;

Remember, white space means nothing in C, so you could see these as:

int* const val;
int*const val;
const int* val;
int const*val;
int* val;
int*val;

Just remember that the asterisk always goes with the _name_, and if
the pointer itself is const then you'll always see the const in the
_name_ and it will always be after the asterisk:

int *const val;
int*const val;
int* const val;

And then you might see something like:

int const* const *const * * * const **p;

p is a
pointer to
pointer to
const pointer to
pointer to
pointer to
const pointer to
const pointer to
const int

Of course you could change the white space:

int const*const*const***const**p;

The only other change you can make to it, without actually changing
the type, is changing the "int const" to "const int" because they're
identical:

const int *const*const***const**p;

Andrew Kerr <arkerr@gatech.edu> writes:
> santosh wrote:
>> Ian Collins wrote:
>>> Leonardo Korndorfer wrote:
>>>> I'm litle confused by the const modifier, particularly when use const
>> Are string literals "real constants", whatever that means? I thought
>> you
>> were just supposed to pretend that they were constants, and treat them
>> as such, to prevent the wrath of UB.
>>
>
> Here, C's subtle goals for portability surface. Some memory pages are
> marked read-only. Any attempted write to a read-only page by a user
> mode program [contrasted with supervisor mode running the OS's kernel]
> will result in an interrupt raised by the Memory Management Unit
> [MMU], the part of the CPU that translates virtual addresses to
> physical addresses. This interrupt notifies the kernel your program is
> behaving badly. The default behavior in this case is an abrupt
> termination known as a "core dump."
>
> Executable files produced by modern linkers are partitioned into
> segments. The ".data" segment is expected to be read-only and *may* be
> mapped to a read-only page in virtual memory. Attempting to write it
> results in the above behavior. This is the meaning of "real constant":
> the hardware and OS will not permit you to write it after the loader
> brings that segment into memory and protects the page. String literals
> are typically placed in the ".data" segment, so treat them as "real
> constants."

The above is all system-specific, and has nothing *directly* to do
with C. It's *indirectly* related to C in that (a) it's probably true
of many C implementations, and (b) it probably provided some of the
motivation for what the C standard actually does (and doesn't)
require.

> This differs somewhat from use of the 'const' keyword. When const is
> used in a variable definition, the compiler typically attempts to
> infer its value. If the compiler can guess the initial value at
> compile time, and by definition the variable's value cannot change
> after initialization, then it may optimize the value away. That is,
> replace all instructions loading that variable with load-immediate
> instructions. If you attempt to take the address of that variable, or
> the compiler chooses not to get rid of it, it may place that value in
> the ".data" segment again resulting in a "real constant."

"const" really means "read-only". An attempt to modify an object that
was declared as "const" invokes undefined behavior. As you say, the
compiler is free to use this information to guide optimization.

> You may implicitly cast a non-const to const.

You cannot "implicitly cast" anything to antyhing. The term "cast"
refers only to the explicit operator.

A value may be implicitly *converted* to a const type.

[...]

> Given a constant variable, you may cast away the const property and
> then write to it. This is only guaranteed to work if you are certain
> that the variable was defined as nonconst.

It's important to keep in mind that "const" and "constant" are two
different things. "const", in C, just means read-only. A "constant"
is what some languages refer to as a literal, such as 42, 'x', or 1.2.
(And a "constant expression" is one that an implementation is required
to be able to evaluate at compilation time.)

[snip]

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

> const int *const*const***const**p;

Yeah... I'm not sure if someone wants to use a pointer like that
one...

My point wasn't how to declare, but when to declare.

So, I've come to one simple conclusion:
One should use const when the content won't be modified anywhere after
initialization, and if it will be (and I say that because in "const
char*" case my compiler doesn't warn about changin' it), just don't
use "const".
Sure there can be ways to chage it's data, but those are compiler
dependent and doesn't matter for what const means, right?

On Jun 3, 1:32 am, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
> Malcolm McLean wrote:
> > So it is not exactly wrong to avoid const. Personally I try to keep it
> > to a minimum.
>
> I almost never use `restrict', because my grasp of precisely
> what it means appears to equal your grasp of `const'. We both
> steer clear of what we don't comprehend.
Is that true? Wouldn't it be better to just learn what 'const' or
'restrict' or X does?

vippstar@gmail.com wrote:
> On Jun 3, 1:32 am, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
>> Malcolm McLean wrote:
>>> So it is not exactly wrong to avoid const. Personally I try to keep it
>>> to a minimum.
>> I almost never use `restrict', because my grasp of precisely
>> what it means appears to equal your grasp of `const'. We both
>> steer clear of what we don't comprehend.
> Is that true? Wouldn't it be better to just learn what 'const' or
> 'restrict' or X does?

It would be better, yes. Probably someday I'll set to
work to try to remedy my understanding of `restrict', and
maybe then I'll find ways to use it intelligently. Until
then, I'll just avoid it for fear of using it improperly
out of ignorance.

I'm suggesting that McLean's avoidance of `const' may be
motivated by feelings similar to mine about `restrict': don't
mess around with what you don't understand.

--
Eric Sosman
esosman@ieee-dot-org.invalid

Eric Sosman <esosman@ieee-dot-org.invalid> writes:

> vippstar@gmail.com wrote:
>> On Jun 3, 1:32 am, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
>>> Malcolm McLean wrote:
>>>> So it is not exactly wrong to avoid const. Personally I try to keep it
>>>> to a minimum.
>>> I almost never use `restrict', because my grasp of precisely
>>> what it means appears to equal your grasp of `const'. We both
>>> steer clear of what we don't comprehend.
>> Is that true? Wouldn't it be better to just learn what 'const' or
>> 'restrict' or X does?
>
> It would be better, yes. Probably someday I'll set to
> work to try to remedy my understanding of `restrict', and
> maybe then I'll find ways to use it intelligently. Until
> then, I'll just avoid it for fear of using it improperly
> out of ignorance.
>
> I'm suggesting that McLean's avoidance of `const' may be
> motivated by feelings similar to mine about `restrict': don't
> mess around with what you don't understand.

So why dont you bother to actually understand what they do mean?

In article <g23ikg$lja$3@registered.motzarella.org>,
Richard <rgrdev@gmail.com> wrote:
>Eric Sosman <esosman@ieee-dot-org.invalid> writes:

>> It would be better, yes. Probably someday I'll set to
>> work to try to remedy my understanding of `restrict', and
>> maybe then I'll find ways to use it intelligently. Until
>> then, I'll just avoid it for fear of using it improperly
>> out of ignorance.

>So why dont you bother to actually understand what they do mean?

How should I prioritize this against the many many other tasks
that I have to do? Would you say that this is more important
or less important than feeding the dog? Is it important enough that
I should take a vacation week in order to study and practice it?
Do I have time for a shower before I start?
--
"It's a hard life sometimes and the biggest temptation is to let
how hard it is be an excuse to weaken." -- Walter Dean Myers

roberson@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:

> In article <g23ikg$lja$3@registered.motzarella.org>,
> Richard <rgrdev@gmail.com> wrote:
>>Eric Sosman <esosman@ieee-dot-org.invalid> writes:
>
>>> It would be better, yes. Probably someday I'll set to
>>> work to try to remedy my understanding of `restrict', and
>>> maybe then I'll find ways to use it intelligently. Until
>>> then, I'll just avoid it for fear of using it improperly
>>> out of ignorance.
>
>>So why dont you bother to actually understand what they do mean?
>
> How should I prioritize this against the many many other tasks
> that I have to do? Would you say that this is more important

Is this some kind of joke? You managed to learn how to use pointers and
you have time to post here. One would have thought using features like
this would be a must for a C programmer who wants to best utilise the language.

> or less important than feeding the dog? Is it important enough that
> I should take a vacation week in order to study and practice it?
> Do I have time for a shower before I start?

Do you accept ridiculous answers like that when you correct others?

Richard wrote:
> Eric Sosman <esosman@ieee-dot-org.invalid> writes:
>
>> vippstar@gmail.com wrote:
>>> On Jun 3, 1:32 am, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
>>>> Malcolm McLean wrote:
>>>>> So it is not exactly wrong to avoid const. Personally I try to keep it
>>>>> to a minimum.
>>>> I almost never use `restrict', because my grasp of precisely
>>>> what it means appears to equal your grasp of `const'. We both
>>>> steer clear of what we don't comprehend.
>>> Is that true? Wouldn't it be better to just learn what 'const' or
>>> 'restrict' or X does?
>> It would be better, yes. Probably someday I'll set to
>> work to try to remedy my understanding of `restrict', and
>> maybe then I'll find ways to use it intelligently. Until
>> then, I'll just avoid it for fear of using it improperly
>> out of ignorance.
>>
>> I'm suggesting that McLean's avoidance of `const' may be
>> motivated by feelings similar to mine about `restrict': don't
>> mess around with what you don't understand.
>
> So why dont you bother to actually understand what they do mean?

Low priority. First, my limited understanding of
`restrict' is that it's mostly an optimizer-enabling hint
to the compiler, not something whose addition affects the
operation or correctness (or incorrectness) of a program.
In this way it's similar to `register', another construct
I avoid (but for different reasons). Second, `restrict'
doesn't work at all with C89/C90/C95 compilers, and C99
compilers (although commoner than they used to be) are
still not exactly thick upon the ground.

So, when I tackle two-and-a-half pages of Standardese
beginning "Let D be a declaration of an ordinary identifier
that provides a means of designating an object P as a restrict-
qualified pointer to type T," I am not strongly motivated to
see the matter through to a conclusion.

That's why I "dont" [sic] bother. Not yet, at least.

As for `const', I believe my understanding is adequate.
On the basis of his posting, I'm suggesting that McLean's may
not be.

--
Eric.Sosman@sun.com

Leonardo Korndorfer wrote:

>
>> const int *const*const***const**p;
>
> Yeah... I'm not sure if someone wants to use a pointer like that
> one...
>
> My point wasn't how to declare, but when to declare.
>
> So, I've come to one simple conclusion:
> One should use const when the content won't be modified anywhere after
> initialization, and if it will be (and I say that because in "const
> char*" case my compiler doesn't warn about changin' it),

It won't warn about a write to the pointer object itself, but it should
warn when you write to what the pointer is pointing to.

> just don't use "const".
> Sure there can be ways to chage it's data, but those are compiler
> dependent and doesn't matter for what const means, right?

Yes. If you do write to a const qualified object the further behaviour
of your program is undefined, which in practise means that it depends
on how exactly your compiler treated that object and other issues. If
there exists any chance at all that you might want a read-write object
then don't use the const qualifier.

Richard wrote:

> roberson@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:
>
>> In article <g23ikg$lja$3@registered.motzarella.org>,
>> Richard <rgrdev@gmail.com> wrote:
>>>Eric Sosman <esosman@ieee-dot-org.invalid> writes:
>>
>>>> It would be better, yes. Probably someday I'll set to
>>>> work to try to remedy my understanding of `restrict', and
>>>> maybe then I'll find ways to use it intelligently. Until
>>>> then, I'll just avoid it for fear of using it improperly
>>>> out of ignorance.
>>
>>>So why dont you bother to actually understand what they do mean?
>>
>> How should I prioritize this against the many many other tasks
>> that I have to do? Would you say that this is more important
>
> Is this some kind of joke? You managed to learn how to use pointers
> and you have time to post here. One would have thought using features
> like this would be a must for a C programmer who wants to best utilise
> the language.
>
>> or less important than feeding the dog? Is it important enough that
>> I should take a vacation week in order to study and practice it?
>> Do I have time for a shower before I start?
>
> Do you accept ridiculous answers like that when you correct others?

Doubtless Eric has numerous other work-related responsibilities. He has
previously indicated that he has practised professional C programming
from the late 70s. I doubt he's still actively involved in professional
C programming. Even if so, I don't think restrict is used all that
frequently in C code. I have hardly ever seen it in code that I have
dealt with. It probably isn't a priority matter for Eric.

Richard wrote:

> roberson@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:
>
>> In article <g23ikg$lja$3@registered.motzarella.org>,
>> Richard <rgrdev@gmail.com> wrote:
>>>Eric Sosman <esosman@ieee-dot-org.invalid> writes:
>>
>>>> It would be better, yes. Probably someday I'll set to
>>>> work to try to remedy my understanding of `restrict', and
>>>> maybe then I'll find ways to use it intelligently. Until
>>>> then, I'll just avoid it for fear of using it improperly
>>>> out of ignorance.
>>
>>>So why dont you bother to actually understand what they do mean?
>>
>> How should I prioritize this against the many many other tasks
>> that I have to do? Would you say that this is more important
>
> Is this some kind of joke? You managed to learn how to use pointers and
> you have time to post here. One would have thought using features like
> this would be a must for a C programmer who wants to best utilise the language.

One would; many don't.

--
"The original and modest plans had to be continually extended."/Sector General/

Hewlett-Packard Limited registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England

In article <g23kub$v80$3@registered.motzarella.org>,
Richard <rgrdev@gmail.com> wrote:
>roberson@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:

>> In article <g23ikg$lja$3@registered.motzarella.org>,
>> Richard <rgrdev@gmail.com> wrote:
>>>Eric Sosman <esosman@ieee-dot-org.invalid> writes:

>>>> Probably someday I'll set to
>>>> work to try to remedy my understanding of `restrict', and
>>>> maybe then I'll find ways to use it intelligently.

>>>So why dont you bother to actually understand what they do mean?

>> How should I prioritize this against the many many other tasks
>> that I have to do? Would you say that this is more important

>Is this some kind of joke?
Well, it was a minor joke in that I don't actually have a dog to feed,
but I do have other kinds of dependants that need to be fed regularly.

>You managed to learn how to use pointers and
>you have time to post here. One would have thought using features like
>this would be a must for a C programmer who wants to best utilise the language.

Well, the time I have spent investigating them so-far has suggested
that const and restrict are of minor value, and no match for the
Intra-Procedural Analysis (IPA) optimizer of the compilers I use.
So either they really are of little importance (or even of hinderance)
to "a C programmer who wants to best utilize the language" -- or
else they -are- of importance in some manner that I have not yet
discerned, in which case it will take a fair bit of effort to
get past my current perceptions that they are more or less useless.

Seeing as you implicitly claim to understand their uses and how
best to utilize them, then you can guide me as to their relative
importance compared to other things in my life. Would my "proper"
understanding of these features revolutionize my C programs? To the
point where I ought to be telling my boss, "I should put these other
tasks aside until I have sussed these features out, as I am assured
that they are the keys to the hidden temple of C and once I understand
them, I'll be five times as productive and able to cure yaws!" ?
Or is this more along the lines of "Probably it'd be a good idea
to attend to those dandelions on your front yard first... and to
wash the windows... and to change the oil in the car..." ??
--
"It's a hard life sometimes and the biggest temptation is to let
how hard it is be an excuse to weaken." -- Walter Dean Myers

roberson@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:

> In article <g23kub$v80$3@registered.motzarella.org>,
> Richard <rgrdev@gmail.com> wrote:
>>roberson@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:
>
>>> In article <g23ikg$lja$3@registered.motzarella.org>,
>>> Richard <rgrdev@gmail.com> wrote:
>>>>Eric Sosman <esosman@ieee-dot-org.invalid> writes:
>
>>>>> Probably someday I'll set to
>>>>> work to try to remedy my understanding of `restrict', and
>>>>> maybe then I'll find ways to use it intelligently.
>
>>>>So why dont you bother to actually understand what they do mean?
>
>>> How should I prioritize this against the many many other tasks
>>> that I have to do? Would you say that this is more important
>
>>Is this some kind of joke?
> Well, it was a minor joke in that I don't actually have a dog to feed,
> but I do have other kinds of dependants that need to be fed regularly.
>
>>You managed to learn how to use pointers and
>>you have time to post here. One would have thought using features like
>>this would be a must for a C programmer who wants to best utilise the language.
>
> Well, the time I have spent investigating them so-far has suggested
> that const and restrict are of minor value, and no match for the
> Intra-Procedural Analysis (IPA) optimizer of the compilers I use.

The compilers you use are of no interest to this group since, as you
constantly remind people, it is about standards compliant C. Especially
with regards to const, I find it hard to believe that you can not find
the time to make your code sturdier and more readable.

On 3 Jun 2008 at 14:03, Walter Roberson wrote:
> Richard <rgrdev@gmail.com> wrote:
>>So why dont you bother to actually understand what they do mean?
>
> How should I prioritize this against the many many other tasks
> that I have to do? Would you say that this is more important
> or less important than feeding the dog? Is it important enough that
> I should take a vacation week in order to study and practice it?
> Do I have time for a shower before I start?

If you want to be a professional C programmer, then of course you need
to understand the basic features of the C language. Even if you refuse
to use them yourself, then you'll undoubtedly run across other people's
code, and they might not have the same prejudices as you against
features introduced into the C standard after the end of the cold war.

Certainly const is something you see all over the place in other
people's code; admittedly restrict is much rarer, but it does crop up in
certain libraries that want to Do Things Right.

I find it pretty amazing that you and Sossman, who are appalled if
people don't keep at the front of their mind that "long unsigned int
long" is a synonym for "unsigned long long", or fail to account for the
behavior of their code on a machine with no stack where fopen always
returns NULL, and generally seem content to waste hours of your time
pouring over the pointless minutiae of the dustier corners of the ANSI
Bible, should be so reluctant to figure out what const means.