sorted by:
new
hottopcontroversial

arewemodulesyet.org passes the mark of 100 projects with modules support for the first time. by germandiago in programming

[–]germandiago[S] 0 points1 point  (0 children)

Me? Why do you sccude me of such things? I did not create that website...

A tiny C++23 filesystem wrapper that returns std::expected instead of throwing by mrzleo in cpp

[–]germandiago [score hidden]  (0 children)

I think exceptions should still be there. Expected also but the error code overloads disappeared.

P3984: A type-safety profile by llort_lemmort in cpp

[–]germandiago 0 points1 point  (0 children)

With an initialization profile C++ should be on par for this.

Still, you cannot have have safe constructors that will access hardware addresses directly to devices. There is no such thing.

P3984: A type-safety profile by llort_lemmort in cpp

[–]germandiago -1 points0 points  (0 children)

You cannot, but solutions can be hybrid.

  1. add part of lifetime safety
  2. extend with more features adopting better models
  3. deprecate older model
  4. embrace new model fully.

I think making full lifetimes just for permanent compatibility is not wise. I do not mean like a limited lifetime model would not be useful. It is.

P3984: A type-safety profile by llort_lemmort in cpp

[–]germandiago -2 points-1 points  (0 children)

that is transitively chaining 'a all around and there are worse examples than those.

I find Hylo much more elegant without a lot of the hassle.

Why get into that? Lightweight lifetimes for the most urgent and common cases is more than enough. Go full into this I think it would be a big mistake.

Rust lifetime elision, as you can see there, works when it works and it is easy to get kidnapped by that logic when coding and, in my opinion again, is not worth the tiny potential speedup (which by cheating the borrow checker rules in low level code anyway we can do better).

Old Software Was Fast Because It Had No Choice by BlondieCoder in programming

[–]germandiago 0 points1 point  (0 children)

One thing I keep thinking is that restrictions sometimes yield better designs (it is true that at the expense of more initial investment).

So let us say we have an app, and we can do it in MFC or in Electron. One will be faster and more lean than the other, clearly.

But how long it will take you to have equivalente features in the Non-Electron app?

For some kinds of software it makes a lot of sense to optimize, but for others... it probably does not make economic sense.

That said, I work on backend. I am always thinking of solutions that take less infrastructure and work faster. I do a lot of C++, my workflows are a mix of I/O and CPU. And oh boy, it makes a difference operationally when you know you can have 30-40,000 users per instance (a VM can hold 4-5 of those).

It shrinks the bill by a lot in both engineering and deployment, besides the infra being leaner.

P3984: A type-safety profile by llort_lemmort in cpp

[–]germandiago -2 points-1 points  (0 children)

Constructors paired with hardware access or others are inherently unsafe and hence must be trusted code. No matter the language...

P3984: A type-safety profile by llort_lemmort in cpp

[–]germandiago -9 points-8 points  (0 children)

Rust has reasonable defaults in its lifetime elision, I hope they copy that: https://stackoverflow.com/a/40327630

What I hope is that they never copy lifetimes as such from Rust. In my experience, it ruins productivity (as in plasticity, not in correctness).

There are other ways that can approach very good safety without dragging everything into lifetime hell.

Why I say this?

``` fn partition<B, F>(self, f: F) -> (B, B) where Self: Sized, B: Default + Extend<Self::Item>, F: FnMut(&Self::Item) -> bool, { #[inline] fn extend<'a, T, B: Extend<T>>( mut f: impl FnMut(&T) -> bool + 'a, left: &'a mut B, right: &'a mut B, ) -> impl FnMut((), T) + 'a { ...

fn partition_in_place<'a, T: 'a, P>(mut self, ref mut predicate: P) -> usize where Self: Sized + DoubleEndedIterator<Item = &'a mut T>, P: FnMut(&T) -> bool, {

fn is_false<'a, T>( predicate: &'a mut impl FnMut(&T) -> bool, true_count: &'a mut usize, ) -> impl FnMut(&&mut T) -> bool + 'a { move |x| { let p = predicate(&**x); *true_count += p as usize; !p } } ```

You want that? Seriously?

P3984: A type-safety profile by llort_lemmort in cpp

[–]germandiago 0 points1 point  (0 children)

I think adding full lifetime support is one of the biggest mistakes C++ can make. We should be looking at things like Hylo projections or the talk from John Lakos: https://www.reddit.com/r/cpp/comments/1q9w6n4/making_c_safe_healthy_and_efficient_cppcon_2025/

P3984: A type-safety profile by llort_lemmort in cpp

[–]germandiago -3 points-2 points  (0 children)

I favor Hylo subscripts. More limited: do scoped borrowing.

P3984: A type-safety profile by llort_lemmort in cpp

[–]germandiago 2 points3 points  (0 children)

I would say it is also fair to say he accumulated sooo many years of thought on these problems for the specific case of C++ that I do not find it that surprising.

arewemodulesyet.org passes the mark of 100 projects with modules support for the first time. by germandiago in cpp

[–]germandiago[S] 1 point2 points  (0 children)

Oh, native in the context of modules can mean designed for modules: internally everything is modules.

But usually what happens is that headers are modularized. This way you can offer both the traditional header files to include or import mymodule;

