Earlier quoted context omitted.
No, they are not.
Incorrect.
[deleted]
C++26 is done: ISO C++ standards meeting Trip Report
431–437 of 437 posts
Re: C++26 is done: ISO C++ standards meeting Trip Report
#432Earlier quoted context omitted.
> With expression templates you can translate one to the other, this is a static manipulation that does not depend on compiler level. How does that work on an implementation level? First thing that comes to mind is specialization, but I wouldn't be surprised if it were something else. > What does depend on the compiler is whether the incidental trivial function calls to operators gets optimized away or not. > Of cour…
Partial specialization specifically. Match some patterns and covert it to something else. For example: struct F { double x; }; enum Op { Add, Mul }; auto eval(F x) { return x.x; } template struct Expr; template struct Expr { L l; R r; friend auto eval(Expr self) { return eval(self.l) + eval(self.r); } }; template struct Expr { L l; R r; friend auto eval(Expr self) { return eval(self.l) * eval(self.r); } }; template s…
Hrm, OK, that makes sense. Thanks for taking the time to explain! Guessing optimizing x+y*z would entail something similar to the third eval() definition but with Expr, Add> instead.
I think at this point I can see how my initial assertion was wrong - specialization isn't fully orthogonal to expression templates, as the former is needed for some of the latter's use cases.
Does make me wonder how far one could get with rustc's internal specialization attributes...
Re: C++26 is done: ISO C++ standards meeting Trip Report
#433Earlier quoted context omitted.
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/cma…
I wanted to ship import std in 4.3 but there are some major disagreements over where the std.o symbols are supposed to come from. Clang says "we don't need them", GCC says "we'll ship them in libstdc++", and MSVC says "you are supposed to provide them". I didn't know about that when I was working on finishing import std for CMake and accidentally broke a lot of code in the move to a native implementation of the modul…
That's really interesting info, thanks!
Re: C++26 is done: ISO C++ standards meeting Trip Report
#434Earlier quoted context omitted.
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/cma…
weird to blame build systems for a problem caused by the language
You are of course right. It's just that Modules inherently put a lot of responsibility on the build system. Among those, but not limited to: a "module registry" wasn't standardized and is in the hands of the build system.
Systems like ninja needs to know modules, which took time and then a stack further up systems like CMake needed to know modules, which took time. That's my answer to the parent "why are there so few modules projects". Because it took time for the ecosystem to catch up.
Re: C++26 is done: ISO C++ standards meeting Trip Report
#435Earlier quoted context omitted.
C++ ODR requires different definition to consist of the same tokens, and if not the the program is IFNDR. Name mangling catches some stuff, but this becomes less relevant today with more things being generated via templates from headers. In C, it is UB when the types are not compatible, which is more robust. In practice it also easy to avoid with the same solution as in C++, i.e. there is a single header which declar…
Different parts of the build seeing inconsistent definitions of the same name is a clear consequence of building things piecemeal rather than as a single project -- which is precisely the problem I described higher up in this thread. Things being built piecemeal also likely won't be using LTO (even if fat LTO allows this, no static library packages in a distro are built with it).
Not sure what you are trying to say. Inconsistent definitions is a consequence of being able to build things separately, which is a major feature of C and C++, although in C++ it does not work well anymore. The reason to not build things piecemeal is often that LTO is more expensive. But occasionally running this will catch violations. When libraries get split up, the interface is defined via headers and there is little risk to get an inconsistency. So really do not think there is a major problem in C.
Re: C++26 is done: ISO C++ standards meeting Trip Report
#436Earlier quoted context omitted.
Much like contracts--yes, C++ needs something modules-like, but the actual design as standardized is not usable. Once big companies like Google started pulling out of the committee, they lost their connection to reality and now they're standardizing things that either can't be implemented or no one wants as specced.
Usable enough for Office, and the initial proposal was done by Microsoft.
I know Microsoft invested a lot into modules development and migrated a few small pieces of Office onto modules, but I'm not sure if they are actually using it extensively, and I'm also not sure if they're actually all that beneficial. Every time I hear about modules, it's stories about a year of migration work for a single-digit build-time improvement.
Re: C++26 is done: ISO C++ standards meeting Trip Report
#437Earlier quoted context omitted.
In essence, a standard committee thinks like bureaucrats. They have little to no incentive to get rid of cruft and only piling on new stuff is rewarded.
In D, we are implementing editions so features that didn't prove effective can be removed.
I am sadly not in the position to use D at work, but I appreciate your work!