[vtkusers] string compare bug?
krw at viz-solutions.com
Mon Oct 7 17:32:27 EDT 2002
At 05:13 PM 10/7/2002 -0400, you wrote:
>>>Are you using vtkSocketController/vtkSocketCommunicator? These objects
>>>already do this under the hood.
>>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...
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 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?
>>>>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:
>>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:
More information about the vtkusers