Browsed by
月份:2014年3月

无插件Vim编程技巧

无插件Vim编程技巧

相信大家看过《简明Vim教程》也玩了《Vim大冒险》的游戏了,相信大家对Vim都有一个好的入门了。我在这里把我日常用Vim编程的一些技巧列出来给大家看看,希望对大家有用,另外,也是一个抛砖引玉的过程,也希望大家把你们的技巧跟贴一下,我会更新到这篇文章中。另外,这篇文章里的这些技巧全都是vim原生态的,不需要你安装什么插件。我的Vim的版本是7.2

浏览代码

首先,我们先从浏览代码开始。有时候,我们需要看多个文件,所以,传统的做法是,我们开多个tty终端,每个tty里用Vim打开一个文件,然后来回切换。这很没有什么效率。我们希望在一个Vim里打开多个文件,甚至浏览程序目录。

浏览目录的命令很简单:(你也可以直接vim一个目录)

:E

注意,是大写。于是,你会看到下面这样的界面:

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (35 人打了分,平均分: 4.57 )
Loading...
Python修饰器的函数式编程

Python修饰器的函数式编程

Python的修饰器的英文名叫Decorator,当你看到这个英文名的时候,你可能会把其跟Design Pattern里的Decorator搞混了,其实这是完全不同的两个东西。虽然好像,他们要干的事都很相似——都是想要对一个已有的模块做一些“修饰工作”,所谓修饰工作就是想给现有的模块加上一些小装饰(一些小功能,这些小功能可能好多模块都会用到),但又不让这个小装饰(小功能)侵入到原有的模块中的代码里去。但是OO的Decorator简直就是一场恶梦,不信你就去看看wikipedia上的词条(Decorator Pattern)里的UML图和那些代码,这就是我在《 从面向对象的设计模式看软件设计》“餐后甜点”一节中说的,OO鼓励了——“厚重地胶合和复杂层次”,也是《 如此理解面向对象编程》中所说的“OO的狂热者们非常害怕处理数据”,Decorator Pattern搞出来的代码简直就是OO的反面教程。

Python 的 Decorator在使用上和Java/C#的Annotation很相似,就是在方法名前面加一个@XXX注解来为这个方法装饰一些东西。但是,Java/C#的Annotation也很让人望而却步,太TMD的复杂了,你要玩它,你需要了解一堆Annotation的类库文档,让人感觉就是在学另外一门语言。

而Python使用了一种相对于Decorator Pattern和Annotation来说非常优雅的方法,这种方法不需要你去掌握什么复杂的OO模型或是Annotation的各种类库规定,完全就是语言层面的玩法:一种函数式编程的技巧。如果你看过本站的《函数式编程》,你一定会为函数式编程的那种“描述你想干什么,而不是描述你要怎么去实现”的编程方式感到畅快。(如果你不了解函数式编程,那在读本文之前,还请你移步去看看《函数式编程》) 好了,我们先来点感性认识,看一个Python修饰器的Hello World的代码。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (23 人打了分,平均分: 5.00 )
Loading...
一个浮点数跨平台产生的问题

一个浮点数跨平台产生的问题

