Pay attention to that copy constructor [C++]
-
I don't particularly mind dealing with bugs as long as they are interesting to fix and you learn something along the way. I was not always so well disposed towards them though. It is only after reading Debugging Applications by John Robbins that I realized how much fun fixing bugs can be 8-)! There are bugs that you feel good about when you fix 'em because it required you to use your "amazing ingenuity" and "extensive knowledge" of how stuff works under the hood and then there are bugs that make you feel rotten because the darn thing won't get reproduced on your box! Those are the nastiest kind of bugs to get stuck with because you know it is there somewhere and there isn't a single thing that you can do about it! I had to deal with a bug like that the other day the root cause for which in the end turned out to be a fairly silly little programming error. "If you can shoot yourself in the foot with 'C', you can blow your whole leg off with C++" reminisced the wise old man while helping himself up the handicap ramp seated on his wheelchair. I know he said this because I was right there behind him when he said it with a big smoking hole in my right foot. Here's what happened. Ours is an ambitious little web application that seeks to do a whole lot of things all by itself using pretty much every single technology that mankind has managed to come up with till about 5 minutes back. One of the things that it jauntily goes about doing every now and then is to call a little Internet Server API (ISAPI) extension on the web server whenever somebody logs off. When a user happens to crash out of a web session however (as can happen for instance when lightning strikes the user's computer and does not give her a chance to cleanly exit the browser and shut the computer down) that little notification does not ever reach the ISAPI extension and the web server remains tragically unaware of the user's untimely end. After twiddling thumbs for some time though the ISAPI extension runs out of patience and just ends that user's session. Now, here's the important part - as part of the processing where it terminates that non-responsive user's session, it turns on a little boolean membe
-
I don't particularly mind dealing with bugs as long as they are interesting to fix and you learn something along the way. I was not always so well disposed towards them though. It is only after reading Debugging Applications by John Robbins that I realized how much fun fixing bugs can be 8-)! There are bugs that you feel good about when you fix 'em because it required you to use your "amazing ingenuity" and "extensive knowledge" of how stuff works under the hood and then there are bugs that make you feel rotten because the darn thing won't get reproduced on your box! Those are the nastiest kind of bugs to get stuck with because you know it is there somewhere and there isn't a single thing that you can do about it! I had to deal with a bug like that the other day the root cause for which in the end turned out to be a fairly silly little programming error. "If you can shoot yourself in the foot with 'C', you can blow your whole leg off with C++" reminisced the wise old man while helping himself up the handicap ramp seated on his wheelchair. I know he said this because I was right there behind him when he said it with a big smoking hole in my right foot. Here's what happened. Ours is an ambitious little web application that seeks to do a whole lot of things all by itself using pretty much every single technology that mankind has managed to come up with till about 5 minutes back. One of the things that it jauntily goes about doing every now and then is to call a little Internet Server API (ISAPI) extension on the web server whenever somebody logs off. When a user happens to crash out of a web session however (as can happen for instance when lightning strikes the user's computer and does not give her a chance to cleanly exit the browser and shut the computer down) that little notification does not ever reach the ISAPI extension and the web server remains tragically unaware of the user's untimely end. After twiddling thumbs for some time though the ISAPI extension runs out of patience and just ends that user's session. Now, here's the important part - as part of the processing where it terminates that non-responsive user's session, it turns on a little boolean membe
-
I don't particularly mind dealing with bugs as long as they are interesting to fix and you learn something along the way. I was not always so well disposed towards them though. It is only after reading Debugging Applications by John Robbins that I realized how much fun fixing bugs can be 8-)! There are bugs that you feel good about when you fix 'em because it required you to use your "amazing ingenuity" and "extensive knowledge" of how stuff works under the hood and then there are bugs that make you feel rotten because the darn thing won't get reproduced on your box! Those are the nastiest kind of bugs to get stuck with because you know it is there somewhere and there isn't a single thing that you can do about it! I had to deal with a bug like that the other day the root cause for which in the end turned out to be a fairly silly little programming error. "If you can shoot yourself in the foot with 'C', you can blow your whole leg off with C++" reminisced the wise old man while helping himself up the handicap ramp seated on his wheelchair. I know he said this because I was right there behind him when he said it with a big smoking hole in my right foot. Here's what happened. Ours is an ambitious little web application that seeks to do a whole lot of things all by itself using pretty much every single technology that mankind has managed to come up with till about 5 minutes back. One of the things that it jauntily goes about doing every now and then is to call a little Internet Server API (ISAPI) extension on the web server whenever somebody logs off. When a user happens to crash out of a web session however (as can happen for instance when lightning strikes the user's computer and does not give her a chance to cleanly exit the browser and shut the computer down) that little notification does not ever reach the ISAPI extension and the web server remains tragically unaware of the user's untimely end. After twiddling thumbs for some time though the ISAPI extension runs out of patience and just ends that user's session. Now, here's the important part - as part of the processing where it terminates that non-responsive user's session, it turns on a little boolean membe
... and this is one reason that more often than not, I use STL collection classes to store pointers to things, not the things themselves. Of course, that leads on to interesting digressions about when it's safe to delete something, but that's a whole other thread...
Steve S Developer for hire
-
... and this is one reason that more often than not, I use STL collection classes to store pointers to things, not the things themselves. Of course, that leads on to interesting digressions about when it's safe to delete something, but that's a whole other thread...
Steve S Developer for hire
Putting pointers to things in STL containers is generally a bad idea. Not only is determining when to delete something difficult but also what to delete. Pointers that point to stuff on the stack or global/static objects should not get deleted and stuff on the heap should. How about putting a reference counted smart pointer to a thing in an STL container? :~
-- Ranju. V http://blogorama.nerdworks.in --
-
Putting pointers to things in STL containers is generally a bad idea. Not only is determining when to delete something difficult but also what to delete. Pointers that point to stuff on the stack or global/static objects should not get deleted and stuff on the heap should. How about putting a reference counted smart pointer to a thing in an STL container? :~
-- Ranju. V http://blogorama.nerdworks.in --
Hmm, I almost always use pointers to things too.
gleat wrote:
Pointers that point to stuff on the stack or global/static objects should not get deleted and stuff on the heap should.
I see that one, however I never give the client access to the stl container so all insertions are done on the heap and deletions are done when the item is removed from the container.
gleat wrote:
How about putting a reference counted smart pointer to a thing in an STL container?
I have done this a few times only in cases where multiple containers shared the same objects or subset of that.
John
-
Putting pointers to things in STL containers is generally a bad idea. Not only is determining when to delete something difficult but also what to delete. Pointers that point to stuff on the stack or global/static objects should not get deleted and stuff on the heap should. How about putting a reference counted smart pointer to a thing in an STL container? :~
-- Ranju. V http://blogorama.nerdworks.in --