c++ identifier "Luservar" is undefined

Question

I am writing a little app that uses SMTP.

And I got a weird error:

identifier "Luservar" is undefined`

code:

o_smtp->BodyText = _T(uservar->get_h().c_str() + ":" + pass_str.c_str() + "\n" + get_mac().c_str());

Why is it saying Luservar if i say uservar?

I have tried:

o_smtp->BodyText = uservar->get_h().c_str() + ":" + pass_str.c_str() + "\n" + get_mac().c_str();

But then I get a error like this: expression must have integral or unscoped enum type

I am fairly new to C++ and maybe its the wrong way to merge strings?

`c_str()` usually returns a `const char*` - you cannot merge those with other `const char*` "strings" using `+` — UnholySheep, Jul 07 '20 at 08:45
`_T` can only be applied to `"literals"` - Applying it to arbitrary expressions is not going to work — StoryTeller - Unslander Monica, Jul 07 '20 at 08:47
You shouldn't be using `_T` anyway. It's 2020 - use UTF-8 everywhere! (Or at least use `wchar_t` with UTF-16 consistently in your code for Win32). `_T` is to allow you to recompile for the (obsolete, horrible, ill-advised, and demonic) MBCS vs. ANSI vs. "Unicode" world we had in the late-1990s. It's completely wrong to use it today. — Dai, Jul 07 '20 at 08:52
What SMTP library are you using? What is the type of `o_smtp` and `o_smtp->BodyText`? — Dai, Jul 07 '20 at 08:59

score 4 · Accepted Answer · answered Jul 07 '20 at 09:07

DO NOT USE _T or TEXT(). Yegods.
- These are positively ancient and obsolete macros that Microsoft absolutely needs to remove from Windows.h (and they should have removed them decades ago).
  - Even Raymond Chen, everyone's favourite Win32-centric blogger, doesn't know why _T exists!
- Just make sure #define UNICODE is enabled in your project properties and forget about the past.
If you're writing C++ (with classes and objects, and using types from the STL and C++'s standard library), then you shouldn't be writing C (by using typedefs, structs and raw pointers).
- Remember that C++ and C are different languages despite their syntactic similarities and C++'s heritage in C.
- Fun fact: Microsoft's VisualC++ is not a C compiler - it only supports the parts of C needed to compile C++: Does Visual Studio 2017 fully support C99?
- What I mean by this is that if you're using std::string then you should not use .c_str() unless you really have to - and in this case, you don't have to (well, not for string-concatenation at least).

As for your code...

I assume these variables and function return-values are typed as std::string:
- uservar->get_h()
- pass_str
- get_mac()
I assume that o_smtp->BodyText is typed as char*.
I assume that you simply want a concatenate those strings together, along with the literals in your C++ code.
- In which case, let std::string do the concatenation for you!

std::string bodyText = uservar->get_h() + ":" + pass_str + "\n" + get_mac();

o_smtp->BodyText = bodyText.c_str();

However you need to be careful about the lifetime of std::string bodyText - as soon as bodyText leaves scope then its c_str expires. See this thread: What is std::string::c_str() lifetime?

Remember that bodyText.c_str() provides a char* view of bodyText (i.e. it's a different representation of the same chunk of memory), rather than a copy of clone or bodyText, so if o_smtp->BodyText is long-life'd then you'll need to ensure bodyText has the same lifetime as o_smtp or copy bodyText's character buffer to a separate buffer that will live long enough - or determine if o_smtp will take ownership of its BodyText character buffer.

c++ identifier "Luservar" is undefined

1 Answers1