اسان C++ ڪوڊ جون 10 ملين لائينون ڪيئن ترجمو ڪيون C++ 14 معيار ۾ (۽ پوءِ C++17)

ڪجهه وقت اڳ (2016 جي زوال ۾)، 1C جي ايندڙ ورزن جي ترقي دوران: انٽرپرائز ٽيڪنالاجي پليٽ فارم، سوال پيدا ٿيو ترقياتي ٽيم جي اندر نئين معيار جي حمايت ڪرڻ بابت سي ++ 14 اسان جي ڪوڊ ۾. نئين معيار ڏانهن منتقلي، جيئن اسان فرض ڪيو، اسان کي اجازت ڏيندو ته ڪيتريون ئي شيون وڌيڪ خوبصورت، سادو ۽ قابل اعتماد انداز سان، ۽ ڪوڊ جي مدد ۽ سار سنڀال کي آسان بڻائي. ۽ لڳي ٿو ته ترجمي ۾ ڪجھ به غير معمولي نه آھي، جيڪڏھن نه ته ڪوڊ بيس جي ماپ ۽ اسان جي ڪوڊ جي مخصوص خصوصيتن لاءِ.

انهن لاءِ جيڪي نه ٿا ڄاڻن، 1C:Enterprise هڪ اهڙو ماحول آهي جيڪو ڪراس پليٽ فارم ڪاروباري ايپليڪيشنن جي تيزيءَ سان ترقي ڪري ٿو ۽ مختلف OS ۽ DBMSs تي انهن جي عمل لاءِ رن ٽائيم. عام اصطلاحن ۾، پيداوار تي مشتمل آهي:

• ايپليڪيشن سرور ڪلستر، ونڊوز ۽ لينڪس تي هلندو آهي
• ڪسٽمر, سرور سان ڪم ڪندي http(s) يا ان جي پنهنجي بائنري پروٽوڪول ذريعي، ڪم ڪري ٿو ونڊوز، لينڪس، macOS تي
• ويب ڪلائنٽ, Chrome ۾ هلندڙ, Internet Explorer, Microsoft Edge, Firefox, Safari برائوزر (JavaScript ۾ لکيل)
• ترقي ماحول (ترتيب ڏيڻ وارو)، ونڊوز، لينڪس، macOS تي ڪم ڪري ٿو
• انتظامي اوزار ايپليڪيشن سرورز، ونڊوز، لينڪس، macOS تي هلن ٿا
• موبائل ڪلائنٽ, http(s) ذريعي سرور سان ڳنڍڻ، Android، iOS، ونڊوز تي هلندڙ موبائل ڊوائيسز تي ڪم ڪري ٿو
• موبائل پليٽ فارم - هڪ فريم ورڪ آف لائن موبائيل ايپليڪيشنون ٺاهڻ لاءِ هم وقت سازي ڪرڻ جي صلاحيت سان، Android، iOS، ونڊوز تي هلندڙ
• ترقي ماحول 1C: انٽرپرائز ڊولپمينٽ جا اوزارجاوا ۾ لکيل آهي
• سرور رابطي جو نظام

اسان ڪوشش ڪريون ٿا ته جيترو ٿي سگهي ساڳيو ڪوڊ مختلف آپريٽنگ سسٽم لاءِ لکجي - سرور ڪوڊ جو بنياد 99٪ عام آهي، ڪلائنٽ ڪوڊ جو بنياد تقريباً 95٪ آهي. 1C: انٽرپرائز ٽيڪنالاجي پليٽ فارم بنيادي طور تي C++ ۾ لکيل آهي ۽ تقريبن ڪوڊ خاصيتون هيٺ ڏنل آهن:

• C++ ڪوڊ جون 10 ملين لائينون،
• 14 هزار فائلون،
• 60 هزار ڪلاس،
• اڌ ملين طريقا.

۽ هي سڀ شيون سي ++ 14 ۾ ترجمو ٿيڻ گهرجن. اڄ اسين توهان کي ٻڌائينداسين ته اسان اهو ڪيئن ڪيو ۽ اسان ان عمل ۾ ڇا ڪيو.

رد ڪرڻ

