Bjarne Stroustrup ਅਤੇ C++: ਬਿਨਾਂ-ਖਰਚ ਵਾਲੀਆਂ ਐਬਸਟ੍ਰੈਕਸ਼ਨਾਂ ਕਿਉਂ ਮਾਇਨੇ ਰੱਖਦੀਆਂ ਹਨ

ਇਹ ਕਹਾਣੀ ਕੀ ਸਮਝਾਉਂਦੀ ਹੈ (ਅਤੇ ਇਹ ਮੈਟਰ ਕਿਉਂ ਹੈ)

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

ਇਹ ਪੋਸਟ ਇਸ ਗੱਲ ਦੀ ਕਹਾਣੀ ਹੈ ਕਿ Bjarne Stroustrup ਨੇ ਇਸ ਲਕੜੀ ਨੂੰ ਇਕ ਭਾਸ਼ਾ ਵਿੱਚ ਕਿਵੇਂ ਢਾਲਿਆ, ਅਤੇ ਇਹ ਵਿਚਾਰ ਅਜੇ ਵੀ ਕਿਉਂ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ। ਇਹ ਉਹਨਾਂ ਲਈ ਇੱਕ ਵਰਤੀਗਾਰੀ ਗਾਈਡ ਵੀ ਹੈ ਜੋ ਪ੍ਰਦਰਸ਼ਨ ਦੀ ਪਰਵਾਹ ਕਰਦੇ ਹਨ ਅਤੇ ਜਾਣਨਾ ਚਾਹੁੰਦੇ ਹਨ ਕਿ C++ ਕਿਸ ਚੀਜ਼ ਨੂੰ Optimize ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ—ਨਾਲੀ ਸਲੋਗਨਾਂ ਤੋਂ ਉੱਪਰ।

ਇੱਥੇ “ਉੱਚ-ਪ੍ਰਦਰਸ਼ਨ ਸਾਫਟਵੇਅਰ” ਦਾ ਮਤਲਬ ਕੀ ਹੈ

“ਉੱਚ-ਪ੍ਰਦਰਸ਼ਨ” ਸਿਰਫ਼ ਬੈਂਚਮਾਰਕ ਨੰਬਰ ਵਧਾਉਣ ਬਾਰੇ ਨਹੀਂ ਹੈ। ਸਧਾਰਨ ਸ਼ਬਦਾਂ ਵਿੱਚ, ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਹਾਲਤਾਂ ਵਿੱਚੋਂ ਕੋਈ ਇੱਕ ਸੱਚੀ ਹੁੰਦੀ ਹੈ:

• ਘੱਟ ਲੇਟੈਂਸੀ: ਕੰਮ ਹਰ ਥੋੜ੍ਹੇ ਸਮੇਂ ਦੇ ਅੰਦਰ ਖਤਮ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ (ਮਿਲੀਸਕਿੰਡ — ਜਾਂ ਮਾਈਕ੍ਰੋਸਕਿੰਡ)।
• ਉੱਚ ਥਰੂਪੁੱਟ: ਸਿਸਟਮ ਨਾਲ ਵਾਰ-ਵਾਰ ਕੰਮ ਪ੍ਰਤੀ ਸਕਿੰਟ ਕਰਨਾ ਲੋੜੀਂਦਾ ਹੈ (ਰਿਕਵੇਸਟ, ਫਰੇਮ, ਟਰੇਡ, ਪੈਕਟ)।
• ਸੀਮਤ ਸਰੋਤ: CPU, ਮੈਮੋਰੀ, ਬੈਟਰੀ ਜਾਂ ਪਾਵਰ ਸੀਮਤ ਹਨ, ਇਸ ਲਈ ਵਿਅਰਥ ਕੰਮ ਜਲਦੀ ਨਜ਼ਰ ਆਉਂਦਾ ਹੈ।

ਜਦੋਂ ਇਹ ਪਾਬੰਦੀਆਂ ਮਾਇਨੇ ਰੱਖਦੀਆਂ ਹਨ, ਤਾਂ ਛੁਪਿਆ ਹੋਇਆ ਓਵਰਹੈਡ—ਵਾਧੂ ਐਲੋਕੇਸ਼ਨ, ਬੇਕਾਰ ਨਕਲਾਂ, ਜਾਂ ਜਿੱਥੇ ਲੋੜ ਨਹੀਂ ਉੱਥੇ ਵਰਚੁਅਲ ਡਿਸਪੈਚ—“ਚੱਲਦਾ ਹੈ” ਅਤੇ “ਟਾਰਗੇਟ ਮਿਸ” ਦੇ ਵਿਚਕਾਰ ਫ਼ਰਕ ਹੋ ਸਕਦਾ ਹੈ।

ਅੱਜ ਕਿੱਥੇ C++ ਮਿਲਦਾ ਹੈ

C++ ਆਮ ਤੌਰ 'ਤੇ ਸਿਸਟਮ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਅਤੇ ਪਰਫਾਰਮੈਂਸ-ਸੰਵੇਦਨਸ਼ੀਲ ਕੰਪੋਨੈਂਟ ਲਈ ਵਰਤੀ ਜਾਂਦੀ ਹੈ: ਗੇਮ ਇੰਜਣ, ਬਰਾਊਜ਼ਰ, ਡੇਟਾਬੇਸ, ਗ੍ਰਾਫਿਕਸ ਪਾਈਪਲਾਈਨ, ਟਰੇਡਿੰਗ ਸਿਸਟਮ, ਰੋਬੋਟਿਕਸ, ਟੈਲੀਕੌਮ ਅਤੇ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਦੇ ਹਿੱਸੇ। ਇਹ ਇਕੱਲਾ ਵਿਕਲਪ ਨਹੀਂ ਹੈ, ਅਤੇ ਬਹੁਤ ਸਾਰੇ ਆਧੁਨਿਕ ਉਤਪਾਦ ਭਾਸ਼ਾਵਾਂ ਨੂੰ ਮਿਕਸ ਕਰਦੇ ਹਨ। ਪਰ ਜਦੋਂ ਟੀਮਾਂ ਨੂੰ ਇਹ ਨਿਯੰਤਰਣ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕੋਡ ਮਸ਼ੀਨ ਨਾਲ ਕਿਵੇਂ ਮੇਪ ਹੋਵੇ, ਤਾਂ C++ ਅਕਸਰ “ਅੰਦਰਲੀ-ਲੂਪ” ਟੂਲ ਬਣ ਕੇ ਰਹਿੰਦੀ ਹੈ।

ਹੋਂਡਰ, ਅਸੀਂ ਜ਼ੀਰੋ-ਕੋਸਟ ਵਿਚਾਰ ਨੂੰ ਸਾਧਾ ਅੰਗਰੇਜ਼ੀ ਵਿੱਚ ਖੋਲਾਂਗੇ, ਫਿਰ ਇਸਨੂੰ ਖਾਸ C++ ਤਕਨੀਕਾਂ (ਜਿਵੇਂ RAII ਅਤੇ ਟੇmplੇਟ) ਨਾਲ ਜੋੜਾਂਗੇ ਅਤੇ ਉਹ ਅਸਲ ਟਰੇਡ-ਆਫ਼ ਜਿਹੜੇ ਟੀਮਾਂ ਨਾਲ ਮੁਕਾਬਲਾ ਹੁੰਦੇ ਹਨ, ਵੇਖਾਂਗੇ।

Bjarne Stroustrup ਦਾ ਟੀਚਾ: ਬਿਨਾਂ ਸਜ਼ਾ ਦੇ ਐਬਸਟ੍ਰੈਕਸ਼ਨ

Bjarne Stroustrup ਨੇ ਇੱਕ ਨਵੀਂ ਭਾਸ਼ਾ “ਖੁਦ ਲਈ” ਬਣਾਉਣ ਦਾ ਫੈਸਲਾ ਨਹੀਂ ਕੀਤਾ। 1970s ਅਤੇ 1980s ਦੇ ਅਖੀਰਲੇ ਦਹਾਕੇ ਵਿੱਚ, ਉਹ ਸਿਸਟਮ ਕੰਮ ਕਰ ਰਹੇ ਸੀ ਜਿੱਥੇ C ਤੇਜ਼ ਅਤੇ ਮਸ਼ੀਨ ਦੇ ਨੇੜੇ ਸੀ, ਪਰ ਵੱਡੇ ਪ੍ਰੋਗਰਾਮਾਂ ਨੂੰ ਠੀਕ ਢੰਗ ਨਾਲ ਢਾਂਚਾ ਦੇਣਾ ਮੁਸ਼ਕਲ, ਬਦਲਣਾ ਔਖਾ ਅਤੇ ਟੁੱਟਣਾ ਆਸਾਨ ਸੀ।

ਉਹਦਾ ਲਕਸ਼ ਸਧਾ ਸੀ ਪਰ ਪ੍ਰਾਪਤ ਕਰਨਾ ਔਖਾ: ਵੱਡੇ ਪ੍ਰੋਗਰਾਮਾਂ ਨੂੰ ਢਾਂਚਾ ਦੇਣ ਦੇ ਚੰਗੇ ਤਰੀਕੇ—ਟਾਈਪ, ਮੋਡੀਊਲ, ਇਨਕੈਪਸੂਲੇਸ਼ਨ—ਲਿਆਓ ਬਿਨਾਂ ਉਸ ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਹਾਰਡਵੇਅਰ ਐਕਸੈਸ ਨੂੰ ਛੱਡੇ ਜੋ C ਨੂੰ ਕੀਮਤੀ ਬਣਾਉਂਦੇ ਹਨ।

“C with Classes” ਤੋਂ C++ ਤੱਕ

ਸਭ ਤੋਂ ਪਹਿਲਾ ਕਦਮ ਲਫ਼ਜ਼ੀ ਤੌਰ 'ਤੇ “C with Classes” ਨਾਮ ਦੇ ਨਾਲ ਸੀ। ਇਹ ਨਾਂ ਦਿਸਾਉਂਦਾ ਹੈ ਕਿ ਮਕਸਦ ਇੱਕ ਪੂਰੇ ਸਲੇਟ ਦੀ ਦੁਬਾਰਾ ਡਿਜ਼ਾਈਨ ਨਹੀਂ ਸੀ, ਪਰ ਇੱਕ ਇਵੋਲੂਸ਼ਨ। C ਦੀਆਂ ਵਧੀਆਆਂ ਗੁਣਾਂ (ਪੇਸ਼ਗੋਹੀਤ ਪਰਫਾਰਮੈਂਸ, ਸੀਧਾ ਮੈਮੋਰੀ ਐਕਸੈਸ, ਸਾਦਾ ਕਾਲਿੰਗ ਕਨਵੈਨਸ਼ਨ) ਨੂੰ ਰੱਖੋ, ਫਿਰ ਵੱਡੇ ਸਿਸਟਮ ਬਣਾਉਣ ਲਈ ਘੁੱਟੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਸ਼ਾਮਿਲ ਕਰੋ।

ਜਿਵੇਂ-ਜਿਵੇਂ ਭਾਸ਼ਾ C++ ਵਿੱਚ ਵਿਕਸਤ ਹੋਈ, ਜੋੜੀਆਂ ਗਈਆਂ ਚੀਜ਼ਾਂ ਸਿਰਫ਼ “ਵੱਧ ਫੀਚਰ” ਨਹੀਂ ਸਨ। ਉਹ ਇਸ ਉਦੇਸ਼ ਲਈ ਡਿਜ਼ਾਈਨ ਕੀਤੀਆਂ ਗਈਆਂ ਸਨ ਕਿ ਜਦੋਂ ਸੋਝੀ-ਵਿਹਾਰ ਨਾਲ ਵਰਤਿਆ ਜਾਵੇ ਤਾਂ ਉੱਚ-ਪੱਧਰ ਦਾ ਕੋਡ ਉਹੋ ਹੀ ਮਸ਼ੀਨ ਕੋਡ ਬਣੇ ਜੋ ਤੁਸੀਂ C ਵਿੱਚ ਹੱਥੋਂ-ਲਿਖਿਆ ਹੋਵੋਗੇ।

ਡਿਜ਼ਾਈਨ ਦਾ ਸੰਘਰਸ਼: ਸਹੂਲਤ ਬਨਾਮ ਕਨਟਰੋਲ

Stroustrup ਦਾ ਮੱਤਵ ਉਹੀ ਰਿਹਾ—ਅਤੇ ਅਜੇ ਵੀ ਹੈ—ਦੋਹਾਂ ਦੇ ਵਿਚਕਾਰ:

• ਸਹੂਲਤ: ਸੁਰੱਖਿਅਤ ਡਿਫ਼ਾਲਟ, ਦੁਹਰਾਏ-ਜਾ ਸਕਣ ਵਾਲੇ ਕੰਪੋਨੈਂਟ, ਅਭਿਵਾਂਚਕ ਐਬਸਟ੍ਰੈਕਸ਼ਨ।
• ਨਿਆੰਤਰਣ: ਲੇਆਉਟ ਚੁਣਨ ਦੀ ਸਮਰੱਥਾ, ਲਾਈਫਟਾਈਮ ਦੀ ਪ੍ਰਬੰਧਨਾ, ਅਤੇ ਖ਼ਰਚਾਂ ਬਾਰੇ ਸੋਚਣ ਦੀ ਯੋਗਤਾ।

ਬਹੁਤ ਸਾਰੀਆਂ ਭਾਸ਼ਾਵਾਂ ਵੇਖਣ ਦੇ ਤਰੀਕੇ ਨੂੰ ਛੁਪਾ ਦਿੰਦੀਆਂ ਹਨ (ਜੋ ਓਵਰਹੈਡ ਨੂੰ ਛੁਪਾ ਸਕਦਾ ਹੈ)। C++ ਤੁਹਾਨੂੰ ਐਬਸਟ੍ਰੈਕਸ਼ਨ ਬਣਾਉਣ ਦਿੰਦੀ ਹੈ ਜਦੋਂ ਕਿ ਤੁਸੀਂ ਹਮੇਸ਼ਾ ਪੁੱਛ ਸਕਦੇ ਹੋ, “ਇਸ ਦੀ ਕੀਮਤ ਕੀ ਹੈ?” ਅਤੇ ਜ਼ਰੂਰਤ ਪੈਣ 'ਤੇ ਨੀਵੇਂ ਪੱਧਰ ਤੇ ਜਾ ਸਕਦੇ ਹੋ।

ਇਹ ਪ੍ਰੇਰਣਾ—ਸਜ਼ਾ ਬਿਨਾਂ ਐਬਸਟ੍ਰੈਕਸ਼ਨ—C++ ਦੀ ਸ਼ੁਰੂਆਤੀ ਕਲਾਸ ਸਹਾਇਤਾ ਤੋਂ ਲੈ ਕੇ RAII, ਟੇmplੇਟ ਅਤੇ STL ਵਰਗੀਆਂ ਵਾਦੀਆਂ ਤੱਕ ਜੁੜੀ ਰਹੀ।

ਜ਼ੀਰੋ-ਕੋਸਟ ਐਬਸਟ੍ਰੈਕਸ਼ਨ: ਸਧਾਰਨ ਅੰਗ੍ਰੇਜ਼ੀ ਵਿੱਚ ਮੁੱਖ ਵਿਚਾਰ

“ਜ਼ੀਰੋ-ਕੋਸਟ ਐਬਸਟ੍ਰੈਕਸ਼ਨ” ਇੱਕ ਨਾਰੇ ਵਾਂਗ ਨਹੀਂ ਹੈ; ਇਹ ਵਪਾਰ-ਸੰਬੰਧੀ ਪ੍ਰਭਾਵਾਂ ਬਾਰੇ ਇਕ ਵਾਅਦਾ ਹੈ। ਰੋਜ਼ਾਨਾ ਵਰਜਨ ਇਹ ਹੈ:

ਜੇ ਤੁਸੀਂ ਇਸਨੂੰ ਵਰਤਦੇ ਨਹੀਂ, ਤਾਂ ਤੁਸੀਂ ਇਸਦੀ ਕੀਮਤ ਨਹੀਂ ਭੁਗਤੋਂਗੇ। ਅਤੇ ਜੇ ਤੁਸੀਂ ਵਰਤਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਲਗਭਗ ਉਸੇ ਦੇਨਗੇ ਜੋ ਤੁਸੀਂ ਹੱਥੋਂ-ਲਿਖਿਆ ਨੀਵੇ ਪੱਧਰ ਵਾਲੇ ਕੋਡ ਲਈ ਦਿੰਦੇ।

“ਲਾਗਤ” ਅਸਲ ਵਿੱਚ ਕੀ ਹੁੰਦੀ ਹੈ

ਪ੍ਰਦਰਸ਼ਨ ਸ਼ਬਦਾਂ ਵਿੱਚ, “ਲਾਗਤ” ਕੁਝ ਵੀ ਹੋ ਸਕਦੀ ਹੈ ਜੋ ਰਨਟਾਈਮ 'ਤੇ ਪ੍ਰੋਗਰਾਮ ਨੂੰ ਵਧੇਰੇ ਕੰਮ ਕਰਨ ਉਤੇ ਮਜਬੂਰ ਕਰੇ। ਇਸ ਵਿੱਚ ਸ਼ਾਮਿਲ ਹੋ ਸਕਦਾ ਹੈ:

• ਅਤਿਰਿਕਤ CPU ਨਿਰਦੇਸ਼ ਜੋ ਲੋੜੀਂਦੇ ਨਹੀਂ ਸਨ
• ਛੁਪਿਆ ਹੋਇਆ ਮੈਮੋਰੀ ਐਲੋਕੇਸ਼ਨ
• ਵਾਧੂ ਪੋਇੰਟਰ ਇੰਡੀਰੈਕਸ਼ਨ (ਡਾਟਾ ਤੱਕ ਪਹੁੰਚਣ ਲਈ ਹੋਰ “ਹੌਪਸ”)
• ਜਿੱਥੇ ਸਧਾਰਨ ਕਾਲ ਕਾਫੀ ਹੁੰਦੀ, ਉਥੇ ਵਰਚੁਅਲ ਕਾਲਜ਼ ਅਤੇ ਡਾਇਨੈਕਮਿਕ ਡਿਸਪੈਚ
• ਅਦ੍ਰਸ਼ਟ ਬੁੱਕਕੀਪਿੰਗ (ਰੇਫ਼ਕਾਊਂਟਿੰਗ, ਲੌਗਿੰਗ ਹੂਕ, ਜਾਂ ਸੁਰੱਖਿਆ ਚੈੱਕ) ਜੋ ਤੁਸੀਂ ਨਹੀਂ ਮੰਗੇ

ਜ਼ੀਰੋ-ਕੋਸਟ ਐਬਸਟ੍ਰੈਕਸ਼ਨ ਤੁਹਾਨੂੰ ਸਾਫ਼, ਉੱਚ-ਪੱਧਰ ਦਾ ਕੋਡ ਲਿਖਣ ਦਿੰਦੇ ਹਨ—ਟਾਈਪ, ਕਲਾਸ, ਫੰਕਸ਼ਨ, ਜਨਰਿਕ ਅਲਗੋਰਿਦਮ—ਜਦੋਂ ਕਿ ਮਸ਼ੀਨ ਕੋਡ ਹੱਥੋਂ-ਲਿਖੇ ਲੂਪਾਂ ਅਤੇ ਮੈਨੁਅਲ ਸੰਸਾਧਨ ਪ੍ਰਬੰਧਨ ਵਾਂਗ ਸਿੱਧਾ ਬਣ ਸਕਦਾ ਹੈ।

ਮਹੱਤਵਪੂਰਕ ਉਲਟ ਪਾਸਾ

C++ ਹਰ ਚੀਜ਼ ਨੂੰ ਆਪੋ-ਆਪ ਹੀ ਤੇਜ਼ ਨਹੀਂ ਬਣਾਉਂਦਾ। ਇਹ ਸਾਂਭਦਾ ਹੈ ਕਿ ਉੱਚ-ਪੱਧਰ ਦਾ ਕੋਡ ਪ੍ਰਭਾਵਸ਼ালী ਤੌਰ 'ਤੇ ਕੰਪਾਇਲ ਹੋ ਸਕਦਾ ਹੈ—ਪਰ ਤੁਸੀਂ ਅਜੇ ਵੀ ਮਹਿੰਗੇ ਪੈਟਰਨ ਚੁਣ ਸਕਦੇ ਹੋ।

ਜੇ ਤੁਸੀਂ ਹਾਟ ਲੂਪ ਵਿੱਚ ਐਲੋਕੇਟ ਕਰਦੇ ਹੋ, ਵੱਡੇ ਆਬਜੈਕਟਾਂ ਦੀਆਂ ਬਾਰ-ਬਾਰ ਨਕਲਾਂ ਕਰਦੇ ਹੋ, ਕੈਸ਼-ਦੋਸਤ ਲੇਆਉਟ ਵਿਖੇ ਗਲਤੀ ਕਰਦੇ ਹੋ, ਜਾਂ ਇੰਡਾਇਰੈਕਸ਼ਨ ਦੀਆਂ ਲੇਅਰਾਂ ਬਣਾਉਂਦੇ ਹੋ ਜੋ ਅਪਟੀਮਾਈਜ਼ੇਸ਼ਨ ਨੂੰ ਰੋਕਦੀਆਂ ਹਨ, ਤਾਂ ਤੁਹਾਡਾ ਪ੍ਰੋਗਰਾਮ ਧੀਮਾ ਹੋ ਜਾਵੇਗਾ। C++ ਤੁਹਾਨੂੰ ਰੋਕੇਗਾ ਨਹੀਂ। “ਜ਼ੀਰੋ-ਕੋਸਟ” ਮਕਸਦ ਉਹਨਾਂ ਚੀਜ਼ਾਂ ਤੋਂ ਬਚਾਓ ਕਰਨ ਬਾਰੇ ਹੈ ਜੋ ਜ਼ਬਰਦਸਤੀ ਓਵਰਹੈਡ ਲਗਾਉਂਦੀਆਂ ਹਨ, ਨਾ ਕਿ ਚੰਗੇ ਫੈਸਲੇ ਦੀ ਗਾਰੰਟੀ ਦੇਣ ਬਾਰੇ।

ਅਗਲੀ ਰਾਹਦਾਰੀ

ਲੇਖ ਦੇ ਬਾਕੀ ਹਿੱਸੇ ਵਿੱਚ ਅਸੀਂ ਇਸ ਵਿਚਾਰ ਨੂੰ ਠੋਸ ਬਣਾਉਂਦੇ ਹਾਂ। ਅਸੀਂ ਵੇਖਾਂਗੇ ਕਿ ਕੰਪਾਈਲਰ ਅਬਸਟ੍ਰੈਕਸ਼ਨ ਓਵਰਹੈਡ ਕਿਵੇਂ ਮਿਟਾਉਂਦਾ ਹੈ, RAII ਕਿਵੇਂ ਸੁਰੱਖਿਆ ਅਤੇ ਤੇਜ਼ੀ ਦੋਹਾਂ ਦੇ ਸਕਦਾ ਹੈ, ਟੇmplੇਟ ਕਿਵੇਂ ਹੱਥੋਂ-ਟਿਊਨ ਕੀਤੇ ਵਰਜਨਾਂ ਵਾਂਗ ਚਲਦੇ ਕੋਡ ਬਣਾਉਂਦੇ ਹਨ, ਅਤੇ STL ਕਿਸ ਤਰ੍ਹਾਂ ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੇ ਬਿਲਡਿੰਗ ਬਲੌਕ ਦਿੰਦਾ ਹੈ ਬਿਨਾਂ ਚੁਪਚਾਪ ਰਨਟਾਈਮ ਕੰਮ ਦੇ—ਜਦੋਂ इन्हें ਧਿਆਨ ਨਾਲ ਵਰਤਿਆ ਜਾਵੇ।

C++ ਕਿਵੇਂ ਐਬਸਟ੍ਰੈਕਸ਼ਨਾਂ ਨੂੰ ਸਸਤਾ ਬਣਾਉਂਦਾ ਹੈ: ਕੰਪਾਈਲਰ ਕੀ ਕਰਦਾ ਹੈ

C++ ਇੱਕ ਸਧਾਰਨ ਬਦਲੇ ਤੇ ਆਸਰਾ ਰੱਖਦਾ ਹੈ: ਬਿਲਡ ਟਾਈਮ 'ਤੇ ਵੱਧ ਭੁਗਤੋ ਤਾਂ ਜੋ ਰਨਟਾਈਮ 'ਤੇ ਘੱਟ ਭੁਗਤੋ। ਜਦੋਂ ਤੁਸੀਂ ਕੰਪਾਈਲ ਕਰਦੇ ਹੋ, ਕੰਪਾਈਲਰ ਸਿਰਫ਼ ਤੁਹਾਡੇ ਕੋਡ ਦਾ ਅਨੁਵਾਦ ਨਹੀਂ ਕਰਦਾ—ਉਹ ਉਹਨਾਂ ਓਵਰਹੈਡਾਂ ਨੂੰ ਹਟਾਉਣ ਲਈ ਕਾਫ਼ੀ ਮਿਹਨਤ ਕਰਦਾ ਹੈ ਜੋ ਹੋਰਥਾਂ ਪ੍ਰੋਗਰਾਮ ਚਲਦੇ ਸਮੇਂ ਦਿਖਾਈ ਦਿੰਦੀਆਂ।

ਬਿਲਡ ਟਾਈਮ 'ਤੇ ਖ਼ਰਚ ਅਦਾ ਕਰਨਾ

ਕੰਪਾਈਲਰ ਦਰਮਿਆਨ ਇਹਨਾਂ ਖ਼ਰਚਾਂ ਨੂੰ “ਪਹਿਲਾਂ ਹੀ ਭੁਗਤ ਸਕਦਾ” ਹੈ:

• ਇਨਲਾਈਨਿੰਗ: ਇੱਕ ਫੰਕਸ਼ਨ ਕਾਲ ਨੂੰ ਉਸਦੇ ਬਾਡੀ ਨਾਲ ਬਦਲਨਾ।
• ਕਾਂਸਟੈਂਟ ਫੋਲਡਿੰਗ: ਕਾਂਸਟੈਂਟ ਐਕਸਪ੍ਰੈਸ਼ਨਾਂ ਨੂੰ ਪਹਿਲਾਂ ਹੀ ਹਿਸਾਬ ਕਰਨਾ।
• ਅਪਟੀਮਾਈਜ਼ੇਸ਼ਨ ਪਾਸ: ਕੰਟਰੋਲ ਫਲੋ ਨੂੰ ਸਧਾਰਨਾ, ਡੈਡ ਕੋਡ ਹਟਾਉਣਾ, ਅਤੇ ਲੂਪਾਂ ਨੂੰ ਤੀਖਾ ਕਰਨਾ।

ਮਕਸਦ ਇਹ ਹੈ ਕਿ ਤੁਹਾਡੀ ਸਾਫ਼, ਪੜ੍ਹਨਯੋਗ ਸੰਰਚਨਾ ਅਜੇਹੇ ਮਸ਼ੀਨ ਕੋਡ ਵਿੱਚ ਬਦਲ ਜਾਵੇ ਜੋ ਤੁਸੀਂ ਹੱਥੋਂ-ਲਿਖਣ 'ਤੇ ਬਣਾਉਂਦੇ।

ਸਮਝਣਯੋਗ ਉਦਾਹਰਣਾਂ

ਇੱਕ ਛੋਟਾ ਸਹਾਇਕ ਫੰਕਸ਼ਨ ਜਿਵੇਂ:

int add_tax(int price) { return price * 108 / 100; }

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

ਲੂਪਾਂ ਨੂੰ ਵੀ ਧਿਆਨ ਮਿਲਦਾ ਹੈ। ਇੱਕ ਇਕਸਾਰ ਰੇਂਜ ਉੱਤੇ ਸਿਧਾ ਲੂਪ ਆਪਟੀਮਾਈਜ਼ਰ ਦੁਆਰਾ ਬਦਲਾਂ ਜਾ ਸਕਦਾ ਹੈ: ਜਦੋਂ ਸਾਬਤ ਤੌਰ 'ਤੇ ਲਾਜ਼ਮੀ ਨਾ ਹੋਵੇ ਤਾਂ ਬਾਊਂਡ ਚੈਕ ਹਟਾਏ ਜਾ ਸਕਦੇ ਹਨ, ਦੁਹਰਾਏ ਗਏ ਹਿਸਾਬ ਲੂਪ ਤੋਂ ਬਾਹਰ ਖਿੱਚੇ ਜਾ ਸਕਦੇ ਹਨ, ਅਤੇ ਲੂਪ ਬਾਡੀ ਨੂੰ CPU ਦੀ ਵਰਤੋਂ ਲਈ ਦੁਬਾਰਾ ਢਾਂਚਾ ਦਿੱਤਾ ਜਾ ਸਕਦਾ ਹੈ।

“ਗਾਇਬ ਹੋਣ ਵਾਲੀ ਐਬਸਟ੍ਰੈਕਸ਼ਨ”

ਇਹ ਜ਼ੀਰੋ-ਕੋਸਟ ਐਬਸਟ੍ਰੈਕਸ਼ਨਾਂ ਦਾ ਪ੍ਰਾਇਗਿਕ ਅਰਥ ਹੈ: ਤੁਸੀਂ ਸਾਫ਼ ਕੋਡ ਪਾਉਂਦੇ ਹੋ ਬਿਨਾਂ ਉਸ ਰਚਨਾ ਲਈ ਸਥਾਈ ਰਨਟਾਈਮ ਫੀਸ ਭੁਗਤਣ ਦੇ।

ਟਰੇਡ-ਆਫ਼

ਕੋਈ ਚੀਜ਼ ਮੁਫ਼ਤ ਨਹੀਂ। ਵੱਧ ਅਪਟੀਮਾਈਜ਼ੇਸ਼ਨ ਅਤੇ ਹੋਰ “ਗਾਇਬ ਹੋਣ ਵਾਲੀਆਂ ਐਬਸਟ੍ਰੈਕਸ਼ਨਾਂ” ਦਾ ਮਤਲਬ ਹੋ ਸਕਦਾ ਹੈ ਲੰਬਾ ਕੰਪਾਈਲ ਸਮਾਂ ਅਤੇ ਕਈ ਵਾਰੀ ਵੱਡੇ ਬਾਈਨਰੀ (ਜਿਵੇਂ, ਜਦੋਂ ਕਈ ਕਾਲ ਸਾਈਟਾਂ ਇਨਲਾਈਨ ਹੋ ਜਾਂਦੀਆਂ ਹਨ)। C++ ਤੁਹਾਨੂੰ ਚੋਣ ਅਤੇ ਜ਼ਿੰਮੇਵਾਰੀ ਦਿੰਦਾ ਹੈ ਕਿ ਬਿਲਡ ਖ਼ਰਚ ਅਤੇ ਰਨਟਾਈਮ ਗਤੀਵਿਧੀ ਵਿੱਚ ਕਿਵੇਂ ਸੰਤੁਲਨ ਬਣਾਇਆ ਜਾਵੇ।

RAII: ਆਟੋਮੈਟਿਕ ਕਲੀਨਅਪ ਰਾਹੀਂ ਸੁਰੱਖਿਆ ਅਤੇ ਤੇਜ਼ੀ

RAII (Resource Acquisition Is Initialization) ਇੱਕ ਸਧਾਰਨ ਨਿਯਮ ਹੈ ਜਿਸਦੇ ਵੱਡੇ ਨਤੀਜੇ ਹੁੰਦੇ ਹਨ: ਸੰਸਾਧਨ ਦੀ ਉਮਰ ਇੱਕ ਸਕੋਪ ਨਾਲ ਜੁੜੀ ਹੁੰਦੀ ਹੈ। ਜਦੋਂ ਇੱਕ ਆਬਜੈਕਟ ਬਣਦਾ ਹੈ, ਉਹ ਸੰਸਾਧਨ ਪ੍ਰਾਪਤ ਕਰ ਲੈਂਦਾ ਹੈ। ਜਦੋਂ ਆਬਜੈਕਟ ਸਕੋਪ ਤੋਂ ਬਾਹਰ ਨਿਕਲਦਾ ਹੈ, ਉਸਦਾ ਡੈਸਟਰਕਟਰ ਇਸਨੂੰ ਰਿਲੀਜ਼ ਕਰ ਦਿੰਦਾ—ਆਟੋਮੈਟਿਕ ਤਰੀਕੇ ਨਾਲ।

ਉਹ “ਸੰਸਾਧਨ” ਲਗਭਗ ਕਿਸੇ ਵੀ ਚੀਜ਼ ਹੋ ਸਕਦੀ ਹੈ ਜਿਸਦੀ ਤੁਸੀਂ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਸਫਾਈ ਦੀ ਲੋੜ ਹੈ: ਮੈਮੋਰੀ, ਫਾਇਲ, ਮਿਊਟੈਕਸ ਲਾਕ, ਡੇਟਾਬੇਸ ਹੈਂਡਲ, ਸਾਕਟ, GPU ਬਫਰ ਆਦਿ। ਹਰ ਰੀਟਰਨ ਪਾਥ 'ਤੇ close(), unlock(), ਜਾਂ free() ਯਾਦ ਰੱਖਣ ਦੀ ਥਾਂ, ਤੁਸੀਂ ਕਲੀਨਅਪ ਨੂੰ ਇੱਕ ਥਾਂ (ਡੈਸਟਰਕਟਰ) ਵਿੱਚ ਰੱਖਦੇ ਹੋ ਅਤੇ ਭਾਸ਼ਾ ਇਹ ਗਾਰੰਟੀ ਕਰਦੀ ਹੈ ਕਿ ਇਹ ਚੱਲੇਗਾ।

RAII ਅਕਸਰ ਕਿਵੇਂ ਤੇਜ਼ ਅਤੇ ਸੁਰੱਖਿਅਤ ਹੈ

ਮੇਨੂਅਲ ਕਲੀਨਅਪ ਅਕਸਰ “ਸ਼ੈਡੋ ਕੋਡ” ਪੈਦਾ ਕਰਦਾ ਹੈ: ਵਾਧੂ if ਚੈੱਕ, ਨਕਲ ਕੀਤੇ ਹੋਏ return ਹੈਂਡਲਿੰਗ, ਅਤੇ ਹਰ ਸੰਭਵ ਤਰੁੱਟੀ ਮਾਰਗ ਤੋਂ ਬਾਅਦ ਧਿਆਨ ਨਾਲ ਰੱਖੇ ਗਏ ਕਲੀਨਅਪ ਕਾਲ। ਫੰਕਸ਼ਨਾਂ ਦੇ ਵਿਕਸਤ ਹੋਣ ਨਾਲ ਇੱਕ ਸ਼ਾਖ ਨੂੰ ਭੁਲਾਉਣਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ।

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

ਪ੍ਰਦਰਸ਼ਨ ਦੀ ਭਵਿੱਖਬਾਣੀ—ਅਤੇ ਘੱਟ ਹੈਰਾਨੀਆਂ

ਲੀਕ ਅਤੇ ਰਿਲੀਜ਼ ਨਾ ਹੋਏ ਲਾਕ ਸਿਰਫ਼ “ਸਹੀਤਾ ਮੁੱਦੇ” ਨਹੀਂ; ਉਹ ਪ੍ਰਦਰਸ਼ਨ ਲਈ ਲੰਬੇ ਸਮੇਂ ਦੇ ਬੰਬ ਹੁੰਦੇ ਹਨ। RAII ਸੰਸਾਧਨ ਰਿਹਾ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਿਯਤ ਬਨਾਉਂਦਾ ਹੈ, ਜੋ ਲੋਡ ਹੇਠ ਸਿਸਟਮਾਂ ਨੂੰ ਸਥਿਰ ਰੱਖਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ।

Exceptions 'ਤੇ ਇੱਕ ਸਾਵਧਾਨ ਨੋਟ

Exceptions ਨਾਲ RAII ਚਮਕਦੀ ਹੈ ਕਿਉਂਕਿ ਸਟੈਕ ਅਨਵਾਇਂਡਿੰਗ ਦੌਰਾਨ ਡੈਸਟਰਕਟਰ ਫਿਰ ਵੀ ਚਲਦੇ ਹਨ, ਇਸ ਲਈ ਸੰਸਾਧਨ ਛੁੱਟ ਜਾਂਦੇ ਹਨ ਭਾਵੇਂ ਕੰਟਰੋਲ ਫਲੋ ਅਚਾਨਕ ਕਿਉਂ ਨਾ ਵਰਿੱਕੇ। Exceptions ਇੱਕ ਟੂਲ ਹਨ: ਉਹਦੀ ਲਾਗਤ ਇਸ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ ਕਿ ਉਹ ਕਿਵੇਂ ਵਰਤੇ ਜਾਂਦੇ ਹਨ ਅਤੇ ਕੰਪਾਈਲਰ/ਪਲੈਟਫਾਰਮ ਸੈਟਿੰਗਜ਼ ਕੀ ਹਨ। ਮੁੱਖ ਗੱਲ ਇਹ ਹੈ ਕਿ RAII ਕਿਸੇ ਵੀ ਤਰੀਕੇ ਨਾਲ ਸਕੋਪ ਛੱਡਣ 'ਤੇ ਕਲੀਨਅਪ ਨਿਰਧਾਰਤ ਰੱਖਦੀ ਹੈ।

