18 ਮਾਰਚ 2025·8 ਮਿੰਟ
ਡੈਨਿਸ ਰਿਚੀ ਅਤੇ C: ਛੋਟੀ ਭਾਸ਼ਾ, ਵੱਡਾ ਸਿਸਟਮ ਪ੍ਰਭਾਵ
Dennis Ritchie ਦੀ C ਨੇ Unix ਨੂੰ ਕਿਵੇਂ ਮੋਰਫ ਕੀਤਾ ਅਤੇ ਅਜੇ ਵੀ ਕਰਨਲ, ਐਂਬੈੱਡਡ ਡਿਵਾਈਸਾਂ ਅਤੇ ਤੇਜ਼ ਸਾਫਟਵੇਅਰ ਨੂੰ ਚਲਾ ਰਹੀ ਹੈ—ਪੋਰਟੇਬਿਲਟੀ, ਪਰਫਾਰਮੈਂਸ ਅਤੇ ਸੁਰੱਖਿਆ ਬਾਰੇ ਜੋ ਜਾਣਨਾ ਲਾਜ਼ਮੀ ਹੈ।
Dennis Ritchie ਦੀ C ਨੇ Unix ਨੂੰ ਕਿਵੇਂ ਮੋਰਫ ਕੀਤਾ ਅਤੇ ਅਜੇ ਵੀ ਕਰਨਲ, ਐਂਬੈੱਡਡ ਡਿਵਾਈਸਾਂ ਅਤੇ ਤੇਜ਼ ਸਾਫਟਵੇਅਰ ਨੂੰ ਚਲਾ ਰਹੀ ਹੈ—ਪੋਰਟੇਬਿਲਟੀ, ਪਰਫਾਰਮੈਂਸ ਅਤੇ ਸੁਰੱਖਿਆ ਬਾਰੇ ਜੋ ਜਾਣਨਾ ਲਾਜ਼ਮੀ ਹੈ।
C ਉਨ੍ਹਾਂ ਤਕਨੀਕਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ ਜਿਸਨੂੰ ਜ਼ਿਆਦਾਤਰ ਲੋਕ ਸਿੱਧਾ ਨਹੀਂ ਛੁਹਦੇ, ਪਰ ਲਗਭਗ ਹਰ ਕੋਈ ਉਸ 'ਤੇ ਨਿਰਭਰ ਹੈ। ਜੇ ਤੁਸੀਂ ਫੋਨ, ਲੈਪਟੌਪ, ਰਾਊਟਰ, ਕਾਰ, ਸਮਾਰਟਵਾਚ ਜਾਂ ਚਿਹਰੇ ਵਾਲੀ ਕੌਫੀ ਮਸ਼ੀਨ ਵਰਗਾ ਕੋਈ ਡਿਵਾਈਸ ਵਰਤਦੇ ਹੋ, ਤਾਂ ਸੰਭਵ ਹੈ ਕਿ ਸਟੈਕ ਦੇ ਕਿਸੇ ਹਿੱਸੇ ਵਿੱਚ C ਸ਼ਾਮਲ ਹੈ—ਜੋ ਡਿਵਾਈਸ ਨੂੰ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ, ਹਾਰਡਵੇਅਰ ਨਾਲ ਗੱਲ ਕਰਵਾਉਂਦਾ ਹੈ ਜਾਂ ਪਰਫਾਰਮੈਂਸ ਇੰਨਾ ਤੇਜ਼ ਰੱਖਦਾ ਹੈ ਕਿ ਸਭ ਕੁਝ ‘ਤੁਰੰਤ’ ਮਹਿਸੂਸ ਹੋਵੇ।
ਬਣਾਉਣ ਵਾਲਿਆਂ ਲਈ, C ਅਜੇ ਵੀ ਇੱਕ ਵਿਆਵਹਾਰਿਕ ਸਾਧਨ ਹੈ ਕਿਉਂਕਿ ਇਹ ਨਿਯੰਤਰਣ ਅਤੇ ਪੋਰਟੇਬਲਟੀ ਦਾ ਇੱਕ ਅਜਿਹਾ ਸਾਂਬਲ ਦਿੰਦਾ ਹੈ ਜੋ ਰੁੱਝੋ-ਰੁੱਝਾ ਮਿਲਦਾ ਹੈ। ਇਹ ਮਸ਼ੀਨ ਦੇ ਨੇੜਲੇ ਤੌਰ ਤੇ ਚੱਲ ਸਕਦਾ ਹੈ (ਤਾਂ ਜੋ ਤੁਸੀਂ ਸਿੱਧਾ ਮੇਮੋਰੀ ਅਤੇ ਹਾਰਡਵੇਅਰ ਨੂੰ ਮੈਨੇਜ ਕਰ ਸਕੋ), ਪਰ ਇਹ ਵੱਖ-ਵੱਖ CPU ਅਤੇ ਓਐੱਸ 'ਤੇ ਥੋੜ੍ਹੇ ਹੀ ਰੀਰਾਈਟਿੰਗ ਨਾਲ ਵੀ ਚੱਲ ਸਕਦਾ ਹੈ। ਇਹ ਮਿਲਾਪ ਬਦਲਣਾ ਮੁਸ਼ਕਲ ਹੈ।
C ਦਾ ਸਭ ਤੋਂ ਵੱਡਾ ਪ੍ਰਭਾਵ ਤਿੰਨ ਖੇਤਰਾਂ ਵਿੱਚ ਦਿੱਖਾਈ ਦਿੰਦਾ ਹੈ:
ਭਾਵੇਂ ਕੋਈ ਐਪ ਉੱਚ-ਸਤਰ ਦੀ ਭਾਸ਼ਾ ਵਿੱਚ ਲਿਖੀ ਹੋਵੇ, ਉਸ ਦੀਆਂ ਬੁਨਿਆਦੀ ਚੀਜ਼ਾਂ ਜਾਂ ਪਰਫਾਰਮੈਂਸ-ਸੰਵੇਦਨਸ਼ੀਲ ਮਾਡਿਊਲ ਅਕਸਰ C ਵਿੱਚ ਦੇਖਣ ਨੂੰ ਮਿਲਦੇ ਹਨ।
ਇਹ ਟੁਕੜਾ Dennis Ritchie, C ਦੇ ਮੂਲ ਉਦਦੇਸ਼ ਅਤੇ ਕਾਰਨਾਂ ਨੂੰ ਜੋ ਇਹ ਅਜੇ ਭੀ ਆਧੁਨਿਕ ਉਤਪਾਦਾਂ ਵਿੱਚ ਮਿਲਦੀ ਹੈ, ਜੋੜਦਾ ਹੈ। ਅਸੀਂ ਇਹ ਕਵਰ ਕਰਾਂਗੇ:
ਇਹ ਖਾਸ ਤੌਰ 'ਤੇ C ਬਾਰੇ ਹੈ, ਨਾ ਕਿ “ਸਾਰੇ ਨੀਵੇਂ-ਸਤਰ ਦੀਆਂ ਭਾਸ਼ਾਵਾਂ” ਬਾਰੇ। C++ ਅਤੇ Rust ਤੁਲਨਾ ਲਈ ਆ ਸਕਦੇ ਹਨ, ਪਰ ਧਿਆਨ ਇਸ ਗੱਲ 'ਤੇ ਹੈ ਕਿ C ਕੀ ਹੈ, ਇਸਨੂੰ ਕਿਉਂ ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਗਿਆ ਸੀ, ਅਤੇ ਟੀਮਾਂ ਅਸਲੀ ਸਿਸਟਮਾਂ ਲਈ ਹੁਣ ਵੀ ਇਸਨੂੰ ਕਿਉਂ ਚੁਣਦੀਆਂ ਹਨ।
Dennis Ritchie (1941–2011) ਇੱਕ ਅਮਰੀਕੀ ਕੰਪਿਊਟਰ ਵਿਗਿਆਨੀ ਸੀ ਜੋ AT&T ਦੇ Bell Labs ਵਿੱਚ ਆਪਣੇ ਕੰਮ ਲਈ ਪ੍ਰਸਿੱਧ ਹਨ, ਇੱਕ ਅਜਿਹਾ ਖੋਜ ਸੰਸਥਾਨ ਜਿਸਦਾ ਪਹਿਲੀ ਕੰਪਿਊਟਿੰਗ ਅਤੇ ਟੈਲੀਕਮਿਊਨਿਕੇਸ਼ਨ ਵਿੱਚ ਕੇਂਦਰੀ ਰੋਲ ਸੀ।
Bell Labs ਵਿੱਚ 1960s ਦੇ ਅੰਤ ਅਤੇ 1970s ਦੌਰਾਨ, Ritchie ਨੇ Ken Thompson ਅਤੇ ਹੋਰਾਂ ਨਾਲ ਓਐੱਸ ਰਿਸਰਚ 'ਤੇ ਕੰਮ ਕੀਤਾ ਜਿਸ ਨਾਲ Unix ਦਾ ਵਿਕਾਸ ਹੋਇਆ। Thompson ਨੇ Unix ਦਾ ਇਕ ਪਹਿਲਾ ਸੰਸਕਰਣ ਬਣਾਇਆ; ਜਿਵੇਂ-ਜਿਵੇਂ ਸਿਸਟਮ ਵਿਕਸਿਤ ਹੋਇਆ, Ritchie ਇਕ ਮੁੱਖ ਸਹਿ-ਸਿਰਜਣਹਾਰ ਬਣ ਗਏ, ਜਿਸ ਨਾਲ ਇਹ ਆਪਣਾ ਰੂਪ ਪਾਇਆ ਜੋ ਅਕਾਦਮੀ ਅਤੇ ਉਦਯੋਗ ਵਿੱਚ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਵਰਤਿਆ ਅਤੇ ਸਾਂਝਾ ਕੀਤਾ ਜਾ ਸਕਿਆ।
Ritchie ਨੇ C ਭਾਸ਼ਾ ਵੀ ਬਣਾਈ, ਜੋ Bell Labs ਵਿੱਚ ਵਿਆਪਤ ਪਹਿਲਾਂ ਦੀਆਂ ਭਾਸ਼ਾਵਾਂ ਦੇ ਵਿਚਾਰਾਂ 'ਤੇ ਅਧਾਰਿਤ ਸੀ। C ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਗਿਆ ਕਿ ਇਹ ਸਿਸਟਮ ਸਾਫਟਵੇਅਰ ਲਿਖਣਾ ਪ੍ਰਾਇਕਟਿਕਲ ਬਣਾਏ: ਇਹ ਪ੍ਰੋਗਰਾਮਰਾਂ ਨੂੰ ਮੈਮੋਰੀ ਅਤੇ ਡੇਟਾ ਪ੍ਰਤੀਨਿਧਿਤਾ 'ਤੇ ਸਿੱਧਾ ਨਿਯੰਤਰਣ ਦਿੰਦੀ ਹੈ, ਜਦਕਿ ਅਸਮੀਬਲੀ ਦੀ ਭੱਤੋਂ ਜ਼ਿਆਦਾ ਪਠਨਯੋਗ ਅਤੇ ਪੋਰਟੇਬਲ ਰਹਿੰਦੀ ਹੈ।
ਇਹ ਮਿਲਾਪ ਮਹੱਤਵਪੂਰਨ ਸੀ ਕਿਉਂਕਿ Unix ਆਖਿਰਕਾਰ C ਵਿੱਚ ਦੁਬਾਰਾ ਲਿਖਿਆ ਗਿਆ। ਇਹ ਸਿਰਫ਼ ਸਟਾਈਲ ਲਈ ਨਹੀਂ ਸੀ—ਇਸ ਨਾਲ Unix ਨੂੰ ਨਵੇਂ ਹਾਰਡਵੇਅਰ ਤੇ ਲਿਜਾਣਾ ਅਤੇ ਸਮੇਂ ਦੇ ਨਾਲ ਵਧਾਉਣਾ ਬਹੁਤ ਆਸਾਨ ਹੋ ਗਿਆ। ਨਤੀਜਾ ਇੱਕ ਤਾਕਤਵਰ ਫੀਡਬੈਕ ਲੂਪ ਰਿਹਾ: Unix ਨੇ C ਲਈ ਇਕ ਡੈਮੇਂਡਿੰਗ ਵਰਤੋਂ ਦਾ ਕੇਸ ਦਿੱਤਾ, ਅਤੇ C ਨੇ Unix ਨੂੰ ਇੱਕ ਵੱਖਰੇ ਮਸ਼ੀਨ ਤੋਂ ਬਾਹਰ ਅਪਣਾਉਣ ਯੋਗ ਬਣਾ ਦਿੱਤਾ।
ਇਕਠੇ, Unix ਅਤੇ C ਨੇ “ਸਿਸਟਮ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ” ਨੂੰ ਉਸ ਰੂਪ ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤਾ: ਇੱਕ ਅਜਿਹੀ ਭਾਸ਼ਾ ਵਿੱਚ ਓਐੱਸ, ਕੋਰ ਲਾਇਬ੍ਰੇਰੀਆਂ ਅਤੇ ਟੂਲ ਬਣਾਉਣਾ ਜੋ ਮਸ਼ੀਨ ਦੇ ਨੇੜੇ ਹੋਵੇ ਪਰ ਕਿਸੇ ਇੱਕ ਪ੍ਰੋਸੈਸਰ ਨਾਲ ਬੰਧਿਆ ਨਾ ਹੋਵੇ। ਇਹਨਾਂ ਦਾ ਪ੍ਰਭਾਵ ਬਾਦ ਵਾਲੇ ਓਐੱਸ, ਡਿਵੈਲਪਰ ਟੂਲਿੰਗ ਅਤੇ ਉਹ ਰਿਵਾਜਾਂ ਵਿੱਚ ਵਿਆਪਕ ਹੈ ਜਿਹੜੇ ਬਹੁਤ ਸਾਰੇ ਇੰਜੀਨੀਅਰ ਅਜੇ ਵੀ ਸਿੱਖਦੇ ਹਨ—ਕਿਉਂਕਿ ਇਹ ਦਰਅਸਲ ਕਾਰਗਰ ਰਿਹਾ।
ਸ਼ੁਰੂਆਤੀ ਓਐੱਸ ਜ਼ਿਆਦਾਤਰ ਅਸਮੀਬਲੀ ਵਿੱਚ ਲਿਖੇ ਜਾਂਦੇ ਸਨ। ਇਸ ਨਾਲ ਇੰਜੀਨੀਅਰਾਂ ਨੂੰ ਹਾਰਡਵੇਅਰ ਉੱਤੇ ਪੂਰਾ ਨਿਯੰਤਰਣ ਮਿਲਦਾ ਸੀ, ਪਰ ਹਰ ਬਦਲਾਅ ধੀਰਾ, ਗਲਤੀ-ਪੂਰਨ ਅਤੇ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਪ੍ਰੋਸੈਸਰ ਨਾਲ ਸਖਤੀ ਨਾਲ ਜੁੜਿਆ ਹੁੰਦਾ ਸੀ। ਨਿੱਕੇ ਫੀਚਰ ਵੀ ਘਣ-ਘਰਹੁ ਕੋਡ ਲਿਖਣ ਦੀ ਲੋੜ ਪੈਦਾ ਕਰ ਦਿੰਦੇ ਸਨ, ਅਤੇ ਸਿਸਟਮ ਨੂੰ ਕਿਸੇ ਹੋਰ ਮਸ਼ੀਨ 'ਤੇ ਲਿਜਾਣ ਲਈ ਵੱਡੇ ਹਿੱਸਿਆਂ ਨੂੰ ਮੁੜ ਲਿਖਣਾ ਪੈਂਦਾ।
Dennis Ritchie ਨੇ C ਇੱਕ ਖਾਲੀ ਜਗ੍ਹਾ 'ਚ ਨਹੀਂ ਬਣਾਈ। ਇਹ Bell Labs 'ਤੇ ਵਰਤੀ ਜਾਂਦੀਆਂ ਪਹਿਲੀਆਂ, ਸਧਾਰਣ ਭਾਸ਼ਾਵਾਂ ਤੋਂ ਉਭਰੀ ਸੀ।
C ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਬਣਾਇਆ ਗਿਆ ਕਿ ਇਹ ਜਿਸ ਤਰ੍ਹਾਂ ਕੰਪਿਊਟਰ ਅਸਲ ਵਿੱਚ ਕੰਮ ਕਰਦੇ ਹਨ, ਉਸ ਨਾਲ ਸਾਫ਼-ਸੁਥਰਾ ਮੈਪ ਕਰੇ: ਮੇਮੋਰੀ ਵਿੱਚ ਬਾਈਟ, ਰਜਿਸਟਰਾਂ 'ਤੇ ਅੰਕਗਣਿਤ, ਅਤੇ ਕੋਡ ਵਿੱਚ ਜੰਪ। ਇਸੀ ਲਈ ਸਧਾਰਨ ਡੇਟਾ ਟਾਈਪ, ਸਪਸ਼ਟ ਮੇਮੋਰੀ ਐਕਸੈਸ ਅਤੇ ऐसे ਓਪਰੇਟਰ ਜੋ CPU ਹਦਾਇਤਾਂ ਨਾਲ ਮਿਲਦੇ ਹਨ, ਭਾਸ਼ਾ ਦੇ ਕੇਂਦਰੀ ਹਿੱਸੇ ਹਨ। ਤੁਸੀਂ ਐਸਾ ਕੋਡ ਲਿਖ ਸਕਦੇ ਹੋ ਜੋ ਵੱਡੇ ਕੋਡਬੇਸ ਨੂੰ ਸਾਂਭ ਸਕੇ, ਪਰ ਫਿਰ ਵੀ ਮੈਮੋਰੀ ਲੇਆਊਟ ਅਤੇ ਪਰਫਾਰਮੈਂਸ 'ਤੇ ਸੁਧਾਰਤ ਨਿਯੰਤਰਣ ਦੇ ਸਕੇ।
“ਪੋਰਟੇਬਲ” ਦਾ ਅਰਥ ਹੈ ਕਿ ਤੁਸੀਂ ਉਹੀ C ਸੋਰਸ ਕੋਡ ਕਿਸੇ ਹੋਰ ਕੰਪਿਊਟਰ 'ਤੇ ਲੈ ਜਾਂਦੇ ਹੋ ਅਤੇ ਥੋੜ੍ਹੀਆਂ ਬਦਲਾਵਾਂ ਨਾਲ ਉਸ ਨੂੰ ਉੱਥੇ ਕੰਪਾਈਲ ਕਰਕੇ ਇੱਕੋ ਜਿਹਾ ਵਿਹਾਰ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹੋ। ਓਐੱਸ ਨੂੰ ਹਰ ਨਵੇਂ ਪ੍ਰੋਸੈਸਰ ਲਈ ਮੁੜ-ਲਿਖਣ ਦੀ ਥਾਂ, ਟੀਮਾਂ ਜ਼ਿਆਦਾਤਰ ਕੋਡ ਨੂੰ ਰੱਖ ਸਕਦੀਆਂ ਹਨ ਅਤੇ ਕੇਵਲ ਛੋਟੇ ਹਾਰਡਵੇਅਰ-ਨਿਰਭਰ ਹਿੱਸਿਆਂ ਨੂੰ ਬਦਲਦੀਆਂ ਹਨ। ਇਸ ਮਿਲਾਪ ਨੇ Unix ਦੇ ਫੈਲਾਅ ਵਿੱਚ ਮਦਦ ਕੀਤੀ।
C ਦੀ ਤੇਜ਼ੀ ਜਾਦੂ ਨਹੀਂ—ਇਹ ਮੁੱਖ ਤੌਰ 'ਤੇ ਇਸ ਗੱਲ ਦਾ ਨਤੀਜਾ ਹੈ ਕਿ ਇਹ ਮਸ਼ੀਨ ਦੇ ਜਿਹੜੇ ਕੰਮ ਹੁੰਦੇ ਹਨ, ਉਨ੍ਹਾਂ ਨਾਲ ਕਿੰਨਾ ਨਜ਼ਦੀਕੀ ਰਿਸ਼ਤਾ ਰੱਖਦੀ ਹੈ ਅਤੇ ਤੁਹਾਡੇ ਕੋਡ ਅਤੇ CPU ਦਰਮਿਆਨ ਕਿੰਨਾ ਘੱਟ "ਵਾਧੂ ਕੰਮ" ਹੁੰਦਾ ਹੈ।
C ਆਮ ਤੌਰ 'ਤੇ ਕੰਪਾਇਲ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਸੀਂ ਮਨੁੱਖ ਪਠਨਯੋਗ ਸੋਰਸ ਕੋਡ ਲਿਖਦੇ ਹੋ, ਫਿਰ ਇੱਕ ਕੰਪਾਇਲਰ ਉਸ ਨੂੰ ਮਸ਼ੀਨ ਕੋਡ ਵਿੱਚ ਤਬਦੀਲ ਕਰਦਾ ਹੈ: ਕੱਚੇ ਹੁਕਮ ਜੋ ਤੁਹਾਡਾ ਪਰੋਸੈਸਰ ਚਲਾਉਂਦਾ ਹੈ।
ਅਮਲੀ ਰੂਪ ਵਿੱਚ, ਕੰਪਾਇਲਰ ਇੱਕ ਐਗਜ਼ੀਕਿਊਟੇਬਲ (ਜਾਂ ਆਬਜੈਕਟ ਫਾਇਲਾਂ) ਤਿਆਰ ਕਰਦਾ ਹੈ। ਮੁੱਢਲਾ ਨੁਕਤਾ ਇਹ ਹੈ ਕਿ ਅਖੀਰੀ ਨਤੀਜਾ ਰਨਟਾਈਮ 'ਤੇ ਲਾਇਨ-ਦਰ-ਲਾਇਨ ਵਿਵਰਤ ਨਹੀਂ ਹੁੰਦਾ—ਇਹ ਪਹਿਲਾਂ ਹੀ CPU ਦੁਆਰਾ ਸਮਝਣਯੋਗ ਰੂਪ ਵਿੱਚ ਹੁੰਦਾ ਹੈ, ਜੋ ਓਵਰਹੈਡ ਘਟਾਉਂਦਾ ਹੈ।
C ਤੁਹਾਨੂੰ ਸਧਾਰਣ ਬਿਲਡਿੰਗ ਬਲਾਕ ਦਿੰਦੀ ਹੈ: ਫੰਕਸ਼ਨ, ਲੂਪ, ਇੰਟੀਜ਼ਰ, ਐਰੇ ਅਤੇ ਪੁਆਇੰਟਰ। ਭਾਸ਼ਾ ਛੋਟੀ ਅਤੇ ਸਪਸ਼ਟ ਹੋਣ ਕਰਕੇ, ਕੰਪਾਇਲਰ ਅਕਸਰ ਸਿੱਧਾ ਮਸ਼ੀਨ ਕੋਡ ਜਨਰੇਟ ਕਰ ਸਕਦਾ ਹੈ।
ਹੋ ਸਕਦਾ ਹੈ ਕੋਈ ਮੈਨਡੇਟਰੀ ਰਨਟਾਈਮ ਨਾ ਹੋਵੇ ਜੋ ਹਰ ਓਬਜੈਕਟ ਨੂੰ ਟਰੈਕ ਕਰੇ, ਛੁਪੇ ਹੋਏ ਚੈੱਕ ਲਗਾਏ ਜਾਂ ਕਠੋਰ ਮੈਟਾਡੇਟਾ ਸੰਭਾਲੇ। ਜਦ ਤੁਸੀਂ ਇੱਕ ਲੂਪ ਲਿਖਦੇ ਹੋ, ਆਮ ਤੌਰ 'ਤੇ ਤੁਹਾਨੂੰ ਇੱਕ ਲੂਪ ਮਿਲਦਾ ਹੈ। ਜਦ ਤੁਸੀਂ ਐਰੇ ਐਲਿਮੈਂਟ ਐਕਸੈਸ ਕਰਦੇ ਹੋ, ਆਮ ਤੌਰ 'ਤੇ ਤੁਹਾਨੂੰ ਸਿੱਧਾ ਮੇਮੋਰੀ ਐਕਸੈਸ ਮਿਲਦਾ ਹੈ। ਇਹ ਪੇਸ਼ਗੀ ਨਿਰਵਚਨਯੋਗਤਾ C ਨੂੰ ਪਰਫਾਰਮੈਂਸ-ਸੰਵੇਦਨਸ਼ੀਲ ਹਿੱਸਿਆਂ ਲਈ ਫਾਇਦੇਮੰਦ ਬਣਾਉਂਦੀ ਹੈ।
C ਮੈਨੁਅਲ ਮੈਮੋਰੀ ਮੈਨੇਜਮੈਂਟ ਵਰਤਦੀ ਹੈ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਹਾਡਾ ਪ੍ਰੋਗਰਾਮ ਖੁਦ ਮੈਮੋਰੀ ਦੀ ਮੰਗ ਕਰਦਾ ਹੈ (ਉਦਾਹਰਨ: malloc) ਅਤੇ ਖੁਦ ਹੀ ਉਸ ਨੂੰ ਰਿਲੀਜ਼ ਕਰਦਾ ਹੈ (free)। ਇਹ ਇਸ ਲਈ ਹੈ ਕਿਉਂਕਿ ਸਿਸਟਮ-ਸਤਰ ਦੇ ਸਾਫਟਵੇਅਰ ਨੂੰ ਅਕਸਰ ਇਹ ਜਾਣਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਕਿ ਕਦੋਂ ਮੈਮੋਰੀ ਆਲੋਕੇਟ ਕੀਤੀ ਜਾਵੇ, ਕਿੰਨੀ, ਅਤੇ ਕਿੰਨੀ ਦੇਰ ਲਈ — ਘੱਟੋ-ਘੱਟ ਛੁਪੇ ਹੋਏ ਓਵਰਹੈਡ ਦੇ ਨਾਲ।
ਚੁਣੌਤੀ ਸਪਸ਼ਟ ਹੈ: ਜ਼ਿਆਦਾ ਨਿਯੰਤਰਣ ਤੇਜ਼ੀ ਅਤੇ ਕੁਸ਼ਲਤਾ ਦੇ ਸਕਦਾ ਹੈ, ਪਰ ਜ਼ਿੰਮੇਵਾਰੀ ਵੀ ਵੱਧ ਜਾਂਦੀ ਹੈ। ਜੇ ਤੁਸੀਂ ਮੈਮੋਰੀ ਨੂੰ ਛੱਡਣਾ ਭੁੱਲੋ, ਦੋ ਵਾਰੀ ਛੱਡ ਦਿਓ, ਜਾਂ ਛੱਡਣ ਤੋਂ ਬਾਅਦ ਵਰਤ ਲਓ, ਤਾਂ ਬਗ ਗੰਭੀਰ ਹੋ ਸਕਦੇ ਹਨ — ਅਤੇ ਕਈ ਵਾਰੀ ਸੁਰੱਖਿਆ ਸੰਬੰਧੀ ਵੀ।
ਆਪਰੇਟਿੰਗ ਸਿਸਟਮ ਸਾਫਟਵੇਅਰ ਅਤੇ ਹਾਰਡਵੇਅਰ ਦਰਮਿਆਨ ਦੀ ਸਰਹੱਦ 'ਤੇ ਖੜੇ ਹੁੰਦੇ ਹਨ। ਕਰਨਲ ਨੂੰ ਮੇਮੋਰੀ ਪ੍ਰਬੰਧਨ, CPU ਸ਼ਡਿਊਲਿੰਗ, ਇੰਟਰਪਟ ਹੇਂਡਲਿੰਗ, ਡਿਵਾਈਸ ਨਾਲ ਗੱਲਬਾਤ ਅਤੇ ਉਹ ਸਿਸਟਮ ਕਾਲਾਂ ਪ੍ਰਦਾਨ ਕਰਣੀਆਂ ਹੁੰਦੀਆਂ ਹਨ ਜਿਨ੍ਹਾਂ 'ਤੇ ਹੋਰ ਸਭ ਨਿਰਭਰ ਹਨ। ਇਹ ਕੰਮ ਸਿਧੇ-ਸਾਫ਼ ਨਹੀਂ ਹਨ—ਇਹ ਵਿਸ਼ੇਸ਼ ਅਡਰੈੱਸ ਤੇ ਲਿਖਣ/ਪੜ੍ਹਨ, CPU ਰਜਿਸਟਰਾਂ ਨਾਲ ਕੰਮ ਅਤੇ ਅਣ-ਸਮੇਂ ਤੇ ਆਉਣ ਵਾਲੇ ਇਵੈਂਟਾਂ 'ਤੇ ਪ੍ਰਤਿਕ੍ਰਿਆ ਕਰਨ ਬਾਰੇ ਹੁੰਦੇ ਹਨ।
ਡਿਵਾਈਸ ਡਰਾਈਵਰ ਅਤੇ ਕਰਨਲ ਨੂੰ ਅਜਿਹੀ ਭਾਸ਼ਾ ਚਾਹੀਦੀ ਹੈ ਜੋ “ਇਹੀ ਕੰਮ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਕਰੋ” ਨੂੰ ਬਿਆਨ ਕਰ ਸਕੇ ਬਿਨਾਂ ਛੁਪੇ ਹੋਏ ਕੰਮਾਂ ਦੇ। ਅਮਲੀ ਤੌਰ 'ਤੇ ਇਹ ਮਤਲਬ ਹੈ:
C ਇਸ ਲਈ ਮੈਚ ਕਰਦੀ ਹੈ ਕਿਉਂਕਿ ਇਸ ਦਾ ਮੁੱਖ ਮਾਡਲ ਮਸ਼ੀਨ ਦੇ ਨੇੜੇ ਹੈ: ਬਾਈਟ, ਐਡਰੈੱਸ ਅਤੇ ਸਧਾਰਨ ਕੰਟਰੋਲ ਫਲੋ। ਕਰਨਲ ਨੂੰ ਬੂਟ ਕਰਨ ਲਈ ਕੋਈ ਮੈਨਡੇਟਰੀ ਰਨਟਾਈਮ, ਗਾਰਬੇਜ ਕਲੇਕਟਰ ਜਾਂ ਵਸਤੂ ਪ੍ਰਣਾਲੀ ਹੋਣ ਦੀ ਲੋੜ ਨਹੀਂ।
Unix ਅਤੇ ਸ਼ੁਰੂਆਤੀ ਸਿਸਟਮਾਂ ਦੇ ਕੰਮ ਨੇ ਉਸ ਪਹੁੰਚ ਨੂੰ ਪ੍ਰਚਲਿਤ ਕੀਤਾ ਜੋ Dennis Ritchie ਨੇ ਸਾਂਝਾ ਕੀਤਾ: ਨਿਵੇਸ਼ਕ ਭਾਗਾਂ ਨੂੰ ਪੋਰਟੇਬਲ ਭਾਸ਼ਾ ਵਿੱਚ ਲਿਖੋ, ਪਰ ਹਾਰਡਵੇਅਰ-ਵਿਸ਼ੇਸ਼ ਹੱਦਾਂ ਨੂੰ patla ਰੱਖੋ। ਬਹੁਤ ਸਾਰੇ ਆਧੁਨਿਕ ਕਰਨਲ ਵੀ ਇਸ ਪੈਟਰਨ ਨੂੰ ਫਾਲੋ ਕਰਦੇ ਹਨ। ਜਿੱਥੇ ਅਸਮੀਬਲੀ ਲਾਜ਼ਮੀ ਹੁੰਦੀ ਹੈ (ਬੂਟ ਕੋਡ, ਕੰਟੈਕਸਟ ਸਵਿੱਚ), ਉੱਥੇ ਵੀ ਜ਼ਿਆਦਾਤਰ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ C ਵਿੱਚ ਹੁੰਦੀ ਹੈ।
C ਕੋਰ ਸਿਸਟਮ ਲਾਇਬ੍ਰੇਰੀਜ਼ ਨੂੰ ਵੀ ਦਬਦਬਾ ਦਿੰਦੀ ਹੈ—ਜਿਵੇਂ ਸਟੈਂਡਰਡ C ਲਾਇਬ੍ਰੇਰੀਆਂ, ਬੁਨਿਆਦੀ ਨੈਟਵਰਕਿੰਗ ਕੋਡ ਅਤੇ ਘੱਟ-ਸਤਰ ਰਨਟਾਈਮ ਹਿੱਸੇ ਜਿਨ੍ਹਾਂ 'ਤੇ ਉੱਚ-ਸਤਰ ਭਾਸ਼ਾਵਾਂ ਅਕਸਰ ਨਿਰਭਰ ਹੁੰਦੀਆਂ ਹਨ। ਜੇ ਤੁਸੀਂ Linux, BSD, macOS, Windows ਜਾਂ ਕਿਸੇ RTOS ਨੂੰ ਵਰਤਿਆ ਹੈ, ਤਾਂ ਸੰਭਵ ਹੈ ਕਿ ਤੁਸੀਂ ਬਿਨਾਂ ਜਾਣੇ-ਪਛਾਣੇ C ਕੋਡ 'ਤੇ ਨਿਰਭਰ ਕੀਤੇ ਹੋ।
C ਦਾ ਆਕਰਸ਼ਣ ਨਾਸਟੈਲਜੀਆ ਦੀ ਬਾਤ ਨਹੀਂ, ਸਗੋਂ ਇੰਜੀਨੀਅਰਿੰਗ ਆਰਥਿਕਤਾ ਦੀ ਗੱਲ ਹੈ:
Rust, C++, ਅਤੇ ਹੋਰ ਭਾਸ਼ਾਵਾਂ ਕੁਝ ਹਿੱਸਿਆਂ ਵਿੱਚ ਵਰਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ ਅਤੇ ਇਹ ਵਾਸਤਵ ਵਿਚ ਲਾਭ ਦੇ ਸਕਦੀਆਂ ਹਨ। ਫਿਰ ਵੀ, C ਆਮ ਸਾਂਝੇ ਬਿੰਦੂ ਰਹਿੰਦੀ ਹੈ: ਬਹੁਤ ਸਾਰੇ ਕਰਨਲ C ਵਿੱਚ ਲਿਖੇ ਗਏ ਹਨ, ਜ਼ਿਆਦਾਤਰ ਨੀਵੇਂ-ਸਤਰ ਇੰਟਰਫੇਸ C ਦੀ ਉਮੀਦ ਕਰਦੇ ਹਨ, ਅਤੇ ਹੋਰ ਸਿਸਟਮ ਭਾਸ਼ਾਵਾਂ ਨੂੰ C ਨਾਲ ਇੰਟਰੋਪਰੇਟ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
“ਐਂਬੈੱਡਡ” ਆਮ ਤੌਰ 'ਤੇ ਉਹ ਕੰਪਿuter ਹੋਂਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਬਾਰੇ ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਸੋਚਦੇ ਨਹੀਂ—ਥਰਮੋਸਟੈਟਾਂ, ਸਮਾਰਟ ਸਪੀਕਰ, ਰਾਊਟਰ, ਕਾਰਾਂ, ਮੈਡੀਕਲ ਡਿਵਾਈਸ, ਫੈਕਟਰੀ ਸੈਂਸਰ ਅਤੇ ਬੇਸ਼ੁਮਾਰ ਉਪਕਰਣ। ਇਹ ਪ੍ਰਣਾਲੀਆਂ ਅਕਸਰ ਸਾਲਾਂ ਤੱਕ ਇੱਕ ਹੀ ਉਦੇਸ਼ ਚੱਲਦੀਆਂ ਹਨ, ਘੱਟ-ਖ਼ਰਚ, ਘੱਟ-ਪਾਵਰ ਅਤੇ ਕੁਝ ਹਾਲਤਾਂ ਵਿੱਚ ਸਖਤ ਸੋਧੀ-ਅਨੁਸਾਰਤਾ ਨਾਲ।
ਕਈ ਐਂਬੈੱਡਡ ਟਾਰਗਟਾਂ ਕੋਲ ਕਿਲੋਬਾਈਟ (ਗਿਗਾਬਾਈਟ ਨਹੀਂ) RAM ਅਤੇ ਸੀਮਤ ਫਲੇਸ਼ ਸਟੋਰੇਜ ਹੁੰਦੀ ਹੈ। ਕੁਝ ਬੈਟਰੀ 'ਤੇ ਚਲਦੇ ਹਨ ਅਤੇ ਜਿਆਦਾਤਰ ਸਮੇਂ ਸੁੱਤੇ ਰਹਿਣਾ ਪੈਂਦਾ ਹੈ। ਹੋਰਾਂ ਦੇ ਕੋਲ ਰੀਅਲ-ਟਾਈਮ ਡੈਡਲਾਈਨ ਹੁੰਦੀਆਂ ਹਨ—ਜੇਕਰ ਮੋਟਰ-ਕੰਟਰੋਲ ਲੂਪ ਕੁਝ ਮਿਲੀ-ਸੈਕੰਡ ਲਈ ਦੇਰ ਕਰ ਜਾਵੇ, ਤਾਂ ਹਾਰਡਵੇਅਰ ਗਲਤ ਤਰੀਕੇ ਨਾਲ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ।
ਇਹ ਸੀਮਾਵਾਂ ਹਰ ਫੈਸਲੇ ਨੂੰ ਰੂਪ ਦਿੰਦੀਆਂ ਹਨ: ਪ੍ਰੋਗਰਾਮ ਕਿੰਨਾ ਵੱਡਾ ਹੈ, ਕਿੰਨੀ ਵਾਰੀ ਉਹ ਜਾਗੇਗਾ, ਅਤੇ ਕੀ ਇਸ ਦੀ ਟਾਈਮਿੰਗ ਭਰੋਸੇਯੋਗ ਹੈ।
C ਆਮ ਤੌਰ 'ਤੇ ਛੋਟੇ ਬਾਈਨਰੀਆਂ ਬਣਾਉਂਦੀ ਹੈ ਅਤੇ ਘੱਟ ਰਨਟਾਈਮ ਓਵਰਹੈਡ ਹੁੰਦਾ ਹੈ। ਕੋਈ ਵਰਤਿਆ ਜਾ ਨਾ ਹੋਣ ਵਾਲੀ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ, ਅਤੇ ਅਕਸਰ ਤੁਸੀਂ ਡਾਇਨੈਮਿਕ ਐਲੋਕੇਸ਼ਨ ਤੋਂ ਪਰੇ ਹੋ ਸਕਦੇ ਹੋ। ਇਹ ਉਸ ਵੇਲੇ ਮੈਟਰ ਕਰਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਫਰਮਵੇਅਰ ਨੂੰ ਇੱਕ ਨਿਰਧਾਰਤ ਫਲੇਸ਼ ਸਾਈਜ਼ ਵਿੱਚ ਫਿੱਟ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ ਜਾਂ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਡਿਵਾਈਸ ਅਚਾਨਕ “ਰੁਕ” ਨਾ ਜਾਵੇ।
ਉਤਨਾ ਹੀ ਮਹੱਤਵਪੂਰਨ, C ਹਾਰਡਵੇਅਰ ਨਾਲ ਗੱਲ ਕਰਨ ਨੂੰ ਸਾਦਾ ਬਣਾਉਂਦਾ ਹੈ। ਐਂਬੈੱਡਡ ਚਿਪ ਪੇਰੀਫੇਰਲਾਂ—GPIO ਪਿੰਸ, ਟਾਈਮਰ, UART/SPI/I2C ਬਸ—ਨੂੰ ਮੇਮੋਰੀ-ਮੈਪਡ ਰਜਿਸਟਰਾਂ ਰਾਹੀਂ ਪੇਸ਼ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। C ਦਾ ਮਾਡਲ ਇਸ ਨਾਲ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਮਿਲਦਾ ਹੈ: ਤੁਸੀਂ ਖ਼ਾਸ ਐਡਰੈੱਸ ਪੜ੍ਹ ਅਤੇ ਲਿਖ ਸਕਦੇ ਹੋ, ਵਿਅਕਤੀਗਤ ਬਿੱਟਾਂ ਨੂੰ ਕਾਬੂ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਘੱਟ ਸਰਗਰਮੀ ਦੇ ਨਾਲ ਇਹ ਸਭ ਕਰ ਸਕਦੇ ਹੋ।
ਬਹੁਤ ਸਾਰਾ ਐਂਬੈੱਡਡ C ਗਿਆ:
ਦੋਹਾਂ ਹਾਲਤਾਂ ਵਿੱਚ, ਤੁਸੀਂ ਹਾਰਡਵੇਅਰ ਰਜਿਸਟਰ (ਅਕਸਰ volatile ਨਾਲ ਨਿਸ਼ਾਨ ਲਗੇ), ਨਿਸ਼ਚਿਤ-ਸਾਈਜ਼ ਬਫ਼ਰ ਅਤੇ ਧਿਆਨ ਨਾਲ ਟਾਈਮਿੰਗ ਦੇ ਕੋਡ ਵੇਖੋਗੇ। ਇਹ “ਮਸ਼ੀਨ ਦੇ ਨੇੜੇ” ਅੰਦਾਜ਼ ਹੀ C ਨੂੰ ਫਰਮਵੇਅਰ ਲਈ ਡੀਫ਼ਾਲਟ ਚੋਣ ਬਣਾਉਂਦਾ ਹੈ।
“ਪਰਫਾਰਮੈਂਸ-ਸੰਵੇਦਨਸ਼ੀਲ” ਉਹ ਹਾਲਤ ਹੈ ਜਿੱਥੇ ਸਮੇ ਅਤੇ ਸਰੋਤ ਉਤਪਾਦ ਦਾ ਹਿੱਸਾ ਹਨ: ਮਿਲੀ-ਸੈਕੰਡ ਯੂਜ਼ਰ ਅਨੁਭਵ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੇ ਹਨ, CPU ਚੱਕਰ ਸਰਵਰ ਲਾਗਤ 'ਤੇ ਅਸਰ ਪਾਉਂਦੇ ਹਨ, ਅਤੇ ਮੇਮੋਰੀ ਵਰਤੋਂ ਤੈਅ ਕਰਦੀ ਹੈ ਕਿ ਪ੍ਰੋਗਰਾਮ ਢੰਗ ਨਾਲ ਫਿੱਟ ਹੁੰਦਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਇਨ੍ਹਾਂ ਥਾਵਾਂ 'ਤੇ, C ਅਜੇ ਵੀ ਡੀਫ਼ਾਲਟ ਚੋਣ ਹੈ ਕਿਉਂਕਿ ਇਹ ਟੀਮਾਂ ਨੂੰ ਡੇਟਾ ਦੀ ਲੇਆਊਟ, ਕੰਮ ਦੇ ਸ਼ੈਡਿਊਲ ਅਤੇ ਕੰਪਾਇਲਰ ਲਈ ਕੀ Optimize ਕਰਨ ਦੀ ਆਜ਼ਾਦੀ ਦਿੰਦਾ ਹੈ।
ਤੁਸੀਂ ਅਕਸਰ C ਨੂੰ ਉਨ੍ਹਾਂ ਸਿਸਟਮਾਂ ਦੇ ਕੋਰ ਵਿੱਚ ਪਾਵੋਗੇ ਜਿੱਥੇ ਊਂਜ ਅਤੇ ਲੇਟਨਸੀ ਮੁਹੱਤਵ ਰੱਖਦੇ ਹਨ:
ਇਹ ਖੇਤਰ ਹਰ ਜਗ੍ਹਾ ਤੇਜ਼ ਨਹੀਂ ਹੁੰਦੇ; ਆਮ ਤੌਰ 'ਤੇ ਕੁਝ ਅੰਦਰੂਨੀ ਲੂਪ ਹੁੰਦੇ ਹਨ ਜੋ ਰਨਟਾਈਮ ਦਾ ਬਹੁਤ ਵੱਡਾ ਹਿੱਸਾ ਖਾਂਦੇ ਹਨ।
ਟੀਮਾਂ ਮੁੱਢਲੀ ਤੌਰ 'ਤੇ ਪੂਰੇ ਉਤਪਾਦ ਨੂੰ C ਵਿੱਚ ਮੁੜ-ਲਿਖਦੀਆਂ ਨਹੀਂ। ਬਜਾਏ, ਉਹ ਪ੍ਰੋਫ਼ਾਈਲ ਕਰਦੀਆਂ ਹਨ, ਹੌਟ ਪਾਥ ਲੱਭਦੀਆਂ ਹਨ (ਉਹ ਛੋਟੀ ਹਿੱਸਾ ਜਿੱਥੇ ਸਮਾਂ ਬਹੁਤ ਹੈ), ਅਤੇ ਉਸ ਨੂੰ ਓਪਟੀਮਾਈਜ਼ ਕਰਦੀਆਂ ਹਨ।
C ਮਦਦ ਕਰਦੀ ਹੈ ਕਿਉਂਕਿ ਹੌਟ ਪਾਥ ਅਕਸਰ ਨੀਵਾਂ-ਸਤਰ ਦੇ ਵਿਵਰਣਾਂ ਨਾਲ ਸੀਮਾ-ਬੱਧ ਹੁੰਦੇ ਹਨ: ਮੈਮੋਰੀ ਐਕਸੈਸ ਪੈਟਰਨ, ਕੈਸ਼ ਵਿਹਾਰ, ਬ੍ਰਾਂਚ ਪ੍ਰੀਡਿਕਸ਼ਨ ਅਤੇ ਐਲੋਕੇਸ਼ਨ ਓਵਰਹੈਡ। ਜਦ ਤੁਸੀਂ ਡੇਟਾ ਸਟਰਕਚਰਾਂ ਨੂੰ ਟਿਊਨ ਕਰ ਸਕਦੇ ਹੋ, ਬੇਕਾਰ ਕਾਪੀਆਂ ਟਾਲ ਸਕਦੇ ਹੋ, ਅਤੇ ਐਲੋਕੇਸ਼ਨ ਨੂੰ ਨਿਯੰਤਰਤ ਕਰ ਸਕਦੇ ਹੋ, ਤਾਂ ਤੇਜ਼ੀਆਂ ਨਤੀਜੇ ਦੇ ਸਕਦੀਆਂ ਹਨ—ਬਿਨਾਂ ਬਾਕੀ ਐਪ ਨੂੰ ਸਪर्श ਕੀਤੇ।
ਆਧੁਨਿਕ ਉਤਪਾਦ ਅਕਸਰ “ਮਿਕਸ-ਭਾਸ਼ਾ” ਹੁੰਦੇ ਹਨ: Python, Java, JavaScript, ਜਾਂ Rust ਬਹੁਤ ਕੋਡ ਲਈ, ਅਤੇ ਪਰਫਾਰਮੈਂਸ-ਨਾਜ਼ੂਕ ਕੋਰ ਲਈ C।
ਆਮ ਇੰਟੇਗ੍ਰੇਸ਼ਨ ਤਰੀਕੇ:
ਇਹ ਮਾਡਲ ਵਿਕਾਸ ਨੂੰ ਪਰਾਇਕਟਿਕ ਰੱਖਦਾ ਹੈ: ਤੁਸੀਂ ਉੱਚ-ਸਤਰ ਭਾਸ਼ਾ ਵਿੱਚ ਤੇਜ਼ ਇਟਰੈਸ਼ਨ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹੋ, ਅਤੇ ਜਿੱਥੇ ਲੋੜ ਹੈ ਉਥੇ ਨਿਰਭਰ ਪਰਫਾਰਮੈਂਸ। ਟਰੇਡ-ਆਫ ਸੀਮਾ ਲੰਘਣ 'ਤੇ ਧਿਆਨ ਦੀ ਲੋੜ ਹੈ—ਡੇਟਾ ਕਨਵਰਸ਼ਨ, ਮਾਲਕੀ ਹੱਕ (ownership) ਨਿਯਮ, ਅਤੇ ਏਰਰ ਹੈਂਡਲਿੰਗ—ਕਿਉਂਕਿ FFI ਸੀਮਾ 'ਤੇ ਕੁਝ ਸੰਭਾਲ ਲੋੜੀਂਦੀ ਹੁੰਦੀ ਹੈ।
ਇੱਕ ਵਜ੍ਹਾ ਕਿ C ਤੇਜ਼ੀ ਨਾਲ ਫੈਲੀ, ਇਹ ਹੈ ਕਿ ਇਹ "ਚੱਲਦੀ" ਹੈ: ਉਹੀ ਮੂਲ ਭਾਸ਼ਾ ਵੱਖ-ਵੱਖ ਮਸ਼ੀਨਾਂ 'ਤੇ ਲਾਗੂ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ, ਛੋਟੀ ਮਾਈਕ੍ਰੋਕੰਟਰੋਲਰ ਤੋਂ ਲੈ ਕੇ ਸੁਪਰਕੰਪਿuter ਤੱਕ। ਇਹ ਪੋਰਟੇਬਿਲਟੀ ਜਾਦੂ ਨਹੀਂ—ਇਹ ਸਾਂਝੇ ਸਟੈਂਡਰਡ ਅਤੇ ਇੱਕ ਸੱਭਿਆਚਾਰ ਦੇ ਨਤੀਜੇ ਹਨ।
ਪਹਿਲੀ C ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਵਾਇਨਡਰ ਵੱਲੋਂ ਵੱਖ-ਵੱਖ ਸੀ, ਜਿਸ ਨਾਲ ਕੋਡ ਸਾਂਝਾ ਕਰਨਾ ਮੁਸ਼ਕਲ ਸੀ। ਵੱਡਾ ਬਦਲਾਅ ANSI C (ਸਧਾਰਨ ਤੌਰ 'ਤੇ C89/C90 ਕਿਹਾ ਜਾਂਦਾ) ਅਤੇ ਬਾਅਦ ਵਿੱਚ ISO C (C99, C11, C17, C23) ਦੇ ਆਉਣ ਨਾਲ ਆਇਆ। ਤੁਹਾਨੂੰ ਵਰਜਨ ਨੰਬਰ ਯਾਦ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ; ਮੁੱਖ ਗੱਲ ਇਹ ਹੈ ਕਿ ਇੱਕ ਸਟੈਂਡਰਡ ਭਾਸ਼ਾ ਅਤੇ ਸਟੈਂਡਰਡ ਲਾਇਬ੍ਰੇਰੀ ਲਈ ਇਕ ਸਾਰਵਜਨਿਕ ਸਹਿਮਤੀ ਦਿੰਦਾ ਹੈ।
ਇੱਕ ਸਟੈਂਡਰਡ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ:
ਇਸ ਲਈ ਸਟੈਂਡਰਡ-ਮਨੁੱਖੀ ਕੋਡ ਕਈ ਵਾਰੀ ਕੰਪਾਈਲਰਾਂ ਅਤੇ ਪਲੇਟਫਾਰਮਾਂ ਵਿੱਚ ਥੋੜੀਆਂ ਹੀ ਬਦਲਾਵਾਂ ਨਾਲ ਚੱਲ ਜਾਂਦਾ ਹੈ।
ਪੋਰਟੇਬਿਲਟੀ ਸਮੱਸਿਆਵਾਂ ਆਮ ਤੌਰ 'ਤੇ ਉਨ੍ਹਾਂ ਚੀਜ਼ਾਂ 'ਤੇ ਆਧਾਰਿਤ ਹੁੰਦੀਆਂ ਹਨ ਜੋ ਸਟੈਂਡਰਡ ਗਾਰੰਟੀ ਨਹੀਂ ਕਰਦਾ:
int ਨੂੰ 32-ਬਿਟ ਦਾ ਵਾਅਦਾ ਨਹੀਂ ਕੀਤਾ ਗਿਆ, ਅਤੇ ਪੁਆਇੰਟਰ ਸਾਈਜ਼ ਵੱਖ-ਵੱਖ ਹੋ ਸਕਦੀ ਹੈ।ਇੱਕ ਵਧੀਆ ਡੀਫ਼ਾਲਟ ਇਹ ਹੈ ਕਿ ਸਟੈਂਡਰਡ ਲਾਇਬ੍ਰੇਰੀ ਦਾ ਪਸੰਦ ਕਰੋ ਅਤੇ ਗੈਰ-ਪੋਰਟੇਬਲ ਕੋਡ ਨੂੰ ਛੋਟੇ, ਸਾਫ਼ ਨਾਮਾਂ ਵਾਲੇ ਰੈਪਰਾਂ ਦੇ ਪਿੱਛੇ ਰੱਖੋ।
ਇਸਦੇ ਨਾਲ-ਨਾਲ, ਉਹ ਕੰਪਾਇਲ ਫਲੈਗ ਵਰਤੋ ਜੋ ਤੁਹਾਨੂੰ ਪੋਰਟੇਬਲ ਅਤੇ ਪਰਿਭਾਸ਼ਿਤ C ਵੱਲ ਧੱਕਦੇ ਹਨ, ਉਦਾਹਰਣ ਲਈ:
-std=c11)-Wall -Wextra) ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਗੰਭੀਰਤਾ ਨਾਲ ਲੈਣਾਇਹ ਜੋੜ—ਸਟੈਂਡਰਡ-ਪਹਿਲਾਂ ਕੋਡ ਅਤੇ ਸਖਤ ਬਿਲਡ—ਪੋਰਟੇਬਿਲਟੀ ਲਈ ਕਿਸੇ ਵੀ "ਚਾਲਾਕ" ਤਰਕੀਬ ਨਾਲੋਂ ਵੱਧ ਮਦਦ ਕਰਦਾ ਹੈ।
C ਦੀ ਤਾਕਤ ਇਸਦੀ ਤੇਜ਼ ਤੇ ਵਾਰ-ਚੁੱਕੀ ਧਾਰ ਹੈ: ਇਹ ਤੁਹਾਨੂੰ ਮੇਮੋਰੀ ਦੇ ਨੇੜੇ ਕੰਮ ਕਰਨ ਦਿੰਦੀ ਹੈ। ਇਹ ਤੇਜ਼ੀ ਅਤੇ ਲਚਕੀਲਾਪਨ ਦਾ ਵੱਡਾ ਕਾਰਨ ਹੈ—ਪਰ ਇਹੀ ਗੱਲ ਨਵੇਂ ਲੋਕਾਂ (ਅਤੇ ਥੱਕੇ ਹੋਏ ਮਾਹਿਰਾਂ) ਲਈ ਸਹੀ ਨਹੀਂ ਹੋ ਸਕਦੀ, ਕਿਉਂਕਿ ਹੋਰ ਭਾਸ਼ਾਵਾਂ ਜਿਹੜੀਆਂ ਇਹ ਗਲਤੀਆਂ ਰੋਕ ਲੈਂਦੀਆਂ ਹਨ, C ਉਨ੍ਹਾਂ ਨੂੰ ਆਸਾਨੀ ਨਾਲ ਕਰਨ ਦੇ ਦਿੰਦਾ਼ ਹੈ।
ਕਲਪਨਾ ਕਰੋ ਕਿ ਤੁਹਾਡੇ ਪ੍ਰੋਗਰਾਮ ਦੀ ਮੇਮੋਰੀ ਇਕ ਲੰਬੀ ਗਲੀ ਹੈ ਜਿਸ 'ਤੇ ਨੰਬਰ ਲੱਗੇ ਹੋਏ ਪੋਸਟ ਬਾਕਸ ਹਨ। ਇੱਕ ਵੈਰੀਏਬਲ ਇਕ ਬਾਕਸ ਹੈ ਜੋ ਕਿਸੇ ਚੀਜ਼ ਨੂੰ ਰੱਖਦਾ ਹੈ (ਜਿਵੇਂ ਇੱਕ ਇੰਟੀਜਰ)। ਇੱਕ ਪੁਆਇੰਟਰ ਉਹ ਚੀਜ਼ ਨਹੀਂ ਹੈ—ਇਹ ਉਸ ਐਡਰੈੱਸ ਵਾਲੇ ਪੱਤਰ ਦੀ ਤਰ੍ਹਾਂ ਹੈ ਜੋ ਦੱਸਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਕਿਹੜਾ ਬਾਕਸ ਖੋਲ੍ਹਣਾ ਹੈ।
ਇਹ ਲਾਭਦਾਇਕ ਹੈ: ਤੁਸੀਂ ਨਕਲ ਕਰਨ ਦੀ ਥਾਂ ਐਡਰੈੱਸ ਪਾਸ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਤੁਸੀਂ ਐਰੇ, ਬਫ਼ਰ, ਸਟ੍ਰਕਟ ਜਾਂ hatta ਫੰਕਸ਼ਨਾਂ ਦੀ ਦੁੱਗਣੀ ਵੀ ਪਾਸ ਕਰ ਸਕਦੇ ਹੋ। ਪਰ ਜੇ ਐਡਰੈੱਸ ਗਲਤ ਹੋਵੇ, ਤਾਂ ਤੁਸੀਂ ਗਲਤ ਬਾਕਸ ਖੋਲ੍ਹ ਲਵੋਗੇ।
ਇਹ ਮੁੱਦੇ ਕਰੈਸ਼, ਚੁਪਚਾਪ ਡੇਟਾ ਰੂਪਾਂਤਰਣ ਅਤੇ ਸੁਰੱਖਿਆ ਦੀਆਂ ਖਾਮੀਆਂ ਵਜੋਂ ਉਭਰਦੇ ਹਨ। ਸਿਸਟਮ ਕੋਡ ਵਿੱਚ—ਜਿੱਥੇ C ਅਕਸਰ ਵਰਤੀਦੀ ਹੈ—ਇਹ ਫੇਲ ਹੋਰ ਉੱਪਰਲੇ ਸਭ ਤੇ ਅਸਰ ਪਾ ਸਕਦੇ ਹਨ।
C "ਡਿਫ਼ੌਲਟ ਤੌਰ 'ਤੇ ਅਸੁਰੱਖਿਅਤ" ਨਹੀਂ ਹੈ; ਇਹ ਆਗਿਆਗ੍ਰਾਹੀ ਹੈ: ਕੰਪਾਇਲਰ ਮੰਨਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਜੋ ਲਿਖਦੇ ਹੋ, ਉਸੇ ਦਾ ਅਰਥ ਹੈ। ਇਹ ਪਰਫਾਰਮੈਂਸ ਅਤੇ ਨੀਵਾਂ ਨਿਯੰਤਰਣ ਲਈ ਵਧੀਆ ਹੈ, ਪਰ ਇਸਦਾ ਮਤਲਬ ਇਹ ਵੀ ਹੈ ਕਿ ਜੇ ਤੁਸੀਂ ਧਿਆਨ ਨਾ ਰੱਖੋ ਤਾਂ C ਦਾ ਗਲਤ ਉਪਯੋਗ ਆਸਾਨ ਹੈ—ਇਸ ਲਈ ਚੰਗੀਆਂ ਆਦਤਾਂ, ਸਮੀਖਿਆਆਂ ਅਤੇ ਸੰਦ ਲੋੜੀਂਦੇ ਹਨ।
C ਤੁਹਾਨੂੰ ਸਿੱਧਾ ਨਿਯੰਤਰਣ ਦਿੰਦੀ ਹੈ, ਪਰ ਅਕਸਰ ਮਾਫ਼ ਨਹੀਂ ਕਰਦੀ। ਚੰਗੀ ਖ਼ਬਰ ਇਹ ਹੈ ਕਿ “ਸੁਰੱਖਿਅਤ C” ਜਾਦੂਈ ਉਪਾਅ ਦੀ ਬਜਾਏ ਅਨੁਸ਼ਾਸਨ, ਸਪਸ਼ਟ ਇੰਟਰਫੇਸ ਅਤੇ ਟੂਲਾਂ ਨਾਲ ਸੰਭਵ ਹੈ।
API ਡਿਜ਼ਾਈਨ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਗਲਤ ਵਰਤੋਂ ਨੂੰ ਮੁਸ਼ਕਿਲ ਬਣਾਉਂਦੇ ਹਨ। ਬਫ਼ਰ ਨਾਲ ਜੁੜੇ ਫੰਕਸ਼ਨਾਂ ਲਈ ਨਿਰਧਾਰਤ ਲੰਬਾਈਆਂ ਲੈਣਾ, ਸਪਸ਼ਟ ਸਟੇਟਸ ਕੋਡ ਵਾਪਸ ਕਰਨਾ ਅਤੇ ਇਹ ਦਸਣਾ ਕਿ ਕੌਣAllocated ਮੈਮੋਰੀ ਦੀ ਮਾਲਕੀ ਰੱਖਦਾ ਹੈ—ਇਹ ਸਭ ਸਧਾਰਨ ਪਰ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਨੀਤੀ ਹਨ।
ਬਾਊਂਡ ਚੈਕਿੰਗ ਰੂਟੀਨ ਬਣਾਉਣਾ ਆਮ ਗੱਲ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਜੇ ਕੋਈ ਫੰਕਸ਼ਨ ਬਫ਼ਰ ਵਿੱਚ ਲਿਖਦਾ ਹੈ, ਤਾਂ ਉਹ ਪਹਿਲਾਂ ਲੰਬਾਈ ਦਿਖਾ ਦੇ ਅਤੇ ਫੇਲ ਫਾਸਟ ਕਰ ਦੇ। ਮੈਮੋਰੀ ਮਾਲਕੀ ਲਈ ਸਧਾਰਤ ਨਿਯਮ ਰੱਖੋ: ਇੱਕ ਐਲੋਕੇਟਰ, ਇੱਕ ਮੁਕਾਬਲ਼ਾ free ਰਾਹ। ਕਾਲਰ ਜਾਂ ਕੈਲੀਦਰ ਕੌਣ ਰਿਸੋਰਸ ਰਿਲੀਜ਼ ਕਰੇਗਾ, ਇਹ ਸਪਸ਼ਟ ਰੱਖੋ।
ਆਧੁਨਿਕ ਕੰਪਾਇਲਰ ਸੰਭਾਵਿਤ ਰਿਸਕ ਪੈਟਰਨਾਂ 'ਤੇ ਚੇਤਾਵਨੀ ਦੇ ਸਕਦੇ ਹਨ—CI ਵਿੱਚ ਵਾਰਨਿੰਗਸ ਨੂੰ errors ਵਾਂਗੋਂ ਸਮਝੋ। ਡਿਵੈਲਪਮੈਂਟ ਦੌਰਾਨ runtime checks ਲਈ sanitizers ਵਰਤੋ (address, undefined behavior, leak) ਤਾਂ ਜੋ ਬਾਊਂਡ-ਆਊਟ, ਯੂਜ਼-ਅਫਟਰ-ਫ੍ਰੀ, ਇੰਟੀਜਰ ਓਵਰਫਲੋ ਵਰਗੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਪਤਾ ਲਾਇਆ ਜਾ ਸਕੇ।
ਸਟੈਟਿਕ ਵਿਸ਼ਲੇਸ਼ਣ ਅਤੇ ਲਿੰਟਰ ਸਾਰੇ ਐਸ булй ਕਰੋ: ਉਹ ਐਸੇ ਮੁੱਦੇ ਲੱਭਣਗੇ ਜੋ ਟੈਸਟਾਂ ਵਿੱਚ ਨਜ਼ਰ ਨਹੀਂ ਆਉਂਦੇ। ਫਜ਼ਿੰਗ parsing ਅਤੇ ਪ੍ਰੋਟੋਕੋਲ-ਹੈਂਡਲਿੰਗ ਲਈ ਬਹੁਤ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੈ: ਇਹ ਅਣਉਮੀਦਿਤ ਇੰਪੁੱਟ ਜਨਰੇਟ ਕਰਦਾ ਹੈ ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਬਫ਼ਰ ਅਤੇ ਸਟੇਟ-ਮਸ਼ੀਨ ਬੱਗ ਖੋਲ੍ਹਦਾ ਹੈ।
ਕੋਡ ਸਮੀਖਿਆ ਵਿੱਚ ਆਮ C ਫੇਲ ਮੋਡਾਂ ਲਈ ਖਾਸ ਤੌਰ 'ਤੇ ਦੇਖਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ: ਆਫ-ਬਾਈ-ਵਨ ਇੰਡੈਕਸਿੰਗ, NUL ਟਰਮੀਨੇਟਰਗੱਲ, ਸਾਇਨਡ/ਅਨਸਾਇਨਡ ਵਿਲੱਖਣਤਾਵਾਂ, ਅਣਚੁੱਕੇ ਰਿਟਰਨ ਵੈਲਿਊਜ਼ ਅਤੇ ਐਰਰ-ਰਾਹ ਜੋ ਮੈਮੋਰੀ ਲੀਕ ਕਰਦੇ ਹਨ।
ਟੈਸਟਿੰਗ ਉਹ ਸਮਾਂ ਤੇ ਵੱਧ ਅਹੰਕਾਰ-ਭਰਪੂਰ ਹੈ ਜਦੋਂ ਭਾਸ਼ਾ ਤੁਹਾਨੂੰ ਰੋਕਦੀ ਨਹੀਂ। ਯੂਨਿਟ ਟੈਸਟਾਂ ਚੰਗੀਆਂ ਹਨ; ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਟੈਸਟ ਵਧੀਆ ਹਨ; ਅਤੇ ਪਹਿਲਾਂ ਹੋਏ ਬੱਗਾਂ ਲਈ ਰੈਗਰੇਸ਼ਨ ਟੈਸਟ ਸਭ ਤੋਂ ਵਧੀਆ ਹਨ।
ਜੇ ਤੁਹਾਡੇ ਪ੍ਰੋਜੈਕਟ ਦੇ ਰਿਲਾਇਬਿਲਟੀ ਜਾਂ ਸੁਰੱਖਿਆ ਦੀਆਂ ਕਠੋਰ ਲੋੜਾਂ ਹਨ, ਤਾਂ C ਦਾ ਇੱਕ ਸੀਮਤ “ਸਬਸੈੱਟ” ਅਤੇ ਲਿਖੀਆਂ ਗਈਆਂ ਨਿਯਮ ਲਵੋ (ਉਦਾਹਰਨ ਲਈ ਪੁਆਇੰਟਰ ਅਰਿਥਮੇਟਿਕ ਨੂੰ ਸੀਮਿਤ ਕਰਨਾ, ਕੁਝ ਲਾਇਬ੍ਰੇਰੀ ਕਾਲਾਂ ਨੂੰ ਮਨਾਂ ਕਰਨਾ, ਜਾਂ ਰੈਪਰ ਲਾਜਿਕ ਜ਼ਰੂਰੀ ਕਰਨਾ)। ਚਾਬੀ ਸਥਿਰਤਾ ਹੈ: ਉਹ ਨਿਯਮ ਚੁਣੋ ਜਿਨ੍ਹਾਂ ਨੂੰ ਟੀਮ ਟੂਲਿੰਗ ਅਤੇ ਸਮੀਖਿਆ ਨਾਲ ਲਾਗੂ ਕਰ ਸਕੇ—ਇਹ ਨਾ ਹੋਵੇ ਕਿ ਸਿਰਫ ਸਲਾਈਡ 'ਤੇ ਰੱਖੇ ਹੋਏ ਆਦਰਸ਼।
C ਇੱਕ ਅਜਿਹੇ ਚੌਕ ਵਿੱਚ ਖੜੀ ਹੈ: ਇਹ ਛੋਟੀ ਹੈ ਤਾਂ ਕਿ ਅੰਤ-ਤੱਕ ਸਮਝ ਆ ਜਾਏ, ਪਰ ਹਾਰਡਵੇਅਰ ਅਤੇ OS ਸਰਹੱਦਾਂ ਦੇ ਨੇੜੇ ਕਾਫ਼ੀ ਹੈ ਤਾਂ ਕਿ ਇਹ ਹਰ ਜਗ੍ਹੇ "ਗਲੂ" ਬਣ ਕੇ ਰਹਿ ਜਾਵੇ। ਇਹ ਮਿਲਾਪ ਕਾਰਨ ਟੀਮਾਂ ਅਜੇ ਵੀ ਇਸਨੂੰ ਚੁਣਦੀਆਂ ਹਨ—ਭਾਵੇਂ ਨਵੀਆਂ ਭਾਸ਼ਾਵਾਂ ਕਾਗਜ਼ ਤੇ ਵਧੀਆ ਲੱਗਦੀਆਂ ਹੋਣ।
C++ ਨੂੰ ਵੱਡੀਆਂ ਐਬਸਟ੍ਰੈਕਸ਼ਨਾਂ (ਕਲਾਸਾਂ, ਟੈਂਪਲੇਟ, RAII) ਜੋੜ ਕੇ ਬਣਾਇਆ ਗਿਆ ਸੀ, ਅਤੇ ਇਹ ਬਹੁਤ ਹੱਦ ਤੱਕ C ਨਾਲ ਸਰੋਤ-ਸਥ ਛੇੜਛਾੜ ਵਿੱਚ ਸਮਰੱਥ ਹੈ। ਪਰ “ਅਨੁਕੂਲ” ਦਾ ਮਤਲਬ “ਇੱਕੋ” ਨਹੀਂ ਹੈ। C++ ਵਿੱਚ implicit conversions, overload resolution ਅਤੇ ਕੁਝ ਏਜੇਡ ਕੇਸਾਂ ਵਿੱਚ ਵਿਧਾਨ ਵੱਖਰੇ ਹੁੰਦੇ ਹਨ।
ਅਸਲ ਉਤਪਾਦਾਂ ਵਿੱਚ ਮਿਲਾਪ ਆਮ ਹੈ:
ਇਸ ਪੁਲ ਦਾ ਆਮ ਤਰੀਕਾ C API ਬੋਰਡਰ ਹੁੰਦਾ ਹੈ। C++ ਕੋਡ extern "C" ਨਾਲ ਫੰਕਸ਼ਨ ਐਕਸਪੋਰਟ ਕਰਦਾ ਹੈ ਤਾਂ ਕਿ name mangling ਨਾ ਹੋਵੇ, ਅਤੇ ਦੋਹਾਂ ਪਾਸਿਆਂ ਨੇ ਸਾਦਾ ਡੇਟਾ ਸਟ੍ਰਕਚਰਾਂ 'ਤੇ ਸਹਿਮਤੀ ਕੀਤੀ ਹੋਵੇ। ਇਸ ਨਾਲ ਟੀਮਾਂ ਧੀਰੇ-ਧੀਰੇ ਮਾਡਰਨਾਈਜ਼ ਕਰ ਸਕਦੀਆਂ ਹਨ ਬਿਨਾਂ ਸਾਰਾ ਕੋਡ ਮੁੜ-ਲਿਖੇ।
Rust ਦੀ ਵੱਡੀ ਵਾਅਦਾ ਹੈ ਕਿ ਗਾਰਬੇਜ ਕਲੇਕਟਰ ਦੇ ਬਗੈਰ ਯਾਦاشت ਸੁਰੱਖਿਆ ਮਿਲਦੀ ਹੈ, ਮਜ਼ਬੂਤ ਟੂਲਿੰਗ ਅਤੇ ਪੈਕੇਜ ਇਕੋ ਸਿਸਟਮ ਦੇ ਨਾਲ। ਕਈ ਨਵੇਂ ਪ੍ਰੋਜੈਕਟਾਂ ਲਈ, ਇਹ ਯੂਜ਼-ਅਫਟਰ-ਫ੍ਰੀ ਅਤੇ ਡਾਟਾ-ਰੇਸ ਵਰਗੀਆਂ ਬੱਗਾਂ ਦੇ ਕਲਾਸਾਂ ਨੂੰ ਘਟਾ ਸਕਦਾ ਹੈ।
ਪਰ ਅਪਣਾਉਣਾ ਮੁਫ਼ਤ ਨਹੀਂ ਹੁੰਦਾ। ਟੀਮਾਂ ਪਰਾਬੰਧਤ ਹੋ ਸਕਦੀਆਂ ਹਨ:
Rust C ਨਾਲ ਇੰਟਰੋਪਰੇਟ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਬਾਰਡਰ ਕੁਝ ਜਟਿਲਤਾ ਜੋੜਦਾ ਹੈ, ਅਤੇ ਹਰ ਐਂਬੈੱਡਡ ਟਾਰਗਟ ਜਾਂ ਬਿਲਡ ਵਾਤਾਵਰਨ ਇਕਸਾਰ ਤੌਰ 'ਤੇ ਸਮਰਥਿਤ ਨਹੀਂ ਹੁੰਦੇ।
ਦੁਨੀਆ ਦਾ ਬਹੁਤ ਸਾਰਾ ਮੂਲ ਕੋਡ C ਵਿੱਚ ਹੈ, ਅਤੇ ਇਸਨੂੰ ਦੁਬਾਰਾ ਲਿਖਣਾ ਖ਼ਤਰਨਾਕ ਅਤੇ ਮਹਿੰਗਾ ਹੈ। C ਉਹ ਜ਼ਮੀਨ ਵੀ ਫਿੱਟ ਕਰਦੀ ਹੈ ਜਿੱਥੇ ਤੁਹਾਨੂੰ ਨਿਰਧਾਰਿਤ ਬਾਈਨਰੀ, ਘੱਟ ਰਨਟਾਈਮ ਅਨੁਮਾਨ ਅਤੇ ਵਿਆਪਕ ਕੰਪਾਇਲਰ ਉਪਲਬਧਤਾ ਦੀ ਲੋੜ ਹੋਵੇ—ਛੋਟੀ ਮਾਈਕ੍ਰੋਕੰਟਰੋਲਰ ਤੋਂ ਲੈ ਕੇ ਸਧਾਰਣ CPU ਤੱਕ।
ਜੇ ਤੁਹਾਨੂੰ ਵੱਧ ਤੋਂ ਵੱਧ ਪਹੁੰਚ, ਸਥਿਰ ਇੰਟਰਫੇਸ ਅਤੇ ਪ੍ਰਮਾਣਿਤ ਟੂਲਚੇਨ ਚਾਹੀਦੇ ਹਨ, ਤਾਂ C ਇਕ ਤਰਕਸੰਗਤ ਚੋਣ ਹੈ। ਜੇ ਤੁਹਾਡੀਆਂ ਸੁਰੱਖਿਆਗਤ ਲੋੜਾਂ ਇਜਾਜ਼ਤ ਦਿੰਦੀਆਂ ਹਨ ਅਤੇ ਤੁਹਾਨੂੰ ਨਵੀਨ ਭਾਸ਼ਾ ਦੀਆਂ ਲਾਭਾਂ ਚਾਹੀਦੀਆਂ ਹਨ, ਤਾਂ ਨਵੀਂ ਭਾਸ਼ਾ ਵੀ ਪਰਖ ਕਰਨਯੋਗ ਹੋ ਸਕਦੀ ਹੈ। ਸਭ ਤੋਂ ਵਧੀਆ ਫੈਸਲਾ ਆਮ ਤੌਰ 'ਤੇ ਲਕੜੀ 'ਤੇ ਨਹੀਂ ਤੱਕਦਾ—ਇਹ ਲਕੜੀ, ਟੂਲਿੰਗ ਅਤੇ ਲੰਮੀ ਅਵਧੀ ਦੀ ਰਖਿਆ ਯੋਜਨਾ 'ਤੇ ਆਧਾਰਿਤ ਹੁੰਦਾ ਹੈ।
C "ਖਤਮ ਹੋ ਰਹੀ" ਨਹੀਂ ਹੈ, ਪਰ ਇਸਦਾ ਕੇਂਦਰ ਹੌਲੀ-ਹੌਲੀ ਸਾਫ਼ ਹੋ ਰਿਹਾ ਹੈ। ਜਿੱਥੇ ਸਿੱਧਾ ਨਿਯੰਤਰਣ, ਟਾਈਮਿੰਗ ਅਤੇ ਬਾਈਨਰੀਆਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, C ਜ਼ਿੰਦਾ ਰਹੇਗੀ—ਅਤੇ ਜਿੱਥੇ ਸੁਰੱਖਿਆ ਅਤੇ ਤੇਜ਼ ਇਟਰੈਸ਼ਨ ਮਹੱਤਵਪੂਰਨ ਹਨ, ਉਥੇ ਇਹ ਆਪਣਾ ਹਿੱਸਾ ਘਟਾ ਸਕਦੀ ਹੈ।
C ਸੰਭਵਤ:
ਇਹ ਖੇਤਰ ਹੌਲੀ-ਹੌਲੀ ਵਿਕਸਿਤ ਹੁੰਦੇ ਹਨ, ਵੱਡੇ ਲੈਗਸੀ ਕੋਡਬੇਸ ਹਨ, ਅਤੇ ਉਹ ਇੰਜੀਨੀਅਰਾਂ ਨੂੰ ਸਰਲ ਬਾਈਟਾਂ, ਕਾਲਿੰਗ ਕਨਵੇਂਸ਼ਨਾਂ ਅਤੇ ਫੇਲ ਮੋਡਲਾਂ ਉੱਤੇ ਸੋਚਣ ਦਾ ਇਨਾਮ ਦਿੱੰਦੇ ਹਨ।
ਨਵੇਂ ਐਪ ਵਿਕਾਸ ਲਈ, ਬਹੁਤ ਸਾਰੀਆਂ ਟੀਮਾਂ ਉਹ ਭਾਸ਼ਾਵਾਂ ਪਸੰਦ ਕਰਦੀਆਂ ਹਨ ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਮਜ਼ਬੂਤ ਸੁਰੱਖਿਆ ਗਾਰੰਟੀ ਅਤੇ ਵੱਡਾ ਇਕੋਸਿਸਟਮ ਹੈ। ਯਾਦاشت ਸੁਰੱਖਿਆ ਬੱਗ ਮਹਿੰਗੀ ਪੈਂਦੇ ਹਨ, ਅਤੇ ਆਧੁਨਿਕ ਉਤਪਾਦ ਅਕਸਰ ਤੇਜ਼ ਡਿਲਿਵਰੀ, ਕਨਕਰਨਸੀ ਅਤੇ ਸੁਰੱਖਿਆ-ਮੁੱਖ ਡਿਫਾਲਟਾਂ ਨੂੰ ਤਰਜੀਹ ਦਿੰਦੇ ਹਨ। ਇਹ ਕਾਰਨ ਹਨ ਕਿ ਨੀਵਾਂ-ਸਤਰ ਦੇ ਕੁਝ ਹਿੱਸੇ ਹੁਣ ਸੇਫਰ ਭਾਸ਼ਾਵਾਂ ਵੱਲ ਜਾ ਰਹੇ ਹਨ—ਪਰ C ਉਹ ਨੀਵ ਹੈ ਜਿਸ ਨਾਲ ਉਹ ਇੰਟਰਫੇਸ ਕਰਦੇ ਹਨ।
ਜ਼ਾਹਿਰ ਹੈ ਕਿ ਘੱਟ-ਸਤਰ ਕੋ어 C ਹੋ ਸਕਦੀ ਹੈ, ਪਰ ਟੀਮਾਂ ਨੂੰ ਆਮ ਤੌਰ 'ਤੇ ਆਲੇ-ਦੁਆਲੇ ਸਾਫਟਵੇਅਰ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ: ਵੈੱਬ ਡੈਸ਼ਬੋਰਡ, API ਸਰਵਿਸ, ਡਿਵਾਈਸ ਮੈਨੇਜਮੈਂਟ ਪੋਰਟਲ, ਜਾਂ ਛੋਟੀ ਮੋਬਾਈਲ ਐਪ ਡਾਇਗਨੋਸਟਿਕ ਲਈ। ਉੱਚ-ਸਤਰ ਉਹ ਜਗ੍ਹਾ ਹੈ ਜਿੱਥੇ ਤੇਜ਼ ਇਟਰੈਸ਼ਨ ਅਹਿਮ ਹੁੰਦੀ ਹੈ।
ਜੇ ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਲੇਅਰਾਂ 'ਤੇ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵੱਧਣਾ ਚਾਹੁੰਦੇ ਹੋ ਬਿਨਾਂ ਪੂਰੇ ਪਾਈਪਲਾਈਨ ਨੂੰ ਮੁੜ-ਤਿਆਰ ਕੀਤੇ, ਤਾਂ Koder.ai ਮਦਦਗਾਰ ਹੋ ਸਕਦਾ ਹੈ: ਇਹ ਇੱਕ vibe-coding ਪਲੇਟਫਾਰਮ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ ਚੈਟ ਰਾਹੀਂ ਵੈੱਬ ਐਪ (React), ਬੈਕਐਂਡ (Go + PostgreSQL) ਅਤੇ ਮੋਬਾਈਲ ਐਪ (Flutter) ਤਿਆਰ ਕਰ ਸਕਦੇ ਹੋ—ਜੋ ਇੱਕ ਐਡਮਿਨ UI, ਲੌਗ ਵੀਅਰ, ਜਾਂ ਫਲੀਟ-ਮੈਨੇਜਮੈਂਟ ਸਰਵਿਸ ਜਲਦੀ ਪ੍ਰੋਟੋਟਾਈਪ ਕਰਨ ਲਈ ਲਾਭਦਾਇਕ ਹੈ। ਯੋਜਨਾ ਮੋਡ ਅਤੇ ਸਰੋਤ-ਕੋਡ ਨਿਰਯਾਤ ਓਪਸ਼ਨ ਪ੍ਰੋਟੋਟਾਇਪ ਨੋਟਬੁੱਕ ਤੋਂ ਅਸਲੀ ਕੋਡਬੇਸ ਤੱਕ ਲਿਜਾਣ ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦੇ ਹਨ।
ਮੁਢਲੀ ਗੱਲਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਪਰ ਉਹਨਾਂ ਨੂੰ ਉਨ੍ਹਾਂ ਤਰੀਕਿਆਂ ਨਾਲ ਸਿੱਖੋ ਜਿਵੇਂ ਪ੍ਰੋਫੈਸ਼ਨਲ C ਵਰਤਦੇ ਹਨ:
ਜੇ ਤੁਸੀਂ ਹੋਰ ਸਿਸਟਮ-ਕੇਂਦਰਤ ਲੇਖ ਅਤੇ ਸਿੱਖਣ ਦੇ ਰਸਤੇ ਚਾਹੁੰਦੇ ਹੋ ਤਾਂ /blog 'ਤੇ ਵੇਖੋ।
C ਅਜੇ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਇਹ ਹਾਰਡਵੇਅਰ ਐਕਸੈਸ (ਮੇਮੋਰੀ, ਡੇਟਾ ਲੇਆਊਟ) ਅਤੇ ਚੌੜੀ ਪੋਰਟੇਬਲਟੀ ਨੂੰ ਇਕੱਠੇ ਕਰਦਾ ਹੈ। ਇਹ ਮਿਲਾਪ ਉਸ ਕੋਡ ਲਈ ਵਰਤੋਂਯੋਗ ਹੈ ਜੋ ਮਸ਼ੀਨਾਂ ਨੂੰ ਬੂਟ ਕਰਨ, ਕਠੋਰ ਸੀਮਾਵਾਂ ਹੇਠ ਚਲਣ ਜਾਂ ਪੇਸ਼ਗੀ ਪ੍ਰਦਰਸ਼ਨ ਦਿੰਦਾ ਹੋਵੇ।
C ਅਕਸਰ ਮਿਲਦਾ ਹੈ:
ਜੇਕਰ ਐਪ ਦਾ ਵੱਡਾ ਹਿੱसा ਉੱਚ-ਸਤਰ ਦੀ ਭਾਸ਼ਾ ਵਿੱਚ ਹੈ, ਤਾਂ ਵੀ ਅਕਸਰ ਨੀਵਾਂ ਹਿੱਸਾ C 'ਤੇ ਨਿਰਭਰ ਹੁੰਦਾ ਹੈ।
Dennis Ritchie ਨੇ Bell Labs ਵਿੱਚ C ਬਣਾਈ ਤਾਂ ਜੋ ਸਿਸਟਮ ਸਾਫਟਵੇਅਰ ਲਿਖਣਾ ਵਾਸਤੇ ਇੱਕ ਵਿਵਹਾਰਿਕ ਭਾਸ਼ਾ ਮਿਲੇ: ਮਸ਼ੀਨ ਦੇ ਨੇੜੇ ਰਹਿ ਕੇ, ਪਰ ਅਸਮੀਬਲੀ ਨਾਲੋਂ ਵਧੇਰੇ ਪੋਰਟੇਬਲ ਅਤੇ ਪਠਨਯੋਗ। Unix ਨੂੰ C ਵਿੱਚ ਦੁਬਾਰਾ ਲਿਖਣਾ ਇਕ ਵੱਡਾ ਮਿਸਾਲ ਸੀ — ਇਸ ਨਾਲ Unix ਨੂੰ ਨਵੇਂ ਹਾਰਡਵੇਅਰ ਤੇ ਆਸਾਨੀ ਨਾਲ ਲਿਜਾਇਆ ਜਾ ਸਕਿਆ ਅਤੇ ਸਮੇਂ ਨਾਲ ਵਧਾਇਆ ਜਾ ਸਕਿਆ।
ਸਧਾਰਨ ਸ਼ਬਦਾਂ ਵਿੱਚ, ਪੋਰਟੇਬਲਟੀ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਸੀਂ ਉਹੀ C ਸੋਰਸ ਕੋਡ ਵੱਖ-ਵੱਖ CPU/OS 'ਤੇ ਕੰਪਾਈਲ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਥੋੜ੍ਹੀਆਂ ਹੀ ਬਦਲਾਵਾਂ ਨਾਲ ਇਕੋ ਜਿਹਾ ਵਿਹਾਰ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹੋ। ਆਮ ਤੌਰ 'ਤੇ ਜ਼ਿਆਦਾਤਰ ਕੋਡ ਸਾਂਝਾ ਰਹਿੰਦਾ ਹੈ ਅਤੇ ਹਾਰਡਵੇਅਰ/OS-ਵਿਸ਼ੇਸ਼ ਹਿੱਸਿਆਂ ਨੂੰ ਛੋਟੇ ਮੋਡੀਊਲਾਂ ਵਿੱਚ ਅਲੱਗ ਰੱਖਿਆ ਜਾਂਦਾ ਹੈ।
C ਆਮ ਤੌਰ 'ਤੇ ਤੇਜ਼ ਹੈ ਕਿਉਂਕਿ ਇਹ ਮਸ਼ੀਨ ਓਪਰੇਸ਼ਨਾਂ ਨਾਲ ਨੇੜੇ ਮੈਪ ਹੁੰਦੀ ਹੈ ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਘੱਟ ਰਨਟਾਈਮ ਓਵਰਹੈਡ ਹੁੰਦਾ ਹੈ। ਕੰਪਾਇਲਰ ਲੂਪ, ਅੰਕਗਣਿਤ ਅਤੇ ਮੈਮੋਰੀ ਐਕਸੈਸ ਲਈ ਸਿੱਧਾ ਕੋਡ ਜਨਰੇਟ ਕਰ ਸਕਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਇੰਨਰ ਲੂਪਾਂ ਵਿੱਚ ਮਿਲੀ-ਸੈਕੰਡਾਂ ਦੀ ਵਚਵਾਟ ਘੱਟ ਹੁੰਦੀ ਹੈ।
ਬਹੁਤ ਸਾਰੇ C ਪ੍ਰੋਗਰਾਮ ਮੈਨੁਅਲ ਮੈਮੋਰੀ ਮੈਨੇਜਮੈਂਟ ਵਰਤਦੇ ਹਨ:
malloc)free)ਇਸ ਤੋਂ ਤੁਹਾਨੂੰ ਇਹ ਨਿਰਧਾਰਿਤ ਕਰਨ ਦੀ ਛੂਟ ਮਿਲਦੀ ਹੈ ਕਿ ਮੈਮੋਰੀ ਕਦੋਂ ਅਤੇ ਕਿੰਨੀ ਵਰਤੀ ਜਾਵੇ — ਜੋ ਕਿ ਕਰਨਲ, ਐਂਬੈੱਡਡ ਸਿਸਟਮ ਅਤੇ ਹੌਟ ਪਾਥ ਲਈ ਕੀਮਤੀ ਹੈ। ਵਪਾਰਦਾਇਕ ਦਾ ਨੁਕਸਾਨ ਇਹ ਹੈ ਕਿ ਗਲਤੀਆਂ ਕਰੈਸ਼ ਜਾਂ ਸੁਰੱਖਿਆ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਕਰ ਸਕਦੀਆਂ ਹਨ।
ਕਰਨਲ ਅਤੇ ਡਰਾਈਵਰਾਂ ਨੂੰ:
C ਇਹ ਸਹੂਲਤ ਦਿੰਦੀ ਹੈ: ਨਿਯਮਤ ਟੂਲਚੇਨ ਅਤੇ ਪੇਸ਼ਗੀ ਅਨੁਮਾਨਯੋਗ ਬਾਈਨਰੀਜ਼ ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਕਾਰਗਰ ਹਨ।
ਐਂਬੈੱਡਡ ਡਿਵਾਈਸਾਂ ਦੇ ਟੀਚੇ ਪ੍ਰਮੁੱਖ ਤੌਰ 'ਤੇ ਬਹੁਤ ਘੱਟ RAM/Flash, ਪਾਵਰ ਸੀਮਾਵਾਂ ਅਤੇ ਬਹੁਤ ਖਾਸ ਸਮੇਂ-ਸੰਬੰਧੀ ਲੋੜਾਂ ਹੁੰਦੀਆਂ ਹਨ। C ਛੋਟੇ ਬਾਈਨਰੀ ਬਣਾਉਂਦਾ ਹੈ, ਭਾਰੀ ਰਨਟਾਈਮ ਨਹੀਂ ਮੰਗਦਾ, ਅਤੇ ਮੈਮੋਰੀ-ਮੈਪਡ ਰਜਿਸਟਰਾਂ ਨਾਲ ਸਿੱਧਾ ਕੰਮ ਕਰਨਾ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ — ਇਸ ਲਈ ਇਹ ਫਰਮਵੇਅਰ ਲਈ ਫ਼ਿਟ ਬੈਠਦਾ ਹੈ।
ਅਕਸਰ ਪੂਰੇ ਪ੍ਰੋਡਕਟ ਨੂੰ C ਵਿੱਚ ਲਿਖਣ ਦੀ ਥਾਂ, ਟੀਮਾਂ:
ਇਸ ਤਰ੍ਹਾਂ ਵਿਕਾਸ ਤੇਜ਼ ਰਹਿੰਦਾ ਹੈ ਅਤੇ ਸਿਰਫ਼ ਉਨ੍ਹਾਂ ਹਿੱਸਿਆਂ ‘ਤੇ ਧਿਆਨ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ ਜਿੱਥੇ ਲਾਭ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਹੁੰਦਾ ਹੈ।
ਅਸਲ-ਜਿੰਦਗੀ ਦੀਆਂ ਹਲਾਂ ਵਿੱਚ ਸੁਰੱਖਿਆ ਵਧਾਉਣ ਲਈ ਅਮਲੀ ਤਰੀਕੇ ਹਨ:
-Wall -Wextra) ਨਾਲ ਕੰਪਾਇਲ ਕਰੋ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਗੰਭੀਰਤਾ ਨਾਲ ਲਓਇਹ ਤਰੀਕੇ ਆਮ ਤਰ੍ਹਾਂ ਕਈ ਅੰਸ਼ਾਂ ਦੇ ਖਤਰੇ ਘਟਾ ਸਕਦੇ ਹਨ।