编程技术

字符串拷贝的小问题

Panic — Fri, 28 Dec 2007 12:33:00 GMT

作者： Panic 2007年12月28日

先看代码：

char buf [20];
strcpy(buf, "abcdefghijklmnopqrstuvwxyz");

呵呵，只有两行，单独看都没错，合起来就麻烦了。
是的，buf的长度只有20字节，无法容纳一个26字符还要外带一个'\0'结尾的字符串。
这个拷贝操作将导致内存写操作越界，从而破坏其他地方的数据。

这并不是一个很难发现的错误，但是当buf的定义和拷贝的时机相隔很远，或者频繁使用了strcat一类函数而忽视了字符串长度的时候，想要找出这个问题，还是比较麻烦的。

解决方法有几种，最简单的就是定义足够大的缓冲区，比如当拷贝路径的时候，使用MAX_PATH宏。但是这有时候不太现实。
我们也可以使用一个string类来管理，比如MFC的CString，或者STL的std::string，都可以，当增长的时候只要调用operator +就可以了。
还有一个方式是使用strncpy，强制每次拷贝都输入一个长度参数。当然，这个参数的数值一般是buf的长度减1，buf的最后一个字节，则在初始化的时候就应该赋值为'\0'。这可以避免很多问题，但是遇到strcat的时候仍旧会有潜在危险，你可以考虑使用strncat，虽然这会带来额外的复杂性。

有符号 & 无符号！改变计算结果的陷阱！

Panic — Wed, 05 Dec 2007 12:09:00 GMT

作者： Panic 2007年12月5日

简单的代码，复杂的问题。
环境：VC6SP5,Win2kPro

int b = 10; //已经赋值为有效数据
const char * str = "1234567890ABCDEF"; //已经赋值为有效的字符串。
int a = (b - strlen(str) ) / 2;

经过了这样的计算，a的值究竟是多少？
结果当然不是 (10-16)/2 的 -3，而是一个天文数字。。。。
a = 2147483645 或者，16进制的 0x7ffffffd

真正的问题代码只有一行，但是结果却令人不快。

这里分析一下产生这个问题的原因：
一个隐含的问题是，strlen的返回值，类型是size_t，也就是unsigned int。这是个无符号类型。
当unsigned int 和 int混合运算的时候，编译器会认为，unsigned int的表达长度比较长，因而结果的类型是unsigned int。
所以 b - strlen(str) 的结果不是 -6，而是和-6具有相同内存布局的unsigned int 值：0xfffffffa，也就是正的4294967290
如果这个数值直接赋值给int，会因为内存布局相同，而避免问题的产生－－问题存在，但是不产生不良效果。但是随后的/2操作把问题彻底暴露出来了。。
/2操作可以认为是一次移位，对于无符号类型，移位后高位补0，于是把原本有符号类型赖以利用的符号位清零了。。最终这个数值赋值给int类型的时候，结果就变成了前面提到的那个可怕的数值。。

有符号数字和无符号数字混合运算的时候，存在一些默认的转换规则，符合这些规则的转换，都不会引发编译器警告或者错误，因此这类问题是难以觉察的。但是，我们需要经常使用的库函数太多了，当参与运算的时候，为每个函数调用都指定一个固定类型的返回值，似乎是不可能的任务。因此如果你的程序中充满各种不同类型的整型运算，那么还是尽量小心一些吧。。。

不同种类的整型比较，到底发生了什么？

Panic — Tue, 17 Jul 2007 03:31:00 GMT

看这么两行代码：
int i = -1;
cout << (char(i) == unsigned char(i)) << endl;
在VC6.0下，永远输出0。而下面这两行代码也永远输出0
int i = 255;
cout << (char(i) == unsigned char(i)) << endl;

而实际上，以上两个代码中，char(i)和unsigned char(i)具有的内存布局都是完全相同的。由于整型之间的类型转换遵循这样的原则：当目标类型比原类型短的时候，直接截断原类型。而当目标类型较长，则无符号类型会直接在高位补0，有符号类型在高位补符号位。

