ऐरे पैरामीटर और कॉलर में दिखने वाले बदलाव
कॉपी हुआ आर्ग्युमेंट भी साझा स्टोरेज बता सकता है
बुनियादी पाठ में देखा कि पूर्णांक पैरामीटर बदलने से कॉलर का पूर्णांक चर नहीं बदलता। पॉइंटर वाले पाठ में फिर देखा कि पॉइंटर मान की कॉपी से एक ऑब्जेक्ट तक दो रास्ते बने रह सकते हैं। दोनों बातें जोड़ें: helper को पॉइंटर के मान की कॉपी मिल सकती है और वह उससे कॉलर के ऐरे का तत्व बदल सकता है।
C में आर्ग्युमेंट के मान की कॉपी बनने वाला तरीका नहीं बदला है। केवल दिए जाने वाले मान का प्रकार और बाद के लेखन से चुना जाने वाला ऑब्जेक्ट अलग है।
इस पाठ के अंत तक आप स्पष्ट लंबाई के साथ ऐरे कॉल का ट्रेस करेंगे, बदले तत्वों को बदले helper-पैरामीटरों से अलग रखेंगे और helper के अभिगम सही होने की शर्तें बताएँगे। आप फ़ंक्शन से लौटे मान को कॉलर में दिखने वाले लेखन से भी अलग पहचानेंगे।
पहले से आवश्यक बातें: स्वीकृत scalar फ़ंक्शन/कॉपी पाठ, ऐरे और सही इंडेक्स, शुरुआती हिस्से की जाँच तथा पॉइंटर के लक्ष्य का रिकॉर्ड। अभी पॉइंटर अंकगणित, sizeof, allocation या पॉइंटर के पॉइंटर का उपयोग नहीं है।
C11 पढ़ाने के लिए हमारा चुना संस्करण है। दिखाए गए सभी वास्तविक ऐरे धनात्मक स्थिर आकार के हैं और उनके int तत्व इनिशियलाइज़ हैं। निश्चित व्यवहार वाली कॉल में जीवित उपयुक्त स्टोरेज और सही चुनी लंबाई दी जाती है। हर अंकगणितीय परिणाम −32767 से 32767 के भीतर है। हर पूरा प्रोग्राम अलग उदाहरण है। स्पष्ट असुरक्षित अभ्यास-अंश केवल वर्गीकरण के लिए है; उसे कंपाइल या निष्पादित न करें।
कॉल और पैरामीटर को अलग पढ़ें
कॉलर में int marks[4] = {3, 1, 4, 2}; वास्तविक चार तत्वों वाला ऐरे बनाता है। कॉल add_to_prefix(marks, used, 2) में व्यंजक marks उसके पहले तत्व का पॉइंटर देता है। ऐरे ऑब्जेक्ट कॉलर में ही रहता है; कॉल उसकी तत्व-दर-तत्व कॉपी नहीं बनाती।
helper की पैरामीटर सूची में int values[] ऐसा पैरामीटर घोषित करता है जिसका प्रकार int के पॉइंटर में समायोजित होता है। यहाँ इस्तेमाल हुए साधारण पैरामीटर रूप में इसे int *values भी लिख सकते हैं। यह पैरामीटर रूप कॉलर की वास्तविक ऐरे-घोषणा से अलग है। helper को पॉइंटर मान मिलता है, नया ऐरे नहीं जिसकी लंबाई खाली कोष्ठकों से पढ़ी जा सके।
values[i] उस पॉइंटर के रास्ते संबंधित तत्व तक पहुँचता है। यहाँ की कॉल में पॉइंटर कॉलर के ऐरे का पहला तत्व बताता है और कॉलर अलग से सही length देता है। पॉइंटर मान में उपलब्ध तत्वों की गिनती अपने-आप नहीं जुड़ी होती। अगले पाठ में ऐरे के आकार वाले व्यंजक पढ़ेंगे; helper के पैरामीटर की लिखावट देखकर लंबाई न गढ़ें।
पूर्णांक आर्ग्युमेंट पहले जैसे ही काम करते हैं। length को कॉलर के used का वर्तमान मान मिलता है और delta को 2। वे helper के अलग पैरामीटर हैं। यहाँ आर्ग्युमेंट व्यंजकों में कोई side effect नहीं है, इसलिए उनका मूल्यांकन-क्रम परिणाम नहीं बदल सकता।
ऐसा helper जो कोई मान वापस नहीं देता
void add_to_prefix(...) में void कहता है कि कॉल कोई परिणाम-मान नहीं देती। हम उसे स्टेटमेंट की तरह लेते हैं: add_to_prefix(marks, used, 2);। उसका उद्देश्य body के लेखन हैं, किसी चर में रखने के लिए लौटने वाली संख्या नहीं।
इस void helper के अंतिम ब्रेस तक पहुँचने पर नियंत्रण कॉलर में लौटता है। कॉलर अगला स्टेटमेंट चलाता है। यह उन पूर्णांक helper से अलग है जो स्पष्ट रूप से संख्या लौटाते हैं; दोनों तरह का लौटना अपने-आप प्रिंट करना नहीं है।
हल किया हुआ उदाहरण 1 शुरुआती हिस्सा बदलें, कॉलर की लंबाई नहीं
कॉलर के प्रिंट होने वाले पाँच पूर्णांकों में कौन-से बदलते हैं?
#include <stdio.h>
void add_to_prefix(int values[], int length, int delta)
{
for (int i = 0; i < length; i++) {
values[i] += delta;
}
length = 0;
}
int main(void)
{
int marks[4] = {3, 1, 4, 2};
int used = 3;
add_to_prefix(marks, used, 2);
printf("%d %d %d %d | %d\n",
marks[0], marks[1], marks[2], marks[3], used);
return 0;
}कॉल से पहले कॉलर के वास्तविक ऐरे का एक ही चित्र बनाएँ: marks = {3, 1, 4, 2} और कॉलर का used = 3। helper में प्रवेश पर अलग पैरामीटर रिकॉर्ड जोड़ें: values → marks[0], length = 3, delta = 2। values के लिए दूसरा चार-तत्वों वाला ऐरे न बनाएँ।
| helper का बिंदु | कॉलर का ऐरे marks | helper का length | कॉलर का used |
|---|---|---|---|
| पहली लूप-जाँच से पहले | {3, 1, 4, 2} | 3 | 3 |
| इंडेक्स 0 की body के बाद | {5, 1, 4, 2} | 3 | 3 |
| इंडेक्स 1 की body के बाद | {5, 3, 4, 2} | 3 | 3 |
| इंडेक्स 2 की body के बाद | {5, 3, 6, 2} | 3 | 3 |
| इंडेक्स 3 पर गलत जाँच के बाद | {5, 3, 6, 2} | 3 | 3 |
length = 0 के बाद | {5, 3, 6, 2} | 0 | 3 |
लूप इंडेक्स 0, 1 और 2 तक जाता है। हर लेखन कॉलर के संबंधित तत्व तक पहुँचता है। चौथा तत्व 2 रहता है, क्योंकि वह चुने शुरुआती हिस्से के बाहर है। तीन body और चार लूप-जाँच हैं।
अंतिम length = 0 केवल helper का पूर्णांक पैरामीटर बदलता है। वह न ऐरे मिटाता है, न कॉलर के used में असाइन करता है। helper समाप्त होने पर कॉलर 5 3 6 2 | 3 और फिर नई पंक्ति प्रिंट करता है।
helper के चलते समय ही तत्वों के बदलाव मूल स्टोरेज में लिखे जा चुके होते हैं। वे लौटते समय किसी खास “copy back” क्रिया की प्रतीक्षा नहीं करते। कॉल समाप्त होने पर helper के अपने पैरामीटर ऑब्जेक्ट का जीवनकाल समाप्त होता है; कॉलर का ऐरे main में जीवित रहता है और नए मान रखता है।
ऐरे को अपरिवर्तित बताना गलत रूप से मानता है कि helper ने ऐरे की निजी कॉपी पर काम किया। अंतिम तत्व को 4 करना चुने शुरुआती हिस्से से एक अतिरिक्त तत्व संसाधित करता है। कॉलर के used को 0 बताना अलग पूर्णांक पैरामीटर का बदलाव वापस कॉपी करता है। हर गलती किसी अलग ऑब्जेक्ट या सीमा को मिलाती है।
helper के पास ही अभिगम की शर्तें लिखें
यहाँ add_to_prefix की कॉल के लिए चाहिए:
- जीवित और इनिशियलाइज़ किए गए पूर्णांक ऐरे के पहले तत्व का पॉइंटर
- शून्य से वास्तविक तत्वों की संख्या तक का
length - helper के तय उद्देश्य के अनुसार चुने तत्व बदलने की अनुमति
- हर वास्तव में होने वाले जोड़ का परिणाम
intमें समाना
length = 0 पर पहली लूप-जाँच गलत होती है और कोई तत्व पढ़ा या लिखा नहीं जाता। तब भी वास्तविक ऐरे दिया जाता है; हम null-array की नई व्यवस्था या शून्य आकार का ऐरे नहीं ला रहे। हल किए प्रोग्राम में लंबाई 4 होने पर चारों तत्व बदलेंगे। लंबाई 5 उसकी चार-तत्व क्षमता के बाहर होगी और ऐसी कॉल अनुमत नहीं है।
केवल पॉइंटर पैरामीटर और दी हुई लंबाई से helper वास्तविक क्षमता अपने-आप नहीं जान या जाँच सकता। गलत लंबाई लिखने से कॉलर का ऐरे बड़ा नहीं होता। ये स्पष्ट पूर्वशर्तें हैं, C द्वारा हर कॉल पर चुपचाप की जाने वाली जाँचें नहीं।
हल किया हुआ उदाहरण 2 स्थानीय पैरामीटर का लक्ष्य बदलें
अब दो पूर्णांक लक्ष्य दें। helper के पॉइंटर पैरामीटर में नया मान रखने से क्या कॉलर के पॉइंटर चर का लक्ष्य भी बदल जाएगा?
#include <stdio.h>
void retarget_then_write(int *target, int *other)
{
target = other;
*target = 9;
}
int main(void)
{
int left = 2;
int right = 7;
int *selected = &left;
retarget_then_write(selected, &right);
printf("%d %d %d\n", left, right, *selected);
return 0;
}- कॉल से पहले कॉलर:
left = 2,right = 7औरselected → left - helper में प्रवेश: उसके अलग
target → leftऔरother → rightहैं। पॉइंटर आर्ग्युमेंट के मान इन पैरामीटरों में कॉपी हुए हैं target = otherhelper केtargetकोrightकी ओर करता है। कॉलर काselectedअभी भीleftबताता है; दोनों पूर्णांक नहीं बदले*target = 9अबrightमें लिखकर उसे 9 करता है- लौटने पर कॉलर का
selected → leftअभी भी 2 पढ़ता है। आउटपुट:2 9 2, फिर नई पंक्ति
ट्रेस में तीन पॉइंटर चर हैं: कॉलर का selected और helper के पैरामीटर target तथा other। लक्ष्य साझा होने से ये चर मिलकर एक नहीं हो जाते। target = other एक स्थानीय पॉइंटर मान बदलता है। *target = 9 उस स्थानीय पॉइंटर मान से चुना गया पूर्णांक बदलता है।
गलत परिणाम 2 9 9 helper का पॉइंटर असाइनमेंट कॉलर के selected तक पहुँचा देता है। गलत परिणाम 9 7 9 लेखन से पहले बदले लक्ष्य को भूलता है। गलत परिणाम 2 7 2 कॉलर के right में हुए वास्तविक लेखन को छोड़ता है। हर पॉइंटर चर का अलग चित्र बनाने से तीनों गलतियाँ दूर होती हैं।
यहाँ हम helper से कॉलर के पॉइंटर चर में नया मान रखना नहीं सिखा रहे। उसके लिए अलग इंटरफ़ेस चाहिए। साधारण पॉइंटर आर्ग्युमेंट को कॉलर के पॉइंटर चर का अपने-आप मिला संदर्भ न मानें।
बताएँ कि फ़ंक्शन क्या लौटाता और क्या बदलता है
केवल तत्व जोड़ने वाला फ़ंक्शन ऐरे में लिखे बिना पूर्णांक लौटा सकता है। दूसरा फ़ंक्शन तत्व बदल सकता है और कोई मान नहीं लौटा सकता। फ़ंक्शन स्टोरेज बदलने के साथ मान भी लौटा सकता है, लेकिन केवल नाम या पैरामीटर सूची में कोष्ठक देखकर इनमें से कोई व्यवहार तय नहीं होता। body और बताई शर्तें पढ़ें।
हर कॉल में चार बातें रखें: आर्ग्युमेंट के मान, helper के अलग पैरामीटर, लेखन से पहुँचे कॉलर ऑब्जेक्ट और कोई लौटा हुआ मान। scalar फ़ंक्शन पाठ की तरह कॉलर और helper के अलग अवस्था-रिकॉर्ड बनाएँ; जहाँ आवश्यक हो लक्ष्य के तीर जोड़ें।
हल से पहले अभ्यास
ये चार मौलिक अभ्यास हैं और इनके अंक नहीं हैं। कॉल का क्रम, लक्ष्य की पहचान और चुनी लंबाई सामने रखें। प्रश्न 4 जानबूझकर सीमा तोड़ता है और केवल वर्गीकरण तथा सुधार के लिए है।
अभ्यास 1 केवल पढ़कर गणना, फिर बदलाव
आउटपुट और अंतिम ऐरे दें। कौन-सा helper ऐरे बदलता है और क्या बाद में सहेजा गया लौटा मान before भी बदलता है?
#include <stdio.h>
int sum_prefix(int values[], int length)
{
int total = 0;
for (int i = 0; i < length; i++) {
total += values[i];
}
return total;
}
void clear_first(int values[], int length)
{
if (length > 0) {
values[0] = 0;
}
}
int main(void)
{
int a[3] = {3, 4, 6};
int before = sum_prefix(a, 3);
clear_first(a, 2);
int after = sum_prefix(a, 2);
printf("%d %d %d\n", before, after, a[2]);
return 0;
}सही चुनी लंबाई लें। यहाँ “केवल पढ़ना” sum_prefix के वास्तविक काम का वर्णन है; यह नया type qualifier नहीं है।
अभ्यास 2 स्थानीय लंबाई बदलने से helper का अपना लूप बदलता है
दिखाए गए चार-तत्वों वाले ऐरे के लिए प्रोग्राम का व्यवहार निश्चित है, लेकिन helper का तय उद्देश्य ठीक माँगा हुआ शुरुआती हिस्सा भरना है। वास्तविक आउटपुट दें, उद्देश्य से जुड़ी गलती पहचानें और एक असाइनमेंट हटाकर सुधारें। कॉलर का requested नहीं बदलना चाहिए।
#include <stdio.h>
void fill_prefix(int values[], int length, int value)
{
length = 2;
for (int i = 0; i < length; i++) {
values[i] = value;
}
}
int main(void)
{
int a[4] = {2, 4, 6, 8};
int requested = 1;
fill_prefix(a, requested, 9);
printf("%d %d %d %d | %d\n",
a[0], a[1], a[2], a[3], requested);
return 0;
}अभ्यास 3 लक्ष्य के मान बदलें और साझा लक्ष्य भी जाँचें
दोनों कॉल का ट्रेस करें। दूसरी कॉल एक ही लक्ष्य दो बार देती है। समझाएँ कि इस खास helper में इससे समस्या होती है या नहीं और आउटपुट दें।
#include <stdio.h>
void swap_values(int *left, int *right)
{
int saved = *left;
*left = *right;
*right = saved;
}
int main(void)
{
int x = 4;
int y = 9;
swap_values(&x, &y);
swap_values(&x, &x);
printf("%d %d\n", x, y);
return 0;
}दोनों दिए लक्ष्य जीवित इनिशियलाइज़ किए गए पूर्णांक हैं। यह न मानें कि पॉइंटर वाले सभी helper को अलग लक्ष्य चाहिए या वे हमेशा साझा लक्ष्य स्वीकार करते हैं; इस helper के स्टेटमेंट जाँचें।
अभ्यास 4 कॉलर ज़रूरत से बड़ी लंबाई देता है
नीचे का अंश जानबूझकर असुरक्षित है। मानें कि दिखाई कॉल main के भीतर है और helper पहले परिभाषित है। उसे कंपाइल या निष्पादित न करें।
void add_one(int values[], int length)
{
for (int i = 0; i < length; i++) {
values[i] += 1;
}
}
int a[2] = {3, 7};
add_one(a, 3);पहला गलत इंडेक्स पहचानें जहाँ लूप पहुँचने की कोशिश करेगा। क्या helper का values[] पैरामीटर दी गई लंबाई के लिए पर्याप्त तत्व बना देता है? केवल कॉल सुधारें, ताकि helper पूरे वास्तविक ऐरे के तत्व एक-एक बढ़ाए; फिर सुधरे प्रोग्राम के दोनों तत्वों का आउटपुट दें।
पूरे हल और गलत उत्तरों का कारण
अभ्यास 1 का हल
पहली sum_prefix कॉल को a तक पहुँच और लंबाई 3 मिलती है। इंडेक्स 0, 1 और 2 देखने पर उसके स्थानीय योग 3, 7 और 13 होते हैं। कोई तत्व बदले बिना वह 13 लौटाती है; कॉलर का before = 13 होता है।
clear_first(a, 2) को कॉपी हुआ पॉइंटर मान और स्थानीय लंबाई 2 मिलती है। उसकी शर्त सही है, इसलिए वह a[0] में 0 लिखती है। वह दोनों चुने तत्व साफ़ नहीं करती: body में केवल इंडेक्स 0 पर एक लेखन है। कॉलर का ऐरे अब {0, 4, 6} है।
दूसरी sum कॉल लंबाई 2 लेती है, इसलिए उसका नया स्थानीय योग पहले 0, फिर 4 होता है। वह 4 लौटाकर after में देती है। कॉलर का सहेजा पूर्णांक before 13 रहता है। आउटपुट: 13 4 6, फिर नई पंक्ति।
4 4 6 सहेजे लौटे मान को बाद के ऐरे बदलावों के साथ बदलता है। 13 10 6 दूसरी लंबाई 2 होने पर भी पूरा ऐरे जोड़ता है। 13 0 6 मानता है कि clear_first पूरा शुरुआती हिस्सा भरता है, जबकि body केवल पहला तत्व लिखती है। फ़ंक्शन की शर्तें और वास्तविक body मेल खानी चाहिए; केवल नाम से गायब काम नहीं जुड़ जाते।
अभ्यास 2 का हल
प्रवेश पर helper का length 1 है और कॉलर का requested भी 1 है। स्थानीय असाइनमेंट helper का length 2 करता है। इसलिए लूप इंडेक्स 0 और 1 पर 9 लिखता है। दोनों इंडेक्स इस चार-तत्वों वाले ऐरे में हैं, इसलिए दिखाए निष्पादन का व्यवहार निश्चित है। अंतिम ऐरे {9, 9, 6, 8} है और कॉलर का requested 1 रहता है। आउटपुट: 9 9 6 8 | 1, फिर नई पंक्ति।
स्टोरेज की सीमा के भीतर रहते हुए भी helper ने माँगे शुरुआती हिस्से वाली शर्त तोड़ी है। व्यवहार निश्चित होना और व्यवहार उद्देश्य के अनुसार होना अलग प्रश्न हैं। कॉपी हुए पैरामीटर का नियम helper को अपनी बदली स्थानीय लंबाई बाद के स्टेटमेंट में इस्तेमाल करने से नहीं रोकता।
length = 2; हटाएँ। पूरा सुधरा प्रोग्राम है:
#include <stdio.h>
void fill_prefix(int values[], int length, int value)
{
for (int i = 0; i < length; i++) {
values[i] = value;
}
}
int main(void)
{
int a[4] = {2, 4, 6, 8};
int requested = 1;
fill_prefix(a, requested, 9);
printf("%d %d %d %d | %d\n",
a[0], a[1], a[2], a[3], requested);
return 0;
}सुधरा helper लंबाई 1 रखता है, केवल a[0] लिखता है और इंडेक्स 1 पर गलत जाँच से रुकता है। वह 9 4 6 8 | 1 और फिर नई पंक्ति प्रिंट करता है। कॉलर के requested को 2 करना helper सुधारने के बजाय कॉलर की माँग बदल देगा। मूल असाइनमेंट को कॉलर के requested का बदलाव मानने पर अंतिम | 2 वाला गलत उत्तर मिलेगा।
अभ्यास 3 का हल
पहली कॉल: helper का left → x, right → y; saved में x = 4 की कॉपी है। लेखन *left = *right से x = 9 होता है, फिर *right = saved से y = 4। किसी पॉइंटर पैरामीटर का लक्ष्य नहीं बदलता। लौटने पर कॉलर में x = 9, y = 4 है।
दूसरी कॉल: helper के दोनों पैरामीटर x बताते हैं। नया स्थानीय saved 9 है। पहला लेखन उसी x को पढ़कर उसी में लिखता है, इसलिए 9 रहता है। दूसरा सहेजा हुआ 9 वहीं लिखता है, इसलिए फिर भी मान वही है। ये अलग, क्रमबद्ध स्टेटमेंट हैं, परस्पर टकराते बिना-क्रम वाले अपडेट नहीं। इस खास helper में दोनों दिए लक्ष्य एक ही ऑब्जेक्ट हो सकते हैं।
आउटपुट: 9 4, फिर नई पंक्ति। अंतिम जोड़ी 4 9 बताना y के साथ एक और अदला-बदली गढ़ता है, जबकि दूसरी कॉल उसका उपयोग करती ही नहीं। केवल साझा लक्ष्य होने से अपने-आप त्रुटि बताना aliasing के बारे में बहुत व्यापक निष्कर्ष है: सुरक्षा क्रियाओं और helper की शर्तों पर निर्भर करती है।
अभ्यास 4 का हल
कॉलर के ऐरे में ठीक दो तत्व हैं, जिनके इंडेक्स 0 और 1 हैं। helper को उस ऐरे तक पहुँच और अलग पूर्णांक लंबाई 3 मिलती है। इंडेक्स 2 पर values[2] += 1 ऐरे की सीमा के बाहर तत्व तक पहुँचने की कोशिश करेगा। पैरामीटर की घोषणा तीसरा तत्व नहीं बनाती। अंश में अपरिभाषित व्यवहार है; उसके लिए C11 का निर्धारित आउटपुट या गारंटी वाला “कुछ तत्व बदला हुआ” अंतिम ऐरे न बताएँ।
add_one(a, 2); लें। पूरा सुरक्षित प्रोग्राम है:
#include <stdio.h>
void add_one(int values[], int length)
{
for (int i = 0; i < length; i++) {
values[i] += 1;
}
}
int main(void)
{
int a[2] = {3, 7};
add_one(a, 2);
printf("%d %d\n", a[0], a[1]);
return 0;
}सही कॉल 3 को 4 और 7 को 8 करती है, फिर इंडेक्स 2 पर बिना तत्व तक पहुँचे लूप-जाँच गलत हो जाती है। आउटपुट: 4 8, फिर नई पंक्ति। लंबाई 1 सुरक्षित होगी, लेकिन पूरे वास्तविक ऐरे को एक-एक नहीं बढ़ाएगी। लंबाई 3 को केवल “by value” भेजे जाने के कारण सही मानना, गिनती की कॉपी और उसकी वैधता-जाँच को मिलाता है।
आगे बढ़ने से पहले
समझाएँ कि कॉपी हुआ पॉइंटर मान तत्व बदलने दे सकता है, जबकि कॉपी हुई लंबाई अलग रहती है। फिर पॉइंटर दोबारा असाइन करने और उसके रास्ते लेखन की तुलना करें। अगले पाठ में ऐरे के भीतर पॉइंटर आगे-पीछे करेंगे और मशीन के बाइट आकार माने बिना वास्तविक ऐरे की तत्व-गिनती को पॉइंटर पैरामीटर के आकार से अलग रखेंगे।
स्रोत टिप्पणी
व्याख्याएँ, कोड, ट्रेस और अभ्यास मौलिक हैं। पहले दो प्रोग्राम इस मॉड्यूल की पहले की मौलिक योजना के प्रोटोटाइप को विकसित करते हैं। C के तथ्यों की जाँच WG14 N1570 C11 समिति-ड्राफ्ट से की गई: ऐरे रूपांतरण §6.3.2.1p3; पैरामीटर समायोजन §6.7.6.3p7; कॉपी हुए आर्ग्युमेंट §6.5.2.2p4; डिरेफ़रेंस §6.5.3.2p4; इंडेक्स वाले अभिगम और सीमाएँ §§6.5.2.1p2, 6.5.6p8; असाइनमेंट §6.5.16.1p2; void व्यंजक §6.3.2.2p1 और फ़ंक्शन का पूरा होना §6.9.1; automatic जीवनकाल §6.2.4। संदर्भ: https://open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
C11 पढ़ाने के लिए चुना संस्करण है, GATE की बताई भाषा-संस्करण शर्त का दावा नहीं। यह कॉल और साझा ऐरे स्टोरेज का सीमित पाठ है, पूरी C या GATE CS की तैयारी नहीं।
सूत्र और नियम
- यहाँ की कॉल में ऐरे आर्ग्युमेंट पहले तत्व का पॉइंटर देता है; वास्तविक ऐरे helper में कॉपी नहीं होता
- साधारण
int values[]पैरामीटर पॉइंटर पैरामीटर में समायोजित होता है; वह नया स्थानीय ऐरे नहीं है - सही चुनी लंबाई स्पष्ट दें। पॉइंटर मान में अपने-आप तत्वों की गिनती नहीं होती
- पैरामीटरों को मानों की कॉपी मिलती है, तब भी जब वे मान पॉइंटर हों
values[i]या*targetमें लेखन पहचाने गए कॉलर ऑब्जेक्ट तक पहुँचता है, जब वह ऑब्जेक्ट साझा और जीवित है- helper का पॉइंटर पैरामीटर दोबारा असाइन करने से कॉलर का पॉइंटर चर दोबारा असाइन नहीं होता
- helper की पूर्णांक लंबाई बदलने से उसके बाद के स्थानीय निर्णय बदलते हैं, कॉलर का लंबाई-चर नहीं
- void helper कोई परिणाम-मान नहीं लौटाता; फिर भी उसके लेखन कॉलर को दिख सकते हैं
- हर कॉल-ट्रेस में लौटे मान, पैरामीटर अपडेट और साझा ऑब्जेक्ट के लेखन अलग रखें
- क्षमता, जीवनकाल, अनुमत बदलाव और अंकगणित की शर्तें बताएँ; न पैरामीटर का नाम, न दी गई लंबाई उन्हें अपने-आप जाँचती है
इस पाठ के नोट्स
प्रगति सहेजने के लिए साइन इन करें। साइन इन