C语言学习之一：sprintf()函数

在Bjarne Stroustrup写的Learning Standard C++ as a New Language中有这样一个程序:

#include<stdio.h>

enum{max=20};

main()

{

  

   char name[max];

   char fmt[10];

   printf( "Please enter your first name: /n");

 

   sprintf(fmt, "%%%ds", max-1);/* 产生一个格式字串，如使用单纯的 %s可能会造成溢位（overflow）*/

 

   scanf(fmt, name);/* 读入至多 max-1 个字元到 name 之中。*/

 

   printf( "Hello %s/n", name);

   return 0;

}

对sprintf函数不太明白,查了一些资料,拿出来和大家分享.

 

先对上面的程序解释一下:

转义序列： %% 转义后为 一个 % ,这里转义后fmt为%19s;(即%%%--->%%ds--->%19s).

就是利用sprintf()做出一个fmt字符串出来，然后再在后面的scanf()中利用这个fmt来控制格式.

 

********************

以下摘自《csdn社区电子杂志－－c&c＋＋杂志》创刊号

 

本文的作者为  ：steedhorse（晨星）   （选录）

 

1：

sprintf 最常见的应用之一莫过于把整数打印到字符串中，所以，spritnf 在大多数场合可以替代itoa。

 

这样，一个整数的16 进制字符串就很容易得到，但我们在打印16 进制内容时，通常想要一种左边补0 的等宽格式，那该怎么做呢？很简单，在表示宽度的数字前面加个0 就可以了。

 

sprintf(s, "%08X", 4567); //产生："000011D7"

 

上面以”%d”进行的10 进制打印同样也可以使用这种左边补0 的方式。

这里要注意一个符号扩展的问题：比如，假如我们想打印短整数（short）-1 的内存16 进制表示形式，在Win32 平台上，一个short 型占2个字节，所以我们自然希望用4 个16 进制数字来打印它：

 

short si = -1;

sprintf(s, "%04X", si);

 

产生“FFFFFFFF”，怎么回事？因为spritnf 是个变参函数，除了前面两个参数之外，后面的参数都不是类型安全的，函数更没有办法仅仅通过一个“%X”就能得知当初函数调用前参数压栈时被压进来的到底是个4 字节的整数还是个2 字节的短整数，所以采取了统一4 字节的处理方式，导致参数压栈时做了符号扩展，扩展成了32 位的整数-1，打印时4 个位置不够了，就把32 位整数-1 的8 位16 进制都打印出来了。如果你想看si 的本来面目，那么就应该让编译器做0 扩展而不是符号扩展（扩展时二进制左边补0 而不是补符号位）：

 

sprintf(s, "%04X", (unsigned short)si);

 

就可以了。或者：

 

unsigned short si = -1;

sprintf(s, "%04X", si);

 

 

2：

浮点数的打印和格式控制是sprintf 的又一大常用功能，浮点数使用格式符”%f”控制，默认保留小数点后6 位数字，比如：

sprintf(s, "%f", 3.1415926); //产生"3.141593"

但有时我们希望自己控制打印的宽度和小数位数，这时就应该使用：”%m.nf”格式，其中m 表示打印的宽度，n 表示小数点后的位数。比如：

sprintf(s, "%10.3f", 3.1415626); //产生：" 3.142"

sprintf(s, "%-10.3f", 3.1415626); //产生："3.142 "

sprintf(s, "%.3f", 3.1415626); //不指定总宽度，产生："3.142"

注意一个问题，你猜

 

int i = 100;

sprintf(s, "%.2f", i);

 

会打出什么东东来？“100.00”？对吗？自己试试就知道了，同时也试试下面这个：

sprintf(s, "%.2f", (double)i);

第一个打出来的肯定不是正确结果，原因跟前面提到的一样，参数压栈时调用者并不知道跟i相对应的格式控制符是个”%f”。而函数执行时函数本身则并不知道当年被压入栈里的是个整数，于是可怜的保存整数i 的那4 个字节就被不由分说地强行作为浮点数格式来解释了，整个乱套了。

 

3:

连接字符串

 

