nemetroid

\<i\>

How are any of these achieved by a vector-like type with capacity frozen at construction time?

Just poking fun - the ad is for a "composing machine", so the joke wrote itself.

From the last image:

No Type. No Distribution. No "Pie"-ing.

Self-spacing. Self-justifying.

Looks machine-composed.

The west, you mean?

Using '=' for both assignment and comparison is awkward when parsing incomplete code. Consider e.g.:

  j = 5;

  i = <|>
  j = 5;

  i = 0;
  j = 5;

Not common for showers, though. Those almost always have separate temperature and flow controls.

I read it and thought it contained several good ideas, but was excessively wordy and would have benefited from being half as long.

Why would I leave it open once I'm done with the task for which I opened the terminal?

Yes, many or even most domains where C++ sees a large market share are domains with no other serious alternative. But this is an indictment of C++ and not praise. What it tells us is that when there are other viable options, C++ is rarely chosen.

The number of such domains has gone down over time, and will probably continue to do so.

You can throw in a destructor but not from one, as the quoted text rightly notes.

Slop.

https://github.com/Cranot/tieredsort/blob/4091f66c31b4d2f8a1...

The new profiling.sampling module looks very neat, but I don't see any way to enable/disable the profiler from code. This greatly limits the usefulness, as I am often in control of the code itself but not how it is launched.

RHEL10 has been released and does require x86-64-v3.

https://access.redhat.com/solutions/7066628

Each entry in the map will be copied. In C++, const T& is allowed to bind to a temporary object (whose lifetime will be extended). So a new pair is implicitly constructed, and the reference binds to this object.

Close, it is a std::pair, but it differs in constness. Iterating a std::map<K, V> yields std::pair<const K, V>, so you have:

  std::pair<const std::string, int>

  std::pair<std::string, int>

Both Microsoft and Google seem to do it just fine

Microsoft sends me DMARC reports saying "yes, everything was accepted 100%, all good". The delivery logs on our end look good as well. However, they silently drop a large portion of messages with a Hotmail destination.

A nice way to fix bugs is to make the buggy state impossible to represent. In cases where a bug was caused by some fundamental flaw in the original design, a redesign might be the only way to feel reasonably confident about the fix.

You're right and I edited my comment.

The effect of referring to a copy of the object when locking, unlocking, or destroying it is undefined.

https://pubs.opengroup.org/onlinepubs/9699919799/functions/V...

I.e., if I pthread_mutex_init(&some_addr, ...), I cannot then copy the bits from some_addr to some_other_addr and then pthread_mutex_lock(&some_other_addr). Hence not movable.

Moving a mutex is otherwise non-sensical once the mutex is visible

What does "visible" mean here? In Rust, in any circumstance where a move is possible, there are no other references to that object, hence it is safe to move.

PLEASE mention INTERCAL!

Did you read the essay?

The article has an off-by-one error. There are 45 characters in the basic alphanumeric alphabet, and / is the missing one.

The tracks on the Gothenburg side have since been removed, so even this workaround would not be possible today (they would have to go to Trelleborg instead).

It is interesting though that when he mentions AI as one of the non-silver bullets, one of the arguments is that the AI models of the time were problem-specific and not easily transferable.

Not really if they only ever do it for small, personal workspaces.

By "western", do you mean American?

Same in Gothenburg. There's a single underground station, with the platform in the middle, so the trams need to cross over. Another underground station is planned, but it will have the tracks in the middle instead.

Maybe some preprocessing, maybe column generation, depends on the problem.

GCC 12 is available for RHEL 7.