感谢网友唐磊(微博@唐磊_name)投稿,本文原文在唐磊的博客上(原文地址),原文分析还不够好,而且可能对人有误导,所以,我对原文做了很多修改,并加了Linux下的内容。浮点数是一个很复杂的事情,希望这篇文章有助于大家了解浮点数与其相关的C/C++的编译选项。(注:我没有Windows 32位以及C#的环境,所以,对于Windows 32位的程序和C#的程序没有验证过)

背景就简单点儿说,最近一个项目C#编写,涉及浮点运算,来龙去脉省去,直接看如下代码。

float p3x = 80838.0f;
float p2y = -2499.0f;
double v321 = p3x * p2y;
Console.WriteLine(v321);

很简单吧,马上笔算下结果为-202014162,没问题,难道C#没有产生这样的结果?不可能吧,开启Visual Studio,copy代码试试,果然结果是-202014162。就这样完了么?显然没有!你把编译时的选项从AnyCPU改成x64试试~(服务器环境正是64位滴哦!!)结果居然边成了-202014160,对没错,就是-202014160。有点不相信,再跑两遍,仍然是-202014160。呃,想通了,因为浮点运算的误差,-202014160这个结果是合理的。

为什么合理呢?很正常,因为上面的p3x和p2y是两个float类型,虽然v321是double,但也是两个float类型计算完后再转成double的,float的精度本来也只有7位,所以,对于这个上亿的数,自然没有办法保证精度

但是为什么修改CPU的type会有不同的效果?嗯,我们再试试C/C++。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (9 人打了分,平均分: 4.44 )
Loading...
Java中的CopyOnWrite容器

Java中的CopyOnWrite容器

感谢 清英 同学的投稿

Copy-On-Write简称COW,是一种用于程序设计中的优化策略。其基本思路是,从一开始大家都在共享同一个内容,当某个人想要修改这个内容的时候,才会真正把内容Copy出去形成一个新的内容然后再改,这是一种延时懒惰策略。从JDK1.5开始Java并发包里提供了两个使用CopyOnWrite机制实现的并发容器,它们是CopyOnWriteArrayList和CopyOnWriteArraySet。CopyOnWrite容器非常有用,可以在非常多的并发场景中使用到。

什么是CopyOnWrite容器

CopyOnWrite容器即写时复制的容器。通俗的理解是当我们往一个容器添加元素的时候,不直接往当前容器添加,而是先将当前容器进行Copy,复制出一个新的容器,然后新的容器里添加元素,添加完元素之后,再将原容器的引用指向新的容器。这样做的好处是我们可以对CopyOnWrite容器进行并发的读,而不需要加锁,因为当前容器不会添加任何元素。所以CopyOnWrite容器也是一种读写分离的思想,读和写不同的容器。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (15 人打了分,平均分: 4.13 )
Loading...
如何用最有创造力的方式输出42

如何用最有创造力的方式输出42

酷壳似乎好长时间没有像《编程真难啊》或是《老手是这样教新手编程的》或是像《如何写出无法维护的代码》这样“严肃正经”的文章了,所以,赶在大家还没有向我扔臭鸡蛋前奉献一篇。这篇文章来自CodeGolf.StackExchange上的《Most creative way to display 42》—— 请以最有创造力的方式输出42。于是出现了下面的这些答案(注:精彩的总是留在最后面)

人生和宇宙终级问题的答案:42

这里,需要介绍一下为什么要输出42。这时因为42是我们人生,世界乃至整个宇宙的终级答案。这要从《银河系漫游指南》(英文名:The Hitchhiker’s Guide to the Galaxy)说起。这本书是著名英国科幻小说作家Douglas  Adams所著5本银河系漫游指南系列科幻喜剧系列小说中的第一本,改编自他本人为英国广播公司第四电台(BBC Radio 4)所写的广播剧剧本。该书1979年10月12日首次由麦克米伦出版公司(Pan Books)出版,次周成为英国图书销量榜冠军,前3个月内销售超过25万本。截至2005年,这本小说已被翻译成超过30种语言在全世界发行,并且被改编为电视剧、电影、舞台剧等多种艺术形式的作品。

这本小说中小说中充满尖锐的讽刺和隐喻,被西方科幻爱好者奉为“科幻圣经”。其中有两个关键词,一个是Don’t Panic,一个是42影响力很大,而其中关于42的故事简介是这样的:

百万年前,老鼠其实是一种超智慧生物,它们建造了一部超级电脑深思Deep Thought,它们问超级电脑,生命、宇宙以及任何事情的终极答案(Answer to Life, the Universe, and Everything)什么,经过了750万年的计算,深思告诉老鼠的后人答案是42,深思解释它只能计算出答案是什么,但答案的原因必须由另一部更高智能的电脑才能解释,而该部电脑就是地球。经过了800万年,就在结果要出来的五分钟前,地球却因为挡在预定兴建的星际间高速公路的路线,被Vogons给毁灭,电脑没有给出最后的结果。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (25 人打了分,平均分: 4.60 )
Loading...