NeXus C++ API

[Brian Tieman]

To all,

I have a C++ API based on NAPI which I've been using for several years now.  The
API I've created hides the NAPI API almost entirely and allows for a much simpler
(in my mind anyway) interface to the data.  There is a class wrappered around NAPI
in the method Mark suggests and this class is the basis to create other classes
which do closely follow groups, datasets (fields in my naming scheme) and
attributes.

I have created C++ clases for groups, fields and attributes which can be linked
together in memory to form a memory structure which mimicks the file structure
which was read or will be written.  These classes, in turn, have been bundled into
a wrapper class I call the NexusBox--the header file for which is included.

There is also Java support for this class structure.

This API has been in use for several years and has served me very well.  It runs
on Windows as well as Solaris and Linux.

I have made mention that this API exists in the past, but I have not publicised it
too much for several reasons...

1)  The API does not support all of NAPI--most notable linking of VGroups.
2)  We don't currently write Nexus format files but rather write HDF files using
only the Nexus interface.  Although a general Nexus reader could read our
files--the metadata will not be where expected.
3)  We were toying with replacing NAPI entirely since it's only serving as a
gateway to HDF.  My API is also generic enough that the underlying file mechanism
is not what's important (we were thinking of adding NetCDF or HDF 5 to the API
independant of NAPI)
4)  Nexus does not appear to be catching on as a file protocol in the areas where
I actively develop.  We will likely keep my API, but we may abandon the efforts to
be Nexus compliant altogether.

That said, if anyone is interested in this code, contact me and we can discuss in
more detail what it does and how it works.  If there is enough interest by others,
I will clean things up a bit and make the code publicly availiable.

Brian Tieman
Experimental Facilities Division
Advanced Photon Source



Mark Koennecke wrote:

> Dear Sebastian Huber,
>
> On Wed, 9 Jan 2002, Sebastian Huber wrote:
>
> > Hello,
> > is someone working on a C++ API for NeXus or has someone developed one?
> > I'am currently working on this topic and it may be helpful to share ideas.
> >
>   There is nobody working on a C++ API. However we strive to have the
>   NeXus API in such a state that it can be compiled with a C++ compiler
>   and can be used easily with C++.
>
>   I wrote the Java-API for NeXus and this made me think about object
>   orientation within the NeXus-API and I want to share that. Initially
>   one would think that NeXus files, groups, datasets and attributes could
>   constitute objects of their own right. When taking a closer look into
>   this I realized that such a separation  would lead to very complicated
>   code due to the fact that the underlying HDF libraries are sophisticated
>   state machines by themselves. So I stepped back from this and just
>   encapsulated the NeXus-API in one class. This is also the way how the
>   people from NCSA did it for their Java-API's to both HDF-4 and HDF-5.
>   And I'am sure with due consideration and for a good reason.
>
> > The work on this API resulted in the question why the C API does not make a
> > consequent use of the const specifier?
> >
> > For example the NXmakegroup function:
> >       The first parameter is CONSTCHAR, but the second not, although the
> >       functions executed with that parameter (strcmp, sprintf and Vsetclass)
> >       declare it as const char.
> >
>   You are right, the NXclass parameter can almost always be CONSTCHAR as
>   well. I know that some people feel strongly about const and there are
>   even good theoretical arguments in favour of it. I personally am very
>   sloppy with const because it tends to come in my way and forces me to
>   clutter the code with lots of casts.
>
> > And why do you use sprintf instead of snprintf?
>
>   Probably because it is in the ANSI-C standard library and snprintf
>   isn't. Though it might be POSIX. I also learned about the virtues of
>   snprintf only recently when reading a paper about writing secure
>   programs. I think changing the code to use snprintf wherevever
>   feasible is a good idea. Before doing this I would like to check if this
>   function is available on all important platforms or if there is a
>   implementation of snprintf which can be distributed with the NeXus code
>   for systems which do not have that function. Any info about this anyone?
>   I know that both Linux and True64 Unix seem to support snprintf.
>
>                       Regards,
>
>                                 Mark Koennecke
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nexusbox.h
Type: application/x-unknown-content-type-hfile
Size: 7936 bytes
Desc: not available
Url : http://lists.nexusformat.org/pipermail/nexus/attachments/20020110/d20396af/attachment.bin