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

C++26 is done: ISO C++ standards meeting Trip Report

herbsutter.com

Post reply on HN
Print view View original

141–150 of 437 posts

Re: C++26 is done: ISO C++ standards meeting Trip Report

#141

Post by FrostKiwi »

duped wrote: post #131
jjmarr wrote: post #40

Earlier quoted context omitted.

You don't on new projects. CMake + ninja has support for modules on gcc, clang, and MSVC. This should be your default stack on any small-to-medium sized C++ project. Bazel, the default pick for very large codebases, also has support for C++20 modules.

I have yet to see modules in the wild. What I have seen extensively are header-only projects.

It's the fault of built systems. CMake still doesn't support `import std` officially and undocumented things are done in the ecosystem [1]

But once it works and you setup the new stuff, having started a new CPP26 Project with modules now, it's kinda awesome. I'm certainly never going back. The big compilers are also retroactively adding `import std` to CPP20, so support is widening.

[1] https://gitlab.kitware.com/cmake/cmake/-/work_items/27706

Re: C++26 is done: ISO C++ standards meeting Trip Report

#142

Post by zarzavat »

lmm wrote: post #138
daemin wrote: post #130

Earlier quoted context omitted.

I may be in the minority but I like that C++ has multiple package managers, as you can use whichever one best fits your use case, or none at all if your code is simple enough. It's the same with compilers, there's not one single implementation which is the compiler, and the ecosystem of compilers makes things more interesting.

Multiple package managers is fine, what's needed is a common repository standard (or even any repository functionality at all). Look at how it works in Java land, where if you don't want to use Maven you can use Gradle or Bazel or what have you, or if you hate yourself you can use Ant+Ivy, but all of them share the same concept of what a dependency is and can use the same repositories.

Also, having one standard packaging format and registry doesn't preclude having alternatives for special use cases.

There should be a happy path for the majority of C++ use cases so that I can make a package, publish it and consume other people's packages. Anyone who wants to leave that happy path can do so freely at their own risk.

The important thing is to get one system blessed as The C++ Package Format by the standard to avoid xkcd 927 issues.

Re: C++26 is done: ISO C++ standards meeting Trip Report

#143

Post by btilly »

gmueckl wrote: post #102
ghighi7878 wrote: post #98

Earlier quoted context omitted.

Just because Bjarne thinks the feature is bad doesnt mean it is bad. He can be wrong. The point is, most peoppe disagree with him, and so a lot of peoppe do think it is good.

There have been several talks about contracts and the somewhat hidden complexities in them. C++ contracts are not like what you'd initally expect. Compiler switches can totally alter how contracts behave from getting omitted to reporting failures to aborting the program. There is also an optional global callback for when a contract check fails. Different TUs can be compiled with different settings for the contract be…

That sounds like the worst kind of misfeature.

It sounds like it should solve your problem. At first it seems to work. Then you keep on finding the footguns after it is too late to change the design.

Re: C++26 is done: ISO C++ standards meeting Trip Report

#144

Post by ranger_danger »

dheera wrote: post #85
mohamedkoubaa wrote: post #2

Biggest open question is whether the small changes to the module system in this standard will actually lead to more widespread adoption

I frankly wish we'd stop developing C++. It's so hard to keep track of all the new unnecessary toys they're adding to it. I thought I knew C++ until I read some recent C++ code. That's how bad it is. Meanwhile C++ build system is an abomination. Header files should be unnecessary.

You don't have to keep up with or use any of the new features. I still pay my bills writing C++98 and have no desire to use a higher version.

Re: C++26 is done: ISO C++ standards meeting Trip Report

#145

Post by saghm »

kibwen wrote: post #106
saghm wrote: post #45

Earlier quoted context omitted.

To me, the most important feature of Cargo isn't even the dependency management but that I don't ever need to tell it which files to compile or where to find them. The fact that it knows to look for lib.rs or main.rs in src and then recursively find all my other modules without me needing to specify targets or anything like that is a killer feature on its own IMO. Over the past couple of years I've tried to clone and…

