Most new features of C++ are introduced to fix problems created by previously new features added to C++.

Constexpr and consteval are hacks that 1) should have just been the default, and 2) shouldn't even be on the function definition, it should instead have been a keyword on the usage site: (and just use const)

  int f() { ... } // any old regular function
  const int x = f(); // this is always get evaluated at compile time, (or if it can't, then fail to compile)
  int y = f(); // this is evaulated at runtime

    const int x = f(); // this is always get evaluated at compile time, (or if it can't, then fail to compile)

    void foo(int x) {
        const int y = bar(x);
    }

So you respond "well, I didn't mean THAT kind of const, you should have a different word for compile-time constants and run-time non-mutability!" Congratulations, you just invented constexpr.

There are many bad things about C++, but constexpr ain't one of them.

The issue is, not everything can be done at compile time, and so “I can use this at compile time” becomes part of the signature because you want to ensure that it will continue to be able to be used that way. Without it, changes in your function could easily break your callers.

This isn't about "oops, I didn't mean to mutate that." This is about rapidly being able to reason about the correctness of some code that is leveraging const-qualified code.

I can't count the number of times I've seen someone new to the language use map::operator[] without realizing that it's a mutating operation.

    for (const auto &thing: collection) {
        counts[thing]++;
    }

Another popular use case is something along the lines of:

    std::unique_ptr<T>& ptr = ptrs[key];
    if (ptr != nullptr) {
      ptr = std::make_unique<T>(...);
    }

Maybe it's not a concern in C-family languages, but rust's culture of defaulting to let and only using mut when it's specifically required does feel very pleasant and ergonomic when I'm in that headspace.

to me, pretty much a few times per week at least

Move constructors are not needed, they don't solve a 'problem', but improve on previous semantics.

    for (const auto item: vec) { ... }

It's been so long since I used C++ for serious work that we weren't using C++11, so neither auto nor range-for were available. It would be uncommon to see "const type = " with a non-reference type and a non-constant initialiser.

Even with your example, some styles avoid "const auto item", using either "auto item" or "const auto& item" instead, because the "const" matters when taking a reference, not so much with a copy.

But I appreciate your point applies to const variables with non-constant initialisers in general, in the language.

There was once a big deal in literature about const in C++ being the "better" alternative to how #define is commonly used with C for constant values, and it seemed applicable to the thread as a key distinction between C and C++, which the parent commenter seemed to have conflated by mistake.

But I'd forgotten about const (non-reference) variables accepting non-constant initialisers, and as I hadn't used C++ seriously in a while, and the language is always changing, I checked in with a couple of C++ tutorials before writing. Unfortunately those tutorials were misleading or too simple, as both tutoruals said nothing about "const type x = " (non-reference/pointer) being uwed in any other way than for defining compile-time constants.

It's bit embarrssing, as I read other parts of the C++ standard quite often despite not using it much these days. (I'm into compiler guts, atomics, memory models, code analysis, portability issues, etc.). Yet I had forgotten this part of the language.

So, thanks for sending me down a learning & reminder rabbit-hole and correcting my error :-)

Constexpr and auto have nothing to do with macros.

The older version is being improved, especially for ergonomics. Regarding your examples, ranges do not obsolete iterators, they are just a convenient way to pass around iterator pairs, but actual range are better implemented in terms of iterators when they are not just a composition of ranges. Similarly move semantics has little to do with nrvo (and in fact using move often is suboptimal as it inhibits nrvo).

Again, I have no idea how constexpr and auto have anything to do with macros.

Concepts fix implicit template requirements

> What about ranges?

Fix the bad iterators

> Auto

Fix the the overly long type names

> Move semantics

This is mostly necessary because of excessive copies that cpp does

> Consteval

Fix cases where constexpr couldn't do it at comptime

Move is fixing the problem of unnecessary mass-construction when you pass around containers.

std::ranges was introduced because dear fucking god the syntax for iterating over a partial container. (And the endless off-by-one errors)

concepts, among other things, fix (sorta) the utter shit show that templates brought to error messages, as well as debacles like SFINAE and std::enable_if.

You're right. They're not fixing problems created by previous features. They're all fixing problems created or made massively worse by templates.

This is very similar to dependency injection. Separating state and construction from function or method implementation makes things a lot easier to test. In my opinion it's also easier to comprehend what the code actually does.

You have clear tracking of when and how functions change the global variable

For non-web work genservers in Elixir have immutable state that is passed to every handler. This is "local" global state and since genservers guarantee ordering of requests via the mailbox handlers can update state also by returning a new state value and you never have race conditions.

