ನಾವು 10 ಮಿಲಿಯನ್ ಸಾಲುಗಳ C++ ಕೋಡ್ ಅನ್ನು C++14 ಸ್ಟ್ಯಾಂಡರ್ಡ್‌ಗೆ ಹೇಗೆ ಅನುವಾದಿಸಿದ್ದೇವೆ (ಮತ್ತು ನಂತರ C++17 ಗೆ)

ಕೆಲವು ಸಮಯದ ಹಿಂದೆ (2016 ರ ಶರತ್ಕಾಲದಲ್ಲಿ), 1C: ಎಂಟರ್‌ಪ್ರೈಸ್ ತಂತ್ರಜ್ಞಾನ ವೇದಿಕೆಯ ಮುಂದಿನ ಆವೃತ್ತಿಯ ಅಭಿವೃದ್ಧಿಯ ಸಮಯದಲ್ಲಿ, ಹೊಸ ಮಾನದಂಡವನ್ನು ಬೆಂಬಲಿಸುವ ಬಗ್ಗೆ ಅಭಿವೃದ್ಧಿ ತಂಡದಲ್ಲಿ ಪ್ರಶ್ನೆ ಉದ್ಭವಿಸಿತು ಸಿ ++ 14 ನಮ್ಮ ಕೋಡ್‌ನಲ್ಲಿ. ಹೊಸ ಮಾನದಂಡಕ್ಕೆ ಪರಿವರ್ತನೆ, ನಾವು ಊಹಿಸಿದಂತೆ, ಅನೇಕ ವಿಷಯಗಳನ್ನು ಹೆಚ್ಚು ಸೊಗಸಾಗಿ, ಸರಳವಾಗಿ ಮತ್ತು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿ ಬರೆಯಲು ನಮಗೆ ಅನುಮತಿಸುತ್ತದೆ ಮತ್ತು ಕೋಡ್‌ನ ಬೆಂಬಲ ಮತ್ತು ನಿರ್ವಹಣೆಯನ್ನು ಸರಳಗೊಳಿಸುತ್ತದೆ. ಮತ್ತು ಅನುವಾದದಲ್ಲಿ ಅಸಾಮಾನ್ಯ ಏನೂ ಇಲ್ಲ ಎಂದು ತೋರುತ್ತದೆ, ಕೋಡ್ ಬೇಸ್ನ ಪ್ರಮಾಣ ಮತ್ತು ನಮ್ಮ ಕೋಡ್ನ ನಿರ್ದಿಷ್ಟ ವೈಶಿಷ್ಟ್ಯಗಳಿಗೆ ಇಲ್ಲದಿದ್ದರೆ.

ತಿಳಿದಿಲ್ಲದವರಿಗೆ, 1C: ಎಂಟರ್‌ಪ್ರೈಸ್ ಎನ್ನುವುದು ಕ್ರಾಸ್-ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ವ್ಯಾಪಾರ ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ತ್ವರಿತ ಅಭಿವೃದ್ಧಿ ಮತ್ತು ವಿಭಿನ್ನ OS ಗಳು ಮತ್ತು DBMS ಗಳಲ್ಲಿ ಅವುಗಳ ಕಾರ್ಯಗತಗೊಳಿಸಲು ರನ್‌ಟೈಮ್‌ಗೆ ಪರಿಸರವಾಗಿದೆ. ಸಾಮಾನ್ಯ ಪರಿಭಾಷೆಯಲ್ಲಿ, ಉತ್ಪನ್ನವು ಒಳಗೊಂಡಿದೆ:

• ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್ ಕ್ಲಸ್ಟರ್, ವಿಂಡೋಸ್ ಮತ್ತು ಲಿನಕ್ಸ್‌ನಲ್ಲಿ ಚಲಿಸುತ್ತದೆ
• ಗ್ರಾಹಕ, http(s) ಅಥವಾ ಅದರ ಸ್ವಂತ ಬೈನರಿ ಪ್ರೋಟೋಕಾಲ್ ಮೂಲಕ ಸರ್ವರ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವುದು, Windows, Linux, macOS ನಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ
• ವೆಬ್ ಕ್ಲೈಂಟ್, Chrome, Internet Explorer, Microsoft Edge, Firefox, Safari ಬ್ರೌಸರ್‌ಗಳಲ್ಲಿ ಚಾಲನೆಯಾಗುತ್ತಿದೆ (ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್‌ನಲ್ಲಿ ಬರೆಯಲಾಗಿದೆ)
• ಅಭಿವೃದ್ಧಿ ಪರಿಸರ (ಸಂರಚನಾಕಾರ), Windows, Linux, macOS ನಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ
• ಆಡಳಿತ ಉಪಕರಣಗಳು ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್‌ಗಳು, ವಿಂಡೋಸ್, ಲಿನಕ್ಸ್, ಮ್ಯಾಕೋಸ್‌ನಲ್ಲಿ ರನ್ ಮಾಡಿ
• ಮೊಬೈಲ್ ಕ್ಲೈಂಟ್, http(s) ಮೂಲಕ ಸರ್ವರ್‌ಗೆ ಸಂಪರ್ಕಿಸುವುದು, Android, iOS, Windows ಚಾಲನೆಯಲ್ಲಿರುವ ಮೊಬೈಲ್ ಸಾಧನಗಳಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ
• ಮೊಬೈಲ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ - Android, iOS, Windows ನಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿರುವ, ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡುವ ಸಾಮರ್ಥ್ಯದೊಂದಿಗೆ ಆಫ್‌ಲೈನ್ ಮೊಬೈಲ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ರಚಿಸುವ ಚೌಕಟ್ಟು
• ಅಭಿವೃದ್ಧಿ ಪರಿಸರ 1C: ಎಂಟರ್‌ಪ್ರೈಸ್ ಡೆವಲಪ್‌ಮೆಂಟ್ ಟೂಲ್ಸ್, ಜಾವಾದಲ್ಲಿ ಬರೆಯಲಾಗಿದೆ
• ಸರ್ವರ್ ಸಂವಹನ ವ್ಯವಸ್ಥೆಗಳು

ನಾವು ಸಾಧ್ಯವಾದಷ್ಟು ವಿಭಿನ್ನ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್‌ಗಳಿಗೆ ಒಂದೇ ಕೋಡ್ ಅನ್ನು ಬರೆಯಲು ಪ್ರಯತ್ನಿಸುತ್ತೇವೆ - ಸರ್ವರ್ ಕೋಡ್ ಬೇಸ್ 99% ಸಾಮಾನ್ಯವಾಗಿದೆ, ಕ್ಲೈಂಟ್ ಕೋಡ್ ಬೇಸ್ ಸುಮಾರು 95% ಆಗಿದೆ. 1C: ಎಂಟರ್‌ಪ್ರೈಸ್ ತಂತ್ರಜ್ಞಾನ ವೇದಿಕೆಯನ್ನು ಪ್ರಾಥಮಿಕವಾಗಿ C++ ನಲ್ಲಿ ಬರೆಯಲಾಗಿದೆ ಮತ್ತು ಅಂದಾಜು ಕೋಡ್ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಕೆಳಗೆ ನೀಡಲಾಗಿದೆ:

• C++ ಕೋಡ್‌ನ 10 ಮಿಲಿಯನ್ ಸಾಲುಗಳು,
• 14 ಸಾವಿರ ಕಡತಗಳು
• 60 ಸಾವಿರ ತರಗತಿಗಳು
• ಅರ್ಧ ಮಿಲಿಯನ್ ವಿಧಾನಗಳು.

ಮತ್ತು ಈ ಎಲ್ಲಾ ವಿಷಯವನ್ನು C++14 ಗೆ ಅನುವಾದಿಸಬೇಕಾಗಿತ್ತು. ನಾವು ಇದನ್ನು ಹೇಗೆ ಮಾಡಿದ್ದೇವೆ ಮತ್ತು ಈ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ನಾವು ಏನು ಎದುರಿಸಿದ್ದೇವೆ ಎಂಬುದನ್ನು ಇಂದು ನಾವು ನಿಮಗೆ ಹೇಳುತ್ತೇವೆ.

ಹಕ್ಕು ನಿರಾಕರಣೆ

ನಿಧಾನ/ವೇಗದ ಕೆಲಸ, (ಅಲ್ಲ) ವಿವಿಧ ಲೈಬ್ರರಿಗಳಲ್ಲಿ ಪ್ರಮಾಣಿತ ತರಗತಿಗಳ ಅಳವಡಿಕೆಗಳ ಮೂಲಕ ದೊಡ್ಡ ಮೆಮೊರಿ ಬಳಕೆಯ ಬಗ್ಗೆ ಕೆಳಗೆ ಬರೆಯಲಾದ ಎಲ್ಲವೂ ಒಂದು ವಿಷಯ: ಇದು US ಗೆ ನಿಜವಾಗಿದೆ. ನಿಮ್ಮ ಕಾರ್ಯಗಳಿಗೆ ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಅಳವಡಿಕೆಗಳು ಹೆಚ್ಚು ಸೂಕ್ತವಾಗಿರುತ್ತದೆ. ನಾವು ನಮ್ಮ ಸ್ವಂತ ಕಾರ್ಯಗಳಿಂದ ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ: ನಾವು ನಮ್ಮ ಗ್ರಾಹಕರಿಗೆ ವಿಶಿಷ್ಟವಾದ ಡೇಟಾವನ್ನು ತೆಗೆದುಕೊಂಡಿದ್ದೇವೆ, ಅವುಗಳ ಮೇಲೆ ವಿಶಿಷ್ಟವಾದ ಸನ್ನಿವೇಶಗಳನ್ನು ನಡೆಸಿದ್ದೇವೆ, ಕಾರ್ಯಕ್ಷಮತೆ, ಸೇವಿಸಿದ ಮೆಮೊರಿಯ ಪ್ರಮಾಣ ಇತ್ಯಾದಿಗಳನ್ನು ನೋಡಿದ್ದೇವೆ ಮತ್ತು ನಾವು ಮತ್ತು ನಮ್ಮ ಗ್ರಾಹಕರು ಅಂತಹ ಫಲಿತಾಂಶಗಳಿಂದ ತೃಪ್ತರಾಗಿದ್ದೇವೆಯೇ ಅಥವಾ ಇಲ್ಲವೇ ಎಂಬುದನ್ನು ವಿಶ್ಲೇಷಿಸಿದ್ದೇವೆ. . ಮತ್ತು ಅವರು ಅವಲಂಬಿಸಿ ವರ್ತಿಸಿದರು.

ನಾವು ಏನನ್ನು ಹೊಂದಿದ್ದೇವೆ

