ਅਸੀਂ C++ ਕੋਡ ਦੀਆਂ 10 ਮਿਲੀਅਨ ਲਾਈਨਾਂ ਨੂੰ C++14 ਸਟੈਂਡਰਡ (ਅਤੇ ਫਿਰ C++17) ਵਿੱਚ ਕਿਵੇਂ ਅਨੁਵਾਦ ਕੀਤਾ।

ਕੁਝ ਸਮਾਂ ਪਹਿਲਾਂ (2016 ਦੇ ਪਤਝੜ ਵਿੱਚ), 1C:Enterprise ਤਕਨਾਲੋਜੀ ਪਲੇਟਫਾਰਮ ਦੇ ਅਗਲੇ ਸੰਸਕਰਣ ਦੇ ਵਿਕਾਸ ਦੇ ਦੌਰਾਨ, ਨਵੇਂ ਸਟੈਂਡਰਡ ਦਾ ਸਮਰਥਨ ਕਰਨ ਬਾਰੇ ਵਿਕਾਸ ਟੀਮ ਦੇ ਅੰਦਰ ਸਵਾਲ ਉੱਠਿਆ ਸੀ। ਸੀ ++ 14 ਸਾਡੇ ਕੋਡ ਵਿੱਚ. ਇੱਕ ਨਵੇਂ ਮਿਆਰ ਵਿੱਚ ਪਰਿਵਰਤਨ, ਜਿਵੇਂ ਕਿ ਅਸੀਂ ਮੰਨਿਆ ਹੈ, ਸਾਨੂੰ ਬਹੁਤ ਸਾਰੀਆਂ ਚੀਜ਼ਾਂ ਨੂੰ ਹੋਰ ਸ਼ਾਨਦਾਰ, ਸਰਲ ਅਤੇ ਭਰੋਸੇਮੰਦ ਢੰਗ ਨਾਲ ਲਿਖਣ ਦੀ ਇਜਾਜ਼ਤ ਦੇਵੇਗਾ, ਅਤੇ ਕੋਡ ਦੇ ਸਮਰਥਨ ਅਤੇ ਰੱਖ-ਰਖਾਅ ਨੂੰ ਸਰਲ ਬਣਾ ਦੇਵੇਗਾ। ਅਤੇ ਅਨੁਵਾਦ ਵਿੱਚ ਕੁਝ ਵੀ ਅਸਧਾਰਨ ਨਹੀਂ ਜਾਪਦਾ ਹੈ, ਜੇਕਰ ਕੋਡ ਬੇਸ ਦੇ ਪੈਮਾਨੇ ਅਤੇ ਸਾਡੇ ਕੋਡ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਲਈ ਨਹੀਂ।

ਉਹਨਾਂ ਲਈ ਜੋ ਨਹੀਂ ਜਾਣਦੇ, 1C:Enterprise ਵੱਖ-ਵੱਖ OS ਅਤੇ DBMSs 'ਤੇ ਉਹਨਾਂ ਦੇ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਲਈ ਕ੍ਰਾਸ-ਪਲੇਟਫਾਰਮ ਬਿਜ਼ਨਸ ਐਪਲੀਕੇਸ਼ਨਾਂ ਅਤੇ ਰਨਟਾਈਮ ਦੇ ਤੇਜ਼ੀ ਨਾਲ ਵਿਕਾਸ ਲਈ ਇੱਕ ਵਾਤਾਵਰਣ ਹੈ। ਆਮ ਸ਼ਬਦਾਂ ਵਿੱਚ, ਉਤਪਾਦ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ:

• ਐਪਲੀਕੇਸ਼ਨ ਸਰਵਰ ਕਲੱਸਟਰ, ਵਿੰਡੋਜ਼ ਅਤੇ ਲੀਨਕਸ 'ਤੇ ਚੱਲਦਾ ਹੈ
• ਗਾਹਕ, http(s) ਜਾਂ ਇਸਦੇ ਆਪਣੇ ਬਾਈਨਰੀ ਪ੍ਰੋਟੋਕੋਲ ਰਾਹੀਂ ਸਰਵਰ ਨਾਲ ਕੰਮ ਕਰਨਾ, Windows, Linux, macOS 'ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ
• ਵੈੱਬ ਕਲਾਇੰਟ, Chrome, Internet Explorer, Microsoft Edge, Firefox, Safari ਬ੍ਰਾਊਜ਼ਰ (JavaScript ਵਿੱਚ ਲਿਖਿਆ) ਵਿੱਚ ਚੱਲ ਰਿਹਾ ਹੈ
• ਵਿਕਾਸ ਵਾਤਾਵਰਨ (ਸੰਰਚਨਾਕਾਰ), Windows, Linux, macOS 'ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ
• ਪ੍ਰਸ਼ਾਸਨ ਦੇ ਸਾਧਨ ਐਪਲੀਕੇਸ਼ਨ ਸਰਵਰ, ਵਿੰਡੋਜ਼, ਲੀਨਕਸ, ਮੈਕੋਸ 'ਤੇ ਚੱਲਦੇ ਹਨ
• ਮੋਬਾਈਲ ਗਾਹਕ, HTTP(s) ਰਾਹੀਂ ਸਰਵਰ ਨਾਲ ਕਨੈਕਟ ਕਰਨਾ, Android, iOS, Windows ਚਲਾਉਣ ਵਾਲੇ ਮੋਬਾਈਲ ਡਿਵਾਈਸਾਂ 'ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ
• ਮੋਬਾਈਲ ਪਲੇਟਫਾਰਮ - ਐਂਡਰੌਇਡ, ਆਈਓਐਸ, ਵਿੰਡੋਜ਼ 'ਤੇ ਚੱਲਦੇ ਹੋਏ, ਸਿੰਕ੍ਰੋਨਾਈਜ਼ ਕਰਨ ਦੀ ਯੋਗਤਾ ਦੇ ਨਾਲ ਔਫਲਾਈਨ ਮੋਬਾਈਲ ਐਪਲੀਕੇਸ਼ਨ ਬਣਾਉਣ ਲਈ ਇੱਕ ਢਾਂਚਾ
• ਵਿਕਾਸ ਵਾਤਾਵਰਣ 1C: ਐਂਟਰਪ੍ਰਾਈਜ਼ ਡਿਵੈਲਪਮੈਂਟ ਟੂਲ, Java ਵਿੱਚ ਲਿਖਿਆ ਗਿਆ ਹੈ
• ਸਰਵਰ ਇੰਟਰਐਕਸ਼ਨ ਸਿਸਟਮ

ਅਸੀਂ ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ ਵੱਖ-ਵੱਖ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮਾਂ ਲਈ ਇੱਕੋ ਕੋਡ ਲਿਖਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਾਂ - ਸਰਵਰ ਕੋਡ ਅਧਾਰ 99% ਆਮ ਹੈ, ਕਲਾਇੰਟ ਕੋਡ ਅਧਾਰ ਲਗਭਗ 95% ਹੈ। 1C: ਐਂਟਰਪ੍ਰਾਈਜ਼ ਤਕਨਾਲੋਜੀ ਪਲੇਟਫਾਰਮ ਮੁੱਖ ਤੌਰ 'ਤੇ C++ ਵਿੱਚ ਲਿਖਿਆ ਗਿਆ ਹੈ ਅਤੇ ਲਗਭਗ ਕੋਡ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਹੇਠਾਂ ਦਿੱਤੀਆਂ ਗਈਆਂ ਹਨ:

• C++ ਕੋਡ ਦੀਆਂ 10 ਮਿਲੀਅਨ ਲਾਈਨਾਂ,
• 14 ਹਜ਼ਾਰ ਫਾਈਲਾਂ,
• 60 ਹਜ਼ਾਰ ਕਲਾਸਾਂ,
• ਅੱਧਾ ਮਿਲੀਅਨ ਤਰੀਕੇ।

ਅਤੇ ਇਹ ਸਾਰੀ ਸਮੱਗਰੀ C++14 ਵਿੱਚ ਅਨੁਵਾਦ ਕੀਤੀ ਜਾਣੀ ਸੀ। ਅੱਜ ਅਸੀਂ ਤੁਹਾਨੂੰ ਦੱਸਾਂਗੇ ਕਿ ਅਸੀਂ ਇਹ ਕਿਵੇਂ ਕੀਤਾ ਅਤੇ ਇਸ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਸਾਨੂੰ ਕੀ ਸਾਹਮਣਾ ਕਰਨਾ ਪਿਆ।

ਬੇਦਾਅਵਾ

ਹੌਲੀ/ਤੇਜ਼ ਕੰਮ ਬਾਰੇ ਹੇਠਾਂ ਲਿਖੀ ਹਰ ਚੀਜ਼, (ਨਹੀਂ) ਵੱਖ-ਵੱਖ ਲਾਇਬ੍ਰੇਰੀਆਂ ਵਿੱਚ ਮਿਆਰੀ ਕਲਾਸਾਂ ਨੂੰ ਲਾਗੂ ਕਰਕੇ ਵੱਡੀ ਮੈਮੋਰੀ ਦੀ ਖਪਤ ਦਾ ਮਤਲਬ ਹੈ: ਇਹ ਅਮਰੀਕਾ ਲਈ ਸੱਚ ਹੈ। ਇਹ ਬਹੁਤ ਸੰਭਵ ਹੈ ਕਿ ਮਿਆਰੀ ਲਾਗੂਕਰਨ ਤੁਹਾਡੇ ਕੰਮਾਂ ਲਈ ਸਭ ਤੋਂ ਅਨੁਕੂਲ ਹੋਣਗੇ। ਅਸੀਂ ਆਪਣੇ ਕਾਰਜਾਂ ਤੋਂ ਸ਼ੁਰੂਆਤ ਕੀਤੀ: ਅਸੀਂ ਉਹ ਡੇਟਾ ਲਿਆ ਜੋ ਸਾਡੇ ਗਾਹਕਾਂ ਲਈ ਆਮ ਸੀ, ਉਹਨਾਂ 'ਤੇ ਆਮ ਦ੍ਰਿਸ਼ਾਂ ਨੂੰ ਚਲਾਇਆ, ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਦੇਖਿਆ, ਮੈਮੋਰੀ ਦੀ ਖਪਤ ਦੀ ਮਾਤਰਾ, ਆਦਿ, ਅਤੇ ਵਿਸ਼ਲੇਸ਼ਣ ਕੀਤਾ ਕਿ ਕੀ ਅਸੀਂ ਅਤੇ ਸਾਡੇ ਗਾਹਕ ਅਜਿਹੇ ਨਤੀਜਿਆਂ ਤੋਂ ਸੰਤੁਸ਼ਟ ਸਨ ਜਾਂ ਨਹੀਂ। . ਅਤੇ ਉਹ ਇਸ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ.

