Sign in to follow this  
Raeldor

C++/CLI std::wstring behaving VERY strangely in release build

Recommended Posts

Hi All, This works fine in debug mode, but in release mode I am getting errors thrown when passing std::wstring from managed to un-managed. I narrowed it down to one line...
		std::wstring name2=L"test";

which in the debugger in debug build says {"test"}, but in release mode it says {"st"}. Something very strange is going on here. Can anyone shed some light? Thanks Rael

Share this post


Link to post
Share on other sites
To add to this, when I try and call my unmanaged function with...

m_node=new NW::Node(L"test");


it works fine in debug mode, but in release mode it blows up with unknown software exception.

Share this post


Link to post
Share on other sites
Here's another interesting tidbit. If I change from Multithreaded DLL to Multithreaded debug dll in the c++ code generation options, it works. If I change back... it stops working again.

Share this post


Link to post
Share on other sites
Well, the problem could lay in L##quote (the macro used to change from wide to ansi strings).

I guess to help further, we'd need more info... =[ what are the errors exactly?

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
C++/CLI was a terrible idea to begin with, and Microsoft seems to agree. Death of the monstrosity is imminent. Please migrate any source code you might have using it to something else before it's too late.

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
C++/CLI was a terrible idea to begin with, and Microsoft seems to agree. Death of the monstrosity is imminent. Please migrate any source code you might have using it to something else before it's too late.


Don't be a retard.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by MENTAL
Quote:
Original post by Anonymous Poster
C++/CLI was a terrible idea to begin with, and Microsoft seems to agree. Death of the monstrosity is imminent. Please migrate any source code you might have using it to something else before it's too late.


Don't be a retard.


You think writing new code for C++/CLI sounds like a good idea?

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Let's not kid ourselves. C++/CLI is a combination of the worst parts of C++ and the worst parts of .NET. If this isn't the worst programming environment ever created already, add some special syntax to make the already complex C++ syntax even worse, and you sure are pretty close to it.

We all know, and Microsoft also knows, that it was intended entirely as a stop gap measure to get people to quickly move their existing C++ code to .NET. But the idea is that after that is done, you can move it piece by piece to a real .NET language later.

Writing new code in it is just wrong.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
i don't even want to comment on the stuff the previous anon said..

but Raeldor, it seems to me that your problem is something simple like not having defined UNICODE in release mode or something like that.
If it works in debug and doesn't in release and is related to the 'L' string prefix its likely to be the fault of some configuration problems.

Share this post


Link to post
Share on other sites
Quote:
Original post by Raeldor
Hi All,

This works fine in debug mode, but in release mode I am getting errors thrown when passing std::wstring from managed to un-managed. I narrowed it down to one line...
*** Source Snippet Removed ***
which in the debugger in debug build says {"test"}, but in release mode it says {"st"}. Something very strange is going on here. Can anyone shed some light?

Thanks
Rael

You can't rely on the debugger to look the variable state in release mode - optimization destroys much of the meaning of the values you get.

Concerning your bug, I'd say that the bug is also present in debug, but that it is probably hidden by some other thing (such as pre-initialized memory buffers and so on). Run your code through a bound-checker like tool, you'll likely find some other problems.

@Anonymous Poster: if writing new code in C++/CLI is a Bad Idea, how do you migrate the code you wrote in unmanaged C++ to your managed code base? You discard it and rewrite it in C#, trying to keep your customer happy while you are wasting his money?

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by Emmanuel Deloget
@Anonymous Poster: if writing new code in C++/CLI is a Bad Idea, how do you migrate the code you wrote in unmanaged C++ to your managed code base? You discard it and rewrite it in C#, trying to keep your customer happy while you are wasting his money?


Hi. I think you should read the post again, since you obviosly missed the point of it. "New code" isn't old code you are moving to .NET, new code is... NEW CODE. If you read the post again, you will notice that I said the only thing it's good for is migrating existing C++ code to .NET.

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
Quote:
Original post by Emmanuel Deloget
@Anonymous Poster: if writing new code in C++/CLI is a Bad Idea, how do you migrate the code you wrote in unmanaged C++ to your managed code base? You discard it and rewrite it in C#, trying to keep your customer happy while you are wasting his money?


Hi. I think you should read the post again, since you obviosly missed the point of it. "New code" isn't old code you are moving to .NET, new code is... NEW CODE. If you read the post again, you will notice that I said the only thing it's good for is migrating existing C++ code to .NET.


You'll typically leave your C++ codebase intact, meaning that you'll have to write the glue between your C++ components and your C# components. What kind magic of truely amazing magic do you use if you achieve to do this without writing new code?

The situation is the same when you just bought a C++ DLL and want to create a managed interface for this DLL. In this case, it is even more clear, as you didn't wrote the code of the DLL - thus, you still end up by writing new code.

Another situation that can arise is that you want to stress the last bits of your computer and you don't trust the CLI. You need "teh fastar" C++ (maybe with mixed asm), but you'll provide some glue to mix you code withing your managed application.

Whenever you have to create some software between a C++ code base and a managed software, you need to write new code - and C++/CLI perfectly fit the bill, as it has a foot in both worlds. You are perfectly free to ignore that. But don't tell us that C++/CLI is a dead beast - or if you do, provide sources. Without them, it is just another absurd AP claim.

Regards,

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by Emmanuel Deloget
But don't tell us that C++/CLI is a dead beast - or if you do, provide sources. Without them, it is just another absurd AP claim.


But you agree yourself that it's of limited use. If it's of limited use already now, it won't exactly become more useful with time. By your own admission it is dying. And you can't deny that it is one of the ugliest languages ever, syntax wise. That isn't helping its case either.

I know you like to troll APs, but tone it down a little. It becomes a little too obvious when you mention them by name.


Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
Quote:
Original post by Emmanuel Deloget
But don't tell us that C++/CLI is a dead beast - or if you do, provide sources. Without them, it is just another absurd AP claim.


But you agree yourself that it's of limited use. If it's of limited use already now, it won't exactly become more useful with time. By your own admission it is dying. And you can't deny that it is one of the ugliest languages ever, syntax wise. That isn't helping its case either.

I know you like to troll APs, but tone it down a little. It becomes a little too obvious when you mention them by name.


Sorry, but it's patently obvious that you're the one trolling here, and while it may be that I have been trolled, I certainly have not lost. (Not to mention, what "mention by name" do you infer from "just another absurd AP claim"?)

If you actually are interested in making a rational argument, then (a) why not register? and (b) please do make such an argument.

Share this post


Link to post
Share on other sites
Yikes, I didn't mean to start WWIII here. :S

I found the problem... I am a moron. I copy+pasted the library directories from debug to release so it was using the debug versions of the libraries, which I guess doesn't work too well when you try and pass across wstring(s) created with the non-debug version.

As far as C++/CLI goes, I am not using C++/CLI for anything other than wrapping my unmanaged code. C++ unmanaged is is great for game programming, but c# is better for UI programming (so tools are nice as a blend of managed/unmanaged). C++/CLI seems to not be good at either, but is a great glue tool, which is probably what MS intended it for.

Just my 2c.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this