glGetProgramiv is referenced inside the documentation as glGetProgram but no mention is made of there being multiple versions - and I see no indication through google of there being other versions such as glGetProgrammiii or glGetProgramii. Is the iv prefix roman numerals related to some type of internal versioning during the specifications process or does it hold some other significance?
Those suffixes are used to distinguish "overloaded" methods with same names and different parameters. iv means this version operates on vector of integers. It's the only version of glGetProgram at the moment.
Related
when using glGetString on the enum GL_SHADING_LANGUAGE_VERSION I get only one value for return, while I was expecting space separated values as with glGetString(GL_EXTENSIONS).
what is even more confusing is that when I use glGetIntegerv(GL_NUM_SHADING_LANGUAGE_VERSIONS, *); I get a number bigger than one, and when I use glGetStringi(GL_SHADING_LANGUAGE_VERSION, i), and iterate over them I can get all the values. So, why don't I get all the values with glGetString(GL_SHADING_LANGUAGE_VERSION). I just get one value
It is this way because that's how the feature was originally defined. All GLSL versions are backwards compatible with prior ones, so the expectation was that if you had a 1.10 shader, you could feed it to any implementation that accepted 1.10 or higher.
But with the break between core and compatibility, that become untenable. Making core implementations tacitly support GLSL shaders that included removed constructs made no sense. So there had to be a way for an implementation to specify exactly which GLSL versions it supported. But they couldn't change the existing version string's definition, so they (eventually) just added a new, indexed-based query.
I got function types in LLVM pass by getFunctionType(), when I print them, the function type contains something like: (%"class.xalanc_1_8::ReusableArenaBlock.10232"*).
The former part is the class name class.xalanc_1_8::ReusableArenaBlock, what about the number. Some of them contain multiple numbers. I'm wondering about the usage of the numbers.
The frontend (which typically parses a source code language) needs to create LLVM types with unique names. Most frontends use type names and other strings from the source code to construct the IR type's name, but sometimes that's not (guaranteed to be) unique. Appending a number is the normal way to achieve uniqueness.
In fact appending a number it is what LLVM itself does if you create certain types or many other things, and there's no error except that your requested name is already taken.
It's not the only way to avoid conflicts. My own code adds line numbers from the source code in some cases (not for types, though).
HDF5 supports various filters to be specified for the output data pipeline, in particular various compression algorithms and a Fletcher32 checksum.
On data input, the HDF5 library automatically detects any filters that have been applied to the data on file and applies the inverse filters (de-compression), without any action required by the user.
However, in the extensive (and somewhat confusing) HDF5 documentation, I couldn't find any mentioning of the consequences of an incorrect checksum detected whilst reading.
I tagged this as c, fortran, and c++, as I'd be happy for the answer for either API.
It doesn't appear to mentioned in the documentation at all, but this design spec for the Fletcher32 filter says that the user can supply a callback function to handle failure (i.e. an incorrect checksum). If no callback function is supplied,
the write and read processes will fail if the Error-detecting code is enabled and finds error in the data.
This means that the return value of H5Dread, say, will be negative.
Once you have applied the Fletcher32 filter (with, e.g. H5Pset_fletcher32), you can set the callback with H5Pset_filter_callback. The callback function has to match the prototype:
typedef H5Z_cb_return_t (H5Z_filter_func_t) (H5Z_filter_t filter_id, void *buf, size_t buf_size, void *op_data)
and return either H5Z_CB_FAIL or H5Z_CB_CONT.This way, you can specify exactly what happens when the checksum fails.
There's a very ugly example of how to use all this in the appendix to the design spec.
I simply want to pass a list of integers to a function written in C++. I've set up the template (.tm) file and all, and I can successfully call a test function whith scalar arguments. Calling the function with the list argument behaves as though the function was not defined at all. I suspect that the argument types don't match.
In the documentation for templates (http://reference.wolfram.com/mathematica/ref/file/file.tm.html) the datatype for lists is something like "Int32List". When I use that, my C++ function must contain an extra long parameter for the list length. The only example code which uses a list is "sumalist.tm". This example uses IntegerList (a type which doesn't appear in the doku).
When I use Int32List, the mprep result requires a function with an extra integer argument (not long as written in the doku). When I use the undocumented IntegerList type, the extra argument is of type long.
During my experiments with scalar types, I had a similar problem - a c++ function was called properly when using "Integer" in the tm-file, and not recognized with "Integer32".
The "sumalist.tm" example also uses a strange Pattern (list:{___Integer}) about which I didn't find any documentation. I'd also like to understand what the Evaluate line means (I suspect that it's used make the function callable without the curly braces around the list).
So who know which datatypes are really appropriate to call a c++ function with a list - maybe also with reals... ?
The mapping of MathLink data types (e.g., Integer32, Integer32List, ...) to C/C++ types is described on the MathLink template file documentation page.
The page no longer documents the old interface types Integer, Real, IntegerList and RealList. These should no longer be used, because the mapping of these types depends on C types whose bit length is platform and compiler dependent (e.g., long). Use the corresponding new type with explicit bit length instead (i.e., Integer32 or Integer64 instead of Integer). The old interface types are still documented in the somewhat dated MathLink reference guide.
The following talk slides contain a simple MathLink example that shows how to implement a MathLink function that adds a scalar value to a vector of reals. This may serve as a starting point.
I don't know much about MathLink, but I can explain the pattern, list:{___Integer}.
The colon is just the general form for a named pattern, that is symbol:pattern just says that the object referred to by symbol has to match pattern. Indeed, pattern like a_Integer or b__List are really just short forms for a:_Integer and b:__List.
So what we are left with interpreting is {___Integer}. This is a pattern matching a list of arbitrary many (including zero) integers. It works as follows:
{Pattern} is the Pattern for a list whose contents matches Pattern
___Integer is the Pattern for a sequence of zero or more Integers.
Visual Studio 2008
Project compiled as multibyte character set
LPWSTR lpName[1] = {(WCHAR*)_T("Setup")};
After this conversion, lpName[0] contains garbage (at least when previewed in VS)
LPWSTR is typedef'd as follows:
typedef __nullterminated WCHAR *NWPSTR, *LPWSTR, *PWSTR;
It's an expanded version of my comment above.
The code shown casts a pointer of type A to a pointer of type B. This is a low-vevel, machine-dependent operation. It almost never works as a conversion of an object of type A to an object of type B, especially if one type is a regular character type and the other is wide characters.
Imagine that you take a French book, and read it aloud as if it was written in English.
FRENCH* book;
readaloud ((ENGLISH*) book);
You will mostly hear gibberish. The letters used in the two languages are the same (or similar, at any rate), but the rules of the two languages are are totally different. The representation is the same for both languages, but the meaning is not.
This is very similar to what we have here. Whatever type you have, bits and bytes are the same, but the rules are totally different. You take bits laid out according to regular character rules, and try to interpret them according to wide character rules. It doesn't work. The representation is the same in both cases, but the meaning is not.
To convert one character flavor to another, you in general need a lookup table or some other means to convert each character from one type to the other — change representation, but keep the meaning. Likewise, to convert a French book into an English book, you need to use a big lookup table a.k.a. dictionary... well, the analogy breaks here, because there's no formal set of conversion rules, you need to be creative! But you get the idea.
The rules of C++ actually prohibit such casts. You can only cast an object type poiner to void*, and only use the result to cast it back to the original object type. Everything else is a no-no (unless you are willing to venture in the realm of undefined behavior).
So what should you do?
Pick one character variant and stick to it.
If you must convert between flavors, do so with a library function.
Try to avoid pointer casts, they almost always signal trouble.
I think what you're looking for is
LPTSTR lpName[1] = {_T("Setup")};
The various typedefs with a T in them (e.g. TSTR, LPTSTR) are dependant on whether you use unicode or multi-byte or whatever else. By using these, you should be able to write code that work in whatever encoding you are using (i.e., tomorrow you could switch to ascii, and a large portion of your code should still work).
Edit
If you are in situation where you really must convert between encodings, then there are various conversion functions available, such as wcstombs (or microsoft's documentation) and mbstowcs. These are defined in <cstdlib>