Hello all
On Fri, 25 May 2007, Some user wrote:
> Hi Albert!
>
> >>but maybe we should rather spend some
> >>time getting AMQCPP to build as a DLL with VC++ 2005 Express (which is
> >>free to use, even for commercial applications) which you can then link
> >>into your VS6-compiled applications.
>
> build dll on 2005 goes fine, however, my application on VS6 anyways fails
> compilation when I include the cms headers, the compilation errors are again
> the same mentioned in the original post by pravin.
>
> Has anyone before tried compiling/running a sample code on VS6?
Looking at the errors again, they are:
1. "differs only by return type" is due to the covariant return in
ActiveMQException. But building the AMQCPP part as DLL probably means
you don't see this anymore.
2. Something is going awry with the static constants in DeliveryMode. I
can't figure out why VS6 doesn't like those. As a quick workaround you
could just #if 0 them and use the literal values or a #define.
3. long followed by long is illegal is probably because VS6 doesn't
support the long long type. Not quite sure what do here. You should be
able to put an #if 0/#endif around that method so that the compiler
ignores it. But you won't be able to get long (as in Java long)
properties from the message.
4. 'size_t' : is not a member of 'std' might be due to CMS not including
some standard header that should strictly be there. Try adding
#include <cstddef> to BytesMessage.h. Alternatively, it might be that
VS6's C++ implementation doesn't have size_t in std. You might be able
to fix this with something like:
namespace std { typedef ::size_t size_t; }
at the top of BytesMessage.h or by simply changing std::size_t to
size_t.
With all these bits fixed, you might still run into problems (I could
be wrong... and I hope I am). The problem is this (I think). E.g.:
Session* session = connection->createSession(...);
createSession calls code in the VS2005-compiled DLL which is
dynamically linked to some version 8 of the Microsoft runtime. This
allocates the Session object on a heap specific to that runtime
library. Now when you do:
delete session;
in code compiled by VS6, that tries to remove the object from some heap
that belongs to some version 6 of the runtime. The object isn't on that
heap, so strange things will happen.
For this to work right, I think the various CMS classes would have to
get methods like destroySession, etc. so that you can be sure that you
always new and free on the same heap when running on Windows.
Anyway, I could be wrong. Anyone else? You can at least try to just
delete the stuff. If it blows up, my theory might explain why.
Cheers,
Albert
