user-0 提问: 再来一发！     C语言菜鸟的第二个问题。

回复:
user: user-1
content: question1：是s（）函数结束后，函数内定义的变量会被释放 question2：【3】是代表第四个元素

user: user-2
content: 至于第二个问题，对于指针（数组名） ： *（p+数字）==p[数字]

user: user-2
content: 我再次在main 函数中以指针的方式调用， 它是不是会重新再次为该数组分配一些内存?         在main函数中，不能调用 s 函数中的数组，因为在s 函数结束后会被回收

user: user-2
content: f函数运行结束后，s中的数组就不能再被其他函数使用，因为被释放了。      这个问题是这样的，在f函数创建了一个新的指针变量 praa ，在  f  函数以外你不能用praa 来对它所指向的数组操作，因为他是局部变量，在f 函数结束时已被回收。但是，在s 函数中，你依旧可以对数组进行操作，失效的只是f 函数中的指针变量，而不是数组（数组不是在f 函数中创建的）

user: user-3
content: 看来确实是基础没打牢。先找书理解下程序是怎么运行的，弄清函数调用与返回的过程，然后再来看数组和指针的问题吧

user: user-4
content: 引用在上面那段代码中，  为什么  parr【3】 直接就是 数组的第三个元素，             我所知道的表示方法有， parr是个地址，  *（parr+2）代表第三个元素。 还有其他的表示方法吗？             还有为什么  parr【3】  也代表第三个元素呢？   是个规定吗？ parr[3]不是第三个元素，是第四个元素。*(parr+2)和parr[2]得到的运行结果是相同的，但是前者的运行效率高，至于为什么，再往底层走！

user: user-4
content: 问题一：引用f 函数运行结束后， s 函数初始化的数组是不是就会被释放掉？  如果在f 函数运行结束后【内存释放了】，   我再次在main 函数中以指针的方式调用， 它是不是会重新再次为该数组分配一些内存? 函数f运行介绍时候，也就是return的时候，那么程序将要执行s函数的printf()语句，这时候你定义的数组shuzu并没有被释放掉，不然你输出shuzu[3]的时候，就输不出值了。当出现执行了printf("", shuzu[3]);之后，返回到main函数，这时候，你的s函数所定义的所有变量都讲会消失。包括你的数组shuzu[5],在内存中就被释放掉了。   你的变量都是定义在栈区里面的，会自动释放，如果你的变量定义在堆区里面，不手动释放，变量是不会被释放的，会导致内存的泄露，因此，你可以写一个小病毒，故意申请了堆区的很多变量，不去释放它，导致运行你的程序的机器内存耗费越来越大，最后死机！ 内存图画得见笑了。

user: user-5
content: s函数执行完毕后，数组的内存没有被释放，只是没有指针指到之前数组的内存了而已，后面会被覆盖的。 parr[3]和shuzu[3]指向的是同一块内存，也就是是同一个值，原因是这个中括号[]是一个变址运算符，并且最开始数组的首地址传给了parr。

user: user-6
content: 问题2的回答，如果你看过《C和指针》就明白了，[ ]等价于*（），int array[5];   2[array]其实就是*（2+arry),有意思的是，数组下标还可以是负数。《c专家编程》关于数组和指针的关系用了3章讨论，可以好好看下。

user: user-7
content: hk是正确的

user: user-8
content: 引用 8 楼 u013163178 的回复:请参考《C专家编程》  +1， 这本书对你的问题有非常详尽的描述，堪称c语言学习神书

user: user-9
content: 请参考《C专家编程》

user: user-10
content: 到百度上搜关键字。 问题1：“局部变量”  “作用域”  “生命周期”。 问题2：“数组名”   “指针”的关系。 看完后应该就明白了。

user: user-11
content: .........没注意你在f里把shuzu[3]改成88了，这样显示的是88.如果你把parr[3]注释掉，显示出来的应该是4.

user: user-11
content: parr[3]应该是第4个元素，你搞错了。显示出来的值应该是4，不是3.

user: user-11
content: 引用f函数运行结束后，s中的数组就不能再被其他函数使用，因为被释放了。  这个问题听起来不知所云？     原谅我表达能力不强！   下面更详细一点：  f 函数运行结束后， s 函数初始化的数组是不是就会被释放掉？  如果在f 函数运行结束后【内存释放了】， 这家伙果然不明不白，因为shuzu是在s函数里声明的，s函数运行完后shuzu就被销毁了，当然不能用了，但是在f函数运行完后shuzu还是能用的，因为s函数还没运行完。你那句printf("%d\n",shuzu[3]);不就是在f函数之后使用的shuzu么。

