diff --git a/base/linux_util.cc b/base/linux_util.ccindex d94588f..1acf5aa 100644--- a/base/linux_util.cc+++ b/base/linux_util.cc@@ -102,11 +102,8 @@ std::string GetLinuxDistro() {// We do this check only once per process. If it fails, there's// little reason to believe it will work if we attempt to run// lsb_release again.- std::vector<std::string> argv;- argv.push_back("lsb_release");- argv.push_back("-d");std::string output;- GetAppOutput(CommandLine(argv), &output);+ GetAppOutput(CommandLine({"lsb_release", "-d"}), &output);if (output.length() > 0) {// lsb_release -d should return: Description:<tab>Distro Infoconst char field[] = "Description:\t";
--
You received this message because you are subscribed to the Google Groups "cxx" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cxx+uns...@chromium.org.
To post to this group, send email to c...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CAF52%2BS7kS09xwjoLngRVS_w9aZG%3DedrPNQrbjaq-SK-zg-eKoA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CADsXd2Pn3-QhVd6nvruwAM2AML_ucuK3NnbPBwKmH%2BY-O%2B3G7g%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CAJqEsoDYQvM%3DW_FCwuNsj3PNHx4-NpmAjJS_P18NPetBpPA%2Bqg%40mail.gmail.com.
maybe we could say "ok to use for initializing vector<>s and map<>s" until we have a better compiler on Windows.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CAMGbLiGwx0XKpoKGJ_G85La6VEbScXsgHMXrHEhEO-e%3DW_dK0w%40mail.gmail.com.
On Mon, Nov 23, 2015 at 5:14 PM, Nico Weber <tha...@chromium.org> wrote:maybe we could say "ok to use for initializing vector<>s and map<>s" until we have a better compiler on Windows.Do we know if MSVC 2015 handles this better?
I'd prefer allowing initializer_list and uniform initialization syntax at the same time. The distinction is not meaningful as a user.
I interpreted it as "most programmers won't see these two different features as different things but will mentally lump them together as "uniform initializer syntax". That's certainly true in my case.
PK
I'm not disputing that they're technically distinct. I'm just agreeing with Sam that I wouldn't see those two things in a program and mentally think of two different things.It's a lot easier to just tell people "{a, b, c} syntax is fine" than to try to make the distinction clear.
I would still caution against allowing typing the words std::initializer_list. People tend to treat them as containers but they are not. Consider this:std::initializer_list<int> f() { return {1, 2, 3}; }int main() {std::vector<int> a(f());printf ("%d %d %d\n", a[0], a[1], a[2]);}$ clang++ -std=c++11 -Wall test.cpp$ ./a.out32767 -54118060 32767This is just an example where returning an intializer_list is very wrong. I don't think this request will prevent any sane usages such as initializing a vector using brace style initialization.
I would like to be able to type std::initializer_list. Can we not just set rules for when it's safe to use? Something like "only use std::initializer_list as a function parameter type"?
--
You received this message because you are subscribed to the Google Groups "cxx" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cxx+uns...@chromium.org.
To post to this group, send email to c...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CADsXd2M_8i81TXJLsjkwRR6n57-q%2BzqSQk%3D0Li2FWM8WGHAopg%40mail.gmail.com.
Are there common uses for writing "std::initializer_list" other than constructor (and possibly assignment operator) arguments?
We could provide guidance that other uses should be examined closely, though the Google C++ Style Guide doesn't place that kind of restrictions on it.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CACuR13cYwTckRfq-Nzc%2BZLaGpfw5s2vuCWa-pCyJoJ4naYbz%3DQ%40mail.gmail.com.
My pet use case for wanting to write std::initializer_list<T> is I have a member function that I want to be a type-safe varargs function. E.g., calls like foo.Bar({a, b, c}, x).I could use a variadic function template to make the function call look like foo.Bar(a, b, c, x) or foo.Bar(x, a, b, c), but I think grouping the a,b,c expressions is helpful to the API's readability and clang-format'ability.I could also just use a std::vector<T> parameter and foo.Bar({a, b, c}, x) would still work (once std::initializer_list is allowed), but it would involve the unnecessary construction of a std::vector<T> to hold the temporary values.
PK
Ultimately it would be up to what your function is doing with these values, but the point of an "initializer list" is, from its name, to initialize something,
* The only case where you should write "std::initializer_list" is for arguments to constructor/assignment functions for custom containers. If you want to pass or return multiple values in any other case, use an actual container, base::Tuple, or some other method.
--
You received this message because you are subscribed to the Google Groups "cxx" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cxx+uns...@chromium.org.
To post to this group, send email to c...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CAF52%2BS7JxzBWqMUt%2BeDBmgO_PoFxCN%3DLo3STHDr_BFmUc045Rw%40mail.gmail.com.
So, is there support for allowing initializer_list under the following conditions?:* Uniform initialization syntax in general is still banned.* In general, this should be used to brace-initialize STL containers.* The only case where you should write "std::initializer_list" is for arguments to constructor/assignment functions for custom containers. If you want to pass or return multiple values in any other case, use an actual container, base::Tuple, or some other method.
This last might be slightly more conservative than is necessary, but it avoids the possibility of problems. We could perhaps eliminate this specific guidance in the long run when people have more experience with initializer lists.
PK
--
You received this message because you are subscribed to the Google Groups "cxx" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cxx+uns...@chromium.org.
To post to this group, send email to c...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CAAHOzFAZP1qoP2brArkTsCn7HD2BaWCzqCfhL82B9OyFJsyPsQ%40mail.gmail.com.
On Mon, Dec 14, 2015 at 4:28 PM, 'Peter Kasting' via cxx <c...@chromium.org> wrote:So, is there support for allowing initializer_list under the following conditions?:* Uniform initialization syntax in general is still banned.* In general, this should be used to brace-initialize STL containers.* The only case where you should write "std::initializer_list" is for arguments to constructor/assignment functions for custom containers. If you want to pass or return multiple values in any other case, use an actual container, base::Tuple, or some other method.This one is risky, as it'll encourage people to add constructors taking std::initializer_list<> to existing constructors, which can silently change the behavior of existing code.
And given the known codegen bugs of 2013 with initialization, brace-initialization STL containers of production code feels risky to me too, especially with 2015 not being too far from ready.
I'd be fine with "You can brace-initialize std::vector and std::map" or something to that effect while we're still on 2013.
On Mon, Dec 14, 2015 at 4:28 PM, 'Peter Kasting' via cxx <c...@chromium.org> wrote:So, is there support for allowing initializer_list under the following conditions?:* Uniform initialization syntax in general is still banned.* In general, this should be used to brace-initialize STL containers.* The only case where you should write "std::initializer_list" is for arguments to constructor/assignment functions for custom containers. If you want to pass or return multiple values in any other case, use an actual container, base::Tuple, or some other method.This one is risky, as it'll encourage people to add constructors taking std::initializer_list<> to existing constructors, which can silently change the behavior of existing code.And given the known codegen bugs of 2013 with initialization, brace-initialization STL containers of production code feels risky to me too, especially with 2015 not being too far from ready.I'd be fine with "You can brace-initialize std::vector and std::map" or something to that effect while we're still on 2013.
----This last might be slightly more conservative than is necessary, but it avoids the possibility of problems. We could perhaps eliminate this specific guidance in the long run when people have more experience with initializer lists.
PK
You received this message because you are subscribed to the Google Groups "cxx" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cxx+uns...@chromium.org.
To post to this group, send email to c...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CAAHOzFAZP1qoP2brArkTsCn7HD2BaWCzqCfhL82B9OyFJsyPsQ%40mail.gmail.com.
You received this message because you are subscribed to the Google Groups "cxx" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cxx+uns...@chromium.org.
To post to this group, send email to c...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CAMGbLiFjao4wsOG1nifWwCUEj4DmmX7ALQMtA6Qnwsurv15HAA%40mail.gmail.com.
On Mon, Dec 14, 2015 at 4:28 PM, 'Peter Kasting' via cxx <c...@chromium.org> wrote:So, is there support for allowing initializer_list under the following conditions?:* Uniform initialization syntax in general is still banned.* In general, this should be used to brace-initialize STL containers.* The only case where you should write "std::initializer_list" is for arguments to constructor/assignment functions for custom containers. If you want to pass or return multiple values in any other case, use an actual container, base::Tuple, or some other method.This one is risky, as it'll encourage people to add constructors taking std::initializer_list<> to existing constructors, which can silently change the behavior of existing code.And given the known codegen bugs of 2013 with initialization, brace-initialization STL containers of production code feels risky to me too, especially with 2015 not being too far from ready.I'd be fine with "You can brace-initialize std::vector and std::map" or something to that effect while we're still on 2013.
----This last might be slightly more conservative than is necessary, but it avoids the possibility of problems. We could perhaps eliminate this specific guidance in the long run when people have more experience with initializer lists.
PK
You received this message because you are subscribed to the Google Groups "cxx" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cxx+uns...@chromium.org.
To post to this group, send email to c...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CAAHOzFAZP1qoP2brArkTsCn7HD2BaWCzqCfhL82B9OyFJsyPsQ%40mail.gmail.com.
You received this message because you are subscribed to the Google Groups "cxx" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cxx+uns...@chromium.org.
To post to this group, send email to c...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CAMGbLiFjao4wsOG1nifWwCUEj4DmmX7ALQMtA6Qnwsurv15HAA%40mail.gmail.com.
On Tue, 15 Dec 2015 at 08:43 Nico Weber <tha...@chromium.org> wrote:On Mon, Dec 14, 2015 at 4:28 PM, 'Peter Kasting' via cxx <c...@chromium.org> wrote:So, is there support for allowing initializer_list under the following conditions?:* Uniform initialization syntax in general is still banned.* In general, this should be used to brace-initialize STL containers.* The only case where you should write "std::initializer_list" is for arguments to constructor/assignment functions for custom containers. If you want to pass or return multiple values in any other case, use an actual container, base::Tuple, or some other method.
I feel like this discussion is getting to the point where someone is going to propose a CL to allow this in some shape or form, so I wanted to verify that I have some idea of what the above three points mean. In particular, given the following.. which are OK and which are not OK? I'm particularly confused about uniform initialization vs brace initializing STL containers:
std::vector<int> a{};std::vector<int> b = {};std::vector<int> c = {1, 2, 3};std::vector<int> d{1, 2, 3};
int e[1] = {};int f[1]{};int g[1] = {1};int h[1]{1};
int i{};int j = {};int k = {1};int l{1};
m({1, 2, 3});n(std::vector{1, 2, 3});
On Thu, Dec 17, 2015 at 1:36 PM, Vladimir Levin <vmp...@google.com> wrote:I feel like this discussion is getting to the point where someone is going to propose a CL to allow this in some shape or form, so I wanted to verify that I have some idea of what the above three points mean. In particular, given the following.. which are OK and which are not OK? I'm particularly confused about uniform initialization vs brace initializing STL containers:I'll do my best, but might be wrong.std::vector<int> a{};std::vector<int> b = {};std::vector<int> c = {1, 2, 3};std::vector<int> d{1, 2, 3};I think these all boil down to calling the initializer_list constructor for vector and are thus fine.
int e[1] = {};int f[1]{};int g[1] = {1};int h[1]{1};I think e and g are simply classic array initialization and are thus fine, while f and h require uniform initialization syntax and are thus not OK.int i{};int j = {};int k = {1};int l{1};These would all be disallowed.m({1, 2, 3});n(std::vector{1, 2, 3});n is OK. m might be OK depending on its signature (I think the vector initializer_list constructor isn't explicit, so if m takes a vector this would be OK).
PK
--
You received this message because you are subscribed to the Google Groups "cxx" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cxx+uns...@chromium.org.
To post to this group, send email to c...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CAAHOzFBkHg3cf2Y53oz5t2sH%2BOcS96qu5hSEW_Yn4hyb%3DwsDxg%40mail.gmail.com.
On Thu, Dec 17, 2015 at 1:36 PM, Vladimir Levin <vmp...@google.com> wrote:I feel like this discussion is getting to the point where someone is going to propose a CL to allow this in some shape or form, so I wanted to verify that I have some idea of what the above three points mean. In particular, given the following.. which are OK and which are not OK? I'm particularly confused about uniform initialization vs brace initializing STL containers:I'll do my best, but might be wrong.std::vector<int> a{};std::vector<int> b = {};
std::vector<int> c = {1, 2, 3};std::vector<int> d{1, 2, 3};I think these all boil down to calling the initializer_list constructor for vector and are thus fine.
int e[1] = {};int f[1]{};int g[1] = {1};int h[1]{1};I think e and g are simply classic array initialization and are thus fine, while f and h require uniform initialization syntax and are thus not OK.int i{};int j = {};int k = {1};int l{1};These would all be disallowed.m({1, 2, 3});n(std::vector{1, 2, 3});n is OK. m might be OK depending on its signature (I think the vector initializer_list constructor isn't explicit, so if m takes a vector this would be OK).
Daniel's point about std::vector<int> v{5} being different from std::vector<int> v(5) is interesting, and probably going to confuse people.
m({1, 2, 3});n(std::vector{1, 2, 3});n is OK. m might be OK depending on its signature (I think the vector initializer_list constructor isn't explicit, so if m takes a vector this would be OK).m should be okay wherever it compiles, it will definitely make an initializer list, so m must either: take an initializer list, or take an object with implicit conversion from an initializer list.
Probably making more explicit where-it's-allowed is understandable/enforceable, if anything is. I liked Nico's and Jeremy's suggestions:* Can be used to initialize standard containers.
* Can be used for hard-coded range-based for loops.
Daniel's point about std::vector<int> v{5} being different from std::vector<int> v(5) is interesting, and probably going to confuse people.
If we all get used to f{a,b} always being an initializer_list (based on our restricted allowed usage), and then start using it for types other than standard containers (that don't have implicit initializer_list constructors), it's going to throw off the simpler intuitions people build around the syntax.
This looks a lot like the MSVC miscompile in https://codereview.chromium.org/1130873007/#msg13. That makes me nervous about allowing any of these until we go to MSVC 2015. At most, an initialization of a class-whose-name-makes-it-clearly-a-container could make sense.