Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #85808 > unrolled thread

initializer list type deduction rules

Back to article view | Back to comp.lang.c++

Contents

  initializer list type deduction rules Juha Nieminen <nospam@thanks.invalid> - 2022-08-09 07:54 +0000
    Re: initializer list type deduction rules Bo Persson <bo@bo-persson.se> - 2022-08-09 10:43 +0200
    Re: initializer list type deduction rules Öö Tiib <ootiib@hot.ee> - 2022-08-09 09:00 -0700
      Re: initializer list type deduction rules Muttley@dastardlyhq.com - 2022-08-09 16:06 +0000
        Re: initializer list type deduction rules Juha Nieminen <nospam@thanks.invalid> - 2022-08-10 02:32 +0000
          Re: initializer list type deduction rules Paavo Helde <eesnimi@osa.pri.ee> - 2022-08-10 09:11 +0300
            Re: initializer list type deduction rules Juha Nieminen <nospam@thanks.invalid> - 2022-08-10 06:57 +0000
          Re: initializer list type deduction rules Muttley@dastardlyhq.com - 2022-08-10 07:31 +0000
        Re: initializer list type deduction rules Öö Tiib <ootiib@hot.ee> - 2022-08-10 00:40 -0700
          Re: initializer list type deduction rules Muttley@dastardlyhq.com - 2022-08-10 07:55 +0000
            Re: initializer list type deduction rules Öö Tiib <ootiib@hot.ee> - 2022-08-10 01:13 -0700
              Re: initializer list type deduction rules Muttley@dastardlyhq.com - 2022-08-10 08:21 +0000
                Re: initializer list type deduction rules Öö Tiib <ootiib@hot.ee> - 2022-08-10 11:13 -0700
                  Re: initializer list type deduction rules Muttley@dastardlyhq.com - 2022-08-12 08:26 +0000
                    Re: initializer list type deduction rules Öö Tiib <ootiib@hot.ee> - 2022-08-12 03:38 -0700
                      Re: initializer list type deduction rules Muttley@dastardlyhq.com - 2022-08-12 10:48 +0000
                        Re: initializer list type deduction rules Öö Tiib <ootiib@hot.ee> - 2022-08-12 04:54 -0700
                          Re: initializer list type deduction rules Muttley@dastardlyhq.com - 2022-08-12 14:34 +0000
                            Re: initializer list type deduction rules Öö Tiib <ootiib@hot.ee> - 2022-08-12 08:34 -0700
                              Re: initializer list type deduction rules Muttley@dastardlyhq.com - 2022-08-12 15:57 +0000
                                Re: initializer list type deduction rules Öö Tiib <ootiib@hot.ee> - 2022-08-12 09:16 -0700
                                  Re: initializer list type deduction rules Muttley@dastardlyhq.com - 2022-08-13 09:35 +0000
                                    Re: initializer list type deduction rules Öö Tiib <ootiib@hot.ee> - 2022-08-13 09:44 -0700
                                      Re: initializer list type deduction rules Muttley@dastardlyhq.com - 2022-08-14 11:12 +0000
                      Re: initializer list type deduction rules scott@slp53.sl.home (Scott Lurndal) - 2022-08-12 14:58 +0000
                        Re: initializer list type deduction rules Öö Tiib <ootiib@hot.ee> - 2022-08-12 08:59 -0700
                          Re: initializer list type deduction rules Muttley@dastardlyhq.com - 2022-08-12 16:11 +0000
                          Re: initializer list type deduction rules scott@slp53.sl.home (Scott Lurndal) - 2022-08-12 16:44 +0000
                            Re: initializer list type deduction rules Öö Tiib <ootiib@hot.ee> - 2022-08-12 12:08 -0700
                              Re: initializer list type deduction rules scott@slp53.sl.home (Scott Lurndal) - 2022-08-12 19:58 +0000
                                Re: initializer list type deduction rules Öö Tiib <ootiib@hot.ee> - 2022-08-12 16:42 -0700
                        Re: initializer list type deduction rules David Brown <david.brown@hesbynett.no> - 2022-08-13 18:14 +0200
                          Re: initializer list type deduction rules Muttley@dastardlyhq.com - 2022-08-14 11:06 +0000
                            Re: initializer list type deduction rules David Brown <david.brown@hesbynett.no> - 2022-08-15 11:34 +0200
                              Re: initializer list type deduction rules Muttley@dastardlyhq.com - 2022-08-15 19:03 +0000
                                Re: initializer list type deduction rules David Brown <david.brown@hesbynett.no> - 2022-08-15 21:23 +0200
                                  Re: initializer list type deduction rules red floyd <no.spam.here@its.invalid> - 2022-08-15 13:51 -0700
                                  Re: initializer list type deduction rules Muttley@dastardlyhq.com - 2022-08-16 19:16 +0000
                                    Re: initializer list type deduction rules Paavo Helde <eesnimi@osa.pri.ee> - 2022-08-21 22:23 +0300
                                      Re: initializer list type deduction rules David Brown <david.brown@hesbynett.no> - 2022-08-22 08:08 +0200
                                        Re: initializer list type deduction rules Paavo Helde <eesnimi@osa.pri.ee> - 2022-08-22 11:37 +0300
                                          Re: initializer list type deduction rules Muttley@dastardlyhq.com - 2022-08-22 10:23 +0000
            Re: initializer list type deduction rules Juha Nieminen <nospam@thanks.invalid> - 2022-08-11 06:24 +0000
              Re: initializer list type deduction rules Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-11 16:37 +0100
                Re: initializer list type deduction rules Juha Nieminen <nospam@thanks.invalid> - 2022-08-11 20:12 +0000
                  Re: initializer list type deduction rules Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-12 00:09 +0100
                    Re: initializer list type deduction rules Juha Nieminen <nospam@thanks.invalid> - 2022-08-12 11:51 +0000
              Re: initializer list type deduction rules Muttley@dastardlyhq.com - 2022-08-12 08:29 +0000
                Re: initializer list type deduction rules Juha Nieminen <nospam@thanks.invalid> - 2022-08-12 12:08 +0000
                  Re: initializer list type deduction rules Muttley@dastardlyhq.com - 2022-08-12 14:37 +0000
                  Re: initializer list type deduction rules scott@slp53.sl.home (Scott Lurndal) - 2022-08-12 15:01 +0000
                    Re: initializer list type deduction rules Juha Nieminen <nospam@thanks.invalid> - 2022-08-15 06:04 +0000
    Re: initializer list type deduction rules Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-08-09 16:08 -0700
      Re: initializer list type deduction rules Juha Nieminen <nospam@thanks.invalid> - 2022-08-10 02:34 +0000

