Re: [boost] New libraries implementing C++11 features in C++03

Subject: Re: [boost] New libraries implementing C++11 features in C++03
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2011-12-01 13:26:09

Dean Michael Berris wrote:
> On Fri, Nov 25, 2011 at 6:10 AM, Daniel James <dnljms_at_[hidden]> wrote:
> > On 24 November 2011 13:35, Dean Michael Berris
> <mikhailberis_at_[hidden]> wrote:
> >>
> >> Why are people blaming the libraries for horrible error messages when
> >> it's compilers that spew these error messages?
> >
> > They just don't want to use a library which has horrible error
> > messages. It doesn't matter if it's the library's fault or the
> > compiler's fault. Blame has nothing to do with it.
>
> But it's not the library emitting these horrible error messages. So
> why is this tied with the library and not the compiler? Why aren't
> people saying "I don't want to use this compiler because it's crappy
> at generating error messages for *any* code"?

I'm astounded at this line of thought, Dean.  When choosing between two courses of action with reasonably equivalent outcomes, surely the one with the least cost is better.  Thus, if using a library that is prone to triggering horrible error messages when misused is compared against using another library this does not trigger such error messages when misused, the choice is clear.

You've complained that the error messages only occur when the library user makes a mistake.  When challenged with the notion that errors occur as a normal part of coding, you seemed incredulous.  (I rarely write mistake-free code on the first try, particularly with libraries like Spirit, despite decades of experience.)  A developer writes some code, compiles it, inspects the error messages, tries to determine the cause, changes the code, and repeats.  Many libraries trigger reasonably easy to grok error messages.  Others, notably those using TMP, trigger difficult to grok error messages.  That's a fact.  It doesn't matter whether those messages could be better by virtue of library or compiler changes.  Thus, the middle steps are much easier with some libraries than others.  If, given a particular library and compiler, a developer encounters troublesome error messages and has little time, inclination, or value expectation to learn enough to deal with them, that developer will select another solution that makes arriving at working code easier.  This should be obvious.

For many, then, avoiding a TMP-based program is a desirable choice.  For them, a library like Local is a better means to the desired end.  (This has nothing to do with whether Local should be accepted.)  Both kinds of libraries can coexist in Boost, although those in each group should compare and contrast with the other choices to help users decide, once multiple choices exist.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer                     using std::disclaimer;
Dev Tools & Components
Susquehanna International Group, LLP  http://www.sig.com

________________________________

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.