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 standard) represents a
good-faith attempt to bring (at least some) current programming language
best practices into C++. It represents an attempt to make C++ at least
pretend to be a modern programming language that is usable without intimate
knowledge of the dark arts of memory management and 30-40 years of
backward-compatible cruft.

Personally, I don't think the standards go far enough. But they are least a
major step in the right direction.

Use of C++11 is not avante garde. It is a very sensible move that will make
it easier for new users to contribute, and make it slightly harder for
certain types of bugs to hide.

Ubuntu LTS 12.04LTS ships with gcc 4.6.3, which fully supports most C++11
features; if there are actual concrete concerns about using the few
features that aren't implemented in a five-year-old compiler, fine. But
just remember that same five-year-old compiler can handle most C++11
features just fine - the main reason not to use them is inertia.

Unfortunately, there does not yet exist a mature general purpose
programming language that can replace C++ for all important use cases. I
have some hope, with the development of new languages like Swift, Rust, and
Go, but we're not there yet.

Take a look at the standard. It's not adding crazy controversial new
things. It's mainly making C++ slightly less like living in the the wild
west, and a little bit like living in the 21st century, where compilers can
do sensible things like infer types some of the time.


On Wed, Jun 17, 2015 at 2:50 PM, Ulrich Germann <[email protected]>
wrote:

> 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
> functionality should be the oldest Ubuntu LTS version still under official
> support, currently Ubuntu 12.04. I have to admit that I don't keep track
> closely what's happening with C++, but for me gcc-4.6 plus the boost
> libraries still does the trick. Why the rush to the latest and greatest?
> What exactly is so broken that we  need C++11 to fix it?
>
> - Uli
>
> On Tue, Jun 16, 2015 at 5:02 PM, Rico Sennrich <[email protected]>
> 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 of
>> the code.
>>
>> before people start making big changes to the codebase, we should make
>> sure
>> that there are no good reasons against allowing c++11 features, such as
>> lack
>> of compiler support.
>>
>> I pushed a minimal commit (6c0f875) to test the waters. If this introduces
>> bugs, or if users still rely on old compilers without c++11 support,
>> please
>> complain here.
>>
>> best wishes,
>> Rico
>>
>> _______________________________________________
>> Moses-support mailing list
>> [email protected]
>> http://mailman.mit.edu/mailman/listinfo/moses-support
>>
>>
>
>
> --
> Ulrich Germann
> Senior Researcher
> School of Informatics
> University of Edinburgh
>
> _______________________________________________
> Moses-support mailing list
> [email protected]
> http://mailman.mit.edu/mailman/listinfo/moses-support
>
>


-- 
When a place gets crowded enough to require ID's, social collapse is not
far away.  It is time to go elsewhere.  The best thing about space travel
is that it made it possible to go elsewhere.
                -- R.A. Heinlein, "Time Enough For Love"
_______________________________________________
Moses-support mailing list
[email protected]
http://mailman.mit.edu/mailman/listinfo/moses-support

Reply via email to