Re: [boost] BGL, iterator_adaptors, VC6, STLport debug mode

From: Jeremy Siek (jsiek_at_[hidden])
Date: 2000-12-21 12:44:15

But can the usability for 2) be regained by using a type generator?

On Thu, 21 Dec 2000, David Abrahams wrote:

abraha> 
abraha> 
abraha> I just spent a few days tracking down a problem which turned out to be that
abraha> this particular combination is poison for me. The symbol names end up going
abraha> past MSVC's arbitrary length limits.
abraha> 
abraha> The question is, what to do about it? We could turn off iterator_adaptors
abraha> when __STL_DEBUG and BOOST_MSVC are #defined, but of course with MSVC we run
abraha> a risk of breakdown even without __STL_DEBUG.
abraha> 
abraha> I've had some other thoughts:
abraha> 
abraha> 1. Change the default type parameter for Traits to void (or something). Then
abraha> detect that it's void inside the class using boost::is_same from
abraha> type_traits, and select boost::iterator_traits<> for a traits_type typedef
abraha> using template "magic". I believe we can easily provide
abraha> boost::iterator_traits<> for compilers without partial specialization by
abraha> using boost::is_pointer<>. This would cut down on the symbol lengths for
abraha> adapted iterators that can use the default Traits parameter, but it wouldn't
abraha> help in cases where an explicit iterator_traits was needed.
abraha> 
abraha> 2. The best way to get the symbol names to be really short in many cases is
abraha> to cut down on the number of template parameters to iterator_adaptors. For
abraha> example, we could ask people to deliver the Iterator parameter and Traits as
abraha> typedefs in the Policies class instead of as separate parameters. I'm none
abraha> too fond of this idea, since I believe it will harm usability in generic
abraha> code.
abraha> 
abraha> Thoughts?
abraha> 
abraha> -Dave
abraha> 
abraha> 
abraha> 
abraha> 
abraha> 

----------------------------------------------------------------------
 Jeremy Siek                        www: http://www.lsc.nd.edu/~jsiek/
 Ph.D. Candidate                  email: jsiek_at_[hidden]
 Univ. of Notre Dame         work phone: [phone]
----------------------------------------------------------------------