[Nexus-developers] C++ NAPI - My version is "done"

[Mark Koennecke]

Peter,

Peterson, Peter F. wrote:
> Everyone,
>
> I just did my last commit on the new API and am now opening the doors to
> criticism/critiques. The API itself is at
> <http://trac.nexusformat.org/code/browser/trunk/bindings/cpp> with a
> test program (mirrors the standard self-test)
> <http://trac.nexusformat.org/code/browser/trunk/test/napi_test_cpp.cxx>.
>
>   
Thanks for doing this.
> Some things to note in particular:
>  N1. I made explicit enumerations for many things.
>  N2. There is a NeXus::Exception class which is thrown if something goes
> wrong rather than integer return types.
>  N3. Where appropriate I used structs rather than a collection of
> primitives. This was done to make the code more readable.
>  N4. As possible the API returns values rather than have the user supply
> pointers. To get a feeling of how this works look at the test.
>  N5. I tried to wrap the C api in the order that functions are found in
> napi.h. Let me know if I missed anything. Some functions are made
> private as the C++ API uses collections instead.
>
> Decisions that need to be made:
>  D1. For makeGroup and makeData there is a flag as to whether or not to
> open the newly created item. The current default is to not open. I think
> we would be better off with "true".
>   
As Freddy already suggested, I opt for false.
>  D2. writeData (all varieties) currently close the data as well. Should
> there be an option to leave it open?
>   
The writeData() functions are new convenience functions,  on top of the
standard NeXus API. I agree that they perfectly make sense. But I do wonder
if they should not be in a derived class extending a base NeXusFile class.

>  D3. For getData there are two variants, one takes a vector reference,
> one returns a pointer to a vector. Which feels more like C++?
>   
I side with Freddy, allow existing arrays to be reused. As the function 
resizes anyway...

I initially was worried about the C++: it makes heavy use of feautures 
like templates
and name spaces which in my experience cause compiler compatability 
problems.  To prove that 
I remembered that I have three different C++ compiler on my machine and 
tried them.
As expected g++ worked fine, Intel C compiled but failed to link because 
there was a mixture
of g++ and Intel c++ compiled code; this is a problem with the setup on 
my machine.
Pgcpp (Portland Group C++) failed with a rather mundane problem: it did 
not have uint8_t, etc.
This is fixable and I am far more confident that the new binding can be 
made to work with
different compilers.

> Do people want to get together sooner than the 27th to discuss this by
> video/tele-conference? Depending on the level of feedback I'm inclined
> to hold the discussion by email.
>
>   
No need, email is good enough

          Mark
> Thank you for your input.
>
> P^2
>