Live data from Hacker News

C++20, How Hard Could It Be

docs.google.com

141–150 of 444 posts

Re: C++20, How Hard Could It Be

#141

When a new C++ feature is proposed does the proposer have to provide a reference implementation? How can features be missing from the major compilers?

Same reason caniuse.com exists for browsers. This just comes from the territory of a language/runtime/platform that doesn't have a monopoly implementation.

Re: C++20, How Hard Could It Be

#142

The Boeing 377 Stratocruiser was the epitome of piston technology: 28-cylinder radial engine that needed more maintenance than flying time. It vibrated so hard that it separated from the wing. https://en.wikipedia.org/wiki/Boeing_377_Stratocruiser

Maybe you're being hyperbolic, but the catastrophic engine separations in the Stratocruiser were due to propeller failures.

http://enginehistory.org/Propellers/B377Props.pdf

Re: C++20, How Hard Could It Be

#143
post #38
post #22

Earlier quoted context omitted.

Which of these things is Rust immune to? How stable is it over a 10, 15, 20 year life? How old can the code be that Rust compiler still compiles and links successfully and bug-free?

Rust does well on this front. There's a new release every 6 weeks, and majority of users jump on it straight away (to complete shock of everyone not used to it). Rust has editions which keep old code working without any changes, even if you mix it with new code, even if you do it with macros. It has rustfix that automatically migrates majority of the old code. Rust has a standard project layout, standard test runner,…

How on earth can you predict that rust will be stable in 20 years?

Re: C++20, How Hard Could It Be

#144
post #125

Earlier quoted context omitted.

One day in the far away future the standard C++ hello world will use 'import std;' and 'std::print' and it will be glorious.

Already available in C++23.

The future tense seems better here. This will (almost certainly) be available in C++ 23.

In the context of Chromium, this slide deck, that means in about 2026.

So if you're starting a three year degree next week, and you already know Google will hire you for the Chromium team straight after because you're the perfect person for that, you won't be writing std::print() calls in that codebase yet 'cos that's too early.

Re: C++20, How Hard Could It Be

#145

Earlier quoted context omitted.

One day in the far away future the standard C++ hello world will use 'import std;' and 'std::print' and it will be glorious.

When I was going to university the computer science department's primary system had two compilers available, GCC 2.96[0] and TenDRA. GCC was generally more popular but it didn't have std::string and any code that threw an exception would crash, so adventurous students would use TenDRA for development. One of the stranger behaviors of TenDRA was that it put all standard library symbols, including the C headers , into…

2.96 exists, at least in the RedHat world.

    $ rpm -qi gcc
    Name        : gcc                          Relocations: (not relocateable)
    Version     : 2.96                              Vendor: Red Hat, Inc.
    Release     : 110                           Build Date: Fri 12 Apr 2002 10:30:47 PM UTC
    Install date: Thu 20 Jan 2011 03:34:36 AM UTC      Build Host: daffy.perf.redhat.com
    Group       : Development/Languages         Source RPM: gcc-2.96-110.src.rpm
    Size        : 8389509                          License: GPL
    Packager    : Red Hat, Inc. 
    URL         : http://gcc.gnu.org
    Summary     : The GNU cc and gcc C compilers.
    Description :
    The gcc package includes the cc and gcc GNU compilers for compiling C
    code.
    $ cat /etc/redhat-release
    Red Hat Linux release 7.3 (Valhalla)

Re: C++20, How Hard Could It Be

#146
post #53

Many are of the listed items are merely being deprecated. These shouldn’t really qualify as breaking changes. In fact, the ability to migrate away incrementally is precisely the point of deprecating instead of removing a feature. What surprises me is that a lot of the deprecated functionality seems really recent — C++14 or newer. Compatibility is C++’s big thing, that’s historically why it kept almost all of C as a s…

The real solution, which decades from now will be the eventual common-place, but no one dares to imaging the possibility today is that when languages deprecate a feature, the compilers deliver code-mods that migrate your code-base perfectly.

But people are afraid of going that route because of the bad press around Python 2 / 3. We need a new generation of developers that don't remember that.

Today, there's already static-code analysis tools that automatically migrate entire code-bases to use new language constructs. The technology is there. It's the people who lack imagination to make it happen.

Once it becomes commonplace, a large % of developers will care very little if some obscure feature of C is dropped. They'll just enjoy having a more streamlined language with all the legacy crap gone.

Re: C++20, How Hard Could It Be

#148

Quoted post unavailable.

Sometimes you need to avoid GC or have direct control of your threading model and you need a language that is more expressive than C. Your only two options here with broad adoption are C++ and Rust, both of which are very complicated languages.

Other languages like Zig, Ocaml, and Erlang have legitimate claims to similar performance to C++/Rust with expressiveness, but they do not have the same adoption.

Re: C++20, How Hard Could It Be

#149
Say I have a new project to start today. I need pick a language to use:

  1. a well-tested language
  2. can not use garbage collector due to *performance* requirement
  3. easy to hire if project expands.
  4. ready to use tooling support
  5. widely available tutorials and info on the web.
  6. language is itself alive and updated
  7. project can be scaled over time.
what options do I have? I have to pick up c++ in this case. it falls to the saying "a language is either blamed, or nobody uses it".

Javascript for the web, Python for machine learning, C for low level and system coding, Go for some native cloud and DevOps, Java for enterprise or Android, C# if you're a windows developer, Swift if you are doing Apple, we actually don't have a lot of choices when you need deliver things faster.

I played with nim, ziglang and Rust, but it's hard to use them for real product developments at this point for me.

Post reply on HN