سست/تيز ڪم جي باري ۾ هيٺ ڏنل هر شيءِ، (نه) مختلف لائبريرين ۾ معياري ڪلاسن جي نفاذ سان وڏي ياداشت جي استعمال جو مطلب هڪ شيءِ آهي: اهو آمريڪا لاءِ صحيح آهي. اهو بلڪل ممڪن آهي ته معياري عمل درآمد توهان جي ڪمن لاءِ مناسب هوندا. اسان پنهنجي ڪمن کان شروع ڪيو: اسان ڊيٽا ورتي جيڪا اسان جي ڪلائنٽ لاءِ عام هئي، انهن تي عام منظرنامو هليو، ڪارڪردگي کي ڏٺو، استعمال ڪيل ميموري جي مقدار وغيره، ۽ تجزيو ڪيو ته ڇا اسان ۽ اسان جا گراهڪ اهڙن نتيجن کان مطمئن هئا يا نه. . ۽ انهن تي منحصر عمل ڪيو.

جيڪو اسان وٽ هو

شروعات ۾، اسان Microsoft Visual Studio ۾ 1C:Enterprise 8 پليٽ فارم لاءِ ڪوڊ لکيو. پروجيڪٽ 2000 جي شروعات ۾ شروع ٿيو ۽ اسان وٽ صرف ونڊوز ورزن هو. قدرتي طور، ان کان پوء ڪوڊ فعال طور تي ترقي ڪئي وئي آهي، ڪيترن ئي ميڪانيزم کي مڪمل طور تي ٻيهر لکيو ويو آهي. پر ڪوڊ 1998 جي معيار جي مطابق لکيو ويو، ۽ مثال طور، اسان جي ساڄي زاويه بریکٹ کي خالن سان الڳ ڪيو ويو ته جيئن تاليف ڪامياب ٿئي، جهڙوڪ:

vector<vector<int> > IntV;

2006 ۾، پليٽ فارم ورزن 8.1 جي رليز سان، اسان لينڪس کي سپورٽ ڪرڻ شروع ڪيو ۽ ٽئين پارٽي جي معياري لائبريري ۾ تبديل ڪيو. ايس ٽي ايل پورٽ. منتقلي جي سببن مان هڪ وسيع لائينن سان ڪم ڪرڻ هو. اسان جي ڪوڊ ۾، اسان std::wstring استعمال ڪندا آهيون، جيڪو سڄي wchar_t قسم تي ٻڌل آهي. ونڊوز ۾ ان جي سائيز 2 بائيٽ آهي، ۽ لينڪس ۾ ڊفالٽ 4 بائيٽ آهي. انهي جي نتيجي ۾ اسان جي بائنري پروٽوڪول جي ڪلائنٽ ۽ سرور جي وچ ۾، انهي سان گڏ مختلف مسلسل ڊيٽا. gcc اختيارن کي استعمال ڪندي، توھان بيان ڪري سگھو ٿا ته wchar_t جي سائيز پڻ 2 بائيٽ آھي، پر پوء توھان وساري سگھوٿا ڪمپلر مان معياري لائبريري استعمال ڪرڻ جي باري ۾، ڇاڪاڻ ته اهو glibc استعمال ڪري ٿو، جنهن جي نتيجي ۾ 4-byte wchar_t لاء مرتب ڪيو ويو آهي. ٻيا سبب معياري طبقن جي بهتر عمل درآمد، هيش جدولن جي مدد، ۽ ڪنٽينرز جي اندر منتقل ٿيڻ جي سيمينٽڪس جي ايميليشن، جن کي اسان فعال طور تي استعمال ڪيو. ۽ هڪ وڌيڪ سبب، جيئن اهي چون ٿا آخري نه پر گهٽ ۾ گهٽ، اسٽرنگ ڪارڪردگي هئي. تارن لاءِ اسان جو پنهنجو ڪلاس هو، ڇاڪاڻ ته... اسان جي سافٽ ويئر جي خاصيتن جي ڪري، اسٽرنگ آپريشن تمام وڏي پيماني تي استعمال ڪيا ويا آهن ۽ اسان لاء هي نازڪ آهي.

اسان جو اسٽرنگ 2000 جي شروعات ۾ بيان ڪيل اسٽرنگ جي اصلاح جي خيالن تي ٻڌل آهي آندري اليگزينڊريسڪو. بعد ۾، جڏهن اليگزينڊريسڪو فيسبوڪ تي ڪم ڪيو، ته سندس تجويز تي، فيس بوڪ انجڻ ۾ هڪ لائين استعمال ڪئي وئي جيڪا ساڳي اصولن تي ڪم ڪندي هئي (ڏسو لائبريري حماقت).

