Date: 2001-01-22 21:25:42
Thank you very much for completing the survey. We are very interested
in the views, suggestions, and concerns of all users.
We take ISO compliance very seriously, and are actively addressing
I shall ensure that your comments are discussed by the team.
Visual C++ Compiler Team
--- In boost_at_[hidden], "Dejan Jelovic" <djelovic_at_s...> wrote:
> David Wolfram wrote:
> > 2. If you cannot use Visual C++ with these libraries, what are the
> > causes of this? For example, does the library require partial
> > template specialization support? Do other issues also prevent you
> > from using the library with Visual C++?
> Almost all libraries work with Visual C++. This compiler is used by
> something like 50% of the world's C++ programmers, so all vendors
> support it as much as they can.
> Getting a template-heavy library to work in Visual C++, however,
> involves cutting out parts of its functionality and making all or
> members public.
> > 3. If you are a library developer, what workarounds or design
> > constraints were required for compatibility with Visual C++? What
> > were the most significant ones?
> VC++ 6/SP4 can't compile member templates and template friends. It
> produces an INTERNAL COMPILER ERROR or silently produces bad code.
> > Did the workarounds or constraints have performance impacts?
> No. The results of workarounds are:
> 1. Significantly reduced functionality.
> 2. Public data members.
> > I hope to hear from you, and shall summarize the replies if they
> > numerous.
> Let me use this opportunity to make a suggestion to the VC++ team:
> Why don't you replace Dinkumware's STL with STLport? I'm sure Boris
> willing to license STL to you guys on very favorable terms, and
> take care of whole lot of headaches.
> Two reasons why this would be a good move:
> 1. Dinkumware still has a number of bugs.
> 2. STLport has a debug mode in which it checks if one is using
> iterators, incompatible iterators, etc. This is extremely useful.
> Dejan (www.jelovic.com)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk