Daniel Frey <[EMAIL PROTECTED]> writes: > Often, granted. But the above patch (the link I gave) shows, that we > also have already evidence of #ifdefs that should be removed.
Actually, there is some argument for keeping the #ifdef there. HP is currently working on fixing their compiler and using our regression tests to do it. With the #ifdef and the appropriate define to turn off workarounds, they will detect the bug. Without it, they won't. I really prefer the solution that uses a single implementation as you do, but I'm just trying to point out that determining which approach is superior isn't as cut-and-dried as you're making it out to be. >> I think everyone is happy to have improvements as long as they work. >> The bottom line is, if you want your "improvements" to be accepted, >> you have to invest the energy to make sure you're not going to break >> things for existing clients of the libraries. It's unrealistic and >> unfair to expect volunteer library maintainers to take your code and >> figure out how to make it work correctly, especially without ifdefs. >> Boost code lives in the real world, not in an idealized one where >> everything can be done "on principle." > > I tried my best to create an implementation that works in the real > world. I tested it for the GCC and the Intel compiler, which is all > I can do. I hoped for a discussion which might lead to an > implementation that works for a great variety of compilers but it is > not going to happen AFAICS. Well maybe we should start over. The way this whole thing started it sounded like a lot of judgemental complaining about the current state of the library without any willingness to bend your principles enough to do something that was actually practical. Let me also point out, just to be clear, that handling "a great variety of compilers" is not enough. Any solution we have has to work for all the currently supported compilers. > I don't see why it is unrealistic or unfair to think that some > boosters might be interested to work on it, though. It isn't unfair to expect that some boosters might be interested in working on the problem. It's unfair to expect that any particular booster will have the time and inclination to pursue a reorganization of working code for no gain in functionality, especially if it looks to them like you'd be willing to sacrifice a working implementation on some supported platforms in order to satisfy some aesthetic ideal. Personally, I don't believe there's any way your proposed is_class implementation can be bent so that it will work on many compilers. I've tried it. How do you envision the process of eliminating #ifdefs in that implementation is going to work if you're not going to run the tests on the other compilers and massage the code yourself? Pretty quickly whoever is testing on vc6 is going to lose patience with your goal of eliminating all #ifdefs, aren't they? > I don't expect my "improvements" to be the holy-grail that is > applied immediatly - it was just meant to start a discussion about > it. If you re-read the first message of this thread, I think you can > see that. I don't know; it looks to me like the beginning of the thread is mostly about (incorrect?) claims that the current implementation is broken. -- Dave Abrahams Boost Consulting www.boost-consulting.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost