ພວກເຮົາແປລະຫັດ C++ 10 ລ້ານແຖວເປັນມາດຕະຖານ C++14 (ແລະຫຼັງຈາກນັ້ນເປັນ C++17)

ບາງຄັ້ງກ່ອນຫນ້ານີ້ (ໃນລະດູໃບໄມ້ປົ່ງຂອງປີ 2016), ໃນລະຫວ່າງການພັດທະນາຂອງເວທີເຕັກໂນໂລຢີ 1C: ວິສາຫະກິດຕໍ່ໄປ, ຄໍາຖາມທີ່ເກີດຂຶ້ນພາຍໃນທີມງານພັດທະນາກ່ຽວກັບການສະຫນັບສະຫນູນມາດຕະຖານໃຫມ່. C ++ 14 ໃນລະຫັດຂອງພວກເຮົາ. ການຫັນປ່ຽນໄປສູ່ມາດຕະຖານໃຫມ່, ດັ່ງທີ່ພວກເຮົາສົມມຸດວ່າ, ຈະຊ່ວຍໃຫ້ພວກເຮົາຂຽນຫຼາຍສິ່ງຢ່າງສະຫງ່າງາມ, ງ່າຍດາຍແລະເຊື່ອຖືໄດ້, ແລະຈະເຮັດໃຫ້ການສະຫນັບສະຫນູນແລະການບໍາລຸງຮັກສາລະຫັດງ່າຍຂຶ້ນ. ແລະເບິ່ງຄືວ່າບໍ່ມີຫຍັງພິເສດໃນການແປພາສາ, ຖ້າບໍ່ແມ່ນສໍາລັບຂະຫນາດຂອງຖານລະຫັດແລະລັກສະນະສະເພາະຂອງລະຫັດຂອງພວກເຮົາ.

ສໍາລັບຜູ້ທີ່ບໍ່ຮູ້, 1C:Enterprise ແມ່ນສະພາບແວດລ້ອມສໍາລັບການພັດທະນາຢ່າງໄວວາຂອງຄໍາຮ້ອງສະຫມັກທຸລະກິດຂ້າມເວທີແລະເວລາແລ່ນສໍາລັບການປະຕິບັດຂອງພວກເຂົາໃນ OSes ແລະ DBMSs ທີ່ແຕກຕ່າງກັນ. ໂດຍທົ່ວໄປ, ຜະລິດຕະພັນປະກອບມີ:

• Application Server Cluster, ແລ່ນໃນ Windows ແລະ Linux
• ລູກຄ້າ, ເຮັດວຽກກັບເຊີບເວີຜ່ານ http(s) ຫຼື binary protocol ຂອງຕົນເອງ, ເຮັດວຽກຢູ່ໃນ Windows, Linux, macOS
• ລູກຄ້າເວັບ, ແລ່ນຢູ່ໃນ Chrome, Internet Explorer, Microsoft Edge, Firefox, Safari browsers (ຂຽນໃນ JavaScript)
• ສະພາບແວດລ້ອມການພັດທະນາ (ຜູ້ກຳນົດຄ່າ), ເຮັດວຽກຢູ່ໃນ Windows, Linux, macOS
• ເຄື່ອງມືບໍລິຫານ ເຊີບເວີແອັບພລິເຄຊັນ, ແລ່ນໃນ Windows, Linux, macOS
• ລູກ​ຄ້າ​ມື​ຖື​, ການ​ເຊື່ອມ​ຕໍ່​ກັບ​ເຊີບ​ເວີ​ຜ່ານ http(s), ເຮັດ​ວຽກ​ກ່ຽວ​ກັບ​ອຸ​ປະ​ກອນ​ມື​ຖື​ທີ່​ແລ່ນ Android​, iOS​, Windows​
• ແພລະຕະຟອມມືຖື — ໂຄງ​ຮ່າງ​ການ​ສໍາ​ລັບ​ການ​ສ້າງ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ມື​ຖື offline ທີ່​ມີ​ຄວາມ​ສາ​ມາດ synchronize​, ແລ່ນ​ໃນ Android​, iOS​, Windows​
• ສະພາບແວດລ້ອມການພັດທະນາ 1C: ເຄື່ອງມືພັດທະນາວິສາຫະກິດ, ຂຽນໃນ Java
• Server ລະບົບການໂຕ້ຕອບ

ພວກເຮົາພະຍາຍາມຂຽນລະຫັດດຽວກັນສໍາລັບລະບົບປະຕິບັດການທີ່ແຕກຕ່າງກັນຫຼາຍເທົ່າທີ່ເປັນໄປໄດ້ - ພື້ນຖານລະຫັດເຊີຟເວີແມ່ນ 99% ທົ່ວໄປ, ພື້ນຖານລະຫັດລູກຄ້າແມ່ນປະມານ 95%. ແພລະຕະຟອມເທກໂນໂລຍີ 1C: ວິສາຫະກິດແມ່ນຂຽນເປັນຕົ້ນຕໍໃນ C ++ ແລະຄຸນລັກສະນະຂອງລະຫັດໂດຍປະມານແມ່ນໃຫ້ຂ້າງລຸ່ມນີ້:

• ລະຫັດ C++ 10 ລ້ານເສັ້ນ,
• 14 ພັນ​ໄຟລ​໌​,
• 60 ພັນ​ຫ້ອງ​ຮຽນ​,
• ເຄິ່ງ​ລ້ານ​ວິ​ທີ​ການ​.

ແລະສິ່ງທັງໝົດນີ້ຕ້ອງໄດ້ແປເປັນ C++14. ມື້​ນີ້​ພວກ​ເຮົາ​ຈະ​ບອກ​ທ່ານ​ວິ​ທີ​ການ​ທີ່​ພວກ​ເຮົາ​ໄດ້​ເຮັດ​ນີ້​ແລະ​ສິ່ງ​ທີ່​ພວກ​ເຮົາ​ພົບ​ໃນ​ຂະ​ບວນ​ການ.

ປະຕິເສດຄວາມຮັບຜິດຊອບ

ທຸກສິ່ງທຸກຢ່າງທີ່ຂຽນຂ້າງລຸ່ມນີ້ກ່ຽວກັບການເຮັດວຽກຊ້າ / ໄວ, (ບໍ່) ການບໍລິໂພກຫນ່ວຍຄວາມຈໍາຂະຫນາດໃຫຍ່ໂດຍການປະຕິບັດຫ້ອງຮຽນມາດຕະຖານໃນຫ້ອງສະຫມຸດຕ່າງໆຫມາຍຄວາມວ່າສິ່ງຫນຶ່ງ: ນີ້ແມ່ນຄວາມຈິງສໍາລັບສະຫະລັດ. ມັນເປັນໄປໄດ້ຂ້ອນຂ້າງວ່າການປະຕິບັດມາດຕະຖານຈະເຫມາະສົມທີ່ສຸດສໍາລັບວຽກງານຂອງທ່ານ. ພວກເຮົາເລີ່ມຕົ້ນຈາກວຽກງານຂອງພວກເຮົາເອງ: ພວກເຮົາເອົາຂໍ້ມູນປົກກະຕິສໍາລັບລູກຄ້າຂອງພວກເຮົາ, ດໍາເນີນການສະຖານະການປົກກະຕິກ່ຽວກັບພວກເຂົາ, ເບິ່ງການປະຕິບັດ, ຈໍານວນຫນ່ວຍຄວາມຈໍາທີ່ບໍລິໂພກ, ແລະອື່ນໆ, ແລະວິເຄາະວ່າພວກເຮົາແລະລູກຄ້າຂອງພວກເຮົາພໍໃຈກັບຜົນໄດ້ຮັບດັ່ງກ່າວຫຼືບໍ່. . ແລະພວກເຂົາປະຕິບັດຂຶ້ນກັບ.

ສິ່ງທີ່ພວກເຮົາມີ

ໃນເບື້ອງຕົ້ນ, ພວກເຮົາໄດ້ຂຽນລະຫັດສໍາລັບແພລະຕະຟອມ 1C:Enterprise 8 ໃນ Microsoft Visual Studio. ໂຄງ​ການ​ດັ່ງ​ກ່າວ​ໄດ້​ເລີ່ມ​ຕົ້ນ​ໃນ​ຕົ້ນ​ປີ 2000 ແລະ​ພວກ​ເຮົາ​ມີ​ສະ​ບັບ Windows ເທົ່າ​ນັ້ນ​. ຕາມທໍາມະຊາດ, ນັບຕັ້ງແຕ່ນັ້ນມາລະຫັດໄດ້ຖືກພັດທະນາຢ່າງຫ້າວຫັນ, ກົນໄກຫຼາຍຢ່າງໄດ້ຖືກຂຽນຄືນໃຫມ່ຢ່າງສົມບູນ. ແຕ່ລະຫັດໄດ້ຖືກຂຽນຕາມມາດຕະຖານປີ 1998, ແລະຕົວຢ່າງເຊັ່ນ, ວົງເລັບມຸມຂວາຂອງພວກເຮົາຖືກແຍກອອກໂດຍຊ່ອງຫວ່າງເພື່ອໃຫ້ການລວບລວມປະສົບຜົນສໍາເລັດ, ເຊັ່ນນີ້:

vector<vector<int> > IntV;

ໃນປີ 2006, ດ້ວຍການປ່ອຍແພລດຟອມເວີຊັ່ນ 8.1, ພວກເຮົາໄດ້ເລີ່ມຮອງຮັບ Linux ແລະປ່ຽນໄປໃຊ້ຫ້ອງສະໝຸດມາດຕະຖານພາກສ່ວນທີສາມ. STLPport. ຫນຶ່ງໃນເຫດຜົນສໍາລັບການຫັນປ່ຽນແມ່ນການເຮັດວຽກທີ່ມີສາຍກວ້າງ. ໃນລະຫັດຂອງພວກເຮົາ, ພວກເຮົາໃຊ້ std::wstring, ເຊິ່ງອີງໃສ່ປະເພດ wchar_t, ຕະຫຼອດ. ຂະຫນາດຂອງມັນຢູ່ໃນ Windows ແມ່ນ 2 bytes, ແລະໃນ Linux ຄ່າເລີ່ມຕົ້ນແມ່ນ 4 bytes. ອັນນີ້ເຮັດໃຫ້ຄວາມບໍ່ເຂົ້າກັນໄດ້ຂອງໂປຣໂຕຄອນຄູ່ຂອງພວກເຮົາລະຫວ່າງລູກຄ້າ ແລະເຊີບເວີ, ເຊັ່ນດຽວກັນກັບຂໍ້ມູນຄົງຄ້າງຕ່າງໆ. ການນໍາໃຊ້ທາງເລືອກ gcc, ທ່ານສາມາດກໍານົດວ່າຂະຫນາດຂອງ wchar_t ໃນລະຫວ່າງການລວບລວມແມ່ນ 2 bytes, ແຕ່ຫຼັງຈາກນັ້ນທ່ານສາມາດລືມກ່ຽວກັບການນໍາໃຊ້ຫ້ອງສະຫມຸດມາດຕະຖານຈາກ compiler, ເພາະວ່າ. ມັນໃຊ້ glibc, ເຊິ່ງຖືກລວບລວມສໍາລັບ wchar_t 4-byte. ເຫດຜົນອື່ນໆແມ່ນການປະຕິບັດທີ່ດີກວ່າຂອງຫ້ອງຮຽນມາດຕະຖານ, ການສະຫນັບສະຫນູນຕາຕະລາງ hash, ແລະແມ້ກະທັ້ງການຈໍາລອງຂອງ semantics ຂອງການເຄື່ອນຍ້າຍພາຍໃນບັນຈຸ, ທີ່ພວກເຮົານໍາໃຊ້ຢ່າງຈິງຈັງ. ແລະອີກເຫດຜົນຫນຶ່ງ, ຍ້ອນວ່າພວກເຂົາເວົ້າວ່າສຸດທ້າຍແຕ່ບໍ່ໄດ້ຢ່າງຫນ້ອຍ, ແມ່ນການປະຕິບັດສາຍ. ພວກເຮົາມີຫ້ອງຮຽນຂອງຕົນເອງສໍາລັບສາຍ, ເນື່ອງຈາກວ່າ ... ເນື່ອງຈາກຄວາມສະເພາະຂອງຊອບແວຂອງພວກເຮົາ, ການປະຕິບັດການສະຕຣິງຖືກນໍາໃຊ້ຢ່າງກວ້າງຂວາງແລະສໍາລັບພວກເຮົາ, ນີ້ແມ່ນສໍາຄັນ.

ສະຕຣິງຂອງພວກເຮົາແມ່ນອີງໃສ່ແນວຄວາມຄິດການເພີ່ມປະສິດທິພາບສະຕຣິງທີ່ສະແດງອອກໃນຕົ້ນຊຸມປີ 2000 Andrei Alexandrescu. ຕໍ່ມາ, ເມື່ອ Alexandrescu ເຮັດວຽກຢູ່ Facebook, ຕາມຄໍາແນະນໍາຂອງລາວ, ສາຍໄດ້ຖືກນໍາໃຊ້ໃນເຄື່ອງຈັກຂອງ Facebook ທີ່ເຮັດວຽກຢູ່ໃນຫຼັກການທີ່ຄ້າຍຄືກັນ (ເບິ່ງຫ້ອງສະຫມຸດ ໂງ່).

ສາຍຂອງພວກເຮົາໄດ້ນໍາໃຊ້ສອງເຕັກໂນໂລຢີການເພີ່ມປະສິດທິພາບຕົ້ນຕໍ:

1. ສໍາລັບຄ່າສັ້ນ, buffer ພາຍໃນໃນ string object ຕົວຂອງມັນເອງຖືກນໍາໃຊ້ (ບໍ່ຮຽກຮ້ອງໃຫ້ມີການຈັດສັນຫນ່ວຍຄວາມຈໍາເພີ່ມເຕີມ).
2. ສໍາລັບຄົນອື່ນທັງຫມົດ, ກົນຈັກຖືກນໍາໃຊ້ ສຳເນົາໃນການຂຽນ. ຄ່າສະຕຣິງຖືກເກັບໄວ້ໃນບ່ອນດຽວ, ແລະເຄື່ອງນັບອ້າງອີງຖືກໃຊ້ໃນລະຫວ່າງການມອບໝາຍ/ດັດແກ້.

ເພື່ອເລັ່ງການລວບລວມແພລະຕະຟອມ, ພວກເຮົາຍົກເວັ້ນການປະຕິບັດການຖ່າຍທອດຈາກຕົວແປ STLPport ຂອງພວກເຮົາ (ທີ່ພວກເຮົາບໍ່ໄດ້ໃຊ້), ນີ້ເຮັດໃຫ້ພວກເຮົາລວບລວມໄວຂຶ້ນປະມານ 20%. ຫຼັງຈາກນັ້ນ, ພວກເຮົາຕ້ອງໄດ້ໃຊ້ຈໍາກັດ ສະຫນັບສະຫນູນ. Boost ເຮັດໃຫ້ການນໍາໃຊ້ການຖ່າຍທອດຢ່າງຫນັກ, ໂດຍສະເພາະໃນ APIs ການບໍລິການຂອງມັນ (ຕົວຢ່າງເຊັ່ນ, ສໍາລັບການບັນທຶກ), ດັ່ງນັ້ນພວກເຮົາຕ້ອງດັດແປງມັນເພື່ອເອົາການໃຊ້ການຖ່າຍທອດອອກ. ອັນນີ້, ເຮັດໃຫ້ມັນຍາກສໍາລັບພວກເຮົາທີ່ຈະຍ້າຍໄປ Boost ຮຸ່ນໃຫມ່.

ວິທີທີສາມ

ເມື່ອຍ້າຍໄປມາດຕະຖານ C ++ 14, ພວກເຮົາໄດ້ພິຈາລະນາທາງເລືອກຕໍ່ໄປນີ້:

1. ອັບເກຣດ STLPport ທີ່ພວກເຮົາດັດແປງເປັນມາດຕະຖານ C++14. ທາງເລືອກແມ່ນມີຄວາມຫຍຸ້ງຍາກຫຼາຍ, ເພາະວ່າ ... ການສະຫນັບສະຫນູນ STLPport ໄດ້ຢຸດເຊົາໃນປີ 2010, ແລະພວກເຮົາຈະຕ້ອງສ້າງລະຫັດທັງຫມົດຂອງຕົນເອງ.
2. ການຫັນປ່ຽນໄປສູ່ການຈັດຕັ້ງປະຕິບັດ STL ອື່ນທີ່ເຂົ້າກັນໄດ້ກັບ C++14. ມັນເປັນຄວາມປາຖະຫນາສູງທີ່ການປະຕິບັດນີ້ແມ່ນສໍາລັບ Windows ແລະ Linux.
3. ເມື່ອລວບລວມສໍາລັບແຕ່ລະ OS, ໃຊ້ຫ້ອງສະຫມຸດທີ່ສ້າງຂຶ້ນໃນ compiler ທີ່ສອດຄ້ອງກັນ.

ທາງເລືອກທໍາອິດຖືກປະຕິເສດທັນທີເນື່ອງຈາກການເຮັດວຽກຫຼາຍເກີນໄປ.

ພວກເຮົາຄິດກ່ຽວກັບທາງເລືອກທີສອງສໍາລັບບາງເວລາ; ຖືວ່າເປັນຜູ້ສະໝັກ libc++, ແຕ່ໃນເວລານັ້ນມັນບໍ່ໄດ້ເຮັດວຽກພາຍໃຕ້ Windows. ເພື່ອເອົາ libc++ ໄປໃສ່ Windows, ເຈົ້າຈະຕ້ອງເຮັດວຽກຫຼາຍ - ຕົວຢ່າງ, ຂຽນທຸກຢ່າງດ້ວຍຕົນເອງທີ່ກ່ຽວຂ້ອງກັບ threads, thread synchronization ແລະ atomicity, ນັບຕັ້ງແຕ່ libc++ ໃຊ້ໃນພື້ນທີ່ເຫຼົ່ານີ້. POSIX API.

ແລະພວກເຮົາເລືອກທາງທີສາມ.

ການຫັນປ່ຽນ

ດັ່ງນັ້ນ, ພວກເຮົາຕ້ອງທົດແທນການໃຊ້ STLPort ກັບຫ້ອງສະຫມຸດຂອງ compilers ທີ່ສອດຄ້ອງກັນ (Visual Studio 2015 ສໍາລັບ Windows, gcc 7 ສໍາລັບ Linux, clang 8 ສໍາລັບ macOS).

ໂຊກດີ, ລະຫັດຂອງພວກເຮົາຖືກຂຽນເປັນສ່ວນໃຫຍ່ຕາມຄໍາແນະນໍາແລະບໍ່ໄດ້ນໍາໃຊ້ທຸກປະເພດຂອງ tricks ສະຫລາດ, ດັ່ງນັ້ນການເຄື່ອນຍ້າຍໄປຫາຫ້ອງສະຫມຸດໃຫມ່ດໍາເນີນໄປຂ້ອນຂ້າງລຽບງ່າຍ, ດ້ວຍການຊ່ວຍເຫຼືອຂອງສະຄິບທີ່ປ່ຽນແທນຊື່ປະເພດ, ຊັ້ນຮຽນ, namespaces ແລະລວມຢູ່ໃນແຫຼ່ງ. ໄຟລ໌. ການເຄື່ອນຍ້າຍສົ່ງຜົນກະທົບຕໍ່ໄຟລ໌ແຫຼ່ງ 10 (ອອກຈາກ 000). wchar_t ຖືກແທນທີ່ດ້ວຍ char14_t; ພວກເຮົາຕັດສິນໃຈທີ່ຈະປະຖິ້ມການໃຊ້ wchar_t, ເພາະວ່າ char000_t ໃຊ້ 16 ໄບຕ໌ໃນທຸກ OS ແລະບໍ່ທໍາລາຍລະຫັດເຂົ້າກັນໄດ້ລະຫວ່າງ Windows ແລະ Linux.

