just a little curious efficiency concern(!)

When I do this in C++:

Code:

---

std::string name("No Name");

---

i believe that compiler stores the const char* in probably read only memory, which will be of no use from now onwards, plus the name object has it's own copy of const char* above. Is it possible/already done by compiler to avoid keeping const char* like above?

What do you mean by "avoid keeping const char* like above"?
The string constructor copies the string into its own buffer, so there's no worries.

I would believe it would still exist until the program ends. It's most likely stored somewhere in the executable, I think (some section).

Quote:

---

Originally Posted by manav

I mean the const char* has served it's purpose now, so should compiler keep it in program read-only memory, or delete it?

---

You're not a compiler. Why do you assume a compiler is stupid? Compilers are written by people much cleverer than most of us. :)
There is one copy in memory and one copy on disk, that's more than you need to know.

Yeah right, like it's a lot :rolleyes:
Plus if you have several lines using the same string, the compiler can optimize them to use the same string. And then there's a question of how long they're going to use that constant pointer or string. The compiler cannot know unless it does a very advanced analyzing of all the code, and can you tell a compiler that can do that? I can't.

Yes, 11 bytes "wasted" is a lot :rolleyes:
Try writing your own compiler for that matter and see how well you can do it.

It didn't seem like that to me. It seemed more like you were worried or complaining about how the compiler kept "unnecessary" data in memory...

I'm a little bit curious as to how you want to solve this problem. The "No name" string HAS TO EXIST at the point when you create the string from it.

The only solution, which seems unreasonable, is that the compiler would understand how to construct a string implicitly, without a char * to create it from - so the compiler would have to produce the code to allocate memory (or store it in the "short string storage"), and somehow then fill that memory with the string. And, most importantly, it should perform all of this, using less than 11 bytes of code and data space. I find that very unlikely to happen.

--
Mats

There's no pointer to store. Your overhead is 8 bytes for the literal. And if you have enough literals to fill a memory page, and they're all only used at the start of the program, the OS will later page out or even drop the page and you'll have no overhead from the strings.

Is this thread missing some context?

manav decided to delete his posts.

Actually, I think what manav is actually suggesting is a variant of string that just stores the orignal string from the constructor [which, you could certainly do that internally]. But if all you really want is a constant textstring, then you probably don't really need to wrap it in a string object in the first place.

The complication of storing the original literal string is that there's no way for the class to quite know when the string is a literal, and when it's just some other const char * value. E.g.

Code:

---

void func(string &s)
{
    char blah[] = "Abcdef";
    const char *pb = blah;
    s = string(pb);
}

---

How does the string implementation know that the const char * here is not a literal, but rather a string stored on the stack in a function, and then goes away when the function returns?

--
Mats