څنګه موږ د C++ 10 معیاري (او بیا C++ 14 ته) ته د C++ کوډ 17 ملیون لاینونه وژباړل

یو څه وخت دمخه (د 2016 په مني کې) ، د 1C: د سوداګرۍ ټیکنالوژۍ پلیټ فارم راتلونکي نسخې پراختیا پرمهال ، د نوي معیار ملاتړ کولو په اړه د پراختیایی ټیم دننه پوښتنه راپورته شوه C ++ 14 زموږ په کوډ کې. نوي معیار ته لیږد، لکه څنګه چې موږ فکر کاوه، موږ ته اجازه راکوي چې ډیری شیان په ډیر ښکلي، ساده او باوري توګه ولیکئ، او د کوډ ملاتړ او ساتنه به ساده کړي. او داسې بریښي چې په ژباړه کې هیڅ غیر معمولي شتون نلري ، که نه د کوډ بیس پیمانه او زموږ د کوډ ځانګړي ځانګړتیاو لپاره.

د هغو کسانو لپاره چې نه پوهیږي، 1C: تصدۍ د کراس پلیټ فارم سوداګرۍ غوښتنلیکونو ګړندۍ پراختیا لپاره چاپیریال دی او په مختلف OS او DBMSs کې د دوی اجرا کولو لپاره د وخت وخت دی. په عمومي توګه، محصول په لاندې ډول دي:

موږ هڅه کوو د امکان تر حده د مختلف عملیاتي سیسټمونو لپاره ورته کوډ ولیکئ - د سرور کوډ اساس 99٪ عام دی ، د پیرودونکي کوډ اساس شاوخوا 95٪ دی. 1C: د تصدۍ ټیکنالوژۍ پلیټ فارم اساسا په C++ کې لیکل شوی او نږدې کوډ ځانګړتیاوې لاندې ورکړل شوي:

  • د C++ کوډ 10 ملیونه لاینونه،
  • 14 زره فایلونه
  • 60 زره ټولګي،
  • نیم ملیون میتودونه.

او دا ټول توکي باید په C++ 14 کې ژباړل شوي وي. نن ورځ موږ به تاسو ته ووایو چې موږ دا څنګه ترسره کړل او موږ په پروسه کې څه سره مخ شو.

څنګه موږ د C++ 10 معیاري (او بیا C++ 14 ته) ته د C++ کوډ 17 ملیون لاینونه وژباړل

ردول

هر څه چې د سست / ګړندي کار په اړه لاندې لیکل شوي ، (نه) په مختلف کتابتونونو کې د معیاري ټولګیو پلي کولو لخوا د لوی حافظې مصرف یو شی معنی لري: دا د متحده ایالاتو لپاره ریښتیا ده. دا خورا ممکنه ده چې معیاري پلي کول به ستاسو د دندو لپاره غوره وي. موږ د خپلو دندو څخه پیل وکړ: موږ هغه معلومات ترلاسه کړل چې زموږ د پیرودونکو لپاره عادي وو، په دوی باندې یې عادي سناریوګانې چلولې، فعالیت ته یې کتل، د مصرف شوي حافظې مقدار، او داسې نور، او تحلیل یې کړل چې ایا موږ او زموږ پیرودونکي د دې پایلو څخه راضي یو که نه. . او دوی په دې اړه عمل وکړ.

هغه څه چې موږ درلودل

په پیل کې، موږ د 1C لپاره کوډ لیکلی: د مایکروسافټ ویژول سټوډیو کې د شرکت 8 پلیټ فارم. پروژه د 2000 لسیزې په لومړیو کې پیل شوه او موږ یوازې د وینډوز نسخه درلوده. په طبیعي توګه، له هغه وخت راهیسې کوډ په فعاله توګه رامینځته شوی، ډیری میکانیزمونه په بشپړه توګه بیا لیکل شوي. مګر کوډ د 1998 معیار سره سم لیکل شوی و، او د بیلګې په توګه، زموږ د ښي زاویه بریکٹونه د ځایونو لخوا جلا شوي ترڅو تالیف بریالی شي، لکه:

vector<vector<int> > IntV;

