Need help preparing for a C++ job interview

Hello,

I posted this in the general forum but wanted to post it here as well. Apologies if I am a bit out of line.

I have a job interview next week and the job description is as follows:

design and implementation of APIs for C++ and scripting language bindings
documentation of APIs
QA of APIs
software engineering
all phases of development: design, implementation, testing, documentation, maintenance, and bug fixing.

Can someone suggest what topics should I look at? Especially for the first bit. I have worked on C++ projects but never worked on libraries that were distributed to other people to link with their own code. What things should I look at and what kind of questions might I expect. Are there any special things or good design practices when designing a C++ library?

Similar thing with regard to script bindings, I have never worked on C++ code where there was scripting support embedded in it.

I do not want to cheat and give them the impression that I know it all, but I definitely want to look up relevant topics and give them the feeling that I am willing to learn things on the job and can get out of my comfort zone.

Thanks,

xarg

These might be the questions you should keep in your mind during the writing of API. (Especially C/SDK style API)

1. Did you check all parameters, NULL values, and invalid data?
2. How do you want to report error? Is it going to be true false, enum, exception, HRESULT or something else?
3. If you are passing buffer to the API, then who is going to allocate the memory of that buffer, and who is going to de-allocate it?
4. In case of passing the buffer, do you have the size of buffer? Is it fixed or passed as a parameter? Did you check it?
5. In case of passing buffer size as a parameter, if your buffer size is not enough, then how do you want to report and error? Do you want to return the required buffer size just like Windows API or use some other method?
6. If you are using any global resource in your API then do you provide the thread safety when using that resource?

Hi Zeeshan,

Thanks for your answer and definitely those are some of the low level details to worry about.

I have been looking at general overview and looking at some presentations, mostly by the Java community and some points do come up consistently.

- Be minimal.
- Be complete.
- Easy to read and maintain code that uses it even without documentation.
- Hard to misuse.
- Easy to extend
- Be open to refactoring.

I just wanted to steal from the collective experience of all the folks here about the specific issues relating to error handling:

Does anyone have ideas and opinions about error handling when designing C++ APIs? Of course, since we are dealing with C++ and OO, should we use exceptions (probably). Who should handle the exceptions and how should the error be propogated to the client code? I am not a big fan of having the user check the return value of every single function call. So, I was wondering how should the errors be best propogated and reported in the least obstructive manner. I know this might be a bit vague.

Many thanks,

xarg

It's ususally considered good practice to raise exceptions only for 'exceptional' events. By this I mean that it should be an error that is not expected to occur in the normal running of the code.

Hi John,

Thanks for the comment and it makes sense. Last night, I started taking a look at the code for Trolltech's Qt and that is exactly how they do it as well.

Thanks,
xarg

Will the APIs be developed in C++?
Will the APIs be used in projects written in other languages?

I have developed, supported, maintained various APIs for 10 years now. Here are some of the things that I have learned.

1. Consider other languages that may use the API

One of the biggest concerns is that the interface is "friendly" to as many other languages as possible.

When I started, I didn't consider that issue and I had a lot of users calling with issues about how to implement pointers in their language. I didn't have any idea that some languages might have problems with pointers. So, we stopped using pointers in our interfaces.

2. Error codes and messages.

We learned to make these as detailed as possible. For instance, one of the APIs I worked with just returned 3 error conditions - Success, Security Error, General Failure - Most users didn't even try to figure out what may have caused the problem and every time we got a call it could take up to an hour to track down the problem (depending on how cooperative the user was). So, we added detailed error messages.

3. The interface should be exported as C

If the API is going to be used by non-C++ languages or even by someone using a different C++ compiler than you, then you really need to export the API interface as C.

This just makes things easier. C++ will mangle the function names and exporting as C will not.

These might be some questions when designing the C++ API (Class library)

1. Is it going to be object oriented (like MFC) or generic (like STL) or mixture of both (like ATL)?
2. In case of object oriented are you going to inherit everything from one base class just like Java and .Net or there may be some independent classes too like MFC?
3. In case of inheritance did you make your destructor virtual?
4. In case of generic, did you properly specify the requirement of concepts (like iterators of STL)?
5. Are you going to do memory manager using RAII and smart pointer (like auto_ptr, shared_ptr etc) or compiler extension like __try and __finally block
6. From the physical design point of view, how many header files do we have to include using one (or more than one) required class? (Some header file inclusion can be eliminate if we avoid including header file within header file using forward deceleration)
7. How do you want to implement callback functions? Is it gloabal function, memberfunction, function object or something else?
8. How you are going to handle the name mangling of a compiler? Is your client using the same compiler or different one?
9. How do you report the error? If you display it in the form of message box then the client of your library might not make an application that run in batch mode.

Quote:

---

Originally Posted by xargon

...
I just wanted to steal from the collective experience of all the folks here about the specific issues relating to error handling:

Does anyone have ideas and opinions about error handling when designing C++ APIs? Of course, since we are dealing with C++ and OO, should we use exceptions (probably). Who should handle the exceptions and how should the error be propogated to the client code? I am not a big fan of having the user check the return value of every single function call. So, I was wondering how should the errors be best propogated and reported in the least obstructive manner. I know this might be a bit vague.
...

---

In my experience, it is best to return error codes from API functions. Ofcourse we didn't have any idea which language our users would be using and I don't have any idea how an exception thrown from a dll would be handled by another language.

Hi Kenrus,

Good insight. Many thanks for that.

xaqrg