Am Donnerstag, 23. Januar 2014, 14:56:26 schrieb John Ralls: > > 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*.
This statement is true for the "building on" system (the host and build system for a cross compiler), but fortunately surely not true for the "build for" system (the target system of a cross compiler): gcc supports the majority of C++11 with 4.6 and almost everything with 4.8. The target systems are no fewer than what normal gcc/C++ can target. As for the build system, yes, that limits our build system choices right now. > > 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. That's wrong - the code is very much useful. Have you looked at it? Yes, it's an example on how to write this in C++ if it should wrap the glib-based existing C objects, but the C++ interface in itself demonstrates rather clearly the parts that are needed regardless of whether the code uses glib or not. I mean, ripping out the glib parts is the smaller problem here - getting a C++ class collection right is much more difficult. > > 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. I am not convinced templates and type traits will easily solve the question on what output strings a class such as gnc::Numeric should have. > > 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. Yes, I agree Pimpl is very good in isolating recompilation. I just think this isn't as important for an application as it is for a library project. And recompilation times for an application also don't matter as much as they used to do. Regards, Christian _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
