Longs Peak and beyond

why the ‘t’ at the end of glTemplateAttrib?
There’s a semantic difference between passing an enumeration token and passing an int. An integer is a number; it has no intrinsic meaning. An enum token does have a semantic meaning.

which seems to more closely match the naming convention of other functions
What other functions? You mean in the OpenGL 2.1 which is not part of Longs Peak? No point in being consistent with 2.1 since Longs Peak is not a 2.1 extension. As long as they’re internally consistent, it’s fine.

I see what you’re saying, but here we’re passing both.

Maybe by the same line of reasoning, it should be something like

glTemplateAttribtti_i() (first i for parameter type, second for attribute type)

That’s where it seems either not verbose enough, just a little redundant, or plain unfamiliar. Since I think that it’s impossible to set an int attribute with a float value, I’m leaning a bit towards redundant, only I’d agree that the semantics would be effectively swapped in this case; you’d be describing the type of attribute, rather than the type of argument (I think that’s what threw me).

I see no harm in maintaining some familiarity within the new API, so long as it doesn’t interfere with things going forward. I think predictability and consistency are two of the nicest aspects of OpenGL. And I also think the traditional conventions employed by the API are just plain cool :wink:

Cheers

I don’t understand what the problem is. They explained how this works very clearly in the newsletter . What is the part that’s unclear?

Is it simply that they are saying that an enum is a type separate from an integer that concerns you?

I was just a bit curious about the naming convention. Now after thinking it through a bit, it actually makes a good deal more sense.

I noticed some concern over this in another thread too, mainly with respect to the underscore. This is a novelty in the GL landscape, after all, so I think it’s pretty understandable.

Anyway, it’s all good.

Cheers

A Jedi friend told me a few weeks ago, that he felt a disturbance in the force. Now we know, it was the underscore.

That underscore doesn’t feel right to me either. Were any alternatives considered?

Oh come on, guys. It’s just an underscore. It’s not the end of the world.

Originally posted by Flavious:
Any chance of getting a sneak peek at what this might look like? :slight_smile:

const int attribs[] = {
    WGL_CONTEXT_VERSION, 3,
    0
};
HGLRC ctx = wglCreateContextVersionEXT(hDC, shareContext, attribs);

Originally posted by remdul:
That underscore doesn’t feel right to me either. Were any alternatives considered?
Yes. We just haven’t found any alternatives that seem any better :confused:

Originally posted by Jon Leech (oddhack):

const int attribs[] = {
WGL_CONTEXT_VERSION, 3,
0
};
HGLRC ctx = wglCreateContextVersionEXT(hDC, shareContext, attribs);

And off we go, for the next round of speculation!

Honestly guys, you are making your own life even harder, by presenting bits and pieces, because now people will again speculate how the rest looks like.
I can understand, that it itches you to show your results, but maybe you should wait a little and then present one complete thing. We have got so much information the last week, we have enough to speculate about for at least a month :wink:

We are all very enthusiastic about this!

Jan.

Any chance to get rid of pixel formats? Or to make rendering context pixel-format neutral as long they are on the same device?

Jon, just as an aside, I totally understand why the C interface is critical and I don’t dispute that. And I understand why any internal C++ objects aren’t exposed as such.

But what do you all think about exposing a standard C+±style set of wrappers (at least) to add some much-needed syntactic sugar?

For example, using templates and/or simple polymorphism in C++, all this explicit name mangling can go away, leaving us with glTemplateAttrib() and more type safety overall.

Isn’t an API redesign the right time to introduce something like that? (of course maintaining compatibility for those using other languages – I understand the issue of apparent forking would be a concern, but it can also be addressed, for example, by using the dreaded underscore in C prototypes where we’d see angle brackets in C++ template instantiations).

For example, using templates and/or simple polymorphism in C++
There’s no need for templates or polymorphism. Simple function overloading will suffice for most of the cases.

And I also see no reason why this has to be done by the ARB.

Thank you very much for the peek, Jon. I had no idea it would look so simple. Very nice indeed.

Cheers

Simple function overloading will suffice for most of the cases.
Yes. That’s what I meant by simple polymorphism. :slight_smile:

I can see two reasons for the ARB to be involved, if not necessarily doing the coding. One is that if there’s an official C++ naming scheme, it would make it easier and more consistent to show the translation to C names, for example, in man pages. To some extent, that requires starting with C++ names and basing the C names on those. IOW, the C++ choices inform the C choices more than the reverse.

Two, is that there are a dozen different ways do accomplish the C++ wrapper (I think I may have tried them all :wink: and the ARB group working on API issues has the implicit authority to bring this aspect to a conclusion. I just hope they don’t mind me suggesting more work for their plate. :slight_smile:

-Avi

Fortunately, since Longs Peak is very object-based, there’s really only one way to make a C++ wrapper.

Or, at least, only one right way.

Well, if anyone from the ARB wants to send me a draft of the new API at whatever point, I’d be happy to help type up a proposal for that “one true” C++ wrapper. I tend to think there would still be things to debate, in any event.

Let’s keep this simple. Leave them alone to keep it simple, and to get it out of the door sooner rather than later.

Why should the ARB bother with any particular language besides C? Why C++ and not Java, C#, Lisp, Python, insert your favourite language here?

Better let them just define a single C API, and let others do all these other languages.

IOW, the C++ choices inform the C choices more than the reverse.
The C choices can be taken in C++ without change, while the other way round is not possible without change. It may not be the most beautiful naming, but it works in (nearly) every language out there.

Believe it or not, there are a lot more languages than C and C++, so it’s not just as simple as changing a few names. Most languages define some way to import C functions, so C is definitely the way to go if you want to support as many languages as possible.

Simple function overloading will suffice for most of the cases.
The same reason why an underscore is neccessary in the first place prevents you from using overloading:
glTemplateAttribt_if(enum, int, float)
glTemplateAttribti_f(enum, int, float)

I don’t know if this particular combination exists, but I think you get the idea.

PS: Polymorphism has nothing to do with overloading :wink:

The same reason why an underscore is neccessary in the first place prevents you from using overloading:
Which would be why I said most cases.

On a completely different note, has the OpenGL GDC stuff started?