[vtkusers] string compare bug?

[Kevin Wright]

At 05:13 PM 10/7/2002 -0400, you wrote:
>>>Are you using vtkSocketController/vtkSocketCommunicator?  These objects 
>>>already do this under the hood.
>>>-Jeff
>>
>>
>>No, I'm tying it in with some other code here.  Are you saying that 
>>vtkSocketController/Communicator addresses the bug that I'm talking 
>>about, or that it provides the same functionality?
>
>
>those classes provide the same functionality, and use a very similar 
>approach.  I'm not sure what you are seeing is a bug per-se - does your 
>Irix/Linux build do the same thing?  I agree that the string compare could 
>be expensive, but the dataset update could be even more so.  I have been 
>told that the data readers/writers are going to change in the near future 
>to xml anyway, but it would be good to know if this is just a windows 
>problem.  I have been using the socketcommunicator for quite some time and 
>it doesn't exhibit these symptoms.  If you have some sample code, it might 
>be worth putting up on the list so people can test it...
>-Jeff

I'm going to be doing some testing on IRIX/LINUX and if there are any 
interesting results I'll post them.  I think its entirely possible that the 
vtk socket code does demonstrate the same symptoms.  As I said, for some 
reason, it only happens when the incoming polydata only changes slightly 
from the version currently in the reader.  It would be difficult to extract 
the code that I'm seeing this on, but perhaps I'll try to make a small 
sample that exhibits the same symptoms.

As far as the cost of the string compare, it seems to me that by uploading 
the responsibility of that check to the caller of the reader, you give the 
programmer the option to either spend the time checking, or not.  In my 
case, I'm performing that check already before sending the data down the 
socket, so its purely wasted time for me.  Its a small point, but perhaps 
even a "no check" option would be a good addition to the reader.

Thanks for the feedback Jeff.

Kevin.




>>Kevin.
>>
>>
>>>Kevin Wright wrote:
>>>
>>>>I just tracked down what looks like an odd bug, and I was wondering if 
>>>>anyone out there had any insight.
>>>>
>>>>I'm using a vtkPolyDataReader object to field incoming polydata 
>>>>definitions through a socket.  I do this by reading the polydata from 
>>>>the socket into a string, then using the input string in the vtkDataReader.
>>>>
>>>>Everything generally worked fine, except in some cases the pipeline 
>>>>would not update when new data came down the socket.  Eventually I 
>>>>tracked the problem down to vtkDataReader::SetInputString which, before 
>>>>assigning the string, does a string compare between the old and new string.
>>>>
>>>>When the new and old datasets were very similar (usually identical 
>>>>geometry, slightly changed scalar values) the strncmp would return a 
>>>>match.  The string length was correct, and once the string compare was 
>>>>removed, everything worked fine.
>>>>
>>>>I'm working on a Windows 2000 machine with VC++ 6.0.  I'm about to try 
>>>>the same thing on IRIX and Linux to see what happens, but I was wondering:
>>>>
>>>>1. Has anyone seen this kind of behavior before?
>>>>2. Should the string compare really be there at all, given that these 
>>>>strings could be very long?
>>>>
>>>>Regards,
>>>>Kevin.
>>>>
>>>>_______________________________________________
>>>>This is the private VTK discussion list. Please keep messages on-topic. 
>>>>Check the FAQ at: <http://public.kitware.com/cgi-bin/vtkfaq>
>>>>Follow this link to subscribe/unsubscribe:
>>>>http://public.kitware.com/mailman/listinfo/vtkusers
>>
>>
>>_______________________________________________
>>This is the private VTK discussion list. Please keep messages on-topic. 
>>Check the FAQ at: <http://public.kitware.com/cgi-bin/vtkfaq>
>>Follow this link to subscribe/unsubscribe:
>>http://public.kitware.com/mailman/listinfo/vtkusers
>>
>