When I do this in C++:
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?Code:std::string name("No Name");
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.
Originally Posted by Adak
I would believe it would still exist until the program ends. It's most likely stored somewhere in the executable, I think (some section).
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.
My homepage
Advice: Take only as directed - If symptoms persist, please see your debugger
Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"
Yeah right, like it's a lot
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
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
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
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.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
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.
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?Code:void func(string &s) { char blah[] = "Abcdef"; const char *pb = blah; s = string(pb); }
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
