summaryrefslogtreecommitdiffstats
path: root/testpar
diff options
context:
space:
mode:
authorBinh-Minh Ribler <bmribler@hdfgroup.org>2015-03-30 17:58:44 (GMT)
committerBinh-Minh Ribler <bmribler@hdfgroup.org>2015-03-30 17:58:44 (GMT)
commit98d1c2d9a9e0e0da02a3bd4367c574bfa3326af7 (patch)
treee37be4cd82fbee35783cdc0cd3634eac7d038c8f /testpar
parentd0cea60466ab11334e8069a45922a9e4cade1e69 (diff)
downloadhdf5-98d1c2d9a9e0e0da02a3bd4367c574bfa3326af7.zip
hdf5-98d1c2d9a9e0e0da02a3bd4367c574bfa3326af7.tar.gz
hdf5-98d1c2d9a9e0e0da02a3bd4367c574bfa3326af7.tar.bz2
[svn-r26655] Purpose: Fixed HDFFV-7947
Description: When copy constructor or constructor that takes an existing id is invoked, the C ref counter stays the same but there is an extra C++ object which later is destroyed and may cause the HDF5 id to be closed prematurely. The C++ library needs to increment the ref counter in these situations, so that the C library will not close the id when it is still being referenced. However, the incrementing of ref count left some objects opened at the end of the program, perhaps, due to compiler's optimization on cons/destructors. The constructor, that takes an existing id, needs to increment the counter but it seems that the matching destructor wasn't invoked. The workaround is to have a function for each class that has "id" that only sets the id and not increment the ref count for the library to use in these situations. These functions are "friend" and not public. The friend functions are: void f_Attribute_setId(Attribute *, hid_t) void f_DataSet_setId(DataSet *, hid_t) void f_DataSpace_setId(DataSpace *, hid_t) void f_DataType_setId(DataType *, hid_t) Platforms tested: Linux/64 (platypus) Linux/32 2.6 (jam gnu and Intel 15.0) SunOS 5.11 (emu)
Diffstat (limited to 'testpar')
0 files changed, 0 insertions, 0 deletions