I wrote a better article on globals. I plan on posting it next week

With that said, it seems obvious that if you want to globally count the calls, then that count shouldn’t live in an argument where you (the function) don’t control its lifetime or how global it actually is. Simple has no say over what object obj.counter points to, it could trivially be a value type passed into that particular call, so if you know you want a global count then of course storing it in the argument is the wrong choice.

Global has two conflated meanings: global lifetime (ie lifetime of the whole program) and global access (which the article states). Simple needs global lifetime but not global access.

You rarely ”need” global access, although for things like a logger it can be convenient. Often you do need global lifetime.

If I have 500 functions, I don't want to extrapolate out the overhead of passing a state object around to all of them. That's a waste of effort, and frankly makes me think you want to code using an FP paradigm even in imperative languages.

Module-level and thread-level "globals" are fine. You gain nothing (other than some smug ivory tower sense of superiority) by making your functions pure and passing around a global state object to every single method invocation.

You also get explicit dependencies and scoping controlled by caller.

I don't mind globals but saying you get nothing for avoiding them is :/

Advantage only the function that depends on the global needs to bring in the dependency.

(To be clear, I’m just tangentially ranting about the state of things in general, might as well post this under somewhere else.)

I said we should either abolish the thread-local variables or not use coroutines, but they said "we don't want to pass so many parameters around" and "coroutines are the modern paradigm in Kotlin", so no dice.

Encapsulation. Provide methods for state manipulation that keep the application state in a known good configuration. App level, module level or thread level.

Use your test harness to control this state.

If you take a step back I think you’ll realize it’s six of one, half dozen of the other. Except this way doesn’t require manually passing an object into every function in your codebase.

Hiding state like that is IMHO just a recipe for disaster. Sure, if you just use global state for metrics or something, it may not be a big deal, but to use it for important business-critical code... no, please pass it around, so I can see at a glance (and with help from my compiler) which parts of the code need what kind of information.

Surely if you can mutate a state object and pass it, its state can get mutated equally deep within the codebase no different than a global, no?

What am I missing here? To me this just sounds like a discipline issue rather than a semantic one.

Using an explicit parameter obviates the need for discipline since you can mechanically trace where the value was set. In contrast, global values can lead to action at a distance via implicit value changes.

For example, if you have two separate functions in the same thread, one can implicitly change a value used by the other if it's thread-local, but you can't do that if the value is passed via a parameter.

A few posts up I clearly said use encapsulation and then mutate state via known methods. These would be just as traceable in your IDE/debugger.

Further, I have also repeatedly mentioned both module-level and thread-level "globals".

And I understand how concurrency works.

Take care.

A debugger can trace a single execution of your program at runtime. It can't statically verify properties of your program.

If you pass state to your functions explicitly instead of looking it up implicitly, even in dynamically typed languages there are linters that can tell you that you've forgot to set some state (and in statically typed languages, it wouldn't even compile).

Yes, that's one reason why shared mutable state should IMHO be kept to a minimum and immutable objects/structs should be preferred.

  // this function will implicitly look up the tenant from some global context
  fun createUser(username: String, password: String)

  fun createUser(username: String, password: String, tenant: Tenant)

The second one is almost impossible to accidentally misuse, the first one can lead to all sorts of weird bugs.

If your global state contains something that runs in prod but should not run in a testing environment (e.g. a database connection), your global variable based code is now untestable.

Dependency Injection is popular for a very good reason.

If you have something that should only run in testing, perhaps your test harness should set the global variable appropriately, no?

I agree that so long as overall complexity is limited these things can be OK. As soon as you're reading and writing a global in multiple locations though I would be extremely, extremely wary.

This:

"You gain nothing (other than some smug ivory tower sense of superiority) by making your functions pure and passing around a global state object to every single method invocation."

...is neither productive nor actually true. But I'll save the latter part for your other reply.

I'm not above being put in my place and being shown the light.

(And when I said OP, I did mean the parent poster)

You should also understand that the "you" in my comment you quoted is the colloquial you and not necessarily the parent poster.

So lay it on me.

But I also got a notification about a big comment you posted but it is now deleted. Did you want to rewrite it or did you give up on it?

It's also helpful to give you time to re-read a mostly good, but maybe not polite, response and tone down your response.

So indeed, let's re-focus and re-engage.

To that end, I will post you a longer reply Later™.

Although Perl 5 has a nice feature where all global variables can automatically be treated this way by using a "local" keyword. It makes the global variables almost useful, and in my experience, makes people accidentally splattering globals around do a lot less damage than they otherwise would because they don't have to make explicit provision for scoped values. I don't miss many features from Perl but this is on the short list.

