[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 290
  • Last Modified:

When references, pointers, and iterators to a string become invalid

From the standard I gather that references, pointers, and iterators to a string become invalid after:

calling any non-const member functions (with the exception of [], at, begin, end, rbegin, rend)

calling data or c_str

the first call to non-const functions [], at, begin, end, rbegin, rend

However, what isn't immediately obvious is that the standard defines compare() as:

traits::compare(data(), str.data(), rlen);

And most string implementations use compare() in the comparison operators.

So can one add to that list all of the compare() overloads and comparison operators?

Is that a justifiable statement? And might there be any more exceptions?

Thanks,
-Sandra
0
Sandra-24
Asked:
Sandra-24
1 Solution
 
jkrCommented:
>>So can one add to that list all of the compare() overloads and comparison operators?

Give me a reason why a comparison is not "const"  regarding the objects being compared and I will say "no" - I guess it is a "yes", though :o)

In other words: Do not rely on the 'const' keyword alone. But, saying that, I start to wonder why there are no 3 'const' overloads for all 4 combinations of comparison...
0
 
jkrCommented:
>>Is that a justifiable statement?

Forgot to write "yes".
0
 
stefan73Commented:
Hi Sandra-24,
> calling data or c_str

Why should calling c_str invalidate a pointer or reference? Or even an iterator?

Cheers,
Stefan
0
Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

 
jasonclarkeCommented:
> Why should calling c_str invalidate a pointer or reference?

Realistically it probably will not invalidate the pointer.

However, the standard allows for the fact that the string could be implemented such that an internal representation may not occupy contiguous storage - e.g. while building a string it could store different sections of the string in multiple places.

However, when the buffer returned by c_str/data must be contigous, so in such an implementation, at this point the class would have to reallocate some contiguous space for the string.
0
 
Sandra-24Author Commented:
Comparison operations SHOULD be const. Any string implementation with a data() function that invalidates pointers,references, or iterators SHOULD not call data() in their comparison operators as the standard seems to hint. However, as far as the standard is concerned, a string implementation could behave this way. Realisticaly it's probably only a concern to implementors of STL strings. I would have to think that any place where data() must be mutating in a way that invalidates references (and I really can't think of one!) that the programmers would have been clever enough to design a compare function that is non-mutating (i.e. doesn't use data() internally). However, the good folks that created the standard must have envisioned a possible scenario (I would hope they didn't just add the rule for fun) where data() could invalidate references, pointers and iterators.
0
 
jasonclarkeCommented:
>  However, the good folks that created the standard must have envisioned a possible scenario

There is quite a lot of evidence that they messed up in the design of the string class (e.g. see this reference: http://www.gotw.ca/gotw/084.htm ).

I think that were they starting again,  std::string might be more prescriptive in design, but would be a lot simpler...  This is the kind of thing that C++ detractors can point to as evidence of how pointlessly complicated the language is - this is only a string, after all.
0

Featured Post

Free Tool: IP Lookup

Get more info about an IP address or domain name, such as organization, abuse contacts and geolocation.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now