اسان جي لائن ٻن مکيه اصلاح ٽيڪنالاجيون استعمال ڪيو:

1. مختصر قدرن لاءِ، اسٽرنگ اعتراض ۾ هڪ اندروني بفر استعمال ڪيو ويندو آهي (اضافي ميموري مختص ڪرڻ جي ضرورت ناهي).
2. ٻين سڀني لاء، ميڪيڪل استعمال ڪيا ويا آهن ڪاپي تي لکو. اسٽرنگ جي قيمت ھڪڙي جڳھ ۾ ذخيرو ٿيل آھي، ۽ ھڪڙي ريفرنس ڪاؤنٽر استعمال ڪيو ويندو آھي تفويض / ترميم دوران.

پليٽ فارم جي تاليف کي تيز ڪرڻ لاءِ، اسان پنهنجي STLPort variant (جنهن کي اسان استعمال نه ڪيو) مان اسٽريم جي عمل درآمد کي خارج ڪيو، هن اسان کي اٽڪل 20 سيڪڙو تيز تاليف ڏنو. ان کان پوء اسان کي محدود استعمال ڪرڻو پيو فروغ. بوسٽ اسٽريم جو بھاري استعمال ڪري ٿو، خاص طور تي ان جي سروس APIs ۾ (مثال طور، لاگنگ لاءِ)، تنھنڪري اسان کي ان کي تبديل ڪرڻو پيو ته اسٽريم جي استعمال کي ختم ڪرڻ لاءِ. اهو، موڙ ۾، اسان لاء Boost جي نئين نسخن ڏانهن لڏپلاڻ ڪرڻ ڏکيو ٿي ويو.

ٽيون رستو

جڏهن C++ 14 معيار ڏانهن منتقل ٿيو، اسان هيٺ ڏنل اختيارن تي غور ڪيو:

1. STLPport کي اپڊيٽ ڪيو اسان C++ 14 معيار ۾ تبديل ڪيو. اختيار تمام ڏکيو آهي، ڇاڪاڻ ته ... STLPport لاءِ سپورٽ 2010 ۾ بند ڪئي وئي، ۽ اسان کي ان جو سمورو ڪوڊ پاڻ ٺاهڻو پوندو.
2. C++ 14 سان مطابقت رکندڙ ٻئي STL تي عمل درآمد. اهو انتهائي گهربل آهي ته اهو عمل ونڊوز ۽ لينڪس لاءِ هجي.
3. جڏهن هر OS لاءِ گڏ ڪرڻ، لاڳاپيل ڪمپلر ۾ ٺهيل لائبريري استعمال ڪريو.

پهرين اختيار کي تمام گهڻو ڪم ڪرڻ جي ڪري رد ڪيو ويو.

اسان ڪجهه وقت لاءِ ٻئي آپشن بابت سوچيو؛ اميدوار طور سمجهيو ويندو libc++، پر ان وقت اهو ونڊوز جي تحت ڪم نه ڪندو هو. libc++ کي ونڊوز ڏانهن پورٽ ڪرڻ لاءِ، توهان کي تمام گهڻو ڪم ڪرڻو پوندو - مثال طور، هر شي پاڻ لکو جنهن جو تعلق ٿريڊ، ٿريڊ سنڪرونائيزيشن ۽ ايٽمي سان آهي، ڇو ته libc++ انهن علائقن ۾ استعمال ٿيندو آهي. POSIX API.

۽ اسان ٽيون رستو چونڊيو.

منتقلي

تنهن ڪري، اسان کي STLPort جي استعمال کي لاڳاپيل ڪمپلرز جي لائبريرين سان تبديل ڪرڻو پوندو (ونڊوز لاء Visual Studio 2015، Linux لاء gcc 7، macOS لاء ڪلنگ 8).