Page 1 of 3  [1] 2 3  Next page →

#85808 — initializer list type deduction rules

The exact type deduction rules for initializer lists are not completely
clear to me. For example, in an expression like this the type is deduced
without problems:

  std::pair<unsigned, unsigned> values[] =
      { { 1, 2 }, { 2, 3 }, { 3, 4 } };

However, here it's not:

  for(const std::pair<unsigned, unsigned>& value:
          { { 1, 2 }, { 2, 3 }, { 3, 4 } })

Sometimes it's useful to loop through a list of values using a range-based
for loop one-liner:

  for(int i: { 10, 2, 15, 28, 3 })

However, because of the limitations of deducing the type of the
initializer list in such range-based for expressions, that's not always
that simple, as in the second example above.

Even in such a simple case as this:

  unsigned values[] = { 1, 2, 3, 5 10 };

vs. this:

  for(unsigned value: { 1, 2, 3, 5, 10 })

if you turn on enough compiler warnings eg. gcc will warn about the
second one (converting 'int' to 'unsigned' may change the sign of the
result) but not the first one. I believe that in the first case the
compiler deduces the type of the initializer list to be 'unsigned'
(even though the literals themselves are of type 'int'), while in
the second case it does not.

I kind of grasp the difference between these two cases, but it just
makes range-based for loops less convenient when it's like this.

[toc] | [next] | [standalone]

#85809

On 2022-08-09 at 09:54, Juha Nieminen wrote:
> The exact type deduction rules for initializer lists are not completely
> clear to me. For example, in an expression like this the type is deduced
> without problems:
> 
>    std::pair<unsigned, unsigned> values[] =
>        { { 1, 2 }, { 2, 3 }, { 3, 4 } };
> 
> However, here it's not:
> 
>    for(const std::pair<unsigned, unsigned>& value:
>            { { 1, 2 }, { 2, 3 }, { 3, 4 } })
> 
> Sometimes it's useful to loop through a list of values using a range-based
> for loop one-liner:
> 
>    for(int i: { 10, 2, 15, 28, 3 })
> 
> However, because of the limitations of deducing the type of the
> initializer list in such range-based for expressions, that's not always
> that simple, as in the second example above.
> 
> Even in such a simple case as this:
> 
>    unsigned values[] = { 1, 2, 3, 5 10 };
> 
> vs. this:
> 
>    for(unsigned value: { 1, 2, 3, 5, 10 })
> 
> if you turn on enough compiler warnings eg. gcc will warn about the
> second one (converting 'int' to 'unsigned' may change the sign of the
> result) but not the first one. I believe that in the first case the
> compiler deduces the type of the initializer list to be 'unsigned'
> (even though the literals themselves are of type 'int'), while in
> the second case it does not.
> 
> I kind of grasp the difference between these two cases, but it just
> makes range-based for loops less convenient when it's like this.

I beleive the rules are pretty clear, but that the use cases are not 
equally common.

For example, in

unsigned values[] = { 1, 2, 3, 5 10 };

you would get tons of false warnings in many programs. So the compiler 
has gotten code to verify that there are in fact no negative values, and 
to suppress the warning.

The same *could* happen for the ranged-for case, but apparently it does 
not. My guess is that there a significantly fewer cases, and the 
"warning suppression" has not gotten a high enough priority.

[toc] | [prev] | [next] | [standalone]

#85813

On Tuesday, 9 August 2022 at 10:54:49 UTC+3, Juha Nieminen wrote:
> The exact type deduction rules for initializer lists are not completely 
> clear to me. For example, in an expression like this the type is deduced 
> without problems: 
> 
> std::pair<unsigned, unsigned> values[] = 
> { { 1, 2 }, { 2, 3 }, { 3, 4 } }; 
> 
> However, here it's not: 
> 
> for(const std::pair<unsigned, unsigned>& value: 
> { { 1, 2 }, { 2, 3 }, { 3, 4 } }) 

Initialiser lists were broken at birth.  Part of it was thanks to the
legacy looseness with initialising various things (like multidimensional
arrays), part thanks to new looseness added by C++11. So being more
explicit just helps everything.
 
// declare types ahead ... something meaningful in context
using Works = std::initializer_list<std::pair<unsigned, unsigned>>;
// then use your types
for(auto const& value: Works{{1, 2}, {2, 3}, {3, 4}, {4, 5}})
std::cout << value.first << " " << value.second << '\n';

