Re: two bugs in ShaderObjects.hs

On 20/01/15 12:14, Sven Panne wrote:
> 2015-01-20 11:53 GMT+01:00 Claude Heiland-Allen <[email protected]>:
>> [...]  But for the second bug, the only way to tell if the
>> glGetShader call failed and left memory unchanged is by checking the GL
>> errors within the binding.  I doubt shaderVar will be used in an inner loop
>> so the performance hit should be acceptable.
>
> Again, there is no need for the binding to check anything, the general
> contract is: If before any call there are no registered errors,
> nothing bad will happen. Randomly inserting some checks in some
> arbitrary places in the binding to check for application programmer
> errors is probably not the way to go. There are more than 80 other
> places in the binding where something similar might happen, why should
> shader queries be special? And as I've previously mentioned,
> exceptions generate more problems than they solve IMHO, at least in
> conjunction with resources and/or mutable state.
>
> In a nutshell: If you want to debug your application, regularly check
> the OpenGL error state, don't expect any kind of error checking being
> done for you. And more often than not, even disable those error state
> checks in the final product for performance reasons.

Ok, I do understand this philosophy, but one last suggestion: replace 
'alloca' with 'with 0' to at least avoid reading uninitialized memory 
when the application programmer makes a mistake (0 should be a sensible 
default in most cases I imagine).  If git patches for this replacement 
would be accepted, I would be willing to submit them for as many places 
in the binding as I can find.


Claude