ມີການຜະຈົນໄພເລັກນ້ອຍ. ຕົວຢ່າງ, ໃນ STLPport ໂຕ iterator ອາດຈະຖືກໂຍນລົງໄປເປັນຕົວຊີ້ໄປຫາອົງປະກອບໃດໜຶ່ງ, ແລະໃນບາງບ່ອນໃນລະຫັດຂອງພວກເຮົານີ້ຖືກນໍາໃຊ້. ໃນຫ້ອງສະຫມຸດໃຫມ່ມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະເຮັດແນວນີ້, ແລະຂໍ້ຄວາມເຫຼົ່ານີ້ຕ້ອງໄດ້ຮັບການວິເຄາະແລະຂຽນໃຫມ່ດ້ວຍຕົນເອງ.

ດັ່ງນັ້ນ, ການເຄື່ອນຍ້າຍລະຫັດແມ່ນສໍາເລັດ, ລະຫັດຖືກລວບລວມສໍາລັບທຸກລະບົບປະຕິບັດການ. ມັນເປັນເວລາສໍາລັບການທົດສອບ.

ການທົດສອບຫຼັງຈາກການປ່ຽນແປງໄດ້ສະແດງໃຫ້ເຫັນການຫຼຸດລົງຂອງການປະຕິບັດ (ໃນບາງບ່ອນເຖິງ 20-30%) ແລະການເພີ່ມຂຶ້ນຂອງການບໍລິໂພກຫນ່ວຍຄວາມຈໍາ (ເຖິງ 10-15%) ເມື່ອທຽບກັບສະບັບເກົ່າຂອງລະຫັດ. ນີ້ແມ່ນ, ໂດຍສະເພາະ, ເນື່ອງຈາກການປະຕິບັດທີ່ດີທີ່ສຸດຂອງສາຍມາດຕະຖານ. ດັ່ງນັ້ນ, ພວກເຮົາອີກເທື່ອຫນຶ່ງຕ້ອງໃຊ້ເສັ້ນຂອງພວກເຮົາ, ດັດແກ້ເລັກນ້ອຍ.

ລັກສະນະທີ່ຫນ້າສົນໃຈຂອງການປະຕິບັດການບັນຈຸໃນຫ້ອງສະຫມຸດຝັງໄດ້ຖືກເປີດເຜີຍຍັງ: ຫວ່າງເປົ່າ (ບໍ່ມີອົງປະກອບ) std::map ແລະ std:: ກໍານົດຈາກຫ້ອງສະຫມຸດໃນຕົວຈັດສັນຫນ່ວຍຄວາມຈໍາ. ແລະເນື່ອງຈາກລັກສະນະການປະຕິບັດ, ໃນບາງບ່ອນໃນລະຫັດຂ້ອນຂ້າງຫຼາຍຂອງຖັງເປົ່າຂອງປະເພດນີ້ຖືກສ້າງຂຶ້ນ. ບັນຈຸຫນ່ວຍຄວາມຈໍາມາດຕະຖານຖືກຈັດສັນພຽງເລັກນ້ອຍ, ສໍາລັບອົງປະກອບຮາກຫນຶ່ງ, ແຕ່ສໍາລັບພວກເຮົານີ້ໄດ້ກາຍເປັນຄວາມສໍາຄັນ - ໃນຫຼາຍໆສະຖານະການ, ການປະຕິບັດຂອງພວກເຮົາຫຼຸດລົງຢ່າງຫຼວງຫຼາຍແລະການບໍລິໂພກຫນ່ວຍຄວາມຈໍາເພີ່ມຂຶ້ນ (ເມື່ອປຽບທຽບກັບ STLPort). ດັ່ງນັ້ນ, ໃນລະຫັດຂອງພວກເຮົາພວກເຮົາໄດ້ປ່ຽນສອງປະເພດຂອງບັນຈຸເຫຼົ່ານີ້ຈາກຫ້ອງສະຫມຸດທີ່ສ້າງຂຶ້ນດ້ວຍການປະຕິບັດຂອງພວກເຂົາຈາກ Boost, ບ່ອນທີ່ບັນຈຸເຫຼົ່ານີ້ບໍ່ມີຄຸນສົມບັດນີ້, ແລະນີ້ແກ້ໄຂບັນຫາດ້ວຍການຊ້າລົງແລະການບໍລິໂພກຄວາມຈໍາເພີ່ມຂຶ້ນ.