Otherwise it is too dim what it is that you initialise.

[toc] | [prev] | [next] | [standalone]

#85814

On Tue, 9 Aug 2022 09:00:06 -0700 (PDT)
=?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote:
>On Tuesday, 9 August 2022 at 10:54:49 UTC+3, Juha Nieminen wrote:
>> The exact type deduction rules for initializer lists are not completely 
>> clear to me. For example, in an expression like this the type is deduced 
>> without problems: 
>> 
>> std::pair<unsigned, unsigned> values[] = 
>> { { 1, 2 }, { 2, 3 }, { 3, 4 } }; 
>> 
>> However, here it's not: 
>> 
>> for(const std::pair<unsigned, unsigned>& value: 
>> { { 1, 2 }, { 2, 3 }, { 3, 4 } }) 
>
>Initialiser lists were broken at birth.  Part of it was thanks to the
>legacy looseness with initialising various things (like multidimensional
>arrays), part thanks to new looseness added by C++11. So being more
>explicit just helps everything.
> 
>// declare types ahead ... something meaningful in context
>using Works = std::initializer_list<std::pair<unsigned, unsigned>>;

Or less confusingly

typedef std::initializer_list<std::pair<unsigned, unsigned>> Works;

"typedef" has one job to do. "using" was already overloaded and the point
of overloading it again simply to duplicate typedef is frankly a mystery to me 
and it just makes C++ even more of a confusing mess.

[toc] | [prev] | [next] | [standalone]

#85821

Muttley@dastardlyhq.com wrote:
> Or less confusingly
> 
> typedef std::initializer_list<std::pair<unsigned, unsigned>> Works;
> 
> "typedef" has one job to do. "using" was already overloaded and the point
> of overloading it again simply to duplicate typedef is frankly a mystery to me 
> and it just makes C++ even more of a confusing mess.

Yeah, because

  typedef double(*Ptr)(int, int);

is so much less confusing than

  using Ptr = double(*)(int, int);

(I bet half of C++ and even C programmers wouldn't even know how to create
a function pointer alias using typedef.)

[toc] | [prev] | [next] | [standalone]

#85825

10.08.2022 05:32 Juha Nieminen kirjutas:
> Muttley@dastardlyhq.com wrote:
>> Or less confusingly
>>
>> typedef std::initializer_list<std::pair<unsigned, unsigned>> Works;
>>
>> "typedef" has one job to do. "using" was already overloaded and the point
>> of overloading it again simply to duplicate typedef is frankly a mystery to me
>> and it just makes C++ even more of a confusing mess.
> 
> Yeah, because
> 
>    typedef double(*Ptr)(int, int);
> 
> is so much less confusing than
> 
>    using Ptr = double(*)(int, int);
> 
> (I bet half of C++ and even C programmers wouldn't even know how to create
> a function pointer alias using typedef.)

I admit I would still need to look up this syntax every time, be it 
either 'typedef' or 'using' ;-)

Luckily, after C+11 I have discovered I do not need function pointers at 
all, because when declaring a callback interface I always need to add 
the possibility to pass also callback data., i.e. I always need 
functors. When declaring, it's now either 'auto' or 
'std::function<double(int,int)>', and when calling, it's typically a lambda.

std::function declaration syntax I can actually use without looking it 
up ;-)

[toc] | [prev] | [next] | [standalone]

#85826

Paavo Helde <eesnimi@osa.pri.ee> wrote:
> Luckily, after C+11 I have discovered I do not need function pointers at 
> all, because when declaring a callback interface I always need to add 
> the possibility to pass also callback data., i.e. I always need 
> functors. When declaring, it's now either 'auto' or 
> 'std::function<double(int,int)>', and when calling, it's typically a lambda.
> 
> std::function declaration syntax I can actually use without looking it 
> up ;-)

Now you'll have to explain the difference between

    double(int,int)
and

    double(*)(int,int)

