Hacker News Reader

Comment by NotSammyHagar | Hacker News Reader

I learned some things from reading that article. I hadn't heard about those other schemes to do rtti. I just want it to be as easy as objective c was, and I still like those smalltalk like api calls that were in that.

But the article reminds me why I still feel frustrated that my programming work is divided between java and c++. There are so many things that are easy in java and hugely painful in c++, and c++ slowly adds those ideas yet it makes the language more painful to use over time. I basically want to throw c++ away and replace it with something that is more regular and doesn't expose so many complexities to the end programmer like the endless nuances of memory allocation, moving, &&, r values etc. But there's no hope of that. For the rest of my life every year or two there will be additions to c++ that I will have learn about and use and gradually discover their own warts, yet java will still keep cruising along.

View on HN

What I want is a language over C++, as typescript is over JavaScript, that keeps compatibility with C and C++ code (Qt, boost...) and provides a clear syntax and some advanced features (as reflection) even paying a price for it. This is it, no more zero cost abstraction.

Like D?

No, D is a separate language. A bit too much. Ideally you will be able to move between a version of the language or another at Class level to alllow a incremental migration of the code that must be "modernized".

That is a great idea and great metaphor to describe your new language.

I'm doing that but it's more a CoffeScript than a Typescript (no semicolons and no commas).

An example:

    fn add(x1 x2)
    {
     return <x1+x2>
    }

    fn <main>(count:int arguments:<const char** const>):int
    {
     (<printf> "%d\n" (add 2 3))

     return 0
    }

Is converted to:

    auto add(const auto x1,const auto x2)
    {
     return x1+x2;
    }

    int main(const int count, const char** const arguments)
    {
     printf("%d\n",add(2,3));

     return 0;
    }

Everything inside the <angle brackets> is left as is in the C++ output.

I use S-expressions for function calls.

Cython? http://cython.org

Yes, it supports C++ (even templates!): http://docs.cython.org/en/latest/src/userguide/wrapping_CPlu...

The closest thing I can think of would be the subset of C++ used in Stepanov + McJones' Elements of Programming, with the addition C++11 stuff like lambdas and std::function, plus (hopefully) C++20 stuff like compile-time reflection, concepts and ranges.

Cruising along with frequent pit stops for garbage collection.

All jokes aside I agree with you to some extent: C++ can be frustrating to work with, and there are a lot of quirks that make it really easy to blow your foot off.

These quirks are not without benefit though. Being able to control how memory is allocated is hugely important in performance sensitive applications where pointer chasing is not tolerable. The same can be said about r values/move semantics.

You can get those benefits without the complexity of C++ if you're willing to break with the past (and as for the newer features, it's possible C++ could have implemented them more straightforwardly, though maybe they were already designed into a corner).

For example, look at C++'s concept of move semantics. The language still runs destructors regardless of whether a value has been moved. This means every movable class has to have a valid "empty" state the destructor can check to avoid double frees. That means you need move constructors which can run arbitrary code. And that means generic code that does moves has to care about exception safety.

Instead, the language could statically avoid running the destructors of moved values. No more rvalue zoo needed to trigger a move, no more mandatory "empty" states because the destructor can assume a valid object, no more move constructors because they all reduce to memcpy, and thus no more exception safety problems and an easier job for the optimizer.

If you implement a move as a swap (as in the examples I saw when I first heard of move constructors back when it was called c++0x) you don't need an empty state.

Not being able to keep track of what cases call a destructor and which ones do not sounds like a much more huge problem than the one you are talking about. Doesn't seem too hard to avoid the temptation throw in a move constructor.

You can't always swap. For example, you may want to use a movable but non-copyable type to keep un-aliased access to a single resource (see linear/affine types) and the compiler treating the move source as dead is useful there. Or maybe you don't want to allocate anything for the move target because the resource you're managing is expensive.

Keeping track of when a destructor gets called is not a huge problem at all. From the user perspective it's airtight, proper uninitialized value analysis in the compiler make it impossible to screw up. From the implementation perspective all you need is the occasional flag on the stack (whose value is already calculated) for situations like `if ... { use_by_move(obj) }`, and a rule against moving things out of fields that you're otherwise not responsible for destructing (you can still swap there).

How do you handle mode as a swap for something like a socket, or a file handle in that case?

These typically have null-like states in C++. If we were making a std::ifstream clone without templates inheritence, etc. we might write...

  class ifstream {
    FILE* f;
    ifstream(const ifstream&) = delete;
    ifstream& operator=(const ifstream&) = delete;
  public:
    ifstream(): f() {}
    explicit ifstream(const char* path): f(fopen(path, "rb")) {}
    ~ifstream() { if (f) fclose(f); }
    
    ifstream(ifstream&& original): f() {
      std::swap(f, original.f);
    }
    
    ifstream& operator=(ifstream&& original) {
      std::swap(f, original.f);
      return *this;
    }
    
    // ...
  };

This is very similar to the common pattern of implementing vanilla assignment in terms of copy construction and a swap.

EDIT: Added deleted copy ctor/assignment ops because I'm not a savage.

In the move constructor of the object wrapping an open file, swap the integer descriptors.

> If you implement a move as a swap (as in the examples I saw when I first heard of move constructors back when it was called c++0x) you don't need an empty state.

You do to e.g. default construct the temporary you'll be swapping with in the first place. Problematic if you're trying to construct e.g. a reference-like type with no null state.

Have you had a look at D, yet?

Reply on news.ycombinator.com