[Bf-committers] Re: MEM_CacheLimiter breaks msvc6 compile unrepairable

[Kenneth Styrberg]

As one of the few using MSVC 6, I also tend too lean ditching it for 
Blender. Most of my concern was to start using other compilers/IDE's as 
I'm sort of a happy user of MSVC 6 for some years now.

//styken

bjornmose wrote:

> Peter Schlaile wrote:
>
>> Hi Ole,
>>
>>
>>> i tried for a while to get over STL problems arising on msvc6 with 
>>> this new
>>> classes.
>>>
>>> Finally i
>>> found:
>>>
>>> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclang98/HTML/MEMORY_allocator.asp 
>>>
>>> So, was it decided to drop msvc6 as a supported build system?
>>
>>
>>
>> Nope. I used a C++ compiler to develop it, not MSVC-6 ;-)
>>
>> Seriously: Have you tried removing the rebind-code completely from the
>> MEM_Allocator.h-file?
>>
>> If this works for you, could you just mail to me a preprocessor-variable
>> which enables me to check for MS-VC6?
>>
>> Or just try to add this:
>>
>> #ifndef __MSVC6__whatever_you_have_to_test_to_detect_msvc6__
>>     template<...> rebind()
>> #endif
>>
>> Also could you just mail the compiler error messages to me?
>>
>> Greetings,
>> Peter
>
>
> ok tried commenting out that rebind stuff,
> but as expected instation of
>
> typedef std::list<MEM_CacheLimiterHandleCClass*,
>           MEM_Allocator<MEM_CacheLimiterHandleCClass* > > list_t;
>
> a few lines later :
>     list_t cclass_list;
> bails out with the meaningfull error message: (me loves msvc6 STL 
> support for that)
>
> MEM_CacheLimiterC-Api.cpp
> C:\Programme\Microsoft Visual Studio\VC98\INCLUDE\list(130) : error 
> C2143: syntax error : missing ';' before '<end Parse>'
>         C:\Programme\Microsoft Visual Studio\VC98\INCLUDE\list(129) : 
> while compiling class-template member function '__thiscall 
> std::list<class MEM_CacheLimiterHandleCClass *,struct 
> MEM_Allocator<class MEM_CacheLimiterHandleCClass *> >::std::list<c
> lass MEM_CacheLimiterHandleCClass *,struct MEM_Allocator<class 
> MEM_CacheLimiterHandleCClass *> >(const struct MEM_Allocator<class 
> MEM_CacheLimiterHandleCClass *> &)'
> Error executing cl.exe.
>
> in <list>
> ...
>     explicit list(const _A& _Al = _A())
> here-->        : allocator(_Al),
>         _Head(_Buynode()), _Size(0) {}
> ...
>
> but like i said expected since
>
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclang98/HTML/MEMORY_allocator.asp 
>
>
> states:
> ".. This means you cannot write an allocator that uses any pointer or 
> reference types that differ from those used by allocator, ..."
>
> and i think that's exactly what
> typedef std::list<MEM_CacheLimiterHandleCClass*,
>           MEM_Allocator<MEM_CacheLimiterHandleCClass* > > list_t;
> is supposed to do.
>
> stivs,
> this aticle
> http://www.codeguru.com/Cpp/Cpp/cpp_mfc/stl/article.php/c4079
> also mentions STLport, but i read it as:
> there are some cumbersome workarounds that may work in some special 
> cases.
>
> to resume my point of view:
> - we know that STL implementation in msvc6 is poor ( to use friendly 
> words )
> - if we decide to use C++/STL with bells and whistles we might be 
> better off ditching mcvc6
> - which would be a pitty for me ( and may be some others ) owning a 
> legal copy of that 'pile of garbage'
> - but well, times are changing and MS has quit msvc6 support
>
>
> again, i may be totally wrong .... sigh ....
>
> ole
>
> P.S. Peter, we're proud of you using a real C++ compiler ... btw on 
> windows i have cygwin with gcc and the free vc7 compiler running too. 
> I can boot to linux and complile there. So to me it's a esoteric self 
> punishment to keep blender compiling on msvc6. ( hope you smell the 
> sarcams in there )
>
>
>
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-committers
>