>>28
Does the 360 not support OpenGL at all?
>>27
Should have expected this response. I know it's the usual response to such things and I should not bother responding to trolls, but the whole thing about many parameters being NULL is just an inadequency of C's parameter list design. Unlike more high-level languages, C doesn't have support for comfortable support for: optional arguments, keyword arguments or variable number of arguments. (okay, you could use varargs to get support for such things, but it'd be more work for little gain, since C doesn't have a powerful enough macro system). So you pass NULL for arguments that you don't care about, instead of having some keyword arguments which your compiler could translate into appropriate calls. That said, NULL args are more efficient than direct keyword args as the arglist parsing is done by the programmer(human compiler), however it would be possible to do such transformations to keep the efficiency using a real macro(in a powerful enough language) or a compiler.
Example:
fun1 has 6 arguments: a,b,c,d,e,f
You only care to pass 2 values, c and f:
fun1(NULL,NULL,1,NULL,NULL,NULL,2);
In another language which supports keyword args:
(fun1 :c 1 :f 2) ;Much clear isn't it?
Now the compiler has 2 options, either pass '(:c 1 :f 2) as a list, and do the arglist parsing/destructuring in fun1 (slower, how it's usually done as someone might want to pass unknown arguments), or the arglist parsing can be done using a compiler macro which transforms it into a call like
(fun1 nil nil 1 nil nil nil 2). C doesn't have easy support for such code transformations, and MS chose it to implement their OS (and C++ for less important client applications).
[m]NULL, NULL, NULL[mm] are the cost of their compromise. It could be easily solved, but it won't be as long as they stay with vanilla C. (Reducing the feature-count is a non-solution for true ``
ENTERPRISE'' flexible applications, so don't even mention it.)