Visual Studio 6 Compiler Error

Thanks for the hard work, Ken, but I think I officially claim defeat
on this. After using your patch I got a few obvious errors then ran
into this (pasted below).

Thanks again,

building tkagg 2 3
        Building for python23
running build
running build_py
running build_ext
No module named msvccompiler in numpy.distutils, trying from distutils..
building 'matplotlib.backends._na_backend_agg' extension
C:\Program Files\Microsoft Visual Studio\VC98\BIN\cl.exe /c /nologo /Ox /MD /W3
/GX /DNDEBUG -Iwin32_static\include -I. -Isrc -Iswig -Iagg23/include -I. -Iwin32
_static\include -I. -Iwin32_static\include\freetype2 -I.\freetype2 -Isrc\freetyp
e2 -Iswig\freetype2 -Iagg23/include\freetype2 -I.\freetype2 -Iwin32_static\inclu
de\freetype2 -I.\freetype2 -Ic:\Python23\include -Ic:\Python23\PC /Tpsrc/_na_bac
kend_agg.cpp /Fobuild\temp.win32-2.3\Release\src/_na_backend_agg.obj -DNUMARRAY=
src/_na_backend_agg.cpp(63) : warning C4800: 'long' : forcing value to bool 'tru
e' or 'false' (performance warning)
C:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\xlocnum(267) : fatal error
        (compiler file 'msc1.cpp', line 1794)
         Please choose the Technical Support command on the Visual C++
         Help menu, or open the Technical Support help file for more information

        C:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\xlocnum(263) : whi
le compiling class-template member function 'class std::istreambuf_iterator<char
,struct std::char_traits<char> > __thiscall std::num_get<char,class std::istream
buf_iterator<char,struct std::char_traits<char> > >::do_get(class std::istreambu
f_iterator<char,struct std::char_traits<char> >,class std::istreambuf_iterator<c
har,struct std::char_traits<char> >,class std::ios_base &,int &,void *& ) const'

error: Command ""C:\Program Files\Microsoft Visual Studio\VC98\BIN\cl.exe" /c /n
ologo /Ox /MD /W3 /GX /DNDEBUG -Iwin32_static\include -I. -Isrc -Iswig -Iagg23/i
nclude -I. -Iwin32_static\include -I. -Iwin32_static\include\freetype2 -I.\freet
ype2 -Isrc\freetype2 -Iswig\freetype2 -Iagg23/include\freetype2 -I.\freetype2 -I
win32_static\include\freetype2 -I.\freetype2 -Ic:\Python23\include -Ic:\Python23
\PC /Tpsrc/_na_backend_agg.cpp /Fobuild\temp.win32-2.3\Release\src/_na_backend_a
gg.obj -DNUMARRAY=1" failed with exit status 2


On 4/13/06, Ken McIvor <mcivor@...227...> wrote:

On Apr 13, 2006, at 9:23 PM, Charlie Moad wrote:
>> I'm thoroughly confused about how the STL comes into play if VC++6 is
>> dying because it can't handle the code constructs in use.
> My impression of the error is that the first argument, which is a
> template, is confusing the vs6 compiler. There are docs everywhere
> saying that vs6 doesn't handle templates worth a darn. All this
> together forms my hunch, but I may be totally wrong.

Templates are a feature of the C++ language. It sounds like you're
running up against fundamental limitations of the compiler. If that
is the case, then changing from one implementation of the STL to
another probably won't do anything.

>> I'm not following John's comment about the animation blit... I
>> thought that the
>> _n?_backend_agg module(s) are part of the Agg backend. Is John
>> proposing we drop Agg support under Python 2.3 / VC++6?
> So the reason that I made the vs7 build for python2.4 is that wx
> blitting in windows was not supported. Mingw is unable to link
> against the libs distributed by wxpython since they are created with
> vs. All John is saying is that people can probably live without wx
> blitting in python2.3 (we would still distribute the mingw 2.3 build).
> The tk and gtk aggs can still blit fine.

Ah, I think I understand now. The WxAgg backend supports blitting
without the _wxagg module, but it won't be as fast.

> Sounds great. I'll be more than happy to test out any of your
> changes. I am leaving town for the weekend tomorrow for Easter, so
> there may be a delay.

Attached is a patch against svn 2292. It works with GGC 3.3.6 on
Debian Stable. I'm not confident it will work under windows... as I
was wrapping it up I found that claims that "a template
cannot be declared a friend of a class" [1]. I guess it's worth a
shot, though.



Sweet, sweet INTERNAL COMPILER ERROR. I think the Boost folks have a strategy for working around this situation by hoisting the friend function template entirely outside of the class. I'll see what I can find online and try to submit another patch soon.



On 04/18/06 18:04, Charlie Moad wrote:

Thanks for the hard work, Ken, but I think I officially claim defeat
on this. After using your patch I got a few obvious errors then ran
into this (pasted below).


Is there a reason that the fill_and_stroke() and render_lines_path() methods of RendererAgg need to be templated? As far as I can tell, the template type is always agg::path_storage.