Practice safe programming !
-
Here is an example from our current development effort:
CYesNoDlgBar *yesNoBar = new CYesNoDlgBar(this, prompt);
yesNoBar->SetCadPtr(this);
ShowCadBarModal(yesNoBar);
ret = yesNoBar->GetResult() ? 1 : 0;
if (yesNoBar)
{
delete yesNoBar;
yesNoBar = NULL;
}Unfortunately I can't track down which developer put in this piece of code as we changed source control and lost that history otherwise he would have got a piece of my mind, as would the one who was supposed to do the code review. Cheers, Brett
LOL :laugh: Good luck of that coder... u changed ur source control... :laugh:
Anand Desai Developer Atharva Infotech
-
Here is an example from our current development effort:
CYesNoDlgBar *yesNoBar = new CYesNoDlgBar(this, prompt);
yesNoBar->SetCadPtr(this);
ShowCadBarModal(yesNoBar);
ret = yesNoBar->GetResult() ? 1 : 0;
if (yesNoBar)
{
delete yesNoBar;
yesNoBar = NULL;
}Unfortunately I can't track down which developer put in this piece of code as we changed source control and lost that history otherwise he would have got a piece of my mind, as would the one who was supposed to do the code review. Cheers, Brett
Somewhat off topic: Never understood the people who allocate objects on heap when it is easier and safer to do it on stack. I.e.:
CYesNoDlgBar yesNoBar(this, prompt);
yesNoBar.SetCadPtr(this);
ShowCadBarModal(&yesNoBar);
ret = yesNoBar.GetResult() ? 1 : 0; -
Here is an example from our current development effort:
CYesNoDlgBar *yesNoBar = new CYesNoDlgBar(this, prompt);
yesNoBar->SetCadPtr(this);
ShowCadBarModal(yesNoBar);
ret = yesNoBar->GetResult() ? 1 : 0;
if (yesNoBar)
{
delete yesNoBar;
yesNoBar = NULL;
}Unfortunately I can't track down which developer put in this piece of code as we changed source control and lost that history otherwise he would have got a piece of my mind, as would the one who was supposed to do the code review. Cheers, Brett
Too bad you can't find the guy who did that. Who knows what other gems he has laying around.
"The clue train passed his station without stopping." - John Simmons / outlaw programmer "Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
-
Somewhat off topic: Never understood the people who allocate objects on heap when it is easier and safer to do it on stack. I.e.:
CYesNoDlgBar yesNoBar(this, prompt);
yesNoBar.SetCadPtr(this);
ShowCadBarModal(&yesNoBar);
ret = yesNoBar.GetResult() ? 1 : 0;Haven't done any C++ for years but I agree. There's a general guideline I came across somewhere: "always use an object or a reference unless you have to use a pointer." I saw lots of unnecessary heap allocation over the years. Why make trouble for yourself when you don't need to? Perhaps it's a sign of misplaced C++ "machismo?" :)
Kevin
-
Haven't done any C++ for years but I agree. There's a general guideline I came across somewhere: "always use an object or a reference unless you have to use a pointer." I saw lots of unnecessary heap allocation over the years. Why make trouble for yourself when you don't need to? Perhaps it's a sign of misplaced C++ "machismo?" :)
Kevin
Kevin McFarlane wrote:
Perhaps it's a sign of misplaced C++ "machismo?"
:) On the contrary, I think it comes from the SmallTalk/Java style of OOP; create anonymous object and pass pointers/references to them around. Nothing wrong with that approach if you have a GC to clean up after you, but in C++ it is much better to create objects on stack than to worry about calling
delete. -
Somewhat off topic: Never understood the people who allocate objects on heap when it is easier and safer to do it on stack. I.e.:
CYesNoDlgBar yesNoBar(this, prompt);
yesNoBar.SetCadPtr(this);
ShowCadBarModal(&yesNoBar);
ret = yesNoBar.GetResult() ? 1 : 0; -
Here is an example from our current development effort:
CYesNoDlgBar *yesNoBar = new CYesNoDlgBar(this, prompt);
yesNoBar->SetCadPtr(this);
ShowCadBarModal(yesNoBar);
ret = yesNoBar->GetResult() ? 1 : 0;
if (yesNoBar)
{
delete yesNoBar;
yesNoBar = NULL;
}Unfortunately I can't track down which developer put in this piece of code as we changed source control and lost that history otherwise he would have got a piece of my mind, as would the one who was supposed to do the code review. Cheers, Brett
-
Outstanding is checking the pointer after using it. At most knowing that delete "survives" a Null-pointer. :-O I think you find more of these eye-candy if you go for it. :~ X|
Greetings from Germany
KarstenK wrote:
I think you find more of these eye-candy if you go for it.
I agree and that was the point of my post earlier :) I would suspect the developer probably did such a thing as a coding standard of their own and the chances of more gems like that are probably bound to be found.
"The clue train passed his station without stopping." - John Simmons / outlaw programmer "Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
-
Somewhat off topic: Never understood the people who allocate objects on heap when it is easier and safer to do it on stack. I.e.:
CYesNoDlgBar yesNoBar(this, prompt);
yesNoBar.SetCadPtr(this);
ShowCadBarModal(&yesNoBar);
ret = yesNoBar.GetResult() ? 1 : 0; -
Somewhat off topic: Never understood the people who allocate objects on heap when it is easier and safer to do it on stack. I.e.:
CYesNoDlgBar yesNoBar(this, prompt);
yesNoBar.SetCadPtr(this);
ShowCadBarModal(&yesNoBar);
ret = yesNoBar.GetResult() ? 1 : 0;Nemanja Trifunovic wrote:
Somewhat off topic: Never understood the people who allocate objects on heap when it is easier and safer to do it on stack.
In the general case, you are absolutely spot on. Also, never use pointer arguments to functions unless 0/NULL is a valid value for input. But, but, but... consider the case when an instance of CYesNoDlgBar eats too much stack by itself, and can therefore only be created on the heap? [1] Not that I actually think that was the case there... [1] I've actually just some moments ago fixed the GIF parts of CxImage to be usable on a handheld device platform, where the default stack is just roughly a handful of 10 KB, because several member arrays of the CxImageGIF were harcoded to sizes accumulating to way above the available stack, causing runtime failures. Using
std::vector<>solved it.-- Time you enjoy wasting is not wasted time - Bertrand Russel
-
Nemanja Trifunovic wrote:
Never understood the people who allocate objects on heap when it is easier and safer to do it on stack.
because C allows you to shoot yourself in the foot, but C++ blows it off... (guess who said it)
Yusuf
It's hardly the stack that'll contribute to your foot's annihilation in C++...
-- Kein Mitleid Für Die Mehrheit