Show HN: Introducting C+
github.com
github.com
I am confused by the implication of this code
var prices = new(Table, String, Int);
put(prices, $(String, "Apple"), $(Int, 12));
Is this all done with header files and the preprocessor? It looks like that is the case - if so, I am impressed at the dances you got it to do ;) Also, have you read http://www.amazon.com/Interfaces-Implementations-Techniques-... which does some "Object Orientation" in C tricks?
Although not perfect this was probably the best way I could have designed such structures. There is some info in the header files as to how to use them.
The call and call_with are intriguing though.
Please change the name to something searchable and easily remembered before it's too late.
Point about name noted, open to suggestions :)
What are the performance implications of these features? How do they compare with similar C++ functionality, especially things they do at compile-time? Can I have a pretty graph?
What trade-offs were made? Can they be improved? Are certain aspects or semantics optional? Do you pay the price of linking this library simply by linking it, or do you "only pay for what you use"?
Is it safe? Type-safe? If not, what's required to make them safe?
If you don't answer these questions, somebody like me will who's ignorant of how this is supposed to work will produce their own data. That's not good, you understand how it's supposed to be used.
The performance implications are much like vtable lookup in C++. Generic functions are essentially overloaded and their function pointer looked up at runtime. The main tradeoff over C++ is that rich types don't play well when allocated on the stack as destructors cannot be automatically called on frame exit.
The added semantics are not optional, but you can still program in standard C while avoiding the defined keywords and functions and the interaction should not be troublesome at all. There is no price for linking the library.
It is not type-safe and employs runtime type checking where inserted by the user - but also this allows for duck typing and more generic code so perhaps it is not a bad thing all round.
I hope that helps. Any more questions feel free to drop me an e-mail.
Short and easily searchable.
Not quite; Objective-C is a superset of C. You can write pure C and compile it as Objective-C all day long.
This is an important point because people think their C knowledge doesn't translate to Objective-C, mainly because people say things like "it's entirely different". At its core, it really isn't -- the superset syntax becomes straight C underneath.
The parser and compiler should only need to examine each source file once.
ps. Of course that does not invalidate your point, which I fully agree with. It's just on the wrong thread.
Wow. That's my favorite part.
The use of the $ function is totally not portable though, which is a bit of a pity.
Doesn't compile on a mac either; bunch of warning about pointer size that are being treated as errors by -Werror
Still, nice work~!
You can hop around this easily using the ST monad. It's less elegant than usual Haskell and often less elegant than languages where mutation is 'native', but it does its job.
It's interesting anyways, I love the simplicity of C but agree that it's a bit "outdated", and I dislike the radical change of Go.
Funny, but the common criticism in the days when Go was first released was that it was not radical enough.