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

51–60 of 75 posts

Re: How to design a replacement for C++

#51

Post by Nitramp »

phaedrus wrote: post #46

1. Instead of the ability to directly call and be called by C/C++, include a really kick-ass Foreign Function Interface that can JIT the hookups and wrappers. And more important than call compatibility IMO is C++ object ABI compatibility. (I realize there is no universal C++ ABI; just pick one and be compatible with it.) If you can declare a struct or class in the language and make its layout match a C or C++ class/s…

  I think exceptions are an important language advance, but 
  I can't dispute that they can cause a mess of problems 
  when it comes to cross-language (or cross-thread) 
  boundaries.
Exceptions are not completely problem-free, but there is no alternative. If you don't have exceptions, every single line of code:

  doSomething();
Becomes:

  int result = doSomething();
  if (result != OK) return result;
... and that is the simple case, without memory management, an actual result to return, unfortunate interactions with your other control flow statements, and so on. And you still end up with your application helpfully saying "ERR: -1923876".

This is simply doesn't work. And few people programming C/C++ appear do it correctly; I'd imagine that many security flaws come from improperly proceeding code that should have checked a return code.

Re: How to design a replacement for C++

#52

Post by JoachimSchipper »

nuxi wrote: post #45
_delirium wrote: post #40

Earlier quoted context omitted.

Most C libraries already implement those as both functions and macros. The macro definition usually shadows the function definition, but you can access the function version if you want, e.g. in glibc, getc() will call the macro, while (getc)() will call the function. The macro is just a wrapper for a function anyway in glibc (the internal _IO_getc), so there's no real reason to retain it except for historical reasons…

> but you can access the function version if you want, e.g. in glibc, getc() will call the macro, while (getc)() will call the function. Are you sure about this?

Yes (the macro must be define as

     #define getc(stream) ...
of course, but that's the only legal definition anyway).

("Free-standing implementations" like kernels have a lot of freedom to muck with the standard library. But that's not really relevant.)

Re: How to design a replacement for C++

#53

Post by froydnj »

shasta wrote: post #4

1. Hey, I more or less agree with this guy 2. Hahahahahaha 3. Aside from the fact that his wording is backwards from his meaning, I agree that it should be possible to write code that doesn't ever garbage collect. 4. Ok 5. Does this guy know the function of a linker? 6. Again, he asserts something you are to avoid, when really he should be emphasizing what you need to support: code without runtime checks. 7. Wrong. T…

> C hardcodes assumptions about the stack that prevent certain low level optimizations.

Would you please expand on this? I can't think of any assumptions C makes about the stack that C++ wouldn't make; neither can I think of low-level optimizations that said assumptions prohibit. I'm curious about what you have in mind.

Re: How to design a replacement for C++

#54

Post by JoachimSchipper »

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.

It's not impossible to imagine a language like C, but with the additional property that any (non-static) function defined in any input file can be used (without a prototype/header) in any other input file. (I.e. all 'undefined function' errors are replaced by a lookup once everything has been compiled.)

Of course, the above model will most likely increase (re-)compilation times.

Re: How to design a replacement for C++

#55

Post by andymorris »

Is there any non-legacy reason to have macros in C++? I've been coding C++ now for over 3 years, and as soon as I learned all the features (especially templates), I have never needed them again. Indeed, I despise them, because they break debuggers and can conceal bugs easily.

I'd like to see an example, if anyone has one. But for me, the template system is the best thing about C++ - they are much closer in functionality to Lisp macros than preprocessor macros are!!

Re: How to design a replacement for C++

#56

Post by JoachimSchipper »

phaedrus wrote: post #46

1. Instead of the ability to directly call and be called by C/C++, include a really kick-ass Foreign Function Interface that can JIT the hookups and wrappers. And more important than call compatibility IMO is C++ object ABI compatibility. (I realize there is no universal C++ ABI; just pick one and be compatible with it.) If you can declare a struct or class in the language and make its layout match a C or C++ class/s…

1. Yes, you can JIT a callback, but without a GC that just leaves you with lots of callbacks scattered about your memory. I.e. qsort() calls lots of times, then returns and never refers to the object again; libevent functions may cause any number of calls (including zero, if the event is deleted); if you have a function pointer void (put)(int key, void value, void (cb)(void cb_arg), void *cb_arg) to store data, it may either call back before returning (e.g. data is stored in memory) or after (e.g. data is stored on a slow disk), or even call back multiple times (to provide progress reports). I see no way to handle this in a sane fashion.

4. If you are going to need threads by default (e.g. for your GC thread) you are breaking lots of UNIX, notably fork(), and require far too much infrastructure for some kernel/embedded programming. Yes, a good concurrency story is needed, but your program should be able to run without threads.

Re: How to design a replacement for C++

#57

Post by JoachimSchipper »

phaedrus wrote: post #50

Some comments on your proposed additions (my other comments were about the proposed reductions): - I don't think .NET-style generics can be implemented in a statically typed language that doesn't have a common base class (e.g. everything derives from class Object). This is an oversimplification to say this but at some level generics are implemented as syntatic sugar for typecasts between Object and the type parameter…

To the best of my knowledge, current C compilers typically convert C programs (which obviously don't have a concept of a reference) into SSA form as one of the first steps after parsing. It's, to me, not obvious that this couldn't be done with C++ references either. (Yes, this would make writing a decent C++ compiler harder; but it's already so monstrously hard that this optimization, which is already in all major compilers anyway, would be a significant additional burden.)

Re: How to design a replacement for C++

#58

Post by shasta »

froydnj wrote: post #53
shasta wrote: post #4

1. Hey, I more or less agree with this guy 2. Hahahahahaha 3. Aside from the fact that his wording is backwards from his meaning, I agree that it should be possible to write code that doesn't ever garbage collect. 4. Ok 5. Does this guy know the function of a linker? 6. Again, he asserts something you are to avoid, when really he should be emphasizing what you need to support: code without runtime checks. 7. Wrong. T…

> C hardcodes assumptions about the stack that prevent certain low level optimizations. Would you please expand on this? I can't think of any assumptions C makes about the stack that C++ wouldn't make; neither can I think of low-level optimizations that said assumptions prohibit. I'm curious about what you have in mind.

I just meant that the role of the stack is hardcoded. In most assemblys you can write to the stack pointer and presto, you're working with a new stack. This is a capability of assembly that C doesn't expose.

Re: How to design a replacement for C++

#59

Post by stcredzero »

shasta wrote: post #58
froydnj wrote: post #53

Earlier quoted context omitted.

> C hardcodes assumptions about the stack that prevent certain low level optimizations. Would you please expand on this? I can't think of any assumptions C makes about the stack that C++ wouldn't make; neither can I think of low-level optimizations that said assumptions prohibit. I'm curious about what you have in mind.

I just meant that the role of the stack is hardcoded. In most assemblys you can write to the stack pointer and presto, you're working with a new stack. This is a capability of assembly that C doesn't expose.

longjmp()?

Re: How to design a replacement for C++

#60

Post by sprout »

ToastOpt wrote: post #30
shasta wrote: post #23

Earlier quoted context omitted.

import_c You can import C headers without your language being a superset of C.

Yes. Many a time I have wished to import a library's symbols without importing its macros. Or better yet, import its symbols under alternate names. "namespace x = import " anyone?

I'm really looking forward to maintaining your code.
Post reply on HN