Unofficial wish list status.(Jul 2008)

[Bill Baxter]

On Wed, Jul 23, 2008 at 9:35 AM, Brad Roberts <braddr at puremagic.com> wrote:

> On Wed, 23 Jul 2008, Bill Baxter wrote:
>
> > On Wed, Jul 23, 2008 at 8:27 AM, Brad Roberts <braddr at puremagic.com>
> wrote:
> > > On Tue, 22 Jul 2008, Walter Bright wrote:
> > >
> > By that do you mean something that's caused you actual trouble in C++
> > projects?  Or just something that keeps you awake at night worrying
> > about the trouble it could cause?  My feeling is that C++ const does a
> > decent job in practice of preventing programmers from doing stupid
> > things.  On the other hand, if you're trying to go out of your way to
> > be stupid... that's another matter.  But for the most part, while it
> > may be easy to circumvent const, it's not so easy to circumvent it
> > accidentally.  Useless for making compiler optimizations, yes, but
> > fine for documenting the intent of code.
> >
> > --bb
>
> I mean has caused real trouble.  I don't tend to make a lot of arguments
> based on theory.  Primarily they're made from hard earned practice.  C++
> does not make it possible (possibly too strong a statement, substitute
> easy if you can think of a loophole) to take an existing object that is
> poorly implemented for const-correctness and make that a contained object
> in another class that wants to behave const correctly.  It's way way too
> easy to make a mistake and have constness end without seeing it.
> Transitivity is what most more junior developers _expect_ from c++'s const
> system and it's not what they get.
>
> Secondarily, I _strongly_ value the benefit of const at the interface
> layer.  That's even more important to me than the other half of constness.
> I love D's use of contracts and const (as well as in, out, and inout)
> playes a big role there.
>
> Yes, it's a matter of mismatched exepctations, and it is possible to use
> const correctly in c++, but to do so requires (like so much of c++)
> considerable care.
>
> To clarify, I've spent much of my 20 year career as both a maintenance
> programmer and as a new code developer (roughly 50/50).  I tend to
> volunteer for the cleanup projects because no one else is willing to do
> it.  A lot of that time has been in multi-million line code bases that
> have been evolved extremely rapidly and haphazardly.  Yes it's the fault
> of the code as much as the language, but a language that gave better
> guarantees would have prevented problems and made ongoing maintenance
> easier by having a trustable const system.
>
> Make sense?
>

Yep.  Thanks for sharing your experience.  I'm a researcher, so while I've
been at this for coding thing for 20 years too, I don't tend to play around
with a lot of million-line code bases written by million-monkey junior
programmers.  I did do a short stint for a big, well-known software company
once, and got my taste of million-monkey code, though.  Scary stuff.  They
wanted me to modify some crufty parser to do some new tricks when there were
absolutely no unit tests or example programs or even documentation to show
me what it was supposed to be doing in the first place.  I'm amazed now that
they didn't tell me to "figure out this mess and document it first, writes
some unit tests, then add feature X" but instead they just wanted me to jump
right in and throw more gasoline into the fire.  Yikes.

--bb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20080723/019d0904/attachment.html>