From: Robert Ramey (ramey_at_[hidden])
Date: 2005-05-28 12:05:15
Please don't get the impression I'm not sympathetic to you're (and others
concerns about this). I am. We'll hear on the list complaints about this
from time to time. On the other hand, we won't hear complaints from those
who encountered the STATIC_ASSERT, puzzled a bit, maybe read the manual and
tweaked the code so the STATIC_ASSERT goes away, and serialization works
just as we expect it to.
If we don't trap this situation, serialization tracking will not work and
the error will not be immediatly apparent and users may have to spend a
very, very, long time to track it down. We may not even hear from these
people as they might just conclude its not worth the effort. So, I'm not
confident that the number of "broken cases" complained about on the list is
an accurate indicator of what the correct thing to do is.
I don't see this change as "breaking code" but rather detecting code that is
very likely already broken.
So, as I said, its not that I'm unsympathetic to your point of view, I just
don't think everyone is sympathetic to mine.
Jeff Garland wrote:
> On Fri, 27 May 2005 20:48:51 -0700, Robert Ramey wrote
>> This is not a problem with your serialization function. But
>> somewhere else. Note the section in the manual under "tracking"
>> addresses this. This describes requirements re const-ness that were
>> documented but only recently enforced.
> Yet more fallout from the 'const-enforcement' change and it hasn't
> even been released. I predict an explosion of user problems after the
> release of 1.33 as working code fails to compile and users are force
> to artificially make things 'const'. I'll shutup after this email,
> but in case it wasn't obvious I think this serialization change is
> very misguided...
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk