Re: [CODE] Windows Issues

From: Patrick Dughi (
Date: 01/03/01

> If I'm not mistaken the C++ guidelines say that if you are declaring a
> template within a template that you need to put spaces around the '<' and
> '>' to not confuse the compiler between the operator >>
> Thus you would write it:
> map< string, map< string, int > > variable_name;
> you can also:
> typedef map< string, int >      map_str_int;
> map< string, map_str_int > variable_name;
        I figured if I could get it to work, a typedef would work..
However, there's a minor problem with using MSVC and the stl - see, it has
to do alot of name mangling, and for stl names, that's pretty long.
Longer, infact than the recommended length for MSVC's compiler.

 ==> Never mind right now, that you don't have the ability to affect <==
 ==> how the compiler does its name mangling.  In a nutshell, it is  <==
 ==> telling you "hey! I can't do what I'm made to do, and somehow it<==
 ==> is your fault. Perhaps you can change how MSVC handles this, but<==
 ==> if so, it is far from intuitive.  You know, like the pragma     <==
 ==> listed below...                                                 <==

        A simple inclusion of the line #pragma warning(disable:4786)
before any stl includes/usage is enough to quash this warning.  However, a
more unquashable warning comes up when i use the fix above - the correct
spacing (which is gobbled, and I assume works as intended - thanks for the
quick response).  The warning is simply that the name the compiler came up
with was far too long, and therefore, was truncated.

                          *snip off the end*

        What a wonderful solution!  Fired with heady dreams of unlimited
power and rollicing imagination, I went over to my credit card bill,
snipped off the trailing 5-6 items with some scissors, and bam! It's
fixed!  Now I only owe 35.40$ for gas.  What an intuitive gesture!  Maybe
I should snip the line item for gas off too!

        As you can see, I don't exactly approve of MSVC's behavior.  Can't
find a way around it, and I can only assume that this has the potential to
cause errors.  So I'll stick with the encapsulating class, despite it all.

        At least I know the right way to do it now.

> I think I read this in Stroustrup's "Design and Evolution of C++"; which is
> a definate buy for anybody interested in the principals behind design
> decisions of C++.

        I shall have to aquire that book.


   | FAQ: |
   | Archives: |

This archive was generated by hypermail 2b30 : 12/03/01 PST