ಆರಂಭದಲ್ಲಿ, ನಾವು ಮೈಕ್ರೋಸಾಫ್ಟ್ ವಿಷುಯಲ್ ಸ್ಟುಡಿಯೋದಲ್ಲಿ 1C: ಎಂಟರ್‌ಪ್ರೈಸ್ 8 ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಾಗಿ ಕೋಡ್ ಅನ್ನು ಬರೆದಿದ್ದೇವೆ. ಯೋಜನೆಯು 2000 ರ ದಶಕದ ಆರಂಭದಲ್ಲಿ ಪ್ರಾರಂಭವಾಯಿತು ಮತ್ತು ನಾವು ವಿಂಡೋಸ್-ಮಾತ್ರ ಆವೃತ್ತಿಯನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಸ್ವಾಭಾವಿಕವಾಗಿ, ಅಂದಿನಿಂದ ಕೋಡ್ ಅನ್ನು ಸಕ್ರಿಯವಾಗಿ ಅಭಿವೃದ್ಧಿಪಡಿಸಲಾಗಿದೆ, ಅನೇಕ ಕಾರ್ಯವಿಧಾನಗಳನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಪುನಃ ಬರೆಯಲಾಗಿದೆ. ಆದರೆ ಕೋಡ್ ಅನ್ನು 1998 ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಪ್ರಕಾರ ಬರೆಯಲಾಗಿದೆ ಮತ್ತು ಉದಾಹರಣೆಗೆ, ನಮ್ಮ ಲಂಬ ಕೋನ ಬ್ರಾಕೆಟ್ಗಳನ್ನು ಸ್ಥಳಗಳಿಂದ ಬೇರ್ಪಡಿಸಲಾಗಿದೆ ಇದರಿಂದ ಸಂಕಲನ ಯಶಸ್ವಿಯಾಗುತ್ತದೆ, ಈ ರೀತಿ:

vector<vector<int> > IntV;

2006 ರಲ್ಲಿ, ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಆವೃತ್ತಿ 8.1 ಬಿಡುಗಡೆಯೊಂದಿಗೆ, ನಾವು ಲಿನಕ್ಸ್ ಅನ್ನು ಬೆಂಬಲಿಸಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ ಮತ್ತು ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಪ್ರಮಾಣಿತ ಲೈಬ್ರರಿಗೆ ಬದಲಾಯಿಸಿದ್ದೇವೆ STLPort. ಪರಿವರ್ತನೆಗೆ ಒಂದು ಕಾರಣವೆಂದರೆ ವಿಶಾಲ ರೇಖೆಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವುದು. ನಮ್ಮ ಕೋಡ್‌ನಲ್ಲಿ, ನಾವು std::wstring ಅನ್ನು ಬಳಸುತ್ತೇವೆ, ಇದು wchar_t ಪ್ರಕಾರವನ್ನು ಆಧರಿಸಿದೆ. ವಿಂಡೋಸ್‌ನಲ್ಲಿ ಇದರ ಗಾತ್ರ 2 ಬೈಟ್‌ಗಳು ಮತ್ತು ಲಿನಕ್ಸ್‌ನಲ್ಲಿ ಡೀಫಾಲ್ಟ್ 4 ಬೈಟ್‌ಗಳು. ಇದು ಕ್ಲೈಂಟ್ ಮತ್ತು ಸರ್ವರ್ ನಡುವಿನ ನಮ್ಮ ಬೈನರಿ ಪ್ರೋಟೋಕಾಲ್‌ಗಳ ಅಸಾಮರಸ್ಯಕ್ಕೆ ಕಾರಣವಾಯಿತು, ಜೊತೆಗೆ ವಿವಿಧ ನಿರಂತರ ಡೇಟಾ. gcc ಆಯ್ಕೆಗಳನ್ನು ಬಳಸಿಕೊಂಡು, ಸಂಕಲನದ ಸಮಯದಲ್ಲಿ wchar_t ಗಾತ್ರವು 2 ಬೈಟ್‌ಗಳು ಎಂದು ನೀವು ನಿರ್ದಿಷ್ಟಪಡಿಸಬಹುದು, ಆದರೆ ನಂತರ ನೀವು ಕಂಪೈಲರ್‌ನಿಂದ ಪ್ರಮಾಣಿತ ಲೈಬ್ರರಿಯನ್ನು ಬಳಸುವುದನ್ನು ಮರೆತುಬಿಡಬಹುದು, ಏಕೆಂದರೆ ಇದು glibc ಅನ್ನು ಬಳಸುತ್ತದೆ, ಇದನ್ನು 4-ಬೈಟ್ wchar_t ಗಾಗಿ ಸಂಕಲಿಸಲಾಗಿದೆ. ಇತರ ಕಾರಣಗಳು ಸ್ಟ್ಯಾಂಡರ್ಡ್ ತರಗತಿಗಳ ಉತ್ತಮ ಅನುಷ್ಠಾನ, ಹ್ಯಾಶ್ ಟೇಬಲ್‌ಗಳಿಗೆ ಬೆಂಬಲ, ಮತ್ತು ನಾವು ಸಕ್ರಿಯವಾಗಿ ಬಳಸುತ್ತಿದ್ದ ಕಂಟೇನರ್‌ಗಳ ಒಳಗೆ ಚಲಿಸುವ ಶಬ್ದಾರ್ಥದ ಅನುಕರಣೆ. ಮತ್ತು ಇನ್ನೊಂದು ಕಾರಣ, ಅವರು ಕೊನೆಯದಾಗಿ ಹೇಳುವಂತೆ ಆದರೆ ಕನಿಷ್ಠವಲ್ಲ, ಸ್ಟ್ರಿಂಗ್ ಕಾರ್ಯಕ್ಷಮತೆ. ನಾವು ತಂತಿಗಳಿಗೆ ನಮ್ಮದೇ ವರ್ಗವನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಏಕೆಂದರೆ... ನಮ್ಮ ಸಾಫ್ಟ್‌ವೇರ್‌ನ ವಿಶಿಷ್ಟತೆಗಳಿಂದಾಗಿ, ಸ್ಟ್ರಿಂಗ್ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ವ್ಯಾಪಕವಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ ಮತ್ತು ನಮಗೆ ಇದು ನಿರ್ಣಾಯಕವಾಗಿದೆ.

