放弃是再容易不过的事情
日历
网志分类
· 所有网志 (44)
· Denx (0)
· 正则表达式 (2)
· u-boot (6)
· CLanguage (4)
· APUE (1)
· 未分类 (31)
最新的评论
站内搜索
友情链接
· 歪酷博客
· 我的歪酷 非非共享界
· juventus

订阅 RSS

0005498

歪酷博客

homey123 @ 2008-12-20 09:16

如果大家平常因为工作的原因,不能使用unix/linux的shell,这里有一些
免费提供shell帐号的服务可供使用:

  • Compaq Test Drive Program,各种型号机器、各种系统,只能用为数众多来形容。
  • cyberspace.org (unix)
  • IBM Linux Community Development System ( Linux on S/390)

    cyberspace.org是我平常常用的,那里可以用lynx。IBM的LCDS是偶尔
    看到的,没有用过。如果大家觉得以上的都不行,可以去dir.google看看:
    FreeShellDirectory@google

    另外,给大家推荐PuTTY,小巧但功能强大,支持telnet/ssh,我在
    windows里常备的工具。刚刚看IBM的LCDS页面时,看到IBM也推荐
    用这个东西登录他的系统
  • OKLinux.cn linux中文技术支持站


     
    homey123 @ 2008-09-11 14:36

    编译连接通过永远不是coding的目标。有时候,编译器也会跟你开个不大不小的玩笑。



    假设这样一段代码 test.c :

    language=javascript src="/plug-ins/SyntaxHighlighter/shCore.js">

    language=javascript src="/plug-ins/SyntaxHighlighter/shBrushCSharp.js"> language=javascript>dp.SyntaxHighlighter.HighlightAll("dp_sourcecode");

     

    编译连接:

    $ gcc -O2 -o test test.c

    顺利通过。但运行的结果完全不是期望的那样(三秒钟触发一次Heart Beat)。实际上如果给 gcc 加上编译参数就能看到警告信息:

    $ gcc -Wall -O2 -o test test.c
    test.c: In function `main':
    test.c:9: warning: implicit declaration of function `time'
    test.c:12: warning: implicit declaration of function `difftime'

    因为 timedifftime 都是在 <time.h> 头文件里面进行的声明,而不是 <sys/time.h> 。遗憾的是 gcc 的缺省编译不会对 implicit declarationwarning 信息进行显示。所以还是加上 -Wall 参数吧,否则一个小小的错误(甚至是笔误)也可能带来意想不到的危险。

    ---------------------------------------

    正好看到一篇相关的文章,转贴到这里(作者如果不希望被转,请与我联系)。原文地址:
    http://daiyuwen.freeshell.org/gb/programming/about_header_files.html

    头文件不是可有可无的
    作者: Dai Yuwen

    我看到有些程序员用C语言写程序的时候,不太了解头文件的作用。他们对编译器提出的警告不在乎,仅以编译、连接通过为目标,这可能会有潜在的危害。

    头文件定义了数据结构和函数接口

    头文件定义了数据结构,这大家都能体会到,因为不包含你要使用头文件的话,编译根本就通不过。 头文件的另一个作用,定义函数接口,作用似乎没那么大,因为编译、连接都通过了,程序也能运行了,这不就行了吗。下面我们用一个例子说明这个问题。
    假设我们写了一个很简单的程序: main调用了一个函数foo:

    #include <stdlib.h>
    #include <stdio.h>

    int main(void){
        int i;

        i = foo (2, 3);
        printf ("foo returns %d\n", i);
        exit(0);
    }

    int foo (int a){
        return (a+a);
    }

    此程序有严重的错误,但是如果我们用命令
    $ gcc -c main.c

    编译的时候,没有任何警告或出错信息。好,我们加上-Wall选项:
    $ gcc -c -Wall main.c
    main.c: In function `main':
    main.c:8: warning: implicit declaration of function `foo'

    这句implicit declaration of function可能是被程序员忽视最多的警告了。 好,我们继续忽视它,接下来连接也能通过:
    $ gcc -o ex1 main.o

    运行也没有问题。 但你不觉得毛骨悚然吗? 一个严重的错误就这样从你眼皮底下过去了。你的程序越来越复杂,这个警告混在一大堆编译信息里,根本就注意不到了。 直到某一天一些奇怪的问题出现了,你开始调用各种土枪洋炮来调试程序…
    其实,如果我们稍微尊重些编译器,把函数的声明加在main的前面,问题错误马上显现:

    int foo (int a);
    int main(void)

    编译
    $ gcc -c -Wall main.c
    main.c: In function `main':
    main.c:9: error: too many arguments to function `foo'

    这就是函数声明的作用。 它既告诉程序员如何调用一个函数,也让编译器检查调用与函数原型是否一致。 有些人以为连接器会检查参数匹配的问题,连接不出错就万事大吉了,这是不对的。你想,参数是以寄存器或压栈的方式传递的。编译之后,参数类型和个数等信息都已丢失,连接器还能帮你查错吗? 它只是简单地把名字相同的符号连接起来而已。

    错误发现的越早越好
    编程出现错误是不可避免的。错误发现的越早,修改的成本就越小。 因此原则是:尽量让错误暴露出来(例如严格的编译选项、测试),而不是掩盖或忽视它。 能在编译时发现的错误,不要拖到运行时;能在编辑时发现的错误,不要拖到编译时(许多编辑器的括号匹配、代码补齐等功能就是为了减少这样的错误)。