[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [h5md-user] Mandate Variable-length string datatype

From: Pierre de Buyl
Subject: Re: [h5md-user] Mandate Variable-length string datatype
Date: Tue, 24 Sep 2013 12:32:20 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

On Tue, Sep 24, 2013 at 11:06:57AM +0200, Konrad Hinsen wrote:
> Peter Colberg writes:
>  > Abstractions are very hard to get right. To day I have not seen a
>  > single C++ interface to HDF5 that is useful beyond the initial goals
>  > at its conception.
> I am tempted to make some mean comments about C++, but I can just
> force myself to shut up ;-)
>  > While it is important to have high-level interfaces that guide new
>  > H5MD users (e.g., pyh5md), it is equally important to support those
>  > users that write high-performance programs using the HDF5 API.
> Another nice illustration for the importance of practicalities.
> In this particular case, we have
> 1) String data in trajectories are usually small in amount (I have yet
>    to see a use for time-dependent string data), so efficiency of storage
>    and access is of secondary importance.
> 2) In high-level languages such as Python, dealing with any kind of string
>    data is easy enough.
> The priority in defining the layout for string data should thus be to
> reduce the barrier for dealing with H5MD in low-level languages. My
> own experience is C, which makes me prefer variable-length strings,
> but of course there are other languages to take into consideration.

Fortran allows both and both require some work (a few extra commands to manage
the strings).

>  > Keeping the choice between fixed- and variable-length strings will
>  > simply mean that many writers and readers will not be interoperable,
>  > even if they use the same domain-specific data.
> Here are the pros and cons as I see them:
>  Mandatory string type (either fixed or variable)
>   + simplifies software for reading H5MD
>  User's choice of string type
>   + simplifies software for writing H5MD
>   - likely to create incompatibilities because people will write
>     H5MD readers with a specific "dialect" in mind
> Personally that makes me favor a mandatory single string type.

My opinion also goes toward simplicity, that is a "variable length strings for


reply via email to

[Prev in Thread] Current Thread [Next in Thread]