I've been thinking about this and reading the various comments. On the whole I'm not convinced that any change would actually be worthwhile at the moment. There would be a very good case for using some of these features if the code were being written from scratch but it's far from clear that there will be any gain from changing the code now.
Bitmap is used in the garbage-collector and there is one bit for each word in the heap. As I understand it, std::vector<bool> does not guarantee to use just a single bit for each bool but that is essential to keep the memory size down. The code, including the way bitmaps are allocated, has been carefully crafted to work with the garbage collector.
The situation continues to evolve and there may be good reasons to make some of these changes in the future but maybe just not now.
Thanks for your comments.
David
On 19/05/2019 04:57, Matthew Fernandez wrote:
Hello PolyMLers,
Some time ago I proposed PolyML switch to building with the C++11 standard [0]. The main blocking issue that surfaced was Isabelle supporting Ubuntu 12.04 which ships without a C++11-enlightened compiler. In January 2019, Makarius bumped the supported Linux release to Ubuntu 14.04 [1] which has a C++11 compiler. Are there any remaining issues preventing a migration to C++11? Do people feel strongly for or against this? The immediate benefits are similar to what I listed in my original posting:
- PLock, PLocker, PCondVar implementations could all be deleted and dropped with std::mutex, std::lock_guard, std::condition_variable respectively
- NORETURNFN could be replaced with [[noreturn]]
- Bitmap could be dropped and replaced with std::vector<bool>
The general motivation here is reducing the maintenance overhead and allowing performance to evolve with libstdc++/libc++. I expect we could get a lot of mileage out of code clarity wins too (e.g. range-based for loops).
I haven?t CCed isabelle-dev because I think they would have no opinion on this topic, but Makarius if you think it?s relevant please loop them into this thread as well.
Thanks, Matt
polyml mailing list polyml at inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml