Hacker News Reader

Comment by barumi | Hacker News Reader

> The syntax is complicated and the debugging is messy.

Truth be told, the syntax is not complicated. What's complicated is how templates are abused to do stuff that wasn't identified in the feature's initial design requirements.

Debugging is an implementation issue, not a language design issue.

Templates are awesome. STL's generic containers are a blessing to the point where they can be used in practically all applications without the developer giving a second thought.

View on HN

If you have an implementation issue which no implementation has managed to overcome, then you probably have a language design issue.

I have very limited exposure to C++, so I'm not sure whether you're saying that some implementations have gotten this right. That isn't the impression I get as an outsider.

> If you have an implementation issue which no implementation has managed to overcome

I recall a time where GCC's error messages were infuriatingly cryptic.

Then clang came up, and suddenly cryptic error messages were not only clear but helpful in identifying root causes.

If your line of thought made sense, C++ would have been an awful language until clang fixed it.

Don't confuse "implementation X didn't bothered to pay attention to a feature" with an issue in how a language was designed.

Very true. clang seemed to give gcc a much needed kick up the arse. Even M$ are taking their C++ compiler, and standards adherence, seriously again.

I think you're misinterpreting OPs post, if there's only one common implementation and another comes along and does it better then that would make it NOT a language design issue.

So the question is whether these template issues are found in every implementation (language design issue) or only some (implementation issue).

Exactly, and back then we had MSVC and Borland's error messages to compare to gcc: it was pretty clear where the fault lay, even before clang came along.

I actually like c++, but I can't deny the syntax is incredibly ugly. for example, here's a declaration of a vector of pairs of strings suitable for a header file:

  std::vector<std::pair<std::string, std::string>> vec;

anything involving nested namespaces and template parameters gets out of control really fast. the textual inclusion paradigm means I must declare the vector this way unless I want to inject everything from std:: into any source file that includes the header.

I'm not sure what GP means about debugging. in my experience it's just like any other language if you have symbols and minimal optimizations. it can be kinda weird with optimizations, but that's to be expected. if the compiler can optimize away entire blocks of code, I don't think a debugger can abstract over that.

You can alias that type into a simpler name and keep using that instead of bringing components into the current namespace (or the global one). I haven't done C++ in some years but this was definitely a part of C++11.

in practice I would probably do something more like this:

  typedef std::pair<std::string, std::string> TStringPair;
  std::vector<TStringPair> vec;

or maybe:

  typedef std::vector<std::pair<std::string, std::string>> TStringPairVec;
  TStringPairVec vec;

this improves readability a bit, but is even more verbose at the declaration site if I'm not reusing the typedefs elsewhere. in an ideal world, I'd like something analogous to #undef for `using namespace` (or better yet, have this be the default at the end of a header file). this is only scratching the surface of the gotchas that come from textual inclusion.

Reply on news.ycombinator.com