-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Port StringPrintf from //base #624
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
This saves having to redefine all the libraries that abseil defines as imported libraries.
Cut the log out of the name to reflect that these will get more components besides just logging.
Prefer this to approaches based on variadic templates. While the variadic template mechanisms are strictly safer, they result in binary bloat we can't afford. This is essentially the same StringPrintf previously open sourced as a part of protobuf, though updated for C++11 which saves a copy and a temporary buffer on the heap.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is StringPrintf and relevant functions the only ones we need from abseil library? I mean, do we have plan to depend on abseil later or will branch their code whenever we need any of them.
These changes don't come from Abseil (nor does Abseil plan to release them). This is from google3 //base and from the point of view of the Abseil team this approach is the legacy approach. As noted in the description though this approach is better for us because:
|
* Update CHANGELOG for macOS AppKit dependency. (#609) * Add Community Supported tvOS (#590) Add Community Supported tvOS for Core, Auth, Database and Storage. Add tvOS unit tests Add tvOS sample app Update README.md Add tvOS to travis testing * Adds API Test for Email Update (#613) * update Gemfile for Travis (#620) * update Travis to Xcode 9.2 (#619) * Removing an obsolete setting from plist files (#617) * Removing an obsolete setting from plist files * Fixing Unit Tests * Fixing nullability * Fully qualify protoc-generated outputs (#626) * Fully-qualify imports in the protocol compiler output * pbxproj updates from running pod update * New checked-in proto outputs * Port StringPrintf from //base (#624) * Port StringPrintf from //base. Prefer this to approaches based on variadic templates. While the variadic template mechanisms are strictly safer, they result in binary bloat we can't afford. This is essentially the same StringPrintf previously open sourced as a part of protobuf, though updated for C++11 which saves a copy and a temporary buffer on the heap. * Add abseil as a subdirectory of Firestore This saves having to redefine all the libraries that abseil defines as imported libraries. * Rename firebase_firesture_util_log_* targets Cut the log out of the name to reflect that these will get more components besides just logging. * Update tests for firebase_firestore_util renames
* Port StringPrintf from //base. Prefer this to approaches based on variadic templates. While the variadic template mechanisms are strictly safer, they result in binary bloat we can't afford. This is essentially the same StringPrintf previously open sourced as a part of protobuf, though updated for C++11 which saves a copy and a temporary buffer on the heap. * Add abseil as a subdirectory of Firestore This saves having to redefine all the libraries that abseil defines as imported libraries. * Rename firebase_firesture_util_log_* targets Cut the log out of the name to reflect that these will get more components besides just logging.
Prefer this to approaches based on variadic templates. While the variadic template mechanisms are strictly safer, they result in binary bloat we can't afford.
This is essentially the same StringPrintf previously open sourced as a part of protobuf. If we do end up actually linking against protobuf we can remove this port. At this point since we're leaning toward using nanopb it seems reasonable to just add this now.
I've also slightly rearranged the CMake build to make it clearer how the platform-specific bits in firebase/firestore/util fit together.
@zxu123 This should make some the feedback I gave in #612 much easier to deal with.