Browsed by
分类:程序设计

使用Flex Bison 和LLVM编写自己的编译器

使用Flex Bison 和LLVM编写自己的编译器

使用Flex Bison 和 LLVM编写你自己的编译器
原文出处:http://gnuu.org/2009/09/18/writing-your-own-toy-compiler

1、介绍

我总是对编译器和语言非常感兴趣,但是兴趣并不会让你走的更远。大量的编译器的设计概念可以搞的任何一个程序员迷失在这些概念之中。不用说,我也曾今尝试过,但是并没有取得太大的成功,我以前的尝试都停留在语义分析阶段。本文的灵感主要来源于我最近一次的尝试,并且在这一次中我取得一点成就。

幸运的是,最近的几年,我参加了一些项目,这些项目给了我在建立编译器上很多有用的经验和观点。另外一件事是,我非常幸运得到LLVM的帮助。对于这个工具,我不知道改怎么去形容它,但是他给我的这个编译器的确带来非常大的帮助。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (20 人打了分,平均分: 4.85 )
Loading...
面试题:赛马问题

面试题:赛马问题

据说,这是Google的面试题。面试题目如下:

Question一共有25匹马,有一个赛场,赛场有5个赛道,就是说最多同时可以有5匹马一起比赛。假设每匹马都跑的很稳定,不用任何其他工具,只通过马与马之间的比赛,试问,最少得比多少场才能知道跑得最快的5匹马?(不能使用撞大运的算法

很明显这是一个算法题,网上有很多贴子在讨论这个问题,不过都没有给出一个明确的答案。我想了想,想到下面的一个算法:

1)分成5组A,B,C,D,E,比五场。然后根据每场结果分别给这五组内的五匹马排序(从快到慢)。
2)每组的头名再赛一场,取走第一名,然后该组第二名顶上。
3)重复第二步,直到选出前5名。

这个算法是比较笨的算法,总计需要赛10次,这个算法应该是万无一失的。现在的问题的就,如何优化这个算法,想了想,的确是有优化的空间的。也就是说,是可以少于10次的。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (17 人打了分,平均分: 4.53 )
Loading...
编程命名中的7+1个提示

编程命名中的7+1个提示

前几天Neo写过《编程中的命名设计那点事》,这里也有另外一篇和程序命名的文章,可以从另一个角度看看。

1.- 变量应该是尽可能的望文知意。千万不要使用教材中的命名方式。

  • 好的变量 daysDateRange, flightNumber, carColor.
  • 坏的变量: days, dRange, temp, data, aux…

在我们的日常工作中,有很大数量的开发人员喜欢使用短的变量名,而不是有含义的变量名。这主要是因为我们大学教科书的那些示例所造成的,人都是先入为主,所以,教科书中的那些很抽象,带着演示的变量命名影响了我们一代又一代的程序员,并影响了他们很多年。虽然那些短的,教材式的变量名,可能会让你少打一些字,但其实,这是非常非常不好的。因为软件的维护成本远远大于了软件的开发成本,如果你不取一个好的一点的变量名,那么当进行代码评审时,当进行bug fixing时,当进行代码重构时,当进行代码维护时,你的某个变量名可能会让你一头雾水,不知道所措,还可以会让你走入陷阱,造成更大的时间成本。所以,一个可阅读的代码必然和那些不错的变量名分不开,而这也能让你的软件间接上有更好的质量。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (9 人打了分,平均分: 4.56 )
Loading...
优质代码的十诫

优质代码的十诫

1.- DRY: Don’t repeat yourself.

10commandementsDRY 是一个最简单的法则,也是最容易被理解的。但它也可能是最难被应用的(因为要做到这样,我们需要在泛型设计上做相当的努力,这并不是一件容易的事)。它意味着,当我们在两个或多个地方的时候发现一些相似的代码的时候,我们需要把他们的共性抽象出来形一个唯一的新方法,并且改变现有的地方的代码让他们以一些合适的参数调用这个新的方法。

DRY 这一法则可能是编程届中最通用的法则了,目前为止,应该没有哪个程序员对这一法则存有异议。但是,我们却能发现,一些程序在编写单元测试(unit testing)时忘记了这一法则:让我们相像一下,当你改变一个类的若干接口,如果你没有使用DRY,那么,那些通过调用一系例类的接口的unit test的程序,都需要被手动的更改。比如:如果你的unit test的诸多test cases中没有使用一个标准共有的构造类的方法,而是每个test case自己去构造类的实例,那么,当类的构造函数被改变时,你需要修改多少个test cases啊。这就是不使用DRY法则所带来的恶果。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (16 人打了分,平均分: 4.88 )
Loading...
编程中的命名设计那点事

