I have a member function that returns a reference to a CString member of the class. It looks something like this:
const CString& GetDateFormat() const { return MyString; }
I am using Visual Studio 2015 and whenever I type this function, the IDE automatically changes it to GetDateFormatA(). When I go to the function definition and hover over the function name I see this:
#define GetDateFormat GetDateFormatA
So it's like VS automatically created this macro.
The function works fine but I have already seen this multiple times (I mean a function — written by others — with a macro renaming it by appending an A) and I am quite curious and a bit confused. What's the purpose? Is it something related to character encoding or at least to strings?
GetDateFormat is a WinAPI function which takes at least one parameter whose type involves TCHAR (in this case, it's the parameters LPCTSTR lpFormat and LPTSTR lpDateStr). All such WinAPI functions actually exist in two forms: one with an A appended, and one with W appended. The A variant is used when TCHAR means char, and the W one is used when TCHAR means wchar_t. To support this, <windows.h> actually defines a macro for each such function, resolving to one or the other based on whether _UNICODE is defined. In your case, there's a definition somewhere in WinAPI headers similar to this:
#ifdef _UNICODE
# define GetDateFormat GetDateFormatW
#else
# define GetDateFormat GetDateFormatA
#endif
This is where your program's occasional reference to GetDataFormatA comes from. You can read more about working with TCHARs on MSDN.
How to solve this depends on whether you need to call WinAPI's GetDateFormat and use its char/wchar_t distinction. If so, you will have to rename your function. However, my impression is that you're not interested in the WinAPI function. In that case, a solution would be to add the following lines to your header which declares your GetDateFormat:
#include <windows.h>
#undef GetDateFormat
That way, nobody consuming your header will see the macro and GetDateFormat will remain GetDateFormat.
Related
<windows.h> defines macroses for Ansi and Unicode versions of WinAPI.
I have a function named SendMessage in my class library. It works fine until <windows.h> is included before including my library. In this case SendMessage is overrided by the macros and the function name becomes SendMessageA or SendMessageW.
Is it possible to somehow deal with it without changing the name of the function in order to save compatibility with older versions of the library?
The real problem is that WinAPI's function definitions are at the C-preprocessor level, and so you have to write some ugly code to try to coexist with them.
If at all possible, you should rename your codebase's functions so that there is no collision with WinAPI.
Otherwise, you can write code like #undef SendMessage to undefine WinAPI's definition of this function before defining your own function.
If you need to switch between defining your own functions and using WinAPI's function macros, you can also use the #pragma push_macro and #pragma pop_macro functionality to preserve the macro before the undef and restore it afterwards.
I've tried making a minimal testcase to reproduce it, but haven't been able to.
Adding a screenshot to show the error
this is the call to the SetClass function
m_luaState["MyClass"].SetClass<MyClass, I32>("AddTo", &MyClass::Add);
This is the MyClass:
class MyClass
{
public:
MyClass(I32 i) : m_i(i), m_j(2*i)
{
}
I32 m_j;
void Add(I32 iv)
{
std::cout << iv + m_i + m_j;
}
private:
I32 m_i;
};
Your RegisterClass(...) method name is being replaced by a Windows #define RegisterClass. Since you are compiling as ANSI, you are picking up the ANSI alias for RegisterClass which is RegisterClassA (it would be RegisterClassW if you were compiling Unicode).
You could either rename your RegisterClass(...) method if that's a viable option, exclude the conflicting Windows header (probably not an option), or conditionally #undef RegisterClass at the top of your header which declares your RegisterClass(...) method, something like:
#ifdef RegisterClass
#undef RegisterClass
#endif
Some additional reference about the conflicting symbol: RegisterClass function
This problem is actually quite interesting, and is nothing you have done wrong. It's because the RegisterClass Windows function and how Windows handle Unicode when programming.
Windows have two variants for almost all its function, if you see the table at the bottom of the linked MSDN reference you will see them mentioned as RegisterClassW and RegisterClassA. The W function is used for Unicode builds, where all strings and characters are of type wchar_t. The A variant is the "ANSI" variant, using normal char characters.
The problem here is that Windows uses macros to decide which of the funcitons to use, basically it does this
#ifdef UNICODE
# define RegisterClass RegisterClassW
#else
# define RegisterClass RegisterClassA
#endif
This is problematic because the preprocessor will replace your call to the RegisterClass member function with the RegisterClassA symbol, leading to your error.
The simple solution is to #undef the RegisterClass macro directly after including <windows.h> (or in some other suitable place). Another is to rename RegisterClass to something which doesn't clash with the Windows function.
I'm new to, and learning C++ (know a lot of Java) and the following code confuses me...
I know this code fragment is dealing with a pointer-to-function (it's a callback, that makes sense) but what is throwing me off is the argument between the return type and the function name. What the bloody hell is that?
It looks like a type of function, but I have never heard of that and even after searching and reading about pointer-to-functions I was not able to find anything mentioning that functions could have a type.
If this is true, how does one define a function type?
Thanks, -Cody
GLFWCALL is not a type, it's a macro which is expanded to a calling convention specific to the platform, or an empty string. Here's a trimmed fragment of glfw.h:
#if defined(_WIN32) && defined(GLFW_BUILD_DLL)
#define GLFWCALL __stdcall
#elif defined(_WIN32) && defined(GLFW_DLL)
#define GLFWCALL __stdcall
#else
/* We are either building/calling a static lib or we are non-win32 */
#define GLFWCALL
#endif
Using a correct calling convention is important on x86/win32, since some of them expect the stack to be cleaned by callee and others by the caller. There can also be differences in the order of passing the arguments.
On Windows, GLFWCALL is a macro for __stdcall, and on other platforms, it's a macro for nothing.
__stdcall implements a particular calling convention, and is a compiler extension on top of normal C or C++.
Macros are pieces of code that do replacements on your code before the lexer and parser of your compiler interact with them.
The GLFWCALL is a macro that can expand to a calling convention if one is needed. Because this function will be called by external code, it has to use the calling convention that external code expects. For example, if the function puts its return value on the stack and the external code expects it in a register, boom.
The question marked part of the function signature is a preprocessor macro that is defined somewhere else in the header. Certain features on certain platforms have extra requirements.
For example functions in DLL files on the Windows platform often make use of the __declspec(dllexport) modifier but when the same header is included in a user's project they need to use __declspec(dllimport). Using a preprocessor macro for that purpose means they can just use that macro on all relevant functions and simply define the macro differently when compiling their own DLL or a user's DLL and on platforms where __declspec is irrelevant it can be defined to nothing. There are many other reasons for macros like that one.
In this particular case you can effectively pretend that macro is blank and ignore it entirely.
I have a class that has a member function called SendMessage. No member function named SendMessageA exists in the project.
Project is multibite, so I have a define
#define SendMessage SendMessageA
If I call SendMessage somewhere in that class, will my project call SendMessage or SendMessageA ?
If the replace is made by preprocessor,the project should not compile. Right ?
But I see in a dump that SendMessageA is called ... end eip register is not in any VAD
EDIT
A more specific question: is preprocessor blindly replace the defines ? or first checks for a match in the class ?
The Preprocessor runs through your code before compilation.
So any SendMessage would be converted into a SendMessageA. The compiler will then look for a function called SendMessageA and call it.
How C++ preprocessor works
In case of #define A B preprocessor replaces ALL occurences of A with B. It is pure substitution.
Will my project call SendMessage or SendMessageA ?
Your project will call either SendMessageA or SendMessageW - depending on whether it was compiled with unicode support or not. There's no SendMessage function - it doesn't exist.
f the replace is made the project should not compile.
SendMessageA is declared within <widnows.h> (or in a header that is included from windows.h) - somewhere, and its linking info is within one of base system libraries (User32.lib, I think). If you're on windows, there's a very good chance <windows.h> is #included from somewhere, and corresponding *.lib is already in linker dependencies.
--EDIT--
A more specific question: is preprocessor blindly replace the defines ?
Yes, preprocessor blindly replaces defines. For non-blind replacement you have templates, but they have their own limitations. Some thing that can be done with preprocessor cannot be done with templates and vice versa. Preprocessor have stringize operator, templates have type-checking and metaprogramming.
My problem is why sometimes the member function SendMessage is called because the code works (most of the time)
If you have SendMessage method in your code (BAD idea on windows platform - clashes with system macro, replace with sendMessage() or use different name, because even namespaces won't help you to avoid omnipresent preprocessor) your method (not SendMessageA/SendMessageW) will be called from *.cpp ONLY if <windows.h> was not included in that *.cpp.
Compiler operates at one file at a time, and has no knowledge of thing that go on in other files, so if there's no <windows.h> #included, your method will be called, because preprocessor won't have any knowledge about SendMessage #define (from <windows.h>). If <windows.h> is included, then ALL occurences of SendMessage will be replaced with SendMessageA/SendMessageW, because preprocessor does its job first.
One possible solution in your situation would be to avoid using naming convention similar to the one in Win API. I.e. make sure that function names don't start with capital letter. That'll solve many problems, but you'll still get minor trouble from min/max macros.
The preprocessor works as a text macro processor. If a macro is defined, all occurrences of the macro are replaced with it's definition.
#define blabla some_real_stuff
struct blabla /* blabla will be replaced with some_real_stuff */
{
void method();
};
int main()
{
some_real_stuff x;
x.method();
}
In the Windows API, there are the two functions SendMessageA and SendMessageW. You will be calling one of these two, depending on what #defines you have in your program.
Are you sure that is not what happens?
Edit: oh wait. Is your #define SendMessage SendMessageA before the definition of the SendMessage member function in your source? If so, the compiler will simply use SendMessageA for the name of the member. Otherwise, your function will be SendMessage, but the rest of your program will call the built in Windows function SendMessageA.
If you have many source files, maybe some of them will know about the #define, while others won't.
My recommendation is to rename the member function to something else and dispense with the #define.
I am developing a multi-platform application and in one component I have a class method called DrawText. Unfortunately, I get a linker error (on windows only) saying that there is an unresolved external symbol for a DrawTextW method of this class.
I've seen this before with other methods ending in "Text" where it is looking for either a FooTextW or FooTextA method instead of the FooText method I defined. My assumption is that somewhere in the Windows headers there is a macro definition assigning FooText to FooTextW or FooTextA based on some other definition.
Aside from renaming my function (which is what I did in the past), does anybody have any good ideas for getting around this issue?
Thanks.
Joe
You really only have two choices:
#ifdef DrawText
#undef DrawText
#endif
Or rename your function. Win32 uses macros which have no namespacing or scoping, so you're kinda stuck.
We just re-name our functions.
BTW: It's based on #ifdef UNICODE usually (or _UNICODE or a few other variants).
Yes, this is a real problem with using Windows, and there's no way to turn it off since the headers all look like this:
#ifdef UNICODE
#define GetDlgItemText GetDlgItemTextW
#else
#define GetDlgItemText GetDlgItemTextA
#endif
So you're going to get the symbol defined either way. It would be very nice if you could #define something before #include'ing windows.h that turns this behavior off, but alas none exists.