On Jan 23, 2014, at 12:53 PM, Christian Stimming <[email protected]> wrote:
> Am Mittwoch, 22. Januar 2014, 20:01:02 schrieb John Ralls: >> On Jan 22, 2014, at 6:15 PM, Derek Atkins <[email protected]> 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 _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
