Working Dev C++ code won't work in Visual C++

[erikn]

In C++11 std::string is null terminated and you can treat it as such except when using iterators. VC++ has apparently not updated this yet.

yeah, i'd thought that C++ std::strings were built from C strings and therefore were null-terminated as well

[Moschops]

yeah, i'd thought that C++ std::strings were built from C strings and therefore were null-terminated as well

They are. My code above demonstrated that. The problem had nothing to do with that.

[erikn]

Athar:

The difference that in that example, it's a C string and those are null-terminated by definition. That means "Hello!" is an array of 7 characters - 6 for Hello! and a final '\0'. That's not true for C++ strings. When you assign "Hello!" to a std::string, it will contain 6 characters, not 7.

is it just me or are you guys disagreeing about this?

and Moschops, you were correct in assuming my current VC setup wouldn't like your code. I got the same Assertion Failure I got with mine. Was that what you were trying to demonstrate?

[erikn]

...or is the difference that the null is assumed and acknowledged by the compiler with C strings, but not with C++ strings? forget it, i'm taking my damn solved marker down :(

[Moschops]

I must have not been clear enough.

A C++ string will be, at heart, an array of characters with a null termination. That null termination does not count as part of the string's user-accessible data, in that if you ask the string what size it is, the size will not include the null termination. To access it directly using the [] notation, you'd have to access stringobject[size+1] which I believe the Microsoft debug runtime stomps all over (based on what your error was). (EDIT: SEE CORRECTION BELOW, SHOULD READ ...to access stringobject[size] which I...)

There has to be null termination there, because when you use the string::c_str() function, you get back a pointer to the first element, and you can treat that just like an old-school C-string with null-termination. This kind of old-school access is not stomped on by the MS debug runtime.

There is no argument; there is an array of char buried in the std::string, it will have a 0 value on the end of it, you should not be directly accessing that 0 value with the [] notation applied directly to the string object because the MS debug runtime doesn't like it.

Was that what you were trying to demonstrate?

Yes. Some other runtimes are very happy with it. I suspect that if you run it not in debug, your system will also be happy with it.

[Peter87]

Moschops, You mean stringobject[size] and not stringobject[size+1]. stringobject[size] is fine in C++11 as long as you don't write to it.

[erikn]

I suspect that if you run it not in debug, your system will also be happy with it.

i just did and it didn't. same Assertion Failure, no debugger...

[Athar]

Then you're still using debug iterators. #define _SECURE_SCL 0 turns them off.
I just tested it with VS2008 and it does not throw an exception when accessing str[size], meaning your problem is likely somewhere else.

[erikn]

Moschops, You mean stringobject[size] and not stringobject[size+1]. stringobject[size] is fine in C++11 as long as you don't write to it.

this is what i thought

[Moschops]

Yeah, sure, you get the point. One off the end.

Man goes to the doctor, and says, "Doctor, every time I do this, it hurts." The doctor turns to him and says "Well stop doing it then!"

[erikn]

Then you're still using debug iterators. #define _SECURE_SCL 0 turns them off.

added that line, ran w/out debugging, still assertion failure.

[Moschops]

Man goes to the doctor, and says, "Doctor, every time I do this, it hurts." The doctor turns to him and says "Well stop doing it then!"

[erikn]

Moschops, this is your code I'm trying to run at this point....

[Moschops]

My code was a simplest possible demonstration that your system won't run it. Your system won't run it.

[erikn]

My code was a simplest possible demonstration that your system won't run it. Your system won't run it.

Right, I'm well aware of that. It is, after all, the title of this thread.
My real question was why.

Look, the last thing I want to do is come off snarky. You guys obviously know more about this than I do, which is why I came here for help. I'd rather understand why something doesn't work than just "not do it", but I don't want to piss you off either because you'll be less willing to help me with more complicated things in the future.

I thought, as Peter87 does, that it was ok to access stringobject[size] as long as I don't write to it, but what I'm now understanding from this thread is that I can't because of something related to how my VC++ is configured. And it has nothing to do with the debugger.

[Athar]

Have you really confirmed that the problem is in that function?
In other words, does

#include <string>
int main() {std::string("Hello!")[6];}

still cause it?

[Moschops]

And it has nothing to do with the debugger.

There's a difference between the debugger and a debug runtime error. The debugger is a program that you can use to interrogate your processes mid-execution. A runtime is a set of library functions and support code that enables your code to actually work. Microsoft's (debug?) runtime, so far as I can tell, is a runtime filled with helpful things to stop you making mistakes; this seems to be one of those things it doesn't like people doing.

I understand Microsoft provides a debug runtime, full of helpful things, and a normal runtime, not full of helpful things.

[erikn]

Have you really confirmed that the problem is in that function?
In other words, does

#include <string>
int main() {std::string("Hello!")[6];}

still cause it?

yup, even that little snippet.

[erikn]

...however,

#include <string>
int main() {std::string("Hello!");}     // I removed the subscript 

does not.

[Athar]

Well, it's not surprising if you don't try an out-of-bounds access.

Considering it does not happen in VS2008, but it does happen in VS2010, it seems likely that it's not a bug, but rather intentional. I suppose they figured accessing the '\0' after the string is usually the result of an off-by-one error and rarely intentional. If so, they're right.