Any reason for local var to be "static const"?

C

Chris

Looking at some code I see a declaration inside a function like

static const string s("some string");

Does the static serve any purpose here?
 
D

David Harmon

On 6 Sep 2006 12:37:08 -0700 in comp.lang.c++, "Chris"
Looking at some code I see a declaration inside a function like

static const string s("some string");

Does the static serve any purpose here?

Prevents the string from being constructed over again for every call
of the function.
 
B

BigBrian

Chris said:
Looking at some code I see a declaration inside a function like

static const string s("some string");

Does the static serve any purpose here?

Yes, static serves a purpose. Static automatic variables are created
once and aren't destroyed when the function exits. The variable s is
only constructed once. I would guess the writter of the code is trying
to improve performance by making it static.

-Brian
 
C

Chris

BigBrian said:
Yes, static serves a purpose. Static automatic variables are created
once and aren't destroyed when the function exits. The variable s is
only constructed once. I would guess the writter of the code is trying
to improve performance by making it static.

-Brian

If "static" weren't there and it was just declared "const", would the
compiler be likely to do the same thing--allocate the string once
somewhere and reuse it? Just wondering if the static is overkill in
practice.
 
C

Colander

Chris schreef:
If "static" weren't there and it was just declared "const", would the
compiler be likely to do the same thing--allocate the string once
somewhere and reuse it? Just wondering if the static is overkill in
practice.

No it's not.

Static say something about scoop. (There is only one)
Const says something about value. (You can't[really shouldn't] change
it)

They are different concepts.
 
R

red floyd

Colander said:
Static say something about scoop. (There is only one)
Const says something about value. (You can't[really shouldn't] change
it)

They are different concepts.

In the case under discussion (local static), your first statement is
incorrect.

static in this case says something about *LIFETIME*. The variable is
constructed exactly once and destroyed only at the end of program execution.

It has nothing to do with scope in this case, and further, you
explanation (There is only one) has nothing to do with scope either.
 
C

Chris

red said:
Colander said:
Static say something about scoop. (There is only one)
Const says something about value. (You can't[really shouldn't] change
it)

They are different concepts.

In the case under discussion (local static), your first statement is
incorrect.

static in this case says something about *LIFETIME*. The variable is
constructed exactly once and destroyed only at the end of program execution.

It has nothing to do with scope in this case, and further, you
explanation (There is only one) has nothing to do with scope either.

I guess my question is--does declaring a local const string that is
initialized to a literal value as static have any real practical
purpose? I understand that static means "create once", but aren't
string literals like this created and stored somewhere "once" by the
compiler anyway?
 
T

Thomas Tutone

Chris said:
red said:
Colander said:
Static say something about scoop. (There is only one)
Const says something about value. (You can't[really shouldn't] change
it)

They are different concepts.

In the case under discussion (local static), your first statement is
incorrect.

static in this case says something about *LIFETIME*. The variable is
constructed exactly once and destroyed only at the end of program execution.

It has nothing to do with scope in this case, and further, you
explanation (There is only one) has nothing to do with scope either.

I guess my question is--does declaring a local const string that is
initialized to a literal value as static have any real practical
purpose?
Yes.

I understand that static means "create once", but aren't
string literals like this created and stored somewhere "once" by the
compiler anyway?

No. You are confusing a std::string with an array of const char
(a.k.a. a "C-string" or "string literal"). The latter should only be
created once (or at least typically is, whether or not that is required
by the Standard). A std::string that was _not_ static, on the other
hand, should be constructed each time the function is entered, and
destroyed each time the function is exited. Every Single Time. It is
possible that a good optimizer might optimize that construction and
destruction away, given that the std::string is decleared const, but in
practice few if any do.

In sum: I think your confusion arises from the fact that the
std::string is initialized with a string literal. That string literal
may well be created only once, but the std::string will be constructed
and destructed multiple times. And that means that putting in "static"
does have a practical purpose. Whether that purpose - saving all those
gratuitous constructions and destructions - matters here could only be
determined by profiling the code.

Best regards,

