   C++ or C-Style API for game engine?
  Hi,Well I guess this is rather a question of personal taste but I would like to hear some opinions about this. The engine I am working on is entirely written in c++ and I am thinking about writing an extra c-style API. I think this is useful for people who don't want to see anything of how the engine works internally. Anyways, at some point it might be good to know what classes to look at to customize things for instance.So my experience is that c-style API is great if you are not familiar with specific engine details, but can be confusing if you get to more detailed applications. Also why would I hide that my engine is OOP? I currently tend towards keeping the API OOP style (for instance like ogre) because even though its not as easy to read as simple c-style functions, it does not hide any details from me, which has it's pros too.What is you preference/experience about this topic?   
Quote:Original post by mokaschittaI currently tend towards keeping the API OOP style (for instance like ogre) because even though its not as easy to read as simple c-style functions, it does not hide any details from me, which has it's pros too.This is totally backwards. Objects should hide irrelevant implementation details. That is one of the fundamental tenets of OOP and writing abstract data types.   ;  By writing a C based API you are doing the opposite of what you want to do, hiding the implementation details. In order for such an API to work you would probably have a lot of those details on display to the end-user as they won't have the objects to hide them away and do it for them.   ;  Using C does not mean that the structures must be visible. A common C idiom is the "opaque pointer" which hides the implementation in a neater way than C++. Another way is to use integer id's like OpenGL does.If that is what bothers you then it can be done in C++ too. For example by exposing only interfaces and hide the actual implementations.I think you will miss a lot of features from C++ when writing the C interface. Inheritance will not be as simple as in C++. You will soon miss templates. All functions must have unique names. Function names must be longer because of prefixing. I can go on. :-)I would perhaps choose C for a small portable library which does only one thing.;  I'd never heard of such an idiom! Learning lots of new things today!   ;  The OP did not say they were actually going to use C, but simply a C-style, or procedural API.That said, whether an API is procedural or OO has little or nothing to do with how many details it exposes. What I would do is build a procedural API, maybe in C itself for portability, then write a thin OO wrapper. It's just more natural to build in that direction.I'm really curious where you got this idea that a C-style API hides more than an OO one.   ;Quote:Original post by theOcelotThe OP did not say they were actually going to use C, but simply a C-style, or procedural API.And the OP never said anything about a procedural API, either. C does not automatically imply procedural, or non-OO. There are plenty of OO C libraries out there. They don't have all the bells and whistles, like polymorphism, but they are based around object manipulation and provide varying degrees of encapsulation. SDL and OpenGL are two obvious ones that spring to mind.@OP: A C interface is great if you want to open your API to use with a variety of languages outside of C++ (including C). It makes it much easier to create bindings for libraries when the interface is exposed as a set of C functions. The problem with using C++ libraries in this scenario is that there's an awful lot of mangling going on with the symbols, and it's up to the compiler what that mangling is. Some languages are ABI compatible with C, but it can be a tremendous amount of work to make them ABI compatible with C++.The SFML library does this. It's a C++ library using a number of C++-specific features. But they have a C interface that makes it quite easy to use the library with C or to create bindings for other languages. But if you aren't interested in making it available for that sort of usage, then I wouldn't bother.   ;Quote:Original post by AldacronQuote:Original post by theOcelotThe OP did not say they were actually going to use C, but simply a C-style, or procedural API.And the OP never said anything about a procedural API, either.I'm fairly sure that's only because he didn't know the term. Unless my understanding is totally off, SDL and OpenGL are procedural API's.   ;  Yes, I actually didn't know the term, I am self tought, so I am still learning alot. Well I was actually thinking about API implementations like for instance openGL. Since I plan on making use of uint handles whenever possible, creating an API on top of it built around the concept of handles propably is a good idea. Thanks for your input, making a so called "procedural" API seems to be a great thing! Anyways, I will propably wait with its implementation until everything else reaches a state where it makes sense.Thanks!   ;Quote:Original post by mokaschittaSince I plan on making use of uint handles whenever possible, creating an API on top of it built around the concept of handles propably is a good idea. Thanks for your input, making a so called "procedural" API seems to be a great thing!Why is that a good idea, though, for you? Are you already using uints in your OO API?   