===========================
VC7/Visual Studio.NET Notes
         9/28/2001
===========================


------------------------------
Always use /WL when compiling!
------------------------------

STLFilt.pl 2.x provides Visual Studio.NET support,
but ONLY if you compile using the /WL ("one line") compile
option. This condenses VC7's new multi-line (and massively
space-wasting) new error format into a contiguous-line
format.

When the error Decryptor sees messages in the VC7 /WL format,
it processes the "with" clauses by substituting all the
place-holder names with the types they represent. The net effect
(no pun intended) is a return to VC6-style messages, with
more-or-less Dinkumware 3.08 identifier names. There are few
changes from the Dinkumware 3.08 format however; VC7 makes
use of nested typedef names such as "value_type" and "_Pairib"
in its native messages. I've taken the liberty of massaging
those types back into VC6 format as well; I think the
explicit type information makes for more useful error
messages. 


Allocator Issues
----------------

An issue arose while integrating .NET support, relating to
the handling of allocator clauses. Previously, I used an
automatic heuristic to detect when the allocator clause was
"significant" (i.e., provided useful information): if the
word "allocator" was preceded by the text " to ", then
presumably the compiler was referring to some kind of error
in converting from "something to" the allocator type, and
we'd probably want to see the details of that type in the
message. All other mentions of allocators were stripped.

This is *still* the way it works when you're not compiling
with VC7. With VC7, the "to...allocator" heuristic fails
miserably, because of the new error message format. So, I
added an "allocator policy" option,  /alloc:x, configurable via
Proxy-CL.INI and/or the Proxy CL and Perl command lines.
You have a choice of either 'S' (Small) or 'L' (Large) allocator
policy, referring to the length of the messages produced.
"Small" pretty much deletes all allocator mentions
indiscriminately, while "Large" leaves them intact. The
default is 'S'.

The allocator policy options are COMPLETELY IGNORED if
you're not compiling with VC7!!!! (I check for those "with"
clauses, and only apply an allocator policy if a "with"
clause was detected on a particular line).

Note that with the "Small" allocator policy, allocator
information will be omitted from messages referring to
allocator errors, so those messages may not make sense. My
suggestion: If you're using custom allocators *AT ALL*
with VC7, set the ALLOCATOR_POLICY in Proxy-CL.INI to L;
otherwise, let it default to S.

Other Function Objects
----------------------

A similar issue arises with function objects in VC7 
messages, and a similar "Functor Policy" option is 
provided: /func:x, with the same choice of Small or 
Large functor expansions. With /func:S, functors are
stripped; with /func:L, they're left intact. The
defaults is 'S'.

As with /alloc, the /func policy option is COMPLETELY 
IGNORED if you're not compiling with VC7.

vector<unsigned> Issue
----------------------

Something weird is happening with vector<unsigned> (at
least under VC7 Beta 1): VC7 seems to be confusing these
with vector<bool>. Just a head's up...the weirdness you
see when using vector<unsigned> is not the decryptor's
fault!
