quote:Original post by benjamin bunny
But anyway, the point [edit: that''s not supposed to be a pun] is that he should set the pointer to NULL when he initialises it so that he can check its validity before he uses it.

A better solution would be to encapsulate the pointer and all manipulation of it within a handle class.

quote:Original post by benjamin bunny
Why bother?

There''s no need for a tantrum.

quote:Original post by benjamin bunny
I''m not sure that "why bother" constitutes a tantrum.

Ah, I interpreted it as "why bother contributing to the thread", but I now see you meant "why bother using a handle class". My apologies...

quote:
I was simply making the point that your method was somewhat unnecessary.

That depends on what you mean by "necessary". I perceive it as necessary to do so when tackling such problems in my own (and my employers'') code for several reasons:

- it encapsulates memory management which helps with fault detection and enables transparency of change;

- it raises the level of intentionality, since user code can be seen to be acting at the intended abstraction level rather than dealing with pointer tracking and memory management;

- user code is vastly simplified, which means it is quicker and easier to get things right.

Usefully for the purposes of this post, there is an article on this very topic in this month''s CUJ, written by Koenig and Moo. It doesn''t appear to be on-line, so here''s a quote:

quote:
Class authors who wish to avoid managing memory can foist off the problem on their users. Indeed, doing so may be tempting, because ignoring memory management makes classes easier to write. However, such classes are harder for users to use, and the overall complexity of a system increases greatly if user code must manage the system''s memory directly.

It may seem a lot of initial investment to come up with a correctly working handle class, but IME that investment is usually more than repaid, and it soon becomes second nature to work in that way. I''m fairly convinced that the OP could avoid writing his own handle class if he refactored his design, and could potentially make use of the Boost libraries. I''d say a significant percentage of problems posted to these forums could be avoided with a simple change of mindset.

Wow, I didn''t realize this thread was still going

quote:
So many guys have been trying to help u man, u say u found the error and u don''t wanna tell

When benjamin said that things looked ok, I went back and looked at my code again (I guess I just needed someone to confirm that things looked ok) Anyways, the error was really a dumb one...when I copied my data from one function over to the other I was missing two lines of code. I somehow manage to do that twice when copying and pasting. That''s all it took to create that error.

Originally I''d put the data into a class and reference it, but I found it was more trouble then what it was worth for this particular situation because I''m dealing with image data that has to be in contiguous order for D3D to load it. I would have had to create another function to swap the data in contiguous order because the class I had contained the header info and a pointer to the image data. As you can see, the pointer would have been the problem. This wasn''t a big deal, it just made things more messy.

Also I do set my pointers to NULL, but for some reason I didn''t their It''s probably because I just wrote the code.

Anyways thanks everyone for your help.

quote:Original post by benjamin bunny
But, for the purpose of an array which is only needed for the lifetime of a function, IMO it''s better to manage the memory yourself.

It''s not completely clear what the OP requires as I don''t know the full usage context, but the scenario you describe here implies a vector, the rationale of which is exlained in Cline''s Arrays are Evil.

quote:
I suppose it''s a matter of preference as much as anything.

I actually think there''s a fairly convincing argument that lifts certain techniques above mere preference, but I really can''t be arsed making that argument. It''s to be found in most reputable C++ publications.