在VC6下，而当两个长度相同，并且具有相同内存布局的整型相比较的时候，编译器做如下的工作：
首先两者长度<=int的长度的时候，全部转化为int，然后实施比较。
所以char(-1)转化的结果是0xFFFFFFFF，而unsigned char(-1)转化的结果是0x000000FF。两者作为int比较的时候，自然是不相等的。
但是，特别的，当两者长度刚好是int长度的时候，比较的结果仅取决于内存布局，而有符号和无符号的转化也不会改变内存布局。

这个事实引起了一个问题，当我们使用char/unsigned char,short/unsigned short这类比int短的类型的时候，无符号类型的变量是绝对不会和有符号的-1相等的，而使用int的时候，int(-1)和unsigned int(-1)则是完全相等的。这使得修改变量类型会引发比较结果的变化，尤其是在做变量扩展，或者在模板代码中这个问题有可能会引发难以觉察的错误。

对这个问题的建议是：永远都不要进行有符号类型和无符号类型之间的数值比较，不同长度的类型之间的比较也要尽量避免。

配置apache，Cannot load php5apache2.dll的错误解决

Panic — Wed, 07 Feb 2007 13:08:00 GMT

被这个问题困扰了一个晚上，搜索了很久都没有找到解决办法。
最后无意间看到这个：
anthony 发表于2006-07-21 15:19:00 IP: 221.223.64.*
关于 "cannot load php5apache2dll" 的问题，是因为php自带的php5apache2.dll只能跟某个特定版本的apache2使用的缘故。只需要到 http://www.apachelounge.com/download/ 下php5apache2.dll-php5.1.x.zip 然后照里面的说明跟着做问题就解决了。

我下载的apache是最新版，貌似php还没有制作对应的php5apache2.dll文件，所以出错了，重新安装了一个旧版的apache就解决了。

郁闷。。。

星星出的丢玻璃棋子的题目，我的解法

Panic — Thu, 07 Dec 2006 07:55:00 GMT

星星链接：
http://blog.vckbase.com/bruceteen/archive/2006/12/07/23394.html
原题：
问题：
有一幢100层高的大楼，给你两个完全相同的玻璃棋子。
假设从某一层开始，丢下玻璃棋子就会破碎。那么怎么利用手中的两颗棋子，
用一种什么样的最优策略，知道这个临界的层高呢？

我的解法，保证所有最坏情况下，需要丢棋子的次数为一个有限次数。
原理如下：
首次丢棋子的位置是可以有变化的，第二次丢棋子则只能从最近的没有破的那一层向上依次丢，不然就得不到结果。
假设极限次数限制为n，那么丢了m次棋子之后，剩余的层数必须等于n-m才能保证能在n次内找到答案。
题目变成求这个n的最小值。
用逆推法，100层是不用考虑的，如果99层丢没有破，答案就是100层。所以最坏情况下，最后一次丢棋子是在99层。
倒数第二次要保证如果没有破，则只剩1层需要测试，如果破了，则也只有一层需要测试。
倒数第二次只能是98层，其后需要测试的两层分别是99和97。
倒数第三次就只能是96层，96层如果破了，有两层需要测试，向上就是98和99（或97），向下就是95，94。
所以倒数第四次一定是93层。
依次类推，最后得到一个逆序数列：
99,98,96,93,89,84,78,71,63,54,44,33,21,8
这个数列逆过来，就是丢棋子的正确顺序。
代码如下：

