undefined | Better HN

0 pointsmaccard1y ago0 comments

Also that the features c++ is getting are bolt on additions that we already have solutions for. I think fmt is a great example - fmt is a header only library that can be dropped in. Meanwhile std format was standardised without printing to stout. That took 3 years to standardise. Meanwhile we’re working on things like ranges, and instead of implementing them in the language it’s shoe horned in as a library feature - we now pay massive compile time hits for these features that are being shoved in alongside the kitchen sink. Meanwhile the solution (modules) has been talked about longer than I’ve been writing c++, it’s still unusable, and it hasn’t shown one of the key things people have been begging for for a decade - faster compile times.

I think the committee is focused on the wrong things

0 comments

meindnoch1y ago

>instead of implementing them in the language it’s shoe horned in as a library feature

Quite the opposite. Proliferating the language itself with ad-hoc constructs would be shoe-horning.

maccardOP1y ago

I disagree completely. Libraries like ranges are dumped into algorithm, and are de-facto considered parts of the language. Reflection has gone back to have range support added, for example. Another one is that span has a performance overhead due to it being implemented as a normal type. If it was part of the language rather than a library type, the compiler could make assumptions about it, but instead it’s treated equivalent to me writing it myself. I would much rather gcc saw me passing a span around and could treat it as a special built in type.

meindnoch1y ago

>Another one is that span has a performance overhead due to it being implemented as a normal type. If it was part of the language rather than a library type, the compiler could make assumptions about it, but instead it’s treated equivalent to me writing it myself.

False. Nothing prevents compilers from giving their own stdlib types special treatment under the hood.

maccardOP1y ago

That would be an ABI break which is just not happening, and you know it. As it is we’ve decided it’s more important to be able to use std span from libc++ on clang than it is to have an optimised version for people on their tool chain.

1 more reply

VHRanger1y ago

You can't have faster compile times. If you want fast compile times C++ needs to sacrifice something else (ABI compatibility, compatibility to compile code from 1979 for some dead big endian 12-bit word chip, etc.

In fact the truth is the people working on C++ don't actually value fast compile times over other matters (fast runtime, ABI compatibility, etc.)

They say they do. But they don't in their actions.

One egregious example: look at the compilation speeds of clang with release build configs (-O2 or higher, etc.) over the years.

It compiles much slower now than it did in 2014 for the same code. The compilation speed is worsening at a much faster rate than the runtime speeds are improving from version to version.

maccardOP1y ago

I agree with you. I would move heaven and earth for faster unoptimizrd builds, but I’m perfectly happy with multi hour O2 builds from clang. The state that modules was standardised in proved what you’re saying - there were many opportunities to allow for faster compile times but instead we chose maximum flexibility with no consideration for what that leaves on the table.

pjmlp1y ago

That sacrifice is called C++20 modules and quite alright on VC++ and clang 18.

lallysingh1y ago

Ha! Modules. I wrote a basic version of that in 2006 for Boost. This is as big a useless mess as web components. It feels like c++ is in the legacy category with x86, still here, tolerable due to exponential efforts, and still dying for simpler solutions that aren't beholden to decades-old design mistakes. (variable instruction width, context-sensitive grammar, #include model, etc).

maccardOP1y ago

I think that what we have standardised as modules give us a path off the include model, honestly. It’s just that it’s the most pandered-to version of modules you could imagine. We entirely changed the compilation model and didn’t manage to tie module names to filesystem paths, meaning you need to parse the module file to figure out what module it is. It’s death by a thousand cuts

j / k navigate · click thread line to collapse

0 comments

meindnoch1y ago

>instead of implementing them in the language it’s shoe horned in as a library feature

Quite the opposite. Proliferating the language itself with ad-hoc constructs would be shoe-horning.

maccardOP1y ago

meindnoch1y ago

False. Nothing prevents compilers from giving their own stdlib types special treatment under the hood.

maccardOP1y ago

1 more reply

VHRanger1y ago

In fact the truth is the people working on C++ don't actually value fast compile times over other matters (fast runtime, ABI compatibility, etc.)

They say they do. But they don't in their actions.

One egregious example: look at the compilation speeds of clang with release build configs (-O2 or higher, etc.) over the years.

It compiles much slower now than it did in 2014 for the same code. The compilation speed is worsening at a much faster rate than the runtime speeds are improving from version to version.

maccardOP1y ago

pjmlp1y ago

That sacrifice is called C++20 modules and quite alright on VC++ and clang 18.

lallysingh1y ago

maccardOP1y ago

j / k navigate · click thread line to collapse