Back to the past - why so much trouble with list?

I like to get some straight , not "modern OpenGL " marketing smoke and mirrors from the group, if possible.

  1. here is my test code

    // create list
    DisplayListIndex = glGenLists(MAX_LIST); // create 10 display lists
    printf("\nDisplayListIndex %i function %s @line %d “, DisplayListIndex ,FUNCTION,
    LINE);
    //delete all
    glDeleteLists(DisplayListIndex,MAX_LIST);
    printf(”\nDisplayListIndex %i function %s @line %d ", DisplayListIndex ,FUNCTION,
    LINE);

Blockquote

  1. Here is the output

ENTER function OpenGL_DisplayList @line 173
DisplayListIndex 1 function OpenGL_DisplayList @line 181
DisplayListIndex 1 function OpenGL_DisplayList @line 187 > Blockquote

  1. I expect the DisplayListIndex = 0

What am I doing wrong ?

You’re expecting the wrong thing. glGenLists could generate almost any value (which doesn’t already overlap with existing display list indices); there is no reason to expect it to spit out any particular integer.

In fact, expecting zero is wrong because glGenLists will never return 0 unless producing the given number of list names is impossible. That is, returning 0 represents an error.

Zero is never a valid display list name.

To augment Alfonse’s reply, if you’re expecting glDelete* to zero out “DisplayListIndex”, then you’re expecting the wrong thing. That’s not how OpenGL objects work.

The uint returned by glGen* isn’t an “object” using a smart pointer or some automatic reference counting, like you might expect in an OOP language. It’s a 32 bit uint, period. It is an opaque name which identifies an object being managed by the GL, in the driver’s opaque data structure (e.g. a hash.) glGen* merely returns a name which can used to lookup (bind, modify, etc) an object, and glDelete* frees up that name (and, eventually, deletes the object in the opaque structure.)

If you want to know if “DisplayListIndex” is actually an object, see the glIs* functions (and read the documentation about when an object name is allocated vs when an object is allocated. The behavior is inconsistent for different types of object.)

Missed my point - I know the “value” being generated and zero is invalid.

I just cannot trust OpenGL to do what is advertising , period.
It states in so many fancy terms that I can reuse the list generated, it is not necessary to delete it.
I had too many “list indexes” floating around so I just wanted to verify if I actually deleted the list.
So the bottom line - delete list is bogus “feature” if it cannot be verified.
But I am getting used to OpenGL “terminology” - named int , OpenGL is not Object Oriented so we “have an object…types of object…”.

PS Linux uses “file descriptor”.

glGenLists allocates names, but does not create lists. Allocation simply provides you with names which aren’t already allocated.
glNewList creates a list. Most commands issued between the glNewList and the next glEndList are stored in the list. If the name already refers to a list, the existing definition will be overwritten. It isn’t strictly necessary to have allocated the name with glGenLists, but doing so ensures that you create a new list rather than overwriting some existing list.
glDeleteLists deletes any definitions for the lists and makes the names available for subsequent allocations. You can “clear” a list without releasing the name for re-use simply by calling glNewList immediately followed by glEndList, overwriting any existing definition with an empty command sequence.
glIsList will tell you if a name refers to a list. This is true from the point that glNewList is called to the point that the list is deleted with glDeleteLists. If glCallList or glCallLists attempt to use a non-existent list (not allocated, allocated but not created, or deleted), nothing happens; no error is generated.