Some time ago (in the fall of 2016), when developing the next version of the 1C: Enterprise technology platform within the development team, the question arose of supporting the new
C ++ 14 standard in our code. The transition to the new standard, as we expected, would allow us to write many things more elegantly, easier and more reliably, simplified support and maintenance of the code. And the translation seems to be nothing extraordinary, if not for the scale of the code base and the specific features of our code.
For those who do not know, 1C: Enterprise is an environment for the rapid development of cross-platform business applications and runtime for their execution in different operating systems and DBMSs. In general terms, the product includes:
- Cluster of application servers running on Windows and Linux
- The client working with the server via http (s) or using its own binary protocol works on Windows, Linux, macOS
- Web client running in Chrome, Internet Explorer, Microsoft Edge, Firefox, Safari (written in JavaScript) browsers
- Development Environment ( Configurator ), runs on Windows, Linux, macOS
- Application Server Administration Tools , run on Windows, Linux, macOS
- Mobile client connecting to the server via http (s), works on mobile devices running Android, iOS, Windows
- Mobile platform - a framework for creating offline mobile applications with the ability to synchronize, working on Android, iOS, Windows
- Development environment 1C: Enterprise Development Tools , written in Java
- Interaction System Server
We try to maximally write one code for different operating systems — the server's code base is 99% common, and the client approximately 95%. The 1C: Enterprise technology platform is primarily written in C ++ and the following are approximate characteristics of the code:
')
- 10 million lines of C ++ code
- 14 thousand files
- 60 thousand classes
- half a million methods.
And all this economy should be transferred to C ++ 14. Today we will tell you about how we did it and what we encountered in the process.

Disclaimer
Everything written below about slow / fast work, (not) high memory consumption by implementations of standard classes in various libraries means one thing: this is true FOR US. Quite possibly, standard implementations are best suited for your tasks. We started from our tasks: we took typical data for our customers, drove typical scenarios on them, looked at the speed, the amount of memory consumed, etc., and analyzed whether we and our customers are satisfied with such results or not. And acted depending on.
What we had
Initially, we wrote the code for the 1C: Enterprise 8 platform in Microsoft Visual Studio. The project began in the early 2000s and we had a version only for Windows. Naturally, since then the code has been actively developed, many mechanisms have been completely rewritten. But the code was written according to the 1998 standard, and, for example, our right-angle brackets were separated by spaces in order for the compilation to succeed, like this:
vector<vector<int> > IntV;
2006 , 8.1, Linux
STLPort. . std::wstring, wchar_t. Windows 2 , Linux 4 . , . gcc , wchar_t 2 , , .. glibc, 4- wchar_t. , - , . , last but not least, . , .. .
, 2000-
. , Facebook, Facebook , (.
folly).
:
- ( ).
- Copy On Write. , / .
, STLPort stream ( ), 20%.
Boost. Boost stream, , API (, ), , stream. , , Boost.
C++14 :
- STLPort C++14. , .. STLPort 2010 , .
- STL, C++14. , Windows Linux.
- .
- .
;
libc++, Windows. libc++ Windows, — , , , , libc++
POSIX API.
.
, STLPort (Visual Studio 2015 Windows, gcc 7 Linux, clang 8 macOS).
, , , , , , . 10 000 ( 14 000). wchar_t char16_t; wchar_t, .. char16_t 2 Windows Linux.
. , STLPort , . , .
, , . .
( 20-30%) ( 10-15%) . , , . , .
: ( ) std::map std::set . . , , – ( STLPort). Boost, , .
, , , , Windows-. , 2017 ( 8.3.11 1:) .
++14 6 . ( ) , , — UI, , ..
. , 1: 8.3.14 ( , )
++17.
. STL std, std , stdx – , , boost – boost. , .
«» (
move constructors) . , STL (, capacity ).
, , ( ) —
obj-, 60 – 70 . , . , , , . . , . , , .
unity build (, , Google Chrome).