The following is a conversation on this topic that Louis and I had on Slack, reproduced with his permission.
The question you're asking is whether we should have a feature test macro that tells whether the replaceable operator new/operator delete have a default (weak) definition in the library, correct?
And you're saying "There should not be such a feature-test macro, because implementing it requires the headers to have a lot of information related to the runtime they will be used for". Is that correct?
If so, one additional bit of information is that on Apple platforms, we do have sufficient information to know whether a default definition of these replaceable allocation functions is provided, because we build libc++ and libc++abi all at the same time.
ben.craig 10:42 AM
You've got the right idea, yes. And I agree, that for Apple platforms, you have sufficient information.
I'm thinking that for homegrown OS's, it will be a harder thing to figure out. Whoever builds the toolchain would need to supply that information, which works, but it's a little hostile. Supporting your own OS is a hostile thing though.
ldionne 10:43 AM
I'm not sure I follow.
Why would whoever builds the toolchain have to supply that information?
That assumes libc++ is part of the toolchain, right?
ben.craig 10:44 AM
the default implementation of libc++abi is going to try to get memory from malloc, and malloc may not be there
and there isn't a way for the compiler front end to ask "is malloc there", and there isn't a good way for <version> to ask "is malloc there"
but the person that builds the toolchain should know if malloc is there, and therefore, whether operator new is there
ldionne 10:46 AM
So, on our platform, we ship libc++ as part of the system.
Not the toolchain
ben.craig 10:47 AM
fair. Your toolchain knows what OS it is targeting though
ldionne 10:48 AM
Yes, but that's not the point I'm trying to make. Even regardless of any toolchain, libc++ knows what it provides when it's built for <name some OS>. For example, when I build libc++ for e.g. macos 10.15, I build libc++, libc++abi and the libc++ headers all at once. The headers I provide can, in theory, have different contents based on that.
So for example if I were to build libc++ for some internal freestanding implementation, I would be able to avoid defining the feature-test-macro for operator new in that build
Does that make sense?
ben.craig 10:49 AM
let me refine what I said earlier.
Whoever builds the ~toolchain~ _standard library and runtime_ would need to supply that information, which works, but it's a little hostile. Supporting your own OS is a hostile thing though.
ldionne 10:50 AM
Right. I don't see how it's really that hostile?
ben.craig 10:50 AM
It's not that bad. It's nicer when I don't have to set a bunch of flags and the headers can just figure it out on their own
but things like MUSL already require some manual configuration, so it's still workable
I can't just take some binaries that someone else built and use those. I have to build them myself.
ldionne 10:52 AM
Here's how I'd implement that hypothetically in libc++ (if we supported freestanding better than not at all):
1. Add a CMake option whether to provide the default definition for operator new
2. Based on that CMake option, include (or don't) the definitions in libc++.a/libc++abi.a
3. Based on that CMake option, define (or don't) the feature test macro
The headers installed in include/c++/v1 would literally be different based on that CMake option. Then, when I build libc++ for my special internal freestanding, I'd define the CMake option and be done with it.
I agree this means the headers on their own can't figure it out.
IOW we can't have one set of headers that is used on both (e.g.) macosx and the freestanding implementation. They need to be *differently configured* headers
ben.craig 10:54 AM
I think this was definitely the weaker point against having a feature test macro, and it's weak enough at this point that I'm tempted to remove it. Do you have opinions on the second point (lack of a good use case)?
ldionne 10:55 AM
No, I don't have a use case off the top of my head. I don't have an opinion either.
I just wanted to let you know that having a feature-test macro wasn't a problem as far as Apple platforms were concerned, because of the way we ship libc++/libc++abi. This might not hold true for other vendors.
My point is: I don't care which way you go, but if you decide to add a macro, we'll be able to implement it.
Maybe not trivially, but it's doable.
Also, feel free to report this conversation to the mailing list. I signed up and should be able to reply inline next time.