Converting from std::string to System::String^
-
Hello everyone... Im just starting a new project using C++/CLI. Can some one please tell me why this code does not work?
std::string nativeStr = "Hello World";
String^ managedStr = nativeStr.c_str(); // error C2440: 'initializing' : cannot convert from 'const char *' to 'System::String ^'but this code does work
std::string nativeStr = "Hello World";
String^ s6 = gcnew String(nativeStr.c_str()); // works!howevet i want to be able to create my managedStr on the stack, and would expect this to work.. Can anybody tell me where i am going wrong
-
Hello everyone... Im just starting a new project using C++/CLI. Can some one please tell me why this code does not work?
std::string nativeStr = "Hello World";
String^ managedStr = nativeStr.c_str(); // error C2440: 'initializing' : cannot convert from 'const char *' to 'System::String ^'but this code does work
std::string nativeStr = "Hello World";
String^ s6 = gcnew String(nativeStr.c_str()); // works!howevet i want to be able to create my managedStr on the stack, and would expect this to work.. Can anybody tell me where i am going wrong
flippydeflippydebop wrote:
i want to be able to create my managedStr on the stack, and would expect this to work
Then you don't understand how the .NET Platform works. Try reading some introductory programming articles on MSDN[^] Actually there might even be some here on CodeProject if you care to look.
led mike
-
Hello everyone... Im just starting a new project using C++/CLI. Can some one please tell me why this code does not work?
std::string nativeStr = "Hello World";
String^ managedStr = nativeStr.c_str(); // error C2440: 'initializing' : cannot convert from 'const char *' to 'System::String ^'but this code does work
std::string nativeStr = "Hello World";
String^ s6 = gcnew String(nativeStr.c_str()); // works!howevet i want to be able to create my managedStr on the stack, and would expect this to work.. Can anybody tell me where i am going wrong
flippydeflippydebop wrote:
howevet i want to be able to create my managedStr on the stack, and would expect this to work..
LedMike has the correct answer. To add...creating a managed object on the stack is a redundant/silly concept. It's all about scope here. Creating it the way you've shown in the working sample gives it the same scope as a stack variable. Mark
"If you can dodge a wrench, you can dodge a ball."
-
flippydeflippydebop wrote:
howevet i want to be able to create my managedStr on the stack, and would expect this to work..
LedMike has the correct answer. To add...creating a managed object on the stack is a redundant/silly concept. It's all about scope here. Creating it the way you've shown in the working sample gives it the same scope as a stack variable. Mark
"If you can dodge a wrench, you can dodge a ball."
well hang on then guys... Why does this:
System::String^ myStr = "hello"
Work fine even though i do not use the gcnew operator to allocate the string 'myStr' on the heap? What i am saying is that i know in the .net world everything is allocated on the heap and that the above statement, even though it appears to reside on the stack is probably being allocated on the heap.. Now if the compiler lets me write code like above, then why wont it let me write code like this:
String^ managedStr = nativeStr.c_str();
The above line fails.. Instead in this instance i have to explicitly allocate the variable managedStr on the heap like so: String^ s6 = gcnew String(nativeStr.c_str()); // works!
-
well hang on then guys... Why does this:
System::String^ myStr = "hello"
Work fine even though i do not use the gcnew operator to allocate the string 'myStr' on the heap? What i am saying is that i know in the .net world everything is allocated on the heap and that the above statement, even though it appears to reside on the stack is probably being allocated on the heap.. Now if the compiler lets me write code like above, then why wont it let me write code like this:
String^ managedStr = nativeStr.c_str();
The above line fails.. Instead in this instance i have to explicitly allocate the variable managedStr on the heap like so: String^ s6 = gcnew String(nativeStr.c_str()); // works!
When you do this
System::String^ myStr = "hello"
myStr gets a reference to a pointer that already exists in the app's (assembly's) user strings metadata section. When you do this
String^ managedStr = nativeStr.c_str();
a System::String constructor is required. To use the constructor the object needs to be created on the managed heap. I tracked down a better description than I could possibly give: Scroll to the second question/answer here[^] Hope that helps! Mark
"If you can dodge a wrench, you can dodge a ball."
-
well hang on then guys... Why does this:
System::String^ myStr = "hello"
Work fine even though i do not use the gcnew operator to allocate the string 'myStr' on the heap? What i am saying is that i know in the .net world everything is allocated on the heap and that the above statement, even though it appears to reside on the stack is probably being allocated on the heap.. Now if the compiler lets me write code like above, then why wont it let me write code like this:
String^ managedStr = nativeStr.c_str();
The above line fails.. Instead in this instance i have to explicitly allocate the variable managedStr on the heap like so: String^ s6 = gcnew String(nativeStr.c_str()); // works!
Yes because "hello" is treated as the type (System.String) by the CLI compiler. Look at the MSIL code to see the difference. Also note that:
System::String^ myStr = (const char*)"hello";does not work. See Stan Lipman's blog[^] The insight to resolve this is to realize that the dual citizenship of a string literal applies to its fundamental type, not to its set of trivial conversions. In effect, under C++/CLI, the underlying type of a string literal such as "Pooh" is both const char[5] (its native inheritance) and System::String (its managed underlying unified type). Under C++/CLI, the string literal is an exact match to System::String and the trivial conversion to const char* is not considered. That is, under the revised C++/CLI language specification, the ambiguity has been resolved in favor of System::Stringled mike
-
Yes because "hello" is treated as the type (System.String) by the CLI compiler. Look at the MSIL code to see the difference. Also note that:
System::String^ myStr = (const char*)"hello";does not work. See Stan Lipman's blog[^] The insight to resolve this is to realize that the dual citizenship of a string literal applies to its fundamental type, not to its set of trivial conversions. In effect, under C++/CLI, the underlying type of a string literal such as "Pooh" is both const char[5] (its native inheritance) and System::String (its managed underlying unified type). Under C++/CLI, the string literal is an exact match to System::String and the trivial conversion to const char* is not considered. That is, under the revised C++/CLI language specification, the ambiguity has been resolved in favor of System::Stringled mike
ahh-haaaa... i see (said the blind man). Well, guys it would seem i need to do some more reading of the subject material. Thankyou both for taking the time to reply. :)