ਜਾਣੋ ਕਿ Bjarne Stroustrup ਨੇ C++ ਨੂੰ ਬਿਨਾਂ-ਖਰਚ ਵਾਲੀਆਂ ਐਬਸਟ੍ਰੈਕਸ਼ਨਾਂ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਕਿਵੇਂ ਸੰਵਾਰਿਆ, ਅਤੇ ਕਿਉਂ ਪਰਫਾਰਮੈਂਸ-ਸੰਵੇਦਨਸ਼ੀਲ ਸਾਫਟਵੇਅਰ ਅਜੇ ਵੀ ਇਸਦੇ ਨਿਯੰਤਰਣ, ਟੂਲਾਂ ਅਤੇ ਇਕੋਸਿਸਟਮ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ।
C++ ਇੱਕ ਖ਼ਾਸ ਵਾਅਦੇ ਨਾਲ ਬਣਾਈ ਗਈ ਭਾਸ਼ਾ ਹੈ: ਤੁਸੀਂ ਐਕਸਪ੍ਰੈਸਿਵ, ਉੱਚ-ਪੱਧਰ ਦਾ ਕੋਡ — ਕਲਾਸਾਂ, ਕਨਟੇਨਰ, ਜਨਰਿਕ ਅਲਗੋਰਿਦਮ — ਲਿਖ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਇਸ ਐਕਸਪ੍ਰੈਸਿਵਨੈਸ ਲਈ ਆਟੋਮੈਟਿਕ ਤੌਰ 'ਤੇ ਵਾਧੂ ਰਨਟਾਈਮ ਖ਼ਰਚ ਭੁਗਤਣ ਦੇ। ਜੇ ਤੁਸੀਂ ਕਿਸੇ ਫੀਚਰ ਨੂੰ ਵਰਤਦੇ ਨਹੀਂ, ਤਾਂ ਤੁਹਾਨੂੰ ਉਸ ਦੀ ਕੀਮਤ ਨਹੀਂ ਚੁੱਕਣੀ ਚਾਹੀਦੀ। ਜੇ ਤੁਸੀਂ ਵਰਤਦੇ ਹੋ, ਤਾਂ ਖ਼ਰਚ ਕਰੀਬ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਉਸ ਚੀਜ਼ ਦੇ ਜੋ ਤੁਸੀਂ ਹੱਥੋਂ-ਲਿਖਿਆ ਹੋਵੇ ਇੱਕ ਨੀਵੇਂ-ਪੱਧਰ ਦੇ ਸਟਾਈਲ ਵਿੱਚ।
ਇਹ ਪੋਸਟ ਇਸ ਗੱਲ ਦੀ ਕਹਾਣੀ ਹੈ ਕਿ Bjarne Stroustrup ਨੇ ਇਸ ਲਕੜੀ ਨੂੰ ਇਕ ਭਾਸ਼ਾ ਵਿੱਚ ਕਿਵੇਂ ਢਾਲਿਆ, ਅਤੇ ਇਹ ਵਿਚਾਰ ਅਜੇ ਵੀ ਕਿਉਂ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ। ਇਹ ਉਹਨਾਂ ਲਈ ਇੱਕ ਵਰਤੀਗਾਰੀ ਗਾਈਡ ਵੀ ਹੈ ਜੋ ਪ੍ਰਦਰਸ਼ਨ ਦੀ ਪਰਵਾਹ ਕਰਦੇ ਹਨ ਅਤੇ ਜਾਣਨਾ ਚਾਹੁੰਦੇ ਹਨ ਕਿ C++ ਕਿਸ ਚੀਜ਼ ਨੂੰ Optimize ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ—ਨਾਲੀ ਸਲੋਗਨਾਂ ਤੋਂ ਉੱਪਰ।
“ਉੱਚ-ਪ੍ਰਦਰਸ਼ਨ” ਸਿਰਫ਼ ਬੈਂਚਮਾਰਕ ਨੰਬਰ ਵਧਾਉਣ ਬਾਰੇ ਨਹੀਂ ਹੈ। ਸਧਾਰਨ ਸ਼ਬਦਾਂ ਵਿੱਚ, ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਹਾਲਤਾਂ ਵਿੱਚੋਂ ਕੋਈ ਇੱਕ ਸੱਚੀ ਹੁੰਦੀ ਹੈ:
ਜਦੋਂ ਇਹ ਪਾਬੰਦੀਆਂ ਮਾਇਨੇ ਰੱਖਦੀਆਂ ਹਨ, ਤਾਂ ਛੁਪਿਆ ਹੋਇਆ ਓਵਰਹੈਡ—ਵਾਧੂ ਐਲੋਕੇਸ਼ਨ, ਬੇਕਾਰ ਨਕਲਾਂ, ਜਾਂ ਜਿੱਥੇ ਲੋੜ ਨਹੀਂ ਉੱਥੇ ਵਰਚੁਅਲ ਡਿਸਪੈਚ—“ਚੱਲਦਾ ਹੈ” ਅਤੇ “ਟਾਰਗੇਟ ਮਿਸ” ਦੇ ਵਿਚਕਾਰ ਫ਼ਰਕ ਹੋ ਸਕਦਾ ਹੈ।
C++ ਆਮ ਤੌਰ 'ਤੇ ਸਿਸਟਮ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਅਤੇ ਪਰਫਾਰਮੈਂਸ-ਸੰਵੇਦਨਸ਼ੀਲ ਕੰਪੋਨੈਂਟ ਲਈ ਵਰਤੀ ਜਾਂਦੀ ਹੈ: ਗੇਮ ਇੰਜਣ, ਬਰਾਊਜ਼ਰ, ਡੇਟਾਬੇਸ, ਗ੍ਰਾਫਿਕਸ ਪਾਈਪਲਾਈਨ, ਟਰੇਡਿੰਗ ਸਿਸਟਮ, ਰੋਬੋਟਿਕਸ, ਟੈਲੀਕੌਮ ਅਤੇ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਦੇ ਹਿੱਸੇ। ਇਹ ਇਕੱਲਾ ਵਿਕਲਪ ਨਹੀਂ ਹੈ, ਅਤੇ ਬਹੁਤ ਸਾਰੇ ਆਧੁਨਿਕ ਉਤਪਾਦ ਭਾਸ਼ਾਵਾਂ ਨੂੰ ਮਿਕਸ ਕਰਦੇ ਹਨ। ਪਰ ਜਦੋਂ ਟੀਮਾਂ ਨੂੰ ਇਹ ਨਿਯੰਤਰਣ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕੋਡ ਮਸ਼ੀਨ ਨਾਲ ਕਿਵੇਂ ਮੇਪ ਹੋਵੇ, ਤਾਂ C++ ਅਕਸਰ “ਅੰਦਰਲੀ-ਲੂਪ” ਟੂਲ ਬਣ ਕੇ ਰਹਿੰਦੀ ਹੈ।
ਹੋਂਡਰ, ਅਸੀਂ ਜ਼ੀਰੋ-ਕੋਸਟ ਵਿਚਾਰ ਨੂੰ ਸਾਧਾ ਅੰਗਰੇਜ਼ੀ ਵਿੱਚ ਖੋਲਾਂਗੇ, ਫਿਰ ਇਸਨੂੰ ਖਾਸ C++ ਤਕਨੀਕਾਂ (ਜਿਵੇਂ RAII ਅਤੇ ਟੇmplੇਟ) ਨਾਲ ਜੋੜਾਂਗੇ ਅਤੇ ਉਹ ਅਸਲ ਟਰੇਡ-ਆਫ਼ ਜਿਹੜੇ ਟੀਮਾਂ ਨਾਲ ਮੁਕਾਬਲਾ ਹੁੰਦੇ ਹਨ, ਵੇਖਾਂਗੇ।
Bjarne Stroustrup ਨੇ ਇੱਕ ਨਵੀਂ ਭਾਸ਼ਾ “ਖੁਦ ਲਈ” ਬਣਾਉਣ ਦਾ ਫੈਸਲਾ ਨਹੀਂ ਕੀਤਾ। 1970s ਅਤੇ 1980s ਦੇ ਅਖੀਰਲੇ ਦਹਾਕੇ ਵਿੱਚ, ਉਹ ਸਿਸਟਮ ਕੰਮ ਕਰ ਰਹੇ ਸੀ ਜਿੱਥੇ C ਤੇਜ਼ ਅਤੇ ਮਸ਼ੀਨ ਦੇ ਨੇੜੇ ਸੀ, ਪਰ ਵੱਡੇ ਪ੍ਰੋਗਰਾਮਾਂ ਨੂੰ ਠੀਕ ਢੰਗ ਨਾਲ ਢਾਂਚਾ ਦੇਣਾ ਮੁਸ਼ਕਲ, ਬਦਲਣਾ ਔਖਾ ਅਤੇ ਟੁੱਟਣਾ ਆਸਾਨ ਸੀ।
ਉਹਦਾ ਲਕਸ਼ ਸਧਾ ਸੀ ਪਰ ਪ੍ਰਾਪਤ ਕਰਨਾ ਔਖਾ: ਵੱਡੇ ਪ੍ਰੋਗਰਾਮਾਂ ਨੂੰ ਢਾਂਚਾ ਦੇਣ ਦੇ ਚੰਗੇ ਤਰੀਕੇ—ਟਾਈਪ, ਮੋਡੀਊਲ, ਇਨਕੈਪਸੂਲੇਸ਼ਨ—ਲਿਆਓ ਬਿਨਾਂ ਉਸ ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਹਾਰਡਵੇਅਰ ਐਕਸੈਸ ਨੂੰ ਛੱਡੇ ਜੋ C ਨੂੰ ਕੀਮਤੀ ਬਣਾਉਂਦੇ ਹਨ।
ਸਭ ਤੋਂ ਪਹਿਲਾ ਕਦਮ ਲਫ਼ਜ਼ੀ ਤੌਰ 'ਤੇ “C with Classes” ਨਾਮ ਦੇ ਨਾਲ ਸੀ। ਇਹ ਨਾਂ ਦਿਸਾਉਂਦਾ ਹੈ ਕਿ ਮਕਸਦ ਇੱਕ ਪੂਰੇ ਸਲੇਟ ਦੀ ਦੁਬਾਰਾ ਡਿਜ਼ਾਈਨ ਨਹੀਂ ਸੀ, ਪਰ ਇੱਕ ਇਵੋਲੂਸ਼ਨ। C ਦੀਆਂ ਵਧੀਆਆਂ ਗੁਣਾਂ (ਪੇਸ਼ਗੋਹੀਤ ਪਰਫਾਰਮੈਂਸ, ਸੀਧਾ ਮੈਮੋਰੀ ਐਕਸੈਸ, ਸਾਦਾ ਕਾਲਿੰਗ ਕਨਵੈਨਸ਼ਨ) ਨੂੰ ਰੱਖੋ, ਫਿਰ ਵੱਡੇ ਸਿਸਟਮ ਬਣਾਉਣ ਲਈ ਘੁੱਟੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਸ਼ਾਮਿਲ ਕਰੋ।
ਜਿਵੇਂ-ਜਿਵੇਂ ਭਾਸ਼ਾ C++ ਵਿੱਚ ਵਿਕਸਤ ਹੋਈ, ਜੋੜੀਆਂ ਗਈਆਂ ਚੀਜ਼ਾਂ ਸਿਰਫ਼ “ਵੱਧ ਫੀਚਰ” ਨਹੀਂ ਸਨ। ਉਹ ਇਸ ਉਦੇਸ਼ ਲਈ ਡਿਜ਼ਾਈਨ ਕੀਤੀਆਂ ਗਈਆਂ ਸਨ ਕਿ ਜਦੋਂ ਸੋਝੀ-ਵਿਹਾਰ ਨਾਲ ਵਰਤਿਆ ਜਾਵੇ ਤਾਂ ਉੱਚ-ਪੱਧਰ ਦਾ ਕੋਡ ਉਹੋ ਹੀ ਮਸ਼ੀਨ ਕੋਡ ਬਣੇ ਜੋ ਤੁਸੀਂ C ਵਿੱਚ ਹੱਥੋਂ-ਲਿਖਿਆ ਹੋਵੋਗੇ।
Stroustrup ਦਾ ਮੱਤਵ ਉਹੀ ਰਿਹਾ—ਅਤੇ ਅਜੇ ਵੀ ਹੈ—ਦੋਹਾਂ ਦੇ ਵਿਚਕਾਰ:
ਬਹੁਤ ਸਾਰੀਆਂ ਭਾਸ਼ਾਵਾਂ ਵੇਖਣ ਦੇ ਤਰੀਕੇ ਨੂੰ ਛੁਪਾ ਦਿੰਦੀਆਂ ਹਨ (ਜੋ ਓਵਰਹੈਡ ਨੂੰ ਛੁਪਾ ਸਕਦਾ ਹੈ)। C++ ਤੁਹਾਨੂੰ ਐਬਸਟ੍ਰੈਕਸ਼ਨ ਬਣਾਉਣ ਦਿੰਦੀ ਹੈ ਜਦੋਂ ਕਿ ਤੁਸੀਂ ਹਮੇਸ਼ਾ ਪੁੱਛ ਸਕਦੇ ਹੋ, “ਇਸ ਦੀ ਕੀਮਤ ਕੀ ਹੈ?” ਅਤੇ ਜ਼ਰੂਰਤ ਪੈਣ 'ਤੇ ਨੀਵੇਂ ਪੱਧਰ ਤੇ ਜਾ ਸਕਦੇ ਹੋ।
ਇਹ ਪ੍ਰੇਰਣਾ—ਸਜ਼ਾ ਬਿਨਾਂ ਐਬਸਟ੍ਰੈਕਸ਼ਨ—C++ ਦੀ ਸ਼ੁਰੂਆਤੀ ਕਲਾਸ ਸਹਾਇਤਾ ਤੋਂ ਲੈ ਕੇ RAII, ਟੇmplੇਟ ਅਤੇ STL ਵਰਗੀਆਂ ਵਾਦੀਆਂ ਤੱਕ ਜੁੜੀ ਰਹੀ।
“ਜ਼ੀਰੋ-ਕੋਸਟ ਐਬਸਟ੍ਰੈਕਸ਼ਨ” ਇੱਕ ਨਾਰੇ ਵਾਂਗ ਨਹੀਂ ਹੈ; ਇਹ ਵਪਾਰ-ਸੰਬੰਧੀ ਪ੍ਰਭਾਵਾਂ ਬਾਰੇ ਇਕ ਵਾਅਦਾ ਹੈ। ਰੋਜ਼ਾਨਾ ਵਰਜਨ ਇਹ ਹੈ:
ਜੇ ਤੁਸੀਂ ਇਸਨੂੰ ਵਰਤਦੇ ਨਹੀਂ, ਤਾਂ ਤੁਸੀਂ ਇਸਦੀ ਕੀਮਤ ਨਹੀਂ ਭੁਗਤੋਂਗੇ। ਅਤੇ ਜੇ ਤੁਸੀਂ ਵਰਤਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਲਗਭਗ ਉਸੇ ਦੇਨਗੇ ਜੋ ਤੁਸੀਂ ਹੱਥੋਂ-ਲਿਖਿਆ ਨੀਵੇ ਪੱਧਰ ਵਾਲੇ ਕੋਡ ਲਈ ਦਿੰਦੇ।
ਪ੍ਰਦਰਸ਼ਨ ਸ਼ਬਦਾਂ ਵਿੱਚ, “ਲਾਗਤ” ਕੁਝ ਵੀ ਹੋ ਸਕਦੀ ਹੈ ਜੋ ਰਨਟਾਈਮ 'ਤੇ ਪ੍ਰੋਗਰਾਮ ਨੂੰ ਵਧੇਰੇ ਕੰਮ ਕਰਨ ਉਤੇ ਮਜਬੂਰ ਕਰੇ। ਇਸ ਵਿੱਚ ਸ਼ਾਮਿਲ ਹੋ ਸਕਦਾ ਹੈ:
ਜ਼ੀਰੋ-ਕੋਸਟ ਐਬਸਟ੍ਰੈਕਸ਼ਨ ਤੁਹਾਨੂੰ ਸਾਫ਼, ਉੱਚ-ਪੱਧਰ ਦਾ ਕੋਡ ਲਿਖਣ ਦਿੰਦੇ ਹਨ—ਟਾਈਪ, ਕਲਾਸ, ਫੰਕਸ਼ਨ, ਜਨਰਿਕ ਅਲਗੋਰਿਦਮ—ਜਦੋਂ ਕਿ ਮਸ਼ੀਨ ਕੋਡ ਹੱਥੋਂ-ਲਿਖੇ ਲੂਪਾਂ ਅਤੇ ਮੈਨੁਅਲ ਸੰਸਾਧਨ ਪ੍ਰਬੰਧਨ ਵਾਂਗ ਸਿੱਧਾ ਬਣ ਸਕਦਾ ਹੈ।
C++ ਹਰ ਚੀਜ਼ ਨੂੰ ਆਪੋ-ਆਪ ਹੀ ਤੇਜ਼ ਨਹੀਂ ਬਣਾਉਂਦਾ। ਇਹ ਸਾਂਭਦਾ ਹੈ ਕਿ ਉੱਚ-ਪੱਧਰ ਦਾ ਕੋਡ ਪ੍ਰਭਾਵਸ਼ালী ਤੌਰ 'ਤੇ ਕੰਪਾਇਲ ਹੋ ਸਕਦਾ ਹੈ—ਪਰ ਤੁਸੀਂ ਅਜੇ ਵੀ ਮਹਿੰਗੇ ਪੈਟਰਨ ਚੁਣ ਸਕਦੇ ਹੋ।
ਜੇ ਤੁਸੀਂ ਹਾਟ ਲੂਪ ਵਿੱਚ ਐਲੋਕੇਟ ਕਰਦੇ ਹੋ, ਵੱਡੇ ਆਬਜੈਕਟਾਂ ਦੀਆਂ ਬਾਰ-ਬਾਰ ਨਕਲਾਂ ਕਰਦੇ ਹੋ, ਕੈਸ਼-ਦੋਸਤ ਲੇਆਉਟ ਵਿਖੇ ਗਲਤੀ ਕਰਦੇ ਹੋ, ਜਾਂ ਇੰਡਾਇਰੈਕਸ਼ਨ ਦੀਆਂ ਲੇਅਰਾਂ ਬਣਾਉਂਦੇ ਹੋ ਜੋ ਅਪਟੀਮਾਈਜ਼ੇਸ਼ਨ ਨੂੰ ਰੋਕਦੀਆਂ ਹਨ, ਤਾਂ ਤੁਹਾਡਾ ਪ੍ਰੋਗਰਾਮ ਧੀਮਾ ਹੋ ਜਾਵੇਗਾ। C++ ਤੁਹਾਨੂੰ ਰੋਕੇਗਾ ਨਹੀਂ। “ਜ਼ੀਰੋ-ਕੋਸਟ” ਮਕਸਦ ਉਹਨਾਂ ਚੀਜ਼ਾਂ ਤੋਂ ਬਚਾਓ ਕਰਨ ਬਾਰੇ ਹੈ ਜੋ ਜ਼ਬਰਦਸਤੀ ਓਵਰਹੈਡ ਲਗਾਉਂਦੀਆਂ ਹਨ, ਨਾ ਕਿ ਚੰਗੇ ਫੈਸਲੇ ਦੀ ਗਾਰੰਟੀ ਦੇਣ ਬਾਰੇ।
ਲੇਖ ਦੇ ਬਾਕੀ ਹਿੱਸੇ ਵਿੱਚ ਅਸੀਂ ਇਸ ਵਿਚਾਰ ਨੂੰ ਠੋਸ ਬਣਾਉਂਦੇ ਹਾਂ। ਅਸੀਂ ਵੇਖਾਂਗੇ ਕਿ ਕੰਪਾਈਲਰ ਅਬਸਟ੍ਰੈਕਸ਼ਨ ਓਵਰਹੈਡ ਕਿਵੇਂ ਮਿਟਾਉਂਦਾ ਹੈ, RAII ਕਿਵੇਂ ਸੁਰੱਖਿਆ ਅਤੇ ਤੇਜ਼ੀ ਦੋਹਾਂ ਦੇ ਸਕਦਾ ਹੈ, ਟੇmplੇਟ ਕਿਵੇਂ ਹੱਥੋਂ-ਟਿਊਨ ਕੀਤੇ ਵਰਜਨਾਂ ਵਾਂਗ ਚਲਦੇ ਕੋਡ ਬਣਾਉਂਦੇ ਹਨ, ਅਤੇ STL ਕਿਸ ਤਰ੍ਹਾਂ ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੇ ਬਿਲਡਿੰਗ ਬਲੌਕ ਦਿੰਦਾ ਹੈ ਬਿਨਾਂ ਚੁਪਚਾਪ ਰਨਟਾਈਮ ਕੰਮ ਦੇ—ਜਦੋਂ इन्हें ਧਿਆਨ ਨਾਲ ਵਰਤਿਆ ਜਾਵੇ।
C++ ਇੱਕ ਸਧਾਰਨ ਬਦਲੇ ਤੇ ਆਸਰਾ ਰੱਖਦਾ ਹੈ: ਬਿਲਡ ਟਾਈਮ 'ਤੇ ਵੱਧ ਭੁਗਤੋ ਤਾਂ ਜੋ ਰਨਟਾਈਮ 'ਤੇ ਘੱਟ ਭੁਗਤੋ। ਜਦੋਂ ਤੁਸੀਂ ਕੰਪਾਈਲ ਕਰਦੇ ਹੋ, ਕੰਪਾਈਲਰ ਸਿਰਫ਼ ਤੁਹਾਡੇ ਕੋਡ ਦਾ ਅਨੁਵਾਦ ਨਹੀਂ ਕਰਦਾ—ਉਹ ਉਹਨਾਂ ਓਵਰਹੈਡਾਂ ਨੂੰ ਹਟਾਉਣ ਲਈ ਕਾਫ਼ੀ ਮਿਹਨਤ ਕਰਦਾ ਹੈ ਜੋ ਹੋਰਥਾਂ ਪ੍ਰੋਗਰਾਮ ਚਲਦੇ ਸਮੇਂ ਦਿਖਾਈ ਦਿੰਦੀਆਂ।
ਕੰਪਾਈਲਰ ਦਰਮਿਆਨ ਇਹਨਾਂ ਖ਼ਰਚਾਂ ਨੂੰ “ਪਹਿਲਾਂ ਹੀ ਭੁਗਤ ਸਕਦਾ” ਹੈ:
ਮਕਸਦ ਇਹ ਹੈ ਕਿ ਤੁਹਾਡੀ ਸਾਫ਼, ਪੜ੍ਹਨਯੋਗ ਸੰਰਚਨਾ ਅਜੇਹੇ ਮਸ਼ੀਨ ਕੋਡ ਵਿੱਚ ਬਦਲ ਜਾਵੇ ਜੋ ਤੁਸੀਂ ਹੱਥੋਂ-ਲਿਖਣ 'ਤੇ ਬਣਾਉਂਦੇ।
ਇੱਕ ਛੋਟਾ ਸਹਾਇਕ ਫੰਕਸ਼ਨ ਜਿਵੇਂ:
int add_tax(int price) { return price * 108 / 100; }
ਅਕਸਰ ਕੰਪਾਈਲੇਸ਼ਨ ਤੋਂ ਬਾਅਦ ਕੋਈ ਕਾਲ ਨਹੀਂ ਬਣਦਾ। ਕਾਲ ਕਰਨ ਦੀ ਥਾਂ ਤੇ ਕੰਪਾਈਲਰ ਸਿੱਧਾ ਗਣਿਤ ਨੂੰ ਉਸ ਥਾਂ 'ਤੇ ਲੱਗਾ ਸਕਦਾ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ ਇਸਨੂੰ ਵਰਤਿਆ। ਐਬਸਟ੍ਰੈਕਸ਼ਨ (ਇੱਕ ਸੁੰਦਰ ਨਾਮ ਦਿੱਤਾ ਫੰਕਸ਼ਨ) ਅਸਲ ਵਿੱਚ ਗਾਇਬ ਹੋ ਜਾਂਦੀ ਹੈ।
ਲੂਪਾਂ ਨੂੰ ਵੀ ਧਿਆਨ ਮਿਲਦਾ ਹੈ। ਇੱਕ ਇਕਸਾਰ ਰੇਂਜ ਉੱਤੇ ਸਿਧਾ ਲੂਪ ਆਪਟੀਮਾਈਜ਼ਰ ਦੁਆਰਾ ਬਦਲਾਂ ਜਾ ਸਕਦਾ ਹੈ: ਜਦੋਂ ਸਾਬਤ ਤੌਰ 'ਤੇ ਲਾਜ਼ਮੀ ਨਾ ਹੋਵੇ ਤਾਂ ਬਾਊਂਡ ਚੈਕ ਹਟਾਏ ਜਾ ਸਕਦੇ ਹਨ, ਦੁਹਰਾਏ ਗਏ ਹਿਸਾਬ ਲੂਪ ਤੋਂ ਬਾਹਰ ਖਿੱਚੇ ਜਾ ਸਕਦੇ ਹਨ, ਅਤੇ ਲੂਪ ਬਾਡੀ ਨੂੰ CPU ਦੀ ਵਰਤੋਂ ਲਈ ਦੁਬਾਰਾ ਢਾਂਚਾ ਦਿੱਤਾ ਜਾ ਸਕਦਾ ਹੈ।
ਇਹ ਜ਼ੀਰੋ-ਕੋਸਟ ਐਬਸਟ੍ਰੈਕਸ਼ਨਾਂ ਦਾ ਪ੍ਰਾਇਗਿਕ ਅਰਥ ਹੈ: ਤੁਸੀਂ ਸਾਫ਼ ਕੋਡ ਪਾਉਂਦੇ ਹੋ ਬਿਨਾਂ ਉਸ ਰਚਨਾ ਲਈ ਸਥਾਈ ਰਨਟਾਈਮ ਫੀਸ ਭੁਗਤਣ ਦੇ।
ਕੋਈ ਚੀਜ਼ ਮੁਫ਼ਤ ਨਹੀਂ। ਵੱਧ ਅਪਟੀਮਾਈਜ਼ੇਸ਼ਨ ਅਤੇ ਹੋਰ “ਗਾਇਬ ਹੋਣ ਵਾਲੀਆਂ ਐਬਸਟ੍ਰੈਕਸ਼ਨਾਂ” ਦਾ ਮਤਲਬ ਹੋ ਸਕਦਾ ਹੈ ਲੰਬਾ ਕੰਪਾਈਲ ਸਮਾਂ ਅਤੇ ਕਈ ਵਾਰੀ ਵੱਡੇ ਬਾਈਨਰੀ (ਜਿਵੇਂ, ਜਦੋਂ ਕਈ ਕਾਲ ਸਾਈਟਾਂ ਇਨਲਾਈਨ ਹੋ ਜਾਂਦੀਆਂ ਹਨ)। C++ ਤੁਹਾਨੂੰ ਚੋਣ ਅਤੇ ਜ਼ਿੰਮੇਵਾਰੀ ਦਿੰਦਾ ਹੈ ਕਿ ਬਿਲਡ ਖ਼ਰਚ ਅਤੇ ਰਨਟਾਈਮ ਗਤੀਵਿਧੀ ਵਿੱਚ ਕਿਵੇਂ ਸੰਤੁਲਨ ਬਣਾਇਆ ਜਾਵੇ।
RAII (Resource Acquisition Is Initialization) ਇੱਕ ਸਧਾਰਨ ਨਿਯਮ ਹੈ ਜਿਸਦੇ ਵੱਡੇ ਨਤੀਜੇ ਹੁੰਦੇ ਹਨ: ਸੰਸਾਧਨ ਦੀ ਉਮਰ ਇੱਕ ਸਕੋਪ ਨਾਲ ਜੁੜੀ ਹੁੰਦੀ ਹੈ। ਜਦੋਂ ਇੱਕ ਆਬਜੈਕਟ ਬਣਦਾ ਹੈ, ਉਹ ਸੰਸਾਧਨ ਪ੍ਰਾਪਤ ਕਰ ਲੈਂਦਾ ਹੈ। ਜਦੋਂ ਆਬਜੈਕਟ ਸਕੋਪ ਤੋਂ ਬਾਹਰ ਨਿਕਲਦਾ ਹੈ, ਉਸਦਾ ਡੈਸਟਰਕਟਰ ਇਸਨੂੰ ਰਿਲੀਜ਼ ਕਰ ਦਿੰਦਾ—ਆਟੋਮੈਟਿਕ ਤਰੀਕੇ ਨਾਲ।
ਉਹ “ਸੰਸਾਧਨ” ਲਗਭਗ ਕਿਸੇ ਵੀ ਚੀਜ਼ ਹੋ ਸਕਦੀ ਹੈ ਜਿਸਦੀ ਤੁਸੀਂ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਸਫਾਈ ਦੀ ਲੋੜ ਹੈ: ਮੈਮੋਰੀ, ਫਾਇਲ, ਮਿਊਟੈਕਸ ਲਾਕ, ਡੇਟਾਬੇਸ ਹੈਂਡਲ, ਸਾਕਟ, GPU ਬਫਰ ਆਦਿ। ਹਰ ਰੀਟਰਨ ਪਾਥ 'ਤੇ close(), unlock(), ਜਾਂ free() ਯਾਦ ਰੱਖਣ ਦੀ ਥਾਂ, ਤੁਸੀਂ ਕਲੀਨਅਪ ਨੂੰ ਇੱਕ ਥਾਂ (ਡੈਸਟਰਕਟਰ) ਵਿੱਚ ਰੱਖਦੇ ਹੋ ਅਤੇ ਭਾਸ਼ਾ ਇਹ ਗਾਰੰਟੀ ਕਰਦੀ ਹੈ ਕਿ ਇਹ ਚੱਲੇਗਾ।
ਮੇਨੂਅਲ ਕਲੀਨਅਪ ਅਕਸਰ “ਸ਼ੈਡੋ ਕੋਡ” ਪੈਦਾ ਕਰਦਾ ਹੈ: ਵਾਧੂ if ਚੈੱਕ, ਨਕਲ ਕੀਤੇ ਹੋਏ return ਹੈਂਡਲਿੰਗ, ਅਤੇ ਹਰ ਸੰਭਵ ਤਰੁੱਟੀ ਮਾਰਗ ਤੋਂ ਬਾਅਦ ਧਿਆਨ ਨਾਲ ਰੱਖੇ ਗਏ ਕਲੀਨਅਪ ਕਾਲ। ਫੰਕਸ਼ਨਾਂ ਦੇ ਵਿਕਸਤ ਹੋਣ ਨਾਲ ਇੱਕ ਸ਼ਾਖ ਨੂੰ ਭੁਲਾਉਣਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ।
RAII ਆਮ ਤੌਰ 'ਤੇ ਸਿੱਧੀ-ਲਾਈਨ ਕੋਡ ਪੈਦਾ ਕਰਦਾ ਹੈ: ਪ੍ਰਾਪਤੀ, ਕੰਮ ਕਰੋ, ਅਤੇ ਸਕੋਪ ਦੇ ਬਾਹਰ ਜਾਉ ਤਾਂ ਕਲੀਨਅਪ ਹੋ ਜਾਵੇ। ਇਸ ਨਾਲ ਨਾਂ ਸਿਰਫ਼ ਬਗ (ਲੀਕ, ਡਬਲ-ਫਰੀ, ਭੁੱਲੇ ਹੋਏ ਅਨਲੌਕ) ਘਟਦੇ ਹਨ, ਬਲਕਿ ਗਰਮ ਰਾਹ 'ਤੇ ਘੱਟ ਤਫ਼ਤੀਸ਼ ਕੋਡ ਹੋਣ ਕਾਰਨ ਇੰਸਟਰਕਸ਼ਨ ਕੈਸ਼ ਅਤੇ ਬ੍ਰਾਂਚ ਪੇਸ਼ਗੋਈ ਵਿੱਚ ਸੁਧਾਰ ਵੀ ਹੋ ਸਕਦਾ ਹੈ।
ਲੀਕ ਅਤੇ ਰਿਲੀਜ਼ ਨਾ ਹੋਏ ਲਾਕ ਸਿਰਫ਼ “ਸਹੀਤਾ ਮੁੱਦੇ” ਨਹੀਂ; ਉਹ ਪ੍ਰਦਰਸ਼ਨ ਲਈ ਲੰਬੇ ਸਮੇਂ ਦੇ ਬੰਬ ਹੁੰਦੇ ਹਨ। RAII ਸੰਸਾਧਨ ਰਿਹਾ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਿਯਤ ਬਨਾਉਂਦਾ ਹੈ, ਜੋ ਲੋਡ ਹੇਠ ਸਿਸਟਮਾਂ ਨੂੰ ਸਥਿਰ ਰੱਖਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ।
Exceptions ਨਾਲ RAII ਚਮਕਦੀ ਹੈ ਕਿਉਂਕਿ ਸਟੈਕ ਅਨਵਾਇਂਡਿੰਗ ਦੌਰਾਨ ਡੈਸਟਰਕਟਰ ਫਿਰ ਵੀ ਚਲਦੇ ਹਨ, ਇਸ ਲਈ ਸੰਸਾਧਨ ਛੁੱਟ ਜਾਂਦੇ ਹਨ ਭਾਵੇਂ ਕੰਟਰੋਲ ਫਲੋ ਅਚਾਨਕ ਕਿਉਂ ਨਾ ਵਰਿੱਕੇ। Exceptions ਇੱਕ ਟੂਲ ਹਨ: ਉਹਦੀ ਲਾਗਤ ਇਸ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ ਕਿ ਉਹ ਕਿਵੇਂ ਵਰਤੇ ਜਾਂਦੇ ਹਨ ਅਤੇ ਕੰਪਾਈਲਰ/ਪਲੈਟਫਾਰਮ ਸੈਟਿੰਗਜ਼ ਕੀ ਹਨ। ਮੁੱਖ ਗੱਲ ਇਹ ਹੈ ਕਿ RAII ਕਿਸੇ ਵੀ ਤਰੀਕੇ ਨਾਲ ਸਕੋਪ ਛੱਡਣ 'ਤੇ ਕਲੀਨਅਪ ਨਿਰਧਾਰਤ ਰੱਖਦੀ ਹੈ।
ਟੇmplੇਟਾਂ ਨੂੰ ਅਕਸਰ “ਕੰਪਾਇਲ-ਟਾਈਮ ਕੋਡ ਜਨਰੇਸ਼ਨ” ਵਜੋਂ ਵੇਖਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਇਹ ਇੱਕ ਉਪਯੋਗਕਾਰੀ ਸੋਚ ਦਾ ਮਾਡਲ ਹੈ। ਤੁਸੀਂ ਇਕ ਵਾਰੀ ਐਲਗੋਰਿਦਮ ਲਿਖਦੇ ਹੋ—ਉਦਾਹਰਨ ਵਜੋਂ, “ਇਹਨਾਂ ਆਇਟਮਾਂ ਨੂੰ ਸੋਰਟ ਕਰੋ” ਜਾਂ “ਆਇਟਮਾਂ ਨੂੰ ਇੱਕ ਕਨਟੇਨਰ ਵਿੱਚ ਸਟੋਰ ਕਰੋ”—ਅਤੇ ਕੰਪਾਈਲਰ ਉਹ ਵਰਜਨ ਉਸੇ ਦੀਆਂ ਨਿਰਧਾਰਤ ਕਿਸਮਾਂ ਲਈ ਤਿਆਰ ਕਰਦਾ ਹੈ।
ਕੰਪਾਈਲਰ ਨੂੰ ਜਦੋਂ ਸੰਕੁਚਿਤ ਕਿਸਮਾਂ ਪਤਾ ਹੁੰਦੀਆਂ ਹਨ, ਉਹ ਇਨਲਾਈਨ ਕਰ ਸਕਦਾ ਹੈ, ਢੰਗ ਦੇ ਅਨੁਸਾਰ ਓਪਰੇਸ਼ਨ ਚੁਣ ਸਕਦਾ ਹੈ, ਅਤੇ ਜੋਰ ਨਾਲ ਅਪਟੀਮਾਈਜ਼ ਕਰ ਸਕਦਾ ਹੈ। ਕਈ ਹਾਲਤਾਂ ਵਿੱਚ, ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਸੀਂ ਵਰਚੁਅਲ ਕਾਲਜ਼, ਰਨਟਾਈਮ ਟਾਈਪ ਚੈਕ ਅਤੇ ਡਾਇਨਾਮਿਕ ਡਿਸਪੈਚ ਤੋਂ ਬਚ ਜਾਂਦੇ ਹੋ ਜਿਨ੍ਹਾਂ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਸੀ ਜੇ ਕੋਡ “ਜਨਰਿਕ” ਬਣਾਉਣਾ ਸੀ।
ਉਦਾਹਰਨ ਵਜੋਂ, ਇੱਕ ਟੇmplੇਟ max(a, b) ਇੰਟੀਜਰਾਂ ਲਈ ਕੁੱਝ ਮਸ਼ੀਨ ਨਿਰਦੇਸ਼ ਬਣ ਸਕਦੀ ਹੈ।ੋਸੇ ਟੇmplੇਟ ਨੂੰ ਛੋਟੀ struct ਨਾਲ ਵਰਤਣਾ ਫਿਰ ਵੀ ਸੀਧੀ ਤੁਲਨਾ ਅਤੇ ਮੂਵਾਂ ਵਿੱਚ ਕੰਪਾਇਲ ਹੋ ਸਕਦਾ ਹੈ—ਕੋਈ ਇੰਟਰਫੇਸ ਪੋਇੰਟਰ ਜਾਂ ਰਨਟਾਈਮ “ਇਹ ਕਿਸਮ ਹੈ?” ਚੈੱਕ ਨਹੀਂ।
Standard Library ਟੇmplੇਟਾਂ 'ਤੇ ਬਹੁਤ ਨਿਰਭਰ ਹੈ ਕਿਉਂਕਿ ਉਹ ਉਨ੍ਹਾਂ ਨੂੰ ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੇ ਬਿਲਡਿੰਗ ਬਲੌਕ ਦਿੰਦੇ ਹਨ ਬਿਨਾਂ ਛੁਪੇ ਕੰਮ ਦੇ:
std::vector<T> ਅਤੇ std::array<T, N> ਤੁਹਾਡੀ T ਨੂੰ ਸਿੱਧਾ ਸਟੋਰੇਜ ਕਰਦੇ ਹਨ।std::sort ਵਰਗੇ ਅਲਗੋਰਿਦਮ ਬਹੁਤ ਸਾਰੀਆਂ ਕਿਸਮਾਂ 'ਤੇ ਕੰਮ ਕਰਦੇ ਹਨ ਜੇ ਤੱਕ ਉਹ ਤੁਲਨਾ ਯੋਗ ਹਨ।ਨਤੀਜਾ ਅਕਸਰ ਇਹ ਹੁੰਦਾ ਹੈ ਕਿ ਕੋਡ ਇੱਕ ਹੱਥੋਂ-ਲਿਖੇ, ਕਿਸਮ-ਨਿਰਧਾਰਤ ਵਰਜਨ ਵਾਂਗ ਹੀ ਪ੍ਰਦਰਸ਼ਨ ਕਰਦਾ ਹੈ—ਕਿਉਂਕਿ ਇਹ ਅਸਲ ਵਿੱਚ ਉਹੀ ਬਣ ਜਾਂਦਾ ਹੈ।
ਡਿਵੈਲਪਰਾਂ ਲਈ ਟੇmplੇਟ ਮੁਫ਼ਤ ਨਹੀਂ। ਉਹ ਕੰਪਾਈਲ ਟਾਈਮ ਵਧਾ ਸਕਦੇ ਹਨ (ਜਿਆਦਾ ਕੋਡ ਬਣਾਉਣ ਅਤੇ Optimize ਕਰਨ ਲਈ), ਅਤੇ ਜਦੋਂ ਕੁਝ ਗਲਤ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਐਰਰ ਸੁਨੇਹੇ ਲੰਬੇ ਅਤੇ ਪੜ੍ਹਨ ਵਿੱਚ ਔਖੇ ਹੋ ਸਕਦੇ ਹਨ। ਟੀਮਾਂ ਆਮ ਤੌਰ 'ਤੇ ਕੋਡਿੰਗ ਨਿਯਮ, ਚੰਗੀ Tooling ਅਤੇ ਉਹਨਾਂ ਜਗ੍ਹਾਂ 'ਤੇ ਟੇmplੇਟ ਕੰਪਲੈਕਸਿਟੀ ਰੱਖ ਕੇ ਇਸਨੂੰ ਹੱਲ ਕਰਦੀਆਂ ਹਨ ਜਿੱਥੇ ਲਾਭ ਹੈ।
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++ ਨੇ Stroustrup ਦੇ ਮੂਲ ਵਿਚਾਰ "ਸਜ਼ਾ ਬਿਨਾਂ ਐਬਸਟ੍ਰੈਕਸ਼ਨ" ਨੂੰ ਛੱਡਿਆ ਨਹੀਂ। ਬਹੁਤ ਸਾਰੇ ਨਵੇਂ ਫੀਚਰ ਉਹ ਤੁਹਾਨੂੰ ਸਾਫ਼ ਕੋਡ ਲਿਖਣ ਦਿੰਦੇ ਹਨ ਜਦੋਂ ਕਿ ਕੰਪਾਈਲਰ ਨੂੰ ਤਿੱਖਾ ਮਸ਼ੀਨ ਕੋਡ ਪੈਦਾ ਕਰਨ ਦਾ ਮੌਕਾ ਮਿਲਦਾ ਹੈ।
ਅਕਸਰ ਸੁਸਤਾਪਨ ਦੀ ਵਜ੍ਹਾ ਅਣਕਾਰਣੀ ਕਾਪੀ ਹੈ—ਵੱਡੀਆਂ strings, ਬਫਰ ਜਾਂ ਡਾਟਾ ਸਟ੍ਰਕਚਰਾਂ ਦੀ ਬੇਕਾਰ ਨਕਲ।
Move semantics ਦਾ ਸਧਾਰਨ ਵਿਚਾਰ ਹੈ “ਜੇ ਤੁਸੀਂ ਵਾਸਤਵ ਵਿੱਚ ਕਿਸੇ ਚੀਜ਼ ਨੂੰ ਹੱਥੋਂ-ਹੱਥ ਸੌਂਪ ਰਹੇ ਹੋ, ਤਾਂ ਕਾਪੀ ਨਾ ਕਰੋ।” ਜਦੋਂ ਇੱਕ ਆਬਜੈਕਟ ਅਸਥਾਈ ਹੁੰਦਾ ਹੈ (ਜਾਂ ਤੁਸੀਂ ਉਸਨੂੰ ਹੋਰ ਵਰਤੋਂ ਲਈ ਨਹੀਂ ਰੱਖ ਰਹੇ), C++ ਉਸਦੇ ਅੰਦਰੂਨੀ ਹਿੱਸਿਆਂ ਨੂੰ ਨਵੇਂ ਮਾਲਿਕ ਨੂੰ ਟ੍ਰਾਂਸਫਰ ਕਰ ਸਕਦੀ ਹੈ ਬਜਾਏ ਇਸਨੂੰ ਨਕਲ ਕਰਨ ਦੇ। ਰੋਜ਼ਾਨਾ ਕੋਡ ਲਈ, ਇਸਦਾ ਮਤਲਬ ਹੈ ਘੱਟ ਐਲੋਕੇਸ਼ਨ, ਘੱਟ ਮੈਮੋਰੀ ਟਰੈਫਿਕ ਅਤੇ ਤੇਜ਼ ਚਲਣਾ—ਬਿਨਾਂ ਮੈਨੁਅਲ ਬਾਈਟ-ਮੈਨੇਜਮੈਂਟ ਦੇ।
constexpr: ਅੱਗੇ ਹੀ ਗਣਨਾ ਕਰੋ ਤਾਂ ਕਿ ਰਨਟਾਈਮ ਘੱਟ ਕਰੇਕੁਝ ਮੁੱਲ ਅਤੇ ਫੈਸਲੇ ਕਦੇ ਨਹੀਂ ਬਦਲਦੇ (ਟੇਬਲ ਆਕਾਰ, ਕਨਫਿਗਰੇਸ਼ਨ ਕਾਂਸਟੈਂਟ, ਲੁੱਕਅਪ ਟੇਬਲ)। constexpr ਨਾਲ ਤੁਸੀਂ C++ ਨੂੰ ਆਖ ਸਕਦੇ ਹੋ ਕਿ ਕੁਝ ਨਤੀਜੇ ਕੰਪਾਇਲ-ਟਾਈਮ 'ਤੇ ਹੀ ਗਣਨਾ ਕੀਤੇ ਜਾਣ ਤਾਂ ਕਿ ਚੱਲਦੇ ਸਮੇਂ ਘੱਟ ਕੰਮ ਰਹੇ।
ਲਾਭ ਦੋਹਾਂ ਗਤੀ ਅਤੇ ਸਧਾਰਣਤਾ ਹੈ: ਕੋਡ ਇੱਕ ਆਮ ਹਿਸਾਬ ਵਾਂਗ ਪੜ੍ਹਨ ਜੋਗਾ, ਪਰ ਨਤੀਜਾ ਇੱਕ “ਬੇਕਡ-ਇਨ” ਕਾਂਸਟੈਂਟ ਹੋ ਸਕਦਾ ਹੈ।
Ranges (ਅਤੇ views ਵਰਗੀਆਂ ਸੰਬੰਧਿਤ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ) ਤੁਹਾਨੂੰ ਇਹ ਪ੍ਰਗਟ ਕਰਨ ਦਿੰਦੇ ਹਨ ਕਿ “ਇਹ ਆਇਟਮ ਲਓ, ਫਿਲਟਰ ਕਰੋ, ਤਬਦੀਲ ਕਰੋ” ਇੱਕ ਪੜ੍ਹਨਯੋਗ ਢੰਗ ਨਾਲ। ਚੰਗੀ ਤਰ੍ਹਾਂ ਵਰਤਿਆਂ, ਇਹ ਸਾਫ਼ ਲੂਪਾਂ ਵਿੱਚ ਕੰਪਾਇਲ ਹੋ ਸਕਦੇ ਹਨ—ਬਿਨਾਂ ਜ਼ਬਰਦਸਤੀ ਰਨਟਾਈਮ ਲੇਅਰਾਂ ਦੇ।
ਇਹ ਫੀਚਰ ਜ਼ੀਰੋ-ਕੋਸਟ ਦਿਸ਼ਾ ਨੂੰ ਸਹਾਰਦੇ ਹਨ, ਪਰ ਪ੍ਰਦਰਸ਼ਨ ਫਿਰ ਵੀ ਇਸ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਇਹਨਾਂ ਨੂੰ ਕਿਵੇਂ ਵਰਤਦੇ ਹੋ ਅਤੇ ਕੰਪਾਈਲਰ ਅਖੀਰਕਾਰ ਫਾਈਨਲ ਪ੍ਰੋਗਰਾਮ ਨੂੰ ਕਿਵੇਂ Optimize ਕਰਦਾ ਹੈ। ਖ਼ਰਚੀਲਾ-ਮਾਮਲਾ ਕੋਡ ਅਕਸਰ ਸ਼ਾਨਦਾਰ ਰੀਤ ਨਾਲ Optimize ਹੋ ਜਾਂਦਾ ਹੈ—ਪਰ ਜੇ ਗਤੀਵਿਧੀ ਇਸ ਲਈ ਸਚਮੁਚ ਮੈਟਰ ਕਰਦੀ ਹੈ ਤਾਂ ਮਾਪਣਾ ਜਰੂਰੀ ਹੈ।
C++ “ਉੱਚ-ਪੱਧਰ” ਕੋਡ ਨੂੰ ਬਹੁਤ ਤੇਜ਼ ਮਸ਼ੀਨ ਨਿਰਦੇਸ਼ਾਂ ਵਿੱਚ ਕੰਪਾਇਲ ਕਰ ਸਕਦਾ ਹੈ—ਪਰ ਇਹ ਤੇਜ਼ ਨਤੀਜਿਆਂ ਦੀ ਗਾਰੰਟੀ ਨਹੀਂ ਦਿੰਦਾ। ਪਰਫਾਰਮੈਂਸ ਅਕਸਰ ਇਸ ਲਈ ਖੋਇਆ ਜਾਂਦਾ ਹੈ ਕਿ ਛੋਟੀਆਂ ਲਾਗਤਾਂ ਹੌਟ ਪਾਥ ਵਿੱਚ ਸੀspraken ਹੋ ਕੇ ਮਿਲਦੀਆਂ ਹਨ ਅਤੇ ਲੱਖਾਂ ਵਾਰੀ ਗੁਣਾ ਹੋ ਜਾਂਦੀਆਂ ਹਨ।
ਕੁਝ ਪੈਟਰਨ ਹਰ ਵਾਰੀ ਮੁੜ-ਮੁੜ ਨਜਰ ਆਉਂਦੇ ਹਨ:
ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ “C++ ਸਮੱਸਿਆ” ਨਹੀਂ ਹੈ। ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਡਿਜ਼ਾਈਨ ਅਤੇ ਵਰਤੋਂ ਦੀ ਸਮੱਸਿਆਵਾਂ ਹਨ—ਅਤੇ ਇਹ ਕਿਸੇ ਵੀ ਭਾਸ਼ਾ ਵਿੱਚ ਹੋ ਸਕਦੀਆਂ ਹਨ। ਫਰਕ ਇਹ ਹੈ ਕਿ C++ ਤੁਹਾਨੂੰ ਠੀਕ ਕਰਨ ਲਈ ਕਾਫ਼ੀ ਨਿਯੰਤਰਣ ਦਿੰਦੀ ਹੈ, ਅਤੇ ਇਨੁ ਹੋਣ ਲਈ ਕਾਫ਼ੀ ਰੱਸੀ ਵੀ ਦਿੰਦੀ ਹੈ।
ਖਰਚ ਮਾਡਲ ਨੂੰ ਸਧਾ ਰੱਖਣ ਵਾਲੀ ਆਦਤਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ:
ਇਕ ਪ੍ਰੋਫਾਈਲਰ ਵਰਤੋ ਜੋ ਮੂਢੇ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦੇ ਸਕੇ: ਕਿੱਥੇ ਸਮਾਂ ਖਰਚ ਹੁੰਦਾ ਹੈ? ਕਿੰਨੀ ਐਲੋਕੇਸ਼ਨਾਂ ਹੋ ਰਹੀਆਂ ਹਨ? ਕਿਹੜੀਆਂ ਫੰਕਸ਼ਨ ਸਭ ਤੋਂ ਵੱਧ ਕਾਲ ਹੋ ਰਹੀਆਂ ਹਨ? ਉਸਨੂੰ ਹਲਕੀ-ਭਾਰੀ ਬੈਂਚਮਾਰਕਾਂ ਨਾਲ ਜੋੜੋ ਜੋ ਉਹ ਹਿੱਸੇ ਜਿਨ੍ਹਾਂ ਦੀ ਤੁਸੀਂ ਪਰਵਾਹ ਕਰਦੇ ਹੋ, ਅੱਗੇ-ਪਿੱਛੇ ਜਾਂਚ ਸਕਣ।
ਜਦੋਂ ਤੁਸੀਂ ਇਹ ਨਿਰੱਤਰਤ ਤਰੀਕੇ ਨਾਲ ਕਰਦੇ ਹੋ, “ਜ਼ੀਰੋ-ਕੋਸਟ ਐਬਸਟ੍ਰੈਕਸ਼ਨ” ਵਰਤੋ: ਪੜ੍ਹਨਯੋਗ ਕੋਡ ਰੱਖੋ, ਫਿਰ ਉਹ ਖਾਸ ਲਾਗਤਾਂ ਹਟਾਓ ਜੋ ਮਾਪਣ 'ਤੇ ਉਭਰਦੀਆਂ ਹਨ।
ਜਿੱਥੇ ਮਿਲੀਸੈਕਿੰਡ (ਜਾਂ ਮਾਈਕ੍ਰੋਸੈਕਿੰਡ) ਸਿਰਫ਼ “ਚੰਗਾ” ਹੀ ਨਹੀਂ ਸਗੋਂ ਉਤਪਾਦੀ ਲੋੜ ਹੁੰਦਾ ਹੈ, ਉਥੇ C++ ਪਿੱਛੇ-ਛੱਡਦਾ ਨਹੀਂ। ਤੁਸੀਂ ਇਸਨੂੰ ਆਮ ਤੌਰ 'ਤੇ ਘੱਟ-ਲੇਟੈਂਸੀ ਟਰੇਡਿੰਗ ਸਿਸਟਮ, ਗੇਮ ਇੰਜਣ, ਬਰਾਊਜ਼ਰ ਕੰਪੋਨੈਂਟ, ਡੇਟਾਬੇਸ ਅਤੇ ਸਟੋਰੇਜ਼ ਇੰਜਣ, ਐਂਬੈੱਡਡ ਫਰਮਵੇਅਰ, ਅਤੇ ਹਾਈ-ਪਰਫਾਰਮੈਂਸ ਕੰਪਿਊਟਿੰਗ (HPC) ਵਰਕਲੋਡਾਂ ਦੇ ਪਿੱਛੇ ਲੱਭੋਗੇ। ਇਹ ਇਕੱਲੇ ਥਾਂ ਨਹੀਂ ਹਨ—ਪਰ ਇਹ ਵਜਹਾਂ ਹਨ ਕਿ ਭਾਸ਼ਾ ਅਜੇ ਵੀ ਵਿਕਸਤ ਹੋ ਰਹੀ ਹੈ।
ਬਹੁਤ ਸਾਰੇ ਪ੍ਰਦਰਸ਼ਨ-ਸੰਵੇਦਨਸ਼ੀਲ ਖੇਤਰਾਂ ਨੂੰ ਸ਼ੀਰਸ਼-ਥਾਂਮ ਤੋਂ ਵੱਧ ਪੇਸ਼ਗੋਈ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ: ਉਹ ਟੇਲ ਲੇਟੈਂਸੀਜ਼ ਹਨ ਜੋ ਫਰੇਮ ਡ੍ਰੌਪ, ਆਡੀਓ ਗਲਿਚ, ਮਾਰਕੀਟ ਮੌਕੇ ਗੁਆਉਣਾ, ਜਾਂ ਵਾਸਤਵਿਕ-ਸਮੇਂ ਡੈਡਲਾਈਨ ਛੱਡਣਾ ਬਣਾਉਂਦੇ ਹਨ। C++ ਟੀਮਾਂ ਨੂੰ ਇਹ ਫੈਸਲਾ ਕਰਨ ਦੀ ਆਜ਼ਾਦੀ ਦਿੰਦਾ ਹੈ ਕਿ ਮੈਮੋਰੀ ਕਦੋਂ ਐਲੋਕੇਟ ਕਰਨੀ ਹੈ, ਕਦੋਂ ਰਿਲੀਜ਼ ਕਰਨੀ ਹੈ, ਅਤੇ ਡੇਟਾ ਮੈਮੋਰੀ ਵਿੱਚ ਕਿਵੇਂ ਲੇਆਉਟ ਹੋਵੇ—ਇਹ ਚੋਣਾਂ ਕੈਸ਼ ਵਤੀਰੇ ਅਤੇ ਲੇਟੈਂਸੀ ਸਪਾਈਕ 'ਤੇ ਜ਼ੋਰਦਾਰ ਪ੍ਰਭਾਵ ਪਾਉਂਦੀਆਂ ਹਨ।
ਕਿਉਂਕਿ ਐਬਸਟ੍ਰੈਕਸ਼ਨ ਸਧਾਰਨ ਮਸ਼ੀਨ ਕੋਡ ਵਿੱਚ ਕੰਪਾਇਲ ਹੋ ਸਕਦੀਆਂ ਹਨ, C++ ਕੋਡ ਮੈਂਟੇਨਬਿਲਟੀ ਲਈ ਬਣਾਇਆ ਜਾ ਸਕਦਾ ਹੈ ਬਿਨਾਂ ਉਸ ਸੰਰਚਨਾ ਲਈ ਆਟੋਮੈਟਿਕ ਤੌਰ 'ਤੇ ਰਨਟਾਈਮ ਓਵਰਹੈਡ ਦੇਣ ਦੇ। ਜਦੋਂ ਤੁਸੀਂ ਲਾਗਤਾਂ ਭਰਤੀਆਂ ਹੋ (ਡਾਇਨਾਮਿਕ ਐਲੋਕੇਸ਼ਨ, ਵਰਚੁਅਲ ਡਿਸਪੈਚ, ਸਿੰਕ੍ਰੋਨਾਈਜੇਸ਼ਨ), ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਦਿਸਣਯੋਗ ਅਤੇ ਮਾਪਣਯੋਗ ਹੁੰਦੇ ਹਨ।
ਪ੍ਰੈਗਮੈਟਿਕ ਕਾਰਨ ਇਹ ਹੈ ਕਿ C++ ਅਜੇ ਵੀ ਆਮ ਹੈ ਕਿਉਂਕਿ ਕਈ ਸੰਸਥਾਵਾਂ ਕੋਲ ਦਹਾਕਿਆਂ ਦੇ C ਲਾਇਬ੍ਰੇਰੀਜ਼, OS ਇੰਟਰਫੇਸ, ਡਿਵਾਈਸ SDKs ਅਤੇ ਟੈਸਟ ਹੋਏ ਕੋਡ ਹਨ ਜੋ ਉਹ ਸੋਧ ਕੇ ਨਹੀਂ ਰੀਲਿਖ ਸਕਦੇ। C++ ਸੀ APIs ਨੂੰ ਸਿੱਧਾ ਕਾਲ ਕਰ ਸਕਦਾ ਹੈ, ਜਦਰੂਰਤ ਹੋਵੇ ਤਾਂ C-ਅਨੁਕੂਲ ਇੰਟਰਫੇਸ ਦਿਖਾ ਸਕਦਾ ਹੈ, ਅਤੇ ਇੱਕ ਕੋਡਬੇਸ ਦੇ ਹਿੱਸਿਆਂ ਨੂੰ ਹੌਲੀ-ਹੌਲੀ ਆਧੁਨਿਕਤਾ ਦੀ ਰਾਹ ਦਿਖਾ ਸਕਦਾ ਹੈ।
ਸਿਸਟਮ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਅਤੇ ਐਂਬੈੱਡਡ ਕੰਮ ਵਿੱਚ, “ਢੰਗ ਨਾਲ ਨਜ਼ਦੀਕ” ਅਜੇ ਵੀ ਗਰਭੀਨ ਹੈ: ਸਿੱਧਾ ਸਿੱਧਾ ਨਿਰਦੇਸ਼, SIMD, ਮੈਮੋਰੀ-ਮੈਪਡ I/O, ਅਤੇ ਪਲੇਟਫਾਰਮ-ਖ਼ਾਸ ਅਪਟੀਮਾਈਜ਼ੇਸ਼ਨ। ਪੱਕੇ ਕੰਪਾਈਲਰ ਅਤੇ ਪ੍ਰੋਫਾਈਲਿੰਗ ਟੂਲਾਂ ਦੇ ਨਾਲ, C++ ਅਕਸਰ ਉਹ ਚੋਣ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਟੀਮਾਂ ਨੂੰ ਪ੍ਰਦਰਸ਼ਨ ਨਿਕਾਲਨਾ ਹੋਵੇ ਅਤੇ ਬਾਈਨਰੀ, ਡੀਪੈਂਡੇਸੀਜ਼ ਅਤੇ ਰਨਟਾਈਮ ਵਿਹਾਰ 'ਤੇ ਨਿਯੰਤਰਣ ਚਾਹੀਦਾ ਹੋਵੇ।
C++ ਆਪਣੀ ਤੇਜ਼ੀ ਅਤੇ ਲਚਕ ਲਈ ਵਫਾਦਾਰੀ ਜਿੱਤਦਾ ਹੈ—ਪਰ ਇਸ ਤਾਕਤ ਦੀ ਕੀਮਤ ਹੈ। ਲੋਕਾਂ ਦੀਆਂ ਆਲੋਚਨਾਵਾਂ ਬੇਮੂਲ ਨਹੀਂ ਹਨ: ਭਾਸ਼ਾ ਵੱਡੀ ਹੈ, ਪੁਰਾਣੇ ਕੋਡਬੇਸਾਂ ਵਿੱਚ ਖ਼ਤਰਨਾਕ ਰਿਵਾਜ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਗਲਤੀਆਂ ਕੁਝ ਸਮੇਂ ਵਿੱਚ ਕਰੈਸ਼, ਡਾਟਾ ਖਰਾਬੀ, ਜਾਂ ਸੁਰੱਖਿਆ ਮੁੱਦੇ ਲਿਆ ਸਕਦੀਆਂ ਹਨ।
C++ ਦਹਾਕਿਆਂ ਵਿੱਚ ਵਿਕਸਤ ਹੋਈ, ਅਤੇ ਇਹ ਨਜ਼ਰ ਆਉਂਦਾ ਹੈ। ਤੁਸੀਂ ਇੱਕੋ ਕੰਮ ਕਰਨ ਦੇ ਕਈ ਤਰੀਕੇ ਵੇਖੋਗੇ, ਨਾਲ ਹੀ “ਤੇਖੀ ਧਾਰਾਂ” ਜੋ ਛੋਟੀਆਂ ਗਲਤੀਆਂ ਨੂੰ ਸਜ਼ਾ ਦਿੰਦੀਆਂ ਹਨ। ਦੋ ਆਮ ਸਮੱਸਿਆਵਾਂ:
ਪੁਰਾਣੇ ਪੈਟਰਨ ਰਿਸਕ ਵਧਾਉਂਦੇ ਹਨ: ਰਾ new/delete, ਮੈਨੂਅਲ ਮੈਮੋਰੀ ਮਾਲਕੀਅਤ, ਅਤੇ ਬੇਚੈੱਕ ਪੋਇੰਟਰ ਅੰਕਗਣਿਤ ਅਜੇ ਵੀ ਲੇਗੇਸੀ ਕੋਡ ਵਿੱਚ ਆਮ ਹਨ।
ਆਧੁਨਿਕ C++ ਅਭਿਆਸ ਜ਼ਿਆਦਾਤਰ ਇਸ ਬਾਰੇ ਹੈ ਕਿ ਲਾਭ ਕਿਵੇਂ ਪ੍ਰਾਪਤ ਕਰਨ ਹਨ ਬਿਨਾਂ ਫੁਟ-ਗਨਜ਼ ਨੂੰ ਉੱਠਾਏ। ਟੀਮਾਂ ਇਹ ਗੱਲਾਂ ਅਪਣਾਉਂਦੀਆਂ ਹਨ:
std::vector, std::string) ਨੂੰ ਕੱਚੇ new/delete ਦੀ ਥਾਂ।std::unique_ptr, std::shared_ptr) ਨਾਲ ਮਾਲਕੀਅਤ ਨੂੰ ਜ਼ਾਹਰ ਕਰਨਾ।clang-tidy ਵਰਗੇ ਸੰਦ ਲਾਗੂ ਕਰਨਾ।ਸਟੈਂਡਰਡ ਹਮੇਸ਼ਾ ਸੁਰੱਖਿਆ ਅਤੇ ਸਾਫ਼-ਲਿਖਤ ਕੋਡ ਵੱਲ ਵੱਧ ਰਿਹਾ ਹੈ: ਬਿਹਤਰ ਲਾਇਬ੍ਰੇਰੀਆਂ, ਵੱਧ ਅਭਿਵਿਕਾਰਕ ਕਿਸਮਾਂ, ਅਤੇ contracts, ਸੁਰੱਖਿਆ ਦੀਆਂ ਗਾਈਡਲਾਈਨ ਅਤੇ ਟੂਲ ਸਹਾਇਤਾ 'ਤੇ ਚੱਲ ਰਹੀ ਕੰਮ। ਟਰੇਡ-ਆਫ਼ ਰਹਿੰਦਾ ਹੈ: C++ ਤੁਹਾਨੂੰ ਲੈਵਰੇਜ ਦਿੰਦਾ ਹੈ, ਪਰ ਟੀਮਾਂ ਨੂੰ ਅਨੁਸ਼ਾਸਨ, ਰਿਵਿਊ, ਟੈਸਟਿੰਗ ਅਤੇ ਆਧੁਨਿਕ ਰਵਾਇਜਾਂ ਰਾਹੀਂ ਭਰੋਸੇਯੋਗਤਾ ਕਮਾਉਣੀ ਪੈਂਦੀ ਹੈ।
C++ ਇੱਕ ਵਧੀਆ ਚੋਣ ਹੈ ਜਦੋਂ ਤੁਹਾਨੂੰ ਪਰਫਾਰਮੈਂਸ ਅਤੇ ਸਰੋਤਾਂ 'ਤੇ ਸੁਖੜ-ਨਿਯੰਤਰਣ ਦੀ ਲੋੜ ਹੋਵੇ ਅਤੇ ਤੁਸੀਂ ਅਨੁਸ਼ਾਸਨ ਵਿੱਚ ਨਿਵੇਸ਼ ਕਰਨ ਦੀ ਯੋਜਨਾ ਰੱਖਦੇ ਹੋ। ਇਹ "C++ ਤੇਜ਼ ਹੈ" ਬਾਰੇ ਨਹੀਂ ਹੈ ਪਰ "C++ ਤੁਹਾਨੂੰ ਫੈਸਲਾ ਕਰਨ ਦਿੰਦਾ ਹੈ ਕਿ ਕਿਹੜਾ ਕੰਮ ਕਦੋਂ ਅਤੇ ਕਿਸ ਕੀਮਤ 'ਤੇ ਹੋਵੇ।"
C++ ਚੁਣੋ ਜਦੋਂ ਇਹਨਾਂ ਵਿੱਚੋਂ ਜ਼ਿਆਦਾਤਰ ਸੱਚ ਹੋਣ:
ਹੋਰ ਭਾਸ਼ਾਵਾਂ 'ਤੇ ਵਿਚਾਰ ਕਰੋ ਜਦੋਂ:
ਜੇ ਤੁਸੀਂ C++ ਚੁਣਦੇ ਹੋ, ਤਾਂ ਜਲਦੀ ਗਾਰਡਰੇਲ ਲਗਾਓ:
new/delete ਤੋਂ ਬਚੋ, std::unique_ptr/std::shared_ptr ਦਾ ਜ਼ਿੰਮੇਵਾਰ ਉਪਯੋਗ ਕਰੋ, ਅਤੇ ਐਨਚੈਕਡ ਪੋਇੰਟਰ ਅੰਕਗਣਿਤ ਨੂੰ ਐਪਲੀਕੇਸ਼ਨ ਕੋਡ ਵਿੱਚ ਮਨਾਂ ਕਰੋ।ਜੇ ਤੁਸੀਂ ਵਿਕਲਪ ਅੰਦਾਜ਼ਾ ਲਗਾ ਰਹੇ ਹੋ ਜਾਂ ਮਾਈਗ੍ਰੇਸ਼ਨ ਦੀ ਯੋਜਨਾ ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ ਇਹ ਵੀ ਮਦਦਗਾਰ ਹੁੰਦਾ ਹੈ ਕਿ ਅੰਦਰੂਨੀ ਫੈਸਲਾ ਨੋਟਜ਼ ਰੱਖੋ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਟੀਮ ਸਪੇਸ ਜਿਵੇਂ blog ਵਿੱਚ ਭਵਿੱਖ ਦੇ ਨੌਕਰੀਦਾਰਾਂ ਅਤੇ ਸਟੇਕਹੋਲਡਰਾਂ ਨਾਲ ਸਾਂਝਾ ਕਰੋ।
ਭਾਵੇਂ ਤੁਹਾਡਾ ਪਰਫਾਰਮੈਂਸ-ਸੰਵੇਦਨਸ਼ੀਲ ਕੋਰ C++ ਵਿੱਚ ਹੀ ਰਹੇ, ਬਹੁਤ ਸਾਰੀਆਂ ਟੀਮਾਂ ਨੂੰ ਖੁਪਰੇ-ਦੂਰ ਨਿਰਧਾਰਨ ਤੇਜ਼ੀ ਨਾਲ ਭੇਜਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ: ਡੈਸ਼ਬੋਰਡ, ਐਡਮਿਨ ਟੂਲ, ਅੰਦਰੂਨੀ APIs, ਜਾਂ ਪ੍ਰੋਟੋਟਾਈਪ ਜੋ ਲੋੜਾਂ ਨੂੰ ਵੈਰੀਫਾਈ ਕਰਨ ਲਈ ਨੀਵੇ ਪੱਧਰ ਦੀ ਇੰਪਲੀਮੇਨਟੇਸ਼ਨ ਤੋਂ ਪਹਿਲਾਂ ਬਣਾਏ ਜਾਂਦੇ ਹਨ।
ਇੱਥੇ Koder.ai ਇਕ ਪ੍ਰਯੋਗਿਕ ਪೂರਕ ਹੋ ਸਕਦਾ ਹੈ। ਇਹ ਇੱਕ vibe-coding ਪਲੇਟਫਾਰਮ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਚੈਟ ਇੰਟਰਫੇਸ ਤੋਂ ਵੈੱਬ, ਸਰਵਰ ਅਤੇ ਮੋਬਾਈਲ ਐਪ ਬਣਾਉਣ ਦਿੰਦਾ ਹੈ (React ਵੈੱਬ ਤੇ, Go + PostgreSQL ਬੈਕਐਂਡ, Flutter ਮੋਬਾਈਲ), ਯੋਜਨਾ ਮੋਡ, ਸੋਰਸ ਕੋਡ ਐਕਸਪੋਰਟ, ਡਿਪਲੋਇਮੈਂਟ/ਹੋਸਟਿੰਗ, ਕਸਟਮ ਡੋਮੇਨ, ਅਤੇ ਰੋਲਬੈਕ ਨਾਲ ਸਨੈਪਸ਼ਾਟ ਆਦਿ ਦੇ ਵਿਕਲਪਾਂ ਨਾਲ। ਦੂਜਾ ਸ਼ਬਦਾਂ ਵਿੱਚ: ਤੁਸੀਂ “ਹੌਟ ਪਾਥ ਦੇ ਆਲੇ-ਦੁਆਲੇ” ਤੇਜ਼ੀ ਨਾਲ ਇਟਰੇਟ ਕਰ ਸਕਦੇ ਹੋ, ਜਦੋਂ ਕਿ ਆਪਣੇ C++ ਕੰਪੋਨੈਂਟਾਂ ਨੂੰ ਉਹੀ ਜਗ੍ਹਾ ਛੱਡੀਏ ਜਿੱਥੇ ਜ਼ੀਰੋ-ਕੋਸਟ ਐਬਸਟ੍ਰੈਕਸ਼ਨ ਅਤੇ ਨਿਯੰਤਰਣ ਸਭ ਤੋਂ ਜ਼ਰੂਰੀ ਹਨ।
“ਜ਼ੀਰੋ-ਕੋਸਟ ਐਬਸਟ੍ਰੈਕਸ਼ਨ” ਇੱਕ ਡਿਜ਼ਾਈਨ ਮਕਸਦ ਹੈ: ਜੇ ਤੁਸੀਂ ਕਿਸੇ ਫੀਚਰ ਨੂੰ ਵਰਤਦੇ ਨਹੀਂ, ਤਾਂ ਇਸਦੇ ਰੰਨਟਾਈਮ ਓਵਰਹੈਡ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ; ਤੇ ਜੇ ਤੁਸੀਂ ਵਰਤਦੇ ਹੋ, ਤਾਂ ਬਣਾਇਆ ਗਿਆ ਮਸ਼ੀਨ ਕੋਡ ਲਗਭਗ ਉਸੇ ਬਰਾਬਰ ਹੋਣਾ ਚਾਹੀਦਾ ਜੋ ਤੁਸੀਂ ਹੱਥੋਂ-ਲਿਖਿਆ ਹੋਵੇ।
ਪ੍ਰੈਕਟਿਕਲ ਤੌਰ 'ਤੇ, ਇਹ ਮਤਲਬ ਹੈ ਕਿ ਤੁਸੀਂ ਸਪਸ਼ਟ ਕੋਡ (ਟਾਈਪ, ਫੰਕਸ਼ਨ, ਜਨਰਿਕ ਅਲਗੋਰਿਦਮ) ਲਿਖ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਆਟੋਮੈਟਿਕ ਤੌਰ 'ਤੇ ਵਾਧੂ ਐਲੋਕੇਸ਼ਨ, ਇੰਡੀਰੈਕਸ਼ਨ ਜਾਂ ਡਿਸਪੈਚ ਭੁਗਤਣ ਕਰਨ ਦੇ।
ਇਸ ਸੰਦਰਭ ਵਿੱਚ, “ਲਾਗਤ” ਦਾ ਅਰਥ ਹੈ ਵਾਧੂ ਰਨਟਾਈਮ ਕੰਮ, ਜਿਵੇਂ:
ਮਕਸਦ ਇਹ ਹੈ ਕਿ ਇਹ ਲਾਗਤਾਂ ਦਿਸਣਯੋਗ ਰਹਿਣ ਅਤੇ ਹਰ ਪ੍ਰੋਗਰਾਮ 'ਤੇ ਥੋਪੀਆਂ ਨਾ ਜਾਣ।
ਇਹ ਸਭ ਤੋਂ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ ਕੰਪਾਈਲਰ ਅਬਸਟ੍ਰੈਕਸ਼ਨ ਨੂੰ ਕੰਪਾਇਲ-ਟਾਈਮ 'ਤੇ ਦੇਖ ਸਕਦਾ ਹੈ—ਆਮ ਕੇਸਾਂ ਵਿੱਚ ਛੋਟੇ ਫੰਕਸ਼ਨ ਜੋ ਇਨਲਾਈਨ ਹੋ ਜਾਂਦੇ ਹਨ, ਕੰਪਾਇਲ-ਟਾਈਮ ਕਾਂਸਟੈਂਟ (constexpr), ਅਤੇ ਟੇmplੇਟਾਂ ਜਿਨ੍ਹਾਂ ਨੂੰ ਸੰਕੁਚਿਤ ਕਿਸਮਾਂ ਨਾਲ ਇੰਸਟੈਂਸ਼ੀਏਟ ਕੀਤਾ ਗਿਆ ਹੈ।
ਜਦੋਂ ਰਨਟਾਈਮ ਇੰਡਾਇਰੈਕਸ਼ਨ ਪ੍ਰਭਾਵਸ਼ালী ਹੁੰਦੀ ਹੈ (ਉਦਾਹਰਨ ਲਈ, ਹਾਟ ਲੂਪ ਵਿੱਚ ਵੱਡੀ ਵਰਚੁਅਲ ਡਿਸਪੈਚ) ਜਾਂ ਅਕਸਰ ਐਲੋਕੇਸ਼ਨ ਅਤੇ ਪੋਇੰਟਰ-ਚੇਜ਼ਿੰਗ ਡੇਟਾ ਸਟ੍ਰਕਚਰ ਆ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਇਹ ਘੱਟ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੁੰਦਾ ਹੈ।
C++ ਬਹੁਤ ਸਾਰੀ ਲਾਗਤਾਂ ਨੂੰ ਬਣਾਉਣ ਸਮੇਂ (ਬਿਲਡ ਟਾਈਮ) ਉਤੇ ਸ਼ਿਫਟ ਕਰਦਾ ਹੈ ਤਾਂ ਕਿ ਰਨਟਾਈਮ ਸਾਫ਼ ਰਹੇ। ਆਮ ਉਦਾਹਰਣਾਂ:
ਲਾਭ ਲਈ, ਪਟੀਮਾਈਜ਼ੇਸ਼ਨ ਨਾਲ ਕੰਪਾਈਲ ਕਰੋ (ਉਦਾਹਰਨ: -O2/-O3) ਅਤੇ ਕੋਡ ਇਸ ਤਰ੍ਹਾਂ ਰਖੋ ਕਿ ਕੰਪਾਈਲਰ ਉਹਨੂੰ ਸਮਝ ਸਕੇ।
RAII (Resource Acquisition Is Initialization) ਦਾ ਸਿਧਾਂਤ ਸਾਫ਼ ਹੈ: ਸੰਸਾਧਨ ਦੀ ਉਮਰ ਸਕੋਪ ਨਾਲ ਜੁੜੀ ਹੁੰਦੀ ਹੈ। ਜਦੋਂ ਇੱਕ ਆਬਜੈਕਟ ਬਣਦਾ ਹੈ, ਉਹ ਸੰਸਾਧਨ ਪ੍ਰਾਪਤ ਕਰ ਲੈਂਦਾ ਹੈ; ਜਦੋਂ ਆਬਜੈਕਟ ਸਕੋਪ ਤੋਂ ਬਾਹਰ ਹੋ ਜਾਂਦਾ ਹੈ, ਉਹਦਾ ਡੈਸਟਰਕਟਰ ਉਸਨੂੰ ਰਿਲੀਜ਼ ਕਰ ਦਿੰਦਾ ਹੈ—ਆਟੋਮੈਟਿਕ।
ਪ੍ਰਯੋਗਿਕ ਅਭਿਆਸ:
std::vector, std::string) ਨੂੰ ਤਰਜੀਹ ਦਿਓ।RAII ਇੱਕ ਲਾਭ ਹੈ ਖ਼ਾਸ ਕਰਕੇ Exceptions ਨਾਲ ਕਿਉਂਕੀ ਸਟੈਕ ਅਨਵਾਇਂਡਿੰਗ ਦੌਰਾਨ ਡੈਸਟਰਕਟਰ ਚਲਦੇ ਹਨ, ਇਸ ਲਈ ਸੰਸਾਧਨ ਫਿਰ ਵੀ ਰਿਲੀਜ਼ ਹੋ ਜਾਂਦੇ ਹਨ।
ਪਰਫਾਰਮੈਂਸ-ਤੌਰ 'ਤੇ, Exceptions ਆਮ ਤੌਰ 'ਤੇ ਮਹਿੰਗੇ ਹੁੰਦੇ ਹਨ ਜਦੋਂ ਉਹ ਫੈਕ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਨਾ ਕਿ ਜਦੋਂ ਉਹ ਸੰਭਵ ਹਨ। ਜੇ ਤੁਹਾਡਾ ਹੌਟ ਪਾਥ ਬਾਰ-ਬਾਰ throws ਕਰਦਾ ਹੈ, ਤਾਂ ਤਰੱਕੀ ਵੱਲ ਰੀਡ੍ਰੈਸ ਕਰੋ—ਇਰਰ ਕੋਡ/expected-ਜਿਹੇ ਨਤੀਜੇ ਵਰਗੇ ਹੱਲ। ਜੇ throws ਬਹੁਤ ਹੀ ਵਿਸ਼ੇਸ਼ ਹਨ, ਤਾਂ RAII + Exceptions ਅਕਸਰ ਤੇਜ਼ ਰਾਹ ਰੱਖਦੇ ਹਨ।
ਟੇmplੇਟ ਤੁਹਾਨੂੰ ਜਨਰਿਕ ਕੋਡ ਲਿਖਣ ਦਿੰਦੇ ਹਨ ਜੋ ਕੰਪਾਇਲ-ਟਾਈਮ 'ਤੇ ਕਿਸਮ-ਨਿਰਧਾਰਤ ਹੋ ਜਾਂਦਾ ਹੈ, ਅਕਸਰ ਇਨਲਾਈਨਿੰਗ ਯੋਗ ਬਣਾਉਂਦਾ ਅਤੇ ਰਨਟਾਈਮ ਕਿਸਮ-ਟੈਸਟਾਂ ਤੋਂ ਬਚਾਉਂਦਾ।
ਤਿਆਰੀ ਕਰਨ ਵਾਲੇ ਟਰੇਡ-ਆਫ਼:
ਟੇmplੇਟ ਕੰਪਲੈਕਸਿਟੀ ਨੂੰ ਉਹਨਾਂ ਥਾਵਾਂ 'ਤੇ ਰੱਖੋ ਜਿੱਥੇ ਇਸਦਾ ਲਾਭ ਹੈ (ਮੂਲ ਅਲਗੋਰਿਦਮ, ਦੁਹਰਾਵਾਂ ਉਪਕਰਨ)।
ਸਹਿਮਤ ਰੂਪ ਵਿੱਚ std::vector-ਸਿਰਫ਼ ਰੱਖਣ ਲਈ ਅਤੇ ਤੇਜ਼ ਇਟਰੇਸ਼ਨ ਲਈ ਡਿਫ਼ਾਲਟ ਪਸੰਦ ਕਰੋ; std::list ਉਸ ਵੇਲੇ ਵਰਤੋ ਜਦੋਂ ਤੁਹਾਨੂੰ ਵਾਸਤਵ ਵਿੱਚ ਸਥਿਰ ਇਟਰੇਟਰ ਅਤੇ ਬਿਨਾਂ ਮੂਵ ਕੀਤੇ ਬਹੁਤ ਸਾਰੀਆਂ ਸਪਲਾਈਸ/ਇਨਸਰਸ਼ਨ ਚਾਹੀਦੀ ਹੋਵੇ।
ਨਕਸ਼ਾ-ਜੈਸੀ ਕਿਸਮਾਂ ਲਈ:
std::unordered_map ਤੇਜ਼ ਔਸਤ-ਮਾਮਲੇ ਵਾਲੀ ਲੁੱਕਅਪ ਲਈ।std::map ਤੀਬਰੇ ਕਿਨ੍ਹੇ ਖੇਤਰ ਕਵੈਰੀਆਂ (ਜਿਵੇਂ “A ਅਤੇ B ਦੇ ਵਿਚਕਾਰ ਸਾਰੇ ਕੀਜ਼”) ਅਤੇ ਅਨੁਕ੍ਰਮਿਤ ਇਟਰੇਸ਼ਨ ਲਈ ਵਧੀਆ ਹੈ, ਪਰ ਲੁੱਕਅਪ ਅਮੂਮਨ ਹੇਠਾਂ ਹੁੰਦਾ ਹੈ।ਇਹ ਉਨ੍ਹਾਂ ਲਾਗਤਾਂ 'ਤੇ ਧਿਆਨ ਦਿਓ ਜੋ ਗੁਣਾ ਹੋ ਕੇ ਵਧਦੀਆਂ ਹਨ:
reserve() ਕਰੋ)ਫਿਰ ਪ੍ਰੋਫਾਈਲਿੰਗ ਨਾਲ ਇਸਦੀ ਪੁਸ਼ਟੀ ਕਰੋ—ਅਗਾਂਹਦੇ ਕਦਮ ਹਮੇਸ਼ਾ ਮਾਪਣ ਤੋਂ ਪਿੱਛੇ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ।
शੁਰੂ ਤੋਂ ਹੀ ਗਾਰਡਰੇਲ ਲਗਾਉ ਤਾਂ ਜੋ ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਸੁਰੱਖਿਆ ਹੀਰੋਇਕ ਵਿਚਾਰਾਂ 'ਤੇ ਨਿਰਭਰ ਨਾ ਰਹਿ ਜਾਣ:
new/delete ਤੋਂ ਬਚੋਜਿਆਦਾ ਡੀਪ ਗਾਈਡ ਲਈ, ਵੇਖੋ: blog/choosing-cpp-containers
std::unique_ptr/std::shared_ptr ਨਾਲ ਜ਼ਾਹਰ ਕਰੋclang-tidy ਵਰਗੇ ਨਿਯਮ ਲਾਗੂ ਕਰੋਇਸ ਤਰ੍ਹਾਂ C++ ਦੀ ਨੀyanਤਿ ਬਰਕਰਾਰ ਰੱਖਦੇ ਹੋਏ ਅਣਪਛਾਤੇ ਵਿਹਾਰਾਂ ਨੂੰ ਘਟਾਇਆ ਜਾ ਸਕਦਾ ਹੈ।