std::string help!!!!

When you say the first ''works'' and the second doesn''t, what do you mean? I assume it compiles as you''re debugging it. So what''s wrong? Does it not copy anything, or does it chop the string off at "ork"?

I think your string implementation may be using a buffer of length 16 as this has come up before. I can''t rememeber what the resolution was.

Have you tried replacing the _T() with string().

When you say a similar signature do you mean that in the ''exactly the same'' sense or in the ''slightly different'' sense?

What compiler and implemntation are you using?

_T is a macro for ASCII/Unicode API selection.

If you're using Unicode string literals, you need to use std::wstring, not std::string.

And as petewood hinted, objects that own memory don't lend themselves to being passed to libraries well. In this case, you're better off passing a const char*

---

[ Start Here ! | How To Ask Smart Questions | Recommended C++ Books | Free C++ IDE. ]
[ Header Files | File Format Docs | LNK2001 | C++ STL Doc | STLPort | Boost C++ Lib ]

[edited by - Fruny on December 12, 2002 3:44:59 AM]

I just checked and what Fruny is saying is right.

The _T will be replaced by the correct type depending on whether or not you are using UNICODE. On my implementation your code won't compile at all if _UNICODE is defined as it can't convert between unsigned short and char. std::string needs to be replaced by the correct type. And if you're using cout it needs to be wcout etc.

Maybe you should typdef your own string class that could be swapped depending on whether you're using unicode.

#ifdef CHAOS_UNICODE
typedef std::wstring chString;
#else
typedef std::string chString;
#endif

and use chString instead.

There's probably a facility to do this already. Any ideas anyone?

If, actually, you don't want unicode at all then just leave out the _T in the original sample code. As it stands it won't compile if you try to make use of it anyway. The _T is currently redundant and being removed by the preprocessor.

I know this doesn't solve your main problem!

[edited by - petewood on December 12, 2002 4:49:24 AM]

I assume you''re on Visual Studio .NET? The STL there has two different "buffers" for strings. _Buf is a static, 16 byte buffer, for small strings. It removes the need to allocate on the heap for small things. _Ptr is used for strings longer than 16 characters, and gets it''s memory from the heap.

Now, I''m not sure what you mean by "doesn''t work", but are you using a DLL for you library? If the string is constructed in the main program, but destroyed in the DLL, this''ll cause errors, because they can be using different heaps. It''d work in the first case, since it uses a buffer on the stack, not the heap.

Of course, the fact that you''re passing references pretty much rules that out - unless you''re mixing inline with non-inline code...

More information would be appreciated, though. What sort of errors are you getting?

If I had my way, I''d have all of you shot!

---

codeka.com - Just click it.

ok thanks for all the responses
unicdoe is NOT defined so that's not the problem. The _T is leftover from other coders work.
It DOES compile, but the string is not copied into the object in the second case

the 2 signatures are



Yes I'm on VX.Net and no, the library is a staticly linked .lib

Basically the error is as follows
pNxPanel->SetText(_T("Panel Heading"));
the string in pNxPanel is now "Panel Heading"

pNxListBox2->AddItem(_T("Nexus GUI Framework"))
the string in pNxListBox2 is "D-9" or something equally random.

both pNxPanel and pNxListBox2 are created on the heap

One other thing.. the application uses a multi threaded socket class, but I don't think that uses std::strings

[edited by - ChaosEngine on December 12, 2002 5:54:19 PM]

arrrggghhh!!!! nevermind....std::string is actually functioning as it''s supposed too. The error was caused by a bit of code one of my idiot minions wrote....I think a smiting is in order!

quote:

---

Original post by ChaosEngine
arrrggghhh!!!! nevermind....std::string is actually functioning as it''s supposed too. The error was caused by a bit of code one of my idiot minions wrote....I think a smiting is in order!

---

Good job. Put one hit in on my behalf

---

[ Start Here ! | How To Ask Smart Questions | Recommended C++ Books | Free C++ IDE. ]
[ Header Files | File Format Docs | LNK2001 | C++ STL Doc | STLPort | Boost C++ Lib ]