> The fact that it knows to look for lib.rs or main.rs in src and then recursively find all my other modules without me needing to specify targets or anything like that is a killer feature on its own IMO. In the interest of pedantry, locating source files relative to the crate root is a language-level Rust feature, not something specific to Cargo. You can pass any single Rust source file directly to rustc (bypassing…

Interesting, I didn't realize this! I know that a "crate" is specifically the unit of compilation for rustc, but I assumed there was some magic in cargo that glued the modules together into a single AST rather than it being in rustc itself.

That being said, I'd argue that the fact that this happens so transparently that people don't really need to know this to use Cargo correctly is somewhat the point I was making. Compared to something like cmake, the amount of effort to use it is at least an order of magnitude lower.

Re: C++26 is done: ISO C++ standards meeting Trip Report

#146

Post by drfloyd51 »

kevin_thibedeau wrote: post #127
spacechild1 wrote: post #69

Earlier quoted context omitted.

Pre- and postconditions are actually part of the function signature, i.e. they are visible to the caller. For example, static analyzers could detect contract violations just by looking at the callsite, without needing access to the actual function implementation. The pre- and postconditions can also be shown in IDE tooltips. You can't do this with your own contracts implementation. Finally, it certainly helps to have…

Is a pointer parameter an input, output, or both?

Input.

You are passing in a memory location that can be read or written too.

That’s it.

Re: C++26 is done: ISO C++ standards meeting Trip Report

#147

Post by saghm »

nicoburns wrote: post #134
saghm wrote: post #45

Earlier quoted context omitted.

To me, the most important feature of Cargo isn't even the dependency management but that I don't ever need to tell it which files to compile or where to find them. The fact that it knows to look for lib.rs or main.rs in src and then recursively find all my other modules without me needing to specify targets or anything like that is a killer feature on its own IMO. Over the past couple of years I've tried to clone and…

> I don't think I've ever had an issue with a Rust project, and it's hard not to feel like a big part of that is because there's not really much configuration to be done. For most crates, yes. But you might be surprised how many crates have a build.rs that is doing more complex stuff under the hood (generating code, setting environment variables, calling a C compiler, make or some other build system, etc). It just al…

True, but if anything, a build.rs is a lot easier for me to read and understand (or even modify) if needed because I already know Rust. With something like cmake, the build configuration is an entirely separate language the one I'm actually working in, and I haven't seen a project that doesn't have at least some amount of custom configuration in it. Starting up a cargo project literally doesn't require putting anything in the Cargo.toml that doesn't exist after you run `cargo new`.

Re: C++26 is done: ISO C++ standards meeting Trip Report

#148

Post by kevin_thibedeau »

drfloyd51 wrote: post #146
kevin_thibedeau wrote: post #127

Earlier quoted context omitted.

Is a pointer parameter an input, output, or both?

Input. You are passing in a memory location that can be read or written too. That’s it.

A pointer doesn't necessarily point to memory.

Re: C++26 is done: ISO C++ standards meeting Trip Report

#149

Post by tourist2d »

einpoklum wrote: post #91

If you ask me (and why wouldn't you? :-)...) I really wish the C++ WG would do several things: 1. Standardize a `restrict` keyword and semantics for it (tricky for struct/class fields, but should be done). 2. Uniform Function Call Syntax! That is, make the syntax `obj.f(arg)` mean simply `f(obj, arg)` . That would make my life much easier, both as a user of classes and as their author. In my library authoring work pa…

1. This seems like it's be far too tricky and make C++ even more footgunny, especially with references, move constructors, etc etc.

2. Name lookup and overload resolution is already so complex though! This will likely never be added because it's so core c++ and would break so much. imo, it also blurs the line between what's your interface vs what I've defined.

3. This is every junior c++ engineers suggestion. Having ABI breaks would probably kill c++, even though it would improve the language long term.

4. Again, you make solid points and I think a lot of the committee would agree with you. However, the committee's job is to adapt C++ in a backwards supporting way, not to disrupt it's users and API each new release.

There are definitely things to fix in c++ and every graduate engineer I've managed has had the same opinions of patching the standard, without considering the full picture.

Re: C++26 is done: ISO C++ standards meeting Trip Report

#150

Post by zrm »

mgaunard wrote: post #120
zrm wrote: post #71

Earlier quoted context omitted.

> C and C++ are usually stuck in that antiquated thinking that you should build a module, package it into some libraries, install/export the library binaries and associated assets, then import those in other projects. That makes everything slow, inefficient, and widely dangerous. It seems to me the "convenient" options are the dangerous ones. The traditional method is for third party code to have a stable API. Newer…

This is all wishful thinking disconnected from practicalities. First you confuse API and ABI. Second there is no practical difference between first and third-party for any sufficiently complex project. Third you cannot have multiple versions of the same thing in the same program without very careful isolation and engineering. It's a bad idea and a recipe for ODR violations. In any non-trivial project there will be co…

> First you confuse API and ABI.

I'm not confusing API with ABI. If you don't have a stable ABI then you essentially forfeit the traditional method of having every program on the system use the same copy (and therefore version) of that library, which in turn encourages them to each use a different version and facilitates API instability by making the bad thing easier.

> Second there is no practical difference between first and third-party for any sufficiently complex project.

Even when you have a large project, making use of curl or sqlite or openssl does not imply that you would like to start maintaining a private fork.

There are also many projects that are not large enough to absorb the maintenance burden of all of their external dependencies.

> Third you cannot have multiple versions of the same thing in the same program without very careful isolation and engineering.

Which is all the more reason to encourage every program on the system to use the same copy by maintaining a stable ABI. What do you do after you've encouraged everyone to include their own copy of their dependencies and therefore not care if there are many other incompatible versions, and then two of your dependencies each require a different version of a third?

> In any non-trivial project there will be complex dependency webs across different files and subprojects, and humans are notoriously bad at packaging pieces of code into sensible modules, libraries or packages, with well-defined and maintained boundaries.

This feels like arguing that people are bad at writing documentation so we should we should reduce their incentive to write it, instead of coming up with ways to make doing the good thing easier.

Post reply on HN