#include <iostream>
using namespace std;
bool throw_at(int i)
{
    int result = 55; //set the result
    if( i >= result ) return true;
    return false;
}
int foo()
{
    int array[] = {1,8,21,33,44,54,63,71,78,84,89,93,96,98,99};
    int count = 0;
    for( int i = 1; i < ( sizeof(array)/sizeof(array[0]) ); ++i )
    {
        bool broken = throw_at(array[i]);
        ++count;
        if( broken )
        {
            for( int j = array[i-1]; j < array[i]; ++j )
            {
                if( throw_at(j) )
                {
                    ++count;
                    cout << "Throw " << count << " times." << endl;
                        cout << "Result is: " << j << endl;
                    return j;
                }
            }
            cout << "Throw " << count << " times." << endl;
                cout << "Result is: " << array[i] << endl;
            return i;
        }
    }
    cout << "Throw " << count << " times." << endl;
        cout << "Result is: " << 100 << endl;
    return 100;
}
int main(int argc, char* argv[])
{
    foo();
    return 0;
}

CMonthCalCtrl的一个BUG

Panic — Wed, 06 Dec 2006 03:38:00 GMT

环境：win2k pro, vc6.0 sp5
bug描述：
CMonthCalCtrl::GetCurSel函数的返回值是错误的。

测试代码：
//CMonthCalCtrl m_c; //定义在某处。
//当用户选择了不同的日期后
CTime t;
m_c.GetCurSel(t);
CString s = t.Format( "%A, %B %d, %Y" );
//之后s的值和用户选择的数值相去甚远。

bug跟踪：
通过简单的跟踪，发现问题出在控件本身对消息的响应上，在winctrl5.cpp中：
BOOL CMonthCalCtrl::GetCurSel(CTime& refTime) const
{
ASSERT(::IsWindow(m_hWnd));

// can't use this method on multiple selection controls
ASSERT(!(GetStyle() & MCS_MULTISELECT));

SYSTEMTIME sysTime;
BOOL bResult = (BOOL)
::SendMessage(m_hWnd, MCM_GETCURSEL, 0, (LPARAM) &sysTime);
//这个消息返回后，sysTime的wMinute和wSecond成员的数值是错误的。

if (bResult)
refTime = CTime(sysTime);

return bResult;
}

解决方法：自己发消息，然后修正sysTime的对应成员。

从一个小问题衍生的方法－－三进制数

Panic — Wed, 11 Oct 2006 11:02:00 GMT

从一个小问题衍生的方法－－三进制数

作者： Panic 2006年10月11日

有一个很久以前（可能有数百年）的问题，是这样：

一个重40磅的砝码，不小心摔成了4块，结果这4块刚好都是整数，而且可以用天平称量1～40以内的任何重量。请问这4块的重量分别是多少。

问题很好分析，天平的特性是，砝码可以放置在两边。也就是说，一个1磅的砝码，可以放在右侧作为砝码，也可以放在左侧作为称量物，放在左侧则最终的称量结果要减去砝码重量。

我们现在考虑只有两个砝码的情况，其中一个砝码是1磅，另外一个假设是2磅。那么称量情况是这样：

1磅砝码    2磅砝码      称量的重量
右侧       右侧         3磅
不放       右侧         2磅
右侧       不放         1磅
左侧       右侧         1磅

从这个表可以看出，当大的砝码是2磅的时候，砝码分置两侧，并不能得到一个新的称量结果，所以大的砝码至少应该有3磅，结果变成：

1磅砝码    3磅砝码      称量的重量
右侧       右侧         4磅
不放       右侧         3磅
右侧       不放         1磅
左侧       右侧         2磅

两颗砝码，可以称量4种重量。用大于3磅的砝码也可以称量4种重量，但是那样的话结果就不连续了。

现在把这两个砝码作为一个组合，加入更大的第三颗砝码，那么为了同样满足砝码分置两侧得到不同结果，第三颗砝码的重量应该是：2×两颗之和+1，也就是9磅。然后利用前两颗的拆分交替，就可以得到1～13的任何重量。

同样的可以轻易计算出第三颗砝码是 13×2+1 = 27磅。

这样，1，3，9，27，4颗砝码组成了一个以3为倍率的等比数列。这4颗砝码可以称量1～40之间的任何整数重量。

