|
Gregor S. wrote:
char *a="a sentence\0";
You don't need the extra \0
Gregor S. wrote:
char *b = new char[strlen(a)];
This is the wrong way. Allways alloc +1 byte for the \0
char *b = new char[strlen(a)+1];
"In an organization, each person rises to the level of his own incompetence." Peter's Principle
|
|
|
|
|
I need to convert a CString into a char*. If the CString is called fldName, then is the following allowed?
char* fldName0 = new char [fldName.GetLength()+1];
strcpy(fldName0, fldName);
The definition of strcpy has two char* as arguments, so I am wondering....
Appreciate your help,
ns
|
|
|
|
|
|
Thank you.
Appreciate your help,
ns
|
|
|
|
|
Nishant S wrote:
(LPTSTR)s
NO NO NO. Sorry, I get upset when I see people do that. That is totally wrong and a bad habit to get newbie programmers into.
First off, the second strcpy() argument is a const char* (I'm avoiding the TCHAR typenames because ns obviously doesn't know them). There is no cast needed because CString has a const char* conversion operator that is called implicitly.
Second, casting a CString to a char* breaks the CString interface -- you are using your knowledge of how a CString works internally, which you must not do to maintain OO encapsulation. The correct way to get a non-const pointer is GetBuffer().
--Mike--
Just released - 1ClickPicGrabber - Grab & organize pictures from your favorite web pages, with 1 click!
My really out-of-date homepage
Sonork-100.19012 Acid_Helm
|
|
|
|
|
Michael Dunn wrote:
The correct way to get a non-const pointer is GetBuffer().
Yeah, but ns only wanted a const char *.
To fiddle around with GetBuffer() is unnecessary here, why force CString to allocate new memory when he's only reading it?
But, more to the point, the whole idea of "converting" the CString to char * is a bit fruitless. You can interchange CString operator char * and CString::GetBuffer entirely for read and write operations that need char *, and this will be quicker than what amounts to doing everything twice, not to mention obfuscates the code.
Jon
Signature space for rent. Apply by email to....
|
|
|
|
|
oops. i only part read your answer properly. ignore the bits that make no sense 
Signature space for rent. Apply by email to....
|
|
|
|
|
Michael Dunn wrote:
NO NO NO. Sorry, I get upset when I see people do that. That is totally wrong and a bad habit to get newbie programmers into.
First off, the second strcpy() argument is a const char* (I'm avoiding the TCHAR typenames because ns obviously doesn't know them). There is no cast needed because CString has a const char* conversion operator that is called implicitly.
Second, casting a CString to a char* breaks the CString interface -- you are using your knowledge of how a CString works internally, which you must not do to maintain OO encapsulation. The correct way to get a non-const pointer is GetBuffer().
-- The more I learn, the more I realize how little I know 
Thanks Mike, I always learn something from your posts, even if they aren't my questions! ![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
Nitron
_________________________________________--
message sent on 100% recycled electrons.
|
|
|
|
|
Michael Dunn wrote:
First off, the second strcpy() argument is a const char*
Oops! When ns mentioned that strcpy takes two char*s I sorta got absent minded about it 
Michael Dunn wrote:
Second, casting a CString to a char* breaks the CString interface
Agreed! But here he only wanted a read-only char*. But I agree that it goes against OOP.
Regards,
Nish
p.s. Never on sonork eh? No beer in LA?
Author of the romantic comedy
Summer Love and Some more Cricket [New Win]
Review by Shog9
Click here for review[NW]
|
|
|
|
|
In an attempt to clarify and emphasize Michael's response...
The explicit and gratuitous cast than Nish suggests is very bad practice. The original poster's code was entirely correct.
As Michael said, CString has a conversion operator to LPCTSTR (aka "const char *"). The second argument to strcpy is a const char *, not a char *, so the implicit conversion occurs and everybody's happy.
The gratuitous cast that Nish suggested is unnecessary and could later hide errors introduced by subsequent changes to the code. NEVER USE EXPLICIT CASTS UNLESS YOU ABSOLUTELY MUST!
I might add that the whole idea of allocating this buffer to a dumb pointer and then copying the string into it is quite questionable. We'd need more context to know whether or not there is any justification for it.
|
|
|
|
|
JT Anderson wrote:
explicit and gratuitous
*Nish staggers on to the ground, first Mike's dagger had pierced his chest and now JT's sword had cut his body into two, and bleeds to death*
But seriously thanks, I do have this bad habit. I have a lot of non-MFC code where I have a lot of functions that take char*s and when I reuse them from my MFC code I do make explicit casts from CString to char* (only when I am sure the char*s are read-only as far as the function is concerned, in which case I should actually have declared the arguments as const char* which I didn't do - another bad habit of mine)
But it is a real nasty bad habit and I better get myself out of it
Thanks fellas
Nish
Author of the romantic comedy
Summer Love and Some more Cricket [New Win]
Review by Shog9
Click here for review[NW]
|
|
|
|
|
I think I should write an article "How to Convert CStrings Properly" 
David Wulff:BT::Me:casting CStrings
--Mike--
Just released - 1ClickPicGrabber - Grab & organize pictures from your favorite web pages, with 1 click!
My really out-of-date homepage
Sonork-100.19012 Acid_Helm
|
|
|
|
|
Maybe an article about different type of strings like char*, TCHAR, CString,std::string, etc. that would be great. 
|
|
|
|
|
Actually, I am working on an article about string types and string classes, but I haven't touched it in about a week. I should finish that up since the frequency of string questions (especially about COM and BSTRs) seems to be going up.
--Mike--
Just released - 1ClickPicGrabber - Grab & organize pictures from your favorite web pages, with 1 click!
My really out-of-date homepage
Sonork-100.19012 Acid_Helm
|
|
|
|
|
Cool, i`ll be waiting for it.
|
|
|
|
|
Do this instead in order to get at the CString's bytes:
strcpy (fldName0, fldName.GetBuffer(0));
fldName.ReleaseBuffer();
/ravi
Let's put "civil" back in "civilization"
http://www.ravib.com
ravib@ravib.com
|
|
|
|
|
Wrong.
strcpy (fldName0, fldName);
Signature space for rent. Apply by email to....
|
|
|
|
|
|
The GetBuffer/ReleaseBuffer isn't necessary there. The second argument to strcpy is a const char*, and the CString conversion function (operator LPCTSTR) is called automatically. Your code still works, it's just a bit more complex than necessary.
--Mike--
Just released - 1ClickPicGrabber - Grab & organize pictures from your favorite web pages, with 1 click!
My really out-of-date homepage
Sonork-100.19012 Acid_Helm
|
|
|
|
|
Hi All,
I'm having a problem with the Document/view arch. My problem is this, when a new document is opened, I call my own dll which contains a custom open dialog. This occurs in OnNewDocument. My issue is that if the user cancels out of this dialog without choosing a document, I simply return FALSE out of the OnNewDocument, which causes MFC to destroy the window. When this occurs, the OnCloseDocument is still called and the destructor for my Document class is called, but since the Document object has already been destroyed, i.e. no longer valid, I get a memory access error in the OnCloseDocument and/or the Destructor.
How can I work with this? I've tried several different approaches without much luck
Any suggestions are greatly appreciated. Thanks!
Dan
|
|
|
|
|
Add the bool member m_bInitialized to CYourDoc, set it to false in CYourDoc c'tor. Set it to true in OnNewDocument/OnOpenDocument, but only if everything worked OK. Check m_bInitialized in OnCloseDocument and perform appropriate actions.
Tomasz Sowinski -- http://www.shooltz.com
*** Si fractum non sit, noli id reficere. ***
|
|
|
|
|
Thanks. That was an easy solution. Is this a typical way of dealing with these kinds of issues? Seems kind of a work around a larger issue to me.
Thank you!
Dan
|
|
|
|
|
groover4life wrote:
Is this a typical way of dealing with these kinds of issues?
I guess it is, but I've never experienced the problem you're describing. What exactly are you doing in OnCloseDocument?
Tomasz Sowinski -- http://www.shooltz.com
*** Si fractum non sit, noli id reficere. ***
|
|
|
|
|
I have several Objects that are instantiated upon the opening of a new document to store the data in the formats I need. So I'm creating them dynamically using new. In the OnCloseDocument, I'm cleaning up the "mess" from the current document by checking to see if the pointers are null (basic assertions) and if not null, then I call delete <class> to clean out the memory.
What was happening is the document went away along with the pointers, so those pointers I was cleaning up were pointing out in no-man's land resulting in the memory access error I was having.
Once again, thanks.
Dan
|
|
|
|
|
Just initialize pointers to NULL in CYourDoc c'tor. It's OK to call delete on NULL pointer - it will be no-op. You may also consider using std::auto_ptr.
Tomasz Sowinski -- http://www.shooltz.com
*** Si fractum non sit, noli id reficere. ***
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
