|
CString* strData;
int nCount;
if(nCount > 0)
{
strData = new CString[nCount];
}
.
.
.
delete[] strData;
I have understood the problem , Paresh . The nCount is 0. So never the memory is allocated . But what should be the condition to test whether strData is actually initialised (strData is an array of pointers of CString type) before it is actually deleted.
Taruni
|
|
|
|
|
Taruni wrote: But what should be the condition to test whether strData is actually initialised
There is such a condition only if you're disciplinate programmer:
CString* strData = NULL;
int nCount;
if(nCount > 0)
{
strData = new CString[nCount];
}
...
if (strData)
{
delate [] strData;
strData = NULL;
}
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.
|
|
|
|
|
Taruni wrote: But I am trying to delete an array of pointers of CString type.
So, you did something like this ?
CString pArray = new CString[10];
If yes, then you need to use delete[] instead:
delete[] pArray;
|
|
|
|
|
Thank you Cedric Moonen.
CString* strData;
int nCount;
if(nCount > 0)
{
strData = new CString[nCount];
}
.
.
.
delete[] strData;
I have understood the problem . The nCount is 0. So never the memory is allocated . But what should be the condition to test whether strData is actually initialised (strData is an array of pointers of CString type) before it is actually deleted.
Taruni
|
|
|
|
|
Initialise strData with NULL and check strData against NULL before deleting.
CString* strData = NULL;<br />
int nCount;<br />
if(nCount > 0)<br />
{<br />
strData = new CString[nCount];<br />
}<br />
<br />
.<br />
.<br />
.<br />
if(NULL != strData)<br />
{<br />
delete[] strData;<br />
}
Regards,
Paresh.
|
|
|
|
|
Paresh Chitte wrote: Initialise strData with NULL
Yes.
Paresh Chitte wrote: and check strData against NULL before deleting.
That's not necessary. Deleting NULL is guaranteed to be a no-op.
|
|
|
|
|
Nemanja Trifunovic wrote: That's not necessary. Deleting NULL is guaranteed to be a no-op.
The test maybe useful to mark again with NULL the deleted pointer:
if (strData)
{
delete [] strData;
strData = NULL;
}
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.
|
|
|
|
|
Paresh Chitte wrote: if(NULL != strData)
{
delete[] strData;
}
I suggest to replace the above with:
if(NULL != strData)
{
delete[] strData;
strData = NULL;
}
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.
|
|
|
|
|
Initialize your pointer to NULL:
CString* strData = NULL;
You should always always initialize your pointers to NULL.
|
|
|
|
|
Cedric Moonen wrote: You should always always initialize your pointers to NULL.
Unless you initialize them with something else
I.e., this is acceptable:
<br />
CString* strData = new CString[count];<br />
In any case this new/delete construct is overused and leads to code that is not exception-safe and is hard to maintain. Wouldn't it be easier and safer to simply write something like:
<br />
vector<CString> strData;<br />
or even:
<br />
CStringArray strData;<br />
|
|
|
|
|
Nemanja Trifunovic wrote: Unless you initialize them with something else
I.e., this is acceptable:
CString* strData = new CString[count];
I agree on the above and suggest the following (weaker than the Cedric Moonen one)
gold rule of the disciplined coder:
You should always initialize your pointers
Nemanja Trifunovic wrote: In any case this new/delete construct is overused and leads to code that is not exception-safe and is hard to maintain. Wouldn't it be easier and safer to simply write something like:
I don't blame for new/delete usage. You've to be disciplined though.
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: I don't blame for new/delete usage. You've to be disciplined though.
A LOT of discipline and hard work is needed to make this code exception-safe:
A* a = new A;
...
B* b = new B;
...
C* c = new C;
...
delete c;
delete b;
delete a;
|
|
|
|
|
Of course, one can choose the proper data depending on the coding scenario. BTW at the very end of your reasonment there's managed code!!
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: BTW at the very end of your reasonment there's managed code!!
Nope!
Managed code would help in this particular scenario, but if we were allocating resources other than memory (files, handles, db connections...) it wouldn't help at all.
What I am advocating here is the use of a simple and effective idiom known as RAII[^]. It enables automatic release of the allocated resources in a deterministic way without use of a GC.
|
|
|
|
|
Managed code works in the same direction.
What I am advocating, instead, it is developer freedom to deallocate resources by itself.
Please note: it always depends on the coding scenario: complex projects usually need some paradigm like the one you suggest.
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.
|
|
|
|
|
Hello All,
I have an Application in VC++6.0 using MFC. I have to build this application in VC++2005. I tried to build this but so many errors are coming. How can I port my applicaion. What steps I should follow to do this. The common bug is given below :-
error C4335: Mac file format detected: please convert the source file to either DOS or UNIX format.
This is comming many times. Can you tell me how can i debug this.
Regards,
Yudhisthira
|
|
|
|
|
yudhisthira wrote: Mac file format detected: please convert the source file to either DOS or UNIX format
I guess, this is warning.
There are not exact step to "port" application from VC 6 to VS2005. Compiler will tell, what need to be corrected. Remember , by default VS2005 projects will be UNICODE. So, you need to decide on that.
There are some functions declared as deprecated , some CRT enhancements are there.
But, if you look at build log, you should able to fix those.
Prasad
MS MVP - VC++
|
|
|
|
|
For example,
return value of CWnd::OnNcHitTest has been changed from UINT to LRESULT in VS2005.
In VC 6.0 - UINT CWnd::OnNcHitTest(CPoint point).
In VS2005 - LRESULT CWnd::OnNcHitTest(CPoint point).
Regards,
Paresh.
|
|
|
|
|
Dear Prasad,
It is not warning but it is the error.This is the only bug which is in my code. How can i debug this. Pls help me.
Regards,
yuhisthira Attry
|
|
|
|
|
yudhisthira wrote: This is the only bug which is in my code
I can't understand, how could be a compiler error is bug ?
yudhisthira wrote: How can i debug this
No, you can't debug it.
yudhisthira wrote: Pls help me.
As told earlier, read build log, and try to fix it.
Prasad
MS MVP - VC++
|
|
|
|
|
From the error message, it would sound link your source (.cpp, .h, etc) files have a simple carriage return (CR) for a line ending. It also says to convert then to DOS or Unix format. DOS formats lines to end with a CR/LF, while Unix uses just a LF character.
You may be able to open the files in word pad or notepad and resave them...it may solve the problem.
Hope that helps.
Karl - WK5M
PP-ASEL-IA (N43CS)
PGP Key: 0xDB02E193
PGP Key Fingerprint: 8F06 5A2E 2735 892B 821C 871A 0411 94EA DB02 E193
|
|
|
|
|
Be a programmer. That's how I do it.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997 ----- "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
Wow, that can't be a very effective way of changing the line-endings in a text file!
|
|
|
|
|
Yudhisthira,
It's simple - your files have Mac-style (CR) line endings, rather than Windows/DOS (CRLF) or Unix (LF) style.
Try opening the file in a text editor (Notepad or Wordpad), adding/removing a couple of newlines and saving. Wordpad often seems good at ironing out line-ending related issues on Save, so I'd suggest that.
Incidentally, when you see a message number like "C4335", it's often worth typing into the Index page of MSDN Help (your local version, or online). This often displays a more detailed error message, as I used to resolve this issue.
Hope this helps,
Rob
|
|
|
|
|
Rob Grainger wrote: Incidentally, when you see a message number like "C4335", it's often worth typing into the Index page of MSDN Help (your local version, or online). This often displays a more detailed error message, as I used to resolve this issue.
Sound advice, except that error does not exist.
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|