user: user-12
content: 栈中的基本变量退出其作用域时，没有谁执行一段代码去释放/销毁/析构它所占用的内存，仅仅是没人再去理会的留在当前栈顶上方的若干遗留下来可被后续压栈操作覆盖的无用数据而已。 而栈中的类变量退出其作用域时，会自动执行其析构函数，……

user: user-12
content: 理解和讨论之前请先学会如何观察！

user: user-12
content: 计算机组成原理→DOS命令→汇编语言→C语言（不包括C++）、代码书写规范→数据结构、编译原理、操作系统→计算机网络、数据库原理、正则表达式→其它语言（包括C++）、架构……  对学习编程者的忠告： 多用小脑和手，少用大脑、眼睛和嘴，会更快地学会编程！ 眼过千遍不如手过一遍！ 书看千行不如手敲一行！ 手敲千行不如单步一行！ 单步源代码千行不如单步Debug版对应汇编一行！ 单步Debug版对应汇编千行不如单步Release版对应汇编一行！  VC调试时按Alt+8、Alt+7、Alt+6和Alt+5,打开汇编窗口、堆栈窗口、内存窗口和寄存器窗口看每句C对应的汇编、单步执行并观察相应堆栈、内存和寄存器变化，这样过一遍不就啥都明白了吗。 对VC来说，所谓‘调试时’就是编译连接通过以后，按F10或F11键单步执行一步以后的时候，或者在某行按F9设了断点后按F5执行停在该断点处的时候。 （Turbo C或Borland C用Turbo Debugger调试,Linux或Unix下用GDB调试时,看每句C对应的汇编并单步执行观察相应内存和寄存器变化。）  想要从本质上理解C指针，必须学习汇编以及C和汇编的对应关系。 从汇编的角度理解和学习C语言的指针，原本看似复杂的东西就会变得非常简单！ 指针即地址。“地址又是啥？”“只能从汇编语言和计算机组成原理的角度去解释了。” 但我又不得不承认：  有那么些人喜欢或者适合用“先具体再抽象”的方法学习和理解复杂事物；  而另一些人喜欢或者适合用“先抽象再具体”的方法学习和理解复杂事物。 而我本人属前者。  不要企图依赖输出指针相关表达式...的值【比如printf("%p\n",...);或者cout<<...】来理解指针的本质， 而要依赖调试时的反汇编窗口中的C/C++代码【比如void *p=(void *)(...);】及其对应汇编指令以及内存窗口中的内存地址和内存值来理解指针的本质。  这辈子不看内存地址和内存值；只画链表、指针示意图，画堆栈示意图，画各种示意图，甚至自己没画过而只看过书上的图……能从本质上理解指针、理解函数参数传递吗？本人深表怀疑！ 这辈子不种麦不收麦不将麦粒拿去磨面；只吃馒头、吃面条、吃面包、……甚至从没看过别人怎么蒸馒头，压面条，烤面包，……能从本质上理解面粉、理解面食吗？本人深表怀疑！！  提醒： “学习用汇编语言写程序” 和 “VC调试(TC或BC用TD调试)时按Alt+8、Alt+7、Alt+6和Alt+5,打开汇编窗口、堆栈窗口、内存窗口和寄存器窗口看每句C对应的汇编、单步执行并观察相应堆栈、内存和寄存器变化，这样过一遍不就啥都明白了吗。 （Linux或Unix下可以在用GDB调试时,看每句C对应的汇编并单步执行观察相应内存和寄存器变化。） 想要从本质上理解C指针，必须学习C和汇编的对应关系。” 不是一回事！  不要迷信书、考题、老师、回帖； 要迷信CPU、编译器、调试器、运行结果。 并请结合“盲人摸太阳”和“驾船出海时一定只带一个指南针。”加以理解。 任何理论、权威、传说、真理、标准、解释、想象、知识……都比不上摆在眼前的事实！  有人说一套做一套，你相信他说的还是相信他做的？ 其实严格来说这个世界上古往今来所有人都是说一套做一套，不是吗？  不要写连自己也预测不了结果的代码！  电脑内存或文件内容只是一个一维二进制字节数组及其对应的二进制地址； 人脑才将电脑内存或文件内容中的这个一维二进制字节数组及其对应的二进制地址的某些部分看成是整数、有符号数/无符号数、浮点数、复数、英文字母、阿拉伯数字、中文/韩文/法文……字符/字符串、汇编指令、函数、函数参数、堆、栈、数组、指针、数组指针、指针数组、数组的数组、指针的指针、二维数组、字符点阵、字符笔画的坐标、黑白二值图片、灰度图片、彩色图片、录音、视频、指纹信息、身份证信息……  十字链表交换任意两个节点C源代码（C指针应用终极挑战）http://download.csdn.net/detail/zhao4zhong1/5532495