5 ms·

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 sti

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.

quinnftw 10y ago
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.
- Rusky 10y ago
  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.
  - asveikau 10y ago
    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.
    - Rusky 10y ago
      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).
    - maccard 10y ago
      How do you handle mode as a swap for something like a socket, or a file handle in that case?
      - MaulingMonkey 10y ago
        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.
dasloop 10y ago
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.
- lossolo 10y ago
  Like D?
  - dasloop 10y ago
    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".
  - deleted 10y ago
    [deleted]
- NotSammyHagar 10y ago
  That is a great idea and great metaphor to describe your new language.
- mabynogy 10y ago
  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.
- smitherfield 10y ago
  Cython? http://cython.org http://cython.org Yes, it supports C++ (even templates!): http://docs.cython.org/en/latest/src/userguide/wrapping_CPlusPlus.html http://docs.cython.org/en/latest/src/userguide/wrapping_CPlu...
eru 10y ago
Have you had a look at D, yet?

quinnftw 10y ago

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.

Rusky 10y ago
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.
- asveikau 10y ago
  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.
  - Rusky 10y ago
    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).
  - maccard 10y ago
    How do you handle mode as a swap for something like a socket, or a file handle in that case?
    - MaulingMonkey 10y ago
      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.

dasloop 10y ago

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.

lossolo 10y ago
Like D?
- dasloop 10y ago
  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".
- deleted 10y ago
  [deleted]
NotSammyHagar 10y ago
That is a great idea and great metaphor to describe your new language.
mabynogy 10y ago
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.
smitherfield 10y ago
Cython? http://cython.org http://cython.org Yes, it supports C++ (even templates!): http://docs.cython.org/en/latest/src/userguide/wrapping_CPlusPlus.html http://docs.cython.org/en/latest/src/userguide/wrapping_CPlu...

eru 10y ago

Have you had a look at D, yet?