Usage of static const

Hi,

When are static consts to be used?

I have some constants which are being used only by that class in that file.
which is preferrable - declaring static consts in class declaration so that it can be initialised there itself / declaring consts in class declaration and initialising them in cpp / declaring consts outside the class so that its scope is that file?
is there any advantage of the above methods?

constants are by default static. Then why static const declaration is necessary?

If you have constants that are only to be used by a certain class I would hide them inside the .cpp file like this:

Code:

---

namespace constants
{
    int const g_my_int(3141592654);
    std::string const g_my_string("pi");
}

---

If I want to have certain integer constants visible in the class declaration I use enum:

Code:

---

struct A
{
    enum
    {
        value_one = 1,
        value_two = 2
    };
};

---

If I would like to expose constant strings I would use static methods like this:

Code:

---

struct B
{
    static std::string const my_string();
};

---

So if you ask me. static const variables doesn't add much.

Quote:

---

constants are by default static. Then why static const declaration is necessary?

---

If I understand you correctly then no, const doesn't implicate static. Consider this:

Code:

---

struct X
{
    X() : m_i(rand())
    {
    }
    int const m_i;
};

---

Now m_i is initialized with a random for each instance of X. So there is a semantic difference between static const and const.

Hope this helps.

If you have constants that are only to be used by a certain class, I would use an unnamed namespace.

Code:

---

namespace
{
    int const g_my_int(3141592654);
    std::string const g_my_string("pi");
}

---

constants are by default static. is this true????

Quote:

---

Originally Posted by walkinginwater

constants are by default static. is this true????

---

No.
If it has to be created on the heap, it will not be static.
Example:

const std::string data = "This is not a static variable, an it's created on the heap";

An std::string object itself isn't created on the heap unless you call new to allocate the std::string object itself. It's another matter that std::string manages pointers to memory allocated on the heap, but the std::string object itself will be placed on the stack if you just declare it normally.

Quote:

---

Originally Posted by Axter

const std::string data = "This is not a static variable, an it's created on the heap";

---

Well...nothing of the above will actually be created on the heap...the string instance is allocated in the stack while the string literal is allocated in the const data area.

Quote:

---

Originally Posted by HighCommander4

An std::string object itself isn't created on the heap unless you call new to allocate the std::string object itself. It's another matter that std::string manages pointers to memory allocated on the heap, but the std::string object itself will be placed on the stack if you just declare it normally.

---

You're absolutely right. That was poor wording in my part.

The std::string object is created on the stack, but the actual data that stores the string contents is created on the heap.

Quote:

---

Originally Posted by Andreas Masur

Well...nothing of the above will actually be created on the heap...the string instance is allocated in the stack while the string literal is allocated in the const data area.
.

---

That's not completely accurate.
While both the std::string object and the string literals are created on the stack, the dynamic memory manage by the std::string is created on the heap.
So the string literal is COPIED to the heap by the std::string object.

Code:

---

const std::string MyConstData = "This string is stored on the heap by std::string";

---

When you retrieve the contents of MyConstData, you're retrieving data that is on the heap.
So although the string literal is on the stack, that is not what you're retrieving. You're retrieving a copy that is on the heap.
Which is the main point I was trying to make on my original post, put failed to give a good accurated description.

Quote:

---

Originally Posted by Axter

That's not completely accurate.
While both the std::string object and the string literals are created on the stack, the dynamic memory manage by the std::string is created on the heap.
So the string literal is COPIED to the heap by the std::string object.

---

Well...based on the assumption that every STL 'string' class uses the heap by default...and that was simply my point...

Quote:

---

Originally Posted by Axter

Which is the main point I was trying to make on my original post, put failed to give a good accurated description.

---

Again...based on the above mentioned assumption...in other words it depends on the class that is used...

It's hard to give an accurate description, because there are no specific rules laid down by the standard for implementaion of string. It's possible to write a "lazy" implementation that reference counts strings (makes for quick copies) and that only makes a separate copy if you do something to modify one of them. It's possible that an implementation could point directly to the literal used to initialise it until such time as you call a mutator function, and only then does it copy it to the heap. I'm not saying it will, just that the rules allow it. There's quite a lot of flexibility there.

Quote:

---

Originally Posted by Graham

It's hard to give an accurate description, because there are no specific rules laid down by the standard for implementaion of string. It's possible to write a "lazy" implementation that reference counts strings (makes for quick copies) and that only makes a separate copy if you do something to modify one of them. used to initialise it until such time as you call a mutator function, and only then does it copy it to the heap. I'm not saying it will, just that the rules allow it. There's quite a lot of flexibility there.

---

Even with reference counting, (which most implementations have) the memory storing the string data would still be placed on the heap.
(***not referring to string literal***).

Quote:

---

Originally Posted by Graham

It's possible that an implementation could point directly to the literal

---

That would be very difficult for an implementation to do. The std::string constructor would have to know that it's pointing to a string literal.

There is a common version of std::string who's data can be completely on the stack for small strings.
One common implementation of std::string creates a static size buffer used for small strings. This buffer is usually about 16 characters or less.
If the string size is larger then the static buffer, then a dynamic buffer is used which is again placed on the heap.

Anyway, both of you are missing the entire point of my original post.
The point I was making is the just because an object is constant, doesn't mean that the entire object is created on the stack.
If the object has dynamic data, the dynamic data can be on the heap.

Quote:

---

Originally Posted by Axter

That would be very difficult for an implementation to do. The std::string constructor would have to know that it's pointing to a string literal.

---

It already does. The constructor that accepts a const char * knows that it's pointing to a constant string. While this may in fact be a string literal, it doesn't necessarily have to be. However, what's the difference? String literals are treated the same as if you declared a const char * and pointed it to a string. Therefore, it would definitely be possible for the std::string class to know that it's pointing to a constant string and only allocate data if the user tries to modify that string.

Quote:

---

Originally Posted by Bob Davis

It already does. The constructor that accepts a const char * knows that it's pointing to a constant string. While this may in fact be a string literal, it doesn't necessarily have to be. However, what's the difference? String literals are treated the same as if you declared a const char * and pointed it to a string. Therefore, it would definitely be possible for the std::string class to know that it's pointing to a constant string and only allocate data if the user tries to modify that string.

---

No it doesn't.
The constructor takes a constant argument. It doesn't know if it's getting constant data or not.

void func1(const char*data);

char d1[] = "none constant data";
func1(d1);
func1("I'm constant string literal");

How would func1 know it's pointing to a string literal or not?
How would func1 know it's pointing to constant data or none-constant data?

It doesn't. It assumes it's constant, and treats all data it gets as if it where constant regardless of the constantness of the original data.

Quote:

---

Originally Posted by Bob Davis

Therefore, it would definitely be possible for the std::string class to know that it's pointing to a constant string and only allocate data if the user tries to modify that string.

---

No. Not in the context that you're describing it.

What you're thinking about is reference counting, which works with an object, and not just with a pointer constant char* pointer.