ਟੇmplੇਟ ਅਤੇ ਜਨਰਿਕ ਕੋਡ ਜੋ ਹੱਥੋਂ-ਲਿਖੇ ਕੋਡ ਵਾਂਗ ਚਲਦੇ ਹਨ

ਟੇmplੇਟਾਂ ਨੂੰ ਅਕਸਰ “ਕੰਪਾਇਲ-ਟਾਈਮ ਕੋਡ ਜਨਰੇਸ਼ਨ” ਵਜੋਂ ਵੇਖਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਇਹ ਇੱਕ ਉਪਯੋਗਕਾਰੀ ਸੋਚ ਦਾ ਮਾਡਲ ਹੈ। ਤੁਸੀਂ ਇਕ ਵਾਰੀ ਐਲਗੋਰਿਦਮ ਲਿਖਦੇ ਹੋ—ਉਦਾਹਰਨ ਵਜੋਂ, “ਇਹਨਾਂ ਆਇਟਮਾਂ ਨੂੰ ਸੋਰਟ ਕਰੋ” ਜਾਂ “ਆਇਟਮਾਂ ਨੂੰ ਇੱਕ ਕਨਟੇਨਰ ਵਿੱਚ ਸਟੋਰ ਕਰੋ”—ਅਤੇ ਕੰਪਾਈਲਰ ਉਹ ਵਰਜਨ ਉਸੇ ਦੀਆਂ ਨਿਰਧਾਰਤ ਕਿਸਮਾਂ ਲਈ ਤਿਆਰ ਕਰਦਾ ਹੈ।

ਕੰਪਾਇਲ-ਟਾਈਮ ਵਿਸ਼ੇਸ਼ੀਕਰਨ (ਰਨਟਾਈਮ ਬਿੱਲ ਤੋਂ ਬਿਨਾਂ)

ਕੰਪਾਈਲਰ ਨੂੰ ਜਦੋਂ ਸੰਕੁਚਿਤ ਕਿਸਮਾਂ ਪਤਾ ਹੁੰਦੀਆਂ ਹਨ, ਉਹ ਇਨਲਾਈਨ ਕਰ ਸਕਦਾ ਹੈ, ਢੰਗ ਦੇ ਅਨੁਸਾਰ ਓਪਰੇਸ਼ਨ ਚੁਣ ਸਕਦਾ ਹੈ, ਅਤੇ ਜੋਰ ਨਾਲ ਅਪਟੀਮਾਈਜ਼ ਕਰ ਸਕਦਾ ਹੈ। ਕਈ ਹਾਲਤਾਂ ਵਿੱਚ, ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਸੀਂ ਵਰਚੁਅਲ ਕਾਲਜ਼, ਰਨਟਾਈਮ ਟਾਈਪ ਚੈਕ ਅਤੇ ਡਾਇਨਾਮਿਕ ਡਿਸਪੈਚ ਤੋਂ ਬਚ ਜਾਂਦੇ ਹੋ ਜਿਨ੍ਹਾਂ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਸੀ ਜੇ ਕੋਡ “ਜਨਰਿਕ” ਬਣਾਉਣਾ ਸੀ।

ਉਦਾਹਰਨ ਵਜੋਂ, ਇੱਕ ਟੇmplੇਟ max(a, b) ਇੰਟੀਜਰਾਂ ਲਈ ਕੁੱਝ ਮਸ਼ੀਨ ਨਿਰਦੇਸ਼ ਬਣ ਸਕਦੀ ਹੈ।ੋਸੇ ਟੇmplੇਟ ਨੂੰ ਛੋਟੀ struct ਨਾਲ ਵਰਤਣਾ ਫਿਰ ਵੀ ਸੀਧੀ ਤੁਲਨਾ ਅਤੇ ਮੂਵਾਂ ਵਿੱਚ ਕੰਪਾਇਲ ਹੋ ਸਕਦਾ ਹੈ—ਕੋਈ ਇੰਟਰਫੇਸ ਪੋਇੰਟਰ ਜਾਂ ਰਨਟਾਈਮ “ਇਹ ਕਿਸਮ ਹੈ?” ਚੈੱਕ ਨਹੀਂ।

ਜਨਰਿਕ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਜੋ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਵਰਤ ਚੁਕੇ ਹੋ

Standard Library ਟੇmplੇਟਾਂ 'ਤੇ ਬਹੁਤ ਨਿਰਭਰ ਹੈ ਕਿਉਂਕਿ ਉਹ ਉਨ੍ਹਾਂ ਨੂੰ ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੇ ਬਿਲਡਿੰਗ ਬਲੌਕ ਦਿੰਦੇ ਹਨ ਬਿਨਾਂ ਛੁਪੇ ਕੰਮ ਦੇ:

• std::vector<T> ਅਤੇ std::array<T, N> ਤੁਹਾਡੀ T ਨੂੰ ਸਿੱਧਾ ਸਟੋਰੇਜ ਕਰਦੇ ਹਨ।
• std::sort ਵਰਗੇ ਅਲਗੋਰਿਦਮ ਬਹੁਤ ਸਾਰੀਆਂ ਕਿਸਮਾਂ 'ਤੇ ਕੰਮ ਕਰਦੇ ਹਨ ਜੇ ਤੱਕ ਉਹ ਤੁਲਨਾ ਯੋਗ ਹਨ।
• ਇਟਰੇਟਰਾਂ ਨੇ ਉਦੋਂ ਹੀ ਇੱਕੋ ਅਲਗੋਰਿਦਮ ਨੂੰ ਵਿਭਿੰਨ ਕਨਟੇਨਰਾਂ ਉੱਤੇ ਚਲਾਉਣ ਦੀ ਆਸਾਨੀ ਦਿੰਦੀ ਹੈ।

ਨਤੀਜਾ ਅਕਸਰ ਇਹ ਹੁੰਦਾ ਹੈ ਕਿ ਕੋਡ ਇੱਕ ਹੱਥੋਂ-ਲਿਖੇ, ਕਿਸਮ-ਨਿਰਧਾਰਤ ਵਰਜਨ ਵਾਂਗ ਹੀ ਪ੍ਰਦਰਸ਼ਨ ਕਰਦਾ ਹੈ—ਕਿਉਂਕਿ ਇਹ ਅਸਲ ਵਿੱਚ ਉਹੀ ਬਣ ਜਾਂਦਾ ਹੈ।

ਟਰੇਡ-ਆਫ਼

ਡਿਵੈਲਪਰਾਂ ਲਈ ਟੇmplੇਟ ਮੁਫ਼ਤ ਨਹੀਂ। ਉਹ ਕੰਪਾਈਲ ਟਾਈਮ ਵਧਾ ਸਕਦੇ ਹਨ (ਜਿਆਦਾ ਕੋਡ ਬਣਾਉਣ ਅਤੇ Optimize ਕਰਨ ਲਈ), ਅਤੇ ਜਦੋਂ ਕੁਝ ਗਲਤ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਐਰਰ ਸੁਨੇਹੇ ਲੰਬੇ ਅਤੇ ਪੜ੍ਹਨ ਵਿੱਚ ਔਖੇ ਹੋ ਸਕਦੇ ਹਨ। ਟੀਮਾਂ ਆਮ ਤੌਰ 'ਤੇ ਕੋਡਿੰਗ ਨਿਯਮ, ਚੰਗੀ Tooling ਅਤੇ ਉਹਨਾਂ ਜਗ੍ਹਾਂ 'ਤੇ ਟੇmplੇਟ ਕੰਪਲੈਕਸਿਟੀ ਰੱਖ ਕੇ ਇਸਨੂੰ ਹੱਲ ਕਰਦੀਆਂ ਹਨ ਜਿੱਥੇ ਲਾਭ ਹੈ।

STL: ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੇ ਬਿਲਡਿੰਗ ਬਲੌਕ ਬਿਨਾਂ ਛੁਪੇ ਕੰਮ ਦੇ

Standard Template Library (STL) C++ ਦਾ ਔਜ਼ਾਰ-ਖ਼ਜ਼ਾਨਾ ਹੈ ਜੋ ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲਾ ਕੋਡ ਲਿਖਣ ਲਈ ਬਣਾਇਆ ਗਿਆ ਹੈ ਜੋ ਫਿਰ ਵੀ ਤੰਗ ਮਸ਼ੀਨ ਨਿਰਦੇਸ਼ਾਂ ਵਿੱਚ ਕੰਪਾਇਲ ਹੋ ਸਕਦਾ ਹੈ। ਇਹ ਕੋਈ ਵੱਖਰਾ ਫ੍ਰੇਮਵਰਕ ਨਹੀਂ ਹੈ ਜੋ ਤੁਸੀਂ “ਜੋੜਦੇ” ਹੋ—ਇਹ ਮਿਆਰੀ ਲਾਇਬ੍ਰੇਰੀ ਦਾ ਹਿੱਸਾ ਹੈ, ਅਤੇ ਇਹ ਜ਼ੀਰੋ-ਕੋਸਟ ਵਿਚਾਰ ਦੇ ਆਸ-ਪਾਸ ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਗਿਆ ਹੈ: ਉਹ ਉੱਚ-ਪੱਧਰ ਬਿਲਡਿੰਗ ਬਲੌਕ ਦਿੰਦਾ ਹੈ ਬਿਨਾਂ ਤੁਹਾਡੇ ਨਾ ਮੰਗੇ ਰਨਟਾਈਮ ਕੰਮ ਦੇ।

ਤਿੰਨ ਸਿਧੀਆਂ: ਕਨਟੇਨਰ, ਅਲਗੋਰਿਦਮ, ਇਟਰੇਟਰ

• ਕਨਟੇਨਰ ਡਾਟਾ ਸਟੋਰ ਕਰਦੇ ਹਨ: vector, string, array, map, unordered_map, list ਆਦਿ।
• ਅਲਗੋਰਿਦਮ ਆਇਟਮ ਦੀਆਂ ਰੇਂਜਾਂ 'ਤੇ ਕੰਮ ਕਰਦੇ ਹਨ: sort, find, count, transform, accumulate ਆਦਿ।
• ਇਟਰੇਟਰ ਉਹ “ਗਲੂ” ਹਨ ਜੋ ਅਲਗੋਰਿਦਮਾਂ ਨੂੰ ਅਨੇਕ ਕਨਟੇਨਰ ਕਿਸਮਾਂ 'ਤੇ ਇੱਕ ਆਮ ਇੰਟਰਫੇਸ ਨਾਲ ਚਲਾਉਣ ਦਿੰਦੇ ਹਨ।

ਇਹ ਵਿਭਾਜਨ ਮੱਤਵਪੂਰਨ ਹੈ। ਹਰ ਕਨਟੇਨਰ ਨੂੰ “sort” ਜਾਂ “find” ਦੁਬਾਰਾ ਬਣਾਉਣ ਦੀ ਥਾਂ, STL ਤੁਸੀਂ ਇੱਕ ਸੀਟ ਅਲਗੋਰਿਦਮ ਦਿੰਦਾ ਹੈ ਜੋ ਕੰਪਾਈਲਰ ਦੁਆਰਾ ਜ਼ੋਰ ਨਾਲ Optimize ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਠੀਕ ਤਰੀਕੇ ਨਾਲ ਵਰਤਣ 'ਤੇ ਕੁਸ਼ਲਤਾ

STL ਕੋਡ ਤੇਜ਼ ਹੋ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਕਈ ਫੈਸਲੇ ਕੰਪਾਇਲ-ਟਾਈਮ 'ਤੇ ਲਏ ਜਾਂਦੇ ਹਨ। ਜੇ ਤੁਸੀਂ std::vector<int> ਸੋਰਟ ਕਰਦੇ ਹੋ, ਕੰਪਾਈਲਰ ਐਲਿਮੈਂਟ ਟਾਈਪ ਅਤੇ ਇਟਰੇਟਰ ਕਿਸਮ ਨੂੰ ਜਾਣਦਾ ਹੈ, ਅਤੇ ਇਹ ਤੁਲਨਾਵਾਂ ਅਤੇ ਲੂਪਾਂ ਨੂੰ ਇਨਲਾਈਨ ਕਰਕੇ ਹੱਥੋਂ-ਲਿਖੇ ਕੋਡ ਵਾਂਗ Optimize ਕਰ ਸਕਦਾ ਹੈ। ਕੁੰਜੀ ਗੱਲ ਇਹ ਹੈ ਕਿ ਉਹ ਡਾਟਾ ਸਟ੍ਰਕਚਰ ਚੁਣੋ ਜੋ ਪਹੁੰਚ ਕਾਰਜਕਲਾਪਾਂ ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਹਨ।

ਪ੍ਰਯੋਗਿਕ ਕਨਟੇਨਰ ਮਾਰਗਦਰਸ਼ਨ (ਕੋਈ ਪੱਕਾ ਨਿਯਮ ਨਹੀਂ)

• vector vs. list: vector ਅਕਸਰ ਡਿਫਾਲਟ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਤੱਤ ਮੈਮੋਰੀ ਵਿੱਚ ਲਗਾਤਾਰ ਹੁੰਦੇ ਹਨ, ਜੋ ਕਿ ਇਟਰੇਸ਼ਨ ਅਤੇ ਰੈਂਡਮ ਐਕਸੈਸ ਲਈ ਕੈਸ਼-ਦੋਸਤ ਅਤੇ ਤੇਜ਼ ਹੁੰਦਾ ਹੈ। list ਉਸ ਵੇਲੇ ਮਦਦਗਾਰ ਹੋ ਸਕਦਾ ਹੈ ਜਦੋਂ ਤੁਹਾਨੂੰ ਵਾਸਤਵ ਵਿੱਚ ਸਥਿਰ ਇਟਰੇਟਰ ਅਤੇ ਬਿਨਾਂ ਤੱਤਾਂ ਨੂੰ ਘੁਮਾਏ ਬਹੁਤ ਸਪੀਸਿੰਗ/ਇਨਸਰਸ਼ਨ ਚਾਹੀਦੀ ਹੋਵੇ—ਪਰ ਹਰ ਨੋਡ ਲਈ ਓਵਰਹੈਡ ਹੁੰਦਾ ਹੈ ਅਤੇ ਇਸਨੂੰ ਟਰੈਵਰਸ ਕਰਨਾ ਅਕਸਰ ਧੀਮਾ ਹੁੰਦਾ ਹੈ।

• unordered_map vs. map: unordered_map ਆਮ ਤੌਰ 'ਤੇ ਤੀਜ਼ ਔਸਤ-ਮਾਮਲਾ ਲੁੱਕਅਪ ਲਈ ਵਧੀਆ ਹੈ। map ਕੁੰਜੀਆਂ ਨੂੰ ਠੀਕ ਕ੍ਰਮ ਵਿੱਚ ਰੱਖਦਾ ਹੈ, ਜੋ ਰੇਂਜ ਕਵੈਰੀਆਂ ਲਈ ਲਾਭਦਾਇਕ ਹੈ (ਉਦਾਹਰਨ: “A ਅਤੇ B ਦੇ ਵਿਚਕਾਰ ਸਾਰੀਆਂ ਕੁੰਜੀਆਂ”), ਪਰ ਲੁੱਕਅਪ ਆਮ ਤੌਰ 'ਤੇ ਚੰਗੀ ਹੈਸ਼ ਟੇਬਲ ਤੋਂ ਧੀਮੀ ਹੁੰਦੀ ਹੈ।

For a deeper guide, see also: blog/choosing-cpp-containers

ਆਧੁਨਿਕ C++ ਫੀਚਰ ਜੋ ਜ਼ੀਰੋ-ਕੋਸਤ ਲਕਸ਼ ਨੂੰ ਸਹਾਇਕ ਬਣਾਉਂਦੇ ਹਨ

ਆਧੁਨਿਕ C++ ਨੇ Stroustrup ਦੇ ਮੂਲ ਵਿਚਾਰ "ਸਜ਼ਾ ਬਿਨਾਂ ਐਬਸਟ੍ਰੈਕਸ਼ਨ" ਨੂੰ ਛੱਡਿਆ ਨਹੀਂ। ਬਹੁਤ ਸਾਰੇ ਨਵੇਂ ਫੀਚਰ ਉਹ ਤੁਹਾਨੂੰ ਸਾਫ਼ ਕੋਡ ਲਿਖਣ ਦਿੰਦੇ ਹਨ ਜਦੋਂ ਕਿ ਕੰਪਾਈਲਰ ਨੂੰ ਤਿੱਖਾ ਮਸ਼ੀਨ ਕੋਡ ਪੈਦਾ ਕਰਨ ਦਾ ਮੌਕਾ ਮਿਲਦਾ ਹੈ।

Move semantics: ਮਲਕੀਅਤ ਤਬਾਦਲੇ 'ਤੇ ਕਾਪੀਆਂ ਤੋਂ ਬਚੋ

ਅਕਸਰ ਸੁਸਤਾਪਨ ਦੀ ਵਜ੍ਹਾ ਅਣਕਾਰਣੀ ਕਾਪੀ ਹੈ—ਵੱਡੀਆਂ strings, ਬਫਰ ਜਾਂ ਡਾਟਾ ਸਟ੍ਰਕਚਰਾਂ ਦੀ ਬੇਕਾਰ ਨਕਲ।

Move semantics ਦਾ ਸਧਾਰਨ ਵਿਚਾਰ ਹੈ “ਜੇ ਤੁਸੀਂ ਵਾਸਤਵ ਵਿੱਚ ਕਿਸੇ ਚੀਜ਼ ਨੂੰ ਹੱਥੋਂ-ਹੱਥ ਸੌਂਪ ਰਹੇ ਹੋ, ਤਾਂ ਕਾਪੀ ਨਾ ਕਰੋ।” ਜਦੋਂ ਇੱਕ ਆਬਜੈਕਟ ਅਸਥਾਈ ਹੁੰਦਾ ਹੈ (ਜਾਂ ਤੁਸੀਂ ਉਸਨੂੰ ਹੋਰ ਵਰਤੋਂ ਲਈ ਨਹੀਂ ਰੱਖ ਰਹੇ), C++ ਉਸਦੇ ਅੰਦਰੂਨੀ ਹਿੱਸਿਆਂ ਨੂੰ ਨਵੇਂ ਮਾਲਿਕ ਨੂੰ ਟ੍ਰਾਂਸਫਰ ਕਰ ਸਕਦੀ ਹੈ ਬਜਾਏ ਇਸਨੂੰ ਨਕਲ ਕਰਨ ਦੇ। ਰੋਜ਼ਾਨਾ ਕੋਡ ਲਈ, ਇਸਦਾ ਮਤਲਬ ਹੈ ਘੱਟ ਐਲੋਕੇਸ਼ਨ, ਘੱਟ ਮੈਮੋਰੀ ਟਰੈਫਿਕ ਅਤੇ ਤੇਜ਼ ਚਲਣਾ—ਬਿਨਾਂ ਮੈਨੁਅਲ ਬਾਈਟ-ਮੈਨੇਜਮੈਂਟ ਦੇ।

constexpr: ਅੱਗੇ ਹੀ ਗਣਨਾ ਕਰੋ ਤਾਂ ਕਿ ਰਨਟਾਈਮ ਘੱਟ ਕਰੇ

ਕੁਝ ਮੁੱਲ ਅਤੇ ਫੈਸਲੇ ਕਦੇ ਨਹੀਂ ਬਦਲਦੇ (ਟੇਬਲ ਆਕਾਰ, ਕਨਫਿਗਰੇਸ਼ਨ ਕਾਂਸਟੈਂਟ, ਲੁੱਕਅਪ ਟੇਬਲ)। constexpr ਨਾਲ ਤੁਸੀਂ C++ ਨੂੰ ਆਖ ਸਕਦੇ ਹੋ ਕਿ ਕੁਝ ਨਤੀਜੇ ਕੰਪਾਇਲ-ਟਾਈਮ 'ਤੇ ਹੀ ਗਣਨਾ ਕੀਤੇ ਜਾਣ ਤਾਂ ਕਿ ਚੱਲਦੇ ਸਮੇਂ ਘੱਟ ਕੰਮ ਰਹੇ।

ਲਾਭ ਦੋਹਾਂ ਗਤੀ ਅਤੇ ਸਧਾਰਣਤਾ ਹੈ: ਕੋਡ ਇੱਕ ਆਮ ਹਿਸਾਬ ਵਾਂਗ ਪੜ੍ਹਨ ਜੋਗਾ, ਪਰ ਨਤੀਜਾ ਇੱਕ “ਬੇਕਡ-ਇਨ” ਕਾਂਸਟੈਂਟ ਹੋ ਸਕਦਾ ਹੈ।

Ranges ਅਤੇ ਸਾਫ਼ ਇਟਰੇਸ਼ਨ (ਬਿਨਾਂ ਛੁਪੇ ਕੰਮ ਦੇ)

Ranges (ਅਤੇ views ਵਰਗੀਆਂ ਸੰਬੰਧਿਤ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ) ਤੁਹਾਨੂੰ ਇਹ ਪ੍ਰਗਟ ਕਰਨ ਦਿੰਦੇ ਹਨ ਕਿ “ਇਹ ਆਇਟਮ ਲਓ, ਫਿਲਟਰ ਕਰੋ, ਤਬਦੀਲ ਕਰੋ” ਇੱਕ ਪੜ੍ਹਨਯੋਗ ਢੰਗ ਨਾਲ। ਚੰਗੀ ਤਰ੍ਹਾਂ ਵਰਤਿਆਂ, ਇਹ ਸਾਫ਼ ਲੂਪਾਂ ਵਿੱਚ ਕੰਪਾਇਲ ਹੋ ਸਕਦੇ ਹਨ—ਬਿਨਾਂ ਜ਼ਬਰਦਸਤੀ ਰਨਟਾਈਮ ਲੇਅਰਾਂ ਦੇ।

ਇੱਕ ਹਕੀਕਤ-ਪੂਰਨ ਨੋਟ: ਜ਼ੀਰੋ-ਕੋਸਟ ਇੱਕ ਲਕਸ਼ ਹੈ, ਗਾਰੰਟੀ ਨਹੀਂ

ਇਹ ਫੀਚਰ ਜ਼ੀਰੋ-ਕੋਸਟ ਦਿਸ਼ਾ ਨੂੰ ਸਹਾਰਦੇ ਹਨ, ਪਰ ਪ੍ਰਦਰਸ਼ਨ ਫਿਰ ਵੀ ਇਸ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਇਹਨਾਂ ਨੂੰ ਕਿਵੇਂ ਵਰਤਦੇ ਹੋ ਅਤੇ ਕੰਪਾਈਲਰ ਅਖੀਰਕਾਰ ਫਾਈਨਲ ਪ੍ਰੋਗਰਾਮ ਨੂੰ ਕਿਵੇਂ Optimize ਕਰਦਾ ਹੈ। ਖ਼ਰਚੀਲਾ-ਮਾਮਲਾ ਕੋਡ ਅਕਸਰ ਸ਼ਾਨਦਾਰ ਰੀਤ ਨਾਲ Optimize ਹੋ ਜਾਂਦਾ ਹੈ—ਪਰ ਜੇ ਗਤੀਵਿਧੀ ਇਸ ਲਈ ਸਚਮੁਚ ਮੈਟਰ ਕਰਦੀ ਹੈ ਤਾਂ ਮਾਪਣਾ ਜਰੂਰੀ ਹੈ।

ਅਸਲ C++ ਕੋਡ ਵਿੱਚ ਪ੍ਰਦਰਸ਼ਨ ਕਿੱਥੇ ਜਿੱਤਿਆ ਜਾਂਦਾ (ਜਾਂ ਹਾਰਿਆ)

C++ “ਉੱਚ-ਪੱਧਰ” ਕੋਡ ਨੂੰ ਬਹੁਤ ਤੇਜ਼ ਮਸ਼ੀਨ ਨਿਰਦੇਸ਼ਾਂ ਵਿੱਚ ਕੰਪਾਇਲ ਕਰ ਸਕਦਾ ਹੈ—ਪਰ ਇਹ ਤੇਜ਼ ਨਤੀਜਿਆਂ ਦੀ ਗਾਰੰਟੀ ਨਹੀਂ ਦਿੰਦਾ। ਪਰਫਾਰਮੈਂਸ ਅਕਸਰ ਇਸ ਲਈ ਖੋਇਆ ਜਾਂਦਾ ਹੈ ਕਿ ਛੋਟੀਆਂ ਲਾਗਤਾਂ ਹੌਟ ਪਾਥ ਵਿੱਚ ਸੀspraken ਹੋ ਕੇ ਮਿਲਦੀਆਂ ਹਨ ਅਤੇ ਲੱਖਾਂ ਵਾਰੀ ਗੁਣਾ ਹੋ ਜਾਂਦੀਆਂ ਹਨ।

