Yes, it's probably a bad thing to reuse the core name of the function. But I don't think testing it with preprocessor directives would solve the problem: it will be a macro only if defined by GLEW; if it is defined in the GL header, it will be a regular function.



I don't understand why so many casts would be needed. As far as I know, "anything op float" yields a float, so there's no need to cast both operands every time.

But the problem is, it will never be defined in the GL header, at least on Windows, unless Microsoft decides that Windows should support a more recent version of OpenGL than what... 1.1? That would break all their precious customers' systems who don't have cards that can support anything more recent, which is also why DirectX has a hardware emulation layer. If OpenGL had a software rasterizer fallback that took care of newer features it wouldn't be a problem to do so, but it isn't part of the standard and Microsoft hasn't shown any interest in it either.This is why GLEW goes ahead and defines even core functions. The goal is that every extension that is proposed goes through a sort of standardization process.First it is probably only supported by a single vendor AMD/Nvidia, then it has the NV or ATI/AMD suffix.Once the vendor can convince other vendors that what they are doing is good, it gets the EXT suffix.When it is submitted to ARB for becoming part of the core API, it gets the ARB suffix.Finally when it gets into the core specification it loses all suffixes.The function will stay in the GLEW header, probably forever, but over time it will change its name, and maybe even its functionality a bit.The only reason why the redefinitions that are in GLExtensions.hpp work now, is because the assumption that "if the card supports the core function it supports the EXT variant as well" holds. As wintertime already said, this can be problematic because they are not required to have the same behaviour, and it is up to the card manufacturers to drop support for legacy APIs if they have had core support for a long time. It might just be that at some point glGenFramebuffers will be available from GLEW, but glGenFramebuffersEXT not, and with those redefinitions you are overwriting a working name with a non-working one. This will break things because the redefinition takes place after you include GLEW the first time and if the compiler can't find the definition of glGenFramebuffersEXT after the preprocessor replaces glGenFramebuffers with it, or even worse tries to call glGenFramebuffersEXT although it is not set up, bad things will happen.I think if you need a common entry point for those different GL functions you should create your own name block for it, something like SFGenFramebuffers and use the GLEW extension probing macros to decide which to assign to it, favouring core functions of course. This is how many other libraries alias lower level functionality in such situations.In the case of a binary operation, yes that is true, but it is also a matter of signalling the programmer's intention, and technically, if you cast one operand on the right-hand-side just to get a floating point operation, you are losing precision over casting the result after the integer operation instead.When there are more operands involved it sometimes isn't always obvious in what order the implicit casts will take place. The goal is to cast as late as possible to take advantage of lossless integer operations but early enough if you know an integer operation will lose precision because it can lead to a fractional value.I've just made it a habit to explicitly specify casts for everything so I know exactly what happens. Leaving things up to the compiler to decide works most of the time, but when higher level semantic knowledge gets involved, the compiler doesn't really have many possibilities to be smart about how it generates code, especially in a case where the standard instructs it to do something we didn't expect.