Regarding Unix/Linux environment, it seems HDF5 library does not like my
NFS:
"unable to flock file, errno = 37, error message = 'No locks available'"
Is there any way to force this library to use lockf() instead of flock()
which is not available on NFS?
If any, I guess I have to recompile the library anyway - right?
Regards,
Rafal
W dniu 2017-03-29 o 11:44, Rafal Lichwala pisze:
Hi All,
I think I found a nice explanation of my problems with Windows binaries
of HDF5 library described before:
http://stackoverflow.com/questions/5339811/how-can-i-pass-c-objects-to-dlls-with-different-iterator-debug-level/5340065#5340065
So it seems I have to use recompiled version of that C++ API or just
forget about C++ and use pure C API instead.
BTW here is a nice article about how to properly implement C++ library
and be able to use them in Windows DLL world:
https://www.codeproject.com/Articles/28969/HowTo-Export-C-classes-from-a-DLL#CppMatureApproach
How it looks in the Unix/Linux world?
Are there similar problems in using binaries of those libraries?
I have to check that by my own anyway... :-)
Regards,
Rafal
W dniu 2017-03-29 o 09:39, Rafal Lichwala pisze:
Hi Elvis,
Thank you for your reply!
W dniu 2017-03-29 o 08:41, Elvis Stansvik pisze:
I think the API is just trying to be similar to strlen (and many other
APIs), which always return the string length excluding the terminating
null character.
If you think about it, it's logical; the terminating null character is
not part of the string, it's simply, well, the terminator.
I agree, but that means the second call to the H5Lget_name_by_idx (any
some others in API) does not behave as we want :-)
Let me explain on the example which I've sent previously: let's assume
the group name is "foobar".
So first call to H5Lget_name_by_idx() return 6 - that's correct - there
are 6 characters excluding NULL terminator.
So now I call H5Lget_name_by_idx again and pass 6 as a value of "size"
of expected name of this group. This time I just found "fooba" in the
buffer...
So I have to manually add 1 to size to get the whole name - that's not
intuitive I guess...
The documentation for H5Lget_name_by_idx function says:
"The size in bytes of name is specified in size. If size is unknown, it
can be determined via an initial H5Lget_name_by_idx call with name set
to NULL; the function's return value will be the size of the name."
To fix that simply, for that function (and some others in API) we could
just say: this function returns the number of characters in the name,
but expects the size of buffer (so +1 for NULL terminator).
Nevermind - that's really a minor issue - let's go to the next more
important one below...
That would indicate a compiler bug, since operator= of std::string is
defined to always make a copy. A compiler is not allowed to optimize
that away if it results in a behavioral change from a user POV.
Well... I've made some research about that and it seems it's not so
simple. It seems that depending on the platform and compiler parameters,
sometimes it's possible to have different implementation od this
operator= for std::string.
I know - that sounds strange, but maybe that's the case this time.
So I highly doubt that's the reason for your access violation.
I've just confirmed that there is something wrong with HDF5 binaries for
Windows x86 (ver. 1.10.0) (at least this version - maybe others too).
I've just downloaded HDF5 sources and compiled them locally (Visual
Studio 2017 with CMake support). Then I use those DLL's in my project
and... it works! No access violation and the group name is properly
returned.
It would help to see a minimal code example that exhibits the problem.
Sure. Here it is:
#include <iostream>
#include "H5Cpp.h"
using namespace std;
#ifndef H5_NO_NAMESPACE
using namespace H5;
#endif
#define FILE_NAME "new.h5"
int main()
{
try {
if (H5File::isHdf5(FILE_NAME))
{
H5File file(FILE_NAME, H5F_ACC_RDONLY);
Group g = file.openGroup(".");
cout << "Nr of links: " << g.getNumObjs() << endl;
for (hsize_t i = 0; i < g.getNumObjs(); i++)
{
string name = g.getObjnameByIdx(i);
// that's the place where access violation comes with
DLL binaries used
cout << "Link name: " << name << endl;
}
g.close();
file.close();
}
}
catch (FileIException error)
{
error.printError();
return -1;
}
catch (DataSetIException error)
{
error.printError();
return -1;
}
return 0;
}
Regards,
Rafal
_______________________________________________
Hdf-forum is for HDF software users discussion.
[email protected]
http://lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org
Twitter: https://twitter.com/hdf5
--
***
Rafał Lichwała
Poznańskie Centrum Superkomputerowo-Sieciowe
ul. Jana Pawła II nr 10
61-139 Poznań
e-mail: [email protected]
***
_______________________________________________
Hdf-forum is for HDF software users discussion.
[email protected]
http://lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org
Twitter: https://twitter.com/hdf5
