zoukankan      html  css  js  c++  java
  • 字符串指针与字符数组

     

    很多刚从CC++的人都不明白,在C中这样的代码

    char *pChar="hELLO!";   //定义字符指针pChar,指向一个字符数组首元素即h

    *pChar='H';             //问题所在行

    到了C++中怎么就不行了?你翻遍参考书,都会说,pChar指向的是常量,怎么能允许改变呢?你又问了,怎么我在C中运行的好好的?没人回答你。

    正在装载数据……

    于是,你只好自我安慰,这就是C++的保护机制吧。

    我来做个总结吧,发现这个问题如果不深入研究一下,总是人云亦云,就像我以前那样。于是,我用BC++3.1编译这段代码后运行,无论是编DOS程序还是Windows程序都是能运行的,结果也和你预期的一样。没什么问题。但是VC++6运行时就会出错,错误你想必相当熟悉(XX内存不能写)。但这只是编译器的问题的吗?

    你可以把你在VC++中编译的程序拿到纯DOS下运行,哪怕他是Console程序,他也会说Can not run in DOS,因为他是32位的。而BC++3.1哪怕是编一个Windows程序,也只是16位的。所以问题的关键在于内存的管理上。32位系统对于应用程序使用的内存定义了操作权限,能读还是能写,或者是其他什么。而16位的系统缺乏这种安全机制,哪怕你说这段数据只能读,但是写一下也没什么关系。

    这种代码之所以能在C中运行的很好,就是因为那时C的编译器都是16位的;现在在C++中不行了,是因为你用的C++编译器是32位的——能找到BC++3.1这种古董还真不容易,相对而言TC2.0更好找。我反汇编TC2.0生成的这两条语句char *p = hellow;char p[] = hellow;发现他们的实现并不相同,相对而言,char *p = hellow;生成的代码更简洁一些。虽然C也想定义常量字符串,但由于16位的欠缺保护,这种想法被人误解了;几乎所有学习过C的人都曾耗费力气去理解如上的代码,然后泛滥的使用。不为别的,只因为这种代码效率高,从反汇编结果能看出来。于是使用char p[] = hellow;这种语法的人被嘲笑,但事实上,这种语法才是本意,那种语法只是钻了个空子,于是,在32位程序中,他被剥夺了生存的权利。

    这让我想起了C中很多怪异的写法,虽然他们让人很费解,但是确实,他们的效率要比容易看懂的写法来得高,当然,我不知道这其中有没有钻空子的例子;从C设计的本意来说,他们有存在的意义,但是从现在的程序设计潮流来看,代码的可读性要求超过了他的效率。不知道这些语法能不能算是程序员中的一种外语——想写高效的程序吗,掌握我吧,哪怕是死记硬背。

    PS32位系统运行16位程序采用的是模拟仿真的方法,就是说和运行在16位系统一样。

  • 相关阅读:
    ORACLE【0】:基本操作
    ORACLE【3】:分区表以及分区索引
    ORACLE【2】:锁机制及解锁
    log4j学习一:解决系统日志错位问题
    使用一个非堵塞的socket用于接收http请求
    Python中文转换报错 'ascii' codec can't decode byte 0xe8 in position
    首次使用Redis记录【3】
    xsi:schemaLocation有何作用
    【转】【redis】3.Spring 集成注解 redis 项目配置使用
    maven仓库地址
  • 原文地址:https://www.cnblogs.com/inspurhaitian/p/1284296.html
Copyright © 2011-2022 走看看