419

Posts tagged with "转载"

很多人都对电池的认识有误区

Saturday, 7. April 2007, 05:21:33

以下转自
笔记本电脑电池使用技巧与维护
http://hi.baidu.com/joe727/blog/item/50063e245352ad2ad4074238.html

误区一：笔记本电脑买回来需要反复充放电三次以便激活电池。

除非你买到的笔记本电脑是库存一年以上的产品，否则就不需要这样做，因为现在的电池电芯在出厂的时候已经经过激活，而电芯在封装成笔记本电池的时候又经过一次相当于激活的检验，因此你拿到手的电池，早已是被激活过的了，再做三次充放电过程只是无谓的增加电池的损耗。

误区二：第一次充电必须充够12小时

这对于早期那些没有电池控制电路的镍氢电池机型是适用的，但对于如今具有智能充放电控制电路的笔记本电池来说却是个笑话，当笔记本电脑电池充满之后，充电电流就会被自动切断，哪怕你继续充120个小时，状态也不会有任何变化了，一般来说，就算充电最慢的机器，6小时也完全充满了，剩下的“充电”只是浪费自己的时间。反而是拿到新机器的时候应该先把电量放光再充电。

误区三：电池需要定期的校正，每月一次彻底充放。

对于记忆效应很强的镍氢电池，这是必须的工作，但对于锂电池，这个周期却太频繁了，锂电池虽然没有完全消除记忆效应，但已经大大减弱了记忆效应，如果你使用电池很频繁，那么你应该将电池放电到比较低（大约10~15%）再充电，但如果放电到连机器都开不了(0~1%)，就属于对锂电池的有较大损伤的深度放电，一般来说每2个月做一次这样的操作就可以了。如果你很少使用电池，那么只要每3个月进行一次这样的操作就可以了。

误区四：进行校正可以提升电池容量

所谓校正，是当电池的实际容量和控制电路中的纪录容量不一样时，对电池进行一次深度充放电操作，让控制电路刷新纪录，使之接近电池的实际情况，这是一个表现电池真实容量的操作而非提升容量，这里关键因素是电池的实际容量，假如电池的实际容量比控制电路中纪录的容量要高，校正可以令电池看起来容量增加了，假如电池的实际容量比控制电路中纪录的容量要低，则校正会令电池看起来容量减少，这也就是许多人对校正效果争论不休的原因，请记住校正是令电池的真实容量呈现出来，消除电池和控制电路之间的偏差，至于显示出来的容量是会增加还是减少，这是电池本身的状态而不是你的校正所决定的。很有可能电池因为校正时候的深度放电损伤，容量反而大大下降。

No comments

新书到手之前～在C语言里散步

Wednesday, 5. April 2006, 07:23:13

programming, 转载

The C Programming Language 看完了，看不懂的就跳过，不为难自己，这本书初者看一次是不可能懂得太多的，以后增加了经验值再回头看。

打算这个周末去广州购书中心买另一本编程方面的书（买什么还没有定），在新书到手之前，先看看网上有什么吧！

先来点基础的～
看到huilin用C++写了个九九乘法表，我也用C写一个。这么简单的程序，C和C++都差不多了，不过C里有格式化输出，输出效果好看一点点

不知道C++里有没有格式化输出（完全没学过C++）。

#include <stdio.h>

int main()
{
  int i, j;

  for (i = 1; i <= 9; i++) {
    for (j = 1; j <= i; j++)
      printf("%2d*%d=%2d", j, i, i*j);
    printf("\n");
  }
  return 0;
}

再来个出人意表的！
http://spaces.msn.com/yysbest/blog/cns!6AA50ECC08C16932!117.entry

IA-32机上，int是32位（4个字节）的。请问，如何把它分解成4个字节？要求不采用任何计算。
不要任何计算，位移不行，指针转换也不行。那咋办咧？还是有高招滴~~~

union test{
    int i;
    unsigned char ch[4];
};
int main()
{
    union test t;
    t.i = 0x01020304;
    
    printf("0x%x 0x%x 0x%x 0x%x\n",t.ch[0],t.ch[1],t.ch[2],t.ch[3]);
}

不过我们把这看成一种思路好了，平白无事就不要写这个代码，写着痛苦看着别扭。

接着再来看一看什么是编程修养吧。

如果把编程比作武功－－算法是内功，语言是武器，技巧是招式，编程修养就是……是什么？想不出来

