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

71–75 of 75 posts

Re: How to design a replacement for C++

#72

Post by supersillyus »

Nitramp wrote: post #51
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 cas…

I prefer return values over exceptions in languages that make it safe and easy.

Haskell does a pretty good job, I think. With Maybe or Either, you have to check it to extract your value, but if you are doing a lot of things that will result in/use the results of Maybe/Either, you can just operate in a Monad that makes them the default.

Similarly, languages with multiple return values make you explicitly ignore the return value.

Exceptions have their benefits, but I have a personal preference for return values because they make it explicit in the interface. Also, I find that it makes more sense to handle various success and failure scenarios in the same bit of code instead of writing a best-case flow and assuming that exceptions will be thrown and errors will be dealt with somehow.

Exceptions are great if you can't continue due to programmer error, but most cases where people use exceptions are just expected execution paths that (in my view) make no sense to handle via non-local control flow.

Re: How to design a replacement for C++

#73

Post by shasta »

froydnj wrote: post #71
shasta wrote: post #61

Earlier quoted context omitted.

No, that only lets you jump out - not e.g. jump between several suspended computations.

Sure you can. This is how user-level threading packages work if you don't have kernel support.

Interesting, it seems many C implementations do support this. It's not standard C, though.

Re: How to design a replacement for C++

#74

Post by JoachimSchipper »

nuxi wrote: post #67
JoachimSchipper wrote: post #52

Earlier quoted context omitted.

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.)

Ah okay, I understand what you meant now. One thing however - if it is a macro, couldn't it just be: #define getc fgetc_or_similar At least C89/90 only mentions that if it is a macro, it may evaluate arguments more than once (but then it may not, as in the above case).

Yes and no. Yes, that is a valid #define; but the following program must work:

    #include 
    #undef getc
    int main(void) {
        getc(stdin);
        return 0;
    }
so it cannot be implemented as only a macro.
Post reply on HN