Why does C/C++ use const & static so many times?

[Todd Blackmon]

The one major beef I have with C/C++ is that there are so many variations
for
the same word.  For example:

static global variable      - variable accessible only from within source
file
static function             - function accessible only from within source
file
static variable in function - variable whose value gets retained between
calls
static member variable      - variable with one value for all classes
static member function      - function accessible from outside the class

I think you are just looking at it wrong. Ignoring the last two
because they are C++ only, for C static *is* consistent.

Static explicitly defines two things about an identifier (function or
variable): 1. scope, 2. lifetime.

Scope
If static is inside a function, it is function-scoped, otherwise it is
file scoped.

Lifetime
The identifier exists for the entire life of the program.

That's it, no more. But what makes it seem different is that the
default scope and lifetime rules are different for global variables,
functions, and local variables. This makes static to appear to mean
different things, but it really doesn't.

tjb

 

[Seebs]

You might want to stop using the word "crazy" when talking to people who
know this stuff better than you do.

I don't think so. So far as I can tell, he's trolling; since using the word
"crazy" when talking to people who know the field much better than he does
produces responses, I think he wants to keep doing it.

-s

 

[Moi]

I don't think so. So far as I can tell, he's trolling; since using the
word "crazy" when talking to people who know the field much better than
he does produces responses, I think he wants to keep doing it.

Please keep in mind that Arnuld is not a native speaker. To him, "crazy" may
mean "weird", "strange", "funny", "awkward", or even "apolitical".

IMO, YMMV,
AvK

 

[Ben Bacarisse]

I think you are just looking at it wrong. Ignoring the last two
because they are C++ only, for C static *is* consistent.

Static explicitly defines two things about an identifier (function or
variable): 1. scope, 2. lifetime.

Scope
If static is inside a function, it is function-scoped, otherwise it is
file scoped.

Lifetime
The identifier exists for the entire life of the program.

That's it, no more. But what makes it seem different is that the
default scope and lifetime rules are different for global variables,
functions, and local variables. This makes static to appear to mean
different things, but it really doesn't.

I disagree. 'static' has no effect on scope -- at least if we take the
conventional meaning of of scope. It affects the linkage of names but
not their scope. As for lifetime, it alters the lifetime of some
objects (those defined inside functions) but it has no effect on the
lifetime of other objects (those declared at file scope).

To my mind, these effects are not consistent though they are nebulously
related to each other. People say that the use of static is not
consistent because it is hard to come up with a simple meaning that
applies in all cases and I don't think you've overcome that objection.

 

[Moi]

Are Arnuld and sandeep, the same person?

No, I don't think so.
But they might be, since I appeared to mess them up ;-)

AvK

 

[Nick Keighley]