ನಮ್ಮ ಸ್ಟ್ರಿಂಗ್ 2000 ರ ದಶಕದ ಆರಂಭದಲ್ಲಿ ವ್ಯಕ್ತಪಡಿಸಿದ ಸ್ಟ್ರಿಂಗ್ ಆಪ್ಟಿಮೈಸೇಶನ್ ವಿಚಾರಗಳನ್ನು ಆಧರಿಸಿದೆ ಆಂಡ್ರೇ ಅಲೆಕ್ಸಾಂಡ್ರೆಸ್ಕು. ನಂತರ, ಅಲೆಕ್ಸಾಂಡ್ರೆಸ್ಕು ಫೇಸ್‌ಬುಕ್‌ನಲ್ಲಿ ಕೆಲಸ ಮಾಡಿದಾಗ, ಅವರ ಸಲಹೆಯ ಮೇರೆಗೆ, ಫೇಸ್‌ಬುಕ್ ಎಂಜಿನ್‌ನಲ್ಲಿ ಇದೇ ರೀತಿಯ ತತ್ವಗಳ ಮೇಲೆ ಕೆಲಸ ಮಾಡುವ ರೇಖೆಯನ್ನು ಬಳಸಲಾಯಿತು (ಲೈಬ್ರರಿ ನೋಡಿ ಮೂರ್ಖತನ).

ನಮ್ಮ ಲೈನ್ ಎರಡು ಮುಖ್ಯ ಆಪ್ಟಿಮೈಸೇಶನ್ ತಂತ್ರಜ್ಞಾನಗಳನ್ನು ಬಳಸಿದೆ:

1. ಸಣ್ಣ ಮೌಲ್ಯಗಳಿಗಾಗಿ, ಸ್ಟ್ರಿಂಗ್ ವಸ್ತುವಿನ ಆಂತರಿಕ ಬಫರ್ ಅನ್ನು ಬಳಸಲಾಗುತ್ತದೆ (ಹೆಚ್ಚುವರಿ ಮೆಮೊರಿ ಹಂಚಿಕೆ ಅಗತ್ಯವಿಲ್ಲ).
2. ಎಲ್ಲಾ ಇತರರಿಗೆ, ಯಂತ್ರಶಾಸ್ತ್ರವನ್ನು ಬಳಸಲಾಗುತ್ತದೆ ಬರಹದಲ್ಲಿ ನಕಲು ಮಾಡಿ. ಸ್ಟ್ರಿಂಗ್ ಮೌಲ್ಯವನ್ನು ಒಂದೇ ಸ್ಥಳದಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ನಿಯೋಜನೆ/ಮಾರ್ಪಾಡು ಮಾಡುವಾಗ ಉಲ್ಲೇಖ ಕೌಂಟರ್ ಅನ್ನು ಬಳಸಲಾಗುತ್ತದೆ.

ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಸಂಕಲನವನ್ನು ವೇಗಗೊಳಿಸಲು, ನಮ್ಮ STLPort ರೂಪಾಂತರದಿಂದ ಸ್ಟ್ರೀಮ್ ಅನುಷ್ಠಾನವನ್ನು ನಾವು ಹೊರಗಿಟ್ಟಿದ್ದೇವೆ (ನಾವು ಅದನ್ನು ಬಳಸಲಿಲ್ಲ), ಇದು ನಮಗೆ ಸುಮಾರು 20% ವೇಗದ ಸಂಕಲನವನ್ನು ನೀಡಿತು. ತರುವಾಯ ನಾವು ಸೀಮಿತ ಬಳಕೆಯನ್ನು ಮಾಡಬೇಕಾಯಿತು ಬೂಸ್ಟ್. ಬೂಸ್ಟ್ ಸ್ಟ್ರೀಮ್ ಅನ್ನು ವಿಶೇಷವಾಗಿ ಅದರ ಸೇವಾ API ಗಳಲ್ಲಿ (ಉದಾಹರಣೆಗೆ, ಲಾಗಿಂಗ್ ಮಾಡಲು) ಭಾರೀ ಬಳಕೆಯನ್ನು ಮಾಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಸ್ಟ್ರೀಮ್ ಬಳಕೆಯನ್ನು ತೆಗೆದುಹಾಕಲು ನಾವು ಅದನ್ನು ಮಾರ್ಪಡಿಸಬೇಕಾಗಿತ್ತು. ಇದು ಪ್ರತಿಯಾಗಿ, ಬೂಸ್ಟ್‌ನ ಹೊಸ ಆವೃತ್ತಿಗಳಿಗೆ ವಲಸೆ ಹೋಗಲು ನಮಗೆ ಕಷ್ಟಕರವಾಗಿದೆ.

ಮೂರನೇ ದಾರಿ

C++14 ಮಾನದಂಡಕ್ಕೆ ಚಲಿಸುವಾಗ, ನಾವು ಈ ಕೆಳಗಿನ ಆಯ್ಕೆಗಳನ್ನು ಪರಿಗಣಿಸಿದ್ದೇವೆ:

1. ನಾವು C++14 ಮಾನದಂಡಕ್ಕೆ ಮಾರ್ಪಡಿಸಿದ STLPort ಅನ್ನು ಅಪ್‌ಗ್ರೇಡ್ ಮಾಡಿ. ಆಯ್ಕೆಯು ತುಂಬಾ ಕಷ್ಟಕರವಾಗಿದೆ, ಏಕೆಂದರೆ ... 2010 ರಲ್ಲಿ STLPort ಗೆ ಬೆಂಬಲವನ್ನು ನಿಲ್ಲಿಸಲಾಯಿತು, ಮತ್ತು ಅದರ ಎಲ್ಲಾ ಕೋಡ್ ಅನ್ನು ನಾವೇ ನಿರ್ಮಿಸಬೇಕಾಗಿದೆ.
2. C++14 ಗೆ ಹೊಂದಿಕೆಯಾಗುವ ಮತ್ತೊಂದು STL ಅನುಷ್ಠಾನಕ್ಕೆ ಪರಿವರ್ತನೆ. ಈ ಅನುಷ್ಠಾನವು ವಿಂಡೋಸ್ ಮತ್ತು ಲಿನಕ್ಸ್‌ಗಾಗಿ ಹೆಚ್ಚು ಅಪೇಕ್ಷಣೀಯವಾಗಿದೆ.
3. ಪ್ರತಿ OS ಗೆ ಕಂಪೈಲ್ ಮಾಡುವಾಗ, ಅನುಗುಣವಾದ ಕಂಪೈಲರ್‌ನಲ್ಲಿ ನಿರ್ಮಿಸಲಾದ ಲೈಬ್ರರಿಯನ್ನು ಬಳಸಿ.

