C++大小写转换和性能

大小写转换和性能

 

 

 

前言

本文主要讨论最基本的一些大小写转换函数和API,不讨论一些常见的字符串程序库里面的大小写转换接口,另外本文的落脚点是这些转换函数的性能和日常开发中遇到的一些问题。

 

不考虑范围

其实ctype.h里面有定义一套宏,就是不考虑字符是否落在A-Za-z范围,直接计算(直接用加减法或者使用位与或计算,差别不是很大)。显然这样的效率是最高的,但是使用可能是有问题的,遇到中文或者其他友邦的一些字符,可能就转换错了,当然如果已经提前确认过输入会落在A-Za-z范围,则是可以使用这种方法计算的。

#define _tolower(_Char)    ( (_Char)-'A'+'a' )

#define _toupper(_Char)    ( (_Char)-'a'+'A' )

 

C库(MS

转小写

tolower

towlower

_tolower_l

_towlower_l

 

转大写

toupper

towupper

_toupper_l

_towupper_l

 

C库没有提供直接转换整个字符串的函数,都只能转换单个字符。另外要注意的是提供的towlowertowupper这两个函数效率出奇的低,为什么效率低没有去深究,反正tolowertoupper的参数是int,也可以用于宽字符版本,不知道为什么还提供towlowertowupper这两个函数。

 

C++库(MS

转小写

errno_t _strlwr_s(char* str, size_t numberOfElements);

errno_t _wcslwr_s(wchar_t* str, size_t numberOfElements);

 

转大写

errno_t _strupr_s(char* str, size_t numberOfElements);

errno_t _wcsupr_s(wchar_t* str, size_t numberOfElements);

 

同时还提供了一套同名的模版函数,可以直接只传递字符数组名进行转换,原理是利用数组引用推导出了数组大小,再调用原始转换函数,微软在字符串处理函数里面,使用了很多类似的小技巧(crtdefs.h)。

注:带_s后缀的表示是安全转换。

__DEFINE_CPP_OVERLOAD_SECURE_FUNC_0_0(errno_t, _wcslwr_s, __inout_ecount(_Size)wchar_t, _String)

 

#define __DEFINE_CPP_OVERLOAD_SECURE_FUNC_0_0(_ReturnType, _FuncName,_DstType, _Dst) \

    extern "C++" \

    { \

    template <size_t _Size> \

    inline \

    _ReturnType __CRTDECL _FuncName(_DstType (&_Dst)[_Size])\

    { \

        return _FuncName(_Dst, _Size);\

    } \

    }

 

Windows API

转小写

CharLower

CharLowerBuff

 

转大写

CharUpper

CharUpperBuff

 

WindowsAPI大部分都是一些宏,对应的多字节版本和宽字符版本在上面的API后面加上AW

 

STL

STL里面的string没有提供专门的转换接口,但是借助STL里面的算法用类似下面的方法实现(转换函数可以自定义,也可以使用系统提供的函数),这个不多说。

transform(strCostInfo2.begin(), strCostInfo2.end(), strCostInfo2.begin(),::tolower);

transform(strCostInfo2.begin(), strCostInfo2.end(), strCostInfo2.begin(),::toupper);

 

自己实现(考虑范围)

//////////////////////////////////////////////////////////////////////////

static const char s_ch_a_minus_A = 'a' - 'A';

inline char ConvToUpperA(char chConv)

{

    return (chConv >= 'a' && chConv <= 'z')? (chConv & 0xdf) : chConv;

}

inline wchar_t ConvToUpperW(wchar_t wchConv)

{

    return (wchConv >= L'a' && wchConv<= L'z') ? (wchConv & 0x00df) : wchConv;

}

inline char ConvToLowerA(char chConv)

{

    return (chConv >= 'A' && chConv <= 'Z')? (chConv | 0x20) : chConv;

}

inline wchar_t ConvToLowerW(wchar_t wchConv)

{

    return (wchConv >= L'A' && wchConv<= L'Z') ? (wchConv | 0x0020) : wchConv;

}

 

inline void ConvStrToUpperA(char* strConv)

{

    for (size_t i = 0; strConv[i] != '\0'; ++i)

    {

        //if(strConv[i] >= 'a'&& strConv[i] <= 'z')

        //   strConv[i] &= 0xdf;

        strConv[i] = ConvToUpperA(strConv[i]);

    }

}

inline void ConvStrToUpperW(wchar_t* strConv)

{

    for (size_t i = 0; strConv[i] != L'\0'; ++i)

    {

        //if(strConv[i] >=L'a' && strConv[i] <= L'z')

        //   strConv[i] &= 0x00df;

        strConv[i] = ConvToUpperW(strConv[i]);

    }

}

 

inline void ConvStrToLowerA(char* strConv)

{

    for (size_t i = 0; strConv[i] != '\0'; ++i)

    {

        //if(strConv[i] >= 'A'&& strConv[i] <= 'Z')

        //   strConv[i]|= 0x20;

        strConv[i] = ConvToLowerA(strConv[i]);

    }

}

inline void ConvStrToLowerW(wchar_t* strConv)

{

    for (size_t i = 0; strConv[i] != L'\0'; ++i)

    {

        //if(strConv[i] >=L'A' && strConv[i] <= L'Z')

        //   strConv[i] |= 0x0020;

        strConv[i] = ConvToLowerW(strConv[i]);

    }

}

 

和直接转换的区别就在于只对A-Za-z范围的字符进行转换,有一定局限性,但是在大部分场景下是可用的,而且效率够好。

 

性能

说了这么多转换方法,其实我最关心的那种方法的效率最高,直接上测试程序和测试环境吧,让数据说话。

 

测试环境

Windows7 x64 SP1

AMD Phenom(tm) II X4 840T4核)

10G内存

 

测试基本方法

对长度1024字节(不包括结尾0)的字符串进行大小写轮换转换,循环百万次,统计时间。

 

测试结果

====>大小写转换函数时间消耗(循环1000000)<====

直接计算(不考虑范围):[1077] 毫秒

C库函数:[6193]毫秒

C++库函数:[5912]毫秒

STL算法库模版函数(自定义转换):[3557] 毫秒

STL算法库模版函数(系统转换):[6146] 毫秒

自定义的函数:[3791] 毫秒

Windows API[13884] 毫秒

 

====>大小写转换函数时间消耗(循环1000000)<====

直接计算(不考虑范围):[1076] 毫秒

C库函数:[6272]毫秒

C++库函数:[5865]毫秒

STL算法库模版函数(自定义转换):[3292] 毫秒

STL算法库模版函数(系统转换):[6053] 毫秒

自定义的函数:[3666] 毫秒

Windows API[13790] 毫秒

 

多次测试结果表明,显然不考虑范围是最快的,但是可用场景太少,其次就是自定义的大小写转换函数了(像中文之类也没有大小写之说,只需要考虑有限的ascii字符),配合STL的容器和算法可以最大化效率。WindowsAPI的效率则比较低,当然效率低的原因并不是算法的问题,而是考虑的情况比较多,譬如要考虑本地化,考虑一些语种特殊的大小写转换问题等等。

在合适的场景下,使用自定义的大小写转换是完全足够,研究这个花了大约半天时间,问题源于一个URL处理函数的性能问题,经过统计发现,这个函数的大量计算消耗在了URL转小写上面,经过改造之后,性能轻松提升60%

tongji.gif

猜你喜欢

转载自blog.csdn.net/magictong/article/details/44756599
今日推荐