ਜੋ ਸਾਡੇ ਕੋਲ ਸੀ

ਸ਼ੁਰੂ ਵਿੱਚ, ਅਸੀਂ Microsoft ਵਿਜ਼ੁਅਲ ਸਟੂਡੀਓ ਵਿੱਚ 1C:Enterprise 8 ਪਲੇਟਫਾਰਮ ਲਈ ਕੋਡ ਲਿਖਿਆ ਸੀ। ਪ੍ਰੋਜੈਕਟ 2000 ਦੇ ਦਹਾਕੇ ਦੇ ਸ਼ੁਰੂ ਵਿੱਚ ਸ਼ੁਰੂ ਹੋਇਆ ਸੀ ਅਤੇ ਸਾਡੇ ਕੋਲ ਇੱਕ ਵਿੰਡੋਜ਼-ਓਨਲੀ ਸੰਸਕਰਣ ਸੀ। ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ, ਉਦੋਂ ਤੋਂ ਕੋਡ ਨੂੰ ਸਰਗਰਮੀ ਨਾਲ ਵਿਕਸਤ ਕੀਤਾ ਗਿਆ ਹੈ, ਬਹੁਤ ਸਾਰੀਆਂ ਵਿਧੀਆਂ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਦੁਬਾਰਾ ਲਿਖਿਆ ਗਿਆ ਹੈ. ਪਰ ਕੋਡ 1998 ਦੇ ਮਿਆਰ ਦੇ ਅਨੁਸਾਰ ਲਿਖਿਆ ਗਿਆ ਸੀ, ਅਤੇ, ਉਦਾਹਰਨ ਲਈ, ਸਾਡੇ ਸੱਜੇ ਕੋਣ ਬਰੈਕਟਾਂ ਨੂੰ ਸਪੇਸ ਦੁਆਰਾ ਵੱਖ ਕੀਤਾ ਗਿਆ ਸੀ ਤਾਂ ਜੋ ਸੰਕਲਨ ਸਫਲ ਹੋ ਸਕੇ, ਇਸ ਤਰ੍ਹਾਂ:

vector<vector<int> > IntV;

