Hi Tim,

...

I am looking into switching CGMA's IDs from ints (4-8 bytes, signed) to RFC4122-style UUIDs (16 bytes, unsigned) so that cross-references across multiple large models are much less likely to have duplicate IDs.

While I think this is worth considering (and doing, if it were just CGM), I'm not sure it's so critical for file operations.

I'm not sure what you mean by "file operations."

...

One problem I am having is that CGMA performs math (addition/subtraction) on UUIDs in places. ... Also, CGMA compares/swaps CAUniqueId and TDUniqueId values, which I thought lived in different "namespaces" (sequential integers for CAUniqueId and random integers for TDUniqueId). Was I wrong to think this? If not, why does CAEntityId add the same id_inc to both its own ID and its merge-partner's (which appears to be obtained in some places using TDUniqueId::find_td_unique_id)?

Here I think you're wrong, the unique id and entity id are different concepts, and the find_td_unique_id in CAEntityId is used strictly with UIDs and not with entity ids.

Thanks, I will take a more careful look there.

To summarize, while I think it would be useful to use a standards-compliant UUID, in practice I'm guessing it's going to be difficult to motivate the Cubit project to change what they do to accomplish this, even if you/we implement all the changes in CGM and below. Cubit guys, please chime in here. It appears to me that GSaveOpen was probably meant to do what a true UUID change would, that is, guarantee different UUID spaces in different files, alas they solved it a different way.

OK. If we cannot find a good way to get by without UUIDs then we'll look to add them as a third attribute instead of a replacement for TDUniqueID. Thanks, David