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

Modern C++ Won't Save Us

alexgaynor.net

Post reply on HN
Print view View original

311–320 of 395 posts

Re: Modern C++ Won't Save Us

#311

Post by colanderman »

Althorion wrote: post #305
colanderman wrote: post #297

Earlier quoted context omitted.

I can't, but I bet they have a standard and well-accepted definition in the mathematical community. In fact, pretty much any real-valued mathematical function passes the test. The interface is settled, almost by definition since C++ functions are inspired by mathematical functions: pass in arguments, return result. Use range/domain exceptions or NaN for reporting such errors. The semantics are obvious: compute the na…

There’s nearly a limitless amount of standard and well-defined functions with a single usage, like those. There’s hardly a point in implementing them in the standard library and C++ is the only language that I’m aware of that has those. If the goal was to create a specialized library for solving differential equations, those would be handy there. But if not, even if you tried implementing everything that you could po…

Then you're not disagreeing with me, because those functions pass my test as I demonstrated above.

Why do these functions bother you so much? It can't be namespace pollution; they're under std::. It can't be that you disagree with their interface or semantics, since by your own admission you don't even know what they are.

You named some other features, such as quaternions, that you think would be better for implementors to spend their time on, but surely you can imagine someone like yourself who is tired of having to define the Bessel functions every time they start a new project, and can't imagine why the C++ committee saw fit to include something so useless and obscure as quaternions before getting to Bessel functions.

Re: Modern C++ Won't Save Us

#312

Post by jstimpfle »

lmm wrote: post #300
jstimpfle wrote: post #294

Earlier quoted context omitted.

> At that point you're not using global state in the library, which was the point. Yes. But I want to make clear that you are still using global state for all uses within the project itself. The library can be implemented in whatever way. For example, setting the pointer in a global variable on API entry ;-) > That doesn't solve the problem at all. WHICH problem? I don't think there is one. > Indeed, and they're seen…

> Yes. But I want to make clear that you are still using global state for all uses within the project itself. But if we believe in using libraries then often our project will itself be a library. > The library can be implemented in whatever way. For example, setting the pointer in a global variable on API entry ;-) And then you have the problem I mentioned: if there is a diamond dependency on your library then the th…

> But if we believe in using libraries then often our project will itself be a library.

How about making the project good first? Let's try to get something done instead of theoretizing.

Re: Modern C++ Won't Save Us

#313

Post by madisfun »

nimrody wrote: post #184
dpc_pw wrote: post #120

Earlier quoted context omitted.

Except for stuff like "trusting trust", I find no need for "multiple vendors of Rust toolchains". It only comes handy when the language itself is not truly open source, and is in itself a form of a product. Building on that " is not standardized," is not a problem, because one Open Source implementation is de facto the standard. Which I find much better than forever fixing your code, working around incompatibilities,…

Sometimes different vendors provide some benefits. For example Intel's C++ compiler produces (or used to produce?) much more efficient numerical code than either gcc or clang. So for numerical applications C++ may make more sense than Rust. Rust does have the advantage of being based on an LLVM backend. So perhaps different vendors can compete by writing more efficient backends that are applicable to both C++ and Rus…

> For example Intel's C++ compiler produces (or used to produce?) much more efficient numerical code than either gcc or clang.

I'm not an expert, but I believe that Intel could have implemented their hardware-specific optimizations in any other compiler framework (either gcc or clang). In this case multiple language implementations, while commercially viable, are not beneficial to all users.

Re: Modern C++ Won't Save Us

#314

Post by Const-me »

nradov wrote: post #108
fooker wrote: post #103

Earlier quoted context omitted.

I don't see the problem. You are free to use such a modern library (Google does, it's called absl). The good thing here is that the standard library doesn't require 'magic' to be implemented (unlike Swift where the standard library relies on hidden language hacks).

Sure it's possible to use a non-standard "standard library". But at that point you're already halfway to using a different language so why not consider switching from C++ to D / Rust / Go?

Many libraries only expose C or C++ APIs. Some of these libraries are hard requirement, like OS kernel APIs or GPU APIs.

Insufficient SIMD support in other languages, Intel only supports their intrinsics in C and Fortran.

Tools for C++ are just too good, IDEs, debuggers, profilers.

Re: Modern C++ Won't Save Us

#315

Post by hu3 »

clouddrover wrote: post #213
hu3 wrote: post #194

Earlier quoted context omitted.

That's not memory safe as the book itself states: > Now, the volatile accesses are performed automatically through the read and write methods. It's still unsafe to perform writes, but to be fair, hardware is a bunch of mutable state and there's no way for the compiler to know whether these writes are actually safe, so this is a good default position. https://github.com/rust-embedded/book/blob/9c05a419fc2ad231c...

I think you need to read on a bit further. The very next section after the sentence you quoted is: "We need to wrap this struct up into a higher-layer API that is safe for our users to call. As the driver author, we manually verify the unsafe code is correct, and then present a safe API for our users so they don't have to worry about it (provided they trust us to get it right!)." Rust lets you write clearly defined u…

Don't assume I haven't read it. I read the book.

Wrapping unsafe code behind an API doesn't make it go away. It's still unsafe and needs manual checking.

Also wrapping code with hints and annotations of some sort is a thing in numerous PL. It's a given, not a feature and certainly not a bug as you wrongly implied I stated.

TLDR: it's still unsafe as the book and others pointed out.

Re: Modern C++ Won't Save Us

#316

Post by lmm »

jstimpfle wrote: post #312
lmm wrote: post #300

Earlier quoted context omitted.

