Re: "using" and "typedef"

[Alf P. Steinbach]

On 02.10.2016 00:11, Stefan Ram wrote:
> I am not sure I know all reasons why some people consider
> "using" to be better than "typedef". So far I am aware of:
>
> - "using" can be "templated" and
>
> - some deem the syntax of "using" to be "more natural"
> than the syntax of "typedef".
>
> So, are there yet other reasons?

`using` is a single general notation that covers everything that
`typedef` does and more.

In the same way, trailing return type, `auto`, is a single general
notation that covers everything that the old function declaration syntax
did, and more.

In my opinion one should simplify by using only the general notations,
because they are not more complex or uglier or more verbose than the old
notations that they replace, so there's no reason to use the old.


Cheers!,

- Alf

[Richard]

[Please do not mail me a copy of your followup]

"Alf P. Steinbach" <alf.p.stein...@gmail.com> spake the secret code
<nspkb9$lrb$1...@dont-email.me> thusly:

>In my opinion one should simplify by using only the general notations,
>because they are not more complex or uglier or more verbose than the old
>notations that they replace, so there's no reason to use the old.

The jury is still out on trailing return type as a "use all the time"
thing.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[JiiPee]

On 02/10/2016 01:27, Alf P. Steinbach wrote:
> On 02.10.2016 00:11, Stefan Ram wrote:
>> I am not sure I know all reasons why some people consider
>> "using" to be better than "typedef". So far I am aware of:
>>
>> - "using" can be "templated" and
>>
>> - some deem the syntax of "using" to be "more natural"
>> than the syntax of "typedef".
>>
>> So, are there yet other reasons?
>
> `using` is a single general notation that covers everything that
> `typedef` does and more.
>
> In the same way, trailing return type, `auto`, is a single general
> notation that covers everything that the old function declaration
> syntax did, and more.

some people, especially beginners, find auto a bit difficult becouse it
does not show what the actually type is.... I talked with them... so
they might prefer int.

>
>
>

[Öö Tiib]

What Alf meant by function declaration with trailing return
type, 'auto' was likely declaration of 'auto main() -> int' instead of
'int main()'. So actual type 'int' is explicitly present on both
cases.

[JiiPee]

On 02/10/2016 16:27, Öö Tiib wrote:
> 'auto main() -> int'


why is this better than

int main()


?

[Alf P. Steinbach]

Öö Tiib hasn't claimed that one of the declarations of `main` is better.


Cheers & hth.,

- Alf

[Scott Lurndal]

Ugly is relative. auto main(int, const char **, const char **) -> int is just plain ugly
and is useless when one cannot use the latest version of C++

[Juha Nieminen]

Alf P. Steinbach <alf.p.stein...@gmail.com> wrote:
> In the same way, trailing return type, `auto`, is a single general
> notation that covers everything that the old function declaration syntax
> did, and more.

There are situations where the trailing return type is needed
because the traditional syntax doesn't suffice. However, how many
real-life cases have you encountered of this, in your code or other
people's code? Not artificial constructed cases made up to demonstrate
the usage, but actual code.

In practice the need is so exceedingly rare that it just doesn't make
sense to always use the more cumbersome syntax just so that the 0.01%
of cases where it's actually needed would fit.

(Also, how many of those trailing return type examples are such that
it wouldn't work with just the 'auto' return type without explicitly
specifying the trailing type, as per C++14?)

--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---

[Öö Tiib]

On Tuesday, 11 October 2016 00:20:38 UTC+3, Juha Nieminen wrote:
> Alf P. Steinbach <alf.p.stein...@gmail.com> wrote:
> > In the same way, trailing return type, `auto`, is a single general
> > notation that covers everything that the old function declaration syntax
> > did, and more.
>
> There are situations where the trailing return type is needed
> because the traditional syntax doesn't suffice. However, how many
> real-life cases have you encountered of this, in your code or other
> people's code? Not artificial constructed cases made up to demonstrate
> the usage, but actual code.
>
> In practice the need is so exceedingly rare that it just doesn't make
> sense to always use the more cumbersome syntax just so that the 0.01%
> of cases where it's actually needed would fit.

Is it really more cumbersome on 99.99% of cases?

In practice if member functions returns something at all then it
is often object of some nested type or typedef. Lot of the member
functions are not defined inline. Such definition will actually have
slightly less stutter while declaration will have more:

// class
class Holder
{
using Value = int; // or whatever other nested type
// ...
Value getter(); // less bloat
auto taker()->Value; // more bloat
};

// stutter bloat
Holder::Value Holder::getter() { return 41; }

// no stutter
auto Holder::taker()->Value { return 42; }

I don't like it that much anyway ... but perhaps it is because I'm
getting old.

>
> (Also, how many of those trailing return type examples are such that
> it wouldn't work with just the 'auto' return type without explicitly
> specifying the trailing type, as per C++14?)

That variant wastes my time. I want to see some type not to conclude it
out from body.