ಹೆಚ್ಚಿನ ಕೆಲಸದ ಕಾರಣದಿಂದಾಗಿ ಮೊದಲ ಆಯ್ಕೆಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ತಿರಸ್ಕರಿಸಲಾಗಿದೆ.

ನಾವು ಸ್ವಲ್ಪ ಸಮಯದವರೆಗೆ ಎರಡನೇ ಆಯ್ಕೆಯ ಬಗ್ಗೆ ಯೋಚಿಸಿದ್ದೇವೆ; ಅಭ್ಯರ್ಥಿಯಾಗಿ ಪರಿಗಣಿಸಲಾಗಿದೆ libc++, ಆದರೆ ಆ ಸಮಯದಲ್ಲಿ ಅದು ವಿಂಡೋಸ್ ಅಡಿಯಲ್ಲಿ ಕೆಲಸ ಮಾಡಲಿಲ್ಲ. Libc++ ಅನ್ನು ವಿಂಡೋಸ್‌ಗೆ ಪೋರ್ಟ್ ಮಾಡಲು, ನೀವು ಬಹಳಷ್ಟು ಕೆಲಸಗಳನ್ನು ಮಾಡಬೇಕಾಗುತ್ತದೆ - ಉದಾಹರಣೆಗೆ, ಈ ಪ್ರದೇಶಗಳಲ್ಲಿ libc++ ಅನ್ನು ಬಳಸಿರುವುದರಿಂದ ಎಳೆಗಳು, ಥ್ರೆಡ್ ಸಿಂಕ್ರೊನೈಸೇಶನ್ ಮತ್ತು ಪರಮಾಣುಗಳೊಂದಿಗೆ ಮಾಡಬೇಕಾದ ಎಲ್ಲವನ್ನೂ ನೀವೇ ಬರೆಯಿರಿ. POSIX API.

ಮತ್ತು ನಾವು ಮೂರನೇ ಮಾರ್ಗವನ್ನು ಆರಿಸಿದ್ದೇವೆ.

ಪರಿವರ್ತನೆ

ಆದ್ದರಿಂದ, ನಾವು STLPort ನ ಬಳಕೆಯನ್ನು ಅನುಗುಣವಾದ ಕಂಪೈಲರ್‌ಗಳ ಲೈಬ್ರರಿಗಳೊಂದಿಗೆ ಬದಲಾಯಿಸಬೇಕಾಗಿತ್ತು (Windows ಗಾಗಿ ವಿಷುಯಲ್ ಸ್ಟುಡಿಯೋ 2015, Linux ಗಾಗಿ gcc 7, macOS ಗಾಗಿ ಕ್ಲಾಂಗ್ 8).

ಅದೃಷ್ಟವಶಾತ್, ನಮ್ಮ ಕೋಡ್ ಅನ್ನು ಮುಖ್ಯವಾಗಿ ಮಾರ್ಗಸೂಚಿಗಳ ಪ್ರಕಾರ ಬರೆಯಲಾಗಿದೆ ಮತ್ತು ಎಲ್ಲಾ ರೀತಿಯ ಬುದ್ಧಿವಂತ ತಂತ್ರಗಳನ್ನು ಬಳಸಲಿಲ್ಲ, ಆದ್ದರಿಂದ ಹೊಸ ಗ್ರಂಥಾಲಯಗಳಿಗೆ ವಲಸೆಯು ತುಲನಾತ್ಮಕವಾಗಿ ಸರಾಗವಾಗಿ ಮುಂದುವರಿಯಿತು, ಪ್ರಕಾರಗಳು, ತರಗತಿಗಳು, ನೇಮ್‌ಸ್ಪೇಸ್‌ಗಳ ಹೆಸರುಗಳನ್ನು ಬದಲಾಯಿಸುವ ಮತ್ತು ಮೂಲದಲ್ಲಿ ಒಳಗೊಂಡಿರುವ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳ ಸಹಾಯದಿಂದ ಕಡತಗಳನ್ನು. ವಲಸೆಯು 10 ಮೂಲ ಫೈಲ್‌ಗಳ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರಿತು (000 ರಲ್ಲಿ). wchar_t ಅನ್ನು char14_t ನಿಂದ ಬದಲಾಯಿಸಲಾಯಿತು; ನಾವು wchar_t ಬಳಕೆಯನ್ನು ತ್ಯಜಿಸಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ, ಏಕೆಂದರೆ char000_t ಎಲ್ಲಾ OS ಗಳಲ್ಲಿ 16 ಬೈಟ್‌ಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು Windows ಮತ್ತು Linux ನಡುವಿನ ಕೋಡ್ ಹೊಂದಾಣಿಕೆಯನ್ನು ಹಾಳು ಮಾಡುವುದಿಲ್ಲ.