sprintf 的格式控制串中既然可以插入各种东西，并最终把它们“连成一串”，自然也就能够连接字符串，从而在许多场合可以替代strcat，但sprintf 能够一次连接多个字符串（自然也可以同时在它们中间插入别的内容，总之非常灵活）。比如：

 

char* who = "I";

char* whom = "CSDN";

sprintf(s, "%s love %s.", who, whom); //产生："I love CSDN. "

 

strcat 只能连接字符串（一段以’/0’结尾的字符数组或叫做字符缓冲，null-terminated-string），

 

但有时我们有两段字符缓冲区，他们并不是以’/0’结尾。比如许多从第三方库函数中返回的字符数组，从硬件或者网络传输中读进来的字符流，它们未必每一段字符序列后面都有个相应的’/0’来结尾。如果直接连接，不管是sprintf 还是strcat 肯定会导致非法内存操作，strncat 也至少要求第一个参数是个null-terminated-string，那该怎么办呢？我们自然会想起前面介绍打印整数和浮点数时可以指定宽度，字符串也一样的。比如：

 

char a1[] = {'A', 'B', 'C', 'D', 'E', 'F', 'G'};

char a2[] = {'H', 'I', 'J', 'K', 'L', 'M', 'N'};

如果：

 

sprintf(s, "%s%s", a1, a2); //Don't do that!

 

十有八九要出问题了。是否可以改成：

sprintf(s, "%7s%7s", a1, a2);

 

也没好到哪儿去，正确的应该是：

 

sprintf(s, "%.7s%.7s", a1, a2);//产生："ABCDEFGHIJKLMN"

 

这可以类比打印浮点数的”%m.nf”，在”%m.ns”中，m 表示占用宽度（字符串长度不足时补空格，超出了则按照实际宽度打印），n 才表示从相应的字符串中最多取用的字符数。通常在打印字符串时m 没什么大用，还是点号后面的n 用的多。自然，也可以前后都只取部分字符：

 

sprintf(s, "%.6s%.5s", a1, a2);//产生："ABCDEFHIJKL"

 

 

<<因为sprintf函数将输出写入到字符串s中，并以'/0'结束，所以生成的s中有'/0'，所以可以用printf(s),而不用担心会出错>>

 

 

 

在许多时候，我们或许还希望这些格式控制符中用以指定长度信息的数字是动态的，而不是静态指定的，因为许多时候，程序要到运行时才会清楚到底需要取字符数组中的几个字符，这种动态的宽度/精度设置功能在sprintf 的实现中也被考虑到了，sprintf 采用”*”来占用一个本来需要一个指定宽度或精度的常数数字的位置，同样，而实际的宽度或精度就可以和其它被打印的变量一样被提供出来，于是，上面的例子可以变成：

 

sprintf(s, "%.*s%.*s", 7, a1, 7, a2);

 

或者：

 

sprintf(s, "%.*s%.*s", sizeof(a1), a1, sizeof(a2), a2);

 

实际上，前面介绍的打印字符、整数、浮点数等都可以动态指定那些常量值，比如：

 

sprintf(s, "%-*d", 4, 'A'); //产生"65 "

sprintf(s, "%#0*X", 8, 128); //产生"0X000080"，"#"产生0X

sprintf(s, "%*.*f", 10, 2, 3.1415926); //产生" 3.14"

读后补充：

1.sprintf（）的模板亲和性不好，需要为那些与sprintf兼容的类型分别提供对应的版本。

2.sprintf（）的几个特点：a.标准（[C90],[C++03],[C99]）；b.易用，代码明确；c.高效，有额外的内存分配；d.长度不安全；e.类型不安全；f.不可用在模板当中

3.sprintf（）的替代方案：

（a）.snprintf 缺点：调用者还是可能将缓冲区长度算错，导致崩溃；若刚好填满或者大于缓冲区，缓冲区就不会以'\0'结尾，需要_snprintf(buf,buflen-1,"%4d",i);buf[buflen-1]='\0';来解决。而sprintf总会自动加'\0'

（b）.std：：stringstream需要自己加上一次.freeze(false)释放内存。

（c）.std：：strstream被遗弃的

（d）.boost：：lexical_cast好好研究boost库，很有价值，开源库，boost提供的更好的方案关注boost::format

建议：永远不要使用sprintf！！！