(because they aren't the same thing).

Why is it that you have to write std::function<int(std::FILE*)> but
std::unique_ptr<std::FILE, int(*)(std::FILE*)>?

[toc] | [prev] | [next] | [standalone]

#85827

On Wed, 10 Aug 2022 02:32:34 -0000 (UTC)
Juha Nieminen <nospam@thanks.invalid> wrote:
>Muttley@dastardlyhq.com wrote:
>> Or less confusingly
>> 
>> typedef std::initializer_list<std::pair<unsigned, unsigned>> Works;
>> 
>> "typedef" has one job to do. "using" was already overloaded and the point
>> of overloading it again simply to duplicate typedef is frankly a mystery to
>me 
>> and it just makes C++ even more of a confusing mess.
>
>Yeah, because
>
>  typedef double(*Ptr)(int, int);
>
>is so much less confusing than
>
>  using Ptr = double(*)(int, int);
>
>(I bet half of C++ and even C programmers wouldn't even know how to create
>a function pointer alias using typedef.)

And how many would know how to do it with using?

[toc] | [prev] | [next] | [standalone]

#85829

On Tuesday, 9 August 2022 at 19:06:57 UTC+3, Mut...@dastardlyhq.com wrote:
> On Tue, 9 Aug 2022 09:00:06 -0700 (PDT) 
> =?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote: 
> >On Tuesday, 9 August 2022 at 10:54:49 UTC+3, Juha Nieminen wrote: 
> >> The exact type deduction rules for initializer lists are not completely 
> >> clear to me. For example, in an expression like this the type is deduced 
> >> without problems: 
> >> 
> >> std::pair<unsigned, unsigned> values[] = 
> >> { { 1, 2 }, { 2, 3 }, { 3, 4 } }; 
> >> 
> >> However, here it's not: 
> >> 
> >> for(const std::pair<unsigned, unsigned>& value: 
> >> { { 1, 2 }, { 2, 3 }, { 3, 4 } }) 
> > 
> >Initialiser lists were broken at birth. Part of it was thanks to the 
> >legacy looseness with initialising various things (like multidimensional 
> >arrays), part thanks to new looseness added by C++11. So being more 
> >explicit just helps everything. 
> > 
> >// declare types ahead ... something meaningful in context 
> >using Works = std::initializer_list<std::pair<unsigned, unsigned>>;
> Or less confusingly 
> 
> typedef std::initializer_list<std::pair<unsigned, unsigned>> Works; 
> 
> "typedef" has one job to do. "using" was already overloaded and the point 
> of overloading it again simply to duplicate typedef is frankly a mystery to me 
> and it just makes C++ even more of a confusing mess.

I have no problems reading neither "using" nor "typedef". As I rarely work on
totally new code-base I try to write what code-base already uses for 
consistency.  

Confusion can arise when both forms of type alias declaration are used
side-by-side. That generates questions why both are used, what kind of
differences these have, is one or other "better" and should we
so change one of those and which one. Extremely pointless waste of time.

Then proposed will be that we put clang-tidy into toolchain. It will
automatically replace all typedefs with using before building and so
one commit later there will be no typedefs in any code that team
maintains manually. It is attractive to people bored of that  
bike-shedding. Tools that automatically replace using with typedef
are missing so there are no way to resolve it sanely in other direction.
 
  

[toc] | [prev] | [next] | [standalone]

#85831

On Wed, 10 Aug 2022 00:40:54 -0700 (PDT)
=?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote:
>On Tuesday, 9 August 2022 at 19:06:57 UTC+3, Mut...@dastardlyhq.com wrote:
>> On Tue, 9 Aug 2022 09:00:06 -0700 (PDT) 
>> >using Works = std::initializer_list<std::pair<unsigned, unsigned>>;
>> Or less confusingly 
>> 
>> typedef std::initializer_list<std::pair<unsigned, unsigned>> Works; 
>> 
>> "typedef" has one job to do. "using" was already overloaded and the point 
>> of overloading it again simply to duplicate typedef is frankly a mystery to
>me 
>> and it just makes C++ even more of a confusing mess.
>
>I have no problems reading neither "using" nor "typedef". As I rarely work on
>totally new code-base I try to write what code-base already uses for 
>consistency.  
>
>Confusion can arise when both forms of type alias declaration are used
>side-by-side. That generates questions why both are used, what kind of

The more pertinent question is why the C++ committee felt the need to 
duplicate the functionality of typedef.

>Then proposed will be that we put clang-tidy into toolchain. It will
>automatically replace all typedefs with using before building and so
>one commit later there will be no typedefs in any code that team
>maintains manually. It is attractive to people bored of that  
>bike-shedding. Tools that automatically replace using with typedef
>are missing so there are no way to resolve it sanely in other direction.

On a large C++ unix project that only uses typedefs for defining types:

grep typedef $(find -E . -regex ".*\.(h|hpp|cc|cpp)")

will list all your definitions. Putting "using" in there will probably bring 
back a whole load of crap you don't want.

[toc] | [prev] | [next] | [standalone]

#85832

On Wednesday, 10 August 2022 at 10:55:25 UTC+3, Mut...@dastardlyhq.com wrote:
> On Wed, 10 Aug 2022 00:40:54 -0700 (PDT)
> =?UTF-8?B?w5bDtiBUaWli?= <oot...@hot.ee> wrote: 
> >On Tuesday, 9 August 2022 at 19:06:57 UTC+3, Mut...@dastardlyhq.com wrote: 
> >> On Tue, 9 Aug 2022 09:00:06 -0700 (PDT)
> >> >using Works = std::initializer_list<std::pair<unsigned, unsigned>>; 
> >> Or less confusingly 
> >> 
> >> typedef std::initializer_list<std::pair<unsigned, unsigned>> Works; 
> >> 
> >> "typedef" has one job to do. "using" was already overloaded and the point 
> >> of overloading it again simply to duplicate typedef is frankly a mystery to 
> >me 
> >> and it just makes C++ even more of a confusing mess. 
> > 
> >I have no problems reading neither "using" nor "typedef". As I rarely work on 
> >totally new code-base I try to write what code-base already uses for 
> >consistency. 
> > 
> >Confusion can arise when both forms of type alias declaration are used 
> >side-by-side. That generates questions why both are used, what kind of
> 
> The more pertinent question is why the C++ committee felt the need to 
> duplicate the functionality of typedef.

That ship has sailed over decade ago and the answer was that there
was need to create alias-templates that typedef does not let to.

> >Then proposed will be that we put clang-tidy into toolchain. It will 
> >automatically replace all typedefs with using before building and so 
> >one commit later there will be no typedefs in any code that team 
> >maintains manually. It is attractive to people bored of that 
> >bike-shedding. Tools that automatically replace using with typedef 
> >are missing so there are no way to resolve it sanely in other direction.
> 
> On a large C++ unix project that only uses typedefs for defining types: 
> 
> grep typedef $(find -E . -regex ".*\.(h|hpp|cc|cpp)") 
> 
> will list all your definitions. Putting "using" in there will probably bring 
> back a whole load of crap you don't want.

Majority are probably indifferent ... usage of grep to find aliases might
feel like usage of #define to declare those. It is two levels below tools
that their IDEs provide with keypress or two.

[toc] | [prev] | [next] | [standalone]

#85834

On Wed, 10 Aug 2022 01:13:05 -0700 (PDT)
=?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote:
>On Wednesday, 10 August 2022 at 10:55:25 UTC+3, Mut...@dastardlyhq.com wrote:
>> The more pertinent question is why the C++ committee felt the need to 
>> duplicate the functionality of typedef.
>
>That ship has sailed over decade ago and the answer was that there
>was need to create alias-templates that typedef does not let to.

And the reason typedef couldn't have been extended to do them was.... ?

>> >Then proposed will be that we put clang-tidy into toolchain. It will 
>> >automatically replace all typedefs with using before building and so 
>> >one commit later there will be no typedefs in any code that team 
>> >maintains manually. It is attractive to people bored of that 
>> >bike-shedding. Tools that automatically replace using with typedef 
>> >are missing so there are no way to resolve it sanely in other direction.
>> 
>> On a large C++ unix project that only uses typedefs for defining types: 
>> 
>> grep typedef $(find -E . -regex ".*\.(h|hpp|cc|cpp)") 
>> 
>> will list all your definitions. Putting "using" in there will probably bring 
>
>> back a whole load of crap you don't want.
>
>Majority are probably indifferent ... usage of grep to find aliases might
>feel like usage of #define to declare those. It is two levels below tools
>that their IDEs provide with keypress or two.

Clearly you've never done much serious development on *nix or had to develop/
debug remotely down an ssh link.

And FWIW Eclipse is a slow steaming bug ridden POC.

[toc] | [prev] | [next] | [standalone]

#85837

On Wednesday, 10 August 2022 at 11:21:32 UTC+3, Mut...@dastardlyhq.com wrote:
> On Wed, 10 Aug 2022 01:13:05 -0700 (PDT) 
> =?UTF-8?B?w5bDtiBUaWli?= <oot...@hot.ee> wrote: 
> >On Wednesday, 10 August 2022 at 10:55:25 UTC+3, Mut...@dastardlyhq.com wrote: 
> >> The more pertinent question is why the C++ committee felt the need to 
> >> duplicate the functionality of typedef. 
> > 
> >That ship has sailed over decade ago and the answer was that there 
> >was need to create alias-templates that typedef does not let to.
>
> And the reason typedef couldn't have been extended to do them was.... ?

No one is capable to come out with suggestion how. Are you?
The typedef can be used by language rules something like that:

typedef int int_t, *intp_t, (&fp)(int, ulong), arr_t[10];

That declares aliases int_t, intp_t, fp and arr_t. How you extend it to 
declare  aliases int_t<K>, intp_t<L>, fp<M> and arr_t<N> instead?

> >> >Then proposed will be that we put clang-tidy into toolchain. It will 
> >> >automatically replace all typedefs with using before building and so 
> >> >one commit later there will be no typedefs in any code that team 
> >> >maintains manually. It is attractive to people bored of that 
> >> >bike-shedding. Tools that automatically replace using with typedef 
> >> >are missing so there are no way to resolve it sanely in other direction. 
> >> 
> >> On a large C++ unix project that only uses typedefs for defining types: 
> >> 
> >> grep typedef $(find -E . -regex ".*\.(h|hpp|cc|cpp)") 
> >> 
> >> will list all your definitions. Putting "using" in there will probably bring 
> > 
> >> back a whole load of crap you don't want. 
> > 
> >Majority are probably indifferent ... usage of grep to find aliases might 
> >feel like usage of #define to declare those. It is two levels below tools 
> >that their IDEs provide with keypress or two.
> 
> Clearly you've never done much serious development on *nix or had to develop/ 
> debug remotely down an ssh link. 

Majority are probably still indifferent. What I have or haven't done ever is
even less relevant to their opinion about usefulness of grep for finding aliases
in code-base. 

> And FWIW Eclipse is a slow steaming bug ridden POC.

OK ... then use CLion, works fine on Linux ... I think it was less than $200/year.

[toc] | [prev] | [next] | [standalone]

#85865

On Wed, 10 Aug 2022 11:13:16 -0700 (PDT)
=?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote:
>On Wednesday, 10 August 2022 at 11:21:32 UTC+3, Mut...@dastardlyhq.com wrote:
>> On Wed, 10 Aug 2022 01:13:05 -0700 (PDT) 
>> =?UTF-8?B?w5bDtiBUaWli?= <oot...@hot.ee> wrote: 
>> >On Wednesday, 10 August 2022 at 10:55:25 UTC+3, Mut...@dastardlyhq.com
>wrote: 
>> >> The more pertinent question is why the C++ committee felt the need to 
>> >> duplicate the functionality of typedef. 
>> > 
>> >That ship has sailed over decade ago and the answer was that there 
>> >was need to create alias-templates that typedef does not let to.
>>
>> And the reason typedef couldn't have been extended to do them was.... ?
>
>No one is capable to come out with suggestion how. Are you?
>The typedef can be used by language rules something like that:
>
>typedef int int_t, *intp_t, (&fp)(int, ulong), arr_t[10];
>
>That declares aliases int_t, intp_t, fp and arr_t. How you extend it to 
>declare  aliases int_t<K>, intp_t<L>, fp<M> and arr_t<N> instead?

Its 7 letters. Is there something magical about the 5 letters u-s-i-n-g?

>> >Majority are probably indifferent ... usage of grep to find aliases might 
>> >feel like usage of #define to declare those. It is two levels below tools 
>> >that their IDEs provide with keypress or two.
>> 
>> Clearly you've never done much serious development on *nix or had to
>develop/ 
>> debug remotely down an ssh link. 
>
>Majority are probably still indifferent. What I have or haven't done ever is
>even less relevant to their opinion about usefulness of grep for finding
>aliases
>in code-base. 

For majority read "windows devs". I'm not interested in how they develop or
what requirements they have. There was however a clear requirement for not
overloading a keyword yet again with the committee ignored.

>> And FWIW Eclipse is a slow steaming bug ridden POC.
>
>OK ... then use CLion, works fine on Linux ... I think it was less than
>$200/year.

Using command line tools is $0 a year.

[toc] | [prev] | [next] | [standalone]

#85868

On Friday, 12 August 2022 at 11:26:37 UTC+3, Mut...@dastardlyhq.com wrote:
> On Wed, 10 Aug 2022 11:13:16 -0700 (PDT)
> =?UTF-8?B?w5bDtiBUaWli?= <oot...@hot.ee> wrote: 
> >On Wednesday, 10 August 2022 at 11:21:32 UTC+3, Mut...@dastardlyhq.com wrote: 
> >> On Wed, 10 Aug 2022 01:13:05 -0700 (PDT) 
> >> =?UTF-8?B?w5bDtiBUaWli?= <oot...@hot.ee> wrote: 
> >> >On Wednesday, 10 August 2022 at 10:55:25 UTC+3, Mut...@dastardlyhq.com 
> >wrote: 
> >> >> The more pertinent question is why the C++ committee felt the need to 
> >> >> duplicate the functionality of typedef. 
> >> > 
> >> >That ship has sailed over decade ago and the answer was that there 
> >> >was need to create alias-templates that typedef does not let to. 
> >> 
> >> And the reason typedef couldn't have been extended to do them was.... ? 
> > 
> >No one is capable to come out with suggestion how. Are you? 
> >The typedef can be used by language rules something like that: 
> > 
> >typedef int int_t, *intp_t, (&fp)(int, ulong), arr_t[10]; 
> > 
> >That declares aliases int_t, intp_t, fp and arr_t. How you extend it to 
> >declare aliases int_t<K>, intp_t<L>, fp<M> and arr_t<N> instead?
> Its 7 letters. Is there something magical about the 5 letters u-s-i-n-g?
> >> >Majority are probably indifferent ... usage of grep to find aliases might 
> >> >feel like usage of #define to declare those. It is two levels below tools 
> >> >that their IDEs provide with keypress or two. 
> >> 
> >> Clearly you've never done much serious development on *nix or had to 
> >develop/ 
> >> debug remotely down an ssh link. 
> > 
> >Majority are probably still indifferent. What I have or haven't done ever is 
> >even less relevant to their opinion about usefulness of grep for finding 
> >aliases 
> >in code-base.
> 
> For majority read "windows devs". I'm not interested in how they develop or 
> what requirements they have. There was however a clear requirement for not 
> overloading a keyword yet again with the committee ignored.

That is just expressing some kind of weird bigotry about widespread operating
system. Business is not about whatever prejudice or religion, leave that to 
political groups. Windows hasn't  been among targets of my code during
last 2 years but that can change anytime.

> >> And FWIW Eclipse is a slow steaming bug ridden POC. 
> > 
> >OK ... then use CLion, works fine on Linux ... I think it was less than 
> >$200/year.
> Using command line tools is $0 a year.

Decent engineer costs about $200K/year so it is pointless to save 0.1%
of it and then waste her time with inadequate tools.

[toc] | [prev] | [next] | [standalone]

#85869

On Fri, 12 Aug 2022 03:38:14 -0700 (PDT)
=?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote:
>On Friday, 12 August 2022 at 11:26:37 UTC+3, Mut...@dastardlyhq.com wrote:
>> >Majority are probably still indifferent. What I have or haven't done ever
>is 
>> >even less relevant to their opinion about usefulness of grep for finding 
>> >aliases 
>> >in code-base.
>> 
>> For majority read "windows devs". I'm not interested in how they develop or 
>> what requirements they have. There was however a clear requirement for not 
>> overloading a keyword yet again with the committee ignored.
>
>That is just expressing some kind of weird bigotry about widespread operating
>system. Business is not about whatever prejudice or religion, leave that to 

Neither should language development. They could have extended typedefs 
functionality but they chose to overload using instead. Even from an english
semantic viewpoint the word "using" in a typedef context is illogical.
Might as well have used "for" or "case" for all the sense it makes.

>> Using command line tools is $0 a year.
>
>Decent engineer costs about $200K/year so it is pointless to save 0.1%
>of it and then waste her time with inadequate tools.

They're not inadequate, they work fine particularly for remote working which
most IDEs are not good at or can't do at all unless via RDP or similar.

[toc] | [prev] | [next] | [standalone]

#85872

On Friday, 12 August 2022 at 13:48:18 UTC+3, Mut...@dastardlyhq.com wrote:
> On Fri, 12 Aug 2022 03:38:14 -0700 (PDT) 
> =?UTF-8?B?w5bDtiBUaWli?= <oot...@hot.ee> wrote: 
> >On Friday, 12 August 2022 at 11:26:37 UTC+3, Mut...@dastardlyhq.com wrote: 
> >> >Majority are probably still indifferent. What I have or haven't done ever 
> >is 
> >> >even less relevant to their opinion about usefulness of grep for finding 
> >> >aliases 
> >> >in code-base. 
> >> 
> >> For majority read "windows devs". I'm not interested in how they develop or 
> >> what requirements they have. There was however a clear requirement for not 
> >> overloading a keyword yet again with the committee ignored. 
> > 
> >That is just expressing some kind of weird bigotry about widespread operating 
> >system. Business is not about whatever prejudice or religion, leave that to
> 
> Neither should language development. They could have extended typedefs 
> functionality but they chose to overload using instead. Even from an english 
> semantic viewpoint the word "using" in a typedef context is illogical. 

You did not explain how you would extend typedef to define alias templates.
AFAIK no one was capable to come out with good idea how. So your criticism
is meaningless. As that issue was already explained  in this thread it looks
like wilfully non-constructive nonsense.

> Might as well have used "for" or "case" for all the sense it makes.
> >> Using command line tools is $0 a year. 
> > 
> >Decent engineer costs about $200K/year so it is pointless to save 0.1% 
> >of it and then waste her time with inadequate tools.
> 
> They're not inadequate, they work fine particularly for remote working which 
> most IDEs are not good at or can't do at all unless via RDP or similar.

In discussion of CLion? CLion supports full remote mode, windows
subsystem for linux, remote debug and remote gdb server. With todays
latency and bandwidth of net who doesn't want CLion could just bluntly
use operating system tools for remote desktop without problems.

All that is rarely needed as most actual development goes using
distributed code repositories (free are market leaders) and continuous
integration (free are good enough) to build, deploy and run the tests.
During Covid it was especially apparent how far it all has evolved
and how cheap it is.

[toc] | [prev] | [next] | [standalone]

#85877

On Fri, 12 Aug 2022 04:54:47 -0700 (PDT)
=?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote:
>On Friday, 12 August 2022 at 13:48:18 UTC+3, Mut...@dastardlyhq.com wrote:
>> On Fri, 12 Aug 2022 03:38:14 -0700 (PDT) 
>> =?UTF-8?B?w5bDtiBUaWli?= <oot...@hot.ee> wrote: 
>> >On Friday, 12 August 2022 at 11:26:37 UTC+3, Mut...@dastardlyhq.com wrote: 
>> >> >Majority are probably still indifferent. What I have or haven't done
>ever 
>> >is 
>> >> >even less relevant to their opinion about usefulness of grep for finding 
>
>> >> >aliases 
>> >> >in code-base. 
>> >> 
>> >> For majority read "windows devs". I'm not interested in how they develop
>or 
>> >> what requirements they have. There was however a clear requirement for
>not 
>> >> overloading a keyword yet again with the committee ignored. 
>> > 
>> >That is just expressing some kind of weird bigotry about widespread
>operating 
>> >system. Business is not about whatever prejudice or religion, leave that to
>> 
>> Neither should language development. They could have extended typedefs 
>> functionality but they chose to overload using instead. Even from an english 
>
>> semantic viewpoint the word "using" in a typedef context is illogical. 
>
>You did not explain how you would extend typedef to define alias templates.

I've already asked if there's something magical about the word "using". 

typedef <var> = 

could use a different syntax to normal typedef but at least it would be the
same keyword.

>AFAIK no one was capable to come out with good idea how. So your criticism
>is meaningless. As that issue was already explained  in this thread it looks
>like wilfully non-constructive nonsense.

Which is your usual opinion if you disagree with someone. Like a lot of people
on this group you seem to believe your opinion is the only correct one.

>> They're not inadequate, they work fine particularly for remote working which 
>
>> most IDEs are not good at or can't do at all unless via RDP or similar.
>
>In discussion of CLion? CLion supports full remote mode, windows
>subsystem for linux, remote debug and remote gdb server. With todays
>latency and bandwidth of net who doesn't want CLion could just bluntly
>use operating system tools for remote desktop without problems.

It writing in fucking java so you can shove that POS where the sun doesn't 
shine. I don't need an IDE using gigabytes of memory just to edit and compile.
I could use Eclipse for that.

Also in a previous job I had to remote debug embedded linux systems running
on a low powered ARM with < 50M of memory. Let me know how I'd have done that 
using clion.

>All that is rarely needed as most actual development goes using
>distributed code repositories (free are market leaders) and continuous

LOL :) Oh you really don't have a clue do you Mr Desktop developer.