ಕೆಲವು ಸಣ್ಣ ಸಾಹಸಗಳು ಇದ್ದವು. ಉದಾಹರಣೆಗೆ, STLPort ನಲ್ಲಿ ಒಂದು ಪುನರಾವರ್ತಕವನ್ನು ಒಂದು ಅಂಶಕ್ಕೆ ಪಾಯಿಂಟರ್‌ಗೆ ಸೂಚ್ಯವಾಗಿ ಬಿತ್ತರಿಸಬಹುದು ಮತ್ತು ನಮ್ಮ ಕೋಡ್‌ನಲ್ಲಿ ಕೆಲವು ಸ್ಥಳಗಳಲ್ಲಿ ಇದನ್ನು ಬಳಸಲಾಗಿದೆ. ಹೊಸ ಗ್ರಂಥಾಲಯಗಳಲ್ಲಿ ಇದನ್ನು ಮಾಡಲು ಇನ್ನು ಮುಂದೆ ಸಾಧ್ಯವಿಲ್ಲ, ಮತ್ತು ಈ ಭಾಗಗಳನ್ನು ವಿಶ್ಲೇಷಿಸಬೇಕು ಮತ್ತು ಕೈಯಾರೆ ಪುನಃ ಬರೆಯಬೇಕು.

ಆದ್ದರಿಂದ, ಕೋಡ್ ವಲಸೆ ಪೂರ್ಣಗೊಂಡಿದೆ, ಎಲ್ಲಾ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್‌ಗಳಿಗೆ ಕೋಡ್ ಅನ್ನು ಸಂಕಲಿಸಲಾಗಿದೆ. ಇದು ಪರೀಕ್ಷೆಗಳ ಸಮಯ.

ಪರಿವರ್ತನೆಯ ನಂತರದ ಪರೀಕ್ಷೆಗಳು ಕಾರ್ಯಕ್ಷಮತೆಯ ಕುಸಿತವನ್ನು ತೋರಿಸಿದೆ (ಕೆಲವು ಸ್ಥಳಗಳಲ್ಲಿ 20-30% ವರೆಗೆ) ಮತ್ತು ಮೆಮೊರಿ ಬಳಕೆಯಲ್ಲಿ ಹೆಚ್ಚಳ (10-15% ವರೆಗೆ) ಕೋಡ್‌ನ ಹಳೆಯ ಆವೃತ್ತಿಗೆ ಹೋಲಿಸಿದರೆ. ಇದು ನಿರ್ದಿಷ್ಟವಾಗಿ, ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಸ್ಟ್ರಿಂಗ್‌ಗಳ ಉಪೋತ್ಕೃಷ್ಟ ಕಾರ್ಯಕ್ಷಮತೆಯಿಂದಾಗಿ. ಆದ್ದರಿಂದ, ನಾವು ಮತ್ತೆ ನಮ್ಮದೇ ಆದ, ಸ್ವಲ್ಪ ಮಾರ್ಪಡಿಸಿದ ರೇಖೆಯನ್ನು ಬಳಸಬೇಕಾಗಿತ್ತು.

ಎಂಬೆಡೆಡ್ ಲೈಬ್ರರಿಗಳಲ್ಲಿ ಕಂಟೇನರ್‌ಗಳ ಅಳವಡಿಕೆಯ ಆಸಕ್ತಿದಾಯಕ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಸಹ ಬಹಿರಂಗಪಡಿಸಲಾಗಿದೆ: ಖಾಲಿ (ಅಂಶಗಳಿಲ್ಲದೆ) std:: ನಕ್ಷೆ ಮತ್ತು std:: ಅಂತರ್ನಿರ್ಮಿತ ಗ್ರಂಥಾಲಯಗಳಿಂದ ಸೆಟ್ ಮೆಮೊರಿಯನ್ನು ನಿಯೋಜಿಸುತ್ತದೆ. ಮತ್ತು ಅನುಷ್ಠಾನದ ವೈಶಿಷ್ಟ್ಯಗಳಿಂದಾಗಿ, ಕೋಡ್‌ನಲ್ಲಿ ಕೆಲವು ಸ್ಥಳಗಳಲ್ಲಿ ಈ ಪ್ರಕಾರದ ಸಾಕಷ್ಟು ಖಾಲಿ ಪಾತ್ರೆಗಳನ್ನು ರಚಿಸಲಾಗಿದೆ. ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಮೆಮೊರಿ ಕಂಟೇನರ್‌ಗಳನ್ನು ಒಂದು ಮೂಲ ಅಂಶಕ್ಕಾಗಿ ಸ್ವಲ್ಪ ಹಂಚಲಾಗುತ್ತದೆ, ಆದರೆ ನಮಗೆ ಇದು ನಿರ್ಣಾಯಕವಾಗಿದೆ - ಹಲವಾರು ಸನ್ನಿವೇಶಗಳಲ್ಲಿ, ನಮ್ಮ ಕಾರ್ಯಕ್ಷಮತೆ ಗಮನಾರ್ಹವಾಗಿ ಕುಸಿಯಿತು ಮತ್ತು ಮೆಮೊರಿ ಬಳಕೆ ಹೆಚ್ಚಾಗಿದೆ (STLPort ಗೆ ಹೋಲಿಸಿದರೆ). ಆದ್ದರಿಂದ, ನಮ್ಮ ಕೋಡ್‌ನಲ್ಲಿ ನಾವು ಈ ಎರಡು ರೀತಿಯ ಕಂಟೇನರ್‌ಗಳನ್ನು ಅಂತರ್ನಿರ್ಮಿತ ಲೈಬ್ರರಿಗಳಿಂದ ಬೂಸ್ಟ್‌ನಿಂದ ಅವುಗಳ ಅನುಷ್ಠಾನದೊಂದಿಗೆ ಬದಲಾಯಿಸಿದ್ದೇವೆ, ಅಲ್ಲಿ ಈ ಕಂಟೇನರ್‌ಗಳು ಅಂತಹ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಹೊಂದಿಲ್ಲ, ಮತ್ತು ಇದು ನಿಧಾನಗತಿ ಮತ್ತು ಹೆಚ್ಚಿದ ಮೆಮೊರಿ ಬಳಕೆಯಿಂದ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುತ್ತದೆ.

