Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C++20, How Hard Could It Be

docs.google.com

Post reply on HN
Print view View original

331–340 of 444 posts

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

#331

Post by ncmncm »

loxias wrote: post #227
synergy20 wrote: post #220

Earlier quoted context omitted.

or use a subset of c++ that does everything c does, plus OOP, RAII and smart pointers for free, and it compiles and links with c code smoothly as well. the only price to pay is that libstdc++ runtime must be present, which is just a few MBs that can even fit for small embedded boards.

I've written firmware, systems software, drivers and plenty else this way. Just because the language gives you rope doesn't mean you _have_ to use all of it. I enjoy how terse and straightforward even good ol' structured non-object oriented code can be.

"Object-oriented" is a niche technique.

Any big-enough system will naturally have some OO-ish parts, just because it has some of almost everything. Most small programs will have none.

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

#332

Post by ncmncm »

alar44 wrote: post #224
synergy20 wrote: post #220

Earlier quoted context omitted.

or use a subset of c++ that does everything c does, plus OOP, RAII and smart pointers for free, and it compiles and links with c code smoothly as well. the only price to pay is that libstdc++ runtime must be present, which is just a few MBs that can even fit for small embedded boards.

This is what I do. Write C in C++. You don't have to use all the fancy new shit. I'll never understand why people get so upset about it.

Then you are writing bad C++ code.

The new features are added specifically because they enable writing better programs. Avoiding them means you are choosing not to write better programs. It is allowed, but not a thing to brag about.

That does not mean every program has to use every feature. But when there is a choice between the new way and the old way to do something, the new way is very probably better.

Passing a reference, where you can, is better than passing a pointer. Passing a lambda is better than passing a function pointer. New for-loops are better than old for-loops. A unique_ptr is a better member than a naked pointer. A compiler-generated destructor is better than a hand-coded one.

And so on.

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

#333

Post by ModernMech »

jcelerier wrote: post #283
ModernMech wrote: post #229

Earlier quoted context omitted.

I think if write-only code were the norm, then APL would be more popular.

But there are APL, k, j and other array lang programs. You can't do as if those don't exist when talking about programming as a whole. Perl used to be pretty popular too.

I didn't say array programming doesn't exist, I said it's not popular. How many people actually use those languages compared to e.g. Python, where readability is one of its main features.

> Perl used to be pretty popular too

And now it’s a meme due to how illegible it is.

I’ll put it this way, there’s a reason Brainfuck is a joke lang instead of something people seriously use.

Also, reading and writing are not orthogonal skills. One has to read to be able to write. I read my programs constantly as I'm writing them.

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

#334

Post by me_again »

evouga wrote: post #307
tialaramex wrote: post #152

Earlier quoted context omitted.

Mostly deprecations mean something was deemed to be a bad idea, which means it's at the very least worth taking a moment to evaluate whether somehow they were a good idea when you did them. For example should I have a method whose parameters are volatile? Well, why did I do that? It didn't do anything in C++ 17 and it still doesn't do anything in C++ 20 but now it's deprecated. Programs are written first and foremost…

The volatile parameters deprecation is one of the stranger decisions, though, since there are plenty of constructions that don’t do anything but are still allowed by the language. I see this as a matter of style that might be useful to warn about, but shouldn’t be policed as an error by the compiler.

Deprecated features are compiler warnings, not compiler errors, unless you use -Werror or the like.

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

#335

Post by phoehne »

sudosysgen wrote: post #330
phoehne wrote: post #225

Earlier quoted context omitted.

The way I look at it is we're in a transitional period. A language like Go or Rust can replace some of the C++ lift, but we're not sure because they're not a large body of experience with those languages. I suspect, but can't say with any certainty, that we'll wind up in a world where the use case for C++ shrinks significantly. Rust and Go will eat into the share of new Greenfield systems that would have normally gon…

Rust can't easily bind to many modern, high performance C++ libraries because it lacks a fair amount of the semantics of C++.

I think that may be a red herring. We normally don't link to name mangled C++ libraries, anyway. Most libraries export their useful symbols in de-mangled format for linking to other languages. That way you can basically dlopen and look for the symbol. There are some libraries that are really only intended to be called from C++ and I don't expect anything other than C++ to use those libraries. I'm not sure if Ruby or Python (for example) can deal with mangled names. I think there are some tools that will generate wrappers to make them callable from things that don't understand mangled names, but if you want to make your stuff interoperable - make it C callable.

It isn't that hard to define something like MyType_t which is a pointer. Then some C code to allocate to wrap the MyType so the type is usable from any language.

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

#336

Post by dtolnay »

pclmulqdq wrote: post #242
pornel wrote: post #38

Earlier quoted context omitted.

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,…

> Rust has a standard project layout, standard test runner, and a central code repository, which enables testing language releases against nearly all publicly available code (see "crater run"). I'm not sure why this is treated as a selling point. It helps projects up to a point, but the minute you want to do something that doesn't fit the mold, it makes things a lot harder. All of these products are orthogonal to a l…

> the minute you want to do something that doesn't fit the mold, it makes things a lot harder

This is not my experience at all; it's been extremely helpful for doing things outside the mold:

In a work codebase that is millions of lines of first-party Rust code with thousands of third-party Rust dependencies from crates.io, we're building with Buck not Cargo because that is what the rest of the monorepo uses for C++ and other languages. It's fantastic for this that all the third-party projects describe their dependency graph in the same standard Cargo manifest format and follow a standard project layout, even though our builds do not use Cargo, because we can programmatically translate them to Buck targets.

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

#337

Post by synergy20 »

user432678 wrote: post #293
synergy20 wrote: post #222

Earlier quoted context omitted.

that's a good question, I have yet to find a good beginner friendly modern c++ education material, be it a book or some course, that can make c++ learning simpler, to the point and enough to start to work with the language before diverting into those deep concepts. Someone needs to write a c++ 101 book, followed by 201 and 301 for beginner, intermediate, and advanced users.

“C++ Crash Course” by Starch seems to be such a beginner’s book, can’t recommend it enough. Although, I was learning C++ mostly for hobby projects.

a good book indeed, hope it will have an updated version for c++20/23, which arguably is the most important release since c++11, new stuff such as ranges, std::span even concepts could be added now. I think this book is a bit tough for beginners though.

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

#338

Post by ncmncm »

fathrowaway12 wrote: post #313
the_af wrote: post #201

Earlier quoted context omitted.

Honest question: is it easy to find good C++ programmers these days?

Seems like there's plenty, but a lot of em' are already gainfully employed by Google, MSFT, FB and co.

The good ones mostly leave those shops after a few years. Beware of anybody who looks back on them with fondness.

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

#339

Post by p1esk »

f1shy wrote: post #309
p1esk wrote: post #295

Earlier quoted context omitted.

What kind of machine learning does your company do? It's probably something simple, because for anything complicated, like computer vision, speech recognition, any non-trivial NLP, and large scale recommender systems you do need neural networks.

Autonomous driving, including, for example, computer vision. No NLP or speech. About the "need" or neural networks, there is a lot of discussion going on. As you may know, the "black box" nature of NNs make them a little more difficult than other means, when you have to validate them for safety critical systems.

If you use CV for autonomous driving you use object detectors, and any modern object detector uses a neural network as its backbone.

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

#340

Post by compiler-guy »

echelon wrote: post #312
compiler-guy wrote: post #298

Earlier quoted context omitted.

This would likely result in worse problems. Things You Should Never Do, Part I https://www.joelonsoftware.com/2000/04/06/things-you-should-...

This has never been my experience, and Joel isn't an all-seeing oracle. In just one notable example, a company I was at had a team develop an important platform in Node.js when the rest of the company was hired for and familiar with Java/Ruby. This app ran our 3rd party API gateway and was a central part of how our company was attempting to grow. The Node.js team left wholesale to go found CockroachDB, which left nob…

No one said to let everyone have a free for all with a million different languages. Rewriting things creates its own set of bugs. Every time.
Post reply on HN