::boost::detail::empty_base could be improved

[sparent@…]

The empty base class used by the operators library will not actually be empty if you have a class inheriting from operators and the first member also inherits from operators - the work around is to have an empty_base<T> to ensure a unique type - so you end up with:

class my_class : equality_comparable<my_class, my_class, empty_base<my_class> > { ...

Kind of gross - such a base could be included directly in the operator library.

Sean

[Daniel Frey]

Accepted, but raised milestone to 1.35.0 as the risk of breaking other compilers is not worth it. Once regression tests show that everything is fine, I might consider moving it back to 1.34.1, but it should not delay 1.34.1.

[Daniel Frey]

Fixed in CVS HEAD

[Thomas Witt]

Reopened for inclusion in 1.34.1

[Dave Abrahams]

I can't see how this is appropriate for 1.34.1

It's NAD, in my opinion, and should be put off until the next full release.

[sparent@…]

Although I have a work around so putting off until 1.35.0 is fine with me - the work around is ugly and I do consider a helper template that adds unnecessary words to my objects a defect.

[Thomas Witt]

Replying to dave:

I can't see how this is appropriate for 1.34.1

It's a "simple" change, passes testing on HEAD and it won't delay 1.34.1 even if we have to back it out again.

It's NAD, in my opinion, and should be put off until the next full release.

If this were a commercial project I would agree. My experience is that a more opportunistic approach is required for boost. There is no way prioritizing changes when you can not prioritize work items.

[Dave Abrahams]

Replying to witt:

Replying to dave:

I can't see how this is appropriate for 1.34.1

It's a "simple" change, passes testing on HEAD and it won't delay 1.34.1 even if we have to back it out again.

Unless the change is not exactly as proposed in the summary of this ticket, it is a breaking change for users. I can't imagine any good excuse for doing that in a point release, and I object strongly to doing so.

[Thomas Witt]

Replying to dave:

Replying to witt:

Replying to dave:

I can't see how this is appropriate for 1.34.1

It's a "simple" change, passes testing on HEAD and it won't delay 1.34.1 even if we have to back it out again.

Unless the change is not exactly as proposed in the summary of this ticket, it is a breaking change for users. I can't imagine any good excuse for doing that in a point release, and I object strongly to doing so.

Dave, I have attached the proposed patch. This may very well be my fault. I never intended to add a breaking change. Looking at the patch I still can't figure it out. What am I missing?

[Dave Abrahams]

Sorry, the mistake is mine. I didn't realize, from the example, which used no qualification and showed empty_base named in what is presumably user code, that empty_base was in boost::detail. As long as users aren't touching empty_base the patch is OK.

[Thomas Witt]

Replying to dave:

I always assumed everything in boost::detail is fair game. Should we be more conservative?

[anonymous]

Replying to witt:

Replying to dave:

I always assumed everything in boost::detail is fair game.

Well, it should be... but occasionally you see stuff like this:

http://www.boost.org/libs/serialization/doc/archive_reference.html http://www.boost.org/libs/serialization/doc/derivation.html

Should we be more conservative?

I don't think so. Did ​http://svn.boost.org/trac/boost/ticket/979#comment:11 lead you to think I would say otherwise.

[Thomas Witt]

Replying to anonymous:

Replying to witt:

Replying to dave:

I always assumed everything in boost::detail is fair game.

Well, it should be... but occasionally you see stuff like this:

http://www.boost.org/libs/serialization/doc/archive_reference.html http://www.boost.org/libs/serialization/doc/derivation.html

Sigh!

Should we be more conservative?

I don't think so. Did ​http://svn.boost.org/trac/boost/ticket/979#comment:11 lead you to think I would say otherwise.

No, not really. I am just paranoid about misunderstandings with release issues ;-).

[Daniel Frey]

Applied patch to RC_1_34_0. Sorry Dave, I should have added the patch to the ticket from the very beginning.