[toc] | [prev] | [next] | [standalone]

#85885

On Friday, 12 August 2022 at 17:34:46 UTC+3, Mut...@dastardlyhq.com wrote:
> On Fri, 12 Aug 2022 04:54:47 -0700 (PDT)
> =?UTF-8?B?w5bDtiBUaWli?= <oot...@hot.ee> wrote: 
> >On Friday, 12 August 2022 at 13:48:18 UTC+3, Mut...@dastardlyhq.com wrote: 
> >> On Fri, 12 Aug 2022 03:38:14 -0700 (PDT) 
> >> =?UTF-8?B?w5bDtiBUaWli?= <oot...@hot.ee> wrote: 
> >> >On Friday, 12 August 2022 at 11:26:37 UTC+3, Mut...@dastardlyhq.com wrote: 
> >> >> >Majority are probably still indifferent. What I have or haven't done 
> >ever 
> >> >is 
> >> >> >even less relevant to their opinion about usefulness of grep for finding 
> > 
> >> >> >aliases 
> >> >> >in code-base. 
> >> >> 
> >> >> For majority read "windows devs". I'm not interested in how they develop 
> >or 
> >> >> what requirements they have. There was however a clear requirement for 
> >not 
> >> >> overloading a keyword yet again with the committee ignored. 
> >> > 
> >> >That is just expressing some kind of weird bigotry about widespread 
> >operating 
> >> >system. Business is not about whatever prejudice or religion, leave that to 
> >> 
> >> Neither should language development. They could have extended typedefs 
> >> functionality but they chose to overload using instead. Even from an english 
> > 
> >> semantic viewpoint the word "using" in a typedef context is illogical. 
> > 
> >You did not explain how you would extend typedef to define alias templates.
> I've already asked if there's something magical about the word "using". 
> 
> typedef <var> = 
> 
> could use a different syntax to normal typedef but at least it would be the 
> same keyword.

