Re: zero memory
ajk wrote:
On Fri, 06 Apr 2007 22:45:16 -0700, Gianni Mariani
<gi3nospam@mariani.ws> wrote:
ajk wrote:
On Fri, 06 Apr 2007 05:39:34 -0700, Gianni Mariani
<gi3nospam@mariani.ws> wrote:
...
Note the lack of a memset call and note that the code will work for POD
types as well as non POD types.
ok that's in a way elegant, but a bit difficult for maintenance
programmers to troubleshoot
That's one serious cop-out. Arguing to have mediocre engineers is an
unsupportable argument.
no, its not an unsuportable argument - coding so that its clear is
what its about.
Let me see:
PMYSTRUCT mys = InitObj();
Oh yeah.... not very clear.
How about this:
PMYSTRUCT mys = NewInitializedObject(); // creates a new zero MYSTRUCT
Let's see which one is more maintainable ....
.................
code in common header file....
struct InitObj
{
template <typename T>
operator T * ()
{
return new T();
}
};
...............
...............
application code.....
PMYSTRUCT mys = InitObj();
...............
vs - in every instance ...
memset(&overlapped,0,sizeof(overlapped)) + other mumbo jumbo with all
kinds of potential for programmer errors.
mumbo jumbo? lol whatever
Is that a nervous laugh ? Or perhaps one of ignorance ? Certainly it
shows a lack of being able to form a coherent argument.
Bugs in calls to memset or memcpy are high on the list of ones that have
worn out their welcome. Eliminating calls to these in mainline code is
a good thing. I don't see how you can argue otherwise if you have had
enough experience.
I know what I would like my engineers to maintain.
your solution has two drawbacks as it allocates memory on heap:
it requires whoever uses it to know that memory is allocated second
second allocating memory on heap just because you want to initialize
it isn't effective.
Are you telling me that you can't extend this design to somthing that is
allocated statically or automatically ? If you can't, look at the
previous post of mine on this thread.
Eliminating repetitive code helps build a solid, easier to maintain code
base. C++ does have some very neat features (some unintentional) that
allows a good programmer to remove alot of repetitive, error prone code.
Admitedly, that one probably (not tested of VC7.X) breaks some buggy
compilers but it shows you what you should be expecting from the language.