c929ab49b9
This is a reland of commit ccc87ea3c625e43ab138e00ba2ef1a2d99756199 Downstream project has been updated. Original change's description: > [Stats] Remove enum-like structs in favor of strings. > > Due to a limitation of RTCStatsMember<T> not supporting enums, as well > as the fact that in JavaScript enums are represented as basic strings, > the stats enums have always been represented by T=std::string. > > Now that we have WebIDL-ified[1] all RTCStats dictionaries and enum > values are simply string-copied (example: [2]) it seems safe to assume > that "stats enums are just strings" is here to stay. > > Therefore there is little value in having C++ structs that look like > enums so I'm deleting those in favor of std::string operator==() > comparisons, e.g. `if (rtp_stream.kind == "audio")`. This removes some > lines of code from our code base. > > I mostly want to get rid of these because they were taking up about 20% > of the rtcstats_objects.h real estate... > > [1] https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/modules/peerconnection/rtc_stats_report.idl > [2] https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/modules/peerconnection/rtc_stats_report.cc;l=667;drc=cf34e84c9df94256abfb1716ba075ed203975755 > > Bug: webrtc:15245 > Change-Id: Iaf0827d7aecebc1cc02976a61663d5298d684f07 > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/308680 > Commit-Queue: Henrik Boström <hbos@webrtc.org> > Reviewed-by: Harald Alvestrand <hta@webrtc.org> > Cr-Commit-Position: refs/heads/main@{#40295} Bug: webrtc:15245 Change-Id: Ibc7aeb518ed0bd7f1d725f140132c99e5a89bcf3 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/308880 Auto-Submit: Henrik Boström <hbos@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Harald Alvestrand <hta@webrtc.org> Cr-Commit-Position: refs/heads/main@{#40305}
How to write code in the api/ directory
Mostly, just follow the regular style guide, but:
- Note that
api/code is not exempt from the “.hand.ccfiles come in pairs” rule, so if you declare something inapi/path/to/foo.h, it should be defined inapi/path/to/foo.cc. - Headers in
api/should, if possible, not#includeheaders outsideapi/. It’s not always possible to avoid this, but be aware that it adds to a small mountain of technical debt that we’re trying to shrink. .ccfiles inapi/, on the other hand, are free to#includeheaders outsideapi/.
That is, the preferred way for api/ code to access non-api/ code is to call
it from a .cc file, so that users of our API headers won’t transitively
#include non-public headers.
For headers in api/ that need to refer to non-public types, forward
declarations are often a lesser evil than including non-public header files. The
usual rules still apply, though.
.cc files in api/ should preferably be kept reasonably small. If a
substantial implementation is needed, consider putting it with our non-public
code, and just call it from the api/ .cc file.