Much worse is protecting concurrent writes, eg to an object or hash table

I was under the impression that many people here were discussing the usage of global variables more generally, though.

> The final optimization notices that q is never written to, so we can replace q[0] by its initial value 0.

However the line right above is

    *(p+1) = 10;

Therefore, the assumption that p[0] does not change and can be swapped out is not somehow surprisingly wrong, but simply entirely unfounded.

It is up to the compiler to prove for itself that assignment through pointers does not change data it's interested in from before to after the assignment. (except, of course, in the case of restrict pointers, where the programmer makes this guarantee). This is not very difficult, at least conceptually.

If the assignment was

    *p = 10;

In the case of the first assignment, we know that *(p+1) means p[1], which is out of bounds for the array. So we do not know whether or not an assignment through *(p+1) modifies q, and we can not assume it does not.

>Since q and p point to different local variables, a pointer derived from p cannot alias q[0], and hence we know that this write cannot affect the value stored at q[0].

Pointer math outside the array bounds isn't defined, so it can be treated as anything, including "cannot possibly do X, so we can optimize it out". A compiler that preferred to spend memory to improve correctness (e.g. Valgrind) might add padding between variables to prevent this kind of small-OOB action, which would make the output change again, which is why this is undefined and you can't rely on it. A compiler that was feeling moody could put that array at the end of your page of addressable memory, and cause a segfault when you try to write to it.

The problem is that pointers of the same type to the same address but originating from pointer arithmetic on the pointers obtained by dereferencing different objects have different semantics.

In other words, the following is not semantically a NOP.

    char *p = /*some valid pointer*/;
    {
        char x;
        char *q = &x;
        while ((uintptr_t) q != (uintptr_t) p)
            q++;
        p = q;
    }

You can find some languages that try to adhere to that, but C is extremely clearly not part of that group. It never has been, and it never will be.

It's like you're supposed to cross an enemies' minefield, with the enemy laying ever more mines in your path and yet you're supposed to walk through the minefield and hope for the best.

You'd have thought that C programmers have the best tools and techniques to avoid UB by now, so that UB would be a non-issue, a relic of the past that people remember suffering from in the 90s.

Out of bounds access is classic UB. The compiler is allowed to assume that you never access an array out of bounds. Since you never access p out of bounds, the effects of any write to p will not affect any "object" that is not p.

>Therefore, the assumption that p[0] does not change and can be swapped out is not somehow surprisingly wrong, but simply entirely unfounded.

I hope you notice your small mistake. It's print(q[0]), not print(p[0]), there is no "p" in the print. It's q[0] and q[0] is not p. The write to p did not affect q, because that would be UB.

>It is up to the compiler to prove for itself that assignment through pointers does not change data it's interested in from before to after the assignment. (except, of course, in the case of restrict pointers, where the programmer makes this guarantee). This is not very difficult, at least conceptually.

The code accesses q[0], not iq. You might say that if you did print(*iq), that the compiler should definitively know that iq and ip are the same and therefore a write to ip would also be a write to iq, but the code uses q[0], which is a memory address that is not proven to be identical to ip.

Then again, what you're hoping for here is that the compiler fixes the UB for you, which is not the point of UB. You're supposed to rely on your godly C programmer instincts to never write code with UB in the first place.

Most people agree that the right solution is that the integer-round trips can not simply be assumed to be a no-op and has the effect that the recreated pointer can be used to point to the other object (as proposed by us in TS 6010). (So in this sense you are right). The LLVM maintainer stated recently that they are going to fix this.

In this context, you means the author of a program written in Standard C. Implementations can choose to allow this (and in practice all do, because of the nature of pointers). And obviously, a code transformer for a particular implementation of C would only need to generate code valid for that implementation of C, not valid Standard C code.

I haven't had as much time as I would have liked to play around with Zig. But, it seems like Zig is like C, but with much stronger static checks, much less UB, lots of useful syntactic sugar, an anti-global agenda (explicitly passed allocator in Zig vs strtok in C) etc. And, truthfully, I really like this.

If we can move from a C/C++/Java world to a Zig/Rust/Go world, I would view that as an absolute win.

As for C++, my experience is that templates can help produce some things in a type safe way that you later tend to regret and understand you should have never produced in the first place :-)

Just created some custom closure producing code that takes a pointer to any function along with arguments. The arguments get stored in custom allocations and can be applied to the function at any later point. Creating the template code is quite painful and probably none of my teammates will be able to maintain it. On the flipside, closures like this might be the right API for the use case.

(The downside is that there's no template parameter inference, but I'm pretty sure that this is one of those things that Zig would avoid by design anyway.)

