lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Default values for default arguments


From: Greg Chicares
Subject: Re: [lmi] Default values for default arguments
Date: Sat, 4 Feb 2017 17:23:19 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0

On 2017-02-04 14:59, Vadim Zeitlin wrote:
> On Sat, 4 Feb 2017 04:51:35 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> Vadim--Do you see any reason why we should not prefer the uniform
> GC> "{}" syntax to specify default values for default arguments as in
> GC> the following examples? E.g., does any compiler you customarily
> GC> use not support this yet?
[...condensing...]
> GC> -        ,std::vector<std::string> const& a_allowed_keywords = 
> std::vector<std::string>()
> GC> +        ,std::vector<std::string> const& a_allowed_keywords = {}
> GC> -        ,std::string const&              a_default_keyword = ""
> GC> +        ,std::string const&              a_default_keyword = {}
> 
>  The answer to the question above depends on what exactly do you mean by
> "this". The code similar to above can be compiled just fine with all of gcc
> (4.9, 5, 6), clang (3.8, 4.0) and MSVS 2015. But, just in case it wasn't
> obvious not only to me, this relies on the existence of the ctor from
> std::initializer_list in both std::string and std::vector.

That was far from obvious to me. But I intuitively feared to try anything
like this:
-  char const* p = "" // pointer to a one-byte array containing '\0'
+  char const* p = {} // the same? or nullptr instead?

> IOW, this
> wouldn't work for any class not providing such ctor, so if the question is
> "can we uniformly use {} to specify default values for all classes", then
> the answer is definitely no.

Agreed.

>  Personally I'm a bit wary of everything involving std::initializer_list in
> C++, it's too simple to write something that compiles without any warnings
> but doesn't behave like you thought it would with it (of course, the worst
> offender here is the notorious std::vector<int> ctor, but there are other
                                             ^^^
I believe you mean std::vector<bool>.

> examples too). So while it is convenient to use it in these 2 particular
> (and, admittedly, very common) cases, I'm not sure it's worth the extra
> potential for confusion that it creates.

Thanks for the explanation. I find it so ugly to write
        ,std::vector<std::string> const& a_allowed_keywords = 
std::vector<std::string>()
that I broke the line in two, which is at best only slightly less ugly.
I believe I will replace that one with "{}" because less awful than
the other options. But this, elsewhere:

    ,std::vector<std::string> const& k = std::vector<std::string>()
    ,std::vector<std::string> const& c = std::vector<std::string>()
    ,bool                            o = false
    ,std::string const&              w = std::string()

extends only to column 67, so I'll leave it alone.

I'm glad I asked this, because I confidently assumed you would say that
"{}" is better--because it clearly expresses the intent and (as where
we use "auto") we shouldn't have to go through the empty ceremony of
reciting the type twice...which would have answered another question
that I had left unasked, but will ask now. Consider:

    ,std::string const&              w = std::string() // quote above
    ,std::string const&              w = ""            // alternative

I'd like to choose one and use it uniformly throughout lmi. I think
the former is better because it means "a default-constructed string",
whereas the later, although shorter, means
  create a one-element array of char in memory, containing '\0'
  and then construct a string from that
and I'm not sure the compiler can elide that. AIUI, in this case:
  std::string a = std::string();
  std::string b = std::string();
&a might equal &b (and probably does), but in this case
  std::string a = "";
  std::string b = "";
maybe it can't because the two '""' objects have different addresses.

Below, if I grepped correctly, is a complete list of the occurrences
of both in lmi (there are fewer than I had guessed), with duplicates
removed for terseness:

'= std::string()' [nine occurrences, three unique]:
    ,std::string const& gloss = std::string()
    ,std::string const&              w = std::string()
    ,std::string const& unexpected = std::string()

'= ""' [two occurrences, both unique]:
    ,std::string const&              a_default_keyword = ""
    ,std::string const&                title = ""

I would propose to change the last two to "= std::string()".




reply via email to

[Prev in Thread] Current Thread [Next in Thread]