[...] (If your
perfectly valid K&R/C90/C99 code uses `class' or `private' as an
identifier, I think you're out of luck if someone decides to dump it
through a C++ compiler; this why I make a point of using `new' as an
identifier whenever it seems descriptive.)
Uhhh I think you mean of NOT using new, so that your code will be
portable to C++ compilers too.
      No, "I meant what I said, and I said what I meant."  I don't
want my C code misinterpreted subtly by a C++ compiler, because I don't
know C++ and even my best C probably has "mistakes" from a C++ point of
view.  By using `new' (and by not casting void* and so on), I try to see
to it that anyone so foolish as to use the wrong compiler on my code
will at least hear some warning bells.

But this is crazy!!

Why would you introduce non-portable constructions deliberately? I can
understand if there's some feature of C you need that clashes with C++
then use it, but why go out of your way to make your code non-portable to
C++ compilers?

     It may come as a surprise to you, but I also use Algol keywords
in my C code, and deliberately write in a style no PL/1 compiler
will accept.

you what?

     To the limits of my ability, my C code is correct as C: It does
what it's supposed to do.  That doesn't mean it would be correct if
processed by a compiler for Fortran, or Pascal, or LISP, C++, Basic,
XPL, TAL, or any other language:

yes but C++ is a special case. C and C++ are strongly related the
others aren't

It's C, not something else.  Now,
no one in his right mind would try to push C code through a CUPL
compiler, or SNOBOL through a C compiler, but there seems to be a
goodly number of people who will try to push C code through a C++
compiler.

me! My C code will usually compile with a C++ compiler (I've even
worked on a project where it was compulsary to write C-like C++ and
compile it with a C++ compiler)

 If a C++ compiler happens to accept my C code (changing
its meaning silently and subtly), my mis-translated code may then do
something undesirable or at least peculiar.  Know what happens next?
*I* get blamed for *their* use of the wrong compiler, because it's
my "incorrect" code that misbehaves.

     No,

     Thank

     You.

a fair point

     The fact that two different languages share a few words does not
mean that the languages are interchangeable, nor even compatible.
Even when they share a great number of words and constructs due to a
common ancestry, they're not interchangeable nor compatible (try
speaking Spanish next time you're in Napoli).

yes but in this case we're comparing english and geordie


since when? I'd have said it was one of the great strengths of C++
that is retained some backwardss compatibility with C (and the cause
of some of its problems)

     Ah!  At last, I understand why C never amounted to anything until
C++ came along.

the great strength of the dollar bill is that fits in a standard
hollerith card hopper

 

[Nick Keighley]

[...] (If your
perfectly valid K&R/C90/C99 code uses `class' or `private' as an
identifier, I think you're out of luck if someone decides to dump it
through a C++ compiler;

you can't compile K&R C with a C++ compiler

this why I make a point of using `new' as an
identifier whenever it seems descriptive.)
Uhhh I think you mean of NOT using new, so that your code will be
portable to C++ compilers too.
     No, "I meant what I said, and I said what I meant."  I don't
want my C code misinterpreted subtly by a C++ compiler, because I
don't know C++ and even my best C probably has "mistakes" from a C++
point of view.  By using `new' (and by not casting void* and so on), I
try to see to it that anyone so foolish as to use the wrong compiler
on my code will at least hear some warning bells. [...]
Why would you introduce non-portable constructions deliberately? I can
understand if there's some feature of C you need that clashes with C++
then use it, but why go out of your way to make your code non-portable
to C++ compilers?

He just explained his reasons.  Did you not understand them, or do you
disagree with them?  If you disagree, how was he wrong?

I disagree with Mr Sosman on this point.

In my opinion portability is a crucial feature of code.

but not portability between languages!

Time and time
again we see good code becoming obsoleted because it was written in a non-
portable way and hardware moves on.

what's that got to do with the price of fish (or C++ compilers)

Sometimes non-portability is needed,
for example a network program will either use BSD sockets or WinSock and
so incompatability is forced.

I've seen libraries that supported both

But in my opinion it is ONLY worth giving
up portability in order to get access to a useful platform-specific
feature.

speed, size, access to a library. C99 has many incompatibilities with C
++

Deliberately making code non-portable to C++ compilers for no clear
advantage is crazy! Many people choose to compile C with C++ compilers...
why make life difficult for them?


For sure Mr Sosman knows C++ well enough! All that is needed is avoiding
certain artificial constructions that don't occur in normal code.

if you think that is the case then you are dangerous. I'm in the
(foolish) habbit of answering questions on comp.lang.c++ when the
answer appears to be confined to the C-subset of the language. It is
surprising how often this is wrong.

 

[Nick Keighley]

I am not saying that you should try especially to write C code that is
also valid in C++. What I am saying is that you should not try especially
to write C code that is invalid C++.

yes but by promising not to write code that isn't gratuitously
incompatible with C++ you have implicitly promised to write code that
is compatible with C++. People will rely on this which increases your
test burden and restricts (good word) your future options. Quick you
suddenly have to use complex numbers in your code. Do you go the C99
or the C++ route?

Here is an analogy,

argument by analogy is usually suspect

 

[Nick Keighley]

Personally, I think it's important to know, or at least
understand and appreciate, a number of techniques. Especially
if you're maintaining a lot of code written by other people.
But there is no ONE TRUE STYLE.

all generalisations are wrong

which is why are I so often appear to arguing both sides of an
argument. There are shades of grey not black and white.

 

[Nick Keighley]

I think it is a mistake to try to inflict our wishes for this sort of
thing on other people.

In a similar vein, if you are writing code for a DSP on some non-hosted
toaster CPU -- all the while reading and writing hardware ports and
other naughty non-portable things, then I see little point in trying to
make your code totally general unless it has some value for *you*.

not totally general, but my experience with "toasters" (some of these
"toasters" were 10kw toasters) is being able to run most of the code
on a "proper" computer as well makes life easier. Sometimes the
"toasters" aren't available 'til late in the development cycle or
won't fit through the door. Of course this is all covered by your
"unless it has some value for *you*" clause.

 

[Ben Bacarisse]

On 24 June, 18:33, Eric Sosman <[email protected]> wrote:

the great strength of the dollar bill is that fits in a standard
hollerith card hopper

Yes, smaller things fit in larger ones! I know you are making an
analogy between C and C++ with the decision to make (IBM) Hollerith
cards the same size as a dollar bill but, in a move that undermines the
analogy, that link was broken when the dollar bill was made smaller in
1929.

C still fits into C++ but there is more room round the edges than many
people think. (OK, I think this analogy has been done to death now.)

 

[Eric Sosman]

[...]
The fact that two different languages share a few words does not
mean that the languages are interchangeable, nor even compatible.
Even when they share a great number of words and constructs due to a
common ancestry, they're not interchangeable nor compatible (try
speaking Spanish next time you're in Napoli).

yes but in this case we're comparing english and geordie

Exactly. Back in Bright College Days, I rented a room from a
couple who'd come to the USA from Britain. They were educated folk
(she was an adjunct professor) and spoke English that even a Merkun
could understand -- but when they wanted to keep their conversation
private from their student roomers, they'd revert to Geordie. It
was very clearly English-like, but utterly unintelligible.

The defense rusts.

 

[Seebs]

Please keep in mind that Arnuld is not a native speaker. To him, "crazy" may
mean "weird", "strange", "funny", "awkward", or even "apolitical".

Is "arnuld" related to "sandeep"?

-s

 

[David Thompson]

The "auto" keyword is very old, going back to B and/or BCPL, and it
wasn't pointless back then. It was legal and very common to rely on the
"implicit int" rule, and the "auto" keyword was a way to mark something
as an object declaration without specifying the type:

{
auto x;
static y;
/* ... */
}

BCPL had effectively auto variables, but didn't use that keyword --
AFAIK; there were several variants. B did, according to dmr's paper.

'common' is an understatement. BCPL and (according to dmr) B had no
type specifiers, so there was no way to not omit them. The 'typeless'
type 'cell' was used as both integer and a pointer, and at least in
BCPL floating-point, and as packed characters (although usually in an
array aka VEC, not a declared variable).

I agree that it's largely pointless in modern C. (BTW, C++ is in
the process of re-using it for a new purpose; "auto x = expr_value;"
declares x as on object of the type of expr.)

Well, if they can't find any more uses for 'static', I guess they have
to settle for compromises like that. <GG>

 

[Brian]

I don't think so. So far as I can tell, he's trolling; since using
the word "crazy" when talking to people who know the field much
better than he does produces responses, I think he wants to keep
doing it.

You know what I think? I think you can't program yourself out of a
paperbag.

 

[Brian]

I don't think so. So far as I can tell, he's trolling; since using
the word "crazy" when talking to people who know the field much
better than he does produces responses, I think he wants to keep
doing it.

I mean, has anyone seen this guy's code? Pfft, it better not look like
Bjarnes! Because that is horrendous!

 

[Brian]

The idiotic Schildt recommendation lends a certain amount of credence
to the trolling theory.

Shut up and write a book. I think I have one of his but not one of yours
on my bookshelf so shut up or shut up.

 

[Brian]

all generalisations are wrong

"sorry" I was absent to say that?

(I taught you well, pilgram)

hehehe

which is why are I so often appear to arguing both sides of an
argument. There are shades of grey not black and white.

That's way different, (pilgram), ... it is bad to be samurai, to "the
uneducated consumer".

 

[Brian]

Nick Keighley wrote:



Post-modernist nonsense.

There are shades of grey, AND black, AND white.

Why you debate this? What is there not unknown?

 

[Brian]

Eric Sosman writes:
On 6/23/2010 3:13 PM, sandeep wrote:
Eric Sosman writes:
[...] (If your
perfectly valid K&R/C90/C99 code uses `class' or `private' as an
identifier, I think you're out of luck if someone decides to
dump it through a C++ compiler; this why I make a point of
using `new' as an identifier whenever it seems descriptive.)
Uhhh I think you mean of NOT using new, so that your code will be
portable to C++ compilers too.
No, "I meant what I said, and I said what I meant." I don't
want my C code misinterpreted subtly by a C++ compiler, because I
don't know C++ and even my best C probably has "mistakes" from a
C++ point of view. By using `new' (and by not casting void* and
so on), I try to see to it that anyone so foolish as to use the
wrong compiler on my code will at least hear some warning bells.
But this is crazy!!

Why would you introduce non-portable constructions deliberately? I
can understand if there's some feature of C you need that clashes
with C++ then use it, but why go out of your way to make your code
non-portable to C++ compilers?
He just explained his reasons. Did you not understand them, or do
you disagree with them? If you disagree, how was he wrong?

I disagree with Mr Sosman on this point.

Fine, I can accept that you disagree with him.

Eric Sosman has contributed to comp.lang.c for many years, and has
built up a fine reputation as an expert C programmer by being right a
lot of the time and wrong not very often.

I understand that. It is commendable (maybe). I think it is true (I only
hesitate because it is my nature to not believe anyone ever), and I'm not
voting for him in any way. C sucks and I don't care if it's his religion.
(?) (I don't do politics).

You have contributed to comp.lang.c for a few weeks, IIRC, and have
built up a reputation as someone who isn't right very often, although
by no means always wrong. You scored one good goal, but that doesn't
make you an expert.

Longevity is orthogonal to expertise.

You *might* be right on this occasion.

Or always, but the post menapausal bitch gets to live? (been there, done
that).

The fact that Eric, an
acknowledged expert,

In what, by whom?

disagrees with you does not necessarily make you
wrong.

Duh. "Heeeeereeee's yer sign".

But the smart money is on Eric.

Heeeeere's the snake oil.

To persuade people that he is
wrong and you are right, you will need better arguments than "I
disagree" and "in my opinion".

That's easy controversy for it says nothing. I'm glad I'm not a warrior
or I'd say shut up and find something new. (I thought taxes were him?
wtf?)

Right. And code written in ISO C is portable.

Bingo! YOU win!!! YOU go to Afghanistan! Do you still want the job? You
know all about portability. Shut up you idiot, because they will send you
there.