خوشقسمتيءَ سان، اسان جو ڪوڊ بنيادي طور تي ھدايتن جي مطابق لکيل ھو ۽ ان ۾ ھر قسم جون چالاڪ چالون استعمال نه ڪيون ويون، تنھنڪري نون لائبريرين ڏانھن لڏپلاڻ نسبتاً آسان ٿي، لکت جي مدد سان، جنھن ۾ قسم، طبقن، نالن جي جڳھن ۽ ماخذن جا نالا تبديل ڪيا ويا. فائلون. لڏپلاڻ 10 ماخذ فائلن کي متاثر ڪيو (000 مان). wchar_t کي تبديل ڪيو ويو char14_t؛ اسان wchar_t جي استعمال کي ڇڏي ڏيڻ جو فيصلو ڪيو، ڇاڪاڻ ته char000_t سڀني او ايسز تي 16 بائيٽ وٺندو آهي ۽ ونڊوز ۽ لينڪس جي وچ ۾ ڪوڊ مطابقت خراب نٿو ڪري.

اتي ڪي ننڍيون وڏيون سرگرميون هيون. مثال طور، STLPport ۾ هڪ آئٽرٽر واضح طور تي هڪ عنصر ڏانهن اشارو ڪري سگهجي ٿو، ۽ اسان جي ڪوڊ ۾ ڪجهه هنڌن تي اهو استعمال ڪيو ويو آهي. نون لائبريرين ۾ اهو ڪرڻ ممڪن نه رهيو هو، ۽ انهن پاسن کي هٿ سان تجزيو ۽ ٻيهر لکڻو پوندو هو.

تنهن ڪري، ڪوڊ لڏپلاڻ مڪمل آهي، ڪوڊ سڀني آپريٽنگ سسٽم لاء مرتب ڪيو ويو آهي. اهو امتحانن جو وقت آهي.

منتقلي کان پوءِ ٽيسٽ ڏيکاريو ڪارڪردگي ۾ گهٽتائي (ڪجهه هنڌن تي 20-30٪ تائين) ۽ ميموري جي استعمال ۾ اضافو (10-15٪ تائين) ڪوڊ جي پراڻي ورزن جي مقابلي ۾. اهو هو، خاص طور تي، معياري تارن جي ذيلي بهتر ڪارڪردگي جي ڪري. تنهن ڪري، اسان کي ٻيهر استعمال ڪرڻو پيو اسان جي پنهنجي، ٿوري تبديل ٿيل لائين.

شامل ٿيل لائبريرين ۾ ڪنٽينرز جي عمل جي هڪ دلچسپ خصوصيت پڻ ظاهر ڪئي وئي: خالي (عناصر کان سواء) std::map ۽ std:: بلٽ ان لائبريرين مان سيٽ ميموري مختص. ۽ عمل جي خاصيتن جي ڪري، ڪوڊ ۾ ڪجهه هنڌن تي هن قسم جا ڪافي خالي ڪنٽينرز ٺاهيا ويا آهن. معياري ميموري ڪنٽينرز ٿورو مختص ڪيا ويا آهن، هڪ روٽ عنصر لاء، پر اسان لاء اهو نازڪ ٿي ويو - ڪيترن ئي منظرنامن ۾، اسان جي ڪارڪردگي خاص طور تي گهٽجي وئي ۽ ياداشت جي استعمال ۾ اضافو ٿيو (STLPort جي مقابلي ۾). تنهن ڪري، اسان جي ڪوڊ ۾ اسان انهن ٻن قسمن جي ڪنٽينرز کي بلٽ ان لائبريرين مان تبديل ڪيو آهي انهن جي بوسٽ تي عمل درآمد سان، جتي انهن ڪنٽينرز ۾ اها خاصيت نه هئي، ۽ اهو مسئلو سست ٿيڻ ۽ ميموري جي استعمال ۾ واڌ سان حل ڪيو.

جيئن ته عام طور تي وڏي منصوبن ۾ وڏي پيماني تي تبديلين کان پوء ٿيندي آهي، ماخذ ڪوڊ جي پهرين ورهاڱي کان سواء ڪم نه ڪيو، ۽ هتي، خاص طور تي، ونڊوز تي عمل درآمد ۾ ڊيبگنگ آئٽرٽرز لاء مدد هٿ ۾ آئي. قدم بہ قدم اسان اڳتي وڌياسين، ۽ 2017 جي بهار تائين (نسخ 8.3.11 1C:Enterprise) لڏپلاڻ مڪمل ٿي وئي.

نتيجو

