C++11

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
51 messages Options
123
Reply | Threaded
Open this post in threaded view
|

C++11

Markus Wanner-2
Hi,

as you may have realized, I'm considering using C++11 for monotone. A
relevant forerunner for that is botan, which already switched to C++11
in its 1.11 development branch. For monotone, there are two branches I'm
played with:

  net.venge.monotone.optional-cxx11: enables C++11 features on
      compilers supporting it. Doesn't change anything for
      compilers that do not provide C++11.

  net.venge.monotone.mandatory-cxx11: mandates C++11 and won't
      compile anymore on compilers that don't provide C++11.


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.

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.)

Is anybody opposed to raising these? Are you fine with landing these
branches and start to use C++11?

Regards

Markus Wanner


_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel

signature.asc (250 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: C++11

Thomas Keller

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 | [hidden email] | 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


_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel

signature.asc (267 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: C++11

Stephen Leake-3
In reply to this post by Markus Wanner-2
Markus Wanner <[hidden email]> 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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel
Reply | Threaded
Open this post in threaded view
|

Re: C++11

Hendrik Boom-2
In reply to this post by Thomas Keller
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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel
Reply | Threaded
Open this post in threaded view
|

Re: C++11

Markus Wanner-2
In reply to this post by Stephen Leake-3
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



_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel

signature.asc (250 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: C++11

Markus Wanner-2
In reply to this post by Hendrik Boom-2
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



_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel

signature.asc (250 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: C++11

J Decker
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.'

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


_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel
Reply | Threaded
Open this post in threaded view
|

Re: C++11

Markus Wanner-2
In reply to this post by Thomas Keller
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_cast<string>, 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.hpp                used by: sanity.hh
 * boost/dynamic_bitset.hpp        used 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.hpp                used 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_cast<bool> 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
vector<bool> (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();
>    set<shared_ptr<reactable> > todo = items;
> -  for (set<shared_ptr<reactable> >::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 long,
now (including constants).

Then there's better control of default constructors. You can explicitly
delete one or explicitly use the default one. Or delegate to another
constructor. Or inherit a base class' constructor.

And lots lots more: Initializer lists: list<pair<string, int>> = {{"A",
1}, {"B", 2}} and in-class member initializers now both work. Variadic
templates, raw string and user-defined literals, attributes, an override
keyword, etc, etc...


Bjarne Stroustrup states that C++11 feels like a new language [0]. I
personally don't think of it as new, but to me C++11 feels more like
what I always wanted C++ to feel like. I absolutely agree with his
follow-up statement: "The pieces just fit together better".

Regards

Markus Wanner


[0]: Bjarne Stroustrup's C++11 FAQ:
http://www.stroustrup.com/C++11FAQ.html#think



_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel

signature.asc (250 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: C++11

Markus Wanner-2
In reply to this post by J Decker
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



_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel

signature.asc (250 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: C++11

Markus Wanner-2
In reply to this post by Markus Wanner-2
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



_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel

signature.asc (250 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: C++11

Hendrik Boom-2
In reply to this post by Markus Wanner-2
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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel
Reply | Threaded
Open this post in threaded view
|

Re: C++11

Hendrik Boom-2
In reply to this post by Markus Wanner-2
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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel
Reply | Threaded
Open this post in threaded view
|

Re: C++11

Markus Wanner-2
In reply to this post by Hendrik Boom-2
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



_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel

signature.asc (250 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: C++11

Markus Wanner-2
In reply to this post by Hendrik Boom-2
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



_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel

signature.asc (250 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: C++11

Jack Lloyd
In reply to this post by Markus Wanner-2
On Tue, May 13, 2014 at 08:09:47PM +0200, Markus Wanner wrote:

Hi Markus,

> 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.)

I plan to maintain 1.10 at more or less the current level of support
(which is essentially: fixing bugs as they are reported but with
little to no new development work) for an extended period with 2.0
being a parallel stable track, until at least a majority of distros
have switched.

It's worth keeping in mind it may well be another year or more before
a new stable tree even happens, there are a lot of open projects I'd
like to work on before committing to supporting things for the long
haul.

> Regarding the new standard: What was your experience with the switch to
> C++11, so far? Would you recommend the monotone project to switch?

I think C++11 is somewhat deceptive in that many of the changes seem
trivial and 'just' save you some extra typing (auto, range-for,
lambdas, and non-static member initializers in particular come to mind
in this class) but I've found they can offer a huge advantage in
productivity vs C++98. Writing C++11 can often feel more like writing
Python or ML than C++98. As a basically solo developer with only
intermittent time for side projects anything that enhances my ability
to get something done is welcome - I expect monotone is in a somewhat
similar situation in that sense.

IMO the most generally useful addition to the language is rvalue
references; even applications which don't use them directly benefit
from its use in the standard library, and where applicable they can
definitely help performance. As Monotone spends a good bit of time
moving around memory blos I expect you could see some great wins
here.

The reduced set of compilers that support C++11 is a mixed bag. It is
unfortunate, in terms of reducing portability, but wonderful for
setting a much higher bar for compiler quality. Not having to worry
about weird bugs in GCC 3.4 or Visual C++ 2008 anymore is nice. One
other problem is the tool ecosystem (ffi generators, static analyzers,
and so on) has not yet caught up to support C++11, though that's
started to get better in the last year or so.

The library additions are nice but are probably less essential if you
already are relying on boost. As previously botan did not use boost,
getting the sudden addition of std::function, a portable threading
library, regexes, shared_ptr, and so on was a huge help.

Cheers,
  Jack

_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel
Reply | Threaded
Open this post in threaded view
|

Re: C++11

Stephen Leake-3
In reply to this post by Markus Wanner-2
Markus Wanner <[hidden email]> writes:

>   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 (?)

Thanks for the list.

You left out Windows:

msys2 mingw64           4.9
cygwin 64 bit           4.8

> Out of these, RHEL 6 hurts the most, IMO.

Yes. That's the required OS for my day job, which is where I use mtn the
most. And I want to stay with mtn head, so I can add new conflict
resolutions etc :).

We also have to run RHEL 5 for a couple of version-frozen projects. But
those don't need the latest monotone, just netsync compatibility.

> However, there's the RedHat Developer Toolset, shipping gcc 4.7.

I was not aware of that, nor of RHEL 7.

In addition, we use AdaCore tools, which provide gcc 4.7. I'll
try testing with that.

> For other old distributions still in use, you're likely to find a
> newer gcc as well, I think.

Right. Or just use an older monotone; as long as we preserve netsync
compatibility, using an older monotone is not a serious problem. People
using old systems have to accept old tools.

We could provide 1.1 source tarball on our website for a while, to allow
compiling on non-C++-11 systems.

We don't have the manpower to maintain two distributions.

We don't want to discourage interested contributors by saying "you can't
use the best tool for the job" (which would actually be Ada 2012, not
C++ 11, but let's not go there :).

--
-- Stephe

_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel
Reply | Threaded
Open this post in threaded view
|

Re: C++11

Stephen Leake-3
In reply to this post by Markus Wanner-2
Markus Wanner <[hidden email]> writes:

>   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 (?)

Thanks for the list.

You left out Windows:

msys2 mingw64           4.9
cygwin 64 bit           4.8

> Out of these, RHEL 6 hurts the most, IMO.

Yes. That's the required OS for my day job, which is where I use mtn the
most. And I want to stay with mtn head, so I can add new conflict
resolutions etc :).

We also have to run RHEL 5 for a couple of version-frozen projects. But
those don't need the latest monotone, just netsync compatibility.

> However, there's the RedHat Developer Toolset, shipping gcc 4.7.

I was not aware of that, nor of RHEL 7.

In addition, we use AdaCore tools, which provide gcc 4.7. I'll
try testing with that.

> For other old distributions still in use, you're likely to find a
> newer gcc as well, I think.

Right. Or just use an older monotone; as long as we preserve netsync
compatibility, using an older monotone is not a serious problem. People
using old systems have to accept old tools.

We could provide 1.1 source tarball on our website for a while, to allow
compiling on non-C++-11 systems.

We don't have the manpower to maintain two distributions.

We don't want to discourage interested contributors by saying "you can't
use the best tool for the job" (which would actually be Ada 2012, not
C++ 11, but let's not go there :).

--
-- Stephe

_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel
Reply | Threaded
Open this post in threaded view
|

Re: C++11

Stephen Leake-3
In reply to this post by Markus Wanner-2
Markus Wanner <[hidden email]> writes:

> Given the (lack of) manpower, I think it's actually beneficial to the
> project to reduce the variety of supported platforms.

Yes.

> 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.

Once we settle on the required OS mininum versions, we should declare
the dependent package versions they ship as the minimums.

> Three years after release 1.0, I think it's about time to discuss the
> set of supported platforms.

Yes.

--
-- Stephe

_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel
Reply | Threaded
Open this post in threaded view
|

Re: C++11

Markus Wanner-2
In reply to this post by Stephen Leake-3
On 05/15/2014 03:30 PM, Stephen Leake wrote:
> You left out Windows:

Yes, sorry, that's not due to my aversion against that OS, but because I
assumed those to be more of a "rolling release" style, where you usually
have a pretty recent gcc.

For the very same reason, I left out Gentoo and Arch Linux.

> We also have to run RHEL 5 for a couple of version-frozen projects. But
> those don't need the latest monotone, just netsync compatibility.

netsync compat is an entirely unrelated issue.

>> However, there's the RedHat Developer Toolset, shipping gcc 4.7.
>
> I was not aware of that, nor of RHEL 7.

There's a first release candidate for RHEL 7, AFAIUI. Not that I had
ever used that or the Developer Toolset.

> In addition, we use AdaCore tools, which provide gcc 4.7. I'll
> try testing with that.

Thanks, I'd appreciate that.

> Right. Or just use an older monotone; as long as we preserve netsync
> compatibility, using an older monotone is not a serious problem. People
> using old systems have to accept old tools.

Agreed.

> We could provide 1.1 source tarball on our website for a while, to allow
> compiling on non-C++-11 systems.

Sure.

> We don't want to discourage interested contributors by saying "you can't
> use the best tool for the job" (which would actually be Ada 2012, not
> C++ 11, but let's not go there :).

In honor of the founder of this project: Sorry, no, the best tool would
rather be rust.  ;-)

Regards

Markus



_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel

signature.asc (250 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: C++11

Stephen Leake-3
In reply to this post by Stephen Leake-3
Stephen Leake <[hidden email]> writes:

> Markus Wanner <[hidden email]> writes:
>
>>   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 (?)
>
> Thanks for the list.
>
> You left out Windows:
>
> msys2 mingw64           4.9
> cygwin 64 bit           4.8
>
>> Out of these, RHEL 6 hurts the most, IMO.
>
> Yes. That's the required OS for my day job, which is where I use mtn the
> most. And I want to stay with mtn head, so I can add new conflict
> resolutions etc :).
>
> We also have to run RHEL 5 for a couple of version-frozen projects. But
> those don't need the latest monotone, just netsync compatibility.
>
>> However, there's the RedHat Developer Toolset, shipping gcc 4.7.
>
> I was not aware of that, nor of RHEL 7.
>
> In addition, we use AdaCore tools, which provide gcc 4.7. I'll
> try testing with that.

Not good:

gcc --version
gcc (GCC) 4.7.4 20131104 for GNAT Pro 7.2.1 (20140108)

In file included from ../mandatory-cxx11/src/globish.cc:14:0:
../mandatory-cxx11/src/option.hh: In member function
option::option_set<T> option::option_set<T>::operator|(const
option::option_set<T>&) const':
../mandatory-cxx11/src/option.hh:332:7: error: 'set_union' is not a member of 'std'
../mandatory-cxx11/src/option.hh: In member function
option::option_set<T> option::option_set<T>::operator-(const
option::option_set<T>&) const':
../mandatory-cxx11/src/option.hh:340:7: error: 'set_difference' is not a member of 'std'
../mandatory-cxx11/src/globish.cc: In function
std::basic_string<char>::const_iterator compile_charclass(const
string&, std::basic_string<char>::const_iterator,
std::back_insert_iterator<std::basic_string<char> >&, origin::type)':
../mandatory-cxx11/src/globish.cc:141:7: error: 'sort' is not a member of 'std'


Also, I notice you are using -std=gnu++11; shouldn't that be
-std=iso9899:2011, so we don't rely on gnu extensions?

--
-- Stephe

_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel
123