　　　　01、版权和版本
　　　　02、缩进、空格、换行、空行、对齐
　　　　03、程序注释
　　　　04、函数的[in][out]参数
　　　　05、对系统调用的返回进行判断
　　　　06、if 语句对出错的处理
　　　　07、头文件中的#ifndef
　　　　08、在堆上分配内存
　　　　09、变量的初始化
　　　　10、h和c文件的使用
　　　　11、出错信息的处理
　　　　12、常用函数和循环语句中的被计算量
　　　　13、函数名和变量名的命名
　　　　14、函数的传值和传指针
　　　　15、修改别人程序的修养
　　　　16、把相同或近乎相同的代码形成函数和宏
　　　　17、表达式中的括号
　　　　18、函数参数中的const
　　　　19、函数的参数个数
　　　　20、函数的返回类型，不要省略
　　　　21、goto语句的使用
　　　　22、宏的使用
　　　　23、static的使用
　　　　24、函数中的代码尺寸
　　　　25、typedef的使用
　　　　26、为常量声明宏
　　　　27、不要为宏定义加分号
　　　　28、||和&&的语句执行顺序
　　　　29、尽量用for而不是while做循环
　　　　30、请sizeof类型而不是变量
　　　　31、不要忽略Warning
　　　　32、书写Debug版和Release版的程序

还找到了一些书的介绍
http://spaces.msn.com/yrayzsu/blog/cns!9BC8CC9F6B83D5A9!136.entry

《C Primer Plus(第四版)》:不错的一本c书籍，不过书里有些一些小bug，可以说是我c的入门书籍。书中讲解比较深入，但浅鲜，而且对数据结构做了一些初步描述，我应该说是从这本书才真正接触了c，虽然它不是我第一本的编程书籍。翻译的也不错，呵呵!!这本书对一些人来说可能浅了一点!

Stanley B.Lippman《C++Primer》:书很全面，描述深入，对一些问题的描述在其他的C++书中是无法得到明确答复。作者是个大师级的人物，书中对C++的描述很有独到之处，而且字里行间都透出作者对C++语言的深厚功底，也包含了作者的一些经验。作者对问题不是一下子给出答案，而是一步步引导我们，让我们明白为什么这样的解决方案不是最好的，最后给出最好的程序实现。书是在启发中教会我们知识的，是国内书籍一直缺乏的东东。书中的例子都是前后联系，这样可以在不同章节来一步步深入问题。（下划线这部分，我读K&R时也有这种感觉！－－419注）书后的问题也是很精彩，可惜我当时没有花时间去做。

Stanley B.Lippman《Essential C++》:这本书是我的第一本的编程书籍，大一时候看的是中文版。当时可能由于第一次接触编程语言觉得比较新鲜，呵呵，很快就看完了，但什么感觉也没有!!就想吃个好吃的东西吃的太快了，吞下去了，结果什么都没品味到!后来又翻过几次觉得书是不错，给初学者描绘了一个C++世界的蓝图。书中对一些晦涩难懂的C++技术点到为止，这样不会给初学者带来太多恐惧，在相当一个层次上保护了读者的学习积极性。不过觉得侯捷翻译有点太做做了，文绉绉的词太多了，有时候影响了对书本内容的理解。不过不失为一本好书。

　　Bjarne Stroustrup《The C++ Programming Language》:C++之父写的，大家认为怎么样呢?我是买了，当做查阅工具，其中对C++语言的描述我想不需要我细说了吧。只是想说的是，要温故而知新哦!!!每次翻这本书都会有新收获，不信的话，试试看。高教出了这本书英文版，呵呵!!!很便宜的，看准“特别版”三个字哦!!!中文版的是机械出的北大一个教授翻译的，翻译的很不错，推荐!!

　　Scott Meyers《Effective C++》:这本书，我一直认为是工程级别的好书啊!!书中作者提供的50个编程建议或者叫经验吧，对C++的编写有很大帮助。能帮我们更好的写出漂亮的代码。书中不但给出了建议，而且对建议还进行了详细的阐述，“为什么这样用好”、“为什么那样不好”。不过这书我由于各种原因只能拜读一部分。真希望有机会在次聆听一下大师的思想。

4 comments

The Art of Unix Programming

Tuesday, 4. April 2006, 07:40:03

转载, programming, unix

http://www.faqs.org/docs/artu/

Doug McIlroy, the inventor of Unix pipes and one of the founders of the Unix tradition, had this to say at the time [McIlroy78]:

(i) Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new features.

(ii) Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input.

(iii) Design and build software, even operating systems, to be tried early, ideally within weeks. Don't hesitate to throw away the clumsy parts and rebuild them.

(iv) Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you've finished using them.

He later summarized it this way (quoted in A Quarter Century of Unix [Salus]):

This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.

3 comments