ດັ່ງທີ່ມັກຈະເກີດຂື້ນຫຼັງຈາກການປ່ຽນແປງຂະຫນາດໃຫຍ່ໃນໂຄງການຂະຫນາດໃຫຍ່, ການ iteration ຄັ້ງທໍາອິດຂອງລະຫັດແຫຼ່ງບໍ່ໄດ້ເຮັດວຽກໂດຍບໍ່ມີບັນຫາ, ແລະໃນທີ່ນີ້, ໂດຍສະເພາະ, ການສະຫນັບສະຫນູນສໍາລັບ debugging iterators ໃນການປະຕິບັດ Windows ແມ່ນມີປະໂຫຍດ. ພວກເຮົາກ້າວໄປຂ້າງໜ້າ, ແລະໃນລະດູໃບໄມ້ປົ່ງຂອງປີ 2017 (ເວີຊັນ 8.3.11 1C:Enterprise) ການເຄື່ອນຍ້າຍໄດ້ສຳເລັດແລ້ວ.

ຜົນໄດ້ຮັບ

ການຫັນປ່ຽນໄປສູ່ມາດຕະຖານ C ++14 ໄດ້ໃຊ້ເວລາປະມານ 6 ເດືອນ. ສ່ວນໃຫຍ່ຂອງເວລາ, ຜູ້ພັດທະນາຫນຶ່ງ (ແຕ່ມີຄຸນວຸດທິສູງຫຼາຍ) ໄດ້ເຮັດວຽກກ່ຽວກັບໂຄງການ, ແລະໃນຂັ້ນຕອນສຸດທ້າຍຜູ້ຕາງຫນ້າຂອງທີມງານທີ່ຮັບຜິດຊອບສໍາລັບພື້ນທີ່ສະເພາະເຂົ້າຮ່ວມ - UI, ກຸ່ມເຄື່ອງແມ່ຂ່າຍ, ການພັດທະນາແລະເຄື່ອງມືບໍລິຫານ, ແລະອື່ນໆ.

ການຫັນປ່ຽນເຮັດໃຫ້ວຽກງານຂອງພວກເຮົາມີຄວາມງ່າຍດາຍຫຼາຍໃນການເຄື່ອນຍ້າຍໄປສູ່ມາດຕະຖານຮຸ່ນຫຼ້າສຸດ. ດັ່ງນັ້ນ, ຮຸ່ນ 1C:Enterprise 8.3.14 (ຢູ່ໃນການພັດທະນາ, ການປ່ອຍທີ່ກໍານົດສໍາລັບຕົ້ນປີຫນ້າ) ໄດ້ຖືກໂອນໄປສູ່ມາດຕະຖານແລ້ວ. C++17.

ຫຼັງຈາກການເຄື່ອນຍ້າຍ, ນັກພັດທະນາມີທາງເລືອກຫຼາຍຂຶ້ນ. ຖ້າກ່ອນຫນ້ານີ້ພວກເຮົາມີສະບັບດັດແກ້ຂອງຕົນເອງຂອງ STL ແລະຫນຶ່ງ std namespace, ໃນປັດຈຸບັນພວກເຮົາມີຫ້ອງຮຽນມາດຕະຖານຈາກຫ້ອງສະຫມຸດ compiler ທີ່ມີການກໍ່ສ້າງໃນ std namespace, ໃນ namespace stdx - ສາຍແລະ containers ຂອງພວກເຮົາ optimized ສໍາລັບວຽກງານຂອງພວກເຮົາ, ໃນ boost - the ຮຸ່ນຫຼ້າສຸດຂອງ boost. ແລະຜູ້ພັດທະນາໃຊ້ຫ້ອງຮຽນເຫຼົ່ານັ້ນທີ່ເຫມາະສົມທີ່ສຸດເພື່ອແກ້ໄຂບັນຫາຂອງລາວ.

