|
Boost : |
From: Jeff Garland (jeff_at_[hidden])
Date: 2005-05-28 13:06:25
On Sat, 28 May 2005 10:05:15 -0700, Robert Ramey wrote
> 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.
Well, I'd say that 'no one' is sympathetic to yours, yet ;-) I don't think
that Vladimir, myself, or the others that have posted on this topic are
convinced that this change is really going to prevent people from making the
error you are concerned about. OTOH, we can all see that much perfectly
working user code will now not compile and that in common use cases people
will start 'hacking' their code with casts or other work arounds b/c they want
to serialize non-const data. And while the interface might have been
documented during the review it's clear none of us understood the implications
-- we wrote code and when it worked we presumed that since it worked we
understood the interface...
Jeff
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk