
On 20/01/15 12:14, Sven Panne wrote:
2015-01-20 11:53 GMT+01:00 Claude Heiland-Allen
: [...] 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