په 2006 کې، د پلیټ فارم نسخه 8.1 په خپرولو سره، موږ د لینکس ملاتړ پیل کړ او د دریمې ډلې معیاري کتابتون ته مو واړوو. STLPport. د لیږد یو دلیل د پراخو لینونو سره کار کول وو. زموږ په کوډ کې، موږ std::wstring کاروو، کوم چې د wchar_t ډول پر بنسټ والړ دی. په وینډوز کې یې اندازه 2 بایټه ده، او په لینوکس کې ډیفالټ 4 بایټس دی. دا د مراجعینو او سرور تر مینځ زموږ د بائنری پروتوکولونو غیر مطابقت لامل شوی، په بیله بیا مختلف دوامداره ډاټا. د gcc اختیارونو په کارولو سره ، تاسو کولی شئ مشخص کړئ چې د تالیف پرمهال د wchar_t اندازه هم 2 بایټه ده ، مګر بیا تاسو کولی شئ د تالیف کونکي څخه د معیاري کتابتون کارولو په اړه هیر کړئ ، ځکه چې دا glibc کاروي، کوم چې په پایله کې د 4-بایټ wchar_t لپاره ترتیب شوی. نور لاملونه د معیاري ټولګیو غوره پلي کول ، د هش میزونو ملاتړ ، او حتی د کانټینرونو دننه حرکت کولو سیمانټیکونو تقلید و ، کوم چې موږ په فعاله توګه کارولی. او یو بل دلیل ، لکه څنګه چې دوی وروستی وایی مګر لږترلږه ، د تار فعالیت و. موږ د تارونو لپاره خپل ټولګی درلود، ځکه چې ... زموږ د سافټویر د ځانګړتیاوو له امله، د سټینګ عملیات خورا پراخه کارول کیږي او زموږ لپاره دا خورا مهم دی.

زموږ تار د تار اصلاح کولو نظرونو پراساس دی چې د 2000s په لومړیو کې څرګند شوي اندری الکساندرسکو. وروسته، کله چې الکساندریسکو په فیسبوک کې کار وکړ، د هغه په ​​​​وړاندې، د فیسبوک انجن کې یوه کرښه وکارول شوه چې په ورته اصولو کار کوي (کتابتون وګورئ حماقت).

زموږ لاین دوه اصلي اصلاح کولو ټیکنالوژي کارولې:

  1. د لنډو ارزښتونو لپاره، پخپله د تار څیز کې داخلي بفر کارول کیږي (د اضافي حافظې تخصیص ته اړتیا نلري).
  2. د نورو ټولو لپاره، میخانیک کارول کیږي په لیکلو کې کاپي کړئ. د تار ارزښت په یو ځای کې زیرمه شوی، او د حوالې کاونټر د دندې / تعدیل پرمهال کارول کیږي.

د پلیټ فارم تالیف ګړندي کولو لپاره ، موږ زموږ د STLPport ډول څخه د جریان پلي کول خارج کړل (کوم چې موږ نه و کارولی) ، دې موږ ته شاوخوا 20٪ ګړندی تالیف راکړ. وروسته بیا موږ باید محدود استعمال وکړو د بست. بوسټ د جریان ډیره ګټه پورته کوي ، په ځانګړي توګه د دې خدماتو APIs کې (د مثال په توګه ، د ننوتلو لپاره) ، نو موږ باید دا د جریان کارولو لرې کولو لپاره تعدیل کړو. دا، په بدل کې، زموږ لپاره د بوسټ نوي نسخو ته مهاجرت ستونزمن کړی.

دریمه لاره

کله چې د C++ 14 معیار ته لاړ شو، موږ لاندې اختیارونه په پام کې نیسو:

  1. د STLPport لوړ کړئ چې موږ د C++ 14 معیار ته بدلون ورکړ. اختیار خورا ستونزمن دی، ځکه چې ... د STLPport لپاره ملاتړ په 2010 کې بند شو، او موږ باید د هغې ټول کوډ پخپله جوړ کړو.
  2. بل STL تطبیق ته لیږد چې د C++ 14 سره مطابقت لري. دا خورا مطلوب دی چې دا پلي کول د وینډوز او لینکس لپاره وي.
  3. کله چې د هر OS لپاره تالیف کول، په اړونده کمپیلر کې جوړ شوی کتابتون وکاروئ.