Someone could indeed do something even far more confusing and so you
would bitch about that here. It was passable what they did.

> >AFAIK no one was capable to come out with good idea how. So your criticism 
> >is meaningless. As that issue was already explained in this thread it looks 
> >like wilfully non-constructive nonsense.

> Which is your usual opinion if you disagree with someone. Like a lot of people 
> on this group you seem to believe your opinion is the only correct one.

You have by now proven that you can't come out with grammar for
type alias template also you can't give any links to any proposals by others
so just a warm air.

> >> They're not inadequate, they work fine particularly for remote working which 
> > 
> >> most IDEs are not good at or can't do at all unless via RDP or similar. 
> > 
> >In discussion of CLion? CLion supports full remote mode, windows 
> >subsystem for linux, remote debug and remote gdb server. With todays 
> >latency and bandwidth of net who doesn't want CLion could just bluntly 
> >use operating system tools for remote desktop without problems.
> 
> It writing in fucking java so you can shove that POS where the sun doesn't 
> shine. I don't need an IDE using gigabytes of memory just to edit and compile. 
> I could use Eclipse for that. 

RAM is like $10 per gigabyte, why you keep constantly discussing things that
do not matter? That memory is not part of bill of material of product but
developer workstation.

> 
> Also in a previous job I had to remote debug embedded linux systems running 
> on a low powered ARM with < 50M of memory. Let me know how I'd have done that 
> using clion.