ਅਕਸਰ ਅਣਜਾਣੇ ਓਵਰਹੈਡ ਦੇ ਸਰੋਤ

ਕੁਝ ਪੈਟਰਨ ਹਰ ਵਾਰੀ ਮੁੜ-ਮੁੜ ਨਜਰ ਆਉਂਦੇ ਹਨ:

• ਅਣਜਰੂਰੀ ਐਲੋਕੇਸ਼ਨ (ਕਈ ਛੋਟੇ ਅਸਥਾਈ ਆਬਜੈਕਟਾਂ ਨੂੰ ਹੀਪ 'ਤੇ ਬਣਾਉਣਾ)
• ਕਾਪੀ ਕਰਨ ਦੀ ਥਾਂ ਮੂਵ ਜਾਂ ਰੇਫਰੰਸ ਵਰਤਣਾ
• ਬਿਖਰੇ ਹੋਏ ਮੈਮੋਰੀ ਲੇਆਉਟ ਨਾਲ ਕੈਸ਼ ਮਿਸ
• ਟਾਈਟ ਲੂਪਾਂ ਵਿੱਚ ਵਰਚੁਅਲ ਡਿਸਪੈਚ ਜਦੋਂ ਕੰਪਾਈਲਰ ਅਸਾਨੀ ਨਾਲ ਇਨਲਾਈਨ ਨਹੀਂ ਕਰ ਸਕਦਾ
• ਕੰਟੈਂਸ਼ਨ (ਥ੍ਰੈਡ ਲੌکس, ਐਟੌਮਿਕਸ, ਸ਼ੇਅਰਡ ਕਿਊ) ਜਿੱਥੇ “ਤੇਜ਼ ਕੋਡ” ਸਮਾਂ ਉਡੀਕਣ 'ਚ ਖ਼ਰਚਦਾ ਹੈ

ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ “C++ ਸਮੱਸਿਆ” ਨਹੀਂ ਹੈ। ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਡਿਜ਼ਾਈਨ ਅਤੇ ਵਰਤੋਂ ਦੀ ਸਮੱਸਿਆਵਾਂ ਹਨ—ਅਤੇ ਇਹ ਕਿਸੇ ਵੀ ਭਾਸ਼ਾ ਵਿੱਚ ਹੋ ਸਕਦੀਆਂ ਹਨ। ਫਰਕ ਇਹ ਹੈ ਕਿ C++ ਤੁਹਾਨੂੰ ਠੀਕ ਕਰਨ ਲਈ ਕਾਫ਼ੀ ਨਿਯੰਤਰਣ ਦਿੰਦੀ ਹੈ, ਅਤੇ ਇਨੁ ਹੋਣ ਲਈ ਕਾਫ਼ੀ ਰੱਸੀ ਵੀ ਦਿੰਦੀ ਹੈ।

ਵਰਤਣਯੋਗ ਨਿਯਮ ਜੋ ਸਚਮੁਚ ਮਦਦ ਕਰਦੇ ਹਨ

ਖਰਚ ਮਾਡਲ ਨੂੰ ਸਧਾ ਰੱਖਣ ਵਾਲੀ ਆਦਤਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ:

1. ਅਨੁਮਾਨ ਲਗਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਮਾਪੋ। ਖ਼ਾਸ ਕਰਕੇ ਕੈਸ਼ ਅਤੇ ਕਨਕਰੈਂਸੀ ਨਾਲ ਤੁਹਾਡੀ ਭਾਨਾ ਅਕਸਰ ਗਲਤ ਹੁੰਦੀ ਹੈ।
2. ਹੌਟ ਕੋਡ ਵਿੱਚ ਐਲੋਕੇਸ਼ਨਾਂ ਘਟਾਓ। ਬਫਰ ਰੀਯੂਜ਼ ਕਰੋ, ਕੈਪੈਸਿਟੀ ਰਿਜ਼ਰਵ ਕਰੋ, ਅਤੇ ਇਨਰ-ਲੂਪ ਵਿੱਚ ਅਸਥਾਈ ਕਨਟੇਨਰ ਨਾ ਬਣਾਓ।
3. ਜਦੋਂ ਪ੍ਰਦਰਸ਼ਨ ਮੈਟਰ ਕਰਦਾ ਹੈ ਤਾਂ ਸਧਾਰਨ, ਲਗਾਤਾਰ ਡੇਟਾ ਲੇਆਉਟ ਨੂੰ ਤਰਜੀਹ ਦਿਓ। ਘੱਟ ਪੋਇੰਟਰ ਅਤੇ ਹੋਰ “ਆਬਜੈਕਟ ਗ੍ਰਾਫ” ਦੇ ਬਦਲੇ ਵਿੱਚ ਥੋੜ੍ਹੇ “ਐਰੇਜ਼ ਆਫ ਸਟੱਫ” ਅਕਸਰ ਜਿੱਤਦੇ ਹਨ।
4. ਹੌਟ ਪਾਥ ਨੂੰ ਬੋਰਿੰਗ ਰੱਖੋ। ਇਨਲਾਈਨਬਲ ਫੰਕਸ਼ਨ, ਅਣੁਮਾਨਯੋਗ ਬ੍ਰਾਂਚ, ਅਤੇ ਘੱਟ ਸਮਨਵਯ ਬਚਾਓ ਤੁਹਾਡੇ ਮਿੱਤਰ ਹਨ।

ਪ੍ਰੋਫਾਈਲਿੰਗ, ਜਾਦੂ-ਟੁੱਟੀ ਬਿਨਾਂ

ਇਕ ਪ੍ਰੋਫਾਈਲਰ ਵਰਤੋ ਜੋ ਮੂਢੇ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦੇ ਸਕੇ: ਕਿੱਥੇ ਸਮਾਂ ਖਰਚ ਹੁੰਦਾ ਹੈ? ਕਿੰਨੀ ਐਲੋਕੇਸ਼ਨਾਂ ਹੋ ਰਹੀਆਂ ਹਨ? ਕਿਹੜੀਆਂ ਫੰਕਸ਼ਨ ਸਭ ਤੋਂ ਵੱਧ ਕਾਲ ਹੋ ਰਹੀਆਂ ਹਨ? ਉਸਨੂੰ ਹਲਕੀ-ਭਾਰੀ ਬੈਂਚਮਾਰਕਾਂ ਨਾਲ ਜੋੜੋ ਜੋ ਉਹ ਹਿੱਸੇ ਜਿਨ੍ਹਾਂ ਦੀ ਤੁਸੀਂ ਪਰਵਾਹ ਕਰਦੇ ਹੋ, ਅੱਗੇ-ਪਿੱਛੇ ਜਾਂਚ ਸਕਣ।

ਜਦੋਂ ਤੁਸੀਂ ਇਹ ਨਿਰੱਤਰਤ ਤਰੀਕੇ ਨਾਲ ਕਰਦੇ ਹੋ, “ਜ਼ੀਰੋ-ਕੋਸਟ ਐਬਸਟ੍ਰੈਕਸ਼ਨ” ਵਰਤੋ: ਪੜ੍ਹਨਯੋਗ ਕੋਡ ਰੱਖੋ, ਫਿਰ ਉਹ ਖਾਸ ਲਾਗਤਾਂ ਹਟਾਓ ਜੋ ਮਾਪਣ 'ਤੇ ਉਭਰਦੀਆਂ ਹਨ।

ਕਿਉਂ ਪਰਫਾਰਮੈਂਸ-ਸੰਵੇਦਨਸ਼ੀਲ ਉਦਯੋਗ ਅਜੇ ਵੀ C++ ਚੁਣਦੇ ਹਨ

ਜਿੱਥੇ ਮਿਲੀਸੈਕਿੰਡ (ਜਾਂ ਮਾਈਕ੍ਰੋਸੈਕਿੰਡ) ਸਿਰਫ਼ “ਚੰਗਾ” ਹੀ ਨਹੀਂ ਸਗੋਂ ਉਤਪਾਦੀ ਲੋੜ ਹੁੰਦਾ ਹੈ, ਉਥੇ C++ ਪਿੱਛੇ-ਛੱਡਦਾ ਨਹੀਂ। ਤੁਸੀਂ ਇਸਨੂੰ ਆਮ ਤੌਰ 'ਤੇ ਘੱਟ-ਲੇਟੈਂਸੀ ਟਰੇਡਿੰਗ ਸਿਸਟਮ, ਗੇਮ ਇੰਜਣ, ਬਰਾਊਜ਼ਰ ਕੰਪੋਨੈਂਟ, ਡੇਟਾਬੇਸ ਅਤੇ ਸਟੋਰੇਜ਼ ਇੰਜਣ, ਐਂਬੈੱਡਡ ਫਰਮਵੇਅਰ, ਅਤੇ ਹਾਈ-ਪਰਫਾਰਮੈਂਸ ਕੰਪਿਊਟਿੰਗ (HPC) ਵਰਕਲੋਡਾਂ ਦੇ ਪਿੱਛੇ ਲੱਭੋਗੇ। ਇਹ ਇਕੱਲੇ ਥਾਂ ਨਹੀਂ ਹਨ—ਪਰ ਇਹ ਵਜਹਾਂ ਹਨ ਕਿ ਭਾਸ਼ਾ ਅਜੇ ਵੀ ਵਿਕਸਤ ਹੋ ਰਹੀ ਹੈ।

ਪੇਸ਼ਗੋਈ ਯੋਗ ਲੇਟੈਂਸੀ ਅਤੇ ਸਪਸ਼ਟ ਨਿਯੰਤਰਣ

ਬਹੁਤ ਸਾਰੇ ਪ੍ਰਦਰਸ਼ਨ-ਸੰਵੇਦਨਸ਼ੀਲ ਖੇਤਰਾਂ ਨੂੰ ਸ਼ੀਰਸ਼-ਥਾਂਮ ਤੋਂ ਵੱਧ ਪੇਸ਼ਗੋਈ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ: ਉਹ ਟੇਲ ਲੇਟੈਂਸੀਜ਼ ਹਨ ਜੋ ਫਰੇਮ ਡ੍ਰੌਪ, ਆਡੀਓ ਗਲਿਚ, ਮਾਰਕੀਟ ਮੌਕੇ ਗੁਆਉਣਾ, ਜਾਂ ਵਾਸਤਵਿਕ-ਸਮੇਂ ਡੈਡਲਾਈਨ ਛੱਡਣਾ ਬਣਾਉਂਦੇ ਹਨ। C++ ਟੀਮਾਂ ਨੂੰ ਇਹ ਫੈਸਲਾ ਕਰਨ ਦੀ ਆਜ਼ਾਦੀ ਦਿੰਦਾ ਹੈ ਕਿ ਮੈਮੋਰੀ ਕਦੋਂ ਐਲੋਕੇਟ ਕਰਨੀ ਹੈ, ਕਦੋਂ ਰਿਲੀਜ਼ ਕਰਨੀ ਹੈ, ਅਤੇ ਡੇਟਾ ਮੈਮੋਰੀ ਵਿੱਚ ਕਿਵੇਂ ਲੇਆਉਟ ਹੋਵੇ—ਇਹ ਚੋਣਾਂ ਕੈਸ਼ ਵਤੀਰੇ ਅਤੇ ਲੇਟੈਂਸੀ ਸਪਾਈਕ 'ਤੇ ਜ਼ੋਰਦਾਰ ਪ੍ਰਭਾਵ ਪਾਉਂਦੀਆਂ ਹਨ।

ਕਿਉਂਕਿ ਐਬਸਟ੍ਰੈਕਸ਼ਨ ਸਧਾਰਨ ਮਸ਼ੀਨ ਕੋਡ ਵਿੱਚ ਕੰਪਾਇਲ ਹੋ ਸਕਦੀਆਂ ਹਨ, C++ ਕੋਡ ਮੈਂਟੇਨਬਿਲਟੀ ਲਈ ਬਣਾਇਆ ਜਾ ਸਕਦਾ ਹੈ ਬਿਨਾਂ ਉਸ ਸੰਰਚਨਾ ਲਈ ਆਟੋਮੈਟਿਕ ਤੌਰ 'ਤੇ ਰਨਟਾਈਮ ਓਵਰਹੈਡ ਦੇਣ ਦੇ। ਜਦੋਂ ਤੁਸੀਂ ਲਾਗਤਾਂ ਭਰਤੀਆਂ ਹੋ (ਡਾਇਨਾਮਿਕ ਐਲੋਕੇਸ਼ਨ, ਵਰਚੁਅਲ ਡਿਸਪੈਚ, ਸਿੰਕ੍ਰੋਨਾਈਜੇਸ਼ਨ), ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਦਿਸਣਯੋਗ ਅਤੇ ਮਾਪਣਯੋਗ ਹੁੰਦੇ ਹਨ।

ਮੌਜੂਦਾ ਇਕੋਸਿਸਟਮ ਵਿੱਚ ਫਿੱਟ ਹੋਣਾ (ਖ਼ਾਸ ਕਰਕੇ C)

ਪ੍ਰੈਗਮੈਟਿਕ ਕਾਰਨ ਇਹ ਹੈ ਕਿ C++ ਅਜੇ ਵੀ ਆਮ ਹੈ ਕਿਉਂਕਿ ਕਈ ਸੰਸਥਾਵਾਂ ਕੋਲ ਦਹਾਕਿਆਂ ਦੇ C ਲਾਇਬ੍ਰੇਰੀਜ਼, OS ਇੰਟਰਫੇਸ, ਡਿਵਾਈਸ SDKs ਅਤੇ ਟੈਸਟ ਹੋਏ ਕੋਡ ਹਨ ਜੋ ਉਹ ਸੋਧ ਕੇ ਨਹੀਂ ਰੀਲਿਖ ਸਕਦੇ। C++ ਸੀ APIs ਨੂੰ ਸਿੱਧਾ ਕਾਲ ਕਰ ਸਕਦਾ ਹੈ, ਜਦਰੂਰਤ ਹੋਵੇ ਤਾਂ C-ਅਨੁਕੂਲ ਇੰਟਰਫੇਸ ਦਿਖਾ ਸਕਦਾ ਹੈ, ਅਤੇ ਇੱਕ ਕੋਡਬੇਸ ਦੇ ਹਿੱਸਿਆਂ ਨੂੰ ਹੌਲੀ-ਹੌਲੀ ਆਧੁਨਿਕਤਾ ਦੀ ਰਾਹ ਦਿਖਾ ਸਕਦਾ ਹੈ।

ਟੂਲਿੰਗ, ਹਾਰਡਵੇਅਰ ਐਕਸੈਸ ਅਤੇ ਡਿਪਲੋਇਮੈਂਟ ਹਕੀਕਤਾਂ

ਸਿਸਟਮ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਅਤੇ ਐਂਬੈੱਡਡ ਕੰਮ ਵਿੱਚ, “ਢੰਗ ਨਾਲ ਨਜ਼ਦੀਕ” ਅਜੇ ਵੀ ਗਰਭੀਨ ਹੈ: ਸਿੱਧਾ ਸਿੱਧਾ ਨਿਰਦੇਸ਼, SIMD, ਮੈਮੋਰੀ-ਮੈਪਡ I/O, ਅਤੇ ਪਲੇਟਫਾਰਮ-ਖ਼ਾਸ ਅਪਟੀਮਾਈਜ਼ੇਸ਼ਨ। ਪੱਕੇ ਕੰਪਾਈਲਰ ਅਤੇ ਪ੍ਰੋਫਾਈਲਿੰਗ ਟੂਲਾਂ ਦੇ ਨਾਲ, C++ ਅਕਸਰ ਉਹ ਚੋਣ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਟੀਮਾਂ ਨੂੰ ਪ੍ਰਦਰਸ਼ਨ ਨਿਕਾਲਨਾ ਹੋਵੇ ਅਤੇ ਬਾਈਨਰੀ, ਡੀਪੈਂਡੇਸੀਜ਼ ਅਤੇ ਰਨਟਾਈਮ ਵਿਹਾਰ 'ਤੇ ਨਿਯੰਤਰਣ ਚਾਹੀਦਾ ਹੋਵੇ।

ਔਖੇ ਹਿੱਸੇ: ਕੰਪਲੈਕਸਿਟੀ, ਸੁਰੱਖਿਆ, ਅਤੇ ਟੀਮਾਂ ਕਿਵੇਂ ਨਜੰਮ ਲੇਂਦੀਆਂ ਹਨ

C++ ਆਪਣੀ ਤੇਜ਼ੀ ਅਤੇ ਲਚਕ ਲਈ ਵਫਾਦਾਰੀ ਜਿੱਤਦਾ ਹੈ—ਪਰ ਇਸ ਤਾਕਤ ਦੀ ਕੀਮਤ ਹੈ। ਲੋਕਾਂ ਦੀਆਂ ਆਲੋਚਨਾਵਾਂ ਬੇਮੂਲ ਨਹੀਂ ਹਨ: ਭਾਸ਼ਾ ਵੱਡੀ ਹੈ, ਪੁਰਾਣੇ ਕੋਡਬੇਸਾਂ ਵਿੱਚ ਖ਼ਤਰਨਾਕ ਰਿਵਾਜ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਗਲਤੀਆਂ ਕੁਝ ਸਮੇਂ ਵਿੱਚ ਕਰੈਸ਼, ਡਾਟਾ ਖਰਾਬੀ, ਜਾਂ ਸੁਰੱਖਿਆ ਮੁੱਦੇ ਲਿਆ ਸਕਦੀਆਂ ਹਨ।

ਕਿਉਂ C++ ਔਖਾ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ

C++ ਦਹਾਕਿਆਂ ਵਿੱਚ ਵਿਕਸਤ ਹੋਈ, ਅਤੇ ਇਹ ਨਜ਼ਰ ਆਉਂਦਾ ਹੈ। ਤੁਸੀਂ ਇੱਕੋ ਕੰਮ ਕਰਨ ਦੇ ਕਈ ਤਰੀਕੇ ਵੇਖੋਗੇ, ਨਾਲ ਹੀ “ਤੇਖੀ ਧਾਰਾਂ” ਜੋ ਛੋਟੀਆਂ ਗਲਤੀਆਂ ਨੂੰ ਸਜ਼ਾ ਦਿੰਦੀਆਂ ਹਨ। ਦੋ ਆਮ ਸਮੱਸਿਆਵਾਂ:

• ਕੰਪਲੈਕਸਿਟੀ: ਟੇmplੇਟ, ਓਵਰਲੋਡ ਅਤੇ ਬਿਲਡ ਸਿਸਟਮ ਡਿਬੱਗਿੰਗ ਅਤੇ ਓਨਬੋਰਡਿੰਗ ਨੂੰ ਛੋਟੀਆਂ ਭਾਸ਼ਾਵਾਂ ਨਾਲੋਂ ਔਖਾ ਕਰ ਸਕਦੇ ਹਨ।
• ਅਣਨਿਰਧਾਰਤ ਵਿਹਾਰ (Undefined behavior): ਕੁਝ ਗਲਤੀਆਂ (ਜਿਵੇਂ ਅਵੈਧ ਮੈਮੋਰੀ ਪੜ੍ਹਨਾ ਜਾਂ ਕਿਸਮ ਕਾਨੂੰਨ ਤੋੜਨਾ) ਮੁੜ-ਰਵਾਇਤੀ ਤੌਰ 'ਤੇ ਫੇਲ ਨਹੀਂ ਹੁੰਦੀਆਂ; ਉਹ ਕੰਪਾਈਲਰ ਅੱਪਡੇਟ ਜਾਂ ਨਵੀਂ ਅਪਟੀਮਾਈਜ਼ੇਸ਼ਨ ਨਾਲ ਅਚਾਨਕ ਕੰਮ ਕਰਨਾ ਬੰਦ ਕਰ ਸਕਦੀਆਂ ਹਨ।

ਪੁਰਾਣੇ ਪੈਟਰਨ ਰਿਸਕ ਵਧਾਉਂਦੇ ਹਨ: ਰਾ new/delete, ਮੈਨੂਅਲ ਮੈਮੋਰੀ ਮਾਲਕੀਅਤ, ਅਤੇ ਬੇਚੈੱਕ ਪੋਇੰਟਰ ਅੰਕਗਣਿਤ ਅਜੇ ਵੀ ਲੇਗੇਸੀ ਕੋਡ ਵਿੱਚ ਆਮ ਹਨ।

ਟੀਮਾਂ ਜੋਖਮ ਘਟਾਉਣ ਲਈ ਕੀ ਕਰਦੀਆਂ ਹਨ (ਕੁਝ ਜਾਦੂ ਨਹੀਂ)

ਆਧੁਨਿਕ C++ ਅਭਿਆਸ ਜ਼ਿਆਦਾਤਰ ਇਸ ਬਾਰੇ ਹੈ ਕਿ ਲਾਭ ਕਿਵੇਂ ਪ੍ਰਾਪਤ ਕਰਨ ਹਨ ਬਿਨਾਂ ਫੁਟ-ਗਨਜ਼ ਨੂੰ ਉੱਠਾਏ। ਟੀਮਾਂ ਇਹ ਗੱਲਾਂ ਅਪਣਾਉਂਦੀਆਂ ਹਨ:

• RAII ਕਿਸਮਾਂ ਅਤੇ ਮਿਆਰੀ ਕਨਟੇਨਰ (std::vector, std::string) ਨੂੰ ਕੱਚੇ new/delete ਦੀ ਥਾਂ।
• ਸਮਾਰਟ ਪੋਇੰਟਰ (std::unique_ptr, std::shared_ptr) ਨਾਲ ਮਾਲਕੀਅਤ ਨੂੰ ਜ਼ਾਹਰ ਕਰਨਾ।
• ਵਾਰਨਿੰਗਜ਼ ਨੂੰ ਆਸ-ਏਰਰਸ ਬਣਾਉਣਾ, clang-tidy ਵਰਗੇ ਸੰਦ ਲਾਗੂ ਕਰਨਾ।
• ਟੈਸਟਿੰਗ ਵਿੱਚ sanitizers (AddressSanitizer, UndefinedBehaviorSanitizer) ਚਲਾਉਣਾ ਤਾਂ ਜੋ ਮੁੱਦੇ ਸ਼ੁਰੂਆਤੀ ਪੜਾਅ ਵਿੱਚ ਫੜੇ ਜਾਣ।
• ਜਦੋਂ ਇਨਪੁਟ ਅਣ-ਭਰੋਸੇਯੋਗ ਹੋ, ਤਾਂ ਸਟੈਟਿਕ ਵਿਸ਼ਲੇਸ਼ਣ ਅਤੇ ਫੱਜਿੰਗ ਸ਼ਾਮਿਲ ਕਰਨਾ।

ਰੁਖ ਦੀ ਦਿਸ਼ਾ

ਸਟੈਂਡਰਡ ਹਮੇਸ਼ਾ ਸੁਰੱਖਿਆ ਅਤੇ ਸਾਫ਼-ਲਿਖਤ ਕੋਡ ਵੱਲ ਵੱਧ ਰਿਹਾ ਹੈ: ਬਿਹਤਰ ਲਾਇਬ੍ਰੇਰੀਆਂ, ਵੱਧ ਅਭਿਵਿਕਾਰਕ ਕਿਸਮਾਂ, ਅਤੇ contracts, ਸੁਰੱਖਿਆ ਦੀਆਂ ਗਾਈਡਲਾਈਨ ਅਤੇ ਟੂਲ ਸਹਾਇਤਾ 'ਤੇ ਚੱਲ ਰਹੀ ਕੰਮ। ਟਰੇਡ-ਆਫ਼ ਰਹਿੰਦਾ ਹੈ: C++ ਤੁਹਾਨੂੰ ਲੈਵਰੇਜ ਦਿੰਦਾ ਹੈ, ਪਰ ਟੀਮਾਂ ਨੂੰ ਅਨੁਸ਼ਾਸਨ, ਰਿਵਿਊ, ਟੈਸਟਿੰਗ ਅਤੇ ਆਧੁਨਿਕ ਰਵਾਇਜਾਂ ਰਾਹੀਂ ਭਰੋਸੇਯੋਗਤਾ ਕਮਾਉਣੀ ਪੈਂਦੀ ਹੈ।

ਪ੍ਰਯੋਗਿਕ ਫੈਸਲਾ ਗਾਈਡ: ਕਦੋਂ (ਅਤੇ ਕਿਵੇਂ) C++ 'ਤੇ ਦਾਉ ਲਗਾਉਣਾ ਚਾਹੀਦਾ ਹੈ

C++ ਇੱਕ ਵਧੀਆ ਚੋਣ ਹੈ ਜਦੋਂ ਤੁਹਾਨੂੰ ਪਰਫਾਰਮੈਂਸ ਅਤੇ ਸਰੋਤਾਂ 'ਤੇ ਸੁਖੜ-ਨਿਯੰਤਰਣ ਦੀ ਲੋੜ ਹੋਵੇ ਅਤੇ ਤੁਸੀਂ ਅਨੁਸ਼ਾਸਨ ਵਿੱਚ ਨਿਵੇਸ਼ ਕਰਨ ਦੀ ਯੋਜਨਾ ਰੱਖਦੇ ਹੋ। ਇਹ "C++ ਤੇਜ਼ ਹੈ" ਬਾਰੇ ਨਹੀਂ ਹੈ ਪਰ "C++ ਤੁਹਾਨੂੰ ਫੈਸਲਾ ਕਰਨ ਦਿੰਦਾ ਹੈ ਕਿ ਕਿਹੜਾ ਕੰਮ ਕਦੋਂ ਅਤੇ ਕਿਸ ਕੀਮਤ 'ਤੇ ਹੋਵੇ।"

ਜਦੋਂ C++ ਠੀਕ ਫਿੱਟ ਹੈ

C++ ਚੁਣੋ ਜਦੋਂ ਇਹਨਾਂ ਵਿੱਚੋਂ ਜ਼ਿਆਦਾਤਰ ਸੱਚ ਹੋਣ:

• ਤੁਹਾਡੇ ਕੋਲ ਕਠੋਰ ਲੇਟੈਂਸੀ, ਥਰੂਪੁੱਟ ਜਾਂ ਮੈਮੋਰੀ ਸੀਮਾਵਾਂ ਹਨ (ਰੀਅਲ-ਟਾਈਮ ਸਿਸਟਮ, ਟਰੇਡਿੰਗ, ਗੇਮ, ਰੈਂਡਰਿੰਗ, ਐਂਬੈੱਡਡ)।
• ਤੁਹਾਨੂੰ ਹਾਰਡਵੇਅਰ, OS API, ਜਾਂ ਮੌਜੂਦਾ C/C++ ਲਾਇਬ੍ਰੇਰੀਆਂ ਨਾਲ ਸਖ਼ਤ ਇন্টեգਰੇਸ਼ਨ ਦੀ ਲੋੜ ਹੈ।
• ਲਾਂਚ ਟਾਈਮ ਅਤੇ ਪੇਸ਼ਗੋਈਯੋਗ ਪ੍ਰਦਰਸ਼ਨ ਤੇਜ਼ ਇਟਰੇਸ਼ਨ ਤੋਂ ਜ਼ਿਆਦਾ ਮਹੱਤਵ ਰੱਖਦੇ ਹਨ।
• ਤੁਸੀਂ ਐਜੇ-ਇੰਜੀਨੀਅਰਾਂ ਨੂੰ ਰੱਖ ਸਕਦੇ ਹੋ ਜੋ ਸੁਰੱਖਿਆ ਅਤੇ ਟੈਸਟਿੰਗ ਨੂੰ ਪਹਿਲੀ ਜ਼ਿੰਮੇਵਾਰੀ ਮੰਨਣਗੇ।

ਹੋਰ ਭਾਸ਼ਾਵਾਂ 'ਤੇ ਵਿਚਾਰ ਕਰੋ ਜਦੋਂ:

• ਵਿਕਾਸ ਦੀ ਰਫ਼ਤਾਰ, ਡਿਫਾਲਟ-ਰੂਪ ਵਿੱਚ ਸੁਰੱਖਿਆ, ਅਤੇ ਸਾਦਾ ਡਿਪਲੋਇਮੈਂਟ ਵੱਧ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹਨ (ਬਹੁਤ ਸਾਰੇ ਵੈੱਬ ਬੈਕਐਂਡ, ਅੰਦਰੂਨੀ ਟੂਲ)। Rust, Go, Java/Kotlin, C#, ਜਾਂ Python ਜੋਖਮ ਘਟਾ ਸਕਦੇ ਹਨ।
• ਤੁਹਾਡੇ ਕੋਲ C++ ਤਜ਼ਰਬਾ ਨਹੀਂ ਹੈ ਅਤੇ ਤੁਸੀਂ ਟਰੇਨਿੰਗ, ਟੂਲਿੰਗ ਅਤੇ ਰਿਵਿਊ ਲਈ ਸਮਾਂ ਨਹੀਂ ਰੱਖ ਸਕਦੇ।
• ਤੁਹਾਨੂੰ ਅਸਲ ਵਿੱਚ ਐਲੋਕੇਸ਼ਨ, ਡੇਟਾ ਲੇਆਉਟ, ਜਾਂ ਟੇਲ ਲੇਟੈਂਸੀ 'ਤੇ ਨਿਯੰਤਰਣ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ।

ਟੀਮਾਂ ਲਈ ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਚੈਕਲਿਸਟ

ਜੇ ਤੁਸੀਂ C++ ਚੁਣਦੇ ਹੋ, ਤਾਂ ਜਲਦੀ ਗਾਰਡਰੇਲ ਲਗਾਓ:

• ਕੋਡਿੰਗ ਗਾਈਡਲਾਈਨ: ਆਧੁਨਿਕ ਬੇਸਲਾਈਨ (C++17/20) ਅਪਣਾਓ, RAII ਤਰਜੀਹ ਦਿਓ, ਕੱਚੇ new/delete ਤੋਂ ਬਚੋ, std::unique_ptr/std::shared_ptr ਦਾ ਜ਼ਿੰਮੇਵਾਰ ਉਪਯੋਗ ਕਰੋ, ਅਤੇ ਐਨਚੈਕਡ ਪੋਇੰਟਰ ਅੰਕਗਣਿਤ ਨੂੰ ਐਪਲੀਕੇਸ਼ਨ ਕੋਡ ਵਿੱਚ ਮਨਾਂ ਕਰੋ।
• ਕੋਡ ਰਿਵਿਊ ਫੋਕਸ: ਲਾਈਫਟਾਈਮ/ਮਾਲਕੀਅਤ, Exceptions ਸੇਫਟੀ, ਛੁਪੇ ਐਲੋਕੇਸ਼ਨ, ਕਾਪੀ vs ਮੂਵ, ਥ੍ਰੈਡ ਸੇਫਟੀ, ਅਤੇ API ਕਲੀਅਰਟੀ (ਕੌਣ ਕੀ ਮਾਲਕੀ ਹੈ?)।
• ਟੂਲਿੰਗ: ਵਾਰਨਿੰਗਜ਼-ਏਜ਼-ਏਰਰਸ, sanitizers (ASan/UBSan/TSan), ਸਟੈਟਿਕ ਵਿਸ਼ਲੇਸ਼ਣ, ਅਤੇ ਫਾਰਮੇਟਿੰਗ।
• ਬੈਂਚਮਾਰਕਿੰਗ ਸੰਸਕ੍ਰਿਤੀ: ਪ੍ਰਤਿਨਿਧੀ ਵਰਕਲੋਡ ਨਿਰਧਾਰਤ ਕਰੋ, ਬਦਲਾਅ ਤੋਂ ਪਹਿਲਾਂ/ਬਾਅਦ ਮਾਪੋ, ਲੇਟੈਂਸੀ ਪ੍ਰਤੀਸ਼ਤ (percentiles) ਟਰੈਕ ਕਰੋ (ਸਿਰਫ਼ ਔਸਤ ਨਹੀਂ), ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਟੈਸਟ CI ਵਿੱਚ ਰੱਖੋ।

ਇੱਕ ਸਧਾਰਣ ਸਿੱਖਣ ਦਾ ਰਾਹ

1. ਆਧੁਨਿਕ ਬੁਨਿਆਦੀ: ਵੈਲਯੂ ਟਾਈਪ, ਰੇਫਰੰਸ, RAII, ਮਿਆਰੀ ਲਾਇਬ੍ਰੇਰੀ, ਅਤੇ ਸਾਫ਼ ਇੰਟਰਫੇਸ ਲਿਖਣਾ।
2. ਮੁੱਖ ਪ੍ਰਦਰਸ਼ਨ ਨਿਯਮ: ਡੇਟਾ ਸਟ੍ਰਕਚਰ, ਕੈਸ਼ ਦੋਸਤਤਾ, ਐਲੋਕੇਸ਼ਨ ਰਣਨੀਤੀਆਂ, ਅਤੇ ਪ੍ਰੋਫਾਈਲਿੰਗ।
3. ਉੱਨਤ ਟੂਲ: ਟੇmplੇਟ/ਜਨਰਿਕ, ਕਨਕਰੈਂਸੀ ਪ੍ਰਿਮਿਟਿਵ, ਅਤੇ ਜਦੋਂ ਲੋੜ ਹੋਵੇ ਤਾਂ ਕੰਪਾਈਲਰ ਆਉਟਪੁੱਟ ਪੜ੍ਹਨਾ।

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

ਇਸ ਤਸਵੀਰ ਵਿੱਚ Koder.ai ਦੀ ਜਗ੍ਹਾ

ਭਾਵੇਂ ਤੁਹਾਡਾ ਪਰਫਾਰਮੈਂਸ-ਸੰਵੇਦਨਸ਼ੀਲ ਕੋਰ C++ ਵਿੱਚ ਹੀ ਰਹੇ, ਬਹੁਤ ਸਾਰੀਆਂ ਟੀਮਾਂ ਨੂੰ ਖੁਪਰੇ-ਦੂਰ ਨਿਰਧਾਰਨ ਤੇਜ਼ੀ ਨਾਲ ਭੇਜਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ: ਡੈਸ਼ਬੋਰਡ, ਐਡਮਿਨ ਟੂਲ, ਅੰਦਰੂਨੀ APIs, ਜਾਂ ਪ੍ਰੋਟੋਟਾਈਪ ਜੋ ਲੋੜਾਂ ਨੂੰ ਵੈਰੀਫਾਈ ਕਰਨ ਲਈ ਨੀਵੇ ਪੱਧਰ ਦੀ ਇੰਪਲੀਮੇਨਟੇਸ਼ਨ ਤੋਂ ਪਹਿਲਾਂ ਬਣਾਏ ਜਾਂਦੇ ਹਨ।

ਇੱਥੇ Koder.ai ਇਕ ਪ੍ਰਯੋਗਿਕ ਪೂರਕ ਹੋ ਸਕਦਾ ਹੈ। ਇਹ ਇੱਕ vibe-coding ਪਲੇਟਫਾਰਮ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਚੈਟ ਇੰਟਰਫੇਸ ਤੋਂ ਵੈੱਬ, ਸਰਵਰ ਅਤੇ ਮੋਬਾਈਲ ਐਪ ਬਣਾਉਣ ਦਿੰਦਾ ਹੈ (React ਵੈੱਬ ਤੇ, Go + PostgreSQL ਬੈਕਐਂਡ, Flutter ਮੋਬਾਈਲ), ਯੋਜਨਾ ਮੋਡ, ਸੋਰਸ ਕੋਡ ਐਕਸਪੋਰਟ, ਡਿਪਲੋਇਮੈਂਟ/ਹੋਸਟਿੰਗ, ਕਸਟਮ ਡੋਮੇਨ, ਅਤੇ ਰੋਲਬੈਕ ਨਾਲ ਸਨੈਪਸ਼ਾਟ ਆਦਿ ਦੇ ਵਿਕਲਪਾਂ ਨਾਲ। ਦੂਜਾ ਸ਼ਬਦਾਂ ਵਿੱਚ: ਤੁਸੀਂ “ਹੌਟ ਪਾਥ ਦੇ ਆਲੇ-ਦੁਆਲੇ” ਤੇਜ਼ੀ ਨਾਲ ਇਟਰੇਟ ਕਰ ਸਕਦੇ ਹੋ, ਜਦੋਂ ਕਿ ਆਪਣੇ C++ ਕੰਪੋਨੈਂਟਾਂ ਨੂੰ ਉਹੀ ਜਗ੍ਹਾ ਛੱਡੀਏ ਜਿੱਥੇ ਜ਼ੀਰੋ-ਕੋਸਟ ਐਬਸਟ੍ਰੈਕਸ਼ਨ ਅਤੇ ਨਿਯੰਤਰਣ ਸਭ ਤੋਂ ਜ਼ਰੂਰੀ ਹਨ।