Re: [Stlport-devel] Ancient compilers support

[<fra...@fr...>]

    I think I found a good description of my position. I agree to remove 
any compiler specific workaround you consider as dead, this is what I 
have done for VC5. But please send a message first if you are thinking 
about removing any official STLport workaround like 
_STLP_NO_MEMBER_TEMPLATES, _STLP_NO_CLASS_PARTIAL_SPECIALIZATION that is 
to say workarounds that are described in stlport/stl/stl_mycomp.h.

    About locale support, I have started to work on it even if I haven't 
have a lot of time to work on it recently. So tell me if you have 
started something on your side.

Bests


Petr Ovtchenkov wrote:
> On Friday 08 December 2006 23:46, you wrote:
>   
>> You are welcome Petr for 5.1 release. There are still however some 
>> points left to complete it:
>> - Tag in SVN: I haven't been able to create one, I don't know why as tag 
>> for RC1 to 3 has not been a problem. I saw that you have already created 
>> a tag STLport-5.1.0, it is the real one ?
>>     
>
> Yes, I made tag and put to rights other (historical) tags and branches.
>
>   
>> - Web site update: I have plan to update Web site but I would like to 
>> know first what HTML editor you are using.
>>     
>
> XEmacs or vi. As for any text file edition.
>
>   
>> I try several one but each  time I save file everything is modified.
>>     
>
> ;-) 
>
>   
>> There is also a small issue  
>> with it, FAQ in web site is great but some answer depends on STLport 
>> version. Putting in answer something like "if you use STLport before x.x 
>> do that overwise do this" is not very clean.
>>     
>
> Ok. FAQ will be separated by MAJOR.MINOR STLport versions. Good suggestion.
>
>   
>>     For old compiler support, I have already clean VC5 pseudo support in 
>> trunk. I had a version of this compiler, that I have removed now, and 
>> was sure that we were not supporting it so it was safe to clean it.
>>     
>
> Francois, this was joke. I know that STLport work with VC5 only with my
> kicks, only as static lib, and it was STLport 3.5 or 4.1 IIRC. VC5 never was
> 'officially' supported by STLport. :-)
>
>   
>> For other compilers I don't think we should hurry in cleaning everything. 
>> Trying to keep support for old compilers like the Open Watcom one forces 
>> us to keep things simple in STLport. Of course we have to find a good 
>> balance between support of limited compilers and support of more advance 
>> feature. For instance, for Open Watcom, I think that I have done most of 
>> the things that could be done in STLport. At the same time I have sent a 
>> message to the Open Watcom community to report last issues, I hope they 
>> will do the other part of the way.
>>     
>
> There are still many bogus workarounds (died code in most cases) for
> compilers that really can't work near C++ standard.
> I mean old HP's aCC, SunPro's (SunSoft's) CC 4.2, 5.0, 5.2(?) (don't know
> about later versions); died KCC; gcc before 3.2.x (well, we can work
> with some restrictions with 2.95.x, but since kernel may be compiled
> by modern compilers, I don't see any reasons to spend time for old
> problems workarounds).
>
> If you see on the size of executable and library with STLport (or other
> template-based C++ sources), you see that DOS beyond our target
> platform too. So any DOS-oriented compilers may be omitted too.
>
> I don't understand the target tasks for Open Watcom; I may imagine
> the reason to play with Borland---integration with Delfy, right?
> But don't see reasons for Metrowerks CodeWarrior on any platform
> (NetWare died, classic MacOS---the same reasons as for DOS, is anybody
> use it under Windows in it best years?).
>
> VxWorks, QNX, au? I never hear ones...
>
> As about eVC, what about Michael's suggestion?
>
> The removing obsolete code will help to clean place for solution at least
> for three problems:
>
>    - locale support
>    - wide chars (+ locale again)
>    - file io background (here tonns of died code, even not clear what really
>      useful)
>
> Bests,
>
>    - ptr
>
>
>