لومړی انتخاب د ډیر کار له امله په کلکه رد شو.

موږ د یو څه وخت لپاره د دوهم انتخاب په اړه فکر وکړ؛ د نوماند په توګه ګڼل کیږي libc++، مګر په هغه وخت کې دا د وینډوز لاندې کار نه کاوه. وینډوز ته د libc++ پورټ کولو لپاره ، تاسو باید ډیر کار وکړئ - د مثال په توګه ، هرڅه پخپله ولیکئ چې د تارونو ، تارونو ترکیب او اتومیت سره تړاو لري ، ځکه چې libc++ پدې برخو کې کارول کیږي POSIX API.

او موږ دریمه لاره غوره کړه.

لیږد

نو، موږ باید د STLPport کارول د اړونده تالیف کونکو کتابتونونو سره ځای په ځای کړو (د وینډوز لپاره ویژول سټوډیو 2015، د لینکس لپاره gcc 7، د macOS لپاره کلینګ 8).

خوشبختانه، زموږ کوډ په عمده توګه د لارښوونو سره سم لیکل شوی و او د هر ډول چال چلن څخه کار نه و، نو نوي کتابتونونو ته مهاجرت نسبتا اسانه پرمخ لاړ، د سکریپټونو په مرسته چې د ډولونو، ټولګیو، نوم ځایونو نومونه او په سرچینه کې شامل دي. فایلونه مهاجرت 10 سرچینې فایلونه اغیزمن کړي (له 000 څخه). wchar_t د char14_t لخوا بدل شو؛ موږ پریکړه وکړه چې د wchar_t کارول پریږدو، ځکه چې char000_t په ټولو OS کې 16 بایټونه اخلي او د وینډوز او لینکس ترمینځ د کوډ مطابقت نه خرابوي.

یو څه کوچني سفرونه وو. د مثال په توګه، په STLPort کې یو تکرار کوالی شي په واضح ډول یو عنصر ته اشاره کونکي ته واچول شي، او زموږ په کوډ کې په ځینو ځایونو کې دا کارول کیده. په نویو کتابتونونو کې دا نور امکان نه درلود چې دا کار وکړي، او دا عبارتونه باید په لاسي ډول تحلیل او بیا لیکل شوي وای.

نو، د کوډ مهاجرت بشپړ شوی، کوډ د ټولو عملیاتي سیسټمونو لپاره ترتیب شوی. دا د ازموینو وخت دی.

د لیږد وروسته ازموینو په فعالیت کې کمښت ښودلی (په ځینو ځایونو کې تر 20-30٪ پورې) او د حافظې مصرف کې زیاتوالی (تر 10-15٪ پورې) د کوډ پخوانۍ نسخې په پرتله. دا په ځانګړي توګه د معیاري تارونو د فرعي غوره فعالیت له امله و. له همدې امله، موږ بیا باید خپل خپل، یو څه بدل شوی کرښه وکاروو.

په ایمبیډ شوي کتابتونونو کې د کانټینرونو پلي کولو یوه زړه پورې ځانګړتیا هم څرګنده شوه: خالي (بغیر عناصر) std:: نقشه او std:: د جوړ شوي کتابتونونو څخه سیټ حافظه تخصیص کوي. او د پلي کولو ځانګړتیاو له امله ، په کوډ کې په ځینو ځایونو کې د دې ډول ډیری خالي کانټینرونه رامینځته شوي. د حافظې معیاري کانټینرونه یو څه تخصیص شوي ، د یو ریښې عنصر لپاره ، مګر زموږ لپاره دا خورا مهم وګرځیدل - په یو شمیر سناریوګانو کې ، زموږ فعالیت د پام وړ راټیټ شو او د حافظې مصرف ډیر شو (د STLPort په پرتله). له همدې امله ، زموږ په کوډ کې موږ دا دوه ډوله کانټینرونه له جوړ شوي کتابتونونو څخه د بوسټ څخه پلي کولو سره ځای په ځای کړل ، چیرې چې دې کانټینرونو دا ځانګړتیا نه درلوده ، او دا ستونزه د سستیدو او د حافظې مصرف ډیروالي سره حل کړه.

