@Stephen:
You’re correct, I didn’t thought of that as a reason.
(Main focus was flexibility.)
Speaking about it, ogl would be better if all version parameters consist of a few int:
ui - uint (32 bits)
For being complete, the version should have 3 ints.
Because the version is in the form: x.y.z
Writing code to compare values is easy with this system.
Thus change of request:
change all version strings into array of ints, with a defined naming and comparing behaviour.
Something e.g. (This is for illustration purposes)
3 int:
Major = first int
Minor = second int
third = third int
Methods:
(API: Minor and major is a good idea, wait a minute, why not use numbers that also indicate the importance and leaving the 0 for the build, if there is no build then don’t use zero:
1 comes first thus:
getVersion: returns all, everything
get1Version: returns the major version number
get2Version: returns minor version number
get3Version
Notice how naming the numbers this way is very intuitive, efficient and clear.
Determining which number is larger is just a matter of comparing the 1st if they match the second and so on…
And the first numbers always have a higher importance
(Major > Minor) then the numbers after them in sorting:
example: 3.1 > 1.4, tada no string issues.
Because it’s comparing two sets of two ints that are ordered by precedence. One has the highest precedence, the larger the number the lower the precedence.
Not to mention flexible, scalable:
//When version number of something is something weird with:
x.y.z.w.v.
then the following becomes:
for w: get4Version
for v: get5Version
For completeness:
Build version is an int
method:
get0Version: returns the build version
Please do allow modular use of these methods:
glversion.get1Version
shadingLanguageVersion.get1Version
End of e.g.
About the ogl --> svg
The geometry shader looks a very convenient starting point for this. Maybe this is (??going to be??) possible to do with ogl, ocl (and openvg)?