2006 ਵਿੱਚ, ਪਲੇਟਫਾਰਮ ਸੰਸਕਰਣ 8.1 ਦੇ ਜਾਰੀ ਹੋਣ ਦੇ ਨਾਲ, ਅਸੀਂ ਲੀਨਕਸ ਦਾ ਸਮਰਥਨ ਕਰਨਾ ਸ਼ੁਰੂ ਕੀਤਾ ਅਤੇ ਇੱਕ ਤੀਜੀ-ਧਿਰ ਸਟੈਂਡਰਡ ਲਾਇਬ੍ਰੇਰੀ ਵਿੱਚ ਬਦਲਿਆ। STLPਪੋਰਟ. ਤਬਦੀਲੀ ਦਾ ਇੱਕ ਕਾਰਨ ਚੌੜੀਆਂ ਲਾਈਨਾਂ ਨਾਲ ਕੰਮ ਕਰਨਾ ਸੀ। ਸਾਡੇ ਕੋਡ ਵਿੱਚ, ਅਸੀਂ std::wstring ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ, ਜੋ ਕਿ wchar_t ਕਿਸਮ 'ਤੇ ਆਧਾਰਿਤ ਹੈ। ਵਿੰਡੋਜ਼ ਵਿੱਚ ਇਸਦਾ ਆਕਾਰ 2 ਬਾਈਟ ਹੈ, ਅਤੇ ਲੀਨਕਸ ਵਿੱਚ ਡਿਫੌਲਟ 4 ਬਾਈਟਸ ਹੈ। ਇਸ ਨਾਲ ਕਲਾਇੰਟ ਅਤੇ ਸਰਵਰ ਵਿਚਕਾਰ ਸਾਡੇ ਬਾਈਨਰੀ ਪ੍ਰੋਟੋਕੋਲ ਦੀ ਅਸੰਗਤਤਾ ਦੇ ਨਾਲ-ਨਾਲ ਵੱਖ-ਵੱਖ ਨਿਰੰਤਰ ਡੇਟਾ ਵੀ ਪੈਦਾ ਹੋਇਆ। gcc ਵਿਕਲਪਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਤੁਸੀਂ ਨਿਸ਼ਚਿਤ ਕਰ ਸਕਦੇ ਹੋ ਕਿ ਕੰਪਾਈਲੇਸ਼ਨ ਦੌਰਾਨ wchar_t ਦਾ ਆਕਾਰ ਵੀ 2 ਬਾਈਟ ਹੈ, ਪਰ ਫਿਰ ਤੁਸੀਂ ਕੰਪਾਈਲਰ ਤੋਂ ਸਟੈਂਡਰਡ ਲਾਇਬ੍ਰੇਰੀ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਭੁੱਲ ਸਕਦੇ ਹੋ, ਕਿਉਂਕਿ ਇਹ glibc ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ, ਜੋ ਬਦਲੇ ਵਿੱਚ ਇੱਕ 4-ਬਾਈਟ wchar_t ਲਈ ਕੰਪਾਇਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਹੋਰ ਕਾਰਨ ਮਿਆਰੀ ਕਲਾਸਾਂ ਨੂੰ ਬਿਹਤਰ ਢੰਗ ਨਾਲ ਲਾਗੂ ਕਰਨਾ, ਹੈਸ਼ ਟੇਬਲਾਂ ਲਈ ਸਮਰਥਨ, ਅਤੇ ਕੰਟੇਨਰਾਂ ਦੇ ਅੰਦਰ ਜਾਣ ਦੇ ਅਰਥ ਵਿਗਿਆਨ ਦੀ ਨਕਲ ਵੀ ਸਨ, ਜਿਨ੍ਹਾਂ ਦੀ ਅਸੀਂ ਸਰਗਰਮੀ ਨਾਲ ਵਰਤੋਂ ਕੀਤੀ ਸੀ। ਅਤੇ ਇੱਕ ਹੋਰ ਕਾਰਨ, ਜਿਵੇਂ ਕਿ ਉਹ ਆਖਰਕਾਰ ਕਹਿੰਦੇ ਹਨ ਪਰ ਘੱਟੋ ਘੱਟ ਨਹੀਂ, ਸਟ੍ਰਿੰਗ ਪ੍ਰਦਰਸ਼ਨ ਸੀ। ਸਤਰ ਲਈ ਸਾਡੀ ਆਪਣੀ ਕਲਾਸ ਸੀ, ਕਿਉਂਕਿ... ਸਾਡੇ ਸੌਫਟਵੇਅਰ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੇ ਕਾਰਨ, ਸਟ੍ਰਿੰਗ ਓਪਰੇਸ਼ਨ ਬਹੁਤ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਵਰਤੇ ਜਾਂਦੇ ਹਨ ਅਤੇ ਸਾਡੇ ਲਈ ਇਹ ਮਹੱਤਵਪੂਰਨ ਹੈ।

ਸਾਡੀ ਸਟ੍ਰਿੰਗ 2000 ਦੇ ਦਹਾਕੇ ਦੇ ਸ਼ੁਰੂ ਵਿੱਚ ਪ੍ਰਗਟ ਕੀਤੇ ਗਏ ਸਟ੍ਰਿੰਗ ਅਨੁਕੂਲਨ ਵਿਚਾਰਾਂ 'ਤੇ ਅਧਾਰਤ ਹੈ ਆਂਦਰੇਈ ਅਲੈਗਜ਼ੈਂਡਰੇਸਕੁ. ਬਾਅਦ ਵਿੱਚ, ਜਦੋਂ ਅਲੈਗਜ਼ੈਂਡਰੇਸਕੂ ਨੇ ਫੇਸਬੁੱਕ 'ਤੇ ਕੰਮ ਕੀਤਾ, ਉਸਦੇ ਸੁਝਾਅ 'ਤੇ, ਫੇਸਬੁੱਕ ਇੰਜਣ ਵਿੱਚ ਇੱਕ ਲਾਈਨ ਵਰਤੀ ਗਈ ਜੋ ਸਮਾਨ ਸਿਧਾਂਤਾਂ 'ਤੇ ਕੰਮ ਕਰਦੀ ਸੀ (ਵੇਖੋ ਲਾਇਬ੍ਰੇਰੀ ਮੂਰਖਤਾ).

ਸਾਡੀ ਲਾਈਨ ਨੇ ਦੋ ਮੁੱਖ ਅਨੁਕੂਲਨ ਤਕਨੀਕਾਂ ਦੀ ਵਰਤੋਂ ਕੀਤੀ:

1. ਛੋਟੇ ਮੁੱਲਾਂ ਲਈ, ਸਟਰਿੰਗ ਆਬਜੈਕਟ ਵਿੱਚ ਇੱਕ ਅੰਦਰੂਨੀ ਬਫਰ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ (ਵਧੀਕ ਮੈਮੋਰੀ ਵੰਡ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ)।
2. ਬਾਕੀ ਸਭ ਲਈ, ਮਕੈਨਿਕ ਵਰਤੇ ਜਾਂਦੇ ਹਨ ਲਿਖਣ 'ਤੇ ਕਾਪੀ ਕਰੋ. ਸਤਰ ਮੁੱਲ ਨੂੰ ਇੱਕ ਥਾਂ ਤੇ ਸਟੋਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਅਸਾਈਨਮੈਂਟ/ਸੋਧਣ ਦੌਰਾਨ ਇੱਕ ਹਵਾਲਾ ਕਾਊਂਟਰ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ।

