0

I'm using std::string for it's memory management and efficiency to store location relative data.

The std::strings are being initialized with lengths of 30 bytes, and after that will never have any calls made to their container aside from maybe the destructor.

What I want to know is if they are guaranteed to stay in one place after they've been initialized assuming they will never be changed?

Improve this question
6
  • See here: "The pointer obtained from c_str() may be invalidated by: Passing a non-const reference to the string to any standard library function, or Calling non-const member functions on the string (...)" Commented Jan 6, 2014 at 16:38
  • I did pass a non-constant reference to a char* for the initialization, but it should just copy that data and be fine I'm assuming after that. Commented Jan 6, 2014 at 16:40
  • Read your reference, but luckily I wont be passing or calling member functions (aside from c_str()) after the initialization, and any access will take place from that pointer. Commented Jan 6, 2014 at 16:47
  • In which case you should also take care to note that "writing to the character array accessed through c_str() is undefined behavior". Which really goes without saying, because you have to cast away the const-ness Commented Jan 6, 2014 at 16:51
  • If the lengths are always fixed, std::array<char, 30> might be more appropriate. They are guaranteed to stay in one place regardless of what some idiot maintenance programmer decides to do with them. Commented Jan 6, 2014 at 17:27

3 Answers 3

Reset to default
2

If by move, you mean that the internal pointer to the string of characters might be changed, then no, that should not happen as long as you don't call any non-const string methods.

One caveat, however, is that if you use a non-simple allocator, the allocated memory may be changed by that allocator, regardless of how you interact with the string. Normally, though, the simple allocator is used and the contents of the allocated memory and the pointer to that memory should not spontaneously change.

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

std::string(data,30); where data is char*, 30 being size_t. After that any read access would need to take place directly from the internal pointer. This is how the creation and access are happening.
1

Unless you modify the string somehow the address of its dynamic data should will not change. I strongly recommend that you use a const std::string in the case you describe for better readability and maintainability.

Improve this answer

Comments

0

This sounds as if you might want to use std::unique_ptr<char[]> instead of std::string. That makes the fact that you're not actually storing a string, but only want automatic destruction, explicit.

Improve this answer

7 Comments

Don't need automatic destruction in this case, the objects are being created dynamically and would be destructed by the code explicitly. Thanks though
Trying to avoid writing an entire container just for efficient memory management of something that would be best suited in a simple C array
@Nowayz It really isn't my business, but now you've made me curious - why, then, doesn't std::unique_ptr<T[]> suit your needs? It takes care of managing a dynamically allocated array of Ts...
It would work, I just don't want it to destroy when it goes out of scope.
@Nowayz Ah, OK, you don't want it to call the T's destructor. So I'm guessing, you currently use placement new to construct the objects within the memory allocated by std::string, and manually call the destructor later to destroy them?
|

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.