Re: [LyX/master] MathAtom is a unique_ptr

Le 12/04/2017 à 22:06, Guillaume MM a écrit : Thanks for doing that. A question, though: do you advise to always add the explicit default entries, even when we believe that the compiler will do it by itself? I would advise to declare all four (both copy operators and both move operators,

Re: [LyX/master] MathAtom is a unique_ptr

Le 08/04/2017 à 15:10, Jean-Marc Lasgouttes a écrit : Le 07/04/2017 à 23:55, Guillaume MM a écrit : commit b382b246b62b66100733449b2bf75a01fd1d263f Author: Guillaume MM <g...@lyx.org> Date: Sun Apr 2 21:04:06 2017 +0200 MathAtom is a unique_ptr Fix coverity suggestion of de

Re: [LyX/master] MathAtom is a unique_ptr

Le 07/04/2017 à 23:55, Guillaume MM a écrit : commit b382b246b62b66100733449b2bf75a01fd1d263f Author: Guillaume MM <g...@lyx.org> Date: Sun Apr 2 21:04:06 2017 +0200 MathAtom is a unique_ptr Fix coverity suggestion of defining a move constructor - /// default const

Re: [PATCH] unique_ptr and some clean-up

Guillaume Munch wrote: > Le 14/06/2016 21:49, Georg Baum a écrit : >> Guillaume Munch wrote: >> >>> What error is it? >> >> ../../src/MetricsInfo.cpp:61:4: error: type ???lyx::MetricsBase??? is not >> a direct base of ???lyx::MetricsBase??? > > Thanks for the clues. I was not even aware that

Re: [PATCH] unique_ptr and some clean-up

Le 14/06/2016 21:49, Georg Baum a écrit : Guillaume Munch wrote: What error is it? ../../src/MetricsInfo.cpp:61:4: error: type ‘lyx::MetricsBase’ is not a direct base of ‘lyx::MetricsBase’ Thanks for the clues. I was not even aware that delegate constructors was a C++11 feature. Master

Re: [PATCH] unique_ptr and some clean-up

Full day of teaching in Rouen. But yes, RER is on strike :) JMarc Le 14 juin 2016 21:41:12 GMT+02:00, Guillaume Munch a écrit : >Le 14/06/2016 20:16, Jean-Marc Lasgouttes a écrit : >> I will not be able to test until Thursday afternoon. >> > >RER is on strike ? ;)

Re: [PATCH] unique_ptr and some clean-up

Guillaume Munch wrote: > What error is it? ../../src/MetricsInfo.cpp:61:4: error: type ‘lyx::MetricsBase’ is not a direct base of ‘lyx::MetricsBase’ BTW, if it is possible to keep gcc 4.6 supported for a while with little effort I am in favour of this as well, and I can do also some testing

Re: [PATCH] unique_ptr and some clean-up

Le 14/06/2016 20:55, Georg Baum a écrit : Guillaume Munch wrote: Le 14/06/2016 16:38, Jean-Marc Lasgouttes a écrit : but of course RefChange proved more difficult. I tried to define it as a subclass of unique_ptr<RevertibleRef>, but then my C++11 default skills showed their weakness.

Re: [PATCH] unique_ptr and some clean-up

Guillaume Munch wrote: > Le 14/06/2016 16:38, Jean-Marc Lasgouttes a écrit : > >> but of course RefChange >> proved more difficult. I tried to define it as a subclass of >> unique_ptr<RevertibleRef>, but then my C++11 default skills showed >> their wea

Re: [PATCH] unique_ptr and some clean-up

Le 14/06/2016 20:16, Jean-Marc Lasgouttes a écrit : Le 14/06/16 à 18:41, Guillaume Munch a écrit : but of course RefChange proved more difficult. I tried to define it as a subclass of unique_ptr<RevertibleRef>, but then my C++11 default skills showed their weakness. What errors does i

Re: [PATCH] unique_ptr and some clean-up

Le 14/06/16 à 18:41, Guillaume Munch a écrit : but of course RefChange proved more difficult. I tried to define it as a subclass of unique_ptr<RevertibleRef>, but then my C++11 default skills showed their weakness. What errors does it give with the attached? I will not be able to test

Re: [PATCH] unique_ptr and some clean-up

the new aliasing thing in Changer.h using a plain old typedef, Yes, this should be synonymous. but of course RefChange proved more difficult. I tried to define it as a subclass of unique_ptr<RevertibleRef>, but then my C++11 default skills showed their weakness. What errors does i