ದೊಡ್ಡ ಯೋಜನೆಗಳಲ್ಲಿ ದೊಡ್ಡ-ಪ್ರಮಾಣದ ಬದಲಾವಣೆಗಳ ನಂತರ ಆಗಾಗ್ಗೆ ಸಂಭವಿಸಿದಂತೆ, ಮೂಲ ಕೋಡ್‌ನ ಮೊದಲ ಪುನರಾವರ್ತನೆಯು ಸಮಸ್ಯೆಗಳಿಲ್ಲದೆ ಕೆಲಸ ಮಾಡಲಿಲ್ಲ, ಮತ್ತು ಇಲ್ಲಿ, ನಿರ್ದಿಷ್ಟವಾಗಿ, ವಿಂಡೋಸ್ ಅನುಷ್ಠಾನದಲ್ಲಿ ಡೀಬಗ್ ಮಾಡುವ ಪುನರಾವರ್ತಕಗಳಿಗೆ ಬೆಂಬಲವು ಸೂಕ್ತವಾಗಿ ಬಂದಿತು. ಹಂತ ಹಂತವಾಗಿ ನಾವು ಮುಂದೆ ಸಾಗಿದ್ದೇವೆ ಮತ್ತು 2017 ರ ವಸಂತಕಾಲದ ವೇಳೆಗೆ (ಆವೃತ್ತಿ 8.3.11 1C: ಎಂಟರ್‌ಪ್ರೈಸ್) ವಲಸೆ ಪೂರ್ಣಗೊಂಡಿತು.

ಫಲಿತಾಂಶಗಳು

C++14 ಸ್ಟ್ಯಾಂಡರ್ಡ್‌ಗೆ ಪರಿವರ್ತನೆಯು ನಮಗೆ ಸುಮಾರು 6 ತಿಂಗಳುಗಳನ್ನು ತೆಗೆದುಕೊಂಡಿತು. ಹೆಚ್ಚಿನ ಸಮಯ, ಒಬ್ಬ (ಆದರೆ ಹೆಚ್ಚು ಅರ್ಹವಾದ) ಡೆವಲಪರ್ ಯೋಜನೆಯಲ್ಲಿ ಕೆಲಸ ಮಾಡಿದರು ಮತ್ತು ಅಂತಿಮ ಹಂತದಲ್ಲಿ ನಿರ್ದಿಷ್ಟ ಪ್ರದೇಶಗಳಿಗೆ ಜವಾಬ್ದಾರರಾಗಿರುವ ತಂಡಗಳ ಪ್ರತಿನಿಧಿಗಳು ಸೇರಿಕೊಂಡರು - UI, ಸರ್ವರ್ ಕ್ಲಸ್ಟರ್, ಅಭಿವೃದ್ಧಿ ಮತ್ತು ಆಡಳಿತ ಉಪಕರಣಗಳು, ಇತ್ಯಾದಿ.

ಸ್ಟ್ಯಾಂಡರ್ಡ್‌ನ ಇತ್ತೀಚಿನ ಆವೃತ್ತಿಗಳಿಗೆ ವಲಸೆ ಹೋಗುವ ನಮ್ಮ ಕೆಲಸವನ್ನು ಪರಿವರ್ತನೆಯು ಹೆಚ್ಚು ಸರಳಗೊಳಿಸಿದೆ. ಹೀಗಾಗಿ, ಆವೃತ್ತಿ 1C: ಎಂಟರ್‌ಪ್ರೈಸ್ 8.3.14 (ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ, ಮುಂದಿನ ವರ್ಷದ ಆರಂಭದಲ್ಲಿ ಬಿಡುಗಡೆ ಮಾಡಲಾಗುವುದು) ಈಗಾಗಲೇ ಪ್ರಮಾಣಿತಕ್ಕೆ ವರ್ಗಾಯಿಸಲಾಗಿದೆ ಸಿ++17.

ವಲಸೆಯ ನಂತರ, ಡೆವಲಪರ್‌ಗಳಿಗೆ ಹೆಚ್ಚಿನ ಆಯ್ಕೆಗಳಿವೆ. ಮೊದಲು ನಾವು ನಮ್ಮದೇ ಆದ ಮಾರ್ಪಡಿಸಿದ STL ಮತ್ತು ಒಂದು std ನೇಮ್‌ಸ್ಪೇಸ್ ಅನ್ನು ಹೊಂದಿದ್ದರೆ, ಈಗ ನಾವು std ನೇಮ್‌ಸ್ಪೇಸ್‌ನಲ್ಲಿ ಅಂತರ್ನಿರ್ಮಿತ ಕಂಪೈಲರ್ ಲೈಬ್ರರಿಗಳಿಂದ ಸ್ಟ್ಯಾಂಡರ್ಡ್ ತರಗತಿಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ, stdx ನೇಮ್‌ಸ್ಪೇಸ್‌ನಲ್ಲಿ - ನಮ್ಮ ಲೈನ್‌ಗಳು ಮತ್ತು ಕಂಟೈನರ್‌ಗಳು ನಮ್ಮ ಕಾರ್ಯಗಳಿಗೆ ಹೊಂದುವಂತೆ, ಬೂಸ್ಟ್‌ನಲ್ಲಿ - ಬೂಸ್ಟ್‌ನ ಇತ್ತೀಚಿನ ಆವೃತ್ತಿ. ಮತ್ತು ಡೆವಲಪರ್ ತನ್ನ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಲು ಸೂಕ್ತವಾಗಿ ಸೂಕ್ತವಾದ ಆ ವರ್ಗಗಳನ್ನು ಬಳಸುತ್ತಾನೆ.

