Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to design a replacement for C++

apenwarr.ca

Post reply on HN
Print view View original

11–20 of 75 posts

Re: How to design a replacement for C++

#11

Post by apenwarr »

tmsh wrote: post #3

I like the article a lot (i.e., the suggestions for a newer alternative). But C + Python is much tricker than you might think (because of the GIL mainly) for any non-trivial, high-performance desktop or mobile app. Because any non-trivial, high-performance app is going to involve queuing and you just can't do that cheaply in CPython (it's not just the GIL, it's that the interpreter is more or less a singleton -- Stac…

I would have called it bottom heavy :) In python+C, every time something is too slow, all you have to do is push more stuff down into the C layer. You have control of the continuum between 100% optimized (100% C) and 100% clean and readable (100% python).

I don't know any other programming environment that can claim that without adding tons of complication (the C/python interface layer is the simplest I've ever seen, except maybe for c/tcl).

Re: How to design a replacement for C++

#12

Post by wvenable »

alextgordon wrote: post #7

2. Do not remove the cpp preprocessor. 7. One-time declaration/definition of functions. Aren't these in conflict? A C-style preprocessor is crippled without the header-file model. You'd do better to replace it with some other kind of metaprogramming.

If you've got one-time declaration/definition of functions, that's just one less thing you need the CPP preprocessor for. There would be no conflict, it would just end up being used for macros only.

I think you might be right though, I'd loose the cpp preprocessor but add built-in hygienic macros and constants to make up for the loss.

Re: How to design a replacement for C++

#13

Post by apenwarr »

hazzen wrote: post #6

An immediate issue with the article: the author takes issue with the liberal attitude taken by C++ in adding features and then proceeds to state: Maybe you like [lambdas], maybe you don't, maybe you think they're God's gift to programming and any language without them is an infidel. But adding them would be harmless, anyway. Well I agree on this point, it seems like a poor argument. You can't just declare a feature h…

If your language isn't completely terrible, then you can choose to use a named function anywhere an anonymous function will do. The libraries can never force you to not give your functions a name or not put them in a global context. That's why it's a harmless feature.

Templates might have been harmless if there was a way to do basic obvious stuff (callback functions, strings) without using them.

Re: How to design a replacement for C++

#14

Post by d0m »

"(Talking about C++ macro) [...] Well fuck you. If you take it out, I can't #include stdio.h, and I can't implement awesome assert-like macros. End of discussion."

This statement is simply wrong, and saying "End of discussion" is useless, if not plain stupid.

It's like saying: 1+1 = 3, End of discussion.

Re: How to design a replacement for C++

#15

Post by apenwarr »

d0m wrote: post #14

"(Talking about C++ macro) [...] Well fuck you. If you take it out, I can't #include stdio.h, and I can't implement awesome assert-like macros. End of discussion." This statement is simply wrong, and saying "End of discussion" is useless, if not plain stupid. It's like saying: 1+1 = 3, End of discussion.

I honestly can't begin to contemplate how you expect stdio.h to work (without writing extra wrappers) if you don't support macros and a preprocessor.

Some of the "functions" in there are macros.

Re: How to design a replacement for C++

#17

Post by wvenable »

apenwarr wrote: post #10
wvenable wrote: post #9

Earlier quoted context omitted.

The problem with C++ isn't so much that it's compatible with C or that you shouldn't pay for any features that you shouldn't use -- it's that they used the same dumb linker as C and so most advanced features are grossly limited and ended up as a twisty maze of text manipulation and includes.

That's no longer true; the linker has been massively extended to support templates at this point. (Otherwise every file that instantiated a particular template would result in all the code for that template being duplicated in the final executable. This actually used to happen in older C++ compilers.)

I don't consider that massively extended -- that's a optimization but it's not really a fundamental change in the way the linker works.

Re: How to design a replacement for C++

#18

Post by tmsh »

apenwarr wrote: post #11
tmsh wrote: post #3

I like the article a lot (i.e., the suggestions for a newer alternative). But C + Python is much tricker than you might think (because of the GIL mainly) for any non-trivial, high-performance desktop or mobile app. Because any non-trivial, high-performance app is going to involve queuing and you just can't do that cheaply in CPython (it's not just the GIL, it's that the interpreter is more or less a singleton -- Stac…

I would have called it bottom heavy :) In python+C, every time something is too slow, all you have to do is push more stuff down into the C layer. You have control of the continuum between 100% optimized (100% C) and 100% clean and readable (100% python). I don't know any other programming environment that can claim that without adding tons of complication (the C/python interface layer is the simplest I've ever seen,…

Right, but the problem is that the root node is always going to be Python, and any code that uses Python is going to have to go through the root node (hence all Python code is really part of the root subtree). This becomes problematic if you have more than one queue that you're watching (e.g., input, network, graphics output, etc.).

Were it possible to have Python code be in some non-root node, it'd be great (e.g., for parsing text, or doing something algorithmic). As it is, when everything has to be fed through the interpreter, the design becomes top-heavy from a performance standpoint because the slow stuff is on top. And any time you want to optimize something but then use some Python, you're stuck (it becomes part of the root subtree again).

At least that was my experience. But Python does encourage interesting alternatives for performance (with generators, etc.). And if you're already mostly doing Python anyway (I'd say the threshold has to be 70%), then it seems to make sense (v. the opportunity cost of switching contexts between languages -- if you are spending more than 30% in C, I find it difficult).

But it's a really interesting issue. C, C++, and Obj-C all take a much longer time to develop up front. But if you refactor into libraries, maybe not in the long-run...

Re: How to design a replacement for C++

#19

Post by mathias_10gen »

bhiggins wrote: post #5

I figure closures would be hard to do in a programmer-friendly way without GC.

C++0x managed to add closures without adding GC. The only issue is that if you want to the closure to outlive the current stack frame you have to capture by value ([=] rather than [&]) or use a shared_ptr (which is then copied by value).
Post reply on HN