Re: CByteBuffer implementation passed between modules
Oh, so "simplified" translates as "syntactically and semantically
incorrect..."?
I can see how this would puzzle someone like you. I wrote it that way
because everyone else on this newsgroup would understand it perfectly.
I have heard many people refer to the MFC runtime as "the" runtime
library. Since you did
not explicitly state "the C runtime library", the reference was ambiguous.
What other library could it be when "new" and "delete" were being discussed?
But the "simplification" changed the nature of the problem! If you put
the code in the
header file, then it is compiled in the context of the caller, which is
COMPLETELY
different from putting the implementation code in a separate file.
Apparently you have a
different interpretation of "simplfied", which includes "syntactically and
semantically
incorrect examples which also do not reflect the actual implementation in
critical ways"
You waste bandwidth with comments like this. Because this is voided out by:
Well, that's an error. The .cpp file should ONLY be in the .dll. The
header file should
reference the external functions in the DLL. Putting two different
implementations in two
different files and somehow expecting they will cooperate is not
reasonable.
This is a small utility class meant to be compiled into every module that
uses it. Like ASSERT.C. Since you fail to appreciate the elegance of
static linking, I don't expect you to understand why I'd want to do this.
Nevertheless I do. So stop trying to sell me on your concept of rightness.
I trashed that months ago.
You have
created an impossible situation, and there isn't a good answer for it.
Oh, hoity toity. I asked for feedback on a solution that seems pretty good
to me. If you don't even appreciate the situation, then just stay quiet.
When did you learn it?
From my colleages at Borland when we were working on Turbo C++ 1.0. Maybe
it was a prerelease version or something.
Just to double-check, I actually dug up the earliest C++ book I
could find easily in my library, "Using C++: Covers C++ 2.0", by Bruce
Eckel, (c) 1989,
Osborne/McGraw-Hill. From page 274:
"In C++ it is quite natural to use the value NULL to indicate the pointer
is empty. This
is supported by a special feature--if you call delete with a NULL pointer
it has no
effect. You don't have to test to see if a pointer is empty before you
delete the free
storage it points to."
So this was known at least as early as 1988. I gather you haven't
actually used C++ since
perhaps 1987, or you used some non-conforming implementation, otherwise
you would have
known this, since many programs actually depend on this behavior.
[Actually, I think this
may have been true in C++ 1.0, but my C++ 1.0 manual is in storage in the
attic and I'm
not motivated to dig it out]
So the null test is silly.
You really are a prick.
-- David