回到最初的问题，我们可以抽象为：用4个位，表达至少40个不同的量。而考虑到砝码有放在左侧，右侧和完全不使用三种状态，这其实是个三进制数，一个有4位的三进制数。

4位三进制数能够表达的范围是81，在天平的问题中，称量物放在左侧和右侧可以认为是两种不同的结果（或者说是符号位），而称量物也没有放置（或者说重量为0）也算一种情况，刚好造成81种结果。

这个问题到此就完整的结束了。

之所以会考虑这个问题，是因为我在设计一个单片机电路的时候，无意中利用到单片机口线的三种状态。

三种状态就表达了一个三进制位，这样利用7条口线，就可以表达3^7 = 2187种状态，这个数字已经超过了11bit的二进制位(2048)，利用这个特性可以用更少的口线，实现更多的功能，更有效的利用单片机有限的资源。

旧事重提，反转一个字节的算法讨论

Panic — Wed, 06 Sep 2006 08:17:00 GMT

作者： Panic 2006年9月6日

很久以前发过一个相关的随笔：反转一个字节的算法
以及相关的效率探讨：效率的边界－－几种反转字节算法分析

昨天周星星旧事重提，又引发了对这个简单问题的讨论，相关的东西以前已经讨论了很多了，这里不再重复，只提供两个新的算法：

首先是周星星的新算法：

unsigned char reverse8( unsigned char c )
{
    c = ( c & 0x55 ) << 1 | ( c & 0xAA ) >> 1;
    c = ( c & 0x33 ) << 2 | ( c & 0xCC ) >> 2;
    c = ( c & 0x0F ) << 4 | ( c & 0xF0 ) >> 4;
    return c;
}

经过测试，这是目前在32位环境，除查表法之外的最高效算法。

我也尝试了一下，要超越这个算法的效率的确很难，几经周折也没有能够成功。不过这个过程中，考虑了另外一个算法，需要64位环境的支持，代码如下：

typedef unsigned long  U_INT64;
//64位环境。long应该是64bit长度。
//如果有更适合的类型，替换这个typedef即可。
typedef unsigned char U_INT8;
U_INT8 reverse64( U_INT8 C )
{
    U_INT64 c = C;
    U_INT64 a = 0xF7B3D591E6A2C480;
    U_INT8 result = ( ( a >> ( (c & 0x0F) << 2 ) ) << 4 )
        | ( ( a >> ( (c & 0xF0) >> 2 ) ) & 0x0F );
    return result;
}

这个算法的本质还是查表法，但是利用64bit变量代替了表，利用移位代替了查表过程中的寻址。
理论上这个算法应该有更高的效率，尽管仍然无法超越原始的查表法。

但是因为我没有64位的编译环境和运行环境，所以在此恳请有条件的朋友帮忙测试一下这两个代码在64位环境下的表现，参考的测试代码如下：

typedef unsigned long  U_INT64;
typedef unsigned char U_INT8;
U_INT8 reverse64( U_INT8 C )
{
    U_INT64 c = C;
    U_INT64 a = 0xF7B3D591E6A2C480;
    U_INT8 result = ( ( a >> ( (c & 0x0F) << 2 ) ) << 4 )
        | ( ( a >> ( (c & 0xF0) >> 2 ) ) & 0x0F );
    return result;
}

U_INT8 reverse8( U_INT8 c )
{
    c = ( c & 0x55 ) << 1 | ( c & 0xAA ) >> 1;
    c = ( c & 0x33 ) << 2 | ( c & 0xCC ) >> 2;
    c = ( c & 0x0F ) << 4 | ( c & 0xF0 ) >> 4;
    return c;
}

//效率测试代码：
#include <iostream>
using namespace std;
inline U_INT64 GetCycleCount()
{
        __asm RDTSC //获取CPU时间戳
}