What madness you are talking about? Remote debugging worked fine already
in eighties with thousand times less memory and who puts source code onto
embedded system to grep it there? 

> >All that is rarely needed as most actual development goes using 
> >distributed code repositories (free are market leaders) and continuous
> LOL :) Oh you really don't have a clue do you Mr Desktop developer.

Giggling madly? Feel free to express whatever weird ideas about my work,
prejudice about programming languages, zealotry about tools, bigotry about
operating systems or dogmatism about how something should be used ... it
adds nothing to discussion. All such extremism and intolerance is reached
anyway without using logic but just being butt-hurt by something.

[toc] | [prev] | [next] | [standalone]

#85886

On Fri, 12 Aug 2022 08:34:20 -0700 (PDT)
=?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote:
>On Friday, 12 August 2022 at 17:34:46 UTC+3, Mut...@dastardlyhq.com wrote:
>> On Fri, 12 Aug 2022 04:54:47 -0700 (PDT)
>> >You did not explain how you would extend typedef to define alias templates.
>> I've already asked if there's something magical about the word "using". 
>> 
>> typedef <var> = 
>> 
>> could use a different syntax to normal typedef but at least it would be the 
>> same keyword.
>
>Someone could indeed do something even far more confusing and so you
>would bitch about that here. It was passable what they did.

Why would it be far more confusing that using a totally inappropriate keyword?
Or do you think "using" is a synonym for define? If so you should have a word
with your english teacher.

>> Which is your usual opinion if you disagree with someone. Like a lot of
>people 
>> on this group you seem to believe your opinion is the only correct one.
>
>You have by now proven that you can't come out with grammar for
>type alias template also you can't give any links to any proposals by others
>so just a warm air.

Clearly reading is not your strongpoint. Should I google translate stuff into
estonian just for you?

>> It writing in fucking java so you can shove that POS where the sun doesn't 
>> shine. I don't need an IDE using gigabytes of memory just to edit and
>compile. 
>> I could use Eclipse for that. 
>
>RAM is like $10 per gigabyte, why you keep constantly discussing things that
>do not matter? That memory is not part of bill of material of product but
>developer workstation.

"developer workstation"? You've heard of dev servers right? And they're not
just hosting one user. Oh sorry Mr Windows dev, multiuser is a novel concept 
for people like you.

>> Also in a previous job I had to remote debug embedded linux systems running 
>> on a low powered ARM with < 50M of memory. Let me know how I'd have done
>that 
>> using clion.
>
>What madness you are talking about? Remote debugging worked fine already
>in eighties with thousand times less memory and who puts source code onto
>embedded system to grep it there? 

face <- palm.

>> >All that is rarely needed as most actual development goes using 
>> >distributed code repositories (free are market leaders) and continuous
>> LOL :) Oh you really don't have a clue do you Mr Desktop developer.
>
>Giggling madly? Feel free to express whatever weird ideas about my work,

See above :) You really have no clue. Go back to Visual Studio.

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.c++

csiph-web