[Juha Nieminen]

Öö Tiib <oot...@hot.ee> wrote:
>> (Also, how many of those trailing return type examples are such that
>> it wouldn't work with just the 'auto' return type without explicitly
>> specifying the trailing type, as per C++14?)
>
> That variant wastes my time. I want to see some type not to conclude it
> out from body.

I would say that if you are using an 'auto' return type, then the actual
type doesn't matter.

Also, C++17 will allow the return type to actually be variable, and
depend on the parameter types.

[Öö Tiib]

On Tuesday, 11 October 2016 09:05:41 UTC+3, Juha Nieminen wrote:
> Öö Tiib <oot...@hot.ee> wrote:
> >> (Also, how many of those trailing return type examples are such that
> >> it wouldn't work with just the 'auto' return type without explicitly
> >> specifying the trailing type, as per C++14?)
> >
> > That variant wastes my time. I want to see some type not to conclude it
> > out from body.
>
> I would say that if you are using an 'auto' return type, then the actual
> type doesn't matter.

When type of what a function returns does not matter? To me it usually
matters (if the function matters at all). Why it returns it if it does not
matter what it is?

I think about that 'auto' in function declaration as 'function' keyword
of Ada (as opposed to 'void' that can be imagined as 'procedure'
keyword of Ada).

>
> Also, C++17 will allow the return type to actually be variable, and
> depend on the parameter types.

It is possible that there won't ever be C++17 and also no one knows
what it will be. C++14 already did bring more damage than benefits.
Currently it seems that in committee are left only saboteurs from
companies like Apple, Oracle, Google, Microsoft, Amazon and IBM
that try to screw with it to each other. Perhaps we should boycott
those companies.

[Juha Nieminen]

Öö Tiib <oot...@hot.ee> wrote:
> When type of what a function returns does not matter?

Do you care, for example, what the exact type that std::bind() returns is?
Or do you only care what it *does*?

> It is possible that there won't ever be C++17 and also no one knows
> what it will be. C++14 already did bring more damage than benefits.
> Currently it seems that in committee are left only saboteurs from
> companies like Apple, Oracle, Google, Microsoft, Amazon and IBM
> that try to screw with it to each other. Perhaps we should boycott
> those companies.

Ah, you are only joking, I see.

[Öö Tiib]

On Wednesday, 12 October 2016 10:23:34 UTC+3, Juha Nieminen wrote:
> Öö Tiib <oot...@hot.ee> wrote:
> > When type of what a function returns does not matter?
>
> Do you care, for example, what the exact type that std::bind() returns is?
> Or do you only care what it *does*?

Now we are getting to philosophical ground and how I think. My view is
not universal, other people may think differently. A "type of it" *is* for
me "what it does". I dont know what 'std::bind' returns (because I use
lambdas that do same and more), but I assume that it is anonymous
functor type (similar like with lambdas).

So "type" for me is not "typename". However I like that types have name.
For example I liked that C++ did disallow anonymous structs and unions
and I disliked witdespread extension that allows those. If we can't name
something then it is probably too dim for us in essence and we need to
think more about it. Why type of value returned by 'std::bind' can not be
concretely 'std::lambda' or something like that? Fortunately there are
'decltype' and 'std::result_of' so I can name types myself when I want
names.

>
> > It is possible that there won't ever be C++17 and also no one knows
> > what it will be. C++14 already did bring more damage than benefits.
> > Currently it seems that in committee are left only saboteurs from
> > companies like Apple, Oracle, Google, Microsoft, Amazon and IBM
> > that try to screw with it to each other. Perhaps we should boycott
> > those companies.
>
> Ah, you are only joking, I see.

Somewhat. I am seriously worried about future of C++. Feeling is that
there are good ideas what to add but then they are adding syntax sugar
perversions instead. Why? The only rational explanation to it is sabotage.

[Juha Nieminen]

Öö Tiib <oot...@hot.ee> wrote:
> I dont know what 'std::bind' returns (because I use
> lambdas that do same and more)

Use the tool that's most convenient for the job at hand. std::bind() can be
shorter and cleaner than a lambda. For example:

auto rng = std::bind(std::uniform_int_distribution<>(0, 100),
std::mt19937(0));

int value = rng();

[Öö Tiib]

On Monday, 17 October 2016 09:05:11 UTC+3, Juha Nieminen wrote:
> Öö Tiib <oot...@hot.ee> wrote:
> > I dont know what 'std::bind' returns (because I use
> > lambdas that do same and more)
>
> Use the tool that's most convenient for the job at hand. std::bind() can be
> shorter and cleaner than a lambda. For example:
>
> auto rng = std::bind(std::uniform_int_distribution<>(0, 100),
> std::mt19937(0));
>
> int value = rng();

Sure, every feature has some use case where it lets to have terser
code. If the 'rng' object above is exactly what you need then great,
you made it with less characters typed. I usually want random bit
generators bound into functor by reference for to not copy it by
accident.