int main(int argc, char* argv[])
{
        U_INT64 i = 0,n = 10000;
        U_INT8 c = 0;

        U_INT64 t1 = GetCycleCount();

        for( i = 0; i < n; i++)
                c += reverse64(i);

        U_INT64 t2 = GetCycleCount();

        for( i = 0; i < n; i++)
                c += reverse8(i);

        U_INT64 t3 = GetCycleCount();

        cout << " T1 = " << U_INT64((t2-t1)/n)
                << " T2 = " << U_INT64((t3-t2)/n)
                << " C = " << c         //输出c是为了避免编译器优化。
                << endl;

        return 0;
}

由于对64位环境近乎无知，所以代码可能无法直接编译运行，仅供参考。
谢谢合作:)

奇怪的代码？

Panic — Fri, 28 Jul 2006 09:11:00 GMT

作者： Panic 2006年7月28日

第一个：

int i = 0;
i.~i();

第二个：

int i = 0; int j = 0;
i.~j();

第三个：

~int();

第四个：

~0();

第五个：

0()()()()()();

这些都是合法的代码么？^_^

一个很巧妙的错误，欺骗编译器

Panic — Thu, 27 Jul 2006 07:21:00 GMT

一个很巧妙的错误，欺骗编译器。

作者： Panic 2006年7月27日

很久没碰到什么有趣的问题了，今天看到一个，特写随笔一篇以作留念:P

问题的来源：

一种让另外的类对本类成员只读，本类对本类成员可读写的方法。 [所有相关帖子]

例子
//a.h
class a
{
public:
void test();
#ifndef A_CPP
const
#endif
int b;
};

//a.cpp
#define A_CPP
#include "a.h"
#undef A_CPP

void a::test
{
b = 12; //可以写
}

//b.cpp
#include "a.h"
void b()
{
a _a;
_a.b = 12;//编译错误不可写
}
书童 xulingfv 发表于 2006-7-27 10:46:09

周星星的代码：

// a.hpp
struct foo
{
    foo();
#ifdef SOMETHING
    int a;
#endif
    int b;
};

// a.cpp
#define SOMETHING
#include "a.hpp"
#undef SOMETHING
foo::foo()
{
a = 1;
b = 2;
}

// main.cpp
#include "a.hpp"
#include <iostream>
int main()
{
foo test; // 理论上讲，a.cpp和main.cpp中的foo定义不同，是不同的类型，所以应当报foo()未实现，但实际上却正确
std::cout << test.b << std::endl; // 输出1
}

上面的代码，有兴趣的可以试试，这里只说明问题：

首先澄清几件事：

1，对编译器来说，一个函数定义在什么地方并不重要，无论foo::foo()定义在哪里，它都是foo类型的构造函数。

2，对链接器来说，区分不同函数（或者类型）的唯一方法是这个函数最后生成的符号名字，如果存在两个相同的符号，就会报重定义的错，而反之，无论这个符号来自何处，链接器都会把这个符号和对应的函数代码链接在一起。

3，对同一个编译单元，或者说，同一个.C/.CPP文件，里面的每个定义只会生成一份OBJ代码，模板则会为每个类型生成一份代码－如果可能的话。

这几件事情澄清之后，其实上面的代码就没有任何问题了，简单的说明一下：

第一段代码：

a.cpp和b.cpp中的class a，毫无疑问并非同一个类型，但是利用#define和#undefine，强制生成了完全相同的类型名字。

为了区分，这里把a.cpp中的class a称作a1，b.cpp中的称作a2。

当编译a.cpp的时候，编译器使用的是含有int b的定义，这时候void a::test是void a1::test。

而编译b.cpp的时候使用的是含有const int b的定义这时候a _a;其实是a2 _a;

这两个类型中因为只存在一个成员是否是const的差别，一般情况下具有相同的内存布局，所以成员函数（包括构造函数）的调用不会出现太大的问题，但是实际上，这是两套不同的类型生硬的捆绑在一起的结果。

假如通过a2来调用test函数，由于编译器为a1生成的void a1::test和void a2::test的符号完全一致，于是链接器很自然的把void a1::test嫁接在了a2的调用点上，造成了a1和a2难以区分的假象。

第二段代码：

其实和第一段完全一样，foo::foo()作为foo1版本的构造函数，它的链接符号和int main()中的foo2版本完全一样，导致链接器错误的把这个函数嫁接在了foo2的构造过程中。

不过这个例子中，foo1和foo2的内存布局不同，所以由此引发的内存越界访问的错误可以通过一个简单的方法测试：

写如下代码：

#include "a.hpp"
#include <iostream>
int main()
{
    int a;
    foo test;
    int b;
    std::cout << a << std::endl; // 输出a
    std::cout << test.b << std::endl; // 输出1
    std::cout << b << std::endl; // 输出b
}

在一般的实现中a和b其中之一会输出数值2，也就是foo::foo()中的第二个赋值。

值得注意的是，在debug版本下这种对编译器的欺骗很可能不会带来实质性的错误，但是经由release版本的优化之后，两种类型定义的差别会显著增大，一般会导致运行期错误。

事实上这种错误以前就出现过，在使用了第三方代码库的项目中，项目自身定义了某个函数而忘记实现，恰好库中也有一个同名但功能却大相径庭的函数，链接器忠实的把错误的函数链接在了用户的调用点，引起一个难以发现和修改的bug。

我们在代码中使用各种命名规范区分名称，使用namespace隔离潜在同名空间，从而最大程度的避免同名函数/类型的问题。而以这种错误为技巧来制造看似有效的手法，会给工程留下隐患。

写到这里，我忽然对早上和释雪探讨的一个问题有了一些认识，问题是这样的：

一个模板
//a.h
template<class T>
class Test
{
};

假如在两个CPP文件中分别以相同的模板参数做了不同的特化（比如写了两个Test<int>的特化代码），会冲突么？答案是不会。而实际使用的特化版本以最先编译的那个单元为准。

要解释这个问题，需要明白另外一件事，就是“模板的代码，在使用的地方必须是可见的”这条规则。

C++ ISO中并没有规定这种行为，那么是什么导致了编译器的这种限制呢？原因就是每个编译单元都不依赖其他单元完成编译，这样一来模板代码就找不到形成OBJ的时机。

具体来说是这样：

假如模板的所有实现代码都存在于某个CPP文件中，当这个CPP文件作为一个编译单元进行解析的时候，因为不知道模板究竟对哪些模板参数进行了实例化，所以也就无从生成OBJ文件。而对所有类型都生成实例在理论上是不可能的。

而在使用了模板的地方，因为不知道模板的实际代码在哪里，也无从为模板生成OBJ文件。这样一来，模板的代码就完全没办法实现了。

于是实际的编译器，应该是采取了这种策略，当编译到使用某个模板的时候，先检查这个模板实例化后生成的符号是否已经存在，如果不存在就根据代码生成实例，并且把符号记录，反之就直接关联已经存在的符号。

由于编译单元的编译顺序完全是由使用者人为控制的，所以编译器自身无法获取首次实例化的时机，那唯一可行的办法就是在每个调用的地方都使得模板代码可见，这样一来无论哪个编译单元首先进行实例化，都可以顺利生成实例。

这条规则有一个隐患是，规则要求的只是可见性，并不要求“同一性”，换句话说，你可以把模板代码写在头文件中，然后所有的使用者都去包含它。也可以把模板的实现代码写在每一个使用它的地方。

如果你使用后一种方法，写在每个文件中的实现代码，可以是各不相同的，能够生成实例的那个版本是首先编译的那个版本。也就是说，程序最终生成的代码，是和编译顺序相关的。

写了这么多，也不知道问题有没有说清楚。

有兴趣的朋友可以写个代码测试下，不同的编译器也许还有不同的细节差异。