ਪਲੇਟਫਾਰਮ ਸੰਕਲਨ ਨੂੰ ਤੇਜ਼ ਕਰਨ ਲਈ, ਅਸੀਂ ਆਪਣੇ STLPport ਵੇਰੀਐਂਟ (ਜਿਸ ਦੀ ਅਸੀਂ ਵਰਤੋਂ ਨਹੀਂ ਕੀਤੀ) ਤੋਂ ਸਟ੍ਰੀਮ ਲਾਗੂਕਰਨ ਨੂੰ ਬਾਹਰ ਰੱਖਿਆ, ਇਸ ਨਾਲ ਸਾਨੂੰ ਲਗਭਗ 20% ਤੇਜ਼ ਸੰਕਲਨ ਮਿਲਿਆ। ਇਸ ਤੋਂ ਬਾਅਦ ਸਾਨੂੰ ਸੀਮਤ ਵਰਤੋਂ ਕਰਨੀ ਪਈ ਰੱਖਣੇ. ਬੂਸਟ ਸਟ੍ਰੀਮ ਦੀ ਭਾਰੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ, ਖਾਸ ਤੌਰ 'ਤੇ ਇਸਦੇ ਸੇਵਾ API ਵਿੱਚ (ਉਦਾਹਰਨ ਲਈ, ਲੌਗਿੰਗ ਲਈ), ਇਸਲਈ ਸਾਨੂੰ ਸਟ੍ਰੀਮ ਦੀ ਵਰਤੋਂ ਨੂੰ ਹਟਾਉਣ ਲਈ ਇਸਨੂੰ ਸੋਧਣਾ ਪਿਆ। ਇਸ ਨਾਲ, ਬਦਲੇ ਵਿੱਚ, ਸਾਡੇ ਲਈ ਬੂਸਟ ਦੇ ਨਵੇਂ ਸੰਸਕਰਣਾਂ 'ਤੇ ਮਾਈਗ੍ਰੇਟ ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੋ ਗਿਆ।

ਤੀਜਾ ਤਰੀਕਾ

C++ 14 ਸਟੈਂਡਰਡ 'ਤੇ ਜਾਣ ਵੇਲੇ, ਅਸੀਂ ਹੇਠਾਂ ਦਿੱਤੇ ਵਿਕਲਪਾਂ 'ਤੇ ਵਿਚਾਰ ਕੀਤਾ:

1. STLPport ਨੂੰ ਅਸੀਂ C++14 ਸਟੈਂਡਰਡ ਵਿੱਚ ਸੋਧਿਆ ਹੈ। ਵਿਕਲਪ ਬਹੁਤ ਮੁਸ਼ਕਲ ਹੈ, ਕਿਉਂਕਿ ... STLPport ਲਈ ਸਮਰਥਨ 2010 ਵਿੱਚ ਬੰਦ ਕਰ ਦਿੱਤਾ ਗਿਆ ਸੀ, ਅਤੇ ਸਾਨੂੰ ਇਸਦਾ ਸਾਰਾ ਕੋਡ ਖੁਦ ਬਣਾਉਣਾ ਹੋਵੇਗਾ।
2. C++14 ਦੇ ਅਨੁਕੂਲ ਕਿਸੇ ਹੋਰ STL ਲਾਗੂਕਰਨ ਵਿੱਚ ਤਬਦੀਲੀ। ਇਹ ਬਹੁਤ ਫਾਇਦੇਮੰਦ ਹੈ ਕਿ ਇਹ ਲਾਗੂ ਕਰਨਾ ਵਿੰਡੋਜ਼ ਅਤੇ ਲੀਨਕਸ ਲਈ ਹੋਵੇ।
3. ਹਰੇਕ OS ਲਈ ਕੰਪਾਇਲ ਕਰਦੇ ਸਮੇਂ, ਸੰਬੰਧਿਤ ਕੰਪਾਈਲਰ ਵਿੱਚ ਬਣੀ ਲਾਇਬ੍ਰੇਰੀ ਦੀ ਵਰਤੋਂ ਕਰੋ।

ਪਹਿਲੇ ਵਿਕਲਪ ਨੂੰ ਬਹੁਤ ਜ਼ਿਆਦਾ ਕੰਮ ਦੇ ਕਾਰਨ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਰੱਦ ਕਰ ਦਿੱਤਾ ਗਿਆ ਸੀ.

