Re: Question about QofIdType assertion in QofCollection

[Chenxiong Qi]

On Tue, Dec 30, 2014 at 1:08 AM, John Ralls  wrote:
>
>> On Dec 29, 2014, at 7:32 AM, Chenxiong Qi  wrote:
>>
>> On Mon, Dec 29, 2014 at 8:22 PM, Derek Atkins  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
>
> 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() 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

Swig and C++11

[Geert Janssens]

On Wednesday 24 December 2014 08:38:06 John Ralls
> ... although the SWIG folks still have some work
> to do to fully assimilate C++11 [1].
> 
> 
> [1] http://www.swig.org/Doc3.0/CPlusPlus11.html

I'm taking this line out of its wider context of the python wrapper discussion 
because it may 
be more important than only the python wrappers.

We also depend on swig for our interaction between current c(++) and guile code.

If we rewrite the engine in c++11, and want to export these new objects to 
guile, swig's 
capability to handle c++11 code becomes important.

I don't know that much about swig's internals. I do know it has a generic core 
and each 
supported language has its own module for language specific implementation. The 
python one 
is currently the most actively developed one.

The guile module on the other hand has no active maintainer and hasn't had one 
for years. (I 
had to implement the guile 2 compatibility myself for that reason).

So it may well be possible that swig's c++11 support for guile is quite broken. 
I don't think it 
gets tested other than "it builds". It is lacking lots of run time tests.

Geert
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Swig and C++11

[John Ralls]

> On Dec 30, 2014, at 3:56 AM, Geert Janssens  
> wrote:
> 
> On Wednesday 24 December 2014 08:38:06 John Ralls
> > ... although the SWIG folks still have some work
> > to do to fully assimilate C++11 [1].
> > 
> > 
> > [1] http://www.swig.org/Doc3.0/CPlusPlus11.html 
> > 
>  
> I'm taking this line out of its wider context of the python wrapper 
> discussion because it may be more important than only the python wrappers.
>  
> We also depend on swig for our interaction between current c(++) and guile 
> code.
>  
> If we rewrite the engine in c++11, and want to export these new objects to 
> guile, swig's capability to handle c++11 code becomes important.
>  
> I don't know that much about swig's internals. I do know it has a generic 
> core and each supported language has its own module for language specific 
> implementation. The python one is currently the most actively developed one.
>  
> The guile module on the other hand has no active maintainer and hasn't had 
> one for years. (I had to implement the guile 2 compatibility myself for that 
> reason).
>  
> So it may well be possible that swig's c++11 support for guile is quite 
> broken. I don't think it gets tested other than "it builds". It is lacking 
> lots of run time tests.

I don’t think that that will be much of a problem. In the near term we need to 
maintain C wrappers anyway so that the engine remains accessible to the GUI. 
SWIG can just wrap those wrappers for Guile. What will be more interesting will 
be moving the core functionality that’s currently in Scheme (e.g. business 
options) into C++11 because those classes will presumably interface directly to 
Guile via SWIG. The abilities of SWIG to do that might affect the way we 
program the interaction, but we won’t know until we start on it.

In my weak understanding of SWIG’s internals it parses the wrapped API into an 
intermediate representation and uses that to generate the wrapper API in 
various  languages. If that’s right, then only changes in the internal 
representation will affect the Guile API. I don’t think there will be many.

There was one section that caught my attention, about lambdas:
"The lambda functions are removed from the wrappers for now, because of the 
lack of support for closures (scope of the lambda functions) in the target 
languages.”
Clearly they weren’t thinking about Scheme when they wrote that! Since SWIG 
does support functors (a.k.a. function objects, classes which have only a 
constructor and which do their useful work in the constructor), which is in 
large part what lambdas are intended to make simpler, I imagine that it’s the 
capture feature that they’re having trouble with. I see that as more of an 
implementation detail rather than something we’d want to wrap.

Regards,
John Ralls

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Question about QofIdType assertion in QofCollection

[John Ralls]

> On Dec 30, 2014, at 1:40 AM, Chenxiong Qi  wrote:
> 
> On Tue, Dec 30, 2014 at 1:08 AM, John Ralls  wrote:
>> 
>>> On Dec 29, 2014, at 7:32 AM, Chenxiong Qi  wrote:
>>> 
>>> On Mon, Dec 29, 2014 at 8:22 PM, Derek Atkins  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
>> 
>> 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() 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?

Qi,

You have to look at the usage of each call. qof_collection_insert_entity is 
used by QofInstance to register itself with the book and stores a backlink to 
the collection so that given an instance the collection can be easily retrieved 
and searched for something else, while qof_collection_add_entity is used by 
gncInvoice for a private collection. In the latter case over-writing the 
collection pointer on the instance would destroy the back link to the book’s 
collection.

The backlink is redundant since every instance also has a pointer to its book 
and the book owns the collections in question, so when reimplementing it I 
wouldn’t include the collection link, but the current design needs it.

When searching for a function name remember to search for scheme wrappers, 
where underscores are replaced with hyphens. E.g. `grep -r 
gnc[-_]get[-_]current[-_]book src`. 

Regards,
John Ralls


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel