On Tue, Dec 30, 2014 at 1:08 AM, John Ralls <jra...@ceridwen.us> wrote:
>
>> On Dec 29, 2014, at 7:32 AM, Chenxiong Qi <qcxh...@gmail.com> wrote:
>>
>> On Mon, Dec 29, 2014 at 8:22 PM, Derek Atkins <de...@ihtfp.com> wrote:
>>> Because it's a constant.
>>>
>>
>> Thanks!
>>
>> In following scenario, a QofInstance cannot be added into a QofCollection
>>
>> QofIdType type = "some type";
>> QofInstance inst = g_object_new (QOF_TYPE_INSTANCE, NULL);
>> inst->e_type = type;
>> QofCollection coll = qof_collection_new (type);
>> qof_collection_add_entity (coll, inst);
>>
>> The last call will always fail, because coll's e_type has different
>> address with the original variable type due to invocation of
>> static_cast<QofIdType>
>
> Which is a good thing in this case, because otherwise it would crash when you
> try to test inst->e_type later, after the function has exited and type is no
> longer valid. It's not the static_cast<QofIdType>() that changes
> coll->e_type, it's CACHE_INSERT(type), which does a string copy so that the
> type doesn't go out of scope.
>
> You can either preempt it with
> QofIdType type = STRING_CACHE("some type");
> Once the string is in the cache, all other calls to STRING_CACHE() will
> return the same pointer, or you could create the collection first and then
> inst->e_type = qof_collection_get_type (coll);
>
Thanks Mr. Ralls. I'm writing unit tests for QofCollection C
interfaces, that allows me to know much details of QofCollection and
QofInstance. Another question is about qof_collection_add_entity.
Sorry for not starting a separate thread for this, I think they are
same things of a kind to QofCollection.
qof_collection_add_entity does not set collection attribute of a
QofInstance once it is added, but qof_collection_insert_entity does
this. This confuses me. By going through the code, I think both of
them should have same behavior. Am I right, or something I missed and
understand incorrectly?
> Your C++ implementation won't work that way, of course: You'll use templates
> to enforce proper type safety instead of horrid string hacks. Right?
>
> Regards,
> John Ralls
>
>
>
--
Regards,
Chenxiong Qi
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
