is there a way i can print __FUNCTION__ as a wide character on linux?
the trick with the WIDEN doesn't work for me, the gcc compiler prints:
error: ?L_FUNCTION_? was not declared in this scope
any help?
Thanks
7+ years later (although things seem to be the same) ...
Since you mentioned gcc, check [GNU.GCC]: Standard Predefined Macros (emphasis is mine):
C99 introduced __func__, and GCC has provided __FUNCTION__ for a long time. Both of these are strings containing the name of the current function (there are slight semantic differences; see the GCC manual). Neither of them is a macro; the preprocessor does not know the name of the current function.
Since __FUNCTION__ is not a macro (the preprocessor doesn't "know" anything about it), it will remain untouched during (outer) macro expansion, generating at the end the L__FUNCTION__ identifier, which is obviously invalid. That's why the double macro approach works for __FILE__ (for example), but not for __FUNCTION__ (or __func__).
So, the short answer to your question is "NO" (at least not at preprocessor level). You will need to convert __FUNCTION__ "manually" (e.g. using one of the [man7]: MBSTOWCS(3) functions family).
Note: It works on VStudio, since according to [MS.Docs]: Predefined Macros (emphasis still mine):
__FUNCTION__ Defined as a string literal that contains the undecorated name of the enclosing function. The macro is defined only within a function.
It can be done using macros, you just have to understand how macros expand.
To get a wide char version of the macro you need to create 2 layers of macros like so:
#define WIDE2(x) L##x
#define WIDECHAR(x) WIDE2(x)
#define WIDE_FUNCTION WIDECHAR(__FUNCTION__)
The all important piece is the L##x that appends the L character to the string constant before the compiler sees it. You can do this to __FILE__ as well using the same technique.
That looks more like a typo of __FUNCTION__ than an issue with widen() or similar, at least if you pasted the exact error message.
Related
The problem arises firstly from the "isfinite" function: (undefined reference to isfinite). From google search I find that I must include "math.h" and write three lines of code, like:
ifdef __linux__
define _finite(v) (__builtin_isfinite(v))
endif
But then, there comes the error: (Make:47 missing endif. Stop).
If I comment out those three lines of code, the error becomes: (<math.h> no such file or directory).
My system is OpenSUSE Leap 15.4; gcc version 7; gnu make version 4.2.1-7.3.2.
I think I have installed all the needed packages. However the errors persist. Any help?
I primarily want to address this part of the question, as the underlying issue has been addressed elsewhere, multiple times:
The problem arises firstly from the "isfinite" function: (undefined reference to isfinite). From google search I find that I must include "math.h" and write three lines of code, like:
ifdef __linux__
define _finite(v) (__builtin_isfinite(v))
endif
I started to write "Google led you astray", but I think it's more likely that you seriously misunderstood what it led you to. And perhaps you happened to choose poor results.
The error message indicates that you put those lines in your makefile, but they are wholly inappropriate for that. Don't put them there.
The lines are C preprocessor directives that have been stripped of their leading # characters. You would use them by restoring the # characters ...
#ifdef __linux__
#define _finite(v) (__builtin_isfinite(v))
#endif
... and putting the resulting lines into one or more of your C source files. BUT DON'T! Those lines are unnecessary and at best unhelpful.
You do need to #include <math.h> in each C source file that contains a call to isfinite(), because that is the header that provides a declaration of the function. Since C99, functions must be declared before they are called (and it was good practice well before then).
Other than that, with GCC and many other traditional-style Unix C compilers, you need to explicitly include the math library in your link when you need any of the functions it provides. That would involve adding -lm to your makefile, at the end of the gcc command that builds the final executable. This is covered in gcc will not properly include math.h, and many other duplicates on this site.
consider this simple code:
#include <vector>
#include <string>
using namespace std;
vector<string> vec1;
//vec1. //completion does not work AND break the completion that used to work if left without semicolon.
int main(){
vector<string> vec2;
vec2.push_back("sometext"); //completion works
vec1.push_back("sometext"); //works here too
return 0;
}
When I type "vec2." or "vec1." I am presented with a drop down list of all methods of the string type right after I type the point. So it works here.
Here is how it gets strange:
1) When I do "vec1." in the global scope right before main I am presented with wrong options in the drop down menu (namespace, using, asm, typedef, using, static_assert, extern, etc...). And it cannot find 'push_back' at all ("User defined completion (^U^P^N) Pattern not found)
2) Now, If I leave this line unfinished and forget to put a semicolon I then can't have proper autocompletion inside main() as I did before!
Only plugins I have running are clang_complete and supertab. I tried without supertab and with various _vimrc and .clang_complete settings to no benefit. I'm on win7, llvm/libclang are from official website.
Is it normal that it bugs like that?
The plugin relies completely on libclang to do the completion, which in turn only completes code that's more or less valid (I think it can forgive some errors before the cursor from which the parser is able to recover and code after the cursor can contain more serious errors).
Statements at the global scope are not among valid syntactical constructs of C++. This probably confuses clang's parsing enough to make it return some generic completion list that's not tied to the immediate context.
I think such behaviour is expected for any completion system that employs clang, unless it's explicitly worked around in some way.
It's possible to override C runtime functions using the preprocessor (e.g. /Dfree=my_debug_free), however having to match the linkage of the redefined symbol is sometimes undesirable or awkward within the context of a given project.
Is there a way to force the dllimport linkage of a symbol to be satisfied with a symbol coming from a static .lib or a .obj?
Let's assume modifying the calling code directly, or defining away the __declspec keyword itself is out of the question.
Answering my own question with what I've found:
One of the things that the __declspec(dllimport) does is say that the function in question has a prefix __imp_ added to it from the importer's point of view, so manually add the prefixed function, and you satisfy the link.
As far as I understand these __imp_ are the bit that the .lib file corresponding to the .dll would normally provide. If you cut out the linking of the .lib for the .dll you cut that those also, and so have to fill in the __imp_ shaped hole manually yourself.
https://msdn.microsoft.com/en-us/library/aa271769(v=vs.60).aspx has a good overview.
All that said, I've found that using a pre-included file (/FI or -include) that #includes the original (unredefined) definitions first, then redefines them with #defines before entering your code works better than using /D to to redefine them everywhere, even in the original definitions. Doing it that way meas you don't need to worry about the .dll stuff.
Are there any direct consequences of toggling between Unicode, MBCS, and Not Set for the VS C++ compiler settings Configuration Properties->General->Character Set, apart from the setting of the _UNICODE, _MBCS and _T macros (which then, of course, indirectly has consequences through the generic text mappings for string functions)?
I am not expecting it to, but since the documentation says "Tells the compiler to use the specified character set", I'd like to be certain that, specifically, it doesn't have any influence on how any literal non-ASCII text put into strings or wstrings is encoded? (I am aware that non ASCII literals in the source is not portable, but am maintaining a solution where this is used heavily.)
Thanks in advance.
No, it only affects the macro definitions. Which in turn can have wide-ranging effects on anything from <tchar.h> or the Windows T string pointer types (LPTSTR etc).
If you use any non-ASCII codes in your string literals then you depend heavily on the way the compiler decodes the text in your source code file. The default encoding it assumes is your system code page as configured in Control Panel + Regional and Language options. This will not work well when your source code file ever strays too far away from your machine. Specifying utf8 with a BOM is wise so this is never a problem. In the IDE that's set with Save As, arrow on the Save button, "Save with encoding", pick 65001. Support for utf8 encoded source code files is spotty in older versions of C++ compilers.
For unadorned strings, C++ follows C: it's ASCII. If you wrap them with anything, the game changes.
C++0x standardises Unicode strings. UTF in particular. This is a new feature.
I'm working on getting a Visual C++ 2005 solution to compile in unicode. However, In some of my projects (but not all), I get errors in the form:
1>.\CBitFlags.cpp(25) : error C2065: 'L' : undeclared identifier
and the line of code in question is:
LOGERROR(UTILITY, L"Tried to use object to store %d flags, when max is %d",
I am BAFFLED. It seems to be treating L as an identifier when L is part of the language syntax. Does anyone know if there is some flag somewhere that has to be enabled in the project or compile settings that if not toggled would cause this? The really weird part is it isn't all of the occurrences of this, it's only some of them. It does seem to be consistent within a single project, but I have entire projects compiling fine, and others that fail miserably like this.
The problem is almost certainly inside of the LOGERROR macro. Look at how it treats that second paramater. Expand the macro yourself, it is easy to overlook small errors in macros sometimes.
Visual C++ 2005 does support the L syntax for wide strings, and doesn't need any special flags or anything to support it. So most likely, your problem is elsewhere. Perhaps the definition of LOGERROR or UTILITY. Or a missing semicolon previously, or.... It could be anything which causes the compiler to expect something other than a string literal when it gets to the L.
Since this appears to be something used in a macro, I think you should look at the definition of the LOGERROR and UTILITY macros and at what they expands to in the context of your code. Use the /P compiler option to preprocess your files without proceeding to the compilation step, and then look at the result to see what the compiler's really seeing.
I can reproduce the error you see if I have a space after the L:
wchar_t const* foo = L "foo";
Are you sure you've copied and pasted the actual code that's giving you trouble?