I have a Windows Phone 8 Solution with a Windows Runtime Component project. In the WinRT code I want to use __FUNCTION__ for logging from a C++ class.
However, __FUNCTION__ is not defined whereas __LINE__ is.
Intellisense only suggests __FUNCTIONW__ to use. But when I jump to the definition of __FUNCTIONW__ in crtdefs.h I can see that __FUNCTION__ is not defined there either:
I have read Why would __FUNCTION__ be undefined? but that did not help me (or I did not understand the problem described there correctly)
How could __FUNCTION__ not be defined? I thought it is build in to the compiler...
Update:
OK, I learned that __FUNCTION__ is actually never colored. Yet I get an error when I type:
TCHAR* f = _T(__FUNCTION__);
It says:
Error: Identifier "L__FUNCTION__" is undefined
Maybe something is wrong with my UNICODE setup? Is there a special header that I need to include?
It works fine when I try it in a C++ Phone 8 app. Do note that you might be confuzzled by __FUNCTION__ not appearing in the IntelliSense auto-complete list. You can only see __FUNCTIONW__. Which is a flaw, the macro is predefined in the compiler but that was overlooked for the IS parser. Since the definition of the macro doesn't appear anywhere in the included headers, the parser won't ever see a definition for it (like it does for __FUNCTIONW__) and you'll see it missing from the list.
I can't confirm if this is a known bug, the search function at connect.microsoft.com isn't good enough to filter the 6600 hits that match "function". You can file the bug if you wish.
Update after edit: you are using the ancient TCHAR macros in your code. There's a trick to get the correct macro but I'm not going to document it. This all stopped being relevant well over 10 years ago when everybody stopped creating programs that could still run on one of the legacy Windows 9x versions. Certainly entirely pointless on a phone.
You in fact want to use __FUNCTIONW__ (without the _T), it produces the Unicode string for the function name. It is a const wchar_t*.
Related
I am using VSCODE in adittion with the C/C++ Extension from Microsoft as a code editor in order to have a more modern code editor than the one my game engine delivers (a code editor from the early 2000s). So I just use vscode to program, I don't compile my code with it.
The problem is that the extension marks correct statements as incorrect:
In my case, I get error squiggles for the simple statement: sizeof(int)
Intellisense says: "Expression expected C/C++ (29)".
Does anyone of you know what is wrong?
Thanks in advance.
I already tried changing the Intellisense mode from msvc-x64 (legacy) to other ones, but the problem still persists.
sizeof if a built-in keyword, it should never be redefined as a macro. The macro is expanded to a function (I believe _sizeof is a function). The macro expansion looks something like this:
(int)_sizeof(int);
The error you get comes from the argument passed. The macro passed a bare data type in a function call (_sizeof(int)), when in reality arguments to a function in a function call must always be expressions. That is why you got the error "Expected an expression".
One solution could be to place some code like this (at the beginning of your code):
#ifdef sizeof
#undef sizeof
#endif
Let me know if you have any problems.
I'm working on a multi-platform codebase, and on one of the platforms, sprintf_s isn't available, but snprintf does exist, so in this case the solution is to have the line
#define sprintf_s snprintf
However, I'd like to either automatically revert this (or throw a compile time error so I can do it manually) should the platform implement sprintf_s.
I've found multiple questions here to detect if a class has a member function defined (or an overload exists of a stream operator), but none for a function like sprintf_s.
(I'd rather not use anything experimental, but if std::experimental::is_detected is the only solution so be it).
The ideal solution looks something like
if !sprintf exists
#define sprintf_s snprintf
but something like the following would also be acceptable
static_assert(!sprintf_s_exists, "sprintf_s is now defined");
An implementation that provides sprintf_s() should define the macro __STDC_LIB_EXT1__ in <stdio.h>. You might also define __STDC_WANT_LIB_EXT1__ to 1 before including the header yourself.
You can also check for implementations you are sure support it, such as MSVC with a minimum version number, and enable it conditionally only for those.
The more general appriach is what auticonf traditionally did: attempt to compile a small program that calls the function you're testing for, and check the return value. If the program compiles and runs as expected, the script added a macro such as HAS_SPRINTF_S to the configuration file, and the program could then test for that.
Such problem (speaking generally) is not uncommon. Many systems solve it during configure phase of the build (when generating platform specific make or ninja files). There you would normally provide the build system generator with a small "feature test" app which would either compile fine or fail to compile, and you can base the logic of the build system (usually by having it define required compiler macros) based on either of outcomes.
In CMake something similar to the above is called cmake-compile-features
I understand that the predefined identifier __func__ makes a function name available for use within the function. But when will i be needing it? One of the purpose can be for debugging. What are the other use cases?
Update: For clarity, since in (portable) C or C++ there is nothing you can do with the name of the current function as "string" (char array), you're pretty much limited to writing that string somewhere - which can all be viewed as diagnostics or "debugging" purposes. Having that said, you might want to come up with some sort of usage for the function name. For example, declarative security, configurable logging (albeit that is "diagnostics" again, etc.).
In fact most descriptions and manuals on the web explicitly mention that the utility of __func__ and (__LINE__and __FILE__ for that matter) is debugging and diagnostics.
Personally I think it is provided to help make "better" assert() outputs possible.
You use that whenever you "programmatically" need to know the name of the current function. That pretty much excludes the debugger, where you have the name (or even context) of the current function by the very means of the debugger available already.
__func__ (or its older, non-standard predecessor __FUNCTION__) is typically used together with the __LINE__ and maybe __FILE__ macros to provide trace or diagnostic output functionality, that automatically includes the current function (and file, line).
#define TRACE(s) \
do { fprintf(stderr, "%s:%d:%s: %s", __FILE__, __LINE__, __func__, (s)); \
} while (0)
You can then use it like this:
int my_func(char* arg1, int arg2)
{
TRACE("Doing stuff...");
/* ... */
}
For more information and examples see this Stackoverflow Q&A.
Even for such output-only purposes, the usability of __func__ is pretty limited, as it only includes the "unqualified and unadorned name" of the function. Such that for the above example it will only by "my_func".
In C/C++ that means that for overloaded functions, you will not be able to distinguish them by the value of __func__ alone. The class- and/or namespace-name, if any, is also not included.
Also compilers typically provide non-standard variations that do include the full function signature or other detail (GCC (see __PRETTY_FUNCTION__), Microsoft C/C++ (see __FUNCDNAME__, __FUNCSIG__)).
I've noticed that adding this macro along with __FILE__ and __LINE__ in my code greatly helps people who are reading the logs of my program. It also makes writing log functions a lot easier as I don't need to hard-code those values since the compiler takes care of that for me.
Remember that people may not have access to the source code of your application, in some cases only the log trace and the output will be available to them. It would be good if there was a transparent way for them to know what's going on.
If it is a constexpr (which it should be, but at least in current GCC isn't, unluckily), it can be hashed and used to implement a very easy and efficient (compile-time, no runtime overhead) RTTI system.
It could also lend to a more usable version of std::type_info::hash_code which neither requires RTTI to be linked nor has the pitfall of allowing different invocations to return different values.
The version supplied by the standard (as of C++11) explicitly gives no such guarantee, which makes it rather useless for anything except as a key in an associative container (such as std::map).
Given the guarantee that different invocations (at least of the same binary, or at least of types that have the exact same definition), it would be much more usable, e.g. for serialization.
(Yes, I'm aware that hash functions have collisions. Yes, in theory that's an issue. However, given a reasonable amount of bits (say, 64) and reasonable amounts of keys (say, a few hundreds), they happen rarely enough as to not turn out being a problem in practice, and it's not something one can't verify.)
I'm working on a proprietary unix-like os (I don't know if that's relevant though) and compiling with g++.
I noticed recently that if I put xml-like tags in my C++ comments I get compiler errors. I don't particularly need to do this, but I thought it was strange and I'd like to know why it's an issue for the compiler. For example:
// <debugoutput>
std::cerr << "I'm debugging!" << std::endl;
// </debugoutput>
would cause massive compiler errors if it were in the middle of my code somewhere. Changing the last comment line </debugoutput> to <debugoutput> makes it compile fine though.
Does anyone know why the compiler would be confused by that line being in a comment? The compiler errors generated when this happens don't seem related at all - they're more like what you'd see if you missed the semi colon on the end of a class, undefined references to well defined classes, etc. I can't paste the output from my dev system, but trust me that it doesn't look related to the issue - its more like the compiler got confused.
This sounds suspiciously like a digraph related issue, but without the actual error message or a small code sample that exhibits the problem it's hard to tell for sure.
Try changing the whitespacing between the <, / and actual text, as well as try it within a C-style comment to see if that provides additional insight.
For information on C/C++ digraphs and trigraphs see http://en.wikipedia.org/wiki/C_trigraph#C and also Purpose of Trigraph sequences in C++? and Why are there digraphs in C and C++? from SO.
It seems possible that there is some sequence being picked up (for example </ as a digraph and it's throwing off the compiler).
note: I am using g++ version 4.3.4
So I was learning about assert statements and came across a homebrew assert macro that uses that variables __LINE__ and __FILE__ which (cleverly) give the line number and the file name from where they were called -- in this case, from where the assertation failed. These are epic pieces of information to have!
I was able to infer that the variable __FUNCTION__ will give you the function name that you are inside of... amazing!! However, when assert.h is at work, you also get the arguments to the function (i.e. function: int main(int, char**) and all I can do currently is get the function name...
Generally speaking, where can I learn more about these wonderful hidden variables and get a complete list of all of them?
p.s. I guess I understand now why you aren't supposed to use variable names starting with __
Generally speaking, you can find out anything you want about a language by reading its standards document and/or lone implementation's documentation. In the case of C++, this would currently be ISO/IEC 14882:2003, the 2003 C++ standard. I don't have a copy, but I do have the C99 standard (ISO/IEC 9899:1990), which also lists (in §6.10.8) the magic macros __DATE__ and __TIME__, which expand to strings containing the date & time of the enclosing source file's compilation. (Also, instead of __FUNCTION__, C99 has __func__ (§6.4.2.2); is the former standard C++ or a compile extension?)
EDIT: The only list of these special names for GCC/G++ that I can find is this section of the GCC manual, which describes __func__, __FUNCTION__, and __PRETTY_FUNCTION__.
As far as getting the function arguments, you can try using __PRETTY_FUNCTION__ instead of __FUNCTION__. More information is available here: http://gcc.gnu.org/onlinedocs/gcc/Function-Names.html
As far as a list of pre-defined macros, you can find a lot of them if you hunt around in here: http://gcc.gnu.org/onlinedocs/cpp/Predefined-Macros.html#Predefined-Macros
I cannot say with certainty that the list referenced above is complete. The reason I say this is that __PRETTY_FUNCTION__ cannot be found under the list of predefined macros... why this is, I cannot say.