It is the almost safe path we could have taken if the likes of Modula-2 and Object Pascal, among others, had stayed in the mainstream.

https://www.dreamsongs.com/RiseOfWorseIsBetter.html

The article compares the Unix/C philosophy with the Lisp philosophy and concludes that Lisp is "better" (it is The Right Thing), but that Unix/C will probably end up dominating. Obviously, he was right.

The article is pretty famous around the suckless, minimalist, crowd. But I think everyone who reads it takes a slightly wrong lesson from that article. The point isn't that Unix/C won because it was simple. The point is that Unix/C was simple enough to use, simple enough to implement on most available hardware and that it did everything you needed it to do.

The minimalist people have turned software simplicity into the modern version of The Right Thing, and are surprised when they found out that the "worse" (more complex) thing wins. But The Right Thing will never win. The Good Enough always wins.

Is Linux better than *BSD? Well *BSDs are more simple, easier to understand and reason about etc. But, at least OpenBSD, doesn't have mount --bind, so I can't use it. Case closed. And I think that's the case for most people. Linux has thing X which I need so I will use Linux, even if ideologically *BSD is imo better.

Is D-Bus The Right Thing? No; but it is The Good Enough. polkit, selinux, ACLs, and so on.

The most recent example I can think of is Hyprland. It is basically the only viable Wayland window manager (aside from sway). Not because it is the best designed or the simplest, or anything like that. But simply because it is the only one Good Enough to use.

SystemV init was not good enough for complex service management. systemd is. systemd simply does everything you need it to do well enough. So systemd wins. Simple as. It will only be replaced when it is no longer Good Enough.

Something like Wine, where in the analogy systemd is the Microsoft Win32 API and we want to be able to run systemd "enabled" software on something else. Or at least re-compile it.

Wine also started with an incredible amount of stubs which did nothing, but that was often enough for many programs to work anyway.

We've seen the launch of GNU's systemd equivalent, which seems to introduce more complexity to the simplest levels and is more difficult for users to understand and configure. Given that every service file is its own erlang program/DSL/whatever, understanding erlang is critical to being able to write or reason about service files.

In essence, it seems to be trying to re-implement what systemd does, but badly.

Reimplementing systemd's API but using other discrete components would also be a bad idea. The biggest reason systemd took off is that it's all the tools a system needs, built in a way that they work well together and can be interacted with and configured consistently. Providing systemd-compatible replacement shim APIs would mean trying to tie a dozen (or more) discrete OSS projects, each with their own philosophies, developers, licenses, goals, etc. together, generating their config files consistently, and trying to mush all that together in a way that doesn't make things vastly more complex than what systemd already provides.

In short: the reason systemd is successful is that it got rid of a giant mess of unrelated or overlapping services and replaced it with something simple, coherent, and functional, built out of components that you can (in most cases) choose to use or not. Most people who hate systemd seem to hate it for largely ideological reasons ("it's too big!") and are more interested in solving those ideological problems at the expense of practical solutions to real user issues. I've yet to see someone argue against systemd because it's bad for end users; only because they don't like the way that it provides benefits for users.

Shim out enough for it to at least run in some capacity on something which does not have systemd.

Go from there.

The amount of work that a project would require over the long-term would be pretty substantial, so I assume that there are a lot of these things which you would suggest fixing over time to be rid of systemd, but I'm not certain what the end benefit of this work would be. Interested to hear more.

