|
Will this[^] give you some pointer ?
Regards,
Paresh.
|
|
|
|
|
revanth1985 wrote: Can we access contents of history folder?
Yes, assuming you have permission. Just access the contents like you would any other folder.
"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Hi all,
I have a CString and I want to store part of it into a buffer. My buffer is in fix size,
char fixBuffer[24];
Every CString is more than 24 in size. That mean I only need to store the initial 24bytes only. How can I do that.
I appreciate your help all the time...
Eranga 
|
|
|
|
|
_tcsncpy(fixBuffer,yourstring,23);<br />
fixBuffer[23] = 0;
CString has an operator LPCTSTR() which means you can avoid messing about with GetBuffer(). the fixBuffer[23] = 0; ensures that for those CStrings which are longer than 24 characters they get NULL terminated correctly, for CStrings shorter than 24 characters _tcsncpy will NULL terminate them at the correct point anyway.
|
|
|
|
|
Thanks. I have a question, no luck on MSDN at all.
Say according to the above code I red the string. Now where is pointed on the CString, at the beginning or the 24th character? I'm confusing it.
I appreciate your help all the time...
Eranga
|
|
|
|
|
Sorry I am not understanding that at all. The operator LPCTSTR() of CString always points to the 1st character. You tell the _tcsncpy() to copy only 23 characters with the last parameter to it. Then you ensure that the 24th character of your fixBuffer contains a NULL.
|
|
|
|
|
Ya thats true, I got the point. What I'm asking is, after reading the first 24 characters, where the operator LPCTSTR() points to the CString. Either on 1st character or 24ht character.
In other words, if I use the same operator to read the CStrign from where it begins.
Hope it is clear to you.
I appreciate your help all the time...
Eranga
|
|
|
|
|
The operator LPCTSTR() of CString always points to the 1st character.
If you want to read out sequential 24 character chunks, you will have to use a different mechanism. One suggestion:
char fixBuffer[25]; // note use of 25 to allow for a terminating NULL
int nLength = yourstring.GetLength();
int nStart;
for(nStart = 0;nStart<nLength;nStart+=24)
{
_tcsncpy(fixBuffer,&yourstring[nStart],24);
fixBuffer[24] = 0;
// do something with fixBuffer
}
|
|
|
|
|
That is interesting. I'll try it and back to here if I got any issue.
Thanks again.
I appreciate your help all the time...
Eranga
|
|
|
|
|
Roger Broomfield wrote: _tcsncpy(fixBuffer,&yourstring[nStart],24);
You can't do that with a CString. You have to use (with care) GetBuffer method.
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.
|
|
|
|
|
You are partially correct. I made one mistake in not including the casting to LPCTSTR. YES you can do this in the context I am using because I am ensuring that access is not attempted outside of the boundaries of the CString and object, and that the LPCTSTR operator is used to ensure that the CString object isnt changed during its usage.
char fixBuffer[25]; // note use of 25 to allow for a terminating NULL
int nLength = yourstring.GetLength();
int nStart;
for(nStart = 0;nStart<nLength;nStart+=24)
{
_tcsncpy(fixBuffer,&((LPCTSTR)yourstring)[nStart],24);
fixBuffer[24] = 0;
// do something with fixBuffer
}
|
|
|
|
|
Roger Broomfield wrote: You are partially correct
Oh no, I'm never partially correct! 
An hazard of your code: what happens if nLength < 24?
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.
|
|
|
|
|
refer the documentation of _tcsncpy[^] in the remarks section:
The strncpy function copies the initial count characters of strSource to strDest and returns strDest. If count is less than or equal to the length of strSource, a null character is not appended automatically to the copied string. If count is greater than the length of strSource, the destination string is padded with null characters up to length count.
So even if yourstring.IsEmpty() is true the code I pasted will work without generating an exception. I used to use it in at least one place, in one of my projects, then I optimized the CString out of the class and replaced it with an array of TCHAR's because the way I was using it was fragmenting memory badly. Usage was that I was creating thousands of instances of the class in a CArray which is contiguous, but the CStrings were allocated and reallocated numerous times in every instance. Also the strings had a maximum length of 16 characters and in release build CString has a minimum AllocationSize of 64 characters.
|
|
|
|
|
_tcsncpy is hazardous developer tolerant  .
![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
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.
|
|
|
|
|
Maybe, maybe not. The most common mistake I have seen (and even done myself) is :-
TCHAR strdest[24];
_tcsncpy(strdest,_T("The quick brown fox jumped over the lazy dog"),24);
here I have not allowed for the terminating NULL. So the next time I use strdest as a source it will overflow into the stack, ie:
_tprintf(strdest);
will not display
The quick brown fox jump
there will be random garbage on the end
and worse is if I manually NULL terminate it using the same logic
strdest[24] = 0;
that will probably generate a stack exception on return because I have overwritten the stack.
|
|
|
|
|
Roger Broomfield wrote: Maybe, maybe not.
Don't care about, I was just kidding
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.
|
|
|
|
|
CPallini wrote: _tcsncpy is hazardous developer tolerant
what about _tcsncpy_s() ? 
t
|
|
|
|
|
Eranga Thennakoon wrote: ...after reading the first 24 characters, where the operator LPCTSTR() points to...
_tcsncpy() does not change anything within the CString object. The second argument is the address from which to start copying.
"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Thanks for all,
Actually I've come across with a new requirement and now my data in a char buffer. I want to read a fixed amount, actually the in to char fixBuffer[24];, from the larger buffer. Can you give some clue on it.
I appreciate your help all the time...
Eranga
|
|
|
|
|
Hello everyone,
I am using Visual Studio 2005 and I am wondering whether we could debug into the global delete operator?
I have tried to debug by setting a break point to delete statement, but I could only debug into destructor.
My understanding is, when we call delete, the internal operations are,
1. invoking destructor;
2. invoking global delete operator.
Is my understanding correct?
For example,
<br />
class Foo {<br />
<br />
int i;<br />
<br />
public:<br />
<br />
Foo()<br />
{<br />
i = 100;<br />
}<br />
<br />
~Foo()<br />
{<br />
i = 0;<br />
}<br />
};<br />
<br />
int main (int argc, char** argv)<br />
{<br />
Foo* f = new Foo();<br />
<br />
delete f;
<br />
return 0;<br />
}<br />
thanks in advance,
George
|
|
|
|
|
why don't you just place a break point in the destructor of the object?
|
|
|
|
|
Thanks Haroon,
I can debug into the destructor, but can not debug into global delete operator.
regards,
George
|
|
|
|
|
hmmm...actually its debugging into it fine on my end (in VS2003)...
|
|
|
|
|
Hi Haroon,
You mean you can debug into the global delete operator in Visual Studio 2003 from delete <pointer> statement? I am using Visual Studio 2005.
regards,
George
|
|
|
|
|
It's a little more complex than that, at least in a Debug build which is where you'll most likely be debugging. In order to debug into delete properly you need to have installed the CRuntime Source files when you installed Visual Studio ( They can probably be added afterwards form the CD ) and then you need to include their folder in the source paths for your project so the debugger can find the source.
delete is potentially a long and complex process depending on what you're deleting and even with all the source not every stage will be visible. Remember the compiler generates destructors for classes where you don't write one and these will get called but throw you into the disassembler because there is no source just injected machine language. Don't let this put you off.
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
