[Insight-developers] STL libraries

[Miller, James V (CRD)]

I think VTK does use streams in threaded functions. If it doesn't then we must not have any debug
macros in any imaging filters.

The reason we need this is that STL does not default to using thread safe containers (not even trying
to thread access to a single instance of a container but rather have two threads operate on separate
instance of a container is not thread safe).  If you tell STL to use thread safe containers, then you
cannot compile against the SGI streams library.  I think ITK won't even compile if you try to use
thread safe containers and the standard streams library. If it did compile, then it crashes on the
access to a stream.

VTK probably does not have this problem because we probably have not told it to build with thread
safe STL containers.

I think it will be very bad for ITK if someone can try to build ITK on the SGI and be presented with
1000s of compiler errors or worse ITK builds but everything crashes.

If everyone is really against having this code in the repository. Then I suggest the following:

Configure the build process so that if using the SGI compiler, makefiles will not be generated unless
this version of Standard Library is available. CMake will print out a message saying what is needed
and where to get it (it a free download from SGI).  Once people set the cache entry satisfactorily,
then makefiles will be generated.

The bottom line is that I do not want people to be able to used the SGI compiler without having an
appropriate Standard Library.  




-----Original Message-----
From: Bill Hoffman [mailto:bill.hoffman@kitware.com]
Sent: Wednesday, December 19, 2001 12:02 PM
To: Lorensen, William E (CRD); 'Will Schroeder'; James V. Miller
Subject: RE: [Insight-developers] STL libraries


Jim, why do we need this again?
It came from using the stream library in threaded executes right?
VTK does not have this problem, because it does not use the stream
library in threaded functions.

Can we just say that you can not use the stream library in threaded functions...

-Bill


At 11:49 AM 12/19/2001 -0500, Bill Hoffman wrote:
>distribute it, OK, but not via cvs.
>
>
>
>At 04:06 PM 12/18/2001 -0500, Lorensen, William E (CRD) wrote:
>>We have to distribute it. Change the name if you want. Call it SGISTL or something like that.
>>
>>
>>-----Original Message-----
>>From: Bill Hoffman [mailto:bill.hoffman@kitware.com]
>>Sent: Tuesday, December 18, 2001 1:27 PM
>>To: Lorensen, William E (CRD); 'Will Schroeder';
>>insight-developers@public.kitware.com
>>Subject: RE: [Insight-developers] STL libraries
>>
>>
>>I disagree, we do not want to support a copy of the c++ stdlib in ITK.
>>It will get old, and modified by ITK people if it is in the tree.
>>Perhaps a tar file that you can download for the SGI.   But I think it is a bit
>>much to include the c++ stadard library in our system.
>>
>>-Bill
>>
>>
>>At 12:05 PM 12/18/2001 -0500, Lorensen, William E (CRD) wrote:
>>>I disagree. The default is not to use them. People should be able to just download itk and build.
>>The
>>>build process is already complicated...
>>>
>>>
>>>-----Original Message-----
>>>From: Will Schroeder [mailto:will.schroeder@kitware.com]
>>>Sent: Tuesday, December 18, 2001 11:33 AM
>>>To: insight-developers@public.kitware.com
>>>Subject: [Insight-developers] STL libraries
>>>
>>>
>>>Hi Folks-
>>>
>>>We are concerned about the STL libraries in Insight/Utilities. We are concerned that this will
cause
>>>confusion and build problems down the road. It might be better to have a tarball for those using
the
>>>SGI, since they were checked in for the sake of the SGI. Other systems should use their own
>>>compiler's version of the STL library.
>>>
>>>Will
>>>
>>>_______________________________________________
>>>Insight-developers mailing list
>>>Insight-developers@public.kitware.com
>>>http://public.kitware.com/mailman/listinfo/insight-developers
>>>_______________________________________________
>>>Insight-developers mailing list
>>>Insight-developers@public.kitware.com
>>>http://public.kitware.com/mailman/listinfo/insight-developers 
>>_______________________________________________
>>Insight-developers mailing list
>>Insight-developers@public.kitware.com
>>http://public.kitware.com/mailman/listinfo/insight-developers 
>
>_______________________________________________
>Insight-developers mailing list
>Insight-developers@public.kitware.com
>http://public.kitware.com/mailman/listinfo/insight-developers