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, includ
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
Date: Sun Apr 2 21:04:06 2017 +0200
MathAtom is a unique_ptr
Fix coverity suggestion of defining a move
Le 07/04/2017 à 23:55, Guillaume MM a écrit :
commit b382b246b62b66100733449b2bf75a01fd1d263f
Author: Guillaume MM
Date: Sun Apr 2 21:04:06 2017 +0200
MathAtom is a unique_ptr
Fix coverity suggestion of defining a move constructor
- /// default constructor, object is
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 delega
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 must
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 ? ;)
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 o
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>, but then my C++11 default skills showed
their weakness.
What errors does
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>, but then my C++11 default skills showed
>> their weakness.
>
> Wha
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>, but then my C++11 default skills showed
their weakness.
What errors does it give with
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>, 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 until Thurs
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>, but then my C++11 default skills showed
their weakness.
What errors does it give with the attac
typedef, but of course RefChange
proved more difficult. I tried to define it as a subclass of
unique_ptr>, 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 the old crufty o
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). M
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 o
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
> >> constructo
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
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
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 supp
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
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
>> do we have for d
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 compil
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
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 12
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
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 'std::make_unique' w
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
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
> > http://stackoverflo
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 version.
Why not?
ch
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 whether the compiler
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 k
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 so
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 currently lack gcc > 4.
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
> > distributions that current
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 since
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 g
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
> >>
> >>> Le 09/06/2016 15:23, Guillaume Munch a écri
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 3353df4..52da6ce 100644
--- a/c
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
> > > --- a/configure.ac
> > > +++ b/c
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 w
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
> > # Nice to have w
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
+LYX_CHECK_DEF(m
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?
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
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
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
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 to
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 a
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
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"
#incl
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_u
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
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
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 C++
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 compile
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
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 o
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
r:
‘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
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, alt
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 Change
. 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
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
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 par
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 stuff if you li
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 (__cplusp
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 r
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 have
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) || (defined(_MSC_VER)&&(_MSC_VER
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 th
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 HAVE_STD_MAKE
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
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
73 matches
Mail list logo