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

21st Century C++

cacm.acm.org

Post reply on HN
Print view View original

221–230 of 281 posts

Re: 21st Century C++

#221

Post by simoncion »

ivan_gammel wrote: post #211
simoncion wrote: post #207

Earlier quoted context omitted.

While "Well, just bundle in a copy of the whole-ass JRE" makes packaging Java software easier, it's still true that Java's backwards-compatibility is often really bad. > ...sharing runtime dependencies [in C or C++] is hard... Is it? The "foo.so foo.1.so foo.1.2.3.so" mechanism works really well, for libraries whose devs that are capable of failing to ship backwards-incompatible changes in patch versions, and ABI-bre…

> Java's backwards-compatibility is often really bad. “Often” is a huge exaggeration. I always hear about it, but never encountered it myself in 25 years of commercial Java development. It almost feels like some people are doing weird stuff and then blame the technology. > Is it? The "foo.so foo.1.so foo.1.2.3.so" Is it “sharing” or having every version of runtime used by at least one app?

> I always hear about it, but never encountered it myself in 25 years of commercial Java development.

Lucky you, I guess?

> Is it “sharing” or having every version of runtime used by at least one app?

I'm not sure what you're asking here? As I'm sure you're aware, software that links against dependent libraries can choose to not care which version it links against, or link against a major, minor, or patch version, depending on how much it does care, and how careful the maintainers of the dependent software are.

So, the number of SOs you end up with depends on how picky your installed software is, and how reasonable the maintainers of the libraries they use are.

Re: 21st Century C++

#222

Post by williamcotton »

imtringued wrote: post #214
IshKebab wrote: post #204

Earlier quoted context omitted.

You absolutely can throw things out, and they have! Checked exceptions, `auto`, and breaking changes to operator== are the two I know of. There were also some minor breaking changes to comparison operators in C++20. They absolutely could say "in C++26 vector::operator[] will be checked" and add an `.at_unsafe()` method. They won't though because the whole standards committee still thinks that This Is Fine. In fact th…

"just get good" implies development processes that catch memory and safety bugs. Meaning what they are really saying between the lines is that the minimum cost of C++ development is really high. Any C++ code without at least unit tests with 100% test coverage on with UB sanitizer etc, must be considered inherently defective and the developer should be flogged for his absurd levels of incompetence. Then there is also…

Add ASan and friends as well as a sanitizer-less build for Valgrind!

Re: 21st Century C++

#224

Post by otabdeveloper4 »

notfed wrote: post #182
otabdeveloper4 wrote: post #181

Earlier quoted context omitted.