ການປະຕິບັດ "ພື້ນເມືອງ" ຂອງຜູ້ກໍ່ສ້າງການເຄື່ອນໄຫວຍັງຊ່ວຍໃນການພັດທະນາ (ຍ້າຍຜູ້ກໍ່ສ້າງ) ສໍາ​ລັບ​ຈໍາ​ນວນ​ຂອງ​ຫ້ອງ​ຮຽນ​. ຖ້າຫ້ອງຮຽນມີຕົວສ້າງຍ້າຍແລະຊັ້ນນີ້ຖືກຈັດໃສ່ໃນຖັງ, ຫຼັງຈາກນັ້ນ STL ເພີ່ມປະສິດທິພາບການຄັດລອກອົງປະກອບພາຍໃນຖັງ (ຕົວຢ່າງ, ເມື່ອຕູ້ຄອນເທນເນີຖືກຂະຫຍາຍແລະມັນຈໍາເປັນຕ້ອງປ່ຽນຄວາມອາດສາມາດແລະການຈັດສັນຫນ່ວຍຄວາມຈໍາຄືນໃຫມ່).

ບ່ວງ tar

ບາງທີຜົນສະທ້ອນທີ່ບໍ່ດີທີ່ສຸດ (ແຕ່ບໍ່ສໍາຄັນ) ຂອງການຍົກຍ້າຍແມ່ນພວກເຮົາປະເຊີນກັບການເພີ່ມຂຶ້ນຂອງປະລິມານ. ໄຟລ໌ obj, ແລະຜົນໄດ້ຮັບອັນເຕັມທີ່ຂອງການກໍ່ສ້າງກັບໄຟລ໌ກາງທັງຫມົດໄດ້ເລີ່ມຕົ້ນທີ່ຈະເອົາເຖິງ 60-70 GB. ພຶດຕິກໍານີ້ແມ່ນເນື່ອງມາຈາກ peculiarities ຂອງຫ້ອງສະຫມຸດມາດຕະຖານທີ່ທັນສະໄຫມ, ເຊິ່ງໄດ້ກາຍເປັນຄວາມສໍາຄັນຫນ້ອຍຂອງຂະຫນາດຂອງໄຟລ໌ການບໍລິການທີ່ສ້າງຂຶ້ນ. ນີ້ບໍ່ມີຜົນກະທົບຕໍ່ການດໍາເນີນງານຂອງຄໍາຮ້ອງສະຫມັກທີ່ລວບລວມ, ແຕ່ມັນເຮັດໃຫ້ເກີດຄວາມບໍ່ສະດວກໃນການພັດທະນາ, ໂດຍສະເພາະ, ມັນເພີ່ມເວລາການລວບລວມ. ຄວາມຕ້ອງການສໍາລັບພື້ນທີ່ດິສກ໌ຟຣີໃນເຊີບເວີສ້າງແລະໃນເຄື່ອງຂອງນັກພັດທະນາກໍ່ເພີ່ມຂຶ້ນ. ນັກພັດທະນາຂອງພວກເຮົາເຮັດວຽກຢູ່ໃນຫຼາຍຮຸ່ນຂອງແພລະຕະຟອມຂະຫນານ, ແລະຫຼາຍຮ້ອຍ gigabyte ຂອງໄຟລ໌ກາງບາງຄັ້ງກໍ່ສ້າງຄວາມຫຍຸ້ງຍາກໃນການເຮັດວຽກຂອງພວກເຂົາ. ບັນຫາແມ່ນບໍ່ພໍໃຈ, ແຕ່ບໍ່ສໍາຄັນ; ພວກເຮົາໄດ້ເລື່ອນການແກ້ໄຂບັນຫາຂອງມັນສໍາລັບຕອນນີ້. ພວກເຮົາກໍາລັງພິຈາລະນາເຕັກໂນໂລຢີເປັນຫນຶ່ງໃນທາງເລືອກໃນການແກ້ໄຂບັນຫາ ສ້າງຄວາມສາມັກຄີ (ໂດຍສະເພາະ, Google ໃຊ້ມັນໃນເວລາທີ່ພັດທະນາຕົວທ່ອງເວັບ Chrome).

ແຫຼ່ງຂໍ້ມູນ: www.habr.com