Re: [Monotone-devel] C++11
Hi Markus! Markus Wanner schrieb: Obviously, the former offers little benefit: We could possibly add minor #ifdef'd optimizations. For example using perfect forwarding and move constructors to avoid some copying if C++11 is used. The latter seems much more interesting, but is a much heftier change as well. Before I proceed with that branch, I'd like to get some feedback and opinions. Since I'm not developing with C++ anymore on a daily basis, would you mind to give guys like me some examples / judgement why monotone should switch to C++11? I could think of having less code in monotone because more is taken care of already in the stdlib, but some examples would be nice. Thanks! Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] C++11
Markus Wanner mar...@bluegap.ch writes: The most obvious drawback is higher requirements on compilers and standard libraries. However, it seems realistic to be able to support gcc-4.6 and clang-3.3 and newer. (Maybe even older clang, but I didn't try.) I have no problem moving to the current language standard, as long as we can actually compile everything we need. Is anybody opposed to raising these? Are you fine with landing these branches and start to use C++11? We need to show that all (most?) tests pass on the various supported platforms before merging to nvm. I can test on 64 bit and 32 bit msys2/ming64, 32 bit Debian stable, and 64 bit Red Hat 6. What platforms have you tested this on? -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] C++11
On Tue, May 13, 2014 at 09:08:01AM +0200, Thomas Keller wrote: Hi Markus! Markus Wanner schrieb: Obviously, the former offers little benefit: We could possibly add minor #ifdef'd optimizations. For example using perfect forwarding and move constructors to avoid some copying if C++11 is used. The latter seems much more interesting, but is a much heftier change as well. Before I proceed with that branch, I'd like to get some feedback and opinions. Since I'm not developing with C++ anymore on a daily basis, would you mind to give guys like me some examples / judgement why monotone should switch to C++11? I could think of having less code in monotone because more is taken care of already in the stdlib, but some examples would be nice. monotone should definitely be compilable on C++11. But it's going to be a while before all platforms have C++11 compiler. I'm thinking of things like long-term-support Ubuntu and Debian Squeeze, older Mac's which do not receive new OS/X's any more, Windows XP machines, and so forth. There are probably even older platforms still in active use somewhere. It's not unusual at all for servers to be running stable long-term-support versions of software and foregoing the latest and greatest for stability. I have noo idea how many of these old systems use monotone. I maintain that monotone should remain compilable on older C++ compilers. At very least, the pre-C++11 version of monotone should be its own legacy branch and should continue to receive bugfixes for a long time, and should remain net-sync-compatible with the current one. Of course, the operational questions here are *when* the transition should occur, and how long dual-operation should be supported when it does. -- hendrik ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] C++11
On 05/13/2014 03:51 PM, Stephen Leake wrote: I have no problem moving to the current language standard, as long as we can actually compile everything we need. Good to hear, thanks. We need to show that all (most?) tests pass on the various supported platforms before merging to nvm. Well, the question is: What's the set of supported platforms. And which ones are we willing to drop in favor of migrating to C++11. For somewhat decent C++11 support, I think we need to target gcc-4.6 as the minimum compiler requirement; release date of 4.6.0: March 2011. (Or alternatively, clang of around 3.1 or 3.2, but a) clang isn't that wide spread, and b) we only started to mention clang in INSTALL since release 1.1). This requirement clearly complicates matters for distributions that ship anything older than gcc-4.6. These are (according to what I could find quickly): NetBSD 5.1 shipping gcc 3.3 OpenBSD 5.5 shipping gcc 4.2 Debian squeeze (oldstable): shipping gcc 4.4 Ubuntu 10.04 LTS (lucid): shipping gcc 4.4 RHEL 6: shipping gcc 4.4 CentOS 6.5: shipping gcc 4.4 FreeBSD 9.0 shipping gcc 4.4 Fedora 14: shipping gcc 4.5 OpenSuse 11.4 shipping gcc 4.5 Slackware 13.37 shipping gcc 4.5 These (and newer) should be fine: Ubuntu LTS 12.04 (precise): shipping 4.4 - 4.8 Debian stable (wheezy): shipping 4.6 and 4.8 Fedora 15: shipping gcc 4.6 FreeBSD 9.2 shipping gcc 4.6 OpenSuse 12.1: shipping gcc 4.6 Slackware 14.0 shipping gcc 4.7 NetBSD 6.1 shipping gcc 4.8 RHEL 7 shipping gcc 4.8 (?) Out of these, RHEL 6 hurts the most, IMO. However, there's the RedHat Developer Toolset, shipping gcc 4.7. For other old distributions still in use, you're likely to find a newer gcc as well, I think. Mac OS X uses clang. Given my experiments and Thomas' feedback, it seems we need at least 10.9 (Mavericks) and Xcode 5.0, but I could try again on my Mountain Lion - its clang version (3.3) should theoretically suffice. I don't remember what went wrong. Regards Markus Wanner signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] C++11
Hey Hendrik, On 05/13/2014 05:17 PM, Hendrik Boom wrote: monotone should definitely be compilable on C++11. It is. That was one of my goals with release 1.1. However, wit that release, C++11 still isn't enabled by default (at least not by our configure script). nvm.optional-cxx11 would change that. But it's going to be a while before all platforms have C++11 compiler. Absolutely. We cannot (and haven't ever) support all platforms, though. See my list in response to Stephen. I'm thinking of things like long-term-support Ubuntu and Debian Squeeze, older Mac's which do not receive new OS/X's any more, Windows XP machines, and so forth. There are probably even older platforms still in active use somewhere. It's not unusual at all for servers to be running stable long-term-support versions of software and foregoing the latest and greatest for stability. Please keep in mind that you don't need the new compiler to *run* monotone. But yeah, I take this as a vote against adapting C++11 now. I have noo idea how many of these old systems use monotone. Sadly, not many. Just one number: Debian popcon lists around 300 installs. Overall. That's 0.13% percent of all popcon-counted systems. (And that includes my several Debian build animals ;-) ) I maintain that monotone should remain compilable on older C++ compilers. At very least, the pre-C++11 version of monotone should be its own legacy branch and should continue to receive bugfixes for a long time, and should remain net-sync-compatible with the current one. I heard you. Of course, the operational questions here are *when* the transition should occur, and how long dual-operation should be supported when it does. I think the answer to the dual-operation duration is obvious: Zero. We just don't have the man-power. What do you think would be a good time to switch to C++11? I'm a bit concerned that botan is switching to C++11. (And just notice that botan even states gcc-4.7 as the minimum requirement for 1.11 onwards.) Regards Markus Wanner signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] C++11
Thomas,
On 05/13/2014 09:08 AM, Thomas Keller wrote:
Since I'm not developing with C++ anymore on a daily basis, would you
mind to give guys like me some examples / judgement why monotone should
switch to C++11? I could think of having less code in monotone because
more is taken care of already in the stdlib, but some examples would be
nice.
In general, I think it's not a question of whether or not to adapt to
C++11, but when. Given we've just released 1.1 and most compilers (even
Microsofts) now offer decent support for a new standard that's around
three years old, I personally think now is a good time. But I'm glad to
show you some of the new C++11 features.
In the nvm.mandatory-cxx11 branch, I already replaced quite some boost
constructs, for which there now is an equivalent or better standard
C++11 counterpart. Examples: std::shared_ptr replaces
boost::shared_ptr, std::unordered_{set,map} replaces all of the former
hash_map.hh, static_assert replaces BOOST_STATIC_ASSERT, to_string
replaces lexical_caststring, etc...
So much of boost has vanished, that I started to check if it's feasible
to drop the boost requirement altogether (even if it's headers only).
After the obvious replacements in nvm.mandatory-cxx11, the following
boost usage remained:
* boost/format.hppused by: sanity.hh
* boost/dynamic_bitset.hppused by: merkle_tree.cc, ancestry.cc
* boost/concept_check.hpp used by: paths.hh
* boost/multi_index_container.hpp used by: ancestry.cc
* boost/tokenizer.hpp:used by: rcs_import.cc, selectors.cc,
migrate_schema.cc
* boost/random.hppused by: tests/xdelta.cc
* boost/lexical_cast.hpp for lexical_casts to anything but
string, mostly bool and ints.
Some of these seem easy enough to replace: With botan, we have at least
one other good PRNG (albeit a crypto PRNG might be overkill for testing
purposes), the multi_index_container can be replaced by multiple
standard containers in parallel and the tokenizers in use seem
relatively simple. For most lexical casts, there are C++11 std library
functions as well. Only lexical_castbool would need a replacement, but
that seems easy enough.
Others look harder: The formatter is not trivial to re-implement, I
guess. I'm not sure how many of its features we really use, though.
Concepts didn't make it into C++11, so the concept_check there seems
difficult to replace. Do we really need it, though? I'm not sure how
performance critical the dynamic_bitset is and how it compares to
vectorbool (which implementations are allowed (but not required) to
optimize into a bit vector).
There's another option: Including the headers (for the remaining
features) in our source tree. The boost license would allow that and
there's a precedent: src/boost/circular_buffer*.hpp (which Graydon
introduced more than 10 years ago, originates from Boost around ca.
release 1.30 and essentially remained untouched ever since). There
clearly are downsides to that approach: Distributors generally don't
like that, as it circumvents their tools for tracking build time
dependencies. And bugs fixed in boost wouldn't automatically propagate
to monotone, anymore (upon rebuild of the latter).
Regarding language features: There are lots! I don't think I can give a
comprehensive overview. Maybe not even a good one. However, my personal
favorite is the new move semantics: perfect forwarding, rvalues and move
constructors, which can often eliminate the need to copy. And sometimes
allow you to pass-by-value, rather than using const references.
Another feature comes in form of a keyword: 'auto'. It basically tells
the compiler to figure itself what type a variable needs to be. Not
losing type safety, but often making obvious things less redundant.
Consider this example patch for src/network/reator.cc (a combination of
the 'auto' keyword with the range based for loops feature):
@@ -107,10 +106,9 @@ void reactor::ready(transaction_guard
probe.clear();
lookup.clear();
setshared_ptrreactable todo = items;
- for (setshared_ptrreactable ::iterator i = todo.begin();
- i != todo.end(); ++i)
+ for (const auto i : todo)
{
- ready_for_io(*i, guard);
+ ready_for_io(i, guard);
}
}
bool reactor::do_io()
Nice and short. I'd certainly like to use that for places where the type
was obvious and repetitive to the human reader. However, I also think
explicitly specifying the type can sometimes be beneficial to the human
reader. So as many good things, this feature can be over-used, I think.
Another big thing are lambda functions, which can replace functors. I
don't think we use those a lot in monotone, though.
I already mentioned the static_assert above, with meaningful error
messages (as opposed to the boost variant). Also relevant to monotone:
long long is guaranteed to be an integer that's at least 64 bits
Re: [Monotone-devel] C++11
On 05/13/2014 07:35 PM, J Decker wrote: I didn't see an answer to 'would you mind to give guys like me some examples / judgement why monotone should switch to C++11? I could think of having less code in monotone because more is taken care of already in the stdlib, but some examples would be nice.' That answer just took a little longer to write. There are so many useful things... ;-) For some more examples, please see the diff between nvm and nvm.optional-cxx11. other than c++11 being new and shiny? I know it has builtin thread support which might removal of some ifdefs ... but I'm sure that's an insignificant change Yeah, monotone doesn't use threads, so that feature is not of use for us. Given the (lack of) manpower, I think it's actually beneficial to the project to reduce the variety of supported platforms. I'm certainly not willing to test gccs back to version 3.2. Nor boost as of 1.33, for example. (As currently stated in INSTALL.) I'd also like to drop support for botan 1.6, maybe even 1.8. Three years after release 1.0, I think it's about time to discuss the set of supported platforms. Regards Markus Wanner signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] C++11
Jack, over here at the monotone mailing list, we're discussing a move to C++11, partly inspired by botan's move. On 05/13/2014 07:29 PM, Markus Wanner wrote: I'm a bit concerned that botan is switching to C++11. (And just notice that botan even states gcc-4.7 as the minimum requirement for 1.11 onwards.) What are your plans for botan 1.10.x? Does that branch keep getting bug-fixes after the 1.12.0 release? (I guess so, but don't remember reading a policy or roadmap or the like on your website.) Regarding the new standard: What was your experience with the switch to C++11, so far? Would you recommend the monotone project to switch? Regards Markus Wanner signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] C++11
On Tue, May 13, 2014 at 08:04:01PM +0200, Markus Wanner wrote: Given the (lack of) manpower, It may take some effort to introduce all the C++11 features being discussed here. Getting rid of things that don't work in C++11, well, that's somethingg we'll have to do anyway. But factoring or refactoring in new C++11 features is probably going to cost us more time than it saves. Unless, of course, there are serious plans to introduce major new facilities into monotone where the improved clarity of the code will benefit us. I think it's actually beneficial to the project to reduce the variety of supported platforms. The way we're talking, it almost seems the C++11 is itself a new platform. -- hendrik ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] C++11
On Tue, May 13, 2014 at 07:29:08PM +0200, Markus Wanner wrote: Hey Hendrik, Of course, the operational questions here are *when* the transition should occur, and how long dual-operation should be supported when it does. I think the answer to the dual-operation duration is obvious: Zero. We just don't have the man-power. What do you think would be a good time to switch to C++11? I'm a bit concerned that botan is switching to C++11. (And just notice that botan even states gcc-4.7 as the minimum requirement for 1.11 onwards.) It's possible that botan may force our hand, whether we want to stay with the old C++ or not. -- hendrik ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] C++11
On 05/13/2014 11:56 PM, Hendrik Boom wrote: It may take some effort to introduce all the C++11 features being discussed here. Absolutely, yes. I see no pressure on that, though. (And no, I don't think we need to introduce *all* those features. I'd like to have the option to use them where applicable.) Getting rid of things that don't work in C++11, well, that's somethingg we'll have to do anyway. I'm not sure what you're talking about, here. monotone 1.1 compiles on gcc and clang with C++11 enabled. I'm not aware of anything that doesn't work. But factoring or refactoring in new C++11 features is probably going to cost us more time than it saves. Unless, of course, there are serious plans to introduce major new facilities into monotone where the improved clarity of the code will benefit us. Sure, there's a trade-off. The way you put it makes me think the bare impression of a living project is already worth the change... And yes, I have some itches with monotone that I'd like to scratch. And I'd like to scratch them the C++11 way. The way we're talking, it almost seems the C++11 is itself a new platform. It mostly is an extension of the existing standards. There are very few legal C++98 constructs that C++11 doesn't tolerate. Monotone doesn't use any of those. Regards Markus Wanner signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] C++11
On 05/14/2014 12:00 AM, Hendrik Boom wrote: It's possible that botan may force our hand, whether we want to stay with the old C++ or not. As much as I like the C++11 features: I don't think that's apt. It seems well possible to use botan 1.12 from 'ifdef HAVE_CXX11' blocks. Any platform that doesn't support C++11 is highly unlikely to ever ship botan 1.12. And for the others, we need to support multiple stable versions of botan, anyways. Regards Markus Wanner signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
