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

341–350 of 395 posts

Re: Modern C++ Won't Save Us

#341

Post by galangalalgol »

0815test wrote: post #310
galangalalgol wrote: post #308

Earlier quoted context omitted.

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…

Cargo now supports airgapped use (no crates.io, no github) since the latest release.

Awesome! Can you provide some documentation to get me started? I have been unable to find any.

Re: Modern C++ Won't Save Us

#342

Post by 0xffff2 »

w0utert wrote: post #262
ayosec wrote: post #219

Earlier quoted context omitted.

How is that different to this? if (my_pointer != NULL) do_stuff(*my_pointer)

In terms of generated coded, it is exactly the same. But that's not the point of optional types. The point of optional types is to force you to write checks for undefined values, otherwise your code will not compile at all. In the old-fashioned style of your example, you might forget to check for the possibility of a null pointer/otherwise undefined value, and use it as if it were valid.

But the whole genesis for this comment chain is that you can make exactly the same mistake with std::optional.

Re: Modern C++ Won't Save Us

#343

Post by geezerjay »

coldtea wrote: post #223
geezerjay wrote: post #146

Earlier quoted context omitted.

> The standard library certainly is lacking things which are commonly used (say, JSON parsing or database connection), I strongly disagree. It's quite obvious that the C++ standard library does not need to add support for "common things", because they already exist as third-party modules. In fact, this obsession to add all sorts of cruft to the C++ standard is the reason we're having this discussion. If there is no w…

> I strongly disagree. It's quite obvious that the C++ standard library does not need to add support for "common things", because they already exist as third-party modules. It's not obvious to me at all. In fact, if that was a valid argument, it would be for C++ not having a standard library at all, as everything (including vectors, strings, etc) also exists as "third-party modules".

> In fact, if that was a valid argument, it would be for C++ not having a standard library at all

Putting aside the continuum fallacy, it's easy to understand how the C++ would be better served by having access to a collection of third-party components instead of repeating C's and even Java's mistakes.

The Boost project is a very good example, so as the wealth of JSON and XML parsers.

In fact, this lesson is so blatantly obvious that essentially all mainstream programming languages simply adopt official package managers and leave it to the community to develop and adop the components they prefer.

Re: Modern C++ Won't Save Us

#344

Post by Kranar »

fooker wrote: post #293
Kranar wrote: post #289

Earlier quoted context omitted.

This is absolutely false. https://github.com/llvm-mirror/libcxx/blob/master/include/ty...

It checks if a non standard feature is available, otherwise falls back to a standard implementation. My argument was that it was possible to implement it with standard C++.

There's no way to implement that type trait using standard C++. The implementation does check if a non-standard feature is available, and if not it delegates to is_scalar which in turn delegates to is_enum which in turn delegates to is_union. is_union can not be implemented in a standard conforming manner without compiler support and libc++ unconditionally returns false if compiler support is not available, which does not conform to the standard.

Re: Modern C++ Won't Save Us

#345

Post by clouddrover »

hu3 wrote: post #315
clouddrover wrote: post #213

Earlier quoted context omitted.

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.

Then you're misrepresenting what the book is saying, which is worse than not having read it.

As an argument your position makes no sense. You might as well be arguing that there's no point in programming languages because sometimes you have to write assembly.

Re: Modern C++ Won't Save Us

#346

Post by ajross »

4thaccount wrote: post #97
ajross wrote: post #64

Earlier quoted context omitted.

> It’s definitely easier to reason about than C++ See... I don't think that's true, and argue the huge body of C++ code and talent in the ecosystem is an existence proof to the contrary. I mean, sure, C++ has its crazy edge cases and its odd notions. But you don't need to understand the vagaries of undefined behavior, or the RVO, or move semantics to write and deploy perfectly sensible code. Literally hundreds of tho…

"Rust is the new APL,like I said" I know you're trying to compare it to APL as that language mostly died off and is thus obscure, but I think the analogy is a little off. While APL is weird, it is actually really easy for me (someone with less than 15 hours playing with the language in total over the past few years) to code up some basic scripts a lot easier than something like C++. I'm being absolutely serious too.…

I picked APL because it matches the "WTF cray cray" aesthetic that Rust's syntax presents to new users. I can see an argument that Ada is the right analogy if you're going for pure complexity.

And yes, Fortran, APL, Ada (also Modula-2 & Oberon, Smalltalk and a bunch of other forgotten languages presented as the Next Big Thing at the time) are all uniformly simpler than either C++ or Rust. The modern world is a more complicated place and programming tools have kept up.

Re: Modern C++ Won't Save Us

#347

Post by int_19h »

geezerjay wrote: post #151
usrnm wrote: post #131

Earlier quoted context omitted.

Good luck implementing something like std::is_standard_layout without "magic language hacks". No, not all libraries are made equal and std is part of the language now, there is no way back

You've cherry-picked a type trait as your example, which arguably could be a core language feature made to look like a third-party module. Meanwhile, do you believe it's hard to implement a container? And no, adding cruft to the STL is not a one-way street. See for example the history of C++'s smart pointers.

It is pretty hard to implement a container with all the precise invariants and guarantees that the Standard requires.

But more to the point, your implementation might still not be as fast as the standard library one, because the standard library can make assumptions about the compiler that you cannot in portable code - what is UB to you might be well-defined behavior to stdlib authors. Thus, for example, they might be able to use memcpy for containers of stdlib types that they know are safe to handle in that manner.

Re: Modern C++ Won't Save Us

#348

Post by int_19h »

AnimalMuppet wrote: post #96
leshow wrote: post #84

Earlier quoted context omitted.

It was presented to show the "just use modern c++" counterargument to discussing the unsafety of c++ isn't a great argument. There are modern parts that are still unsafe.

Fair enough. But tatersolid seems to be condemning the entire language, which is a step too far for the evidence given.

std::string_view is supposed to be idiomatic C++, though.

Re: Modern C++ Won't Save Us

#349

Post by int_19h »

Animats wrote: post #93

The C++ people are trying to refit ownership to the language without adding a borrow checker. This is painful. They've made it possible to write code that expresses ownership, but they can't catch all the places where the abstraction leaks. string_view is really a non-mutable borrow. But the compiler does not know this.

It's still strictly better than a language with no borrow checker and no way to express ownership (other than comments), like C, or C++ itself before all the smart pointers.

Re: Modern C++ Won't Save Us

#350

Post by int_19h »

mjevans wrote: post #65
_wmd wrote: post #11

Earlier quoted context omitted.

Linux hit a related situation: a harmless null pointer dereference was treated by GCC as a signal that a subsequent isnull test could not be true, causing the test to be optimized away. https://lwn.net/Articles/575563/

My opinion on that, is that such code MUST NOT be optimized away. Instead it should be a compile error.

Why should it be a compile error? The pointer may be null, but is not guaranteed to be.

If you mean that C++ should require a null check before dereferencing any pointer that is not guaranteed to be non-null, then that would break most existing C++ code out there, so it's a non-starter.

Post reply on HN