Re: [boost] [filesystem] Compatibility with STLPort

Subject: Re: [boost] [filesystem] Compatibility with STLPort
From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2009-09-21 11:43:31

On Mon, Sep 21, 2009 at 11:22 AM, Andrey Semashev
<andrey.semashev_at_[hidden]> wrote:
> Andrey Semashev wrote:
>>
>> Andrey Semashev wrote:
>>>
>>> Beman Dawes wrote:
>>>>
>>>> On Sun, Aug 30, 2009 at 10:18 AM, Andrey Semashev
>>>> <andrey.semashev_at_[hidden]
>>>>>
>>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> 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).

Tony