3,881
社区成员
发帖
与我相关
我的任务
分享在dos下开大数组的问题
在dos下编程，C或C＋＋都可以，代码不多，数据很大，大概600兆。数据需要保存在内存中，最后存盘。但是dos实模式下只能存取640K内存，最大数组可以开65535字节，不能满足要求。动态分配内存好像成功了（用malloc，返回指针不为空）。但我试着给这块空间赋值，最后存盘，发现每次都是64K的一个块赋值成功，在每个64k的代码中间还夹杂着许多乱七八糟的符号。
请高手指教。
不胜感激！
请高手指教。
不胜感激！
...全文
请发表友善的回复…
发表回复
fixopen 2005-12-01
- 打赏
- 举报
我说说我的想法，物理地址空间是完全可以超过４Ｇ的．不过，不可能在不改变段选择子的情况下访问超过４Ｇ的内存．这有点类似于XMS技术，在1M的地址空间里面开个窗，用来访问超过1M的地址空间，如果想访问，就得依次的改变窗子map的位置。段选择子起的也是这个作用。另外值得注意的是：段这个武器在windows和linux下都弃之不用，原因很简单，一、它复杂化了寻址方式，二、它降低了性能。当然，随着段带来的大空间寻址的好处也被丢弃了。段的引入使得地址空间变成二维的了，这似的我们可能在不同段里面访问到相同的物理地址，这个极大的增加了寻址的复杂性。
fixopen 2005-11-30
- 打赏
- 举报
哈哈，好玩。
我插一句：Intel CPU的Page大小可以是4M的。
我插一句：Intel CPU的Page大小可以是4M的。
antijpn 2005-10-15
- 打赏
- 举报
看来ANSI和ISO都在出售粪土，所谓的黄金是拿来供人下载的……无知且无聊的人才会在拥有标准的正文的情况下再去以所谓的“黄金”作为准则来衡量代码与标准的契合程度
megaboy 2005-10-15
- 打赏
- 举报
从你的用词：“旧标准”、“草案”就知道这么多天了你仍然不知道自己究竟错在哪里，更说明你对标准的历史、结构、功能是多么无知。你寻找答案的能力实在不能恭维，更可能的是不愿承认。我从来不认为你的技术水平不行，即使你犯了上述这些错误，我也没有怀疑这一点，相信大家也不会，人孰无错？一个人的能力不会因为几个错误就被否定。但是，你这个人不值得别人去尊重，因为你不尊重事实、不尊重别人，又盲目自负。看来我前面说得没错，无赖两个字最配得上现在的你。
我在这个贴子的讨论到此为止，抱着你的无知发春秋大梦去吧，醒来的时候，你就会发现其实自己拿着一堆粪土当黄金！
我在这个贴子的讨论到此为止，抱着你的无知发春秋大梦去吧，醒来的时候，你就会发现其实自己拿着一堆粪土当黄金！
antijpn 2005-10-15
- 打赏
- 举报
落水狗居然还敢出来……
不介意再痛打一次，有脑子的都看到是你一直在拿着旧标准说是。另外，我不知道做编译器是该按照草案还是按照标准的正文，按照你的说法似乎应该是草案？不按照草案做，而按照正式发布的标准正文做反而是错误的？
不介意再痛打一次，有脑子的都看到是你一直在拿着旧标准说是。另外，我不知道做编译器是该按照草案还是按照标准的正文，按照你的说法似乎应该是草案？不按照草案做，而按照正式发布的标准正文做反而是错误的？
tiaoci 2005-10-14
- 打赏
- 举报
我觉得应用开发人员最好别太关注OS和底层的
如果DOS无法满足需求，那就换操作系统么，只要达到目的就可以了
另外你说WIN无法满足实时要求，你确定吗？
如果DOS无法满足需求，那就换操作系统么，只要达到目的就可以了
另外你说WIN无法满足实时要求，你确定吗？
tiaoci 2005-10-14
- 打赏
- 举报
楼主为什么不放弃DOS用linux呢，用DJ编译
megaboy 2005-10-14
- 打赏
- 举报
人家在说你呢，可怜虫。
我再说一遍，你现在连c89、c99分多少部分发行的都不懂！还谈什么标准？先回家去把不懂的东西弄好了，就会在里面找到我摘录的那些话了。
我再说一遍，你现在连c89、c99分多少部分发行的都不懂！还谈什么标准？先回家去把不懂的东西弄好了，就会在里面找到我摘录的那些话了。
antijpn 2005-10-14
- 打赏
- 举报
回复人： BluntBlade(无锋之刃·说C，C是个什么东西？) ( ) 信誉：105 2005-10-14 01:56:00 得分: 0
听说Watcom的编译器优化都做得不错啊……
嗯，感觉大米和Megaboy的争论有点过头了。
如果标准没有用那制订标准来做什么呢？
------------------------------------------
就是阿，放着最新的标准不看（新标准不止有新特性，还有对原来标准的修正），却一定要在故纸堆里面找东西，这个逻辑真的很奇怪
听说Watcom的编译器优化都做得不错啊……
嗯，感觉大米和Megaboy的争论有点过头了。
如果标准没有用那制订标准来做什么呢？
------------------------------------------
就是阿，放着最新的标准不看（新标准不止有新特性，还有对原来标准的修正），却一定要在故纸堆里面找东西，这个逻辑真的很奇怪
BluntBlade 2005-10-14
- 打赏
- 举报
听说Watcom的编译器优化都做得不错啊……
嗯，感觉大米和Megaboy的争论有点过头了。
如果标准没有用那制订标准来做什么呢？
嗯，感觉大米和Megaboy的争论有点过头了。
如果标准没有用那制订标准来做什么呢？
yulinlang 2005-10-14
- 打赏
- 举报
楼主试试这个：
DJGPP32位的C语言编程环境
--------------------------------------------------------------------------------
提起ＤＯＳ下的Ｃ语言，大多数朋友都会想到Ｂｏｒｌａｎｄ Ｃ，可
惜一个大点的游戏涉及到图象声音等等大量的数据。显然在１６位实模式下
写程序，便会因为６４０Ｋ的内存限制而碍手碍脚：（而用ＢＣ写３２位程
序就不那么方便了。有的朋友转到了Ｗｉｎｄｏｗｓ ９５编程，而剩下来
仍奋战在ＤＯＳ环境下的游戏程序员便开始使用别的为３２位保护模式设计
的Ｃ语言了。Ｗａｔｃｏｍ Ｃ 一时间风靡全国。而另一个强大的Ｃ系统
ＤＪＧＰＰ，却无人问津。云风也曾学习使用过Ｗａｔｃｏｍ Ｃ，可是一
当试用ＤＪＧＰＰ，便彻底删除了硬盘中的Ｗａｔｃｏｍ Ｃ，现作此小文
以在国内推广此强力工具：）
以下文字无意贬低其它Ｃ语言系统的强大功能，评论文字仅为云风一人之见
首先，ＤＪＧＰＰ是一个ＧＮＵ软件，换句话说，你可以得到它整个系
统的源代码，且可以任意修改。正因如此，ＤＪＧＰＰ比起其它的商业化Ｃ
系统技术的发展要快的多，无数计算机高手不停的在完善它，为它注入新的
活力；而被发现的ＢＵＧ也能在第一时间被去掉。通过Ｉｎｔｅｒｎｅｔ，
你永远可以使用到世界上的最新技术，而且不用为其付费：）
我很喜欢ＤＪＧＰＰ的３２位保护模式引擎ＣＷＳＤＰＭＩ，至少它的
装栽速度比Ｗａｔｃｏｍ Ｃ常用的ＤＯＳ／４ＧＷ要快的多，体积小的多
如果不使用ＤＰＭＩ，而换用ＶＣＰＩ，甚至连ＣＷＳＤＰＭＩ这个程序都
不需要：）
其次，ＤＪＧＰＰ拥有丰富的外围软件，我很满意那个为ＤＪＧＰＰ而
编制的集成环境ＲＨＩＤＥ。简直棒极了，界面按我熟悉的Ｂｏｒｌａｎｄ
Ｃ＋＋ ３、１仿制而成，而细微处又增加了许多体贴人心的设计，尤其内
置的Ｄｅｂｕｇ，不仅功能超过了Ｔｕｒｂｏ Ｄｅｂｕｇ，而且稳定性一
流。这套ＩＤＥ不仅支持Ｃ，而且支持Ｃ＋＋，Ｏｂｊ Ｃ，Ｐａｓｃａｌ
Ａｓｍ，Ａｄａ等多种语言的ＧＮＵ版本，使得混合编程易如反掌。
而另一个叫作Ａｌｌｅｇｒｏ的游戏开发库简直无所不包，是游戏程序
员的必备。
如果你现在还在使用Ｂｏｒｌａｎｄ Ｃ写程序，那么转到ＤＪＧＰＰ
来是最容易不过了：）还是一样的界面，一样的写你的程序，只是你不必在
考虑什么远指针，近指针；什么６４Ｋ限制；什么扩展内存，高端内存。就
按你所想去做吧，你会喜欢上这么一个好东东的：）
DJGPP32位的C语言编程环境
--------------------------------------------------------------------------------
提起ＤＯＳ下的Ｃ语言，大多数朋友都会想到Ｂｏｒｌａｎｄ Ｃ，可
惜一个大点的游戏涉及到图象声音等等大量的数据。显然在１６位实模式下
写程序，便会因为６４０Ｋ的内存限制而碍手碍脚：（而用ＢＣ写３２位程
序就不那么方便了。有的朋友转到了Ｗｉｎｄｏｗｓ ９５编程，而剩下来
仍奋战在ＤＯＳ环境下的游戏程序员便开始使用别的为３２位保护模式设计
的Ｃ语言了。Ｗａｔｃｏｍ Ｃ 一时间风靡全国。而另一个强大的Ｃ系统
ＤＪＧＰＰ，却无人问津。云风也曾学习使用过Ｗａｔｃｏｍ Ｃ，可是一
当试用ＤＪＧＰＰ，便彻底删除了硬盘中的Ｗａｔｃｏｍ Ｃ，现作此小文
以在国内推广此强力工具：）
以下文字无意贬低其它Ｃ语言系统的强大功能，评论文字仅为云风一人之见
首先，ＤＪＧＰＰ是一个ＧＮＵ软件，换句话说，你可以得到它整个系
统的源代码，且可以任意修改。正因如此，ＤＪＧＰＰ比起其它的商业化Ｃ
系统技术的发展要快的多，无数计算机高手不停的在完善它，为它注入新的
活力；而被发现的ＢＵＧ也能在第一时间被去掉。通过Ｉｎｔｅｒｎｅｔ，
你永远可以使用到世界上的最新技术，而且不用为其付费：）
我很喜欢ＤＪＧＰＰ的３２位保护模式引擎ＣＷＳＤＰＭＩ，至少它的
装栽速度比Ｗａｔｃｏｍ Ｃ常用的ＤＯＳ／４ＧＷ要快的多，体积小的多
如果不使用ＤＰＭＩ，而换用ＶＣＰＩ，甚至连ＣＷＳＤＰＭＩ这个程序都
不需要：）
其次，ＤＪＧＰＰ拥有丰富的外围软件，我很满意那个为ＤＪＧＰＰ而
编制的集成环境ＲＨＩＤＥ。简直棒极了，界面按我熟悉的Ｂｏｒｌａｎｄ
Ｃ＋＋ ３、１仿制而成，而细微处又增加了许多体贴人心的设计，尤其内
置的Ｄｅｂｕｇ，不仅功能超过了Ｔｕｒｂｏ Ｄｅｂｕｇ，而且稳定性一
流。这套ＩＤＥ不仅支持Ｃ，而且支持Ｃ＋＋，Ｏｂｊ Ｃ，Ｐａｓｃａｌ
Ａｓｍ，Ａｄａ等多种语言的ＧＮＵ版本，使得混合编程易如反掌。
而另一个叫作Ａｌｌｅｇｒｏ的游戏开发库简直无所不包，是游戏程序
员的必备。
如果你现在还在使用Ｂｏｒｌａｎｄ Ｃ写程序，那么转到ＤＪＧＰＰ
来是最容易不过了：）还是一样的界面，一样的写你的程序，只是你不必在
考虑什么远指针，近指针；什么６４Ｋ限制；什么扩展内存，高端内存。就
按你所想去做吧，你会喜欢上这么一个好东东的：）
antijpn 2005-10-12
- 打赏
- 举报
回复人： DiabloWalkOnTheEarth(WorldOfWg( 狗城是个烂代理 )) ( ) 信誉：97 2005-10-10 15:03:15 得分: 0
严重同意 megaboy(飞天御剑流之杀神一刀斩) ..
楼上的好像不知道 X86 还有段寄存器一样, 保护模式下段寄存器还有 14位是有效的( 13位是选择子, 一位选择是在 GDT 还是在 LDT 中 , 最后两位是请求的特权级别 ) , 14 + 32 不是46位还是什么. 虽然 WIN32 && LINUX 实际上木有怎么利用段寄存器, 只用了32位的偏移, 但只要自己喜欢, 完全可以这么做, 只是麻烦一点.
=====================================
哦，对了，关于段还有一些问题要说明。少使用段是可以理解的，过多的使用段的话，会有额外的开销。譬如跨段的过程调用，对于stack来说，要额外的放置一个16位的segment selector，返回的时候还要恢复CS，不用段（或者少用段）的话可以避免这样造成的开销。
严重同意 megaboy(飞天御剑流之杀神一刀斩) ..
楼上的好像不知道 X86 还有段寄存器一样, 保护模式下段寄存器还有 14位是有效的( 13位是选择子, 一位选择是在 GDT 还是在 LDT 中 , 最后两位是请求的特权级别 ) , 14 + 32 不是46位还是什么. 虽然 WIN32 && LINUX 实际上木有怎么利用段寄存器, 只用了32位的偏移, 但只要自己喜欢, 完全可以这么做, 只是麻烦一点.
=====================================
哦，对了，关于段还有一些问题要说明。少使用段是可以理解的，过多的使用段的话，会有额外的开销。譬如跨段的过程调用，对于stack来说，要额外的放置一个16位的segment selector，返回的时候还要恢复CS，不用段（或者少用段）的话可以避免这样造成的开销。
antijpn 2005-10-11
- 打赏
- 举报
回复人： DiabloWalkOnTheEarth(WorldOfWg( 狗城是个烂代理 )) ( ) 信誉：97 2005-10-11 00:17:00 得分: 0
好像别人木有说过是64T物理内存，听说世界上还有什么狗屁虚存。
================================================
“狗屁虚存”么，那个是通过paging实现的，这个是另外一种东西。我先问一句，你对Intel的Architecture Software Developer's Manual不存在什么异议吧？如果你不承认这个东西，我下面说得你就不用看了，基本上都是来自那里：
When operating in protected mode, IA-32 architecture permits linear address space to be mapped directly into a large physical memory (for example, 4 GBytes of RAM) or indirectly
(using paging) into a smaller physical memory and disk storage. This latter method of mapping the linear address space is referred to as virtual memory or demand-paged virtual memory.
这段描述么，就说了VM其实只不过把linear address space分成页，然后映射到物理内存和磁盘上面而已。所以paging也无法影响线性地址的大小……但是如果你要是说自己偷偷修改磁盘上面的那部分page的话，我也没什么好说了，磁盘的大小早就突破了64G，Maxtor以前买250G硬盘时候送的那块IDE卡好像就是48bit的寄存器（然后乘以512，就是磁盘最大的字节数了）。说白了，VM其实V的是线性地址空间，在你的物理内存没那么大的时候造出个你有xxxxM内存的假象而以，如果要突破4G的限制，PAE是不可缺少的，突破64G的话64bit就不可缺少了（还有点其他的话没贴，允许我稍微偷懒一下吧……）……
我觉得这样说有点问题。段是逻辑地址的概念，线性地址是没有段这个东西的，虽然在地址总线32位的情况下，线性地址空间是4G，但每个线性地址对应很多个逻辑地址，这些逻辑地址都对应相同的线性地址，对这些逻辑地址相互之间来说，的确是彼此不同的，64T是逻辑地址的空间，不是线性地址的空间。
================================================
不知道你否定的是我的话还是Intel的话（我估计应该是我的）。但是似乎只看了最后一句话，前面还有一句“The processor translates every logical address into a linear address”你没看到么？不过段允许重合，如果算上这个，逻辑地址的确可以达到64T，所有的描述符全都一样不就行了么？如果给你三个容量都为n的口袋，其中前两个装完东西以后要放入第三个，你认为你可以在这里放超过n的东西么？作为代码来说，共享空间也就算了，但是对于一个可以说系统中唯一存在的程序（其他的暂时都忽略吧）把存放数据的段再重复的话没什么意思吧？所以我在上面说这个和浮点数差不多都素那浮云阿浮云，也不是没道理吧？
由于在MMU内部不启用分页部件的时候线性地址就是物理地址，因此这个时候的线性地址肯定是64G的，就是36位，否则就没办法表示所有的物理内存空间。
==================================================
不分页也可以使用64G的物理地址空间？哪本书上说的？我不知道这本书来自除了Intel以外的哪一家公司，怎么就这么强啊（是不是IA32的手册？）？贴一下书名，我去参拜一下……
另外，上次的那个(*pf)()和pf()的帖子里面你说我编译时候用的命令有错，到底错在哪里啊？我真的好困惑啊……帮我解解惑吧……
好像别人木有说过是64T物理内存，听说世界上还有什么狗屁虚存。
================================================
“狗屁虚存”么，那个是通过paging实现的，这个是另外一种东西。我先问一句，你对Intel的Architecture Software Developer's Manual不存在什么异议吧？如果你不承认这个东西，我下面说得你就不用看了，基本上都是来自那里：
When operating in protected mode, IA-32 architecture permits linear address space to be mapped directly into a large physical memory (for example, 4 GBytes of RAM) or indirectly
(using paging) into a smaller physical memory and disk storage. This latter method of mapping the linear address space is referred to as virtual memory or demand-paged virtual memory.
这段描述么，就说了VM其实只不过把linear address space分成页，然后映射到物理内存和磁盘上面而已。所以paging也无法影响线性地址的大小……但是如果你要是说自己偷偷修改磁盘上面的那部分page的话，我也没什么好说了，磁盘的大小早就突破了64G，Maxtor以前买250G硬盘时候送的那块IDE卡好像就是48bit的寄存器（然后乘以512，就是磁盘最大的字节数了）。说白了，VM其实V的是线性地址空间，在你的物理内存没那么大的时候造出个你有xxxxM内存的假象而以，如果要突破4G的限制，PAE是不可缺少的，突破64G的话64bit就不可缺少了（还有点其他的话没贴，允许我稍微偷懒一下吧……）……
我觉得这样说有点问题。段是逻辑地址的概念，线性地址是没有段这个东西的，虽然在地址总线32位的情况下，线性地址空间是4G，但每个线性地址对应很多个逻辑地址，这些逻辑地址都对应相同的线性地址，对这些逻辑地址相互之间来说，的确是彼此不同的，64T是逻辑地址的空间，不是线性地址的空间。
================================================
不知道你否定的是我的话还是Intel的话（我估计应该是我的）。但是似乎只看了最后一句话，前面还有一句“The processor translates every logical address into a linear address”你没看到么？不过段允许重合，如果算上这个，逻辑地址的确可以达到64T，所有的描述符全都一样不就行了么？如果给你三个容量都为n的口袋，其中前两个装完东西以后要放入第三个，你认为你可以在这里放超过n的东西么？作为代码来说，共享空间也就算了，但是对于一个可以说系统中唯一存在的程序（其他的暂时都忽略吧）把存放数据的段再重复的话没什么意思吧？所以我在上面说这个和浮点数差不多都素那浮云阿浮云，也不是没道理吧？
由于在MMU内部不启用分页部件的时候线性地址就是物理地址，因此这个时候的线性地址肯定是64G的，就是36位，否则就没办法表示所有的物理内存空间。
==================================================
不分页也可以使用64G的物理地址空间？哪本书上说的？我不知道这本书来自除了Intel以外的哪一家公司，怎么就这么强啊（是不是IA32的手册？）？贴一下书名，我去参拜一下……
另外，上次的那个(*pf)()和pf()的帖子里面你说我编译时候用的命令有错，到底错在哪里啊？我真的好困惑啊……帮我解解惑吧……
DiabloWalkOnTheEarth 2005-10-11
- 打赏
- 举报
好像别人木有说过是64T物理内存，听说世界上还有什么狗屁虚存。
megaboy 2005-10-11
- 打赏
- 举报
这个最后一句话如果我没理解错误的话，应该是说：所有的段都在这个4G的线性地址空间中……也就是段的容量总和还是不能突破4G，如果算上了系统的各个表的话，还要更小才对。
-----------------------------------------------------------------------
我觉得这样说有点问题。段是逻辑地址的概念，线性地址是没有段这个东西的，虽然在地址总线32位的情况下，线性地址空间是4G，但每个线性地址对应很多个逻辑地址，这些逻辑地址都对应相同的线性地址，对这些逻辑地址相互之间来说，的确是彼此不同的，64T是逻辑地址的空间，不是线性地址的空间。
不过前面一点的地方还提到这个线性地址空间和物理地址空间一样大的，是否意味着可以达到64G呢？
----------------------------------------------------------------------------------------
由于在MMU内部不启用分页部件的时候线性地址就是物理地址，因此这个时候的线性地址肯定是64G的，就是36位，否则就没办法表示所有的物理内存空间。
-----------------------------------------------------------------------
我觉得这样说有点问题。段是逻辑地址的概念，线性地址是没有段这个东西的，虽然在地址总线32位的情况下，线性地址空间是4G，但每个线性地址对应很多个逻辑地址，这些逻辑地址都对应相同的线性地址，对这些逻辑地址相互之间来说，的确是彼此不同的，64T是逻辑地址的空间，不是线性地址的空间。
不过前面一点的地方还提到这个线性地址空间和物理地址空间一样大的，是否意味着可以达到64G呢？
----------------------------------------------------------------------------------------
由于在MMU内部不启用分页部件的时候线性地址就是物理地址，因此这个时候的线性地址肯定是64G的，就是36位，否则就没办法表示所有的物理内存空间。
antijpn 2005-10-11
- 打赏
- 举报
我从来不介意痛打落水狗，从标准中无法找到任何理由来驳斥我的话，只能借着“无赖”什么的字眼搞人身攻击，没有技术，更丢了人品，BS一个
megaboy 2005-10-11
- 打赏
- 举报
你连标准分多少部分都没弄清楚，还谈什么标准？
算了，既然你这么欣赏无赖这个角色，以后我都不会再在你身上浪费那怕一秒钟的时间。你自己喜欢想什么，说什么，由得你吧，跟我无关。
算了，既然你这么欣赏无赖这个角色，以后我都不会再在你身上浪费那怕一秒钟的时间。你自己喜欢想什么，说什么，由得你吧，跟我无关。
realstephen 2005-10-11
- 打赏
- 举报
两位哥哥别争论了，小弟无能才来这里求助的。
眼看这问题得不到解决，帖子先跑了主题。
唉，这年头，干点啥都不易...
眼看这问题得不到解决，帖子先跑了主题。
唉，这年头，干点啥都不易...
icansaymyabc 2005-10-11
- 打赏
- 举报
既然是这样的话。去找一个DOS下的32位C/C++编译器了事。
典型的就是 DOS/4G 这个工具。
不过用法好像有点复杂，反正比windows/ linux/ unix 下的32位c程序复杂多了。
dos下的大型游戏都是用这个工具写出来的。
典型的就是 DOS/4G 这个工具。
不过用法好像有点复杂，反正比windows/ linux/ unix 下的32位c程序复杂多了。
dos下的大型游戏都是用这个工具写出来的。
antijpn 2005-10-11
- 打赏
- 举报
可笑了，这话怎么都开始倒着说了？明明是按照你的说法，大多数编译器行为才是不符合标准的
6.5.3.2 Address and indirection operators
Constraints
1 The operand of the unary & operator shall be either a function designator, the result of a [] or unary * operator, or an lvalue that designates an object that is not a bit-field and is not declared with the register storage-class specifier.
2 The operand of the unary * operator shall have pointer type.
Semantics
3 The unary & operator returns the address of its operand. If the operand has ype 'type', the result has type 'pointer to type'. If the operand is the result of a unary * operator, neither that operator nor the & operator is evaluated and the result is as if both were omitted, except that the constraints on the operators still apply and the result is not an lvalue.
Similarly, if the operand is the result of a [] operator, neither the & operator nor the unary * that is implied by the [] is evaluated and the result is as if the & operator were removed and the [] operator were changed to a + operator. Otherwise, the result is a pointer to the object or function designated by its operand.
4 The unary * operator denotes indirection. If the operand points to a function, the result is a function designator; if it points to an object, the result is an lvalue designating the object. If the operand has type 'pointer to type', the result has type 'type'. If an invalid value has been assigned to the pointer, the behavior of the unary * operator is undefined.)
标准里面就这么说了，你的那些故纸堆里翻出来的东西在哪？
一切依照现行标准说话，这个要是无赖的话，我宁愿做个无赖，并且要在我所能及的范围内让所有人来做“标准无赖”。关于函数的隐式声明，这本身就是一个历史原因产生的问题。为了程序的健壮性与正确性，牺牲一点点的书写方便绝对是划得来的。
你一而再再而三的逃避我的问题，这说明什么？1、可能是技术问题，不愿承认。2、人品问题，根本就没有探讨的态度，只知道找些故纸堆里面的东西来误导别人。无论是哪一种都实在应该好好BS
6.5.3.2 Address and indirection operators
Constraints
1 The operand of the unary & operator shall be either a function designator, the result of a [] or unary * operator, or an lvalue that designates an object that is not a bit-field and is not declared with the register storage-class specifier.
2 The operand of the unary * operator shall have pointer type.
Semantics
3 The unary & operator returns the address of its operand. If the operand has ype 'type', the result has type 'pointer to type'. If the operand is the result of a unary * operator, neither that operator nor the & operator is evaluated and the result is as if both were omitted, except that the constraints on the operators still apply and the result is not an lvalue.
Similarly, if the operand is the result of a [] operator, neither the & operator nor the unary * that is implied by the [] is evaluated and the result is as if the & operator were removed and the [] operator were changed to a + operator. Otherwise, the result is a pointer to the object or function designated by its operand.
4 The unary * operator denotes indirection. If the operand points to a function, the result is a function designator; if it points to an object, the result is an lvalue designating the object. If the operand has type 'pointer to type', the result has type 'type'. If an invalid value has been assigned to the pointer, the behavior of the unary * operator is undefined.)
标准里面就这么说了，你的那些故纸堆里翻出来的东西在哪？
一切依照现行标准说话，这个要是无赖的话，我宁愿做个无赖，并且要在我所能及的范围内让所有人来做“标准无赖”。关于函数的隐式声明，这本身就是一个历史原因产生的问题。为了程序的健壮性与正确性，牺牲一点点的书写方便绝对是划得来的。
你一而再再而三的逃避我的问题，这说明什么？1、可能是技术问题，不愿承认。2、人品问题，根本就没有探讨的态度，只知道找些故纸堆里面的东西来误导别人。无论是哪一种都实在应该好好BS
加载更多回复（29）
