u****u
发帖数: 229 | 1 好象现在看到的C编译器都把变量放在stack上，把动态内存放在heap上。比如：
foo() {
int a,b[100];
int *pa;
pa = new int[200];
}
a,b[100],pa都是在stack上的变量，pa指向一块在heap上的内存。特别是b[100]，是存在
stack上的100个int大小的内存块。
我的问题是，是不是C规定函数的变量“必须”放在stack上？比如，可以不可以有一个编
译器,把b[100]解释成一个存在stack上的int *, 指向一个heap上100个int大小的内存块
（当然，这块内存的分配，释放由编译器实现）。
这样的一个C/C++编译器会不会违反C的什么规定？可以不可以做这么一个compiler?请高
手详细解释一下吧。谢谢。 |
a***x
发帖数: 26368 | 2 does malloc work?
在
编
块
高
【在 u****u 的大作中提到】
: 好象现在看到的C编译器都把变量放在stack上，把动态内存放在heap上。比如：
: foo() {
: int a,b[100];
: int *pa;
: pa = new int[200];
: }
: a,b[100],pa都是在stack上的变量，pa指向一块在heap上的内存。特别是b[100]，是存在
: stack上的100个int大小的内存块。
: 我的问题是，是不是C规定函数的变量“必须”放在stack上？比如，可以不可以有一个编
: 译器,把b[100]解释成一个存在stack上的int *, 指向一个heap上100个int大小的内存块
|
u****u
发帖数: 229 | 3 why not?
【在 a***x 的大作中提到】
: does malloc work?
:
: 在
: 编
: 块
: 高
|
o**o
发帖数: 3964 | 4 smart pointer就是这样的啊，int*的wrapper在stack里面
在
编
块
【在 u****u 的大作中提到】
: 好象现在看到的C编译器都把变量放在stack上，把动态内存放在heap上。比如：
: foo() {
: int a,b[100];
: int *pa;
: pa = new int[200];
: }
: a,b[100],pa都是在stack上的变量，pa指向一块在heap上的内存。特别是b[100]，是存在
: stack上的100个int大小的内存块。
: 我的问题是，是不是C规定函数的变量“必须”放在stack上？比如，可以不可以有一个编
: 译器,把b[100]解释成一个存在stack上的int *, 指向一个heap上100个int大小的内存块
|
g********t
发帖数: 153 | 5 I dn't think you can do this.
b[100] will be stack and it is defined by compiler, no any dynamica
mallocation is invovled here,
so either user-define malloc or smart ptr can't help
在
编
块
【在 u****u 的大作中提到】
: 好象现在看到的C编译器都把变量放在stack上，把动态内存放在heap上。比如：
: foo() {
: int a,b[100];
: int *pa;
: pa = new int[200];
: }
: a,b[100],pa都是在stack上的变量，pa指向一块在heap上的内存。特别是b[100]，是存在
: stack上的100个int大小的内存块。
: 我的问题是，是不是C规定函数的变量“必须”放在stack上？比如，可以不可以有一个编
: 译器,把b[100]解释成一个存在stack上的int *, 指向一个heap上100个int大小的内存块
|
u****u
发帖数: 229 | 6 我的意思是compiler把这个b[100]放到stack上，不是programmer决定的。一般的
compiler看到int b[100]就会在stack上安排一个100个int的空间，我问的是可以不可以
有一个“特别的compiler”，把这个"100个int"的空间放到heap上。这个过程对
programmer是透明的，programmer不能控制的。
或者从另一个角度说，如果你看到int b[100]，programmer能不能认为这个存储空间一定
是在stack上的？会不会有一个特别的compiler为了某种需要将这个存储空间安排到heap
上？如果compiler这么做，会不会违反C中的某些规定？
【在 g********t 的大作中提到】
: I dn't think you can do this.
: b[100] will be stack and it is defined by compiler, no any dynamica
: mallocation is invovled here,
: so either user-define malloc or smart ptr can't help
:
: 在
: 编
: 块
|
P*****f
发帖数: 2272 | 7 the machine architecure is stack-model,
why bother do that?
以
定
heap
【在 u****u 的大作中提到】
: 我的意思是compiler把这个b[100]放到stack上，不是programmer决定的。一般的
: compiler看到int b[100]就会在stack上安排一个100个int的空间，我问的是可以不可以
: 有一个“特别的compiler”，把这个"100个int"的空间放到heap上。这个过程对
: programmer是透明的，programmer不能控制的。
: 或者从另一个角度说，如果你看到int b[100]，programmer能不能认为这个存储空间一定
: 是在stack上的？会不会有一个特别的compiler为了某种需要将这个存储空间安排到heap
: 上？如果compiler这么做，会不会违反C中的某些规定？
|
b**g
发帖数: 335 | 8 不管它摆在heap或stack上,只要这函数一返回
int b[100]就不该再被reference到(除非宣告为static)
所以摆在哪里有什么差别吗?
ANSI/ISO C标准里应该没提到heap/stack这么细的东西
也有些C compiler(e.g Watcom)把local variables(如果量不大)
存在register里以增进性能的
以
定
heap
【在 u****u 的大作中提到】
: 我的意思是compiler把这个b[100]放到stack上，不是programmer决定的。一般的
: compiler看到int b[100]就会在stack上安排一个100个int的空间，我问的是可以不可以
: 有一个“特别的compiler”，把这个"100个int"的空间放到heap上。这个过程对
: programmer是透明的，programmer不能控制的。
: 或者从另一个角度说，如果你看到int b[100]，programmer能不能认为这个存储空间一定
: 是在stack上的？会不会有一个特别的compiler为了某种需要将这个存储空间安排到heap
: 上？如果compiler这么做，会不会违反C中的某些规定？
|
c*r
发帖数: 278 | 9 有差别. Stack size is limited. You cannot have a big array in stack.
【在 b**g 的大作中提到】
: 不管它摆在heap或stack上,只要这函数一返回
: int b[100]就不该再被reference到(除非宣告为static)
: 所以摆在哪里有什么差别吗?
: ANSI/ISO C标准里应该没提到heap/stack这么细的东西
: 也有些C compiler(e.g Watcom)把local variables(如果量不大)
: 存在register里以增进性能的
:
: 以
: 定
: heap
|
b**g
发帖数: 335 | 10
那只是implementation问题
【在 c*r 的大作中提到】
: 有差别. Stack size is limited. You cannot have a big array in stack.
|