ಮೂವ್ ಕನ್‌ಸ್ಟ್ರಕ್ಟರ್‌ಗಳ "ಸ್ಥಳೀಯ" ಅನುಷ್ಠಾನವು ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ ಸಹಾಯ ಮಾಡುತ್ತದೆ (ಕನ್ಸ್ಟ್ರಕ್ಟರ್‌ಗಳನ್ನು ಸರಿಸಿ) ಹಲವಾರು ತರಗತಿಗಳಿಗೆ. ಒಂದು ವರ್ಗವು ಮೂವ್ ಕನ್‌ಸ್ಟ್ರಕ್ಟರ್ ಅನ್ನು ಹೊಂದಿದ್ದರೆ ಮತ್ತು ಈ ವರ್ಗವನ್ನು ಕಂಟೇನರ್‌ನಲ್ಲಿ ಇರಿಸಿದರೆ, ನಂತರ STL ಕಂಟೇನರ್‌ನೊಳಗಿನ ಅಂಶಗಳ ನಕಲು ಮಾಡುವಿಕೆಯನ್ನು ಉತ್ತಮಗೊಳಿಸುತ್ತದೆ (ಉದಾಹರಣೆಗೆ, ಧಾರಕವನ್ನು ವಿಸ್ತರಿಸಿದಾಗ ಮತ್ತು ಸಾಮರ್ಥ್ಯವನ್ನು ಬದಲಾಯಿಸಲು ಮತ್ತು ಮೆಮೊರಿಯನ್ನು ಮರುಹಂಚಿಕೆ ಮಾಡಲು ಇದು ಅಗತ್ಯವಾಗಿರುತ್ತದೆ).

ಮುಲಾಮುದಲ್ಲಿ ಫ್ಲೈ

ಬಹುಶಃ ವಲಸೆಯ ಅತ್ಯಂತ ಅಹಿತಕರ (ಆದರೆ ನಿರ್ಣಾಯಕವಲ್ಲ) ಪರಿಣಾಮವೆಂದರೆ ನಾವು ಪರಿಮಾಣದಲ್ಲಿ ಹೆಚ್ಚಳವನ್ನು ಎದುರಿಸುತ್ತಿದ್ದೇವೆ obj ಫೈಲ್‌ಗಳು, ಮತ್ತು ಎಲ್ಲಾ ಮಧ್ಯಂತರ ಫೈಲ್‌ಗಳೊಂದಿಗೆ ನಿರ್ಮಾಣದ ಪೂರ್ಣ ಫಲಿತಾಂಶವು 60-70 GB ಅನ್ನು ತೆಗೆದುಕೊಳ್ಳಲು ಪ್ರಾರಂಭಿಸಿತು. ಈ ನಡವಳಿಕೆಯು ಆಧುನಿಕ ಗುಣಮಟ್ಟದ ಗ್ರಂಥಾಲಯಗಳ ವಿಶಿಷ್ಟತೆಗಳ ಕಾರಣದಿಂದಾಗಿರುತ್ತದೆ, ಇದು ರಚಿತವಾದ ಸೇವಾ ಫೈಲ್‌ಗಳ ಗಾತ್ರದ ಬಗ್ಗೆ ಕಡಿಮೆ ವಿಮರ್ಶಾತ್ಮಕವಾಗಿದೆ. ಇದು ಕಂಪೈಲ್ ಮಾಡಿದ ಅಪ್ಲಿಕೇಶನ್‌ನ ಕಾರ್ಯಾಚರಣೆಯ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ, ಆದರೆ ಇದು ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ ಹಲವಾರು ಅನಾನುಕೂಲತೆಗಳನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ, ನಿರ್ದಿಷ್ಟವಾಗಿ, ಇದು ಸಂಕಲನ ಸಮಯವನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ. ಬಿಲ್ಡ್ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಮತ್ತು ಡೆವಲಪರ್ ಯಂತ್ರಗಳಲ್ಲಿ ಉಚಿತ ಡಿಸ್ಕ್ ಸ್ಥಳಾವಕಾಶದ ಅವಶ್ಯಕತೆಗಳು ಸಹ ಹೆಚ್ಚುತ್ತಿವೆ. ನಮ್ಮ ಡೆವಲಪರ್‌ಗಳು ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನ ಹಲವಾರು ಆವೃತ್ತಿಗಳಲ್ಲಿ ಸಮಾನಾಂತರವಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತಾರೆ ಮತ್ತು ನೂರಾರು ಗಿಗಾಬೈಟ್‌ಗಳ ಮಧ್ಯಂತರ ಫೈಲ್‌ಗಳು ಕೆಲವೊಮ್ಮೆ ತಮ್ಮ ಕೆಲಸದಲ್ಲಿ ತೊಂದರೆಗಳನ್ನು ಸೃಷ್ಟಿಸುತ್ತವೆ. ಸಮಸ್ಯೆಯು ಅಹಿತಕರವಾಗಿದೆ, ಆದರೆ ನಿರ್ಣಾಯಕವಲ್ಲ; ನಾವು ಇದೀಗ ಅದರ ಪರಿಹಾರವನ್ನು ಮುಂದೂಡಿದ್ದೇವೆ. ನಾವು ಅದನ್ನು ಪರಿಹರಿಸುವ ಆಯ್ಕೆಗಳಲ್ಲಿ ಒಂದಾಗಿ ತಂತ್ರಜ್ಞಾನವನ್ನು ಪರಿಗಣಿಸುತ್ತಿದ್ದೇವೆ ಏಕತೆ ನಿರ್ಮಾಣ (ನಿರ್ದಿಷ್ಟವಾಗಿ, Chrome ಬ್ರೌಸರ್ ಅನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವಾಗ Google ಅದನ್ನು ಬಳಸುತ್ತದೆ).

ಮೂಲ: www.habr.com