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

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

Substitution failure can be an error

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

Contents

  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

Page 2 of 2 — ← Prev page 1 [2]

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

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.

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.

Andy

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

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

On Fri, 2019-11-22, Vir Campestris wrote:
> On 19/11/2019 11:48, Alf P. Steinbach wrote:
[...]

> 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 :(

"Use auto everywhere, and let your IDE tell you what the type is with
a tooltip".  I remember asking about that here some years ago -- what
people thought of that advise.  I don't remember a clear outcome, except
someone predicted we'd see a few years of auto abuse, followed by a
backlash.

> The argument is that given "x=4.2" you _know_ that x is a double, 
> there's no point in saying so.
>
> 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.

Reminds me of why I don't like Python so much: I find it easy to write
the code, but when I revisit it I have to backtrack through my own
duck typing stunts in order to find out what it actually does.

> 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 tend to agree.  I use auto, but try to be careful so it won't be a
problem when I revisit the code, like my duck typing exercises are in
Python.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

#70017 — Re: Almost Always Auto? (was Re: Substitution failure can be an

On 23 Nov 2019 09:29:01 GMT
Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
>On Fri, 2019-11-22, Vir Campestris wrote:
>> On 19/11/2019 11:48, Alf P. Steinbach wrote:
>[...]
>
>> 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 :(
>
>"Use auto everywhere, and let your IDE tell you what the type is with
>a tooltip".  I remember asking about that here some years ago -- what
>people thought of that advise.  I don't remember a clear outcome, except
>someone predicted we'd see a few years of auto abuse, followed by a
>backlash.

Its pretty stupid advice since not everyone uses or wants to use an IDE.
If find they just get in the way and offer little over a decent programmers
editor and standard command line tools on *nix. And as for Visual Shitshow on 
Windows, god almighty , how does anyone use that obtuse piece of garbage 
without going insane.  

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

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

Jorgen Grahn <grahn+nntp@snipabacken.se> writes:

> On Fri, 2019-11-22, Vir Campestris wrote:
>
>> 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 tend to agree.  I use auto, but try to be careful so it won't be a
> problem when I revisit the code, like my duck typing exercises are in
> Python.

I don't have a lot of experience with "auto" in C++, but a fair
amount of experience with type inference (and not needing type
annotations in many cases) in other programming languages.  I
don't have any hard and fast rule, but generally I find it works
well to give an explicit type annotation only in those cases
where it's important to know exactly what the type is.  Probably
this rule carries over into C++ reasonably well, although the
two situations are not completely parallel.  In particular, C++
doesn't have partial types, except maybe for arrays -- it's
pretty much all or nothing, either a completely specified type
or none at all;  there is no way in C++ to say a type is "a list
of something, but I won't say what the something is".  But I
think the general rule is still good in the C++ domain.

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

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

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

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

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

On 24.11.2019 00:26, Alf P. Steinbach wrote:
> [snip]
>
> 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;
>      }
> }

Oops. ">=", "<=". Oh well.

- Alf

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

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

On 24.11.2019 00:26, Alf P. Steinbach wrote:
> code that wouldn't even compile

Good idea to compile before posting, yes!

So here's the example, with a few instances of `auto` declarations of 
things where either the type is irrelevant, or already explicit:


#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 );
     const auto ascii_del = char( 127 );

     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

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

#70028 — Re: Almost Always Auto? (was Re: Substitution failure can be an

On Sun, 24 Nov 2019 00:26:14 +0100
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> wrote:
>auto main()
>     -> int

And the point of writing that instead of

int main()

is what exactly? Other than showing off of course.

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

#70039 — Re: Almost Always Auto? (was Re: Substitution failure can be an

On 2019-11-24, boltar@nowhere.co.uk <boltar@nowhere.co.uk> wrote:
> On Sun, 24 Nov 2019 00:26:14 +0100
> "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> wrote:
>>auto main()
>>     -> int
>
> And the point of writing that instead of
>
> int main()
>
> is what exactly? Other than showing off of course.