> Yes. But I want to make clear that you are still using global state for all uses within the project itself. But if we believe in using libraries then often our project will itself be a library. > The library can be implemented in whatever way. For example, setting the pointer in a global variable on API entry ;-) And then you have the problem I mentioned: if there is a diamond dependency on your library then the th…

> But if we believe in using libraries then often our project will itself be a library. How about making the project good first? Let's try to get something done instead of theoretizing.

You mean start by building something that can be used and tested in isolation, rather than trying to build an enormous system in one go? Isn't that what you've been arguing against?

Re: Modern C++ Won't Save Us

#317

Post by ncmncm »

nicoburns wrote: post #263
ncmncm wrote: post #125

Earlier quoted context omitted.

The whole point of C++ is that it enables writing more powerful libraries, capturing semantics in libraries that can then just be used. C++ is still quite a lot more powerful for this purpose than Rust. Rust will get better at it, over time, but it has a long way to go and C++ is not siiting still. Rust is still a niche language, and if its rates of adoption and improvement do not keep up, it will remain a niche lang…

> Rust is still a niche language Only just barely at this point. It has significant projects from a lot of the largest companies (Google, Microsoft, Amazon, etc). Firefox is using it, Dropbox is using it, Red Hat is using it.

In five years it might be just barely a niche language. In ten, if it catches on, it won't be.

If it does, its users will have come over from Java, C#, and C.

Re: Modern C++ Won't Save Us

#318

Post by Althorion »

colanderman wrote: post #311
Althorion wrote: post #305

Earlier quoted context omitted.

There’s nearly a limitless amount of standard and well-defined functions with a single usage, like those. There’s hardly a point in implementing them in the standard library and C++ is the only language that I’m aware of that has those. If the goal was to create a specialized library for solving differential equations, those would be handy there. But if not, even if you tried implementing everything that you could po…

Then you're not disagreeing with me, because those functions pass my test as I demonstrated above. Why do these functions bother you so much? It can't be namespace pollution; they're under std::. It can't be that you disagree with their interface or semantics, since by your own admission you don't even know what they are. You named some other features, such as quaternions, that you think would be better for implement…

> Then you're not disagreeing with me, because those functions pass my test as I demonstrated above.

Yeah. I must have misunderstood your definition of ‘obvious’—I though you meant ‘an obvious inclusion to the standard library’, not ‘having an obvious definition’. The definition is obvious, why they should be in a standard library is not.

> […] since by your own admission you don't even know what they are

I mostly do—I studied mathematics. Or, to be more precise, I learned about them, then never used them in programming, had to remind myself what they were and even after that, I don’t find them useful enough to warrant an inclusion to the standard library. Thus, since they were included, I think that’s a good evidence of C++ committee not trying to keep its standard library concise.

> You named some other features, such as quaternions, that you think would be better for implementors to spend their time on, but surely you can imagine someone like yourself who is tired of having to define the Bessel functions every time they start a new project, and can't imagine why the C++ committee saw fit to include something so useless and obscure as quaternions before getting to Bessel functions.

The thing is, I can’t. If you use them, you want a better support for solving differential equations than C++ offers anyway, so it’s more of a ‘OK, I have this small part already implemented, but I still have to find ways of doing the rest 95%’. This, plus the fact that I’m quite certain that people using C++ to do 3D geometry outnumber people using it for solving differential equations by a few orders of magnitude—a cursory glance at GitHub showed me that the only projects in C++ that mention it are… implementations of a standard library (and forks upon forks of those).

My problems with this is that C++ is now in a very strange place—it implements some very high level, niche features, bloating the language and its implementations (the size of glibc is a practical problem) while still lacking many others, that seem much more ‘obvious’ (i.e. ‘if given an unknown language, I would be much less surprised to find them included in its standard library). In the end, I have a language that both has annoyingly big standard library and heavily relies on other, non-standard ones for quite a lot of things.

Re: Modern C++ Won't Save Us

#319

Post by swiftcoder »

galangalalgol wrote: post #308
swiftcoder wrote: post #50

Earlier quoted context omitted.

It's a bona fide C++ killer for applications that are both security and performance critical. It's already gaining traction for those applications even within relatively conservative engineering organisations. That said, there are many performance-critical applications who are not security-critical, and in those I'd expect C/C++ to persist pretty much indefinitely. And many security-critical applications which are no…

Cargo is the problem for those organizations. People who worry about security and safety often develop on airgapped networks. You can go nostd for small stuff. For bigger stuff you could mirror crates.io but that isn't a well supported workflow and it's a lot o code from a lot of randos. The notion of a blessed subset would help get more buy in from that community. Even still, rustup isn't working on airgapped Dev ne…

Thankfully Cargo is an optional component. We've replaced Cargo for internal use (all dependencies checked into the monorepo and compiled with Buck).

Re: Modern C++ Won't Save Us

#320

Post by majewsky »

Althorion wrote: post #305
colanderman wrote: post #297

Earlier quoted context omitted.

I can't, but I bet they have a standard and well-accepted definition in the mathematical community. In fact, pretty much any real-valued mathematical function passes the test. The interface is settled, almost by definition since C++ functions are inspired by mathematical functions: pass in arguments, return result. Use range/domain exceptions or NaN for reporting such errors. The semantics are obvious: compute the na…

There’s nearly a limitless amount of standard and well-defined functions with a single usage, like those. There’s hardly a point in implementing them in the standard library and C++ is the only language that I’m aware of that has those. If the goal was to create a specialized library for solving differential equations, those would be handy there. But if not, even if you tried implementing everything that you could po…

> C++ is the only language that I’m aware of that has those.

https://golang.org/pkg/math/#J0

Post reply on HN