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

[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?

[David Harmon]

On 6 Sep 2006 12:37:08 -0700 in comp.lang.c++, "Chris"
<ch***************@gmail.comwrote,

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

[BigBrian]

Chris wrote:

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

[Chris]

BigBrian wrote:

Chris wrote:

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

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.

[Colander]

Chris schreef:

BigBrian wrote:

Chris wrote:

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

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.

[red floyd]

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.

[Chris]

red floyd wrote:

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? I understand that static means "create once", but aren't
string literals like this created and stored somewhere "once" by the
compiler anyway?

[Thomas Tutone]

Chris wrote:

red floyd wrote:

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

[Chris]

Thomas Tutone wrote:

Chris wrote:

red floyd wrote:

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.

[Frederick Gotham]

Chris posted:

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?

When you finish reading every else's replies, you might want to read up on
this:

http://en.wikipedia.org/wiki/Reentrant

--

Frederick Gotham

[Chris]

Frederick Gotham wrote:

Chris posted:

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?

When you finish reading every else's replies, you might want to read up on
this:

http://en.wikipedia.org/wiki/Reentrant

--

Frederick Gotham

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

[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;
}

--

Frederick Gotham

[Victor Bazarov]

Frederick Gotham wrote:

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
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

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

--

Frederick Gotham

[Victor Bazarov]

Frederick Gotham wrote:

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.

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

[Frederick Gotham]

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?

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

--

Frederick Gotham

[Noah Roberts]

Frederick Gotham wrote:

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?

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.