Live data from Hacker News

Towards a more powerful and simpler C++ with Herb Sutter

blog.jetbrains.com

61–63 of 63 posts

Re: Towards a more powerful and simpler C++ with Herb Sutter

#61

Earlier quoted context omitted.

I think the general consensus of the C++ community is that we need Concepts or something like it. I don't think anyone is really claiming no other language offers something similar. I'd love to learn more Haskell but for my primary domain (games and VR) it's not a terribly practical option. This gets back to my original point - yes Concepts will make C++ more complex (in the sense of adding features) but I think it w…

> I'd love to learn more Haskell but for my primary domain (games and VR) it's not a terribly practical option. Oh, sure, Haskell has lots of defects. (Chiefly among those, being lazy.) I only said that it has something that's essentially concepts, except it has been designed, implemented and used since ages ago. > This seems to be more an issue of encapsulation than support for ADTs. The whole point to ADTs is that…

> I only said that it has something that's essentially concepts, except it has been designed, implemented and used since ages ago.

I'm not sure why this is relevant to the topic at hand though, other than historical interest. What's relevant is that something like concepts are a useful thing for a language to have and C++ will be a better / more usable language with them, even if it means adding 'complexity'.

> The whole point to ADTs is that clients don't get to manipulate the internal representation! What exactly is that, if not encapsulation?

You said "The concrete representation of these three types must be hidden from the user" and mentioned the pimpl pattern which led me to think you were talking about ABI issues. In C++ generally private members are not accessible but they are visible (in headers) and affect object size and layout. That can be a problem for build times and for versioning / binary compatibility but it also allows for private functions to be inlined and avoids pointer indirections and simplifies certain other optimizations (devirtualization for example).

C++ does not currently have a language level concept of modules (and I'm not sure the modules proposal working its way through standardization addresses your issue here) or anything like the C# internal access level. There are patterns to structure your code to enable implementation hiding for collaborating classes in a 'module' but they don't tend to be very widely used due to lack of first class language support. In my own experience I haven't found this to be a huge issue but maybe I just don't know what I'm missing.

Re: Towards a more powerful and simpler C++ with Herb Sutter

#62
post #40

Earlier quoted context omitted.

That is not a step toward simpler code. Under that proposal, people looking at your code will have to look up definitions of basic things that ought to be keywords---like "interface"---in order to reason about the code.

> Under that proposal, people looking at your code will have to look up definitions of basic things that ought to be keywords---like "interface"---in order to reason about the code. That's a good thing: now you can refer to 20 lines of code instead of 15 pages of standardese to understand what happens.

I can learn the 15 pages of standardese and it'll apply uniformly to every program. The 20 lines will contain some subtle surprise at the worst possible time.

Re: Towards a more powerful and simpler C++ with Herb Sutter

#63
post #62

Earlier quoted context omitted.

> Under that proposal, people looking at your code will have to look up definitions of basic things that ought to be keywords---like "interface"---in order to reason about the code. That's a good thing: now you can refer to 20 lines of code instead of 15 pages of standardese to understand what happens.

I can learn the 15 pages of standardese and it'll apply uniformly to every program. The 20 lines will contain some subtle surprise at the worst possible time.

> I can learn the 15 pages of standardese and it'll apply uniformly to every program.

That's assuming the compilers implementors had the same interpretation than you. With code, there is much less room for interpretation.

Post reply on HN