[Rxtx] C++ Branch

[Trent Jarvi]

On Thu, 26 Aug 2010, Adrian Crum wrote:

> --- On Thu, 8/26/10, George H <george.dma at gmail.com> wrote:
>> 1. There is going to be a partial or nearly full re-write
>> of the rxtx
>> C lib and JNI
>> 2. There will be lot more discussions on JNA and perhaps
>> sample libs
>> 3. A new version of rxtx will most likely be released with
>> the new
>> patches and many bug fixes
>
> Just a quick update on the work I have been doing: The native serial port code is finished and seems to be working well. Good data transfer speed with no data loss, serial devices can be unplugged while the port is being used without crashing RXTX or the JRE, and real-time port detection is working. I'm working on the parallel port native code right now. If all goes well, I might have a preliminary version to put in the bug tracker by the end of this weekend.
>
> Maybe a C++ guru could help me out with a problem I can't seem to solve. I want an exception subclass to contain a pointer to an informational message on the heap. The pointer is deleted in the subclass's destructor. When the exception is caught, C++ copies the exception subclass and returns a reference to the copy in the catch block. The original exception is discarded, so the informational message is lost. I tried using a copy constructor so I can copy the message before it is destroyed, but the copy is done *after* the original is deleted (??!!).
>
> void function a()
> {
>  char *message = new char[...];
>  throw ExceptionSubclass(message);
>  // message is deleted in the exception's destructor
> }
>
> void function b
> {
>  try
>  {
>    a();
>  } catch (ExceptionSubclass &e)
>  {
>    // e is a copy of the exception and the
>    // message in the original was deleted
>  }
> }
>

Hi Adrian

I'd just point out that you are making a large number of decisions on your 
own without buy-in at this stage.

The move to C++ can be problematic for embedded device development as it 
expands the toolchain requirements.  Often we see people 'rewrite' rxtx 
for their purposes and drop large patch sets without putting a great deal 
of thought into the corner cases thinking that they did the hard part the 
rest is easy.

I'm all for creating a C++ branch as I'm in favor of a JNA branch and 
letting people try everything.  Don't assume that it's a natural 
progression just as I avoid assuming it is not a natural progression.

The way we did this with GCJ which I suggest for JNA and C++ efforts is 
create a new directory in the current working branch and let people do 
anything they want in that directory.  In the GCJ case, nothing really 
came of it beyond proof of concept but there was nothing preventing it 
from being more widely accepted.

Why don't we start with that so you can at least start getting some buy in 
to your ideas from members that may want to help?

--
Trent Jarvi
tjarvi at qbang.org