you can totally build an intrusive container/refcounter/etc. using just composition

Fair enough. What I should have said was that an unintrusive container would be less hassle to maintain and more likely to be useful for reuse in the future.

I don't quite get the whole ECS stuff anyway

Easier to give power to scripters and to maintain (you can rewrite a component as a new version and then swap it out with the old version without shutting everything down). IIRC this was popularized by MMOs, where those kinds of things outweigh everything else.

I don't quite get the whole ECS stuff anyway

Easier to give power to scripters and to maintain (you can rewrite a component as a new version and then swap it out with the old version without shutting everything down). IIRC this was popularized by MMOs, where those kinds of things outweigh everything else.

maybe there's a better way to handle linear polymorphic iteration that I don't know about

You get those same ability with regular, plain, no framework required, composition.

Isn't ECS just composition ad absurdum? It seems like every time I talk to people about ECS the boundaries of its definition are different. -.- My impression was that ECS is a system where new types of component can be created and injected, and entities are just clumps of various components constructed at runtime by data.

Nope. It was someone who claimed it would be the future of MMOs. I've worked on MMOs for most of the 10 years since that blog post was written and I've not seen or heard of a single one use a component-based architecture, never mind the extreme component/entity/system separation that blog talks about.

Nice. I'll extend my procrastination about messing with it.

Composition is a feature of almost every language and the core pillar of OO (and ecs, with limits...)

An "Entity/Component/System framework" (abbreviated as ECS) means:
Entities are nothing, but can compose components into themselves.
Components are data structures that are banned from using composition themselves, but they may link to entities.
Systems contain logic that operates on specific components.

Note that this is different to an "Entity/Component framework" (often called an "Entity/Component system" as system/framework are interchangeable)... So if you're building an Entity/Component system, that is a different thing to building an Entity/Component/System system!
These is a much more vague term, but is usually the same thing but with Components and Systems being rolled together, and overall less dogma. There's usually still the same restriction that entities may make use of composition while components are banned.

Often EC-frameworks are made to mesh well with OOP, while ECS-frameworks are closer to relational database systems or procedural programming.

Common features of both kinds of framework include:
* the component members of an entity being identified only by their type, instead of name as in OOP.
* often a restriction that an entity cannot contain two instances of a single component type.
* the ability to find components by type, and to query the parent entity of a component to find sibling components by type.
* a data driven template/prototype system, that allows entity "classes" to be created from data files.

As a fun straw-man exercise... :D
To an OO programmer, adding ECS dogma to your coding style while remaining on OO land would be similar to this:
* Classes must be commented as an Entity type or Component type.
* Classes labelled as Component can only contain primitive types, or pointers to an Entity type class.
* Classes labelled as Entity can only contain pointers to Component type classes.
* Classes labelled as Entity must name their members the same as those member types - and as a consequence, there cannot be two members of the same type.
* No class may contain member functions or any logic.
e.g.

struct Health { float hit_points; }; // component
struct PoisonSpell { Player* target; float time_left; }; // component
class Player // entity
{
  Health* _Health;
  PoisonSpell* _PoisonSpell;
};
void PoisonSystem( float dt, Player* begin, Player* end )//system
{
  for( Player* p = begin; p != end; ++p )
  {
    PoisonSpell* s = p->_PoisonSpell;
    if( !s )
      continue;
    s->time_left -= dt;
    if( s->time_left <= 0 || !s->target )
    {
      p->_PoisonSpell = 0;
      delete s;
    }
    Health* h = s->target->_Health;
    if( h )
      h->hit_points -= dt;
  }
}

Sure that's a valid style that you can choose to program in, and by default in C++ it's not at all dynamic (my entity definition above is static code)... so if you like this style you would either have to build a big ECS framework to actually allow dynamic entity descriptions, or just use another language like Lua where you could write in this style natively without the need to build a framework at all! Personally, I'm a fan of doing the latter -- write code that's idiomatic to he language and forgo large frameworks of any kind.

I have read that there are some obscure custom compilers for things like DSPs and microcontrollers that don't support it

That isn't the real problem with them. The main problem is that they just don't work the way most people think they do, and it's fairly trivial to break them in larger build systems.

And part of _that_ problem is that pragma once is not well-defined. Namely, how does the compiler decide that a header has already been included? Is it the file's inode? Relative path name? Absolute path name (including symlinks? multiple mount points? etc.) ? What about a file that is accessed through two separate paths that go through two separate virtual filesystems (like an NFS mount to the localhost and the direct local path? yes, there are systems setup like this, and can be relevant to games on Linux-based CI systems). This also comes up on some weirder systems (not relevant to games) that don't have directory structures similar to the POSIX/Win32 model.

Basically, it's impossible to make pragma once work reliably the way people expect. There simple isn't a way to uniquely identify a file across all possible file systems, platforms, and weird things some platforms can do with reparse or mount points or network filesystems and so on.

The compiler differences do come up. For instance, porting code between GCC and MSVC when using precompiled headers on both can be a little tricky specifically because of the different rules each have surrounding #pragma once. Those differing rules also make it impossible to standardize, since if it were then one or the other would be required to change behavior and break existing code.

There are active official proposals to include #pragma once or a variant #once in the C++ standard. If they are accepted they would like use the #pragma once version because of the existing universal support.

#pragma once will never be standardized since it is inherently broken as described above.

The #once proposal is basically just a syntactic shortcut to include guards: the #once syntax requires an additional token (just like an include guard) to identify the file which is intended to be unique (though it could be used to ensure that only one of a particular set of files is included by sharing the identifier between them). "#once foo" essentially just wraps the file contents in "#ifndef FOO #define FOO #endif".

And even that's super unlikely, because Modules will kind of make traditional headers obsolete anyway.

... all that said, I just use #pragma once myself. :p