I'm testing people's acceptance of C++11 by enabling it in Moses.
https://github.com/moses-smt/mosesdecoder/commit/4910a385906d68caa8f9b54dc6aaeb44b205a9c5
We're linking to libraries that requires it so not having C++11 is getting
to be a chore.
Please let me know if you have trouble compiling Mo
-
___
Moses-support mailing list
Moses-support@mit.edu
http://mailman.mit.edu/mailman/listinfo/moses-support
On June 18, 2015 4:50:46 AM GMT+07:00, Lane Schwartz wrote:
>C++ is a legacy programming language, built on an even older legacy
>programming language.
>
>Programming good C++ code that is readable, maintainable, and
>memory-safe
>is possible, but it requires a high degree of technical competency
C++ is a legacy programming language, built on an even older legacy
programming language.
Programming good C++ code that is readable, maintainable, and memory-safe
is possible, but it requires a high degree of technical competency and
discipline.
The C++11 standard (and even more so the C++14 sta
I'd strongly advise against being too avant garde. Moses has a large user
base, and many users are still using (or have to use) stable, run-off-the
mill linux installations that are a few years old yet still officially
supported. In my opinion, our reference architecture for core moses
functionalit
On June 16, 2015 11:02:59 PM GMT+07:00, Rico Sennrich
wrote:
>Hi list,
>
>some code in mosesdecoder (oxlm, c++tokenizer) already requires c++11.
>To
>let people benefit from the usability and functionality improvements of
>c++11, it would be beneficial to allow the use of c++11 features in all
>o
Hi list,
some code in mosesdecoder (oxlm, c++tokenizer) already requires c++11. To
let people benefit from the usability and functionality improvements of
c++11, it would be beneficial to allow the use of c++11 features in all of
the code.
before people start making big changes to the codebase, w
It makes sense. I didn't use bjam for building, so that's why it broke
Best regards,
*Jie Jiang*
Senior Language Technology Specialist
Capita Translation and Interpreting
Riverside Court, Huddersfield Road, Delph, Oldham, OL3 5FZ | Tel (UK): +44
845 367 7000 | Tel (US): +1 (800) 579-5010
T
On 15.01.2014 23:23, Jie Jiang wrote:
Sorry Rico, my bad, I didn't turn on that switch. Now it compiled.
However, c++11 was not specified in Jamroot, how did your compiler
have that flag on?
I added the switch -std=c++0x to Jamroot, which is synonymous with
-std=c++11 for gcc (see commit d2
Sorry Rico, my bad, I didn't turn on that switch. Now it compiled.
However, c++11 was not specified in Jamroot, how did your compiler have
that flag on?
Best regards,
*Jie Jiang*
Senior Language Technology Specialist
Capita Translation and Interpreting
Riverside Court, Huddersfield Road, Delph
On 15.01.2014 16:58, Jie Jiang wrote:
Hi Roco:
I think in the future it would be better to wrap up the c11 code with
macros like:
#if __cplusplus >= 201103L
//c11 code here
#
//old code here
#endif
or else it will fail others who are not using a compiler with c11
support
I was using TDM-gcc 4.7.1 under mingw
Best regards,
*Jie Jiang*
Senior Language Technology Specialist
Capita Translation and Interpreting
Riverside Court, Huddersfield Road, Delph, Oldham, OL3 5FZ | Tel (UK): +44
845 367 7000 | Tel (US): +1 (800) 579-5010
Tel Direct: +44 (0)844 854 8984 | mail
which compiler were you using, so that we know what to look out for?
On 15 January 2014 16:58, Jie Jiang wrote:
> Hi Roco:
>
> I think in the future it would be better to wrap up the c11 code with
> macros like:
>
> #if __cplusplus >= 201103L
> //c11 code here
> #
> //old co
Hi Roco:
I think in the future it would be better to wrap up the c11 code with
macros like:
#if __cplusplus >= 201103L
//c11 code here
#
//old code here
#endif
or else it will fail others who are not using a compiler with c11 support,
like what happened to me this morning...
Rico Sennrich writes:
>
> I just pushed a commit that uses a C++11 feature (initalizer list). It
> should work with compilers that are no older than 5 years or so (gcc >= 4.4).
>
I reverted the commits again; there were issues with gcc < 4.6, and
apparently some different problems with the rec
This is called by some very shady code of mine, memory mapping is
involved and stuff. I will take a closer look today.
W dniu 15.01.2014 10:32, Rico Sennrich pisze:
> Marcin Junczys-Dowmunt writes:
>
>> Revision d2d508184e35909aa5da901b81bb70f10f7794c7 breaks my compact
>> reordering model, but
Marcin Junczys-Dowmunt writes:
> Revision d2d508184e35909aa5da901b81bb70f10f7794c7 breaks my compact
> reordering model, but at runtime and only if you do a clean build
> without any build artifacts from earlier compilations. It segfaults
> during loading in a weird low-level place.
Hi Marcin
Hi Rico,
Revision d2d508184e35909aa5da901b81bb70f10f7794c7 breaks my compact
reordering model, but at runtime and only if you do a clean build
without any build artifacts from earlier compilations. It segfaults
during loading in a weird low-level place. I can investigate some more
if you want m
Hi list,
I just pushed a commit that uses a C++11 feature (initalizer list). It
should work with compilers that are no older than 5 years or so (gcc >= 4.4).
If you have trouble compiling it (because you're using an older gcc version
or another compiler), please speak up. This is basically a test
, Li Xiang wrote:
> Hi,
>
> Does Moses support C++11 compilation?
> Because I want to integrate my code which is base on C++11 into Moses.
> How to modify the bjam config file to compile Moses using C++11?
> Thanks.
>
> --
> Xiang Li
>
>
Hi,
Does Moses support C++11 compilation?
Because I want to integrate my code which is base on C++11 into Moses.
How to modify the bjam config file to compile Moses using C++11?
Thanks.
--
Xiang Li
___
Moses-support mailing list
Moses-support@mit.edu
21 matches
Mail list logo
