| 3 | | Attached is a patch that overrides the = operator to force a malloc + memcpy in that circumstance, but I'm not entirely happy with that solution, since it doesn't readily allow detection of out of memory conditions without introducing exception handling. My initial thought was to instead introduce a new BReferenceable subclass specifically for storing implicit value data, and then have ValuePieceLocation simply store a reference to such an object rather than a void pointer, so that the assignment operator would simply add a reference and deal with it from there. However, this is problematic due to ValueLocation's use of the Array class for storing its pieces. The latter uses malloc/memcpy/memmove to manage its internal array, and consequently doesn't actually wind up calling object constructors for its templated type. This in turn leads to a crash here, since this means it calls our overridden operator= on an uninitialized block of memory, and in turn, its member BReferenceable has an invalid pointer that it thinks it must release before assigning the new reference. If the Array class is generally intended to be used with C++ objects, that behavior seems suboptimal, but I'm uncertain as to the best way to fix it. Any thoughts/alternative suggested approaches? |
| | 3 | Attached is a patch that overrides the = operator to force a malloc + memcpy in that circumstance, but I'm not entirely happy with that solution, since it doesn't readily allow detection of out of memory conditions without introducing exception handling. My initial thought was to instead introduce a new BReferenceable subclass specifically for storing implicit value data, and then have ValuePieceLocation simply store a reference to such an object rather than a void pointer, so that the assignment operator would simply add a reference and deal with it from there. However, this is problematic due to ValueLocation's use of the Array class for storing its pieces. The latter uses malloc/memcpy/memmove to manage its internal array, and consequently doesn't actually wind up calling object constructors for its templated type. This in turn leads to a crash here, since this means it calls our overridden operator= on an uninitialized block of memory, and in turn, its member BReference has an invalid pointer that it thinks it must release before assigning the new reference. If the Array class is generally intended to be used with C++ objects, that behavior seems suboptimal, but I'm uncertain as to the best way to fix it. Any thoughts/alternative suggested approaches? |
