|
Rajesh R Subramanian wrote: I would not recommend the usage of GetBuffer() method for the sake of copying the string content to another TCHAR* .
I agree.
Rajesh R Subramanian wrote: Which means two things: 1. You must never forget to call ReleaseBuffer() after you're done with it. 2. All the member functions on your CString object are *not* guarenteed to work perfectly between the GetBuffer() and ReleaseBuffer() calls.
In fact he took care about both the issues.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
CPallini wrote: In fact he took care about both the issues.
And the first line of my reply was "I'd rather liked it if he had replied to me." His post was something like "hey, use GetBuffer()". He wasn't bothered to explain the issues related to it, mostly because he didn't know it. And you agreed GetBuffer() isn't the best way around to do it.
Nobody can give you wiser advice than yourself. - Cicero
.·´¯`·->Rajesh<-·´¯`·.
Codeproject.com: Visual C++ MVP
|
|
|
|
|
Rajesh R Subramanian wrote: And you agreed GetBuffer() isn't the best way around to do it
In fact it is the only way if you really need a pointer to the string buffer (i.e. whenever CString LPCTSTR cast operator isn't a viable option) though I agree, usually asking for a pointer to editable CString buffer is not a good idea.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
Rajesh R Subramanian wrote: 1. You must never forget to call ReleaseBuffer()
It is similar to new TCHAR []; and delete
Rajesh R Subramanian wrote: 2. All the member functions on your CString object are *not* guarenteed to work perfectly between the GetBuffer() and ReleaseBuffer() calls.
I expect we want to work on TCHAR rather than CString in this context
|
|
|
|
|
Rajkumar R wrote: It is similar to new TCHAR []; and delete
Thanks, but I am not in need of this information.
Rajkumar R wrote: I expect we want to work on TCHAR rather than CString in this context
We may do it, becasue we know it. You can't expect the O.P. to always know it. Also, I've stated several times this is not the best approach to extract the string from a CString object.
Nobody can give you wiser advice than yourself. - Cicero
.·´¯`·->Rajesh<-·´¯`·.
Codeproject.com: Visual C++ MVP
|
|
|
|
|
Rajesh R Subramanian wrote: but I am not in need of this information.
this is not for ur info and to mispell it, the similarity i meant here is, if the person is forgetting to write ReleaseBuffer, the same can happen in delete, and also between CreateFile-CloseHandle, GetDC-ReleaseDC, lock-unlock, ... It all upto the programmer who should be careful writting a single character of production quality code.
Rajesh R Subramanian wrote: We may do it, becasue we know it. You can't expect the O.P. to always know it.
ignorance and carelessness will always leads to bugs. I don't think this argument is supportive.
Rajesh R Subramanian wrote: Also, I've stated several times this is not the best approach
It is not supported by valid statements.
I believe this class is not designed by a team of junk fellows, they might have analysed many usecases. Direct use of CString with C-Style API, System API considering performance (while calling ReleaseBuffer CString is updated without need to assign back the editted one) and ease of use...
Rajesh R Subramanian wrote: I would not recommend the usage of GetBuffer() method for the sake of copying the string content to another TCHAR* .
make no sense, example i have given is tcscpy doesnot mean that it is for the sake of copy.
if you meant that getbuffer is making copy FYI it does return pointer without any copy unless the required buffer size is greater, the editted TCHAR data is also not copied back to CString
|
|
|
|
|
Rajkumar R wrote: this is not for ur info and to mispell it, the similarity i meant here is, if the person is forgetting to write ReleaseBuffer, the same can happen in delete, and also between CreateFile-CloseHandle, GetDC-ReleaseDC, lock-unlock, ..
But then the point here is that GetBuffer() is a member function and so people may just call it like that, while they'd generally know that new and delete, etc., go as pairs. But, they may not know it's the case with GetBuffer(). See here[^] for an example. It is up to the programmer to write good quality code, but then someone who's asking how to extract the string out of a CString will definitely need some assistance in writing good quality code. So, I'd always explain the tradeoffs while using something like GetBuffer().
Rajkumar R wrote: ignorance and carelessness will always leads to bugs. I don't think this argument is supportive.
Again, if I feel that someone may do it in an ignorant way, rather than just providing an answer which may lead him to do somethign in a wrong way, I'd try to correct him when I am answering his query.
Rajkumar R wrote: if you meant that getbuffer is making copy FYI it does return pointer without any copy unless
Do you even think that I wouldn't know this? This shows that you didn't even understand what I was talking about.
Nobody can give you wiser advice than yourself. - Cicero
.·´¯`·->Rajesh<-·´¯`·.
Codeproject.com: Visual C++ MVP
|
|
|
|
|
Rajesh R Subramanian wrote: But then the point here is that GetBuffer() is a member function and so people may just call it like that
Lock is also a member function of CMutex()
Rajesh R Subramanian wrote: Do you even think that ...
that is why i used "if", but i think i pointed what u meant just above that.
"hey, use GetBuffer()" by him, doesnot mean simply code without reading doc, he given a hint, he may not like spoon feeding and use bandwidth for explaining which is already explained in doc. however we used bandwidth enough debating.
|
|
|
|
|
Rajkumar R wrote: Lock is also a member function of CMutex()
Again, Lock and Unlock goes as one pair always. Even newbies would know it, unlike ReleaseBuffer() after GetBuffer().
Rajkumar R wrote: however we used bandwidth enough debating.
I think yes.
|
|
|
|
|
I see an error in your code.
Hint: you're usign generic text mappings.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
I type directly in the reply message, I didn't compile.
I think, if i put _T(""), may be u will ask for #include <tchar.h>
|
|
|
|
|
Rajkumar R wrote: may be u will ask for #include <tchar.h>
of course.
Rajkumar R wrote: I type directly in the reply message, I didn't compile.
My brain-integrated-compiler issued the error!
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
Oh "My brilliant Brain" !!!
|
|
|
|
|
Rajkumar R wrote: Oh "My brilliant Brain" !!!
Indeed.
But not your, mine.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
yes offcource, "My Brilliant Brain" is a program on National Geographic
|
|
|
|
|
So I'm on TV and noone told me.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
wow, error in error statement, Hint in Hint statement.
May be this was because the brain-integrated Spell checker cannot spawn when the heavily loaded integrated compiler.
|
|
|
|
|
Actually the brain-integrated Spell checker is Express Edition .
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
is this useful,
CString szString( "MyString" );
int istrlen= (szString.GetLength() + 1);
LPTSTR lpsz = new TCHAR[ istrlen];
_tcscpy_s(lpsz, istrlen, szString);
|
|
|
|
|
i tried like ur method . but i did not get perfect o/p.
can u tell more
Franics K Antony
|
|
|
|
|
Can you tell what u exactly need, what is the issue u r facing now
|
|
|
|
|
i am using encryption in the server and cliient . in that i want to encrypt my data in the server and to decrypt in the client side .
to encrypt the data want to convert CSTRING into TCHAR ...
Franics K Antony
|
|
|
|
|
Man, u want to encrypt data i agree, but why u r encrypting the question?
What is the issue, can u post the code snippet.
|
|
|
|
|
CString has a operator LPCTSTR meaning that the convertion to a const TCHAR* is automatic. You probably meant converting to an array of TCHAR, not a TCHAR, right ?
|
|
|
|
|
Hello everyone,
I think compiler is too strict in this case. You can see, no data member, no virtual function.
I am using Visual Studio 2008. The compiler error is simply because of Diamond pattern -- duplicate base class? Actually from logical point of view, there should be no ambiguity issue.
Any ideas?
class Base {
public:
int foo() {cout << "Base" << endl;}
};
class Derived1: public Base
{
public:
int foo() {cout << "Derived1" << endl;}
};
class Derived2: public Base
{
public:
int foo() {cout << "Derived2" << endl;}
};
class Final: public Derived1, public Derived2 {
public:
int foo() {cout << "Final" << endl;}
};
int main()
{
Final f;
Final* p = &f;
Base* pb = p;
return 0;
}
thanks in advance,
George
|
|
|
|