u/DeGerlash

AFAIK this is still the case in the EXA series: they will all be identical craft. Anyone is free to start up their own manned drone racing series with their own rules though (although it may not be certified by Airspeeder)

Oh waw, I had no idea about this. This probably solves all of my use cases!
Thanks a bunch

i never heard of git submodule sync before, thanks.
What do you mean by relative URLs in .gitmodules? To specify the remote, I have to specify a (full) URL, no?

>  it automatically updates the remote URL of every repo if it changes based on the URL in the .gitdeps file.

This is a godsend indeed

Pretty cool that you developed your own fix. Looks like git-deps always tracks the latest commit on a remote though; have you never needed more stability on a submodule/dependency? Some of our submodules evolve quickly, and git-submodule's ability to track a specific commit until we're ready to upgrade to the latest version has been super useful in the past. It seems like git-deps forces you into either immediate adoption of API changes, or API stability for the dependency. Has that been an issue?

1. I don't mean that `git pull` should trigger a pull in all submodules. That would be undesirable indeed. I mean that `git pull` should imply `git submodule update`, because that's expected behavior: if a certain top-level commit changes the tracked submodule commit, I would expect everyone's repository state to be consistent (i.e. tracking that new submodule commit) after pulling that top-level commit. Just like with every other git-tracked file/resource

2. Fast-forward merge is indeed ideal for the perfect case, where there are no conflicts. If you are collaboratively working on a feature branch however, and the fast-forward merge fails with conflicts; do you accept a merge commit?

3. I don't think I made it clear enough what I meant here; I am specifically talking about the .gitmodules file, and how it both forces you to hardcode an authentication type for the submodule remote, and does not update the cached remote when changed. Both of these are annoying and unnecessary imo. Thoughts on this?

Post may have been unclear; I mean that `git pull` should imply `git submodule update`. _Not_ that it should imply `cd submodule; git pull`. The latter is indeed insane, but the former is expected behavior imo.

I'm using submodules to track source dependencies that other projects also depend on. Every so often, we need to a new feature or bugfix to the dependency, which will be welcomed by all users that include this dependency as a submodule. Whenever they want, they can update to this new version by tracking a new commit in their submodule. However, anyone else pulling from those top-level repos will not receive the updated submodule automatically; they have to run git submodule update themselves after pulling

Ah, I see I've misread the original comment. Apologies

The run time context doesn't matter. A standards-conforming compiler is allowed to detect that the ISR is never called from within some event loop, assume that the flag cannot be written inside the loop, and optimize based on that. Volatile is intended to notify the compiler that it shouldn't try to be so smart, and reload the variable from memory anyway.

UB doesn't care about the execution context, in part because a lot of UB is already capitalized on in the compiler.

The optimization I mention might be unlikely to be performed in practice, given external code being called from inside the loop etc., but that doesn't make it not UB. Volatile is a complicated qualifier, but one of the purposes it has today is to prevent this exact optimization in the face of ISRs/signal handlers.

It's always UB when a non-atomic, non-volatile flag is used for synchronization.

Flutter. Many advantages, but Dart is just a great language, too

AFAIK, it's only UB in C++, C should be fine. Except if the fact that T is a struct changes things, or if I'm overestimating the layout guarantees for bitfields in structs.

Flutter for desktop is a great alternative these days. Entirely cross-platform, great & familiar language (Dart), and can easily be turned into a mobile or web app later if needed.

Nitpick: it is not a race condition that is undefined behavior, but rather the data race

Guaranteed to be 1 by C standard. But I'm also not against putting it explicitly to communicate type info.

Belgium recently passed a law that protect these people legally under some conditions!

Tbh often times, if your constructor doesn't necessarily have to run at the very start of the program, but simply before some operation you control gets executed, I find the singleton pattern to be much more flexible and high level.

Especially when you have multiple of these functions that need to run in a certain order, it's much easier to let C++ constructors call each other than to use the GNU attributes.

Common issue. Translation units get discarded as a whole by some linkers if nothing references any of their functions. Unfortunately, the linker does not consider the fact that some functions are constructor functions when doing this.

My typical workaround is to add an empty function in the TU containing the constructor function, and call empty function that from at least one other function in another TU whose symbols definitely get referenced (will not be discarded).

Do not include any of the bits/ headers directly. Errors can rise and fall depending on platform and compiler version when doing that.

Probably because the test for zero can either be done implicitly, or one of the registers is hardwired to be 0, so you don't have to zero a GPR just to compare with it.

Entirely uneducated guess though, never programmed ARM.

Vind niet dat het hoger onderwijs systeem van schuivende vakken naar het middelbaar zou moeten komen. Ik vermoed dat je het vooral over het ASO hebt, aangezien in het TSO en BSO de vakken minder uiteenlopend zijn, en deze situatie allicht minder voorkomt. Vind het belangrijk dat iemand in het ASO elk jaar opnieuw geëvalueerd wordt op de vaardigheid om het brede gamma aan algemene kennis tegelijk te kunnen verwerken, en op alle vakken te kunnen slagen. Iemand die een bepaalde subset van de opleiding prioritiseert tot op het punt dat de kennis rest van het aanbod simpelweg onvoldoende is, heeft wat mij betreft de doeleinden niet gehaald om verder vooruit te gaan in de opleiding.

Daarnaast zijn er ook meer praktische problemen: schuivende vakken leggen enorme druk op lessenroosters, die nu al een hel om op te stellen zijn. In het hoger onderwijs leidt dat vaak tot overlappende uren voor studenten, wat moeilijk te verantwoorden valt in het middelbaar onderwijs. Daarnaast pedagogische argumenten over integratie in een klasgroep; wanneer je een volledig jaar opnieuw doet zit je tenminste terug in een stabiele groep voor elk lesuur.

Die competentieplicht lijkt me wel een goed idee, is dat dan gelijkaardig aan de centrale examencomissie nu?

I would argue that a chain of sequentially evaluated predicates is indeed a flat control flow hierarchy, and the allowance of most programming language to express 'elif'-like constructs helps to express that in source code.

Now, to the compiler, it's obviously still a nested hierarchy, I agree. But a 'match'-like construct that evaluates predicates in its different cases is also just a nested control flow hierarchy to the compiler (just a series of sequentially tested predicates). So it's really just a syntax issue.

From my perspective, an elif construct more clearly communicates the common understanding to the programmer that these statements will compile to a sequence of conditional evaluations, whereas some switch-like construct may mislead programmers without compiler background to thing it's more efficient for large sets of cases. So I would argue the opposite point: the equivalent 'match'-like statement gives the illusion of a flat hierarchy for what is really a nested hierarchy. But that's already a very subjective argument.

In any case, good luck with your design and with the progress of the language!

Others have given some nice examples about constructs that allow you to ban else-if-chains while maintaining consistent syntax, but I wonder why you consider them a code smell?

I use them very extensively in my own code, and don't particularly see a problem: the compiler optimizes them out to a switch statement if appropriate? So this would be more of a syntax thing, but even then: what's the problem with it?

Sometimes you're refactoring code quickly, and want to focus on real warnings you're introducing while suppressing temporary ones like this.

Other times this can be generated from a macro that is conditionally defined as a void cast to avoid this warning if its input would otherwise be unused

Other times this can be a function argument that you don't need (e.g. callback signature). There's many options