## C++ fun

 error: value of type 'std::__1::__map_const_iterator<std::__1::__tree_const_iterator<std::__1::__value_type<float, TStrongObjectPtr<UObject> >, std::__1::__tree_node<std::__1::__value_type<float, TStrongObjectPtr<UObject> >, void *> *, long> >' is not contextually convertible to 'bool' 

## Comment viewing options

### What language has inspired

What language has inspired more language designers than C++?

C? Lisp? Algol?

### Failure to pith

I had mind programmers that encounter some state of affairs in C++ (perhaps the above error message) and are inspired by the thought "I can do better than this."

### None

If you're looking for inspiration to build a better language, C++ is hard to beat. 'nuff said. :-)

Though in fairness, lots of better languages have existed before and after C++ that had little uptake. C++ definitely broke some ice there.

### Pith lord

I knew where you were headed ... ;-)

### Error messages in general

Back in college I wrote an experimental compiler for a language with moderately extensible syntax. As the error-message generation techniques I'd been taught were evidently inapplicable (customized entries hand-crafted for particular cells in massive, and fixed, LR tables), I set up a technique based on placing each error in a context that ought to make sense to the programmer. As the compiler parsed source code, each token was stamped with its source file, line number, and column numbers, each compound expression with its source file and starting/ending line/column, and likewise semantemes got stamped with the source-code locations of the expressions that declared them. When there was an error, the compiler would include in the message up to about three lines of source code, with the relevant region shaded, and a very general description of what had gone wrong. It was really stunning to me how much more lucid these messages were than anything I was used to; the broadness of the error descriptions made them consistently understandable, and with that much of a hint at the abstract difficulty, the highlighted source regions generally made the problem immediately obvious. The common practice of identifying an error with a single line/column location seemed like an obviously bad choice in retrospect.

Re the diagnostic tradition inherited by C++ from C, I recall from a graduate compilers class (a few years later) a remark by the professor, concerning the notoriously indecipherable C error messages, that it makes perfect sense if you know the guy who originally wrote them — I think his exact words were, "Dennis doesn't make mistakes".

### Seen worse

I've seen worse while I was developing the Egel interpreter. The bad part, not really getting what is going on and poking at the code in different manners to get it to pass.

I am still in favor of burning down Stroustrup's house. Language developers should feel the pain for what they inflict on poor programmers.

### He does feel the pain,

He does feel the pain, burning down his house is not necessary.

- dup -