llvm dev - Jan 2017 - [cfe-dev] Modernizing LLVM Coding Style Guide and enforcing Clang-tidy

Hi,

Sorry I fat fingered an earlier send in the previous email.  I was
trying to say:

On Mon, Jan 9, 2017 at 2:52 PM, Sanjoy Das
<sanjoy at playingwithpointers.com> wrote:
>> +1 Exactly this.
>> I don't think C programmer will not understand using. The
"=" makes it much
>> simpler to read, even if it is the first time you see it, which is not
the
>> case of typedef.
>>
>> typedef MyType::NestedType (*fptr)(const MyOhterType&);
>> or
>> using fptr = MyType::NestedType (*)(const MyOhterType&);
>
I would prefer to please keep using typedefs at least for function
pointers.  I find either of

typedef MyType::NestedType (*fptr)(const MyOhterType&);

or

typedef int fptr(const int&);

void f(fptr* ptr) {
  ...
}

easier to read than the "using" declaration (especially the second
form, with the explicit `fptr* ptr`).

-- Sanjoy

On Mon, Jan 9, 2017 at 2:59 PM Sanjoy Das via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi,
>
> Sorry I fat fingered an earlier send in the previous email.  I was
> trying to say:
>
> On Mon, Jan 9, 2017 at 2:52 PM, Sanjoy Das
> <sanjoy at playingwithpointers.com> wrote:
> >> +1 Exactly this.
> >> I don't think C programmer will not understand using. The
"=" makes it
> much
> >> simpler to read, even if it is the first time you see it, which is
not
> the
> >> case of typedef.
> >>
> >> typedef MyType::NestedType (*fptr)(const MyOhterType&);
> >> or
> >> using fptr = MyType::NestedType (*)(const MyOhterType&);
> >
>
> I would prefer to please keep using typedefs at least for function
> pointers.  I find either of
>
> typedef MyType::NestedType (*fptr)(const MyOhterType&);
>
> or
>
> typedef int fptr(const int&);
>
> void f(fptr* ptr) {
>   ...
> }
>
> easier to read than the "using" declaration (especially the
second
> form, with the explicit `fptr* ptr`).
>
Not sure I follow. You're saying this:

  typedef int func_type(const int&);

is easier for you to read than this:

  using func_type = int(const int&);

?

>
> -- Sanjoy
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170109/5e81ee26/attachment.html>

On Mon, Jan 9, 2017 at 3:06 PM, David Blaikie via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
>
>
> On Mon, Jan 9, 2017 at 2:59 PM Sanjoy Das via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hi,
>>
>> Sorry I fat fingered an earlier send in the previous email.  I was
>> trying to say:
>>
>> On Mon, Jan 9, 2017 at 2:52 PM, Sanjoy Das
>> <sanjoy at playingwithpointers.com> wrote:
>> >> +1 Exactly this.
>> >> I don't think C programmer will not understand using. The
"=" makes it
>> much
>> >> simpler to read, even if it is the first time you see it,
which is not
>> the
>> >> case of typedef.
>> >>
>> >> typedef MyType::NestedType (*fptr)(const MyOhterType&);
>> >> or
>> >> using fptr = MyType::NestedType (*)(const MyOhterType&);
>> >
>>
>> I would prefer to please keep using typedefs at least for function
>> pointers.  I find either of
>>
>> typedef MyType::NestedType (*fptr)(const MyOhterType&);
>>
>> or
>>
>> typedef int fptr(const int&);
>>
>> void f(fptr* ptr) {
>>   ...
>> }
>>
>> easier to read than the "using" declaration (especially the
second
>> form, with the explicit `fptr* ptr`).
>>
>
> Not sure I follow. You're saying this:
>
>   typedef int func_type(const int&);
>
> is easier for you to read than this:
>
>   using func_type = int(const int&);
>
I'd say so, one looks like the functions i right. The other looks strange ;)

>
> ?
>
>
>>
>> -- Sanjoy
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170109/7a295e55/attachment.html>

2017-01-10 0:06 GMT+01:00 David Blaikie <dblaikie at gmail.com>:
>
>
> On Mon, Jan 9, 2017 at 2:59 PM Sanjoy Das via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hi,
>>
>> Sorry I fat fingered an earlier send in the previous email.  I was
>> trying to say:
>>
>> On Mon, Jan 9, 2017 at 2:52 PM, Sanjoy Das
>> <sanjoy at playingwithpointers.com> wrote:
>> >> +1 Exactly this.
>> >> I don't think C programmer will not understand using. The
"=" makes it
>> much
>> >> simpler to read, even if it is the first time you see it,
which is not
>> the
>> >> case of typedef.
>> >>
>> >> typedef MyType::NestedType (*fptr)(const MyOhterType&);
>> >> or
>> >> using fptr = MyType::NestedType (*)(const MyOhterType&);
>> >
>>
>> I would prefer to please keep using typedefs at least for function
>> pointers.  I find either of
>>
>> typedef MyType::NestedType (*fptr)(const MyOhterType&);
>>
>> or
>>
>> typedef int fptr(const int&);
>>
>> void f(fptr* ptr) {
>>   ...
>> }
>>
>> easier to read than the "using" declaration (especially the
second
>> form, with the explicit `fptr* ptr`).
>>
>
> Not sure I follow. You're saying this:
>
>   typedef int func_type(const int&);
>
> is easier for you to read than this:
>
>   using func_type = int(const int&);
>
> ?
>
>
I never saw syntax

typedef int funct_type(const int&);

I tried to use it and I got compile error for code:
int z(const int&);

int main() {
    typedef int fptr(const int&);

    fptr f = z;
    f(42);
}

where typedef int (*fptr)(const int&)

works.


>
>> -- Sanjoy
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170110/26496c7d/attachment.html>