Making a function to construct a class pointer object and returning it... problems.
Quote:Original post by PCN
I'm not sure why NULL is used often but it should become a keyword like "true" and "false" became it's own type after so many uses like this:
*** Source Snippet Removed ***
But if it became it's own type, what would it be? An integer? Maybe something different?
windows.h aliases BOOL to an integer type for historical reasons. It's worth noting that bool and BOOL are completely different types as a result -- it didn't actually become it's own type (in the "it became itself" sense anyways). Aren't C++ warts fun?
@swiftcoder: Not to be nitpickery, but you're leaking memory there. The A instance created in BuildA() is never cleaned up.
@PCN: I find it deceptive to hide new under a function and then expect the calling code to clean up the given resource manually - this is easily forgotten, as demonstrated above. If you go for a Build function, then at least also provide a Destroy function, or use auto pointers or some other form of smart resource management.
@PCN: I find it deceptive to hide new under a function and then expect the calling code to clean up the given resource manually - this is easily forgotten, as demonstrated above. If you go for a Build function, then at least also provide a Destroy function, or use auto pointers or some other form of smart resource management.
Quote:Original post by Captain PNot to be pedantic, but I am not leaking memory there, because memory is always reclaimed when the application exits. Unless A has a non-trivial destructor with other side-effects, there is no need to free memory that will be in use up until program exit time.
@swiftcoder: Not to be nitpickery, but you're leaking memory there. The A instance created in BuildA() is never cleaned up.
As a matter of form, I probably should have deleted it, but in this case it is not a requirement.
Quote:Original post by swiftcoderQuote:Original post by Captain PNot to be pedantic, but I am not leaking memory there, because memory is always reclaimed when the application exits. Unless A has a non-trivial destructor with other side-effects, there is no need to free memory that will be in use up until program exit time.
@swiftcoder: Not to be nitpickery, but you're leaking memory there. The A instance created in BuildA() is never cleaned up.
As a matter of form, I probably should have deleted it, but in this case it is not a requirement.
Of course, you're right. However, I think it's a bad habit to get into. After all, small programs may eventually grow larger and it's too easy to forget things like this. Using smart pointers instead would be a better habit, imho. :)
Quote:Original post by Captain P
Of course, you're right. However, I think it's a bad habit to get into. After all, small programs may eventually grow larger and it's too easy to forget things like this. Using smart pointers instead would be a better habit, imho. :)
I am inclined to feel that development 'bad habits' are overblown as compared to cardinal sins [smile]
Why would a small program tend to grow? A small program should either be a test case for a single feature (like the above), or a utility/tool with a single purpose. In the former case, the code should be rewritten if reused - the test case is typically not robust enough for production code, and in the latter the program should grow at worst very slightly, because of the single purpose requirement.
Sure, we have all seen swiss-army-knife utilities, and spaghetti code copy/pasted from lord knows where, but long before one starts worrying about 'defensive coding' practises, one should be doing defensive design and planning.
(I am likely to be preaching to the choir here, but whatever)
Heh, I can see your point. But as you flirt from test to test to small utility without defending ones self, all it takes is one slip in a large final project to create a timesink. I might be a quick find, it might take a while, but its a stop that isnt so much a "should" have been avoided with practise, but "could" have, and in some sense, time == money;
naturally if this is just casual coding that might as well be tossed out the window. those big companies making massive games that they can assume people will want to run with all sorts of other applications at the same time, it might come into play.
In my projects' scope, I dont bother with it either for the most part...
naturally if this is just casual coding that might as well be tossed out the window. those big companies making massive games that they can assume people will want to run with all sorts of other applications at the same time, it might come into play.
In my projects' scope, I dont bother with it either for the most part...
Author
I hate to bust your bubbles, but this small "test" was actually developed into something much larger, but I took care of the destructors and memory leaks... I think. I'm admitting it, I'm not a professional coder. I've only learned from trial-and-error and a Beginner's C++ book my friend's older brother had. So, in short, if there is something that I need to arrange in my code a certain way, please inform me. I actually plan to release my tool to the GameDev forums here so everyone can use and I'd hate to release it with "potential" problems.
~PCN
~PCN
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
