I have a legacy application which uses ChoosePixelFormat function. PIXELFORMATDESCRIPTOR object contains PFD_SUPPORT_COMPOSITION flag. How to define PFD_SUPPORT_COMPOSITION flag as wglChoosePixelFormatARB attribute ?
Related
In OpenGL ES Shading Language, the shader storage buffer object (SSBO) can be decorated with qualifier readonly or writeonly.
Section 4.9 (Memory Access Qualifiers) of OpenGL ES Shading Language version 3.1 specification:
Shader storage blocks, variables declared within shader storage blocks and variables declared as image types (the basic opaque types with “image” in their keyword), can be further qualified with one or more of the following memory qualifiers: ...(A table is listed)
So I can have something in opengl es shader like this:
layout(std430, binding = 0) readonly buffer mybuffer {
a_struct_type myarray[]; //a_struct_type was defined before
};
But how to specify the readonly in spir-v?
In spir-v specification, 3.18 section, Access Qualifier, it says:
Used by OpTypeImage and OpTypePipe.
Does this mean that, in spir-v, the SSBO cannot be specified as readonly? I do not think SSBO falls into type OpTypeImage or OpTypePipe.
---------------------------------------------
Resource Type | Storage Class | Type
---------------------------------------------
Storage Buffer| Uniform |
|----------------| OpTypeStruct
| Storage Buffer |
----------------------------------------------
The appropriate decorations are unintuitively NonWritable and NonReadable.
why data type in windows.h have CALLBACK ?
how to use it ?
what is the difference between other data type ?
https://msdn.microsoft.com/en-us/library/windows/desktop/aa383751(v=vs.85).aspx
The answer is right there in the page you linked to:
CALLBACK, WINAPI, and APIENTRY are all used to define functions with
the __stdcall calling convention. Most functions in the Windows API
are declared using WINAPI. You may wish to use CALLBACK for the
callback functions that you implement to help identify the function as
a callback function.
On 32-bit Windows x86 machines there are multiple calling conventions but the two most common are stdcall and cdecl. Most functions in the Windows API are stdcall and functions in the C standard library are cdecl.
Most public functions in the Windows SDK use the WINAPI define while callback functions that you or a library create will usually use the CALLBACK define. They both end up declaring that the function is using the stdcall calling convention and the generated code is the same. The CALLBACK define is used just as a reminder to you, the programmer, that this particular function is a callback function.
In rewriting the API for an existing C++ DLL into a Windows 10 Universal component, how to model generic 'context' parameters for the caller to define and use? The original API was:
typedef void (*My_Callback)
(const int deviceHandle,
void *pContext);
I am trying to rewrite as
delegate void My_Callback(const int deviceHandle, ???? context);
Since the parameters must be passed across the Windows Runtime ABI, it cannot be a void *. What would make sense in its place?
I have C++/CLI class that defines a property:
public ref class AbstractOffer
{
public:
AbstractOffer();
property String^ Body;
};
In some function the AbstractOffer class is passed by const ref
foo(const AbstractOffer^ ao)
{
ao->Body;
}
When I call the property the method compiler gives the following error :-
error C2662: 'ivrworx::interop::AbstractOffer::Body::get' : cannot
convert 'this' pointer from 'const ivrworx::interop::AbstractOffer'
to 'ivrworx::interop::AbstractOffer %' 1> Conversion loses
qualifiers
It seems somehow connected to const. How can I call the Body property of the object if the object reference is passed by const?
The const qualifier is a problem in C++/CLI. It is only meaningful when it can be checked and that's not in general possible in .NET. It is of course not a problem when you only have one kind of compiler and that compiler follows strict language rules. Like C++. But .NET supports many languages, your method could be easily called from a Cobol.NET program for example. The odds of ever getting const-correctness added to the Cobol language are zero.
The compiler does compile code with const qualifiers and does make an effort to check when it can. Which is why you got the diagnostic. That can even work when the declaration exists in another assembly, as long as it was compiled with C++/CLI, the compiler emits modopt annotations in the metadata.
But there are limitations with that. Properties are one of them, you can't add the const qualifier to the getter, or a member function in general, you'll get slapped with C3842.
Best thing to do is to use C++/CLI for what it is good at, it is an interop language. And const qualifiers just don't work well in an interop scenario.
The only way I know to get round this is the cast away the const-ness. As long as you don't modify the object, it should be fine. (If you do modify it, I've no idea what the outcome will be).
i.e. change your function to be
void foo(const AbstractOffer^ ao)
{
const_cast<AbstractOffer^>(ao)->Body;
}
I'm attempting to update some circa-2003 I/O Kit code and I'm running to something strange: there are a few places where methods are declared as pure virtual only if the __LP64__ preprocessor macro is set. Example, from IOBlockStorageDevice:
public
#ifdef __LP64__
virtual IOReturn getWriteCacheState(bool *enabled) = 0;
#else /* !__LP64__ */
virtual IOReturn getWriteCacheState(bool *enabled); /* 10.3.0 */
#endif /* !__LP64__ */
In the above example, why force the implementation of getWriteCacheStatus in >=10.4 but not in 10.3? Is this just a case of "we should have done this before" or is there something deeper that I'm not seeing (which is usually the case).
My guess is that the 32-bit version includes a default implementation to fall back on for drivers written before the method was introduced. Since there was never a 64-bit version of OSX that didn't include that method, they don't need to provide a fallback. I've seen similar patterns in other parts of IOKit for new methods that supersede deprecated methods. The deprecated method only exists in 32-bit mode and by default calls the new method. The new method is pure virtual in 64-bit mode.