لکه څنګه چې ډیری وختونه په لویو پروژو کې د لوی کچې بدلونونو وروسته پیښیږي، د سرچینې کوډ لومړی تکرار پرته له کومې ستونزې کار نه کوي، او دلته، په ځانګړې توګه، د وینډوز پلي کولو کې د ډیبګ کولو تکرارونو ملاتړ په لاس کې راغلی. ګام په ګام موږ مخ په وړاندې لاړو، او د 2017 په پسرلي کې (نسخه 8.3.11 1C:Enterprise) مهاجرت بشپړ شو.

پایلې

د C++ 14 معیار ته لیږد موږ شاوخوا 6 میاشتې وخت واخیست. ډیری وخت، یو (مګر خورا لوړ وړ) پراختیا کونکي په پروژه کې کار کاوه، او په وروستي پړاو کې د ځانګړو ساحو لپاره د مسؤل ټیمونو استازي شامل شوي - UI، سرور کلستر، پراختیا او اداري وسایل، او نور.

لیږد د معیاري وروستي نسخو ته د مهاجرت په اړه زموږ کار خورا ساده کړی. په دې توګه، نسخه 1C: تصدۍ 8.3.14 (په پراختیا کې، د راتلونکي کال په پیل کې خوشې کول) دمخه معیار ته لیږدول شوي C++17.

د مهاجرت وروسته، پراختیا کونکي ډیر اختیارونه لري. که مخکې موږ د STL خپله بدله شوې نسخه او یو std نوم ځای درلود، اوس موږ په std نوم ځای کې د جوړ شوي کمپیلر کتابتونونو څخه معیاري ټولګي لرو، په stdx نوم ځای کې - زموږ لاینونه او کانټینرونه زموږ د کارونو لپاره غوره شوي، په وده کې. د بوسټ وروستۍ نسخه. او پراختیا کونکی هغه ټولګي کاروي چې د هغه د ستونزو حل کولو لپاره په مناسب ډول مناسب دي.

د حرکت جوړونکو "اصلي" پلي کول هم په پراختیا کې مرسته کوي (حرکت جوړونکي) د یو شمیر ټولګیو لپاره. که یو ټولګی د حرکت جوړونکی ولري او دا ټولګي په کانټینر کې ځای په ځای شوي وي، نو STL د کانټینر دننه د عناصرو کاپي کولو ته وده ورکوي (د مثال په توګه، کله چې کانټینر پراخ شي او د ظرفیت بدلولو او د حافظې بیا ځای پرځای کولو ته اړتیا وي).

په میتر کې الوتل

شاید د مهاجرت ترټولو ناخوښه (مګر نازک نه) پایله دا وي چې موږ د حجم له زیاتوالي سره مخ یو. obj فایلونه، او د ټولو منځنیو فایلونو سره د جوړونې بشپړ پایله د 60-70 GB په اخیستلو پیل وکړ. دا چلند د عصري معیاري کتابتونونو د ځانګړتیاوو له امله دی، کوم چې د تولید شوي خدماتو فایلونو اندازې په اړه لږ مهم شوي دي. دا د تالیف شوي غوښتنلیک عملیات اغیزه نه کوي ، مګر دا په پراختیا کې د یو شمیر ستونزو لامل کیږي ، په ځانګړي توګه ، دا د تالیف وخت ډیروي. د جوړ سرورونو او پراختیا کونکي ماشینونو کې د وړیا ډیسک ځای اړتیاوې هم مخ په ډیریدو دي. زموږ پراختیا کونکي په موازي ډول د پلیټ فارم په څو نسخو کار کوي ، او په سلګونو ګیګابایټ منځګړی فایلونه ځینې وختونه د دوی په کار کې ستونزې رامینځته کوي. ستونزه ناخوښه ده، مګر نازکه نه ده؛ موږ د اوس لپاره د هغې حل ځنډولی دی. موږ ټیکنالوژي د دې د حل کولو لپاره د یو انتخاب په توګه په پام کې نیسو یووالي جوړول (په ځانګړې توګه، ګوګل دا د کروم براوزر جوړولو په وخت کې کاروي).

سرچینه: www.habr.com

Add a comment