You said it's not useful for static data.

No. I said: "An example of "Safely Storing Static Data" that doesn't appear to declare any static data is pretty worthless."

You contradicted what you imagined I said, not what I actually said.

There are so many things wrong with that example it is hard to know where begin.

• The title of the section talks about "static data".

  In C, the keyword 'static' has a very particular meaning and purpose. It denotes both persistence and limited visiblity.

  Used within a function, the value of static variables persist between calls, but their visibility is restricted to that function.

  Used outside of a function, not only does it retain it value like any normal global, but also its visibility is restricted to the source file it is declared in. (Ie. It cannot be addressed from another source file using extern!)

  The macros in that example address neither property correctly.

  What the macros actually operate on is global (or in C terminology: external) data. Not static data.

  And BTW, your statement above that " It can't be both static and per-interpreter. is utter bollocks. Here you go:

  static int var[NO_OF_THREADS];
  [download]

  Per interpreter static integers.

  Which is essentially all those macros do, except they omit the 'static', meaning the potential for unintentional clashes between globals declared in different source files within the same compilation.

• But the main problem is that what the macros actually do is not explained.

  For example. The context key you have to declare is never used:

   * 1. #define MY_CXT_KEY to a unique string, e.g.
   *    "DynaLoader::_guts" XS_VERSION
   *    XXX in the current implementation, this string is ignored.
  [download]

  Which means that if you try to compile two files that each contain different MY_CXT declarations into a single binary, they conflict.

  All these macros do is abuse the pre-compiler to obscure and obfuscate what is a rudimentary and badly flawed implementation of a simple to understand and program technique for dealing with the issues of persistent data and threads.

You said "_" was invisible.

No. I said: "an almost invisible _".

Saying that , is less visible than _ does not contradict what I said -- saying that 0.00001 is smaller than 0.0001, doesn't make the latter not small -- it is just a puerile attempt to justify its use.

A justifiction that falls completely flat if you take syntax highlighting into consideration. Or a programmer's font.

You indicated the use of "a", "d" and "p" was problematic.

No. I said: "stupid, bordering on criminal".

Saying that it is done other places does not contradict the premise that it is bad practice. The fact that years ago, putting fizzy drinks and household chemicals in nearly identical bottles was normal practice, didn't make it a good idea which is why legislation prevents that in the modern world.

Again, not contradiction, just a justifiction.

1. So, you didn't contradict what I said, but what you thought I said.

   Contradiction isn't a valid argument form anyway.

2. Instead of just trying to help the OP, you try to make political capital from a documentation reference.

   I'll point out again. Had you posted your initial response to the OP and not me, this long and sorry sub-thread would not exist.

3. Please take special note of the very first sentence of my initial response to you: Personally, I found that example almost completely useless.

   Your opinion does not override, negate or change my opinion.

4. But most damning of all:

   You try to come across all superior, by taking the documentation as gospel and good, and quoting it verbatim, rather than actually thinking through the implications.

For all the good information that you've supplied me down the years -- much of it uniquely -- I'm sick of these pointless exchanges, so please stop responding to my posts.