Tom
 
C

Chris

Thomas said:
Chris said:
red said:
Colander wrote:

Static say something about scoop. (There is only one)
Const says something about value. (You can't[really shouldn't] change
it)

They are different concepts.


In the case under discussion (local static), your first statement is
incorrect.

static in this case says something about *LIFETIME*. The variable is
constructed exactly once and destroyed only at the end of program execution.

It has nothing to do with scope in this case, and further, you
explanation (There is only one) has nothing to do with scope either.

I guess my question is--does declaring a local const string that is
initialized to a literal value as static have any real practical
purpose?
Yes.

I understand that static means "create once", but aren't
string literals like this created and stored somewhere "once" by the
compiler anyway?

No. You are confusing a std::string with an array of const char
(a.k.a. a "C-string" or "string literal"). The latter should only be
created once (or at least typically is, whether or not that is required
by the Standard). A std::string that was _not_ static, on the other
hand, should be constructed each time the function is entered, and
destroyed each time the function is exited. Every Single Time. It is
possible that a good optimizer might optimize that construction and
destruction away, given that the std::string is decleared const, but in
practice few if any do.

In sum: I think your confusion arises from the fact that the
std::string is initialized with a string literal. That string literal
may well be created only once, but the std::string will be constructed
and destructed multiple times. And that means that putting in "static"
does have a practical purpose. Whether that purpose - saving all those
gratuitous constructions and destructions - matters here could only be
determined by profiling the code.

Best regards,

Tom

Thanks, that explains it perfectly and answers my questions.
 
F

Frederick Gotham

Chris posted:
Ok, read it. What am I supposed to glean from it? Please elaborate.

To think twice before introducing static data into a function. Here's an
example of a non-reentrant function which will malfunction if run
concurrently by two separate threads. At first thought, it may be a good
idea to use static data, but beware...

(The aim of the function is to centre a string horizontally in a space of
specified width.)

#include <assume all necessary includes...

template<std::size_t width>
char const *CenterHoriz(char const *const p)
{
using std::memset; using std::strlen; using std::size_t;

char static spaces[width+1] = {};
memset(spaces,' ',width);

size_t const len = strlen(p);
assert(width >= len);

char *const pos = spaces + (width/2 - len/2);

memcpy(pos,p,len);

return spaces;
}
 
V

Victor Bazarov

Frederick said:
Chris posted:
Ok, read it. What am I supposed to glean from it? Please elaborate.

To think twice before introducing static data into a function. [..]

It has nothing to do with static *const*, though, does it?

V
 
F

Frederick Gotham

Victor Bazarov posted:
It has nothing to do with static *const*, though, does it?


There will only be a problem if static data is altered (as in my example). If
the static data remains constant, there shouldn't be a problem.
 
V

Victor Bazarov

Frederick said:
Victor Bazarov posted:



There will only be a problem if static data is altered (as in my
example). If the static data remains constant, there shouldn't be a
problem.

So, your example is not applicable in the case discussed in this
thread, right?
 
F

Frederick Gotham

Victor Bazarov posted:
So, your example is not applicable in the case discussed in this
thread, right?


To be honest I didn't pay much attention to the original code snippet. I just
saw a question pertaining to static data and thought I'd throw in about
"Reentrant functions".
 
N

Noah Roberts

Frederick said:
Victor Bazarov posted:



To be honest I didn't pay much attention to the original code snippet. I just
saw a question pertaining to static data and thought I'd throw in about
"Reentrant functions".

Would not a "reentrant function" by definition protect data that can be
stomped on by opposing threads? At least that is how I've always heard
it discussed. For instance, compiling a special "reentrant std lib"
protects static member data used in such functions as the C function
strtok.

I believe you are meaning that using a non-reentrant function that
manipulates static data is dangerous. Of course this is a given, as is
a non-reentrant function that manipulates global data. In fact the
problem of using non-reentrant functions in a threaded program are so
numerous that pointing out one and saying, "watch out, it could cause
problems in threaded systems," seems rather a moot point when arguing
against using such constructs.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top