Re: CByteBuffer implementation passed between modules
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
news:0irab25uv2snlgng9br3joq8nl8haopic0@4ax.com...
This seems an overly complex way to implement CByteArray. Why do you feel
a need to
reimplement an existing class?
Because my class actually has more functionality, but I stripped it down for
demonstration purposes. Since you seem unable to distinguish the forest
from the trees, I was asking a general question pertaining to any class that
has Stack Value semantics. You know, like CString.
Since this won't even compile, what's the question? Note that your Set
method requires
two parameters and you supplied one.
I typed it in to demonstrate the problem, that is why I said it was
SIMPLIFIED.
The problem now is that the CByteBuffer::m_pBuf was allocated using the
"new" in MyDLL and deleted using the "delete" in MyEXE (when the instance
goes out of scope). If the RTL is statically linked into both MyApp and
MyDLL, then the "delete" causes a crash since the memory was allocated
using
a different instance of the heap. If the RTL is dynamically linked, it's
fine since the same heap is shared. But I don't want the users of my
CByteBuffer class to be forced to dynamically link the RTL.
****
Define "the RTL". Do you mean the C runtime? In general, the C runtime
uses the
application heap, so different C runtimes should be able to work together.
But if it
won't work, it won't work.
Well duh, RTL stands for Run Time Library, doesn't it?
I simply make it a policy that my code only works with dynamic MFC
linking, and it isn't
even an issue I consider negotiable. I do not consider static linking a
viable option.
Well, that is your opinion, as we have gone round and round many times
before. Since I clearly said static linking needed to be supported, if you
don't have an answer to my question, then simply don't answer instead of
using my post as a launchpad for your diatribes.
Key here is to not put the function bodies in the class definition, but in
the
implementation file. This forces the code to execute in the correct
environment. So just
defined
void Set(LPVOID p, size_t size);
in the header file, AND THAT'S ALL. Then, in the body of the DLL, write
void CByteBuffer::Set(LPVOID p, size_t size)
{
m_pBuf = new BYTE[size];
memcpy(m_pBuf, p, size);
}
By putting the code in the class definition, you force it to compile and
execute in the
context of the call, not in the context of the DLL.
As I said, I simplified it. I don't normally put the implementation in the
header file, but even if I did, it is legal and a valid way of coding. In
fact, it is the only sane way to code a template based class. And your
comment is simply not true. Whether the implementation is placed in the
header file or not doesn't make any difference as to the code that is
executed.
You misunderstand what I'm trying to do. I have 2 files called ByteBuffer.h
and ByteBuffer.cpp. They are compiled into BOTH MyExe.vcproj and
MyDll.vcproj. They're meant to slip into any VC++ project, to just be
compiled in. And I expect that all projects that have included them will be
able to properly accept and manipulate the CByteBuffer::m_pBuf. You can't
just say:
You would then have to provide a Delete() method which was implemented in
the DLL, e.g.,
~CByteBuffer() { Delete(m_pBuf); }
and in the DLL you would implement
void CByteBuffer::Delete(LPBYTE b) { delete [] b; }
because the ctor/dtor may be executed in the DLL module, the EXE module, or
any other module, and the Set() can be in another module.
The NULL test is silly because if the value is NULL delete is defined to
work correctly by
the C++ language standard.
That you for that astute comment Professor. When I learned C++, this was
not the case.
Does anyone (else) have any comments on the main question?
-- David