activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Timothy Bish <tab...@twcny.rr.com>
Subject Re: Licensing and Porting Issue for the CMS (ActiveMQ-CPP) on Visual Studio 6 from Visual Studio 8
Date Fri, 25 May 2007 14:12:59 GMT
Hi

Albert Strasheim wrote:
> 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
>
>   
If I recall correctly from my VC6 days in order to get STL working
reliably we had to actually use a third party STL package, STLPort I
think.  VC6's standards compliance is atrocious and there are a lot of
things missing from STL, and a lot that just don't work real well.  I
think that getting this to work in VC6 is going to be a very time
consuming task, almost as hard as getting it working in gcc v2.9.5 or
some other ancient compiler. 

tim




Mime
View raw message