int i=atoi(msg.type);
error C2664: 'atoi' : cannot convert parameter 1 from 'class CString' to 'const char *'
what should I do?
int i=atoi(msg.type);
error C2664: 'atoi' : cannot convert parameter 1 from 'class CString' to 'const char *'
what should I do?
CString is not automatically convertible to a character string. Use the following to retrieve a compatible string:
Code:atoi(msg.type.c_str());
thanks for reply
class CMsg : public CObject
{
.....
public:
//CString name;
CString type;
....
};
cMsg msg;
.....
int i=atoi(msg.type);
error C2664: 'atoi' : cannot convert parameter 1 from 'class CString' to 'const char *'
how can I do?
One solution is GetBuffer(). Use const_cast() if required.
Kuphryn
thanks for reply,
int i=atoi(GetBuffer(msg.type));
error C2065: 'GetBuffer' : undeclared identifier
i add #include "Afx.h" in the files's head
i hope you can give me some more code.
thanks very much
GetBuffer() is a CString member function.
type.GetBuffer(0)
Kuphryn
You can use the CString's LPCTSTR operator to give you the char *Hope it will work for youCode:int i=atoi((LPCTSTR)msg.type);
:) ,first thank very much
i tried kuphryn and rxbagain two method.it compiled the same
error C2664: 'atoi' : cannot convert parameter 1 from 'unsigned short *' to 'const char *'
:o ,how can I do?
You must be working with UNICODE project. Convert first the UNICODE string to ANSI to use it in atoiHope it will work for youCode:char buff[100];
wcstombs(buff, (LPCTSTR)msg.type, msg.GetLength());
int i=atoi(buff);
In this case, you don't need to convert if you use the UNICODE version of atoi, _wtoi. Even better is to use _ttoi, which is the TCHAR version and will work for both UNICODE and MBCS: If UNICODE is defined, it will accept a const wchar_t*, if not, a const char*. You don't even need the explicit cast to LPCTSTR, as it will be invoked automatically:And please don't listen to people who tell you to use CString::GetBuffer() in this situation, they don't know what they are talking about. GetBuffer() is used exclusively to gain write access to CString's internal buffer, not to convert from CString to char*. And if you don't be careful to match every GetBuffer() call with ReleaseBuffer(), using that CString object will produce unpredictable results.Code:int i=_ttoi(msg.type);
Furthermore, do not listen to unoriginal rigid people who think they know everything, but have nothing to show. Maybe they have some simple techniques down, but languages come and go. They get caughtup in the techiques and lost the valuable concepts along the way. Sad huh?
Kuphryn
Yes, there are many wrong answers posted by people guessing. It is not so bad if they say they are guessing; I know I often post answers that are a guess. However when they post an answer as if they know what they are doing yet they do not know then that is wrong.Quote:
Originally posted by gstercken
And please don't listen to people who tell you to use CString::GetBuffer() in this situation, they don't know what they are talking about. GetBuffer() is used exclusively to gain write access to CString's internal buffer, not to convert from CString to char*. And if you don't be careful to match every GetBuffer() call with ReleaseBuffer(), using that CString object will produce unpredictable results.
In this situation, the code would have worked if it was not a Unicode problem. So what you or I probably would have said is that it should work therefore there must be something that is not shown in the sample code and not specified in the question. Yet people that have minimal experience with CString guessed at an answer and answered as if they were experts yet they were wrong.
Also, when it is possible to test the code, I usually do. So people could have run a quick test to verify their answers first, for example:Code:CString msgtype("96");
int i=atoi(msgtype);
cout << i << '\n';
You completely missed the point. This is not about languages or techniques, but about providing correct and valuable solutions instead of wrong or misleading answers. If you don't know a solution to a problem, simply don't reply. Others will do. And even if nobody posts a reply, this is still better than a wrong, misleading or unrelated post. Remember: Always know what you say. Don't always say what you know (or pretend to know).Quote:
Originally posted by kuphryn
Furthermore, do not listen to unoriginal rigid people who think they know everything, but have nothing to show. Maybe they have some simple techniques down, but languages come and go. They get caughtup in the techiques and lost the valuable concepts along the way. Sad huh?
And: You know perfectly well that I write this because this was by far not the first time I saw you making this kind of 'One solution is <any unrelated or wrong stuff>' post.
Thanks, Sam. I usually do the same.Quote:
Originally posted by Sam Hobbs
Also, when it is possible to test the code, I usually do. So people could have run a quick test to verify their answers first, for example:
I think I agree with everything but this one part probably does not say what you menat it to say. If you want to edit your post I will probably just delete this post.Quote:
Originally posted by gstercken
Don't always say what you know
gstercken,
You are the one who's missing the point. There are no set rules on software design and implementation. My solution works. Maybe your solution does too, or maybe it does not. The point is that the person wanting answers should get to see multiple solutions and decide what is best.
Kuphryn