commit | beb94d86fce503636263511f9adbba1119d9c4e3 | [log] [tgz] |
---|---|---|
author | Alex Clarke <alexclarke@chromium.org> | Mon Feb 18 22:01:17 2019 |
committer | Commit Bot <commit-bot@chromium.org> | Mon Feb 18 22:01:17 2019 |
tree | 54782c67f7165659ef959cb9dc9c117448193cfc | |
parent | a2b8ddd7f75d67914e780ee6e7f01773105c2787 [diff] |
Make sure TypeId doesn't use PRETTY_FUNCTION when DCHECK is turned off Change-Id: I0a4b8205534d275afbb6dd0b94361839391fe187 Reviewed-on: https://chromium-review.googlesource.com/c/1477124 Commit-Queue: Alex Clarke <alexclarke@chromium.org> Commit-Queue: Gabriel Charette <gab@chromium.org> Reviewed-by: Gabriel Charette <gab@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#633151} Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src Cr-Mirrored-Commit: 54a1e08b17612589d2bc7f9986c8e2d8c8b16513
Contains a written down set of principles and other information on //base. Please add to it!
Chromium is a very mature project. Most things that are generally useful are already here and things not here aren't generally useful.
Base is pulled into many projects. For example, various ChromeOS daemons. So the bar for adding stuff is that it must have demonstrated wide applicability. Prefer to add things closer to where they're used (i.e. “not base”), and pull into base only when needed. In a project our size, sometimes even duplication is OK and inevitable.
Adding a new logging macro DPVELOG_NE
is not more clear than just writing the stuff you want to log in a regular logging statement, even if it makes your calling code longer. Just add it to your own code.
If the code in question does not need to be used inside base, but will have multiple consumers across the codebase, consider placing it in a new directory under components/ instead.
Owners are added when a contributor has shown the above qualifications and when they express interest. There isn't an upper bound on the number of OWNERS.
Since the primitives provided by //base are used very widely, it is important to ensure they scale to the necessary workloads and perform well under all supported platforms. The base_perftests
target is a suite of synthetic microbenchmarks that measure performance in various scenarios:
Regressions in these benchmarks can generally by caused by 1) operating system changes, 2) compiler version or flag changes or 3) changes in //base code itself.