He doesn't like C++ ;)
>
>


-- 
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi --  Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi 
bili naoruzani. -- Mladen Gogala

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

#70056 — Re: Almost Always Auto? (was Re: Substitution failure can be an

On Sun, 24 Nov 2019 13:37:11 GMT
Melzzzzz <Melzzzzz@zzzzz.com> wrote:
>On 2019-11-24, boltar@nowhere.co.uk <boltar@nowhere.co.uk> wrote:
>> On Sun, 24 Nov 2019 00:26:14 +0100
>> "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> wrote:
>>>auto main()
>>>     -> int
>>
>> And the point of writing that instead of
>>
>> int main()
>>
>> is what exactly? Other than showing off of course.
>
>He doesn't like C++ ;)

He certainly doesn't like clear code. Devs like him piss me off - they make
simple things complicated for no reason other than to show boat and/or make
it hard for others to maintain the code and so keep themselves in a job.

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

#69928

On 11/18/2019 6:49 PM, Alf P. Steinbach 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; }
> 
> //-----------------------------------
> template< class Int >
> struct S
> {
>      using U = make_unsigned_t<Int>;
>      U m;
> 
>      S( Int x, Int ): m( U( x ) ) {}
> };
> 
> template< class Int >
> auto is_in( const S<Int>& s, const Int v )
>      -> bool
> { return true; }
> 
> auto main()
>      -> int
> { return 100 + is_in( {&cout, &cerr}, &clog ); }
> 
> 
> For now I've just used a `std::enable_if` to restrict `S` to integral 
> types, but I don't feel that this can be the best solution.
> 
> Like, it feels like a kludge, somewhat dirty.
> 
> 
> - Alf
> 

I'll steer away from the discussion about trailing return type (which 
has been discussed ad nauseam)

Substitution failure in this case happens for instantiation of a class 
member (m), after specialization of the template S.
So it looks like the error occurs too late to be eliminated by SFINAE.

I didn't check the standard, but Bjarne's book on SFINAE says that the 
compiler eliminates a candidate if the associated substitution would 
lead to a "template specialization that would be nonsensical" - now, 
define "nonsensical".
He says: "A template specialization is considered nonsensical if it 
would lead to a type error." And further on that only declarations are 
considered, neither function definitions nor definitions of class 
members are considered.

So, slippery, but we can say that SFINAE is not a fully baked tool for 
template selection. He himself suggests enable_if as a more specific 
tool for the task.
I would say that even if enable_if looks dirty, this is because of its 
syntactic ugliness, and it is probably the right choice.

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

#69946

On 20.11.2019 18:46, Manfred wrote:
> Bjarne's book on SFINAE

Uh, which book?

I remember introducing Bjarne to the term in a mail exchange, but it's 
apparently not in my GMail so it must be have been before July 2006.

- Alf

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

#69955

On 11/21/2019 6:02 AM, Alf P. Steinbach wrote:
> On 20.11.2019 18:46, Manfred wrote:
>> Bjarne's book on SFINAE
> 
> Uh, which book?
> 
> I remember introducing Bjarne to the term in a mail exchange, but it's 
> apparently not in my GMail so it must be have been before July 2006.
> 
> - Alf
read: Bjarne's book says on SFINAE ...
The C++ Programming Language (4th Edition), p. 692

However, it is curious that the following still fails:

template< class Int, class UInt = make_unsigned_t<Int> >
struct S
{
     // using UInt = make_unsigned_t<Int>;
     UInt m;

     S( Int x, Int ): m( UInt( x ) ) {}
};

The error is still about "invalid use of incomplete type", which sounds 
like a type error to me.

while

template< class Int, typename = typename 
enable_if<is_integral<Int>::value>::type
   >
struct S
{
   using UInt = make_unsigned_t<Int>;
   UInt m;

   S( Int x, Int ): m( UInt( x ) ) {}
};

seems to work fine.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web