Re: [boost] [filesystem] Compatibility with STLPort

Subject: Re: [boost] [filesystem] Compatibility with STLPort
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2009-09-21 12:04:43

Gottlob Frege wrote:

>>>>>> I've created ticket #3241 some time ago, with a patch attached. It's
>>>>>> about
>>>>>> Boost.Filesystem compatibility with STLPort expression templates
>>>>>> feature.
>>>>>>
>>>>>> So far no activity has appeared on it, although the fix is trivial. Is
>>>>>> it
>>>>>> OK if I go ahead and commit the patch?
>>>>>>
>>>>>> PS: Ticket URL is https://svn.boost.org/trac/boost/ticket/3241
>>>>>
>>>>> Unless I'm missing something, the code being replaced would be perfectly
>>>>> valid with a conforming implementation of the standard library, and only
>>>>> causes a problem because STLPort isn't conforming. Thus I'd rather use
>>>>> an
>>>>> #ifdef so that the replacement only applies to STLPort.
>>>> But the new code is also conforming. Is it worth to put an #ifdef when
>>>> the new code alone works everywhere?
>>>>
>>>>> Is this something STLPort intends to fix, by the way?
>>>> I didn't ask, as I don't think this can be fixed in STLPort. Unless, by
>>>> disabling the template expressions altogether, that is, which is already
>>>> possible. But it would be a pity to lose this optimization because of one or
>>>> two places of incompatibility that are so easy to fix.
>>> Ping?
>> Ping 2? I would really like this issue settled for the upcoming release.
> 
> Personally, I wouldn't accept the patch without some comments in it
> stating that separated lines (or a cast) is required for some systems
> (ie STLPort) where result_of(string + string) != typeof(string) or
> something like that.
> An #ifdef does that. (pro)
> It also means 2 code blocks to maintain instead of one. (con)
> 
> So even though the patch is conforming, (and by chance could have been
> written that way originally), I wouldn't want to lose the
> compatibility information now that we have it (one way or another).

No problem, I can add a comment that says why it is written that way. 
Actually, I don't mind #ifdef'ing the workaround, it just seems too 
clumsy for this trivial problem to me. Anyway, all I need is a green 
light from the library maintainer. :)