I'm pretty sure not James. I could be wrong about it. You might want to check it out. I believe there may be a distinction there between creation of POD types, i.e., Plain Old Data, and class types. That's exactly the point I was trying to make. I haven't done an internet search on it or anything like that (I did think of asking at
www.cplusplus.com), but I just haven't. The reason I posted though what I did is because of my results from my applications I've been working with. When I was doing that #define stuff, I was having to do the memset thing on my ints. In fact, I had a nasty bug about it. What happened was that my tables like I posted above a few posts were coming out with massive errors, i.e., numbers like so ...
3453214567 in many fields that should have been zeros or small numbers like 3420, etc. I mean a bad mess up. No crashes or anything, just very bad results. And what I tracked it down to was that when I was doing the memset thing on the allocated memory I was forgetting to add the sizeof(int) to my multiplication of the bytes to multiply by. For example, if I wanted 4 rows by 3 cols I'd need this to null it out ...
memset(pInts,0,4*3*sizeof(int));
and this is what I had ...
memset(pInts,0,4*3);
See, I'm not a big user of new. Usually I use the Win32 memory allocation functions like HeapAlloc(), GlobalAlloc(), etc. Those functions want the number of bytes you want allocated - not the number of some kind of object. Of course, to use that memory after successfully acquiring it, it must be cast to some variable type the compiler is aware of. But C++'s new wants the number of objects - not the number of bytes. So to null out memory returned by C++'s new, you'll need to multiply the number of objects times the sizeof each object. In my case above, after I fixed my expression - no more bogus data.
Where the plot thickens is several days ago, in working with this stuff, I tried to create an array of std::string objects. I posted some of that code using my string class and the std::string class several posts back. In doing that I immediately got instant GPFs with the std::string class. I was bewildered. So I started putting printf statements all over the class code to try to determine where it was crashing. Where it was crashing was in the destructor calls. All of a sudden the bells, sirens, and whistles went off when it dawned on me that when any class is instantiated, the compiler immediately executes constructor calls on the object. In C++ if there is a default constructor supplied, the compiler uses that one; if not it provides its own. In any case, every cell in the array will contain a default object on which the constructor was called. If, as my code would do with the memsets in place, it went through it and nulled out all that memory, it would all then be corrupted in terms of the existing classes there - I think. That seemed to be the case. When I removed those memset calls - it worked perfectly.
Now, in your case, you are doing what I'm doing with vectors, and the code for all that is somewhere in the C++ Standard Libraries. They may handle that situation there for you. You may not need to do this for your vector based arrays. I simply don't know that. But for my technique, it looks like I need to handle it as I've said in my last post.
Now another issue here is RTTI, i.e., runtime type information. If my premise is correct, I could solve it within my class by determining what type of object is being created, i.e., a POD type or a non-POD type (Plain Old Data). Again, if my premise is correct, POD types need zeroed out - not non-POD types. You have seen that acronym, haven't you? I see it in error messages all the time.
Thoughts??? I mean, you are the one with the big red book!