Re: [PATCH] unique_ptr and some clean-up

typedef, but of course RefChange proved more difficult. I tried to define it as a subclass of unique_ptr<RevertibleRef>, but then my C++11 default skills showed their weakness. Here is what I have right now. If we manage to get somewhere we should keep both the new shiny constructs and t

Re: [PATCH] unique_ptr and some clean-up

Le 14/06/2016 10:38, Jean-Marc Lasgouttes a écrit : Le 13/06/2016 à 23:15, Guillaume Munch a écrit : I am not in charge for the machines around me and given 12.04 LTS ends up 2017-04 I don't expect any migration happening soon :) I am in a similar situation (although as I said, clang works).

Re: [PATCH] unique_ptr and some clean-up

Le 13/06/2016 à 23:15, Guillaume Munch a écrit : I am not in charge for the machines around me and given 12.04 LTS ends up 2017-04 I don't expect any migration happening soon :) I am in a similar situation (although as I said, clang works). My fatest machine runs 12.04, only updated in terms

Re: [PATCH] unique_ptr and some clean-up

Am Montag, 13. Juni 2016 um 22:15:02, schrieb Guillaume Munch > Le 13/06/2016 21:54, Pavel Sanda a écrit : > > Guillaume Munch wrote: > >> Starting from 2.3, LyX will require a C++11 compiler, and g++ 4.6 fails > >> (it seems) at a feature as elementary as generating a default move

Re: [PATCH] unique_ptr and some clean-up