(Now, the importance of portability is a separate question. If you want systemd to "eat the world" it's even a negative value.)

1: https://wiki.gentoo.org/wiki/Hard_dependencies_on_systemd

The most prominent dependency on systemd components is Gnome on logind, which already has a shim.

The problem is that if the only complaint with systemd is that it's too complex, any backwards compatible alternative will necessarily be as complex as systemd + the new thing (at least in terms of complexity of interface).

If there are actual technical deficiencies of systemd, then sure, maybe such a backwards compatible alternative might be in order.

Also, everything expands in time. Wine may have started out with many stubs, but now we're at the point of implementing Windows-y APIs in the kernel with the sole goal of improving wine performance (NTSYNC).

As I understand it, that isn't the only, nor even the main, complaint with systemd. On the contrary, the main complaint with systemd is that, like strangler vine (kudzu?), it's spreading everywhere, taking over functions that it originally had nothing to do with, and forcing ever more unrelated things to adapt to systemd -- thereby making them much less portable away from systemd; to something that doesn't use it.

It's like the old debate about "BTW, you should call it GNU/Linux, because..." is sooo yesterday: Nowadays it's systemd/Linux -- and well on its way to becoming systemd-OS, with the kernel a mere afterthought, soon to be if not replaced at least easily replacable. Sure, that may not bother you or most systemd fans, but one can't help wonder: Do you even realise that this is what you're condoning, or even actively advocating? Maybe it would bother you, if you realised it.

(Also, the whole "strangler vine" thing, when deliberately applied, used to have a name: "Embrace, Extend, Extinguish". Now, I can't really swear that it is being deliberately applied here... But do we really dare to blithely assume it's just a coincidence that the creator of systemd so naturally found a home at the company the expression was coined for?)

As for SystemV... as I mentioned in another comment - in hindsight, that was not the issue. There were and are SystemV alternatives [1]. One can even write one that uses D-Bus in an opt-in fashion, to foster other facilities' use of it.

The init system excuse is very much like the stone in the fable of the stone soup: https://en.wikipedia.org/wiki/Stone_Soup - it's what gets the vagabond's foot in the door, and is the first ingredient for the soup. But actually, the stone carried no significance, and the resulting soup is pretty much the same thing as without the stone part.

[1] : ruint, OpenRC, launchd, s6, nosh, finit, procd, upstart etc. See brief description and links at https://alternativeto.net/software/sysvinit/ for example.

and one more thing about that: For PC users and "vanilla" machine setups - sysvinit, weirdly, still works fine. Startup is quick, and developers don't live in pain making it work. Of course it is kind of lame design-wise, but it's not even that we just _had_ to replace it - we've still not reached even that point.

I'd wager the vast majority of (non-embedded / single-purpose) Wayland deployments are gnome and KDE.

Part of the problem with all of them is less the wm and more knowing what parts you need. Not so much bars as portals. I'm vaguely surprised hyprland doesn't have a "good enough" batteries included config and documentation.

You simply install everything from the "Must-Have" page, then go through the other pages and install everything you want and by the end you have a complete and functional desktop. For every component, there is a good description of how to use it in Hyprland.

I simply followed that guide, remapped some shortcuts, copied some guy's waybar config from GitHub, and, well, did little else, and had a perfectly functional Hyprland desktop that I used virtually unchanged for ~six months.

Only recently got into ricing it more, and only to the extent that now all my components (app launcher, notification manager, waybar etc.) use the same color theme.

[1]: https://wiki.hyprland.org/Useful-Utilities/

This is the best system we have found to establish the impermanence of the elite class. Because this is the real beauty of what we in the west call democracy: not the absence of an elite class, for there is no such system, but it's impermanence.

And while that is all well and good within a country, the argument is that it would be unwise to allow a foreign hostile power a seat at our propaganda game. Especially one which does not reciprocate this permission.

I guess more than anything I'm just surprised that it's the "threat to democracy" crowd that would be taking such a cynical view of democracy. They're admitting that Trump's propaganda was just better than theirs. Which is, in some ways, hilarious.

I've used mk in the past, but asking users to install Plan 9 from User Space is a big ask :). A rust program they can just build with cargo feels a lot better.

Questions:

* is there a way to pass arguments, such as CC etc. to werk. will config or let skip past the first assignment if there is an environment variable defined with the same name? or how do i get my config to werk without editing the werkfile

* does the depfile rule get called if the depfile already exists? if so, what are the performance implications of this? if not, what happens when I include a new header in a file and the dependencies change?

I can spend hours upon hours on a Discord call discussion whatever, working on a collaborative project etc. But every second I have to spend on a video call looking at myself drains my soul.

I get it if it's some investor meeting or whatever, but if it's a call for a team where we all know each other, what's the point?

The day I realised this, was the day 75% of my zoom fatigue disappeared.

I find that a lot of people who say they turn their camera off say they do it because they don't like watching themselves on screen, and don't realise this is optional. Personally I think all the video call systems should turn it off by default, I've never understood what purpose seeing yourself all the time is supposed to have. It would be like having a meeting room full of mirrors.

Either way, it would be nice if they put a bit more effort into these things. Video calling could be much nicer for a lot of people with a little bit of effort.

It shocks me every time just how fast Chrome is. It is legitimately a superb piece of software. Going to Librewolf after feels like going back ten years in hardware.

Can we please start spending some money to make Firefox better? Instead of whatever Mozilla is currently doing?

Firefox Quantum was great. But why stop? Just keep doing that! It's the only thing you should be doing!

uBlock Origin on both (wouldn't browse the web without it). Vimium and Dark Reader on Librewolf. But turning Dark Reader off does speed it up by _a lot_.

Chrome still seems faster but now they're both playing in the same league.

Never thought about it.