http://docs.gl/gl4/glVertexAttribPointer in this page, the description of parameter size, it said the initial value is 4, what does it mean? is it mean the value when invalid argument used?
Most OpenGL functions set state into objects or the context. But that state exists before those functions get called. As such, that state has a value before the first time this function is called on a VAO.
That part of the documentation tells you what the initial value of the state that would be set by the size parameter is.
Related
When reading documentation on functions from external libraries of different kinds I have always seen the documentation state that a variable has to be [IN/OUT]. Could someone give me a detailed understanding on how [IN/OUT] relates to parameters of a function being passed by reference or by value.
Here is an example of a function I have come across that tells me it needs an [IN/OUT] parameter:
Prototype:
ULONG GetActivationState( ULONG * pActivationState );
Parameters
Type: ULONG*
Variable: pActivationState
Mode: IN/OUT
This part applies to all types of paramters - most library interfaces try to be C compatible, so it is more common to pass parameters by pointer, rather than by reference.
IN: When a parameter is listed as IN it is a guarantee being offered by the interface that it won't modify that parameter. In my opinion, this is better conveyed by marking the parameter as const, then the language itself will prevent modifications to the value. If this parameter is being passed by value, it is inconsequential whether it is marked IN in the documentation (or const in the prototype) since the parameter is local to the function anyway. But to avoid copying it may be passed by reference or by pointer, in which case the const keyword becomes very important.
OUT: A parameter marked OUT usually means that the value of the parameter when it is being passed to the function is not of any importance. In fact, if it being passed by pointer, it may even be required to be NULL, and the function will allocate memory and pass a value back to you.
IN/OUT: An IN/OUT parameter usually indicates something where both the input and output values are meaningful. For instance, if you have a library function that fills a buffer, it may require you to pass a pointer to the buffer, along with another pointer indicating the length of the buffer. When the function returns, the second pointer may contain the actual number of bytes that have been written to the buffer.
This parameter is in/out because you provide a value that is used inside the function, and the function modifies it to inform you about something that happened inside the function. The usage of this function would be something like this:
ULONG activationState = 1; // example value
ULONG result = GetActivationState(&activationState);
note that you have to supply the address of the variable so that the function can get the value and set the value outside the function. For instance, the GetActivationState function can perform something like this:
ULONG GetActivationState(ULONG* pActivationState)
{
if (*pActivationState == 1)
{
// do something
// and inform by the modification of the variable, say, resetting it to 0
*pActivationState = 0;
}
// ...
return *pActivationState; // just an example, returns the same value
}
Note how:
The function accepts the parameter as a non-const pointer to an UINT. This means it may modify it.
The function can access the value you gave to the parameter by dereferencing it
The function can modify the parameter again by dereferencing it.
The calling function sees the activationState variable holding the new value (0 in this case).
This is an example of "pass by reference", which is performed by using pointers in C (and also with references in C++.)
Generally, things marked as IN/OUT will be passed via a non-const pointer or reference, allowing the function to modify the variable directly, as well as read it. Be sure to check the documentation to see if it expects the value to be set prior to passing it in.
Parameters marked as IN will be passed by value, or by constant pointer or constant reference, disallowing the function from modifying the variable.
C++ doesn't enforce OUT-only parameters, but generally they will be passed using non-const pointer or references, similar to IN/OUT.
If a parameter is OUT, it has to be passed by reference. A purely IN parameter would be usually passed by value or const reference, if the cost of copying is too high (nothing prevents the designed from passing it by reference, but it's not very good design IMHO). An IN/OUT parameter must be passed by reference.
I'm of a mixed mind regarding the use of in, out, and in/out.
Upside: When done properly, it communicates intent to the reader of the documentation.
Downside: Far too often it is not done properly. Those designations obviously are not a part of the language; they are either in comments or are in some document that is maintained separately from the code. I've seen far too many cases where a parameter was marked as "out" but the first thing done in the code with that parameter is to use it as a right-hand side value.
You can use by value (simply types) or by constant reference const & for input only parameters. Use non-const reference & or pointer * as in/out parameter to change the value of the variable. You can also use a pointer reference * & to allow you to change the address the actual pointer points to (in/out). As Dave Smith pointed out there is no out only parameter in C++.
I have a use case where I need to use counting_semaphore as a data member in a class. If it were a global variable, I could've omitted the template argument, and it would've been default initialized. But as mentioned here, in case of a member variable, the template argument needs to be specified, and in our case it has to be a compile-time constant.
So, I'm not sure what to initalize the value of LeastMaxValue to? Are there any heuristics for it that you use, or is there a way I can still use the implementation defined default value for this?
Ideally, you would look at how the data member will be used and determine an upper bound on what the semaphore needs to count. This upper bound is an appropriate LeastMaxValue.
It is not always possible to find such a bound, though. If you have no way of bounding the maximum the data member needs to handle, you could use the largest possible value, std::numeric_limits<std::ptrdiff_t>::max().
I have a C++ object exposed to QML with a "sort of" read-only property, except that the property still needs to be set from QML, so it has a WRITE method defined, but other than the initial mandatory setting it never changes, so I feel like a NOTIFY is redundant, as it will already have that value set at the time of its usage, and it will never change.
However, QML doesn't share my feeling, and regardless it spews out a "Expression depends on non-NOTIFYable properties" warning.
Due to the way objects are instantiated using a property is the only applicable way of setting that value, it is not possible to use an invokable setter as such would require the object to already be "completed" and it cannot really complete without that value. Thus the need of the property mechanism and a WRITE method, which unfortunately leads Qt to believe that the property will change. I tried setting the property as CONSTANT but that doesn't seem to stack with having a WRITE method.
I've put a dummy signal as a temporary measure to deal with the flood of warnings, but I'd prefer if there was a more elegant way to deal with this. Again, the very design practically eliminates the possibility of setting this value after its initial setting, but since it is a C++ object and the value needs to be set on a per-object basis, it is not applicable to use a QML readonly property either. Is there a work-around for this that doesn't involve the redundant signal?
Just to clarify, the underlying problem here is that in its current state, QML has pretty much no way to initialize a read only property of an object, implemented in C++. Such a property wouldn't have a setter (if it would then it would spew the "depends on..." warning), and there is no way to pass a value to the object's constructor. As described in my answer below, there are hacks around this, but they are either limited in application or rather inconvenient. In C++ you can do even initialization of const members on a per-instance basis by passing the value to the constructor which does the initialization in the initializer list, but not in QML. Even in pure QML, read only properties must be initialized on the spot, it is not possible to leave them uninitialized (readonly property type name without : statement) and delay that until the instantiation and get per-instance initialization (Obj { name : initValue }). You could do this:
Item { // T.qml
readonly property int r : w
property int w
}
...
T { w: value }
but it... kind of defeats the purpose... And considering that a property can be "bound" only once in the body of its instantiation, I think this could be seen as an act of initialization, while further assignment or imperative rebinding (Qt.binding()) is prohibited. A setter without the redundant notification signal would do the trick, however qtquick's implementation design assumes that if it has a setter it will be changing, thus will complain that it doesn't have a notify signal, which IMO is a design oversight - that is, not providing any way to initialize a read only property on the QML side on per-instance basis. And currently, as I already mentioned, the 3 possible solutions come either with overheads (have a notify signal), limitations (set value before object creation - only applicable for dynamic instantiation) or major inconveniences (use setter and getter slots without implementing the actual property interface).
It depends a bit on what you need the value for.
If the property is used in any property binding then you will need the notification, otherwise you end up in a situtation where you rely on the order of object instantiations and binding evaluations.
E.g. if it is used in a binding elsewhere without having an associated notification signal, then you rely on the initial setting happending before any such binding is evaluated for the first time.
If, on the other hand, the value is only used to initialize the C++ side but never used in QML elsewhere, you could consider using a "setter" function/slot.
One possible solution is to only have a setter and getter functions exposed to QML, but without the actual property. It is a little less elegant and more verbose (an extra ()), but at least it deals with the warning spam in the console. It will probably end up more efficient, since aside from eliminating the redundant signal, there might be less binding expression reevaluation watchers instantiated.
There is also another way, but it only works for creating objects dynamically - it will not work if you create the objects declaratively. This approach involves calling a function before each and every object creation, that function sets a static member value, which the constructor of the object uses as an implicit parameter to initialize the read only property. Thus it becomes obvious why this can only work for objects that are created dynamically, in the other case you don't get to call the function and set the value before the constructor of the object is invoked.
There are also some stock APIs that seem to come with properties that do not have notification either. For example FolderListModel's rootFolder property, and so it generates warnings every time it is used in a binding. The solution to remove those is to use an additional proxy property and bind the FolderListModel property to it.
I'm working on C++,
The following is a function call in C++,
argument = myFunction(argument);
What will be the value of argument variable passed to myFunction() call i.e. value assigned before call to the function or value returned from the myFunction() function call.
Due to temporal necessity, the value of argument before calling myFunction will be passed. This is simply because you don't have the return value yet.
The parameters to a function call have to be evaluated before the call. The order of evaluation between parameters is unspecified, but you only have one, so it is evaluated. Whatever it is at that point (before the call) is used, then the function is called. When the function returns, after being run, the return value is assigned to argument.
+1 - #peachykeen
Also may I add that if argument isn't assigned a value before being passed to myFunction then depending on the compiler and settings, argument's value may be indeterminate before use.
This means that it's value may not be null or zero (depending on type).
Value assigned BEFORE the call will be used inside the function.
When reading documentation on functions from external libraries of different kinds I have always seen the documentation state that a variable has to be [IN/OUT]. Could someone give me a detailed understanding on how [IN/OUT] relates to parameters of a function being passed by reference or by value.
Here is an example of a function I have come across that tells me it needs an [IN/OUT] parameter:
Prototype:
ULONG GetActivationState( ULONG * pActivationState );
Parameters
Type: ULONG*
Variable: pActivationState
Mode: IN/OUT
This part applies to all types of paramters - most library interfaces try to be C compatible, so it is more common to pass parameters by pointer, rather than by reference.
IN: When a parameter is listed as IN it is a guarantee being offered by the interface that it won't modify that parameter. In my opinion, this is better conveyed by marking the parameter as const, then the language itself will prevent modifications to the value. If this parameter is being passed by value, it is inconsequential whether it is marked IN in the documentation (or const in the prototype) since the parameter is local to the function anyway. But to avoid copying it may be passed by reference or by pointer, in which case the const keyword becomes very important.
OUT: A parameter marked OUT usually means that the value of the parameter when it is being passed to the function is not of any importance. In fact, if it being passed by pointer, it may even be required to be NULL, and the function will allocate memory and pass a value back to you.
IN/OUT: An IN/OUT parameter usually indicates something where both the input and output values are meaningful. For instance, if you have a library function that fills a buffer, it may require you to pass a pointer to the buffer, along with another pointer indicating the length of the buffer. When the function returns, the second pointer may contain the actual number of bytes that have been written to the buffer.
This parameter is in/out because you provide a value that is used inside the function, and the function modifies it to inform you about something that happened inside the function. The usage of this function would be something like this:
ULONG activationState = 1; // example value
ULONG result = GetActivationState(&activationState);
note that you have to supply the address of the variable so that the function can get the value and set the value outside the function. For instance, the GetActivationState function can perform something like this:
ULONG GetActivationState(ULONG* pActivationState)
{
if (*pActivationState == 1)
{
// do something
// and inform by the modification of the variable, say, resetting it to 0
*pActivationState = 0;
}
// ...
return *pActivationState; // just an example, returns the same value
}
Note how:
The function accepts the parameter as a non-const pointer to an UINT. This means it may modify it.
The function can access the value you gave to the parameter by dereferencing it
The function can modify the parameter again by dereferencing it.
The calling function sees the activationState variable holding the new value (0 in this case).
This is an example of "pass by reference", which is performed by using pointers in C (and also with references in C++.)
Generally, things marked as IN/OUT will be passed via a non-const pointer or reference, allowing the function to modify the variable directly, as well as read it. Be sure to check the documentation to see if it expects the value to be set prior to passing it in.
Parameters marked as IN will be passed by value, or by constant pointer or constant reference, disallowing the function from modifying the variable.
C++ doesn't enforce OUT-only parameters, but generally they will be passed using non-const pointer or references, similar to IN/OUT.
If a parameter is OUT, it has to be passed by reference. A purely IN parameter would be usually passed by value or const reference, if the cost of copying is too high (nothing prevents the designed from passing it by reference, but it's not very good design IMHO). An IN/OUT parameter must be passed by reference.
I'm of a mixed mind regarding the use of in, out, and in/out.
Upside: When done properly, it communicates intent to the reader of the documentation.
Downside: Far too often it is not done properly. Those designations obviously are not a part of the language; they are either in comments or are in some document that is maintained separately from the code. I've seen far too many cases where a parameter was marked as "out" but the first thing done in the code with that parameter is to use it as a right-hand side value.
You can use by value (simply types) or by constant reference const & for input only parameters. Use non-const reference & or pointer * as in/out parameter to change the value of the variable. You can also use a pointer reference * & to allow you to change the address the actual pointer points to (in/out). As Dave Smith pointed out there is no out only parameter in C++.