ਅਸੀਂ ਕੁਝ ਸਮੇਂ ਲਈ ਦੂਜੇ ਵਿਕਲਪ ਬਾਰੇ ਸੋਚਿਆ; ਉਮੀਦਵਾਰ ਵਜੋਂ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ libc++, ਪਰ ਉਸ ਸਮੇਂ ਇਹ ਵਿੰਡੋਜ਼ ਦੇ ਅਧੀਨ ਕੰਮ ਨਹੀਂ ਕਰਦਾ ਸੀ। ਵਿੰਡੋਜ਼ ਵਿੱਚ libc++ ਨੂੰ ਪੋਰਟ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਬਹੁਤ ਸਾਰਾ ਕੰਮ ਕਰਨਾ ਪਏਗਾ - ਉਦਾਹਰਨ ਲਈ, ਉਹ ਸਭ ਕੁਝ ਆਪਣੇ ਆਪ ਲਿਖੋ ਜਿਸਦਾ ਥਰਿੱਡ, ਥ੍ਰੈਡ ਸਿੰਕ੍ਰੋਨਾਈਜ਼ੇਸ਼ਨ ਅਤੇ ਐਟਮੀਸਿਟੀ ਨਾਲ ਸਬੰਧ ਹੈ, ਕਿਉਂਕਿ ਇਹਨਾਂ ਖੇਤਰਾਂ ਵਿੱਚ libc++ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। POSIX API.

ਅਤੇ ਅਸੀਂ ਤੀਜਾ ਰਾਹ ਚੁਣਿਆ।

ਤਬਦੀਲੀ

ਇਸ ਲਈ, ਸਾਨੂੰ STLPport ਦੀ ਵਰਤੋਂ ਨੂੰ ਸੰਬੰਧਿਤ ਕੰਪਾਈਲਰਾਂ ਦੀਆਂ ਲਾਇਬ੍ਰੇਰੀਆਂ ਨਾਲ ਬਦਲਣਾ ਪਿਆ (ਵਿੰਡੋਜ਼ ਲਈ ਵਿਜ਼ੂਅਲ ਸਟੂਡੀਓ 2015, ਲੀਨਕਸ ਲਈ ਜੀਸੀਸੀ 7, ਮੈਕੋਸ ਲਈ ਕਲੈਂਗ 8)।

ਖੁਸ਼ਕਿਸਮਤੀ ਨਾਲ, ਸਾਡਾ ਕੋਡ ਮੁੱਖ ਤੌਰ 'ਤੇ ਦਿਸ਼ਾ-ਨਿਰਦੇਸ਼ਾਂ ਦੇ ਅਨੁਸਾਰ ਲਿਖਿਆ ਗਿਆ ਸੀ ਅਤੇ ਹਰ ਤਰ੍ਹਾਂ ਦੀਆਂ ਚਲਾਕ ਚਾਲਾਂ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰਦਾ ਸੀ, ਇਸਲਈ ਨਵੀਆਂ ਲਾਇਬ੍ਰੇਰੀਆਂ ਵਿੱਚ ਮਾਈਗ੍ਰੇਸ਼ਨ ਮੁਕਾਬਲਤਨ ਸੁਚਾਰੂ ਢੰਗ ਨਾਲ ਅੱਗੇ ਵਧਿਆ, ਸਕ੍ਰਿਪਟਾਂ ਦੀ ਮਦਦ ਨਾਲ ਜੋ ਕਿਸਮਾਂ, ਕਲਾਸਾਂ, ਨੇਮ ਸਪੇਸ ਅਤੇ ਸਰੋਤ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ ਦੇ ਨਾਮ ਬਦਲਦੀਆਂ ਹਨ। ਫਾਈਲਾਂ। ਮਾਈਗ੍ਰੇਸ਼ਨ ਨੇ 10 ਸਰੋਤ ਫਾਈਲਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕੀਤਾ (000 ਵਿੱਚੋਂ)। wchar_t ਨੂੰ char14_t ਨਾਲ ਬਦਲਿਆ ਗਿਆ ਸੀ; ਅਸੀਂ wchar_t ਦੀ ਵਰਤੋਂ ਨੂੰ ਛੱਡਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਹੈ, ਕਿਉਂਕਿ char000_t ਸਾਰੇ OS ਤੇ 16 ਬਾਈਟ ਲੈਂਦਾ ਹੈ ਅਤੇ ਵਿੰਡੋਜ਼ ਅਤੇ ਲੀਨਕਸ ਵਿਚਕਾਰ ਕੋਡ ਅਨੁਕੂਲਤਾ ਨੂੰ ਖਰਾਬ ਨਹੀਂ ਕਰਦਾ।

ਕੁਝ ਛੋਟੇ ਸਾਹਸ ਸਨ. ਉਦਾਹਰਨ ਲਈ, STLPport ਵਿੱਚ ਇੱਕ ਇਟਰੇਟਰ ਨੂੰ ਇੱਕ ਐਲੀਮੈਂਟ ਦੇ ਪੁਆਇੰਟਰ 'ਤੇ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਕਾਸਟ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਅਤੇ ਸਾਡੇ ਕੋਡ ਵਿੱਚ ਕੁਝ ਥਾਵਾਂ 'ਤੇ ਇਹ ਵਰਤਿਆ ਗਿਆ ਸੀ। ਨਵੀਆਂ ਲਾਇਬ੍ਰੇਰੀਆਂ ਵਿੱਚ ਅਜਿਹਾ ਕਰਨਾ ਹੁਣ ਸੰਭਵ ਨਹੀਂ ਸੀ, ਅਤੇ ਇਹਨਾਂ ਅੰਸ਼ਾਂ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਅਤੇ ਹੱਥੀਂ ਦੁਬਾਰਾ ਲਿਖਣਾ ਪੈਂਦਾ ਸੀ।

