C++ plans? (Re: r23706 - gnucash/trunk/src/register/ledger-core - Bug 721791)

[John Ralls]

On Jan 23, 2014, at 12:53 PM, Christian Stimming <christian at cstimming.de> wrote:

> Am Mittwoch, 22. Januar 2014, 20:01:02 schrieb John Ralls:
>> On Jan 22, 2014, at 6:15 PM, Derek Atkins <derek at ihtfp.com> wrote:
>>> On Wed, January 22, 2014 8:57 pm, John Ralls wrote:
>>>> PImpl, which decomposes as either "Private Implementation" or "Pointer to
>>>> Implementation" is a basic C++ idiom. Here's Herb Sutter's explanation:
>>>> http://herbsutter.com/gotw/_100/
>>> 
>>> Ahh, I do know this idiom, I have just never seen it named this way.
>>> Indeed, I use this idiom all the time, although I don't use "unique_ptr".
>> 
>> Unique_ptr is a new feature of C++11, replacing the old auto_ptr with
>> similar behavior and supposedly without the bugs. Fortunately we don't need
>> to require C++11 to use it, it's been in Boost since 1.37.
> 
> 1. In boost, the class is called boost::scoped_ptr; in C++11, it's called 
> std::unique_ptr, hence it can't immediately be switched one by the other. 

Indeed, I was fooled by http://www.boost.org/doc/libs/1_37_0/doc/html/boost/interprocess/unique_ptr.html,
which is for IPC. We don’t want that, especially for PImpl! 

But it’s easy to work around the naming difference.

> 
> 2. If we decide to switch to C++ at this point in time, by all means we should 
> choose C++11. Things like the auto keyword and the standarized things which no 
> longer require boost will make life so much easier in many places.

I agree, but I’m concerned that it will prevent building on any but the latest systems, and may even limit the systems we can build *for*.

> 
> 3. By all means, anyone who thinks about C++ in gnucash, please please have a 
> look in the already existing experimental code in src/optional/gtkmm/gncmm/ !! 
> For example, the C++ version of gnc_numeric is already there, in 
> gncmm/Numeric.hpp. When reading the discussion here, it still seems to me 
> nobody has really looked into how a C++ set of classes of the engine could 
> look like, while optional/gtkmm/gncmm was intentionally done as exactly one 
> example on how this might look like.

No. That’s backwards. The object of the exercise is to get rid of Glib, not to wrap it. Sorry, that code isn’t useful.
> 
> And the code already demonstrates the constraints that have to be thought 
> about when talking about C++... such as: Which string type will be used etc. 
> (Think Numeric::to_string() and Numeric::printAmount()) The class gnc::Numeric 
> is probably one of the very few classes where a C++ struct can directly be 
> used as a replacement of the C class. But this is the big exception. All other 
> "important" classes will give us plenty of headaches if there should be a 
> coexistence of C and C++ during a migration path. 

One handles things like which string (or iostream) class is being output with templates and type traits.

> 
> Also, pimpl in itself isn't of much value per se for an application project 
> such as gnucash. The picture is different if we're talking about a library, 
> but gnucash is an application. For an application project, IMHO it is usually 
> enough to keep the member variables private, hence guiding the developers to 
> use only the public interface of the class. Pimpl OTOH would just confirm this 
> access levels in a much stricter way. But as we're inside our own application 
> code anyway, IMHO using pimpl in itself isn't as important as it would be for 
> a library, and mainly a matter of taste.

No, the point of PImpl isn’t to enforce privacy, though it does do a good job of that. It’s to isolate recompilation so that making a change to a class declaration like adding a new member variable doesn’t telegraph through to the exported header and require recompiling everything.

Regards,
John Ralls