Re: [Monotone-devel] C++11
On Friday 16 May 2014 13:16:11 Stephen Leake wrote: Compiling with cygwin g++ --version g++ (GCC) 4.8.2 g++ -I. -I../monotone-I/usr/include/botan-1.10 -g -O2 -Wall -Wextra -Wno-unused -Wno-unused-parameter -std=c++11 -MT src/unix/process.o -MD -MP -MF $depbase.Tpo -c -o src/unix/process.o ../monotone/src/unix/process.cc \ mv -f $depbase.Tpo $depbase.Po ../monotone/src/unix/process.cc: In function ‘pid_t process_spawn_pipe(const char* const*, FILE**, FILE**)’: ../monotone/src/unix/process.cc:264:29: error: ‘fdopen’ was not declared in this scope *in = fdopen(infds[1], w); fdopen should be in stdio.h, and '#include stdio.h is present. The error goes away if I delete '-std=c++11'. Or if I change it to gnu++11! This is expected behavior. Setting the language level to -std='c++11' enables strict ISO C++ library support. fdopen() is not part of the C11 or C++11 standards. Instead it is a POSIX function. I've found that this feature of gcc quite helpful to uncover implicit dependencies on POSIX. If POSIX features are desired, you can either use another language level for the -std option or you can enable a number of macros that glibc understand depending on the POSIX level you want. -D'_POSIX_SOURCE=1' -D'_POSIX_C_SOURCE=200809L' -D'_XOPEN_SOURCE=700' -D'_XOPEN_SOURCE_EXTENDED=1' GNU extensions can then be enabled using: -D'_GNU_SOURCE=1' -- JP ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] C++11
On 05/19/2014 12:51 AM, Stephen Leake wrote: done, tested, pushed. Thanks. I back-patched that to nvm, as I think it's useful there as well. IMO boost::shared_ptrvoid is equally bogus - even if the compiler doesn't seem to complain in that case. 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
Markus Wanner mar...@bluegap.ch writes: We can put such things in src/base.hh or add to CXXFLAGS via the configure script. I personally prefer the former, but we need to consider that it has no effect on the embedded netxx sources. netxx/* apparently doesn't include base.hh; undefining __STRICT_ANSI__ is also required in nextxx/datagram.cxx. So now Cygwin compiles nvm. Tests running ... (Actually an argument to get rid of those...) Is that what the nvm.asio branch is for? -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] C++11
On 05/18/2014 10:02 PM, Stephen Leake wrote: Markus Wanner mar...@bluegap.ch writes: We can put such things in src/base.hh or add to CXXFLAGS via the configure script. I personally prefer the former, but we need to consider that it has no effect on the embedded netxx sources. netxx/* apparently doesn't include base.hh; undefining __STRICT_ANSI__ is also required in nextxx/datagram.cxx. Happened as well: ffec710d4a1399a13c04866a42511ba79c86c665 So now Cygwin compiles nvm. Tests running ... If you invoked with 'make check', expect validate_changes_hook to fail. Running via run_func_tests works just fine. I suspect a PATH issue. 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
Markus Wanner mar...@bluegap.ch writes: Apparently 'std::shared_ptrvoid' is illegal, and that is enforced in gcc 4.9.0 Yeah, seems like a weird construct. cow_trie::_data is set by the 'walk' code above; apparently we have two node types. So to use a shared_ptr, we need a union of those types. ..or give the two a common base class? done, tested, pushed. -- -- Stephe ___ 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: On 05/16/2014 05:17 PM, Stephen Leake wrote: Markus Wanner mar...@bluegap.ch writes: Interesting, I thought I tested that. But you're right, this looks like the macro doesn't do what it's supposed to do. It itself claims: # The first argument, if specified, indicates whether you insist on an # extended mode (e.g. -std=gnu++11) or a strict conformance mode (e.g. # -std=c++11). If neither is specified, you get whatever works, with # preference for an extended mode. I left it unspecified, as I'm fine with whatever works (tm). I corrected the order of tests, now. So for gcc, it now yields the c++?? rather than gnu++?? variants. But it says with preference for an extended mode., which means it should pick gnu++ if both work. Which is what it did. Oh, right, I read that the wrong way around. Thanks for clarifying. Either way, the script now does what we want it to do. I should adjust the comment, though. If we are also supporting clang and MSVC, we need c++11, not gnu++11 (I think). Well, the intent of the script is to *test* what works and what not. (And MSVC needs an entirely different build system.) I meant we need to enforce using only standard C++ 2011 constructs, and not allow Gnu extensions, since the Gnu extensions are not likely to be supported by clang and MSVC. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] C++11
LeJacq, Jean Pierre jeanpierre.lej...@quoininc.com writes: error: ‘fdopen’ was not declared in this scope *in = fdopen(infds[1], w); Setting the language level to -std='c++11' enables strict ISO C++ library support. fdopen() is not part of the C11 or C++11 standards. Instead it is a POSIX function. Ok. -D'_POSIX_SOURCE=1' -D'_POSIX_C_SOURCE=200809L' -D'_XOPEN_SOURCE=700' -D'_XOPEN_SOURCE_EXTENDED=1' GNU extensions can then be enabled using: -D'_GNU_SOURCE=1' Is there a separate include file for posix? That would be cleaner than messing with these macros. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] C++11
On 05/17/2014 04:48 PM, Stephen Leake wrote: I meant we need to enforce using only standard C++ 2011 constructs, and not allow Gnu extensions, since the Gnu extensions are not likely to be supported by clang and MSVC. Agreed. FWIW, clang tries hard to be compatible to gcc and supports -std=gnu++11, though. 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/17/2014 05:08 PM, Stephen Leake wrote: LeJacq, Jean Pierre jeanpierre.lej...@quoininc.com writes: Setting the language level to -std='c++11' enables strict ISO C++ library support Hm.. sure? Other than Cygwin, I saw no platform failing. I think __STRICT_ANSI__ is not defined on anything but Cygwin. I don't think we ever enforced strict ansi compliance, before. So I just tried to make Cygwin consistent with the other platforms by undefining __STRICT_ANSI__. -D'_POSIX_SOURCE=1' -D'_POSIX_C_SOURCE=200809L' -D'_XOPEN_SOURCE=700' -D'_XOPEN_SOURCE_EXTENDED=1' Cygwin still didn't compile. Neither with _POSIX_C_SOURCE=200809L nor _XOPEN_SOURCE=700. But requires undefining __STRICT_ANSI__ to actually define fdopen (see its stdio.h header file). (Even though we don't pass the -ansi argument.) GNU extensions can then be enabled using: -D'_GNU_SOURCE=1' Is there a separate include file for posix? That would be cleaner than messing with these macros. We can put such things in src/base.hh or add to CXXFLAGS via the configure script. I personally prefer the former, but we need to consider that it has no effect on the embedded netxx sources. (Actually an argument to get rid 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
Markus Wanner mar...@bluegap.ch writes: On 05/15/2014 09:18 PM, Stephen Leake wrote: gcc --version gcc (GCC) 4.7.4 20131104 for GNAT Pro 7.2.1 (20140108) for GNAT Pro?!? yes; it's for my day job, we pay for AdaCore support. I'm not suggesting it as a general solution for mtn on Red Hat 6, but it works for me. In file included from ../mandatory-cxx11/src/globish.cc:14:0: ../mandatory-cxx11/src/option.hh: In member function option::option_setT option::option_setT::operator|(const option::option_setT) const': ../mandatory-cxx11/src/option.hh:332:7: error: 'set_union' is not a member of 'std' Does that g++ version compile plain nvm? That's is using the very same standard library functions from algorithm... But options.hh does not have #include algorithm . Adding that fixes the problem; mtn compiles (tests running ...). Apparently #include algorithm is implied somehow, or included in another include file, in nvm? Or it's actually a bug in older versions of the g++ std library, now fixed in 4.7.4. Also, I notice you are using -std=gnu++11; shouldn't that be -std=iso9899:2011, so we don't rely on gnu extensions? The m4 script is supposed to use -std=gnu++11 only if -std=c++11 is not supported. I haven't ever seen -std=iso9899:2011, before, but certainly prefer the shorter variant. I found it from 'g++ -v --help' Does your g++ support -std=c++11? Yes (it's in the same help listing). If so, it looks like the m4 macro is failing to do its job properly. config.log says it checks 'g++' first (default language version), then 'g++ -std=gnu++11', and that works, so it is used. So yes, this is a bug in the m4 macro. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] C++11
On 05/16/2014 12:43 PM, Stephen Leake wrote: Does that g++ version compile plain nvm? That's is using the very same standard library functions from algorithm... But options.hh does not have #include algorithm . Adding that fixes the problem; mtn compiles (tests running ...). Good, that means the compiler and standard libraries are just fine, which I'm glad. Apparently #include algorithm is implied somehow, or included in another include file, in nvm? Maybe C++11 is more restrictive on including header (or allows the library to be written so). Sounds like we want to add that include to nvm as well. If so, it looks like the m4 macro is failing to do its job properly. config.log says it checks 'g++' first (default language version), then 'g++ -std=gnu++11', and that works, so it is used. So yes, this is a bug in the m4 macro. Interesting, I thought I tested that. But you're right, this looks like the macro doesn't do what it's supposed to do. It itself claims: # The first argument, if specified, indicates whether you insist on an # extended mode (e.g. -std=gnu++11) or a strict conformance mode (e.g. # -std=c++11). If neither is specified, you get whatever works, with # preference for an extended mode. I left it unspecified, as I'm fine with whatever works (tm). I corrected the order of tests, now. So for gcc, it now yields the c++?? rather than gnu++?? variants. 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/12/2014 09:51 PM, Markus Wanner wrote: 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. Given the consensus on enabling C++11 if available, I landed that branch, yesterday. 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 07:23:07PM +0200, Markus Wanner wrote: This requirement clearly complicates matters for distributions that ship anything older than gcc-4.6. These are (according to what I could find quickly): Debian squeeze (oldstable): shipping gcc 4.4 Unfortunately, it looks like squeeze is going to be picked for long-term support. (Why, why, couldn't they haave picked wheezy for this?) -- hendrik ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] C++11
On Thu, May 15, 2014 at 06:44:42PM +0200, Markus Wanner wrote: In honor of the founder of this project: Sorry, no, the best tool would rather be rust. ;-) Causing me to look up rust on the wikipedia. Yes, it looks useful. There's one thing not clear to me from the writeup -- is it possible to have structures that are *not* pointed to? And yes, it looks like rust might be tthe right language, too. How well does it interface with C++? -- hendrik ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] C++11
Jack, On 05/14/2014 05:08 PM, Jack Lloyd wrote: 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. That's good to know. Thanks for your continued efforts in providing a decent crypto library. 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. Understood, makes sense to me, yes. 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. Thanks for that first-hand experience. Very much appreciated. I absolutely agree that rvalues and the entire concept of moving (rather than copying) is the most useful new feature. But there's a bit of a learning curve. Once you get the hang of it (and I'm not claiming I'm completely there, yet), you're starting to question how you've ever been able to write C++ without it (I certainly had that feeling, already). 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. Yeah, it's quite an improvement. In the past, there certainly were efforts to get rid of boost. I'm not sure about the exact benefits, as of now, but C++11 would certainly get us a huge step towards that goal. 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/16/2014 03:28 PM, Hendrik Boom wrote: Unfortunately, it looks like squeeze is going to be picked for long-term support. Squeeze currently ships monotone-0.48-3. I don't think this affects build requirements of future releases of monotone. I agree it's an indicator that we better remain netsync compatible back to (at least) 0.48. (Why, why, couldn't they haave picked wheezy for this?) Quoting from your link: Importantly, the success of Squeeze-LTS will be used to judge the viability of LTS support for [wheezy and [jessie]. So there's still hope. Regards Markus Wanner ___ 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: Interesting, I thought I tested that. But you're right, this looks like the macro doesn't do what it's supposed to do. It itself claims: # The first argument, if specified, indicates whether you insist on an # extended mode (e.g. -std=gnu++11) or a strict conformance mode (e.g. # -std=c++11). If neither is specified, you get whatever works, with # preference for an extended mode. I left it unspecified, as I'm fine with whatever works (tm). I corrected the order of tests, now. So for gcc, it now yields the c++?? rather than gnu++?? variants. But it says with preference for an extended mode., which means it should pick gnu++ if both work. Which is what it did. If we are also supporting clang and MSVC, we need c++11, not gnu++11 (I think). -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] C++11
On Fri, May 16, 2014 at 04:36:08PM +0200, Markus Wanner wrote: On 05/16/2014 03:28 PM, Hendrik Boom wrote: Unfortunately, it looks like squeeze is going to be picked for long-term support. Squeeze currently ships monotone-0.48-3. I don't think this affects build requirements of future releases of monotone. I agree it's an indicator that we better remain netsync compatible back to (at least) 0.48. Yes. That is indeed the most important point here. And it's probably not all that hard to do. -- hendrik ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] C++11
Hendrik Boom hend...@topoi.pooq.com writes: On Tue, May 13, 2014 at 07:23:07PM +0200, Markus Wanner wrote: This requirement clearly complicates matters for distributions that ship anything older than gcc-4.6. These are (according to what I could find quickly): Debian squeeze (oldstable): shipping gcc 4.4 Unfortunately, it looks like squeeze is going to be picked for long-term support. picked by who? The Debian project? (Why, why, couldn't they haave picked wheezy for this?) That does seem very odd. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] C++11
On Fri, May 16, 2014 at 10:19:05AM -0500, Stephen Leake wrote: Hendrik Boom hend...@topoi.pooq.com writes: Unfortunately, it looks like squeeze is going to be picked for long-term support. picked by who? The Debian project? Yes. Experimentally, to see how well it works, but yes. -- hendrik ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] C++11
On 05/16/2014 05:17 PM, Stephen Leake wrote: Markus Wanner mar...@bluegap.ch writes: Interesting, I thought I tested that. But you're right, this looks like the macro doesn't do what it's supposed to do. It itself claims: # The first argument, if specified, indicates whether you insist on an # extended mode (e.g. -std=gnu++11) or a strict conformance mode (e.g. # -std=c++11). If neither is specified, you get whatever works, with # preference for an extended mode. I left it unspecified, as I'm fine with whatever works (tm). I corrected the order of tests, now. So for gcc, it now yields the c++?? rather than gnu++?? variants. But it says with preference for an extended mode., which means it should pick gnu++ if both work. Which is what it did. Oh, right, I read that the wrong way around. Thanks for clarifying. Either way, the script now does what we want it to do. I should adjust the comment, though. If we are also supporting clang and MSVC, we need c++11, not gnu++11 (I think). Well, the intent of the script is to *test* what works and what not. (And MSVC needs an entirely different build system.) 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 msys2:
g++ --version
g++.exe (Rev2, Built by MSYS2 project) 4.9.0
g++ -I. -I../mandatory-cxx11 -I/mingw64/include
-I/mingw64/include/botan-1.10-DWIN32 -DNETXX_NO_PTON -DNETXX_NO_NTOP
-DNETXX_NO_INET6 -g -O2 -Wall -Wextra -Wno-unused -Wno-unused-parameter
-std=c++11 -MT src/roster.o -MD -MP -MF $depbase.Tpo -c -o src/roster.o
../mandatory-cxx11/src/roster.cc \
mv -f $depbase.Tpo $depbase.Po
In file included from
C:/Msys2/msys64/mingw64/include/c++/4.9.0/bits/shared_ptr.h:52:0,
from C:/Msys2/msys64/mingw64/include/c++/4.9.0/memory:82,
from ../mandatory-cxx11/src/roster.cc:14:
C:/Msys2/msys64/mingw64/include/c++/4.9.0/bits/shared_ptr_base.h: In
instantiation of 'std::__shared_ptr_Tp, _Lp::__shared_ptr(_Tp1*) [with _Tp1 =
cow_trieunsigned int, std::shared_ptrmarking, 8::middle_node_type; _Tp =
void; __gnu_cxx::_Lock_policy _Lp = (__gnu_cxx::_Lock_policy)2u]':
C:/Msys2/msys64/mingw64/include/c++/4.9.0/bits/shared_ptr_base.h:1023:4:
required from 'void std::__shared_ptr_Tp, _Lp::reset(_Tp1*) [with _Tp1 =
cow_trieunsigned int, std::shared_ptrmarking, 8::middle_node_type; _Tp =
void; __gnu_cxx::_Lock_policy _Lp = (__gnu_cxx::_Lock_policy)2u]'
../mandatory-cxx11/src/cow_trie.hh:48:4: required from 'bool cow_trie_Key,
_Value, _Bits::walk(std::shared_ptrvoid, _Key, int, _Value**) [with _Key =
unsigned int; _Value = std::shared_ptrmarking; int _Bits = 8]'
../mandatory-cxx11/src/cow_trie.hh:135:38: required from 'const _Value
cow_trie_Key, _Value, _Bits::get_unshared_if_present(_Key) [with _Key =
unsigned int; _Value = std::shared_ptrmarking; int _Bits = 8]'
../mandatory-cxx11/src/roster.cc:212:59: required from here
C:/Msys2/msys64/mingw64/include/c++/4.9.0/bits/shared_ptr_base.h:874:4: error:
static assertion failed: incomplete type
static_assert( !is_void_Tp::value, incomplete type );
I think the problem is in cow_trie.hh:
bool walk(std::shared_ptrvoid d, _Key key, int level, _Value **ret)
{
if (!d)
{
if (level 0)
d.reset(new middle_node_type());
else
d.reset(new leaf_node_type());
}
Apparently 'std::shared_ptrvoid' is illegal, and that is enforced in
gcc 4.9.0
I don't have the c++11 reference manual. I found this:
http://en.cppreference.com/w/cpp/memory/shared_ptr
std::shared_ptr may be used with an incomplete type T, but T must be
complete at the point in code where the constructor from a raw
pointer or the reset(T*) member function is called (note that
std::unique_ptr may be constructed from a raw pointer to an
incomplete type).
I assume 'void' is an incomplete type.
The parameter 'd' in 'walk' is used to pass cow_trie::_data.
cow_trie::_data is set by the 'walk' code above; apparently we have two
node types. So to use a shared_ptr, we need a union of those types.
Can we use a unique_ptr here? I don't see where _data is shared. Guess I
should just try it: no, that gives a different error:
g++ -I. -I../mandatory-cxx11 -I/mingw64/include
-I/mingw64/include/botan-1.10-DWIN32 -DNETXX_NO_PTON -DNETXX_NO_NTOP
-DNETXX_NO_INET6 -g -O2 -Wall -Wextra -Wno-unused -Wno-unused-parameter
-std=c++11 -MT src/cmd_netsync.o -MD -MP -MF $depbase.Tpo -c -o
src/cmd_netsync.o ../mandatory-cxx11/src/cmd_netsync.cc \
mv -f $depbase.Tpo $depbase.Po
In file included from C:/Msys2/msys64/mingw64/include/c++/4.9.0/memory:81:0,
from
C:/Msys2/msys64/mingw64/include/boost/container/container_fwd.hpp:36,
from
C:/Msys2/msys64/mingw64/include/boost/lexical_cast.hpp:170,
from ../mandatory-cxx11/src/lexical_cast.hh:13,
from ../mandatory-cxx11/src/option.hh:29,
from ../mandatory-cxx11/src/options.hh:26,
from ../mandatory-cxx11/src/commands.hh:14,
from ../mandatory-cxx11/src/cmd.hh:17,
from ../mandatory-cxx11/src/cmd_netsync.cc:13:
C:/Msys2/msys64/mingw64/include/c++/4.9.0/bits/unique_ptr.h: In instantiation
of 'void std::default_delete_Tp::operator()(_Tp*) const [with _Tp = void]':
C:/Msys2/msys64/mingw64/include/c++/4.9.0/bits/unique_ptr.h:236:16: required
from 'std::unique_ptr_Tp, _Dp::~unique_ptr() [with _Tp = void; _Dp =
std::default_deletevoid]'
../mandatory-cxx11/src/cow_trie.hh:20:7: required from here
C:/Msys2/msys64/mingw64/include/c++/4.9.0/bits/unique_ptr.h:72:2: error: static
assertion failed: can't delete pointer to incomplete type
static_assert(!is_void_Tp::value,
So we need a union type.
--
-- Stephe
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] C++11
Stephen, thanks for trying. On 05/16/2014 07:47 PM, Stephen Leake wrote: On msys2: g++ --version g++.exe (Rev2, Built by MSYS2 project) 4.9.0 gcc 4.9.0 is pretty new. I just recently got that via Debian testing and haven't used it much, yet. Apparently 'std::shared_ptrvoid' is illegal, and that is enforced in gcc 4.9.0 Yeah, seems like a weird construct. cow_trie::_data is set by the 'walk' code above; apparently we have two node types. So to use a shared_ptr, we need a union of those types. ..or give the two a common base class? Can we use a unique_ptr here? That doesn't make the void pointer any more type safe. We should get rid of void*, that's supposed to be C++, after all. 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/16/2014 01:54 PM, Markus Wanner wrote: Given the consensus on enabling C++11 if available, I landed that branch, yesterday. Looks like that upset some build animals. Interestingly, Debian/sid runs into some boost issue, when C++11 is enabled. I don't see that issue on Debian/testing, so I'm not sure if it's really monotone's fault or due to some sid update. 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/16/2014 08:16 PM, Stephen Leake wrote: The error goes away if I delete '-std=c++11'. Or if I change it to gnu++11! It also vanishes if we undefine __STRICT_ANSI__, as I did in my recent commits. I'm not quite sure if that's the best way, though. Maybe we're better off using gnu++11. Build animal wallaby (using bleeding edge clang) isn't quite happy, either. 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
Markus Wanner mar...@bluegap.ch 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 Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] C++11
Markus Wanner mar...@bluegap.ch 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 Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] C++11
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 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
Stephen Leake stephen_le...@stephe-leake.org writes: Markus Wanner mar...@bluegap.ch 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_setT option::option_setT::operator|(const option::option_setT) 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_setT option::option_setT::operator-(const option::option_setT) 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_stringchar::const_iterator compile_charclass(const string, std::basic_stringchar::const_iterator, std::back_insert_iteratorstd::basic_stringchar , 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 Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] C++11
On 05/15/2014 09:18 PM, Stephen Leake wrote: gcc --version gcc (GCC) 4.7.4 20131104 for GNAT Pro 7.2.1 (20140108) for GNAT Pro?!? In file included from ../mandatory-cxx11/src/globish.cc:14:0: ../mandatory-cxx11/src/option.hh: In member function option::option_setT option::option_setT::operator|(const option::option_setT) 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_setT option::option_setT::operator-(const option::option_setT) 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_stringchar::const_iterator compile_charclass(const string, std::basic_stringchar::const_iterator, std::back_insert_iteratorstd::basic_stringchar , origin::type)': ../mandatory-cxx11/src/globish.cc:141:7: error: 'sort' is not a member of 'std' Hm.. there's nothing new about std::sort. Nor set_union or set_difference. This looks more like you're using some weird standard library. Does that g++ version compile plain nvm? That's is using the very same standard library functions from algorithm... Also, I notice you are using -std=gnu++11; shouldn't that be -std=iso9899:2011, so we don't rely on gnu extensions? The m4 script is supposed to use -std=gnu++11 only if -std=c++11 is not supported. I haven't ever seen -std=iso9899:2011, before, but certainly prefer the shorter variant. Does your g++ support -std=c++11? If so, it looks like the m4 macro is failing to do its job properly. 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
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
[Monotone-devel] C++11
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 signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
