[SERVER-47912] add MONGO_CONCEPTS_ macro prefix Created: 03/May/20 Updated: 06/Dec/22 Resolved: 23/Jun/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Internal Code |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Billy Donahue | Assignee: | Backlog - Service Architecture |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Service Arch
|
||||||||
| Participants: | |||||||||
| Description |
|
The src/mongo/util/concepts.h header defines a set of 4 macros:
Change these to
An examination of the sites that use these names shows they can afford the extra space. TEMPLATE and REQUIRES are single common words that are overloaded to mean various unrelated things. Google uses REQUIRES annotations to enforce lock ordering, and even has its own #define REQUIRES in the vendored benchmark library, which I'm in the process of upgrading. It would be clearer and safer if Mongo's Concepts macros were renamed with a MONGO_CONCEPTS_* prefix. I thought of this when I saw that the Catch framework uses a REQUIRE macro, which is almost but not quite a collision with our REQUIRES macro. It's a close call. In Catch (which has been tossed around as a possibility for us |
| Comments |
| Comment by Billy Donahue [ 17/Jun/20 ] |
|
Fine by me! |
| Comment by Mira Carey [ 16/Jun/20 ] |
|
I've filed |
| Comment by Ratika Gandhi [ 16/Jun/20 ] |
|
billy.donahue any objections to closing this ticket? |
| Comment by Mira Carey [ 16/Jun/20 ] |
|
My take on this one is that these macros solve a transitional problem (specifically a lack of concepts support in our toolchain). Once we get to C++20, we won't need these (at least TEMPLATE/REQUIRES). We also don't make a special effort to enforce macro hygiene in general, for better or worse. If we don't have a pressing need for this now, I'd like to close this out and expect that we'll be able to dump the majority of these macros as part of converting to C++20 |
| Comment by Billy Donahue [ 03/May/20 ] |