[filesystem] Compatibility with STLPort
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
On Sun, Aug 30, 2009 at 10:18 AM, Andrey Semashev <andrey.semashev@gmail.com
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. Is this something STLPort intends to fix, by the way? --Beman
Beman Dawes wrote:
On Sun, Aug 30, 2009 at 10:18 AM, Andrey Semashev <andrey.semashev@gmail.com
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.
Andrey Semashev wrote:
Beman Dawes wrote:
On Sun, Aug 30, 2009 at 10:18 AM, Andrey Semashev <andrey.semashev@gmail.com
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?
Andrey Semashev wrote:
Andrey Semashev wrote:
Beman Dawes wrote:
On Sun, Aug 30, 2009 at 10:18 AM, Andrey Semashev <andrey.semashev@gmail.com
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.
On Mon, Sep 21, 2009 at 11:22 AM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
Andrey Semashev wrote:
Andrey Semashev wrote:
Beman Dawes wrote:
On Sun, Aug 30, 2009 at 10:18 AM, Andrey Semashev <andrey.semashev@gmail.com
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
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. :)
participants (3)
-
Andrey Semashev -
Beman Dawes -
Gottlob Frege