_itoa_s有关问题

_itoa_s问题

string strTemp;
_itoa_s(0,(char*)strTemp.c_str(),10,10);
strTemp += ".";

itoa_s操作后，对strTemp 操作无效，不知道为什么？
[解决办法]
无源码，无真相。下面我列出vs2010中string部分代码回答你的问题。

const _Elem *c_str() const
{// return pointer to null-terminated nonmutable array
return (_Myptr());
}

const _Elem *_Myptr() const
{// determine current pointer to buffer for nonmutable string
return (this->_BUF_SIZE <= this->_Myres ? this->_Bx._Ptr
: this->_Bx._Buf);
}

从这里我们可以看出，c_str()的结果就是_Myptr中的那一句。
说一下微软string的实现。为了提高小字符串的效率，string内部有一个16个字节的缓冲区这样的东西（具体我不解释太详细，能解释问题就行，以后有时间可以自己多看看源码，很有帮助的），当字符串长度小于16的时候，字符是直接存储在这个缓冲区中的，如果超过了则会再另外分配空间。
_BUF_SIZE在存储char字符串的时候可以看成是常量16，_Myres可以理解为当前可以容纳的字符个数。string使用默认构造函数初始化的时候，因为有个16字节的缓冲区，所以_Myres为15，因为最后一个位置要看需求补'\0'的，不能用。你此时直接调用c_str，比较为false，这时候返回_Bx._Buf。这是个什么呢？我们可以把_Bx看成一个联合。

union BX_TYPE
{
    char _Buf[_BUF_SIZE];
    char* _Ptr;
}

_Buf就是那个所谓的缓冲区，_Ptr是在缓冲区不够用的时候，在外部分配的内存的指针。所以，当使用缓冲区存储数据的时候呢，第一个字符的起始位置为_Buf，而不用缓冲区的时候呢，第一个字符的起始位置为_Ptr。
如果直接调用_itoa_s(0,(char*)strTemp.c_str(),10,10);函数会把格式化之后的字符串写入到_Buf开头的内存区域中。很不幸的是，本来该报错的一个操作，因为_Buf后面正好有空闲位置而表现得相当正常。之所以说不幸，是因为c_str()返回的是一个const指针，我们绝对不应该改写其指向的内存的内容。string的实现机制各式各样，你永远不可能知道这样做会导致怎样的错误。
在我的vs2010中，这段代码看起来是正常的，而且strTemp还可以正常加字符串呢。你的不行，说明你的机器环境和我的不一样。不过也没必要深究这种差异了。
说了为什么错，再来说说正确的做法，毕竟你是为了解决问题而来嘛。如果用C++的做法，你应该：

#include <sstream>
using namespace std;
int value = 100; // 要转换的整数
stringstream ss; // c++中用于格式化字符串的流
ss << value;
string strTemp;
ss >> strTemp; // 此时strTemp变为"100"
strTemp += "."; // 后面想干啥依然可以

[解决办法]
其实直接这样就行。

std::string const a = std::to_string(10);

[解决办法]

引用:

引用:其实直接这样就行。
C/C++ code?1std::string const a = std::to_string(10);
g++ 4.7.2表示不认识这种东西，呵呵。这就是实现的差异。

g++-4.7.0 表示你的测试有问题.我刚试了 4.7.2 没问题，看来你是理解的差异了。
[解决办法]
我从来不用 itoa 这样的东东，还是 boost 简单干脆:
#include <boost/lexical_cast.hpp>
int number = 2325252;
string id = boost::lexical_cast<string>(number);