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

Groups > comp.lang.c++ > #70022

Re: Almost Always Auto? (was Re: Substitution failure can be an error)

Show all headers | View raw

On 22.11.2019 22:46, Vir Campestris wrote:
> On 19/11/2019 11:48, Alf P. Steinbach wrote:
>> On 19.11.2019 04:53, Melzzzzz wrote:
>>> On 2019-11-18, Alf P. Steinbach <alf.p.steinbach+usenet@gmail.com> 
>>> wrote:
>>>> As the title says, substitution failure can be an error:
>>>>
>>>>
>>>> #include <iostream>
>>>> #include <initializer_list>
>>>> #include <type_traits>
>>>> using namespace std;
>>>>
>>>> template< class Value >
>>>> auto is_in( const initializer_list<Value>& list, const Value v )
>>>>       -> bool
>>>> { return false; }
>>>
>>> why not just auto? What's the point of both auto and return type?
>>
>> It may be that you're asking about the syntax.
>>
>> Well, `auto f() -> T` for /trailing return type/ was introduced in C++11.
>>
>> Now that you have a name you can look it up.
>>
>> `auto` for /deduced return type/, like `auto f() { return 3; }` was 
>> introduced in C++14, almost like sabotage of the C++11 syntax.
>>
>> Apparently support for `auto auto`, writing `auto f() -> auto { return 
>> 3; }` in order to specify deduced return type explicitly, was 
>> introduced in C++17. But of this I'm less sure. Even though compilers 
>> I've tried accept the syntax I don't even know, 100%, that it's valid 
>> C++.
>>
>> ---
>>
>> It may alternatively be that you're asking why most C++ programmers 
>> still generally specify return types instead of using deduced return 
>> type.
>>
>> A deduced return type can be very convenient for e.g. a `begin()` 
>> member function that just defers the work to some member container's 
>> `begin()`.
>>
>> But a deduced return type can in the worst case mean that you have to 
>> delve to the bottom of an arbitrary long call chain in order to find 
>> out what the return type, that the compiler knows, is. On the way you 
>> may have to do overload resolution and template instantiation just 
>> like the compiler, to figure out where these calls go. You may have to 
>> use a debugger.
>>
>> That's just a waste of time for the programmer.
>>
>> And so it's strongly counter-productive to use this feature in general.
>>
>> ---
>>
>> If you meant the second interpretation, then I think a better question 
>> is whether there are programmers who regularly use deduced return 
>> type, and if so, what on Earth makes them do that counter-productive 
>> thing?
>>
>> In my opinion, if they exist, then they're likely a collection of 
>> total incompetents, the genuinely insane and maybe herd followers, 
>> just as with any group that does irrational things: some are insane, 
>> some don't understand any of it, and some (in religion that's most) 
>> follow the herd in order to derive social advantages, or avoid social 
>> disadvantage.
>>
>> But I would guess that any group of C++ programmers using deduced 
>> return type is not yet large enough that there would be any herd 
>> followers.
>>
>>
>> - Alf
> 
> That's interesting. That sound as if you're on my side of the "almost 
> always auto" argument I've heard bandied about - not least by the guy 
> who owns our coding standards :(
> 
> The argument is that given "x=4.2" you _know_ that x is a double, 
> there's no point in saying so.

It requires /reading/ with analysis and comprehension as opposed to just 
looking at.

And it fails for

     auto hm = 0x1'0000'0000;

This type depends on the compiler.


> I don't like it - that variable ought to be a type you know, and you 
> should say so. I find it easier to _read_ code that explicitly states 
> the types. OTOH, I've experimented, and it's easier to _write_ code that 
> uses auto everywhere.
> 
> When I read "auto x = somefunction()" I don't know what x is. Unless I 
> look at the declaration. Which if I'm unlucky is one of several 
> overloads with template type deduction from the parameters.
> 
> But IMHO reading matters more. You'll only write it once.

I prefer that the type is generally specified explicitly in a 
declaration, either on the left side or explicitly in the initializer.

Exception: types that are effectively or formally unspecified, such as 
iterator type or the type of an iostream manipulator.

Example, display the ASCII code:


#include <ctype.h>          // ::isprint
#include <iomanip>          // std::setw
#include <iostream>
#include <limits.h>         // CHAR_MIN, UCHAR_MAX

using Byte = unsigned char;

auto is_noncontrol_ascii_char( const int code )
     -> bool
{ return (code > CHAR_MIN and code < UCHAR_MAX and ::isprint( Byte( code 
) ); }

auto main()
     -> int
{
     using std::cout, std::endl, std::left, std::setw;
     constexpr auto& hex_digits = "0123456789abcdef";

     const auto field = setw( 4 );
     cout << left;

     // Column headers.
     cout << field << "";
     for( int x = 0; x < 16; ++x ) { cout << field << hex_digits[x]; }
     cout << endl;
     cout << endl;               // Spacer line to make the header row 
stand out as such.

     // Main table with a row header column to the left.
     for( int y = 0; y < 8; ++y ) {
         cout << field << hex_digits[y];
         for( int x = 0; x < 16; ++x ) {
             const int code = 16*y + x;
             const auto ch = char( is_noncontrol_ascii_char( code )? 
code: ascii::del );
             cout << field << ch;
         }
         cout << endl;
     }
}


- Alf

Back to comp.lang.c++ | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Substitution failure can be an error "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-11-18 18:49 +0100
  Re: Substitution failure can be an error Vir Campestris <vir.campestris@invalid.invalid> - 2019-11-18 21:54 +0000
  Re: Substitution failure can be an error Sam <sam@email-scan.com> - 2019-11-18 18:12 -0500
  Re: Substitution failure can be an error Melzzzzz <Melzzzzz@zzzzz.com> - 2019-11-19 03:53 +0000
    Re: Substitution failure can be an error "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-11-19 12:48 +0100
      Re: Substitution failure can be an error Melzzzzz <Melzzzzz@zzzzz.com> - 2019-11-19 19:48 +0000
        Re: Substitution failure can be an error "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-11-19 21:31 +0100
          Re: Substitution failure can be an error Melzzzzz <Melzzzzz@zzzzz.com> - 2019-11-19 21:20 +0000
            Re: Substitution failure can be an error "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-11-19 22:51 +0100
              Re: Substitution failure can be an error Melzzzzz <Melzzzzz@zzzzz.com> - 2019-11-19 21:58 +0000
            Re: Substitution failure can be an error David Brown <david.brown@hesbynett.no> - 2019-11-20 09:19 +0100
              Re: Substitution failure can be an error Öö Tiib <ootiib@hot.ee> - 2019-11-20 02:16 -0800
                Re: Substitution failure can be an error scott@slp53.sl.home (Scott Lurndal) - 2019-11-20 14:13 +0000
                Re: Substitution failure can be an error Öö Tiib <ootiib@hot.ee> - 2019-11-20 08:34 -0800
                Re: Substitution failure can be an error David Brown <david.brown@hesbynett.no> - 2019-11-21 12:34 +0100
                Re: Substitution failure can be an error Öö Tiib <ootiib@hot.ee> - 2019-11-21 05:29 -0800
                Re: Substitution failure can be an error David Brown <david.brown@hesbynett.no> - 2019-11-21 15:58 +0100
          Re: Substitution failure can be an error Christian Gollwitzer <auriocus@gmx.de> - 2019-11-20 11:12 +0100
            Re: Substitution failure can be an error Öö Tiib <ootiib@hot.ee> - 2019-11-20 04:25 -0800
              Re: Substitution failure can be an error Öö Tiib <ootiib@hot.ee> - 2019-11-20 06:05 -0800
      Almost Always Auto? (was Re: Substitution failure can be an error) Vir Campestris <vir.campestris@invalid.invalid> - 2019-11-22 21:46 +0000
        Re: Almost Always Auto? (was Re: Substitution failure can be an error) Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-11-23 09:29 +0000
          Re: Almost Always Auto? (was Re: Substitution failure can be an boltar@nowhere.co.uk - 2019-11-23 17:23 +0000
          Re: Almost Always Auto? (was Re: Substitution failure can be an error) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-28 12:46 -0800
        Re: Almost Always Auto? (was Re: Substitution failure can be an error) "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-11-24 00:26 +0100
          Re: Almost Always Auto? (was Re: Substitution failure can be an error) "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-11-24 00:28 +0100
          Re: Almost Always Auto? (was Re: Substitution failure can be an error) "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-11-24 00:45 +0100
          Re: Almost Always Auto? (was Re: Substitution failure can be an boltar@nowhere.co.uk - 2019-11-24 10:47 +0000
            Re: Almost Always Auto? (was Re: Substitution failure can be an Melzzzzz <Melzzzzz@zzzzz.com> - 2019-11-24 13:37 +0000
              Re: Almost Always Auto? (was Re: Substitution failure can be an boltar@nowhere.co.uk - 2019-11-25 11:08 +0000
  Re: Substitution failure can be an error Manfred <noname@add.invalid> - 2019-11-20 18:46 +0100
    Re: Substitution failure can be an error "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-11-21 06:02 +0100
      Re: Substitution failure can be an error Manfred <noname@add.invalid> - 2019-11-21 15:50 +0100

csiph-web