Modeled after a now 20-year old library (Qt), Wt has never been, nor tried to be, a poster-child of modern c++. Admittedly, when Wt was created (I know realize we are celebrating a 10th anniversary in December!) c++11 wasn’t around the corner, and we did already make some choices (STL, standard library, boost) which made Wt less of an archaism than Qt is today.
But even then we more than happy to get our inspiration from what is probably still the best and consistent desktop UI toolkit around rather than experimenting with fancy new c++ features.
Today, it seems that after c++11, and c++14, with excursions in new complex features (move semantics, decltype, etc…), there’s a new focus on how to use all of this behind the scenes to allow programmers young and old create good software (nicely illustrated in the keynote of Herb Sutter). The goal clearly is to make c++ again an enjoyable language.
One of the main changes we foresee is to align with the core guidelines with respect to the preference for smart pointers over raw pointers. We believe that the strict ownership model of Wt (and Qt) is quite intuitive, mostly transparent, and gives few problems in terms of memory leaks or dangling pointers. But it would be nice to express transfer of ownership in APIs, as well as get exceptions rather than segmentation faults if one de-references a dangling pointer. In other words, we do not want to change the ownership model, but rather make it more clear and safe.
Another change that we are looking forward to is the removal of some arcane boost libraries that we’ve been dragging along for years. One such library is Boost.Signals (or Boost.Signals2), of which we use only a tiny portion, for the use-case in Wt, resulting not only in faster compile times (experiments indicated a factor of 2 should be feasible) but also faster code (for those that worry) and simpler stack-traces. Along the same lines, another choice that we have regretted since we understood it’s a bottleneck is the use of boost::any in our public APIs.
Specific non-goals are anything that make it harder to port over existing Wt 3 code to Wt 4 (although there will be a porting effort) without adding value: e.g. we will not exchange CamelCase for snake_style.
Before you ask: there’s no time-frame yet. At the moment we are gathering ideas and looking at technical constraints (such as our internal C++ Wt to Java JWt tool-chain).