I have a class non-static member function, and it has variable arguments, I'm compiling on Visual Studio 2005, with the 64-bit runtime, on 64-bit Windows.
void Class::Foo(void* ptr,...)
{
va_list args;
va_start(args,ptr);
float f=va_arg(args,float);
va_end(args)
}
I'm expecting a float, I pass a float to the function. But when I debug - I don't get the float I've passed. In fact - it's being received by the function as a 64-bit double! I have to do this:
double d=va_arg(args,double);
float f=(float)d;
Now I know Win64 likes to pass parameters in registers, and casts floats when it does this, shouldn't a va_list always be on the stack?
According to most references, I should have just a clean stack full of the passed parameters.
My question is: is this correct behaviour, or a bug? And if it's a bug, is it my bug, or Microsoft's?
I have the defines WIN64 and _M_AMD64, and WIN32 is undefined.
I don't have the C++ standard here, but it follows the C standard in this matter. C99, 6.5.2.2p7 says
If the expression that denotes the
called function has a type that does
include a prototype, the arguments are
implicitly converted, as if by
assignment, to the types of the
corresponding parameters, taking the
type of each parameter to be the
unqualified version of its declared
type. The ellipsis notation in a
function prototype declarator causes
argument type conversion to stop after
the last declared parameter. The
default argument promotions are
performed on trailing arguments.
So for your float argument, "default argument promotions" are performed.
These are defined in p6 as
If the expression that denotes the
called function has a type that does
not include a prototype, the integer
promotions are performed on each
argument, and arguments that have type
float are promoted to double. These
are called the default argument
promotions. [...]
So all floats are converted to double when being passed to an ellipse. VS apparently conforms in this respect, and the bug is in your code, which shouldn't use float in va_arg.
Looks like it is a VC++ x64 bug.
FIX: The va_arg function returns an incorrect value in a Visual C++ 2005 application
Related
I was openbsd bcrypt code and I got warning of unknown attribute bounded at below code snippet:
void SHA256Update(SHA2_CTX *, const void *, size_t)
__attribute__((__bounded__(__string__,2,3)));
I tried to google the attribute bounded but no relevant result was found. I want to port that code to a different platform and if I get the meaning of bounded attribute, I want to use a similar attribute of that platform.
Any suggestion would be appreciated!
The __bounded__ attribute is available in the context of function declarations to enable to determine the length of the memory region pointed by one of the function arguments using the value of another of it's arguments; the first parameter slightly changes the type of the check for different styles of functions.
In this case it augments the type of the second argument to the function with the length specified by the third argument; the __string__ bound style additionally checks that the size argument doesn't come from a sizeof applied to a pointer, as you want the destination's size.
It's only available in the OpenBSD's fork of GCC (see man 1 gcc-local); there also was a short-lived GNU C extension (somewhere between 2000 and 2003) by the same name and for the same purpose, which was a direct type qualifier instead and was usable outside function declarations too, however, AFAIK it was undocumented.
When we return a value from a C++ function copy-initialisation happens. Eg:
std::string hello() {
std::string x = "Hello world";
return x; // copy-init
}
Assume that RVO is disabled.
As per copy-init rule if x is a non-POD class type, then the copy constructor should be called. However for C++11 onward, I see move-constrtuctor being called. I could not find or understand the rules regarding this https://en.cppreference.com/w/cpp/language/copy_initialization. So my first question is -
What does the C++ standard say about move happening for copy-init when value is returned from function?
As an extension to the above question, I would also like to know in what cases move does not happen. I came up with the following case where copy-constructor is called instead of move:
std::string hello2(std::string& param) {
return param;
}
Finally, in some library code I saw that std::move was being explicitly used when returning (even if RVO or move should happen). Eg:
std::string hello3() {
std::string x = "Hello world";
return std::move(x);
}
What is the advantage and disadvantage of explicitly using std::move when returning?
You are confused by the fact that initialization via the move constructor is a special case of "copy initialization", and does not come as seperate concept. Check the notes on the cppreference page.
If other is an rvalue expression, move constructor will be selected by overload resolution and called during copy-initialization. There is no such term as move-initialization.
For returning a value from the function, check the description of returning on cppreference. It says in a box called "automatic move from local variables and parameters", where expression refers to what you return (warning: that quote is shortened! read the original for full details about other cases):
If expression is a (possibly parenthesized) id-expression that names a variable whose type is [...] a non-volatile object type [...] and that variable is declared [...] in the body or as a parameter of the [...] function, then overload resolution to select the constructor to use for initialization of the returned value is performed twice: first as if expression were an rvalue expression (thus it may select the move constructor), and if the first overload resolution failed [...] then overload resolution is performed as usual, with expression considered as an lvalue (so it may select the copy constructor).
So in the special case of returning a local variable, the variable can be treated as r-value, even if normal syntactic rules would make it a l-value. The spirit of the rule is that after the return, you can't find out whether the value of the local variable has been destroyed during the copy-initialization of the returned value, so moving it does not do any damage.
Regarding your second question: It is considered bad style to use std::move while returning, because moving will happen anyway, and it inhibits NRVO.
Quoting the C++ core guidelines linked above:
Never write return move(local_variable);, because the language already knows the variable is a move candidate. Writing move in this code won’t help, and can actually be detrimental because on some compilers it interferes with RVO (the return value optimization) by creating an additional reference alias to the local variable.
So that library code you quote is suboptimal.
Also, you can not implicitly move from anything that is not local to the function (that is local variables and value parameters), because implicit moving may move from something that is still visible after the function returned. In the quote from cppreference, the important point is "a non-volatile object type". When you return std::string& param, that is a variable with reference type.
I was going through a project code in C. In there, I saw this declaration of thread :
pthread_t ui_thread = (pthread_t) 0;
I didn't understand the part starting from '=' operator. What is it and how can I code the same declaration in C++.
(pthread_t) 0 converts the literal integer value 0 to a thread handle pthread_t. This assumes that such a conversion is possible, and valid, and that this is a meaningful value (probably expected to be "no thread").
The full statement creates a variable ui_thread which is a thread handle of type pthread_t, and initializes it with this value.
In C++, you could probably write the same if you were on a platform where it was valid for C. However, you would be better to use the C++ thread library.
std::thread t;
will create a default-constructed thread handle with no associated thread, which is likely the equivalent to the above.
The (pthread_t) part is known as type casting in C. Also called explicit type conversion. It is just a way for the programmer to inform the compiler that the programmer means for the value (0 in this case) to be treated as the type pthread_t.
The code you have is still valid C++.
In C++11 you can probably just do this:
pthread_t ui_thread{nullptr};
I'm writing a constrexpr function taking either a CArray T(&)(N), either a std::array.
I think I have to write 2 functions (if you know better I would be happy to know),
But I'm concerned about what I wrote with the std::array
constexpr float LinInterp01(const std::array<float, N>& inArray, float inX);
Is it correct when writing a constrexpr function to pass by const & or not?
I think it should be because at compile time the compiler would instanciate a copy and there is no notion of L Value, at compile time.
Could someone explain me this?
C++ standard section § 7.1.5 [dcl.constexpr]
The definition of a constexpr function shall satisfy the following constraints:
— it shall not be virtual (10.3);
— its return type shall be a literal type;
— each of its parameter types shall be a literal type;
And section § 3.9 [basic.types]
A type is a literal type if it is:
— void; or
— a scalar type; or
— a reference type; or
— an array of literal type; or
— a class type (Clause 9) that has all of the following properties:
— it has a trivial destructor,
— it is an aggregate type (8.5.1) or has at least one constexpr constructor or constructor template
that is not a copy or move constructor, and
— all of its non-static data members and base classes are of non-volatile literal types.
So yes, you can pass parameters by reference to constexpr functions.
Now whether or not your function calls will actually be evaluated at compile time depends on the body and calls of LinInterp01.
Looking at the Windows SDK, I found this #define directive for MAKEINTRESOURCEW:
#define MAKEINTRESOURCEW(i) ((LPWSTR)((ULONG_PTR)((WORD)(i))))
Can someone explain to me what the heck that means? For example, what would be the value of MAKEINTRESOURCEW(0)? (1)? (-1)?
The result of this macro will be pointer to long string with value equal to given parameter. You can see it by reading precompiler output (see /P C++ compiler options). All casting is required to compile this macro result, when LP[w]WSTR pointer is required, both in Win32 and x64 configurations.
Some Windows API, like LoadIcon, expect string pointer as their parameter. Possibly, these functions test the pointer value, and if it is less than some maximum, they interpret it as resource index, and not as string (problems of ugly C-style interface). So, this macro allows to pass WORD as string, without changing its value, with appropriate casting.
For the most part, it leaves the value unchanged, but converts it from an int to a pointer so it's acceptable to functions that expect to see a pointer. The intermediate casts widen the input int to the same size as a pointer, while ensuring against it's being sign extended. In case you care, ULONG_PTR is not a "ULONG POINTER" like you might guess -- rather, it's an unsigned long the same size as a pointer. Back before 64-bit programming became a concern, the definition was something like:
#define MAKEINTRESOURCE(i) (LPTSTR) ((DWORD) ((WORD) (i)))
Nowadays, they use ULONG_PTR, which is a 32-bit unsigned long for a 32-bit target, and a 64-bit unsigned long for a 64-bit target.
That's a macro that casts an argument i to a word, then casts that result to a pointer to an unsigned long, then again to a long pointer to a wide-character string.
Like other users said - it just casts an integer into a "pointer to a string".
The reason for this is the following: At the ancient times of Windows 3.0 people tried to be minimalistic as much as possible.
It was assumed that resources in the executable can have either string identifier or integer. Hence when you try to access such a resource - you specify one of the above, and the function distinguish what you meant automatically (by checking if the provided "pointer" looks like a valid pointer).
Since the function could not receive a "variable argument type" - they decided to make it receive LPCTSTR (or similar), whereas the actual parameter passed may be integer.
Another example from Windows API: A pointer to the window procedure. Every window has a window procedure (accessed via GetWindowLong with GWL_WNDPROC flag.
However sometimes it's just an integer which specifies what "kind" of a window is that.
Then there's a CallWindowProc which knows to distinguish those cases.