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

401–410 of 444 posts

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

#401

Post by kazinator »

ncmncm wrote: post #348
kazinator wrote: post #270

Why only an unhip, old geezer would write outdated drivel like: const int MAX_SIZE = 1024; const int HEADER_SIZE = 128; set_content_size(HEADER_SIZE - MAX_SIZE);

Probably less geezery to write set_content_size(MAX_SIZE-HEADER_SIZE); Sayin'.

Never mind the operand order; what do we gain by using constexpr instead of const?

In C++, const int x = 3 is already a constant. As of C++98 already, you can use x as a case label in a switch statement.

It cannot be any more constant.

Not cool any more?

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

#402

Post by ncmncm »

kazinator wrote: post #401
ncmncm wrote: post #348

Earlier quoted context omitted.

Probably less geezery to write set_content_size(MAX_SIZE-HEADER_SIZE); Sayin'.

Never mind the operand order; what do we gain by using constexpr instead of const? In C++, const int x = 3 is already a constant. As of C++98 already, you can use x as a case label in a switch statement. It cannot be any more constant. Not cool any more?

You just want to ensure they don't take up space in your struct body.

Otherwise, const is fine.

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

#403

Post by nickysielicki »

misnome wrote: post #51

Wait, so the words "concepts" and "requires" were newly made keywords, and this breaks code, but the words "yield" and "await" were determined too important and too common to standards members that they needed to be renamed to the horrifically ugly "co_await" and "co_yield"? Also, last time I actually tried to use C++20 none of the standard library implementations had std::format; has this changed now?

The east coast fintech folks are the reason we couldn’t have yield as a keyword. Too much of their code uses the variable name yield in the trading sense of the word, and so we’re stuck with this instead. This is what someone on the standards committee told me on the cpp slack a few years ago, at least.

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

#404

Post by nickysielicki »

layer8 wrote: post #247
misnome wrote: post #51

Wait, so the words "concepts" and "requires" were newly made keywords, and this breaks code, but the words "yield" and "await" were determined too important and too common to standards members that they needed to be renamed to the horrifically ugly "co_await" and "co_yield"? Also, last time I actually tried to use C++20 none of the standard library implementations had std::format; has this changed now?

`std::this_thread::yield` already existed at the time, and “yield” was presumed to also be a common identifier in financial and agricultural contexts. I’m nevertheless surprised that new noncontextual and previously-unreserved-identifier keywords were added at all. In earlier times, the approach would have been to use a reserved identifier like “_Yield” for the keyword, and to provide a standard opt-in header that wo…

Such a weak argument, you can fix this in your entire code base with a single call to sed. There is no reason to introduce a language feature with some weird prefix instead of changing existing code and having them prefix their variable names.

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

#405

Post by f1shy »

p1esk wrote: post #339
f1shy wrote: post #309

Earlier quoted context omitted.

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.

Used yes. But not the biggest part. Maybe 10% at most.

We are doing L4, so if something goes wrong, the manufacturer is responsible. Once we were in a test car. It was behaving great. At one point, the car "makes the decision" to accelerate and pass. The manager to which we were showing asks "we did the car not waited a little bit? can we change that behavior?". A very long discussion ensued, about data sets, labeling, training... long story short: we have to be able to change behavior (even for perception) in a deterministic way. So the amount of NNs went down dramatically after that.

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

#406

Post by p1esk »

f1shy wrote: post #405
p1esk wrote: post #339

Earlier quoted context omitted.

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

Used yes. But not the biggest part. Maybe 10% at most. We are doing L4, so if something goes wrong, the manufacturer is responsible. Once we were in a test car. It was behaving great. At one point, the car "makes the decision" to accelerate and pass. The manager to which we were showing asks "we did the car not waited a little bit? can we change that behavior?". A very long discussion ensued, about data sets, labelin…

This is a good point, and I expect in the near future we will be able to simply ask a neural network to explain and change its behavior without retraining. I already see signs of that in prompt engineering used to interact with GPT3 or Dalle2.

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

#407

Post by gpderetta »

tialaramex wrote: post #363
kristopolous wrote: post #323

Earlier quoted context omitted.

There's a lot there. Let's get the technical part done first. Historically after you create object files the linker doesn't care what c++ standard the source was. So you could carefully combine different standards. I guess I have to establish I'm talking about the GNU toolchain here and that it's been a few years since I've done this. I'll try it again when I get home, maybe that all blows up now. Now about the other…

> Historically after you create object files the linker doesn't care what c++ standard the source was. Mechanically this is true, but just because we can link object files together doesn't mean the resulting program makes sense. Suppose I have an object file I made with GCC's copy-on-write C++ 98 strings and then I linked that to an object file I made with GCC's modern C++ 11 short string optimised strings. If these…

When gcc broke the string ABI they made sure that code that uses one version wouldn't link with code that uses the other one.

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

#408

Post by dureuill »

int_19h wrote: post #381
dureuill wrote: post #84

Earlier quoted context omitted.

modules were my #1 wanted feature in C++, but they are very disappointing to me: - they allow `.` in their names to signify hierarchy, but have no built-in notion of hierarchy or submodule. This means possible error messages will have to be suboptimal - they are orthogonal to namespaces, meaning if you have a module `foo.bar` any identifier it will export will be in the global namespace unless you put it in the `foo:…

Popular languages that went for strict 1:1 mapping between modules and filesystem, like Java and Python, often end up moving away from it, or at least adding various hacks (e.g. the way you can split submodules across packages in Python).

I don't know about Java, but in Python, 99% of the modules I create respect the 1:1 mapping between modules and filesystem.

Same in Rust, the overwhelming majority of modules I create is in the standard filesystem modules mapping. For generated code, I use the special syntax that allows not respecting this mapping, but that's once in a blue moon.

IMO, C++ should have taken the same steps: providing sane, correct and easy defaults, while allowing the flexibility to override them when necessary (with special annotations).

I'm disappointed that a modern C++ feature was designed in the long tradition of having bad defaults instead.

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

#409

Post by leni536 »

int_19h wrote: post #379
leni536 wrote: post #76

Earlier quoted context omitted.

umm, you can edit: to elaborate both g++ and clang++ implement the Itanium C++ ABI[1]. You might get binary incompatibility by mixing standard libraries, so just don't do that. [1] https://itanium-cxx-abi.github.io/cxx-abi/abi.html

Standard libraries is what makes most of C++. (Like, literally, going by the size of the language spec.)

And the same applies to C and libc.

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

#410

Post by arinlen »

gpderetta wrote: post #356
arinlen wrote: post #111

Earlier quoted context omitted.

> It's a branding problem. They should probably be viewed as different flavors. They are already different language versions. They're specified in entirely different standards. I don't see what's left to be confused about. At most, perhaps the C++ standard committee could be criticized for repeatedly going out of their way to maximize backward compatibility. > If every time they're going to add things, remove things…

Not only it is possible, it is routinely done. At $WORK we have libraries that are use std=20 features in its implementation and only expose a c++=14 interface because that's what expected by our clients. It is mildly painful, bit not more painful than restricting to c++14.

> At $WORK we have libraries that are use std=20 features (...)

That's specified at the package/project level. You're inadvertently proving my point.

> (...) and only expose a c++=14 interface because that's what expected by our clients.

That's also configured at the package level, because the interface headers need to be included in translation units from projecta configured tu be C++14.

Again, you're also inadvertently supporting the point I made.

Post reply on HN