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

[Christian Stimming]

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. 

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.

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.

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. 

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.

Regards,

Christian