I am learning the winAPI through the docs and I am kind of puzzled by this one thing. The docs use CALLBACK and WINAPI in the same example and when I tried peeking their definition, they were both defined as __stdcall. If both are defined as the same thing, what's the point of having two different definitions for just __stdcall?
Also worth noting that while peeking their definitions I also found APIPRIVATE and PASCAL which were defined as __stdcall. What's the point? Can I just replace every instance of those 4 definitions with __stdcall or is it problematic?
WINAPI is the decoration used for APIs that Windows exposes to you.
CALLBACK is the decoration used for callback functions that you pass to Windows.
Replacing them with __stdcall is problematic only insomuch as your code might ever be deemed good enough for other developers to use, who might try and use a gcc, llvm or other compiler that can target Windows, but does not support __stdcall as a keyword (except probably does as a backwards compatibility hack because of the number of times reasoning such as the above went unchallenged).
Related
I am reading about Win32 programming with C/C++ and came across a page which defines the WinMain as:
int WINAPI wWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, PWSTR pCmdLine, int nCmdShow);
I understand most of this, except I do not understand where did the part WINAPI come from?
I know that this is a macro for a calling convention. That's not what I am seeking clarity on. My question is not on calling conventions.
When I look at Microsoft's documentation on C++ functions, and I read through optional parts of a function declaration, I don't see any mention of including a calling convention at any place in the function declaration. So where exactly does Microsoft in their documentation speak about including calling conventions in a function declaration?
The portion of Microsoft's documentation that you linked to refers to only standard components of the C++ language. Calling conventions are not part of the C++ specification.
The C++ specification describes how a function can declare its return type and parameters, but it does not define how those values are actually passed between caller and callee. Calling conventions dictate that, and different compilers/platforms implement calling conventions in their own ways. So the C++ specification doesn't describe calling conventions.
In Microsoft's documentation, calling conventions are referred to as Microsoft-Specific Modifiers to the C++ language. Which is technically correct, as any identifier that begins with 1-2 underscores in its name is a vendor-specific extension, and all of the known calling conventions begin with underscores in their names, eg:
__cdecl
__stdcall
__fastcall
__thiscall
__safecall
__vectorcall
__pascal
__fortran
__syscall
etc...
Macros like WINAPI, STDMETHODCALL, etc simply map to a specific calling convention (usually __stdcall, but sometimes __cdecl).
If omitted in a function declaration, the compiler decides which calling convention it wants to use (usually __cdecl).
Compilers from different vendors are not required to implement each others extensions. However, in the case of calling conventions, most compilers at least implement __cdecl and __stdcall, and agree on how they should work, for code portability. But make no mistake, calling conventions are still a vendor-specific extension to the standard language specification.
I got an old codebase, where I want to use some implementations in a new environment. The old base used the TBB framework which I am really unfamiliar with.
Are there any equivalents implementaions to these TBB's types in C++11:
tbb::enumerable_thread_specific<...>
mutex_t
mutex_t::scoped_lock
If not: Any tips how I can convert them (links to good TBB summaries, tutorials, ...) or do I need to work myself into the whole TBB documentation?
(And no. Inserting TBB to the project is not an option.)
EDIT: forget to mention tbb::this_tbb_thread::yield any suggestion about this?
The TBB features in your code do have near-equivalents in C++11 (or you can create one simply).
enumerable_thread_specific<T> is an implementation of thread-local storage. It can use the platform's local storage, or a tbb::concurrent_vector to hold instances. The default is to consume no platform thread-local storage keys. C++11 has the thread_local qualifier, so depending on how the enumerable_thread_specific is used you can replace it with a thread_local version of the same type. If you are using the structure to persist the data, or to access it outside a thread-local context, you may have your work cut out for you.
mutex_t is a generic mutex type, and can be replaced with std::mutex, though the developer may have chosen a particular implementation (like spin_mutex) that will be affected by the replacement.
scoped_lock is an RAII object that locks the mutex on construction, and when the leaving the scope will unlock the mutex (making it somewhat exception-friendly.) You can use std::lock_guard<std::mutex> if you're at C++17, otherwise you can roll your own.
It has been awhile since I read the yield documentation. I believe the implementation looks for other possible tasks before giving up the time slice. You can use std::this_thread::yield() to relenquish the time slice, but the behavior may differ if the code is using TBB constructs. The fact you haven't mentioned any other TBB stuff implies to me there are none in the program, and the tbb::yield() does the same thing as std::this_thread::yield().
I would suggest making the old codebase work first and only then change.
tbb::enumerable_thread_specific<...> does not have standard equivalents.
mutex_t and mutex_t::scoped_lock you can replace with std::mutex and std::unique_lock<std::mutex>.
I've been trying for weeks now to get lldb working with C++11 on Mavericks, and I just cannot get it working reliably. Has anyone managed this? What exact steps did you take?
Symptoms I find include:
(1) Unable to invoke basic std functions, like if I have a vector v in the code, I cannot call "v.size()" (earlier StackOverflow responses agreed with this).
(2) Generally gets confused all the time about data types and classes. Sometimes it understands simple things, sometimes it just gives odd error messages, and misinterprets user types.
(3) If I stop the code and call a bunch of other functions, lldb sometimes just gets very confused, and I have seen utterly bizarre run-time behavior (e.g., I call a function from lldb and get logically impossible results, as if the call stack or memory was somehow mangled).
(4) Sometimes lldb just gives up and seems to lose track of where it is on the stack.
I know these are vague, but has anyone used lldb extensively for expression evaluation (not just breakpoints, but calling functions and methods from with debugger) and had lldb work? I have these very complex, very large datastructures and need an interactive debugger to manipulate them, and invoke methods on them, interactively (i.e., a repl).
Not part of the question, but if anyone knows of a true C++11 debugger that can call methods and evaluate functions at run time interactively, and works reliably on MacOS Mavericks, I'd be very grateful.
N.B. earlier MacOS versions are entirely different from Mavericks.
I don't know about 2-4, they are not specific enough to really tell. But #1 turns out to be a problem with the new C++ standard library on OS X. It is pretty aggressive about inlining most of the std::* functions, and not creating out of line copies. That's actually usually exactly what you want, but it is inconvenient for debugging!
You usually see errors like:
(lldb) expr my_vec.size()
error: call to a function 'std::__1::vector<int, std::__1::allocator<int> >::size() const' ('_ZNKSt3__16vectorIiNS_9allocatorIiEEE4sizeEv') that is not present in the target
And that's because there is no function to call, there's only inlined versions sprinkled through-out your code.
In C++11 you can work around this if you know in advance you will want to call functions in some particular template class by putting:
template class std::vector<int>;
for instance, in you code somewhere. Probably want to do this inside some kind of #ifdef DEBUG construct, you wouldn't want to ship code this way.
I am using GCC 4.6 as part of the lpcxpresso ide for a Cortex embedded processor. I have very limited code size, especially when compiling in debug mode. Using attribute((always_inline)) has so far proven to be a good tool to inline trivial functions and this saves a lot of code bloat in debug mode while still maintaining readability. I expect it to be somewhat mainstream and supported in the future because it is mentioned here http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0348c/CIAJGAIH.html
Now to my question: Is this the correct Syntax for declaring a Lambda always inline?
#define ALWAYS_INLINE __attribute__((always_inline))
[](volatile int &i)ALWAYS_INLINE{i++;}
It does work, my question is will it continue to work in future and what can I do to ensure it works in the future. If I ever switch to another major compiler that supports c++11 will I find a similar keyword which I can replace the attribute((always_inline)) with?
If I were to meet my fairy godmother I would wish for a compiler directive which causes all lambdas which are constructed as temporaries with empty constructors and bound by reference to be automatically inlined even in debug mode. Any ideas?
Will it continue to work in future?
Likely but, always_inline is compiler specific and since there is no standard specifying its exact behavior with lambda, there is no guaranty that this will continue to work in the future.
What can I do to ensure it works?
This depends on the compiler not you. If a future version drops support for always_inline with lambda, you have to stick with a version that works or code your own preprocessor that inlines lambdas with an always_inline-like keyword.
If I ever switch to another major compiler that supports c++11 will I
find a similar keyword?
Likely but again, there is no guaranty. The only real standard is the C++ inline keyword and it is not applicable to lambdas. For non-lambda it only suggests inlining and tells the compiler that a function may be defined in different compile units.
I'm trying to do some shader programming on windows. All the code I've been able to find online says you have to use wglGetProcAddress to figure out where these functions are, but i'm not sure what library to link against.
Ben Voigt's answer is nearly correct, with two exceptions:
All OpenGL 1.0 and 1.1 functionality is inlcuded in opengl32.lib, only 1.3 and upwards and all extension must be loaded dynamically.
WGL guarantees that all contexts sharing the same pixel format share identical function pointers. This is an important detail, as otherwise any application using either OpenGL 3.x/4.x or multisampling would necessarily be malformed.
However, in short, forget all this blah blah. Download GLEW and be done in 5 minutes. It just works and you need not care about petty implementation details. Call one init function at program start, and everything is good.
You link against opengl32.lib to get wglGetProcAddress. All the rest must be dynamically obtained via wglGetProcAddress after you have made a context current, since different contexts can use different implementations of the various functions.
An extension loader such as GLee or GLEW can do the function-pointer details for you, but you still need to be linking opengl32.lib.