C++ 14 معيار جي منتقلي اسان کي اٽڪل 6 مهينا ورتو. اڪثر وقت، هڪ (پر تمام اعليٰ قابل) ڊولپر پروجيڪٽ تي ڪم ڪيو، ۽ آخري مرحلي ۾ مخصوص علائقن جي ذميوار ٽيمن جا نمائندا شامل ٿيا - UI، سرور ڪلسٽر، ڊولپمينٽ ۽ انتظامي اوزار، وغيره.

منتقلي اسان جي ڪم کي معياري جي جديد نسخن ڏانهن منتقل ڪرڻ تي تمام گهڻو آسان ڪيو. اهڙيء طرح، نسخو 1C: انٽرپرائز 8.3.14 (ترقي ۾، ايندڙ سال جي شروعات لاء جاري ڪيل شيڊول) اڳ ۾ ئي معياري ڏانهن منتقل ڪيو ويو آهي سي++17.

لڏپلاڻ کان پوء، ڊولپرز وٽ وڌيڪ اختيار آهن. جيڪڏهن اڳ ۾ اسان وٽ STL جو پنهنجو تبديل ٿيل نسخو ۽ هڪ std namespace هوندو هو، ته هاڻي اسان وٽ std namespace، stdx namespace ۾ ٺهيل ڪمپيلر لائبريريءَ مان معياري ڪلاسز آهن- اسان جون لائينون ۽ ڪنٽينر اسان جي ڪمن لاءِ بهتر ڪيا ويا آهن، واڌاري ۾. واڌاري جو جديد نسخو. ۽ ڊولپر انهن طبقن کي استعمال ڪري ٿو جيڪي هن جي مسئلن کي حل ڪرڻ لاء مناسب آهن.

حرڪت جي تعمير ڪندڙن جي "مقامي" تي عملدرآمد پڻ ترقي ۾ مدد ڪري ٿو (تعمير ڪندڙن کي منتقل ڪريو) ڪيترن ئي طبقن لاء. جيڪڏهن هڪ طبقي ۾ هڪ حرڪت وارو تعمير ڪندڙ آهي ۽ اهو طبقو هڪ ڪنٽينر ۾ رکيل آهي، پوء STL ڪنٽينر جي اندر عناصر جي نقل کي بهتر بڻائي ٿو (مثال طور، جڏهن ڪنٽينر کي وڌايو ويندو آهي ۽ اهو ضروري آهي ته ظرفيت کي تبديل ڪرڻ ۽ ياداشت کي ٻيهر بحال ڪرڻ).

تارن جو هڪ چمچو

شايد لڏپلاڻ جو سڀ کان وڌيڪ ناپسنديده (پر نازڪ نه) نتيجو اهو آهي ته اسان کي حجم ۾ واڌ سان منهن ڏيڻو پوي ٿو. obj فائلون، ۽ سڀني وچولي فائلن سان تعمير جو پورو نتيجو 60-70 GB تائين وٺڻ شروع ڪيو. اهو رويو جديد معياري لائبريرين جي خاصيتن جي ڪري آهي، جيڪي ٺاهيل سروس فائلن جي سائيز کان گهٽ نازڪ ٿي چڪا آهن. اهو مرتب ٿيل ايپليڪيشن جي آپريشن کي متاثر نٿو ڪري، پر اهو ترقي ۾ ڪيتريون ئي تڪليفون پيدا ڪري ٿو، خاص طور تي، اهو تاليف جو وقت وڌائي ٿو. بلڊ سرورز ۽ ڊولپر مشينن تي مفت ڊسڪ اسپيس جون گهرجون پڻ وڌي رهيون آهن. اسان جا ڊولپر متوازي پليٽ فارم جي ڪيترن ئي ورزن تي ڪم ڪن ٿا، ۽ سوين گيگا بائيٽ وچولي فائلون ڪڏهن ڪڏهن انهن جي ڪم ۾ مشڪلاتون پيدا ڪن ٿيون. مسئلو ناخوشگوار آهي، پر نازڪ ناهي؛ اسان هن وقت تائين ان جو حل ملتوي ڪيو آهي. اسان ٽيڪنالاجي کي حل ڪرڻ جي اختيارن مان هڪ سمجهي رهيا آهيون اتحاد جي تعمير (خاص طور تي، گوگل ان کي استعمال ڪري ٿو جڏهن Chrome برائوزر کي ترقي ڪندي).

جو ذريعو: www.habr.com