1

This seems simple to me but I'm having trouble actually finding anything explicitly stating this.

Does std::string stringArray[3] not create an array of std::string objects, the way that SomeType typeArray[3] would? The actual number is irrelevant; I just picked 3 arbitrarily.

In the Visual Studio 2010 debugger, it appears to create a single string as opposed to an array of strings. Why?

Wild guess: is it calling the default std::string constructor, and then invoking an unused access of index 3? If so, why doesn't that cause an out of bounds exception on an empty string?

Does this have something to do with overloading the [] operator?

There are plenty of ways to code the same things without specifically using an array of std::string without issue, but what is the explanation/justification for this behavior? It seems counterintuitive to me.

Edit: I found this thread std::string Array Element Access in which the comments on the answer appear to observe the same behavior.

Community
  • 1
  • 1
taz
  • 1,506
  • 3
  • 15
  • 26
  • 6
    What leads you to believe it creates a single string? – chris Nov 03 '12 at 00:23
  • Because it does. Debugging through the code and examining the output, it is a single string. – taz Nov 03 '12 at 00:27
  • Why the downvote? I explained exactly what I was observing. I researched the topic first. I explained my possible interpretations. – taz Nov 03 '12 at 00:29
  • 3
    It would be helpful if you give us minimal example code where this behaviour supposedly occurs, along with its actual output and what you expect it to output. – Dylan Nov 03 '12 at 00:29
  • 2
    You didn't explain what you're observing (until your comment just now). You said it appears to create one object, without saying why you think that. Since it _doesn't_ create a single object, you must be misinterpreting something, but you didn't give enough info to guess what. – Jonathan Wakely Nov 03 '12 at 00:30
  • I didn't specify how it appeared that way because this is such an incredibly simple scenario. It didn't occur to me that there could be a discrepancy in what I was seeing in the debugger and what I was expecting to be in the memory. There are only so many ways to directly check the content of a single variable declaration. I guess this is a lesson to future readers that even when you think you are viewing the contents of allocated memory there can be a layer of obfuscation, and that debuggers aren't necessarily reliable. – taz Nov 03 '12 at 00:46
  • @taz: -1, for providing so little info that people had to *guess* at what the actual problem might be. – Nicol Bolas Nov 03 '12 at 01:10
  • @taz, your question didn't even _mention_ a debugger, you only said "debugging" in a comment. You didn't say Visual Studio (VC2010 is a compiler not debugger or IDE) and you didn't say "when displaying the variable in the debugger". You could have been trying to print values with `printf` or something completely different, you gave no clues. _"There are only so many ways to directly check the content of a single variable declaration."_ nonsense ... using a debugger is not the only way, **and you didn't mention using a debugger anyway** – Jonathan Wakely Nov 03 '12 at 01:27
  • @JonathanWakely I didn't mean that using a debugger is the only way. I meant that my test program was literally a main function and a single assignment, which I examined in the debugger. I should have edited the question to specify the debugger instead of leaving that information in the comments. I have edited the original post. – taz Nov 03 '12 at 01:33
  • downvote removed, the question has enough context to be useful now IMHO – Jonathan Wakely Nov 03 '12 at 01:39

4 Answers4

6

Visual studio's debugger will often show you only the first thing an array or pointer points to. You will have to use stringArray[1] stringArray[2] etc to see farther than that.

Dan
  • 12,409
  • 3
  • 50
  • 87
  • I'm going to wager that this is what the OP is observing and misinterpreting as well. You may want to mention how exactly you can view other elements of an array in the VS debugger. – Dylan Nov 03 '12 at 00:35
  • This is indeed what happened. While I was aware that the debugger behaves this way, I was under the impression that for a variable declared as a sized array (as opposed to as a pointer) once each index was actually defined the debugger would display it that way, as it did for an array of a different type I had declared right alongside it in the code. This is not the case; I don't know when the debugger will display only the contents of the index of a pointer and when it will display an array type. – taz Nov 03 '12 at 00:39
4

The OP is NOT losing his mind. But Visual Studio's integrated debugger certainly is. I believe this is a bust in the detection of operator [] for std::string, which is sad However, it does work correctly for std::vector<std::string>

An excellent reference to how you can get around this using the watch-window (no way to do it using the Auto or Locals window afaik) can be found at this previously posted question. This is also an extremely helpful method for viewing pointer-based dynamic arrays (arrays allocated with Type *p = new Type[n];). Hint: use "varname,n" where varname is the variable (pointer or fixed array), and 'n' is the number of elements to expand.

A demonstration is in order to show a declared C-array of std::string and what the OP was observing, and a std::vector<std::string> to show what things should look like:

int main(int argc, char *argv[])
{
    std::string stringArray[3];
    std::vector<std::string> vecStrings(3);
    return 0; // set bp *here*
}

enter image description here

Community
  • 1
  • 1
WhozCraig
  • 65,258
  • 11
  • 75
  • 141
  • Agreed, but I think it is equally brain dead for std::vector. It works for POD types though. – zdan Nov 03 '12 at 00:44
  • Wow, thanks! I didn't know I could post screen caps here or I would've done that in my original post! – taz Nov 03 '12 at 00:48
  • @zdan If you mean `std::vector myArray[10];` is a bust as well, I'm not at all surprised. – WhozCraig Nov 03 '12 at 00:49
  • @WhozCraig Yup that's what I meant. – zdan Nov 03 '12 at 00:50
  • @taz **please** don't capture whole screens and post them =P. As small a snippet of graphics as possible, and then only because it is *directly* relevant to the question. lets keep the disks at SO happy. – WhozCraig Nov 03 '12 at 00:50
2

It creates an array. Either you compiled something different or you misinterpreted the results.

It doesn't create an array in these contexts:

void function(std::string stringArray[3]) { }

This function parameter is a pointer to std::string, you can't have function parameters of array type.

extern std::string strnigArray[3];

This declares but doesn't define an array. It tells the compiler there is an array of three strings somewhere in the program call stringArray but doesn't actually create it.

Otherwise, it creates an array of three strings.

You can check that with:

assert( sizeof(stringArray) == 3*sizeof(std::string) );

or in C++11

static_assert( sizeof(stringArray) == 3*sizeof(std::string), "three strings" );
Jonathan Wakely
  • 166,810
  • 27
  • 341
  • 521
0

Yeah the debugger in VS 2010 doesn't do a great job here, but as others have said, it's only a display issue in the debugger, it does work as you'd expect.

In VS 2012 they've done a much better job :-

enter image description here

jcoder
  • 29,554
  • 19
  • 87
  • 130