C++ plans? (Re: r23706 - gnucash/trunk/src/register/ledger-core - Bug 721791)
christian at cstimming.de
Thu Jan 23 15:53:49 EST 2014
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.
More information about the gnucash-devel