"Undefined behavior" is not a bug. It's something that isn't specified by an ISO standard. Rust code is 100 percent undefined behavior because Rust doesn't have an ISO standard. So, theoretically some alternative Rust compiler implementation could blow up your computer or steal your bitcoins. There's no ISO standard to forbid them from doing so. (You see where I'm going with this? Standards are good, but they're a le…

> "Undefined behavior" is not a bug. It's something that isn't specified by an ISO standard. An ISO standard ? According to who, ISO?

Yeah, legal constructs are not actually real and are based on circular logic. (And not just in software, that's a property of legal constructs in general.)

Your point is what?

Re: 21st Century C++

#225

Post by pxmpxm »

logicchains wrote: post #201
nindalf wrote: post #172

Earlier quoted context omitted.

> And it's not clear if memory safety is the largest source of problems building software today. The Chromium team found that > Around 70% of our high severity security bugs are memory unsafety problems (that is, mistakes with C/C++ pointers). Half of those are use-after-free bugs. Chromium Security: Memory Safety ( https://www.chromium.org/Home/chromium-security/memory-safet... ) Microsoft found that > ~70% of the v…

Two of the biggest use cases for modern C++ are video games and HFT, where memory safety is of absolutely minimal importance (unless you're writing some shitty DRM/anticheat). I work in HFT using modern C++ and bugs related to memory safety are vanishingly rare compared to logic and performance bugs.

Very much this. For some reason people assume that security/exploits are what the below is refering to, as if that's the endgoal that software is trying to solve.

> it's not clear if memory safety is the largest source of problems building software today

Re: 21st Century C++

#226

Post by jpc0 »

tsimionescu wrote: post #197
jpc0 wrote: post #179

Earlier quoted context omitted.

> Around 70% of our high severity security bugs are memory unsafety problems > ~70% of the vulnerabilities Microsoft assigns a CVE > 76% of vulnerabilities What is the difference between the first two (emphasis added) and what you said? Just as a thought experiment... If I measure a single factor in exclusion to all others I can also find whatever I want in any set of data. Now your point may be valid but it is not w…

This whole concept that code should be architected as "libraries" and "userspace" is such a C++ism. It's a really weird concept that probably comes only from having this extremely complex language where even the designers expect some parts of it are too weird for "normal programmers". But then they imagine some advanced class of programmer, the "library programmers", who can deal with such complexity. The more modern…

So you strongly believe that the programmer should implement .map on arrays and hashmaps etc themselves? Well you will love C code then.

The point of library code is to implement these things once in a safe and efficient manner and reuse the implementation.

Sometimes there are more domain or even company specific things that should be implemented exactly once and reused.

Nobody said there are different tiers of developers like "library developers" and "normal developers". Those are different types of programming that a single developer can do but fundamentally require a different thought pattern. Designing datastructures and algorithms are a lot more CS whereas general programming is much more akin to plumbing. If you think library code isn't needed it's because you overlook the library code you already use.

There are some things that are not yagni, if you have those in place then the rest of your code can literally be implemented that way because you literally won't need it.

It's not that shared_ptr isn't needed, it's that people don't use it where necessary, they use it because it's convenient not to think entirely and because the necessary Library code isn't there. I stand strong that seeing std::shared_ptr/box (or even std::unique_ptr/Box) in general code is a code smell, the fact that you even said that there are certain algorithm's that cannot be expressed without it means you agree, the algorithm should be implemented exactly once and reused. If it's only used one then sure it can be abstracted when needed but that doesn't mean you shouldn't need to justify why it's there.

Re: 21st Century C++

#227

Post by ivan_gammel »

simoncion wrote: post #221
ivan_gammel wrote: post #211

Earlier quoted context omitted.

> Java's backwards-compatibility is often really bad. “Often” is a huge exaggeration. I always hear about it, but never encountered it myself in 25 years of commercial Java development. It almost feels like some people are doing weird stuff and then blame the technology. > Is it? The "foo.so foo.1.so foo.1.2.3.so" Is it “sharing” or having every version of runtime used by at least one app?

> I always hear about it, but never encountered it myself in 25 years of commercial Java development. Lucky you, I guess? > Is it “sharing” or having every version of runtime used by at least one app? I'm not sure what you're asking here? As I'm sure you're aware, software that links against dependent libraries can choose to not care which version it links against, or link against a major, minor, or patch version, de…

> So, the number of SOs you end up with depends on how picky your installed software is, and how reasonable the maintainers of the libraries they use are.

And that is the hard problem, because it’s people problem, not technical one, and it’s platform independent. When some Java app was requiring a specific build of JRE, it wasn’t limitation or requirement of the platform, but rather the choice of developers based on their expectations and level of trust. Windows still dominates desktop space and it’s not uncommon for C++ programs to install or require a specific version of runtime, so you eventually have lots of them installed.

Re: 21st Century C++

#228

Post by janwas »

imtringued wrote: post #216
jandrewrogers wrote: post #159

Earlier quoted context omitted.

Unfortunately, Rust is significantly less expressive than C++ and therefore is unlikely to replace it for high-performance systems code. As much as I don’t like C++, it is very powerful as a tool. The ability to express difficult low-level systems constructs and optimizations concisely and safely in the language are its killer feature. Once you know how to use it, other languages feel hobbled.

Most high performance code is vectorized and Rust is better at autovectorization and aliasing analysis than C++, so I'm not really seeing your point. Having to drop down to intrinsics early is not a strength.

hm, I'd be concerned about relying on autovectorization. How much better is 'better'? Compiler friends have told me that something permute-heavy like sorting is unlikely to soon work, if ever.

My biased opinion, from doing this full-time in C++, is that the C++ SIMD story is much further along, especially regarding mature libraries.

Re: 21st Century C++

#229

Post by ephaeton »

IshKebab wrote: post #204
Animats wrote: post #192

Earlier quoted context omitted.

> The C++ committee, including Bjarne Stroustrup, needs to accept that the language cannot be improved without breaking changes. The example in the article starts with "Wow, we have unordered maps now!" Just adding things modern languages have is nice, but doesn't fix the big problems. The basic problem is that you can't throw anything out. The mix of old and new stuff leads to obscure bugs. The new abstractions tend…

You absolutely can throw things out, and they have! Checked exceptions, `auto`, and breaking changes to operator== are the two I know of. There were also some minor breaking changes to comparison operators in C++20. They absolutely could say "in C++26 vector::operator[] will be checked" and add an `.at_unsafe()` method. They won't though because the whole standards committee still thinks that This Is Fine. In fact th…

That explains very well why rust (to me) feels like C++ommitte-designed, thanks for that!

Re: 21st Century C++

#230

Post by steveklabnik »

ephaeton wrote: post #229
IshKebab wrote: post #204

Earlier quoted context omitted.

You absolutely can throw things out, and they have! Checked exceptions, `auto`, and breaking changes to operator== are the two I know of. There were also some minor breaking changes to comparison operators in C++20. They absolutely could say "in C++26 vector::operator[] will be checked" and add an `.at_unsafe()` method. They won't though because the whole standards committee still thinks that This Is Fine. In fact th…

That explains very well why rust (to me) feels like C++ommitte-designed, thanks for that!

I don’t understand what you’re trying to say, could you elaborate?
Post reply on HN