I am currently using gluPerspective to setup my perspective projection. Since I want to use OpenGL 4.0 I have substitute code to setup perspective. Should I avoid using gluPerspective? What can happen in the long run if I use deprecated functions?

It's true that gluPerspective is just a software helper function, but -- it will most likely call either glFrustum or glLoad/MultMatrix internally (haven't checked and would be implementation-dependent anyway - although glLoadMatrix would violate spec) and those calls ARE deprecated.

It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.

i looked around the web on this there is some conflicting information stating 'opengl 3+ doesn't support gluPerspective' and there are the once that state like Hodgman said 'glu is not part of opengl so it is still valid'. I checked opengl spec file i found on opengl.org it seems that it is not deprecated after all.

Lets solve it in the simplest way. Create a core GL context and call the function you want. If it works, it is not deprecated. glu is not the part of the core functionality, so it cannot be deprecated directly, but it uses deprecated (legacy) commands, so it cannot be executed in the core profile. In short, it is not deprecated since it has never been the part of the core, but it cannot execute in core context now.

Sorry for this post. Combination of Android, Opera Mobile and scripts on this page generated two identical posts. Since there is no way to delete a post (reqest for the administrator/web master), I had to modify it.

And what do you expect to happen when you call it, even if there is no error reported? The function operates on the current matrix stack, but there is no such thing in a core context.

Yup, this basically.

If gluPerspective works in your tests, all that means is that your GL implementation is not fully conformant in that it's allowing you to do things in a core profile that you should not be allowed to do. So the fact that it works is something you should most definitely not be relying on, because a future driver revision, or other hardware, could quite easily break it.

If you want to construct a perspective matrix there is a much easier way that will work in all cases. Just grab a sample implementation of gluPerspective from something like Mesa and re-implement it in a conformant manner. Or better yet, use a tried and trusted matrix library that will already contain a routine for constructing a perspective matrix.

It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.

In OpenGL 4.0, the entire fixed-function pipeline (used by glu*) is deprecated. This is exactly why I never use helper libraries—the core moves on but the helper libraries don’t.
If you are using shaders as you should be (in OpenGL 4.0, not using shaders is deprecated) then there is no way glu* can help you. The matrices you want to create will be used by you manually in your shaders.

This is actually a good thing honestly because OpenGL was originally not created for games and had some quirks in it that made it more of a nuisance than anything else (for example, lights were originally multiplied by the current model-view matrix, so you had to constantly update their positions every frame and in a very inefficient manner).
With shaders nothing is done for you. You have to write your own shaders and thus, by definition, you have to handle the primitive pipeline manually.

glu* and friends no longer have meaning because they set a bunch of states that you aren’t (shouldn’t be) using.
In OpenGL 4.0, you need to have your own matrix math library, calculate your own model, view, and projection matrices, and send them to your shaders manually.