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
[0]: http://lists.inf.ed.ac.uk/pipermail/polyml/2017-December/002125.html
[1]: http://isabelle.in.tum.de/repos/isabelle/rev/88b8bc6a6e5f
_______________________________________________
polyml mailing list
polyml@inf.ed.ac.uk
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
_______________________________________________
polyml mailing list
polyml@inf.ed.ac.uk
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