编程中的命名设计那点事

在我开始设计系统的时候,我会花去很多时间去设计命名,因为好的命名和好的设计是分不开的。

In the beginning was the Word, and the Word was with God, and the Word was God
太初有道。道与神同在,道就是神。 (约翰福音第一章,第一节)

在设计过程中给类,方法和函数好的命名会带来好的设计,虽然这不是一定成立,但是如果坏的命名那一定不会给你带来好的设计。在设计过程,如果你发现你很难命名某一个模块,某个方法时,可能你真正遇到的问题不是难命名的问题,而是这个设计是否真的合理,你或许应该花更多的时间来重新设计一下你的模块。

好的命名不仅会带来好的设计,好的命名还提高了程序的可读性,降低代码维护的成本。另一方面,如果糟糕的命名会给代码带来一堵无形的墙,让你必须深入代码去研究代码具有的行为,增加你理解代码的时间。

为此我总结了几条关于命名的指导原则,希望这几条原则能为你的命名设计带来帮助,我使用的是C++的语法,当然这些原则也很容易扩展到其他语言中去。

类型命名(类,接口,和结构)


名字应该尽量采用名词
Bad:           Happy
Good:          Happiness

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (23 人打了分,平均分: 4.57 )
Loading...
菜鸟学PHP之Smarty入门

菜鸟学PHP之Smarty入门

  刚开始接触模版引擎的 PHP 设计师,听到 Smarty 时,都会觉得很难。其实笔者也不例外,碰都不敢碰一下。但是后来在剖析 XOOPS 的程序架构时,开始发现 Smarty 其实并不难。只要将 Smarty 基础功练好,在一般应用上就已经相当足够了。当然基础能打好,后面的进阶应用也就不用怕了。
  
  这篇文章的主要用意并非要深入探讨 Smarty 的使用,这在官方使用说明中都已经写得很完整了。笔者仅在此写下一些自己使用上的心得,让想要了解 Smarty 却不得其门而入的朋友,可以从中得到一些启示。就因为这篇文章的内容不是非常深入,会使用 Smarty 的朋友们可能会觉得简单了点。
  

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (2 人打了分,平均分: 4.50 )
Loading...
C语言下的错误处理的问题

C语言下的错误处理的问题

下面是三种C语言的错误处理,你喜欢哪一种?还是都不喜欢?

/* 问题: 不充分,而且很容易出错,前面成功分配的资源,后面出错需要帮助释放 */
int foo(int bar)
{
        int return_value = 0;
        int doing_okay = 1;
        doing_okay = do_something( bar );
        if (doing_okay)
        {
                doing_okay = init_stuff();
        }
        if (doing_okay)
        {
                doing_okay = prepare_stuff();
        }
        if (doing_okay)
        {
                return_value = do_the_thing( bar );
        }
        return return_value;
}

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (5 人打了分,平均分: 4.40 )
Loading...
一个排序算法比较的网站

一个排序算法比较的网站

下面这个网站是一个非常丰富的排序算法的网站。

Sorting Algorithm Animations
http://www.sorting-algorithms.com/

这是一个非常不错的排序算法的网站,当你打开这个网站的时候,请不要因为看到很多个图片的大红叉而鄙视它。你先点击网页上方的Problem Size,选择一个尺寸,20,30,40还是50,都行,于是你就可以看到下面整个大表中有图片显示出来了。如下所示:

sort

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (15 人打了分,平均分: 5.00 )
Loading...
深入浅出单实例Singleton设计模式

深入浅出单实例Singleton设计模式

单实例Singleton设计模式可能是被讨论和使用的最广泛的一个设计模式了,这可能也是面试中问得最多的一个设计模式了。这个设计模式主要目的是想在整个系统中只能出现一个类的实例。这样做当然是有必然的,比如你的软件的全局配置信息,或者是一个Factory,或是一个主控类,等等。你希望这个类在整个系统中只能出现一个实例。当然,作为一个技术负责人的你,你当然有权利通过使用非技术的手段来达到你的目的。比如:你在团队内部明文规定,“XX类只能有一个全局实例,如果某人使用两次以上,那么该人将被处于2000元的罚款!”(呵呵),你当然有权这么做。但是如果你的设计的是东西是一个类库,或是一个需要提供给用户使用的API,恐怕你的这项规定将会失效。因为,你无权要求别人会那么做。所以,这就是为什么,我们希望通过使用技术的手段来达成这样一个目的的原因。

本文会带着你深入整个Singleton的世界,当然,我会放弃使用C++语言而改用Java语言,因为使用Java这个语言可能更容易让我说明一些事情。

阅读全文 Read More

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