Le 13/06/2016 21:54, Pavel Sanda a écrit : Guillaume Munch wrote: Starting from 2.3, LyX will require a C++11 compiler, and g++ 4.6 fails (it seems) at a feature as elementary as generating a default move constructor, even when told so explicitly (which we cannot really blame it for, given that

Re: [PATCH] unique_ptr and some clean-up

Le 13/06/2016 21:40, Stephan Witt a écrit : gcc-Version 4.4.7 20120313 (Red Hat 4.4.7-17) (GCC) IMO it’s not dead and end of life is 2020-11-30 I do not know what can be done at the LyX level for CentOS 6. It seems that it is very easy to obtain gcc 4.8 on CentOS 6 provided one has access to

Re: [PATCH] unique_ptr and some clean-up

Stephan Witt wrote: > IMO it?s not dead and end of life is 2020-11-30 CentOs/Redhat has extremely long LTS (e.g. clusters around here still have gcc 4.4). On the other hand no one sane would use it for GUI development, it's more for server/clusters deployment. So we shouldn't really strive to

Re: [PATCH] unique_ptr and some clean-up

Guillaume Munch wrote: > Starting from 2.3, LyX will require a C++11 compiler, and g++ 4.6 fails > (it seems) at a feature as elementary as generating a default move > constructor, even when told so explicitly (which we cannot really blame > it for, given that it does not claim C++11 compliance in

Re: [PATCH] unique_ptr and some clean-up

Am 13.06.2016 um 22:26 schrieb Guillaume Munch : > > Le 13/06/2016 20:50, Pavel Sanda a écrit : >> Guillaume Munch wrote: >>> Then if we are dropping g++ 4.6, does anyone know whether it makes >>> sense >> >> Sorry I might got lost somewhere in the threads around. What reasons >>

Re: [PATCH] unique_ptr and some clean-up

Le 13/06/2016 20:50, Pavel Sanda a écrit : Guillaume Munch wrote: Then if we are dropping g++ 4.6, does anyone know whether it makes sense Sorry I might got lost somewhere in the threads around. What reasons do we have for dropping gcc 4.6? Starting from 2.3, LyX will require a C++11

Re: [PATCH] unique_ptr and some clean-up

Guillaume Munch wrote: > Then if we are dropping g++ 4.6, does anyone know whether it makes sense Sorry I might got lost somewhere in the threads around. What reasons do we have for dropping gcc 4.6? Pavel

Re: [PATCH] unique_ptr and some clean-up

Le 13/06/2016 12:53, Jean-Marc Lasgouttes a écrit : Le 13/06/2016 à 10:14, Guillaume Munch a écrit : Le 12/06/2016 09:29, Pavel Sanda a écrit : Guillaume Munch wrote: I do not clearly see the situation wrt gcc 4.6. Which are the distributions that currently lack gcc > 4.6 ? this is ubuntu

Re: [PATCH] unique_ptr and some clean-up

Le 13/06/2016 à 18:01, Kornel Benko a écrit : I don't understand, why _my_ clang 3.6 accepts parameter '-std=c++14'. I am not sure that I understand your question. Here example (without source file) gcc4.8 # g++ -std=c++14 g++: error: unrecognized command line option

Re: [PATCH] unique_ptr and some clean-up

Am Montag, 13. Juni 2016 um 17:49:07, schrieb Jean-Marc Lasgouttes > Le 13/06/2016 à 17:34, Kornel Benko a écrit : > >> The posting you refer to seems to imply that it is a C++14 problem. What > >> about enforcing C++11 mode instead? > > > > Hm, yes. But if we want to support

Re: [PATCH] unique_ptr and some clean-up

Le 13/06/2016 à 17:34, Kornel Benko a écrit : The posting you refer to seems to imply that it is a C++14 problem. What about enforcing C++11 mode instead? Hm, yes. But if we want to support 'std::make_unique' we need C++14 test. At least, that was my impression while working with 4.8 and 5.3.1

Re: [PATCH] unique_ptr and some clean-up

Am Montag, 13. Juni 2016 um 16:22:56, schrieb Jean-Marc Lasgouttes > Le 13/06/2016 à 14:11, Kornel Benko a écrit : > > I had no problems with clang 3.3. But using clang 3.6 with installed libs > > from gcc4.8 > > has problems while compiling cstdio. > > According to page >

Re: [PATCH] unique_ptr and some clean-up

Le 13/06/2016 à 16:50, Stephan Witt a écrit : Am 13.06.2016 um 16:25 schrieb Jean-Marc Lasgouttes : Le 13/06/2016 à 14:27, Stephan Witt a écrit : Stephan, I'd be interested to know what clang version is returned by the Apple version. I hope it does not return the XCode

Re: [PATCH] unique_ptr and some clean-up

Am 13.06.2016 um 16:25 schrieb Jean-Marc Lasgouttes : > > Le 13/06/2016 à 14:27, Stephan Witt a écrit : >>> Stephan, I'd be interested to know what clang version is returned by the >>> Apple version. I hope it does not return the XCode version. >> >> Why not? >> >> checking

Re: [PATCH] unique_ptr and some clean-up

Le 13/06/2016 à 14:27, Stephan Witt a écrit : Stephan, I'd be interested to know what clang version is returned by the Apple version. I hope it does not return the XCode version. Why not? checking whether the compiler is clang... yes checking for clang version... 7.3.0 Because I'd like to

Re: [PATCH] unique_ptr and some clean-up

Le 13/06/2016 à 14:11, Kornel Benko a écrit : I had no problems with clang 3.3. But using clang 3.6 with installed libs from gcc4.8 has problems while compiling cstdio. According to page http://stackoverflow.com/questions/17775390/clang-3-3-in-c1y-mode-cannot-parse-cstdio-header this snipped

Re: [PATCH] unique_ptr and some clean-up

Am 13.06.2016 um 13:53 schrieb Jean-Marc Lasgouttes : > > Le 13/06/2016 à 10:14, Guillaume Munch a écrit : >> Le 12/06/2016 09:29, Pavel Sanda a écrit : >>> Guillaume Munch wrote: >> I do not clearly see the situation wrt gcc 4.6. Which are the >> distributions that

Re: [PATCH] unique_ptr and some clean-up

Am Montag, 13. Juni 2016 um 13:53:43, schrieb Jean-Marc Lasgouttes > Le 13/06/2016 à 10:14, Guillaume Munch a écrit : > > Le 12/06/2016 09:29, Pavel Sanda a écrit : > >> Guillaume Munch wrote: > > I do not clearly see the situation wrt gcc 4.6. Which are the > >

Re: [PATCH] unique_ptr and some clean-up

Le 13/06/2016 à 10:14, Guillaume Munch a écrit : Le 12/06/2016 09:29, Pavel Sanda a écrit : Guillaume Munch wrote: I do not clearly see the situation wrt gcc 4.6. Which are the distributions that currently lack gcc > 4.6 ? this is ubuntu 12.04.p I see. I has assumed g++-4.7 was there

Re: [PATCH] unique_ptr and some clean-up

Le 12/06/2016 09:29, Pavel Sanda a écrit : Guillaume Munch wrote: I do not clearly see the situation wrt gcc 4.6. Which are the distributions that currently lack gcc > 4.6 ? this is ubuntu 12.04.p I see. I has assumed g++-4.7 was there since there is gcc-4.7. How does clang fare? it has

Re: [LyX/master] unique_ptr and make_unique

Am Sonntag, 12. Juni 2016 um 18:35:56, schrieb Guillaume Munch > Le 12/06/2016 10:23, Kornel Benko a écrit : > > Am Sonntag, 12. Juni 2016 um 10:25:30, schrieb Kornel Benko > >> Am Sonntag, 12. Juni 2016 um 03:25:38, schrieb Guillaume Munch > >> >

Re: [LyX/master] unique_ptr and make_unique

Le 12/06/2016 10:23, Kornel Benko a écrit : Am Sonntag, 12. Juni 2016 um 10:25:30, schrieb Kornel Benko Am Sonntag, 12. Juni 2016 um 03:25:38, schrieb Guillaume Munch Le 09/06/2016 15:23, Guillaume Munch a écrit : diff --git a/configure.ac b/configure.ac index

Re: [LyX/master] unique_ptr and make_unique

Am Sonntag, 12. Juni 2016 um 10:25:30, schrieb Kornel Benko > Am Sonntag, 12. Juni 2016 um 03:25:38, schrieb Guillaume Munch > > Le 09/06/2016 15:23, Guillaume Munch a écrit : > > > diff --git a/configure.ac b/configure.ac > > > index 3353df4..52da6ce 100644 > > >

Re: [PATCH] unique_ptr and some clean-up

Guillaume Munch wrote: >>> I do not clearly see the situation wrt gcc 4.6. Which are the >>> distributions that currently lack gcc > 4.6 ? >> >> this is ubuntu 12.04.p >> > > I see. I has assumed g++-4.7 was there since there is gcc-4.7. How does > clang fare? it has gcc 4.6.3. clang is not and

Re: [LyX/master] unique_ptr and make_unique

Am Sonntag, 12. Juni 2016 um 03:25:38, schrieb Guillaume Munch > Le 09/06/2016 15:23, Guillaume Munch a écrit : > > diff --git a/configure.ac b/configure.ac > > index 3353df4..52da6ce 100644 > > --- a/configure.ac > > +++ b/configure.ac > > @@ -130,6 +130,9 @@ AC_C_BIGENDIAN > > #

Re: [LyX/master] unique_ptr and make_unique

Le 09/06/2016 15:23, Guillaume Munch a écrit : diff --git a/configure.ac b/configure.ac index 3353df4..52da6ce 100644 --- a/configure.ac +++ b/configure.ac @@ -130,6 +130,9 @@ AC_C_BIGENDIAN # Nice to have when an assertion triggers LYX_CHECK_CALLSTACK_PRINTING +# C++14 only

Re: [PATCH] unique_ptr and some clean-up

Le 12/06/2016 00:58, Pavel Sanda a écrit : Guillaume Munch wrote: I do not clearly see the situation wrt gcc 4.6. Which are the distributions that currently lack gcc > 4.6 ? this is ubuntu 12.04.p I see. I has assumed g++-4.7 was there since there is gcc-4.7. How does clang fare?

Re: [PATCH] unique_ptr and some clean-up

Guillaume Munch wrote: > I do not clearly see the situation wrt gcc 4.6. Which are the > distributions that currently lack gcc > 4.6 ? this is ubuntu 12.04.p

Re: [PATCH] unique_ptr and some clean-up

problem of this particular patch, which would be easy to revert, but the fact that this arose from a very simple and common idiom (p.impl. or handler with unique_ptr) and that really nothing fancy is done in this patch. That's why I suspect that such problems will arise again with gcc 4.6. (Or if somebody could

Re: [PATCH] unique_ptr and some clean-up

Jean-Marc Lasgouttes wrote: > Le 07/06/2016 ?? 19:05, Guillaume Munch a écrit : > >> It says that it picked the wrong constructor for the pair, that requires >> a copyable object. Which precise version of g++ 4.6 do you have? In >> 4.6.3 pairs accept movable objects. Maybe it fails to generate the

Re: [PATCH] unique_ptr and some clean-up

Le 10/06/2016 11:19, Jean-Marc Lasgouttes a écrit : Le 07/06/2016 à 19:05, Guillaume Munch a écrit : It says that it picked the wrong constructor for the pair, that requires a copyable object. Which precise version of g++ 4.6 do you have? In 4.6.3 pairs accept movable objects. Maybe it fails

Re: [PATCH] unique_ptr and some clean-up

Le 07/06/2016 à 19:05, Guillaume Munch a écrit : It says that it picked the wrong constructor for the pair, that requires a copyable object. Which precise version of g++ 4.6 do you have? In 4.6.3 pairs accept movable objects. Maybe it fails to generate the default move constructor. Can you try

Re: [PATCH] unique_ptr and some clean-up

Le 09/06/2016 à 16:49, Guillaume Munch a écrit : Where does this problem comes from? My patches are not touching these files. I suspect that other headers used to include these (needed for std::count and std::sort), but they don't anymore. JMarc

Re: [PATCH] unique_ptr and some clean-up

Le 07/06/2016 15:23, Jean-Marc Lasgouttes a écrit : diff --git a/src/frontends/qt4/GuiPainter.cpp b/src/frontends/qt4/GuiPainter.cpp index 725320b..2fd2a20 100644 --- a/src/frontends/qt4/GuiPainter.cpp +++ b/src/frontends/qt4/GuiPainter.cpp @@ -29,6 +29,8 @@ #include "support/lassert.h"

Re: unique_ptr

Le 08/06/2016 21:58, Jean-Marc Lasgouttes a écrit : Le 08/06/16 à 20:21, Guillaume Munch a écrit : I'd rather include only the standard headers to obtain unique_ptr, and then include support/make_unique.h when we explicitly need it. When you have unique_ptr, you also want to have make_unique

Re: unique_ptr

Le 08/06/16 à 20:21, Guillaume Munch a écrit : I'd rather include only the standard headers to obtain unique_ptr, and then include support/make_unique.h when we explicitly need it. When you have unique_ptr, you also want to have make_unique without hassle. The reason is that apart from some

Re: unique_ptr

Le 07/06/2016 16:32, Jean-Marc Lasgouttes a écrit : Le 07/06/2016 à 17:25, Guillaume Munch a écrit : Technically, unique_ptr.h is also useful to include . When you start using unique_ptr, you expect that you might use make_unique at some point, so you want to just include a generic header

Re: [PATCH] unique_ptr and some clean-up

Jean-Marc Lasgouttes wrote: > Le 06/06/2016 22:26, Georg Baum a écrit : > > Why do you remove the code that checks for C++11? At some time my idea > was to do > > for arg in "" "-std c++11" "-std c++0x" ; do >if $CXX $arg is a C++11 compiler then > break > done > if $CXX $arg is not

Re: [PATCH] unique_ptr and some clean-up

Le 07/06/2016 15:23, Jean-Marc Lasgouttes a écrit : Le 05/06/2016 à 01:01, Guillaume Munch a écrit : Dear List, I have recently started using c++11 features, and, one thing leading to another, some cleaning of the tree happened. Apparently most of the changes below are supported by old

Re: unique_ptr

compilers (exceptions below), i.e. MSVC 2012 and maybe MSVC 2010 (if lucky) since at least one developer seemed to care about it. 1-3. Introduce lyx::unique_ptr and lyx::make_unique and remove auto_ptr. This is used by two other patches waiting to be committed. After the first commit, the option --disable

Re: unique_ptr

Le 07/06/2016 à 17:25, Guillaume Munch a écrit : Technically, unique_ptr.h is also useful to include . When you start using unique_ptr, you expect that you might use make_unique at some point, so you want to just include a generic header. I'd rather include only the standard headers to obtain

Re: changes (Re: [PATCH] unique_ptr and some clean-up)

Le 07/06/2016 08:09, Jean-Marc Lasgouttes a écrit : Le 05/06/2016 01:01, Guillaume Munch a écrit : 13. This one is more for Jean-Marc I think (but not exclusively). There are three changes detailed in the log which are a bit less important than the ones above, but for which I would nevertheless

Re: [PATCH] unique_ptr and some clean-up

ur: ‘lyx::IconvProcessor::IconvProcessor(const lyx::IconvProcessor&)’ is implicitly deleted because the default definition would be ill-formed: ../../../master/src/support/../support/unicode.h:48:7: erreur: use of deleted function ‘std::unique_ptr<_Tp, _Dp>::unique_ptr(const std

changes (Re: [PATCH] unique_ptr and some clean-up)

Le 05/06/2016 01:01, Guillaume Munch a écrit : 13. This one is more for Jean-Marc I think (but not exclusively). There are three changes detailed in the log which are a bit less important than the ones above, but for which I would nevertheless be happy to have comments. This one looks good,

changer (was: Re: [PATCH] unique_ptr and some clean-up)

Le 05/06/2016 01:01, Guillaume Munch a écrit : 12. This is a new helper class that I wrote because the Changer class from MetricsInfo was too cumbersome (essentially a TeX \def with shadowing). This commit entirely replaces the latter with a better alternative. While I am not sure that the

remove boost stuff (was: Re: [PATCH] unique_ptr and some clean-up)

. Straightforward and without risk. 7-8. These are essentially examples. While there is no hurry to apply these patches, they are a good example of how the unique_ptr introduced in the first commit let us simplify the class definitions. I believe in "do not fix the unbroken", but I also believe that

unique_ptr (was: Re: [PATCH] unique_ptr and some clean-up)

2010 (if lucky) since at least one developer seemed to care about it. 1-3. Introduce lyx::unique_ptr and lyx::make_unique and remove auto_ptr. This is used by two other patches waiting to be committed. After the first commit, the option --disable-cxx11 will fail. As I see it, support/unique_ptr.h

Re: [PATCH] unique_ptr and some clean-up

Le 06/06/2016 22:26, Georg Baum a écrit : It turned out that it was too difficult to retain the stuff for some hypothetical future C++14 checks. I will commit the attached unless nobody objects. This is simply the unconditional use of C++11. After this patch it would be possible to get rid of

Re: [PATCH] unique_ptr and some clean-up

st change the >> --disable-cxx11 switch to --disable-cxx14, so that we do not loose >> the infrastructure, and remove all code that is inside #ifndef >> LYX_USE_CXX11. Afterwards, we can gradually introduce more C++11 >> features like unique_ptr. I can do the configure stu

Re: [PATCH] unique_ptr and some clean-up

Le 06/06/16 à 21:04, Guillaume Munch a écrit : Le 06/06/2016 10:22, Jean-Marc Lasgouttes a écrit : Le 05/06/2016 à 13:54, Georg Baum a écrit : Looks good, I have only one minor comment: Please do not use _MSC_VER in the sources. This code is better located in config.h, like that: #if

boost:regex & gcc (was: [PATCH] unique_ptr and some clean-up)

Guillaume Munch wrote: > 11. boost:regex. We have learnt the pitfalls of having two regex > libraries at the same time. However, according to a comment in the > source, gcc < 4.9.0 supports std::regex badly. Do we still care about > gcc < 4.9.0 ? (no hurry, and the patch is trivial) I think that

Re: [PATCH] unique_ptr and some clean-up

Le 06/06/2016 10:35, Jean-Marc Lasgouttes a écrit : Le 05/06/2016 à 13:54, Georg Baum a écrit : I won't comment on the other items. IMHO, discussing all these in one message makes things more complicated. I would prefer to go step by step. I agree with Georg on that. It would be better to

Re: [PATCH] unique_ptr and some clean-up

Le 06/06/2016 10:22, Jean-Marc Lasgouttes a écrit : Le 05/06/2016 à 13:54, Georg Baum a écrit : Looks good, I have only one minor comment: Please do not use _MSC_VER in the sources. This code is better located in config.h, like that: #if (__cplusplus >= 201402L) ||

Re: [PATCH] unique_ptr and some clean-up

Le 05/06/2016 à 13:54, Georg Baum a écrit : I won't comment on the other items. IMHO, discussing all these in one message makes things more complicated. I would prefer to go step by step. I agree with Georg on that. It would be better to have distinct threads, at least for groups of patches

Re: [PATCH] unique_ptr and some clean-up

Le 05/06/2016 à 13:54, Georg Baum a écrit : Looks good, I have only one minor comment: Please do not use _MSC_VER in the sources. This code is better located in config.h, like that: #if (__cplusplus >= 201402L) || (defined(_MSC_VER)&&(_MSC_VER>=1800)) // C++14, MSVC >= 2013 #define

Re: [PATCH] unique_ptr and some clean-up

for the release of lyx 2.2, I vote for supporting MSVC >= 2015. 1-3. Introduce lyx::unique_ptr and lyx::make_unique and remove auto_ptr. This is used by two other patches waiting to be committed. After the first commit, the option --disable-cxx11 will fail. Looks good, I have only one mi

Re: [PATCH] unique_ptr and some clean-up

uld vote to support MSVC 2013 and later, but nothing earlier. > 1-3. Introduce lyx::unique_ptr and lyx::make_unique and remove auto_ptr. > This is used by two other patches waiting to be committed. After the > first commit, the option --disable-cxx11 will fail. Looks good, I have only one