ਇਸ ਲਈ, ਕੋਡ ਮਾਈਗ੍ਰੇਸ਼ਨ ਪੂਰਾ ਹੋ ਗਿਆ ਹੈ, ਕੋਡ ਸਾਰੇ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮਾਂ ਲਈ ਕੰਪਾਇਲ ਕੀਤਾ ਗਿਆ ਹੈ. ਇਹ ਟੈਸਟਾਂ ਦਾ ਸਮਾਂ ਹੈ।

ਪਰਿਵਰਤਨ ਤੋਂ ਬਾਅਦ ਟੈਸਟਾਂ ਨੇ ਕੋਡ ਦੇ ਪੁਰਾਣੇ ਸੰਸਕਰਣ ਦੀ ਤੁਲਨਾ ਵਿੱਚ ਕਾਰਗੁਜ਼ਾਰੀ ਵਿੱਚ ਕਮੀ (ਕੁਝ ਥਾਵਾਂ ਵਿੱਚ 20-30% ਤੱਕ) ਅਤੇ ਮੈਮੋਰੀ ਦੀ ਖਪਤ ਵਿੱਚ ਵਾਧਾ (10-15% ਤੱਕ) ਦਿਖਾਇਆ। ਇਹ, ਖਾਸ ਤੌਰ 'ਤੇ, ਸਟੈਂਡਰਡ ਸਟ੍ਰਿੰਗਜ਼ ਦੇ ਸਬ-ਓਪਟੀਮਲ ਪ੍ਰਦਰਸ਼ਨ ਦੇ ਕਾਰਨ ਸੀ। ਇਸ ਲਈ, ਸਾਨੂੰ ਦੁਬਾਰਾ ਸਾਡੀ ਆਪਣੀ, ਥੋੜੀ ਸੋਧੀ ਹੋਈ ਲਾਈਨ ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਪਈ।

ਏਮਬੈਡਡ ਲਾਇਬ੍ਰੇਰੀਆਂ ਵਿੱਚ ਕੰਟੇਨਰਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੀ ਇੱਕ ਦਿਲਚਸਪ ਵਿਸ਼ੇਸ਼ਤਾ ਵੀ ਸਾਹਮਣੇ ਆਈ ਸੀ: ਖਾਲੀ (ਬਿਨਾਂ ਤੱਤ) std::map ਅਤੇ std:: ਬਿਲਟ-ਇਨ ਲਾਇਬ੍ਰੇਰੀਆਂ ਤੋਂ ਸੈੱਟ ਮੈਮੋਰੀ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਨ। ਅਤੇ ਲਾਗੂ ਕਰਨ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੇ ਕਾਰਨ, ਕੋਡ ਵਿੱਚ ਕੁਝ ਥਾਵਾਂ ਤੇ ਇਸ ਕਿਸਮ ਦੇ ਬਹੁਤ ਸਾਰੇ ਖਾਲੀ ਕੰਟੇਨਰ ਬਣਾਏ ਗਏ ਹਨ. ਸਟੈਂਡਰਡ ਮੈਮੋਰੀ ਕੰਟੇਨਰਾਂ ਨੂੰ ਇੱਕ ਰੂਟ ਤੱਤ ਲਈ, ਥੋੜਾ ਜਿਹਾ ਨਿਰਧਾਰਤ ਕੀਤਾ ਗਿਆ ਹੈ, ਪਰ ਸਾਡੇ ਲਈ ਇਹ ਨਾਜ਼ੁਕ ਸਾਬਤ ਹੋਇਆ - ਕਈ ਦ੍ਰਿਸ਼ਾਂ ਵਿੱਚ, ਸਾਡੀ ਕਾਰਗੁਜ਼ਾਰੀ ਵਿੱਚ ਮਹੱਤਵਪੂਰਨ ਗਿਰਾਵਟ ਆਈ ਹੈ ਅਤੇ ਮੈਮੋਰੀ ਦੀ ਖਪਤ (STLPport ਦੇ ਮੁਕਾਬਲੇ) ਵਿੱਚ ਵਾਧਾ ਹੋਇਆ ਹੈ। ਇਸ ਲਈ, ਸਾਡੇ ਕੋਡ ਵਿੱਚ ਅਸੀਂ ਇਹਨਾਂ ਦੋ ਕਿਸਮਾਂ ਦੇ ਕੰਟੇਨਰਾਂ ਨੂੰ ਬਿਲਟ-ਇਨ ਲਾਇਬ੍ਰੇਰੀਆਂ ਤੋਂ ਉਹਨਾਂ ਦੇ ਬੂਸਟ ਤੋਂ ਲਾਗੂ ਕਰਨ ਨਾਲ ਬਦਲ ਦਿੱਤਾ ਹੈ, ਜਿੱਥੇ ਇਹਨਾਂ ਕੰਟੇਨਰਾਂ ਵਿੱਚ ਇਹ ਵਿਸ਼ੇਸ਼ਤਾ ਨਹੀਂ ਸੀ, ਅਤੇ ਇਸ ਨਾਲ ਸਮੱਸਿਆ ਦਾ ਹੱਲ ਹੌਲੀ ਹੋ ਗਿਆ ਅਤੇ ਮੈਮੋਰੀ ਦੀ ਖਪਤ ਵਧ ਗਈ।

ਜਿਵੇਂ ਕਿ ਅਕਸਰ ਵੱਡੇ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ ਵੱਡੇ ਪੈਮਾਨੇ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਤੋਂ ਬਾਅਦ ਹੁੰਦਾ ਹੈ, ਸਰੋਤ ਕੋਡ ਦੀ ਪਹਿਲੀ ਦੁਹਰਾਓ ਸਮੱਸਿਆ ਤੋਂ ਬਿਨਾਂ ਕੰਮ ਨਹੀਂ ਕਰਦੀ ਸੀ, ਅਤੇ ਇੱਥੇ, ਖਾਸ ਤੌਰ 'ਤੇ, ਵਿੰਡੋਜ਼ ਲਾਗੂ ਕਰਨ ਵਿੱਚ ਡੀਬੱਗਿੰਗ ਦੁਹਰਾਓ ਲਈ ਸਮਰਥਨ ਕੰਮ ਵਿੱਚ ਆਇਆ ਸੀ। ਕਦਮ ਦਰ ਕਦਮ ਅਸੀਂ ਅੱਗੇ ਵਧੇ, ਅਤੇ 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 ਤੱਕ ਲੈਣਾ ਸ਼ੁਰੂ ਹੋ ਗਿਆ। ਇਹ ਵਿਵਹਾਰ ਆਧੁਨਿਕ ਸਟੈਂਡਰਡ ਲਾਇਬ੍ਰੇਰੀਆਂ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੇ ਕਾਰਨ ਹੈ, ਜੋ ਕਿ ਤਿਆਰ ਕੀਤੀਆਂ ਸਰਵਿਸ ਫਾਈਲਾਂ ਦੇ ਆਕਾਰ ਲਈ ਘੱਟ ਆਲੋਚਨਾਤਮਕ ਬਣ ਗਈਆਂ ਹਨ। ਇਹ ਕੰਪਾਇਲ ਕੀਤੇ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਸੰਚਾਲਨ ਨੂੰ ਪ੍ਰਭਾਵਤ ਨਹੀਂ ਕਰਦਾ ਹੈ, ਪਰ ਇਹ ਵਿਕਾਸ ਵਿੱਚ ਬਹੁਤ ਸਾਰੀਆਂ ਅਸੁਵਿਧਾਵਾਂ ਦਾ ਕਾਰਨ ਬਣਦਾ ਹੈ, ਖਾਸ ਤੌਰ 'ਤੇ, ਇਹ ਸੰਕਲਨ ਦੇ ਸਮੇਂ ਨੂੰ ਵਧਾਉਂਦਾ ਹੈ। ਬਿਲਡ ਸਰਵਰਾਂ ਅਤੇ ਡਿਵੈਲਪਰ ਮਸ਼ੀਨਾਂ 'ਤੇ ਖਾਲੀ ਡਿਸਕ ਸਪੇਸ ਲਈ ਲੋੜਾਂ ਵੀ ਵਧ ਰਹੀਆਂ ਹਨ। ਸਾਡੇ ਡਿਵੈਲਪਰ ਪਲੇਟਫਾਰਮ ਦੇ ਕਈ ਸੰਸਕਰਣਾਂ 'ਤੇ ਸਮਾਨਾਂਤਰ ਕੰਮ ਕਰਦੇ ਹਨ, ਅਤੇ ਸੈਂਕੜੇ ਗੀਗਾਬਾਈਟ ਇੰਟਰਮੀਡੀਏਟ ਫਾਈਲਾਂ ਕਈ ਵਾਰ ਉਹਨਾਂ ਦੇ ਕੰਮ ਵਿੱਚ ਮੁਸ਼ਕਲਾਂ ਪੈਦਾ ਕਰਦੀਆਂ ਹਨ। ਸਮੱਸਿਆ ਨਾਜ਼ੁਕ ਹੈ, ਪਰ ਨਾਜ਼ੁਕ ਨਹੀਂ; ਅਸੀਂ ਇਸ ਦੇ ਹੱਲ ਨੂੰ ਫਿਲਹਾਲ ਮੁਲਤਵੀ ਕਰ ਦਿੱਤਾ ਹੈ। ਅਸੀਂ ਇਸ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ ਤਕਨਾਲੋਜੀ ਨੂੰ ਇੱਕ ਵਿਕਲਪ ਵਜੋਂ ਵਿਚਾਰ ਰਹੇ ਹਾਂ ਏਕਤਾ ਦਾ ਨਿਰਮਾਣ (ਖਾਸ ਤੌਰ 'ਤੇ, Google Chrome ਬ੍ਰਾਊਜ਼ਰ ਨੂੰ ਵਿਕਸਤ ਕਰਨ ਵੇਲੇ ਇਸਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ)।

ਸਰੋਤ: www.habr.com