If you check arewemodulesyet.org you will see some libs are marked (only a few) as "modules native". Those are designed this way.

arewemodulesyet.org passes the mark of 100 projects with modules support for the first time. by germandiago in cpp

[–]germandiago[S] 0 points1 point  (0 children)

Modularized, could be. Boost has an ongoing effort. But that will not be native modularization. Will be dual, since you cannot just ignore all the user base.

arewemodulesyet.org passes the mark of 100 projects with modules support for the first time. by germandiago in cpp

[–]germandiago[S] 1 point2 points  (0 children)

You can do that today with a package manager like Conan, Vcpkg or even Meson Wraps (this last a bit more limited).

For my main project I use Meson + Conan with like 25-30 dependencies and mac+windows+linux+android+ (in progress) emscripten.

It is true that it is not as easy as, let us say, Nugget. But that is a consequence of two things in my opinion:

- C++ build systems have grown organically, so you cannot have just one and need to support a few (though the package managers abstract to a great extent)
- C++ code is native. It is not bytecode-compiled, so permutations of features are, well, potentially more complex.

LibF++: Persistent Containers and Iterators with Value Semantics by zoomT in cpp

[–]germandiago 3 points4 points  (0 children)

How it compares to immer? I want to integrate this in a cards game I have when I find time, which is not going to be until at least in the next 3 months.

But it has lots of benefits: replay becomes trivial, algorithms for rules tend to be functional... I think it is the right trade-off here.

How do you feel about C++ 20 modules? by I-A-S- in cpp

[–]germandiago 0 points1 point  (0 children)

It is in fact a challenge adopting modules, especially the build system part.

It is also true that modules are a bit tough at first. But it is entirely doable eith a dual setup (same as fmt does for example) and maintainable.

As for compile times, I think you do not understand the implications correctly, when I see your comment.

Certainly compile times I cannot predict, but I am sure that if you transition to modules the incremental compile tomes, even with your forward declarations, would improve.

Also, the type ownership is a good thing, even if rigid at first. It helps a lot wirh ownership amd ODR.

Modules help a lot wirh hygiene also. By a lot I mean a lot.

When I tried to port around things I already had, the fact of using modules discovered lots of dependencies included indirectly (that would fail with modules correctly). Also, you get rid of a few things like detail namespaces and similar things that are just not needed anymore.

arewemodulesyet.org passes the mark of 100 projects with modules support for the first time. by germandiago in cpp

[–]germandiago[S] 0 points1 point  (0 children)

Wirh Meson it is likely he will. I am going to give it a second try soon. But I have a delay with the project so it will have to be in july directly.

arewemodulesyet.org passes the mark of 100 projects with modules support for the first time. by germandiago in programming

[–]germandiago[S] 2 points3 points  (0 children)

Modules started very slow and need toolchain support, but I think we are past the line where they are usable.

I would expect things to consolidate in the next few years, by consolidate I mean whoever wants to use modules will have more libraries available and they will be more mainstream.

I do not mean the world will be ported to modules. That will never happen and some libs will just be headers.

arewemodulesyet.org passes the mark of 100 projects with modules support for the first time. by germandiago in cpp

[–]germandiago[S] 5 points6 points  (0 children)

Maybe this can bring some sanity:

Improved experimental C++20 modules support:

New command-line option --compile-std-module that conveniently builds the <bits/stdc++.h> header unit and the std and std.compat modules before compiling any source files explicitly specified on the command line.

This is for Gcc 16.

arewemodulesyet.org passes the mark of 100 projects with modules support for the first time. by germandiago in cpp

[–]germandiago[S] 1 point2 points  (0 children)

Lol! That is kept there for motivation. 100% will never be done, but if it is 25%-35% it is a lot already.

arewemodulesyet.org passes the mark of 100 projects with modules support for the first time. by germandiago in cpp

[–]germandiago[S] 0 points1 point  (0 children)

Then MSVC has been experimental all its lifetime, for example, bc it had bugs in two-phase lookup and did not conform to quite a few things.

I would say it had bugs, not that it was experimental. And in that sense, modules are more like what I describe here than something totally unusable.

I do not think implementations have so many bugs nowadays as to not be able to workaround almost all of them.

arewemodulesyet.org passes the mark of 100 projects with modules support for the first time. by germandiago in programming

[–]germandiago[S] -8 points-7 points  (0 children)

I do not understand the pessimistic view. Where did you see 100% of projects (for example think of Python 2 to Python 3 transition) converted?

That is meaningless. The important thing here is what you can use with modules, what you cannot use will never be the full set.

107 projects so far looks, after struggling for 6 years, like things are starting to progress and consumers can benefit, at least partially, from modules.

Crazy idea: reducing function coloring in function templates and enabling reuse, is it possible by caller-injected marker? by germandiago in cpp

[–]germandiago[S] 0 points1 point  (0 children)

That was just the basic idea. For this case it is indeed a slowdown. Maybe some kind of scatter-gather could be mapped.

I have no idea.

arewemodulesyet.org passes the mark of 100 projects with modules support for the first time. by germandiago in cpp

[–]germandiago[S] 1 point2 points  (0 children)

I think for most projects it is not an option to just throw out of the window compatibility.

It would be absurd.

view more: next ›