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

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

overuse of auto is dangerous

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

Contents

  overuse of auto is dangerous jacobnavia <jacob@jacob.remcomp.fr> - 2020-03-13 00:27 +0100
    Re: overuse of auto is dangerous Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-03-13 00:27 +0000
    Re: overuse of auto is dangerous Ian Collins <ian-news@hotmail.com> - 2020-03-13 13:57 +1300
      Re: overuse of auto is dangerous Daniel <danielaparker@gmail.com> - 2020-03-12 18:16 -0700
        Re: overuse of auto is dangerous Ian Collins <ian-news@hotmail.com> - 2020-03-13 16:17 +1300
          Re: overuse of auto is dangerous Daniel <danielaparker@gmail.com> - 2020-03-12 20:48 -0700
            Re: overuse of auto is dangerous "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2020-03-13 21:27 +0100
              Re: overuse of auto is dangerous Daniel <danielaparker@gmail.com> - 2020-03-13 13:35 -0700
    Re: overuse of auto is dangerous Cholo Lennon <chololennon@hotmail.com> - 2020-03-12 22:06 -0300
    Re: overuse of auto is dangerous Bo Persson <bo@bo-persson.se> - 2020-03-13 03:17 +0100
      Re: overuse of auto is dangerous jacobnavia <jacob@jacob.remcomp.fr> - 2020-03-13 08:51 +0100
      Re: overuse of auto is dangerous Öö Tiib <ootiib@hot.ee> - 2020-03-13 01:14 -0700
        Re: overuse of auto is dangerous Vir Campestris <vir.campestris@invalid.invalid> - 2020-03-16 21:35 +0000
          Re: overuse of auto is dangerous Ian Collins <ian-news@hotmail.com> - 2020-03-17 11:49 +1300
      Re: overuse of auto is dangerous Bonita Montero <Bonita.Montero@gmail.com> - 2020-03-13 21:27 +0100
    Re: overuse of auto is dangerous David Brown <david.brown@hesbynett.no> - 2020-03-13 11:07 +0100
      Re: overuse of auto is dangerous Bart <bc@freeuk.com> - 2020-03-13 10:39 +0000
        Re: overuse of auto is dangerous David Brown <david.brown@hesbynett.no> - 2020-03-13 14:26 +0100
          Re: overuse of auto is dangerous jacobnavia <jacob@jacob.remcomp.fr> - 2020-03-14 09:20 +0100
            Re: overuse of auto is dangerous Sam <sam@email-scan.com> - 2020-03-14 10:12 -0400
            Re: overuse of auto is dangerous David Brown <david.brown@hesbynett.no> - 2020-03-14 16:12 +0100
              Re: overuse of auto is dangerous Bart <bc@freeuk.com> - 2020-03-14 17:23 +0000
                Re: overuse of auto is dangerous David Brown <david.brown@hesbynett.no> - 2020-03-15 12:27 +0100
                  Re: overuse of auto is dangerous Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-03-15 15:41 -0700
                    Re: overuse of auto is dangerous Ian Collins <ian-news@hotmail.com> - 2020-03-16 13:37 +1300
                      Re: overuse of auto is dangerous Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-03-16 07:26 +0000
                        Re: overuse of auto is dangerous Sam <sam@email-scan.com> - 2020-03-16 07:05 -0400
                          Re: overuse of auto is dangerous David Brown <david.brown@hesbynett.no> - 2020-03-16 12:32 +0100
                            Re: overuse of auto is dangerous Sam <sam@email-scan.com> - 2020-03-16 08:21 -0400
                        Re: overuse of auto is dangerous Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-03-16 11:27 +0000
                    Re: overuse of auto is dangerous David Brown <david.brown@hesbynett.no> - 2020-03-16 09:11 +0100
                      Re: overuse of auto is dangerous Bart <bc@freeuk.com> - 2020-03-16 11:44 +0000
                        Re: overuse of auto is dangerous David Brown <david.brown@hesbynett.no> - 2020-03-16 13:29 +0100
                      Re: overuse of auto is dangerous Öö Tiib <ootiib@hot.ee> - 2020-03-16 05:35 -0700
                      Re: overuse of auto is dangerous James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-03-16 09:16 -0400
                    Re: overuse of auto is dangerous Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-04-02 07:13 -0700
                      Re: overuse of auto is dangerous James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-02 07:45 -0700
                        Re: overuse of auto is dangerous Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-02 10:25 -0700
                        Re: overuse of auto is dangerous Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-04-04 12:49 -0700
                          Re: overuse of auto is dangerous David Brown <david.brown@hesbynett.no> - 2020-04-05 14:15 +0200
                      Re: overuse of auto is dangerous Paavo Helde <myfirstname@osa.pri.ee> - 2020-04-02 19:20 +0300
                      Re: overuse of auto is dangerous Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-02 10:19 -0700
          Re: overuse of auto is dangerous Bonita Montero <Bonita.Montero@gmail.com> - 2020-03-15 16:26 +0100
      Re: overuse of auto is dangerous Daniel <danielaparker@gmail.com> - 2020-03-13 07:27 -0700
        Re: overuse of auto is dangerous Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-03-13 21:22 +0000
        Re: overuse of auto is dangerous Melzzzzz <Melzzzzz@zzzzz.com> - 2020-03-14 04:53 +0000
          Re: overuse of auto is dangerous Öö Tiib <ootiib@hot.ee> - 2020-03-14 03:23 -0700
            Re: overuse of auto is dangerous Melzzzzz <Melzzzzz@zzzzz.com> - 2020-03-14 13:20 +0000
              Re: overuse of auto is dangerous Öö Tiib <ootiib@hot.ee> - 2020-03-14 09:20 -0700
    Re: overuse of auto is dangerous Paavo Helde <myfirstname@osa.pri.ee> - 2020-03-13 13:53 +0200
    Re: overuse of auto is dangerous Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2020-03-13 15:46 +0000
    Re: overuse of auto is dangerous Sam <sam@email-scan.com> - 2020-03-13 23:09 -0400
    Re: overuse of auto is dangerous Bonita Montero <Bonita.Montero@gmail.com> - 2020-03-14 08:06 +0100
      Re: overuse of auto is dangerous Melzzzzz <Melzzzzz@zzzzz.com> - 2020-03-14 13:16 +0000
        Re: overuse of auto is dangerous Bonita Montero <Bonita.Montero@gmail.com> - 2020-03-16 15:31 +0100

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

#72756

On 2.04.2020 17:13, Tim Rentsch wrote:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Good reasons for using a different name for the same parameter in a
>> declaration and definition of a function?  I can't think of any.
>
> Do you think it's possible that, for reasons of their own,
> someone would deliberately choose to use a different name for
> some function parameter where the function is declared, as
> compared to where the function is defined, even though you
> can't think of any good reason to do so?

One possible reason would be to clarify a bad parameter name in the 
implementation, but to keep the header file unchanged to avoid 
"recompiling the world". Not sure if this is a good reason.

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

#72758

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 14/03/2020 18:23, Bart wrote:
>> [...]
>>>> C, and I assume C++, allows this:
>>>>
>>>>   void fn(int sum, int prod);
>>>>   void fn(int prod, int sum) {....}
>>>>
>>>> If only the declaration is visible at the call-site, it will be misleading.
>>>
>>> Yes.  That is one thing I strongly dislike about the languages, and it
>>> is a big hinder to having a simple system of named parameters.
>>> However, it is also clear that there are some /good/ reasons for
>>> allowing different names for parameters.
>>
>> [...]
>>
>> Good reasons for using a different name for the same parameter in a
>> declaration and definition of a function?  I can't think of any.
>
> Do you think it's possible that, for reasons of their own,
> someone would deliberately choose to use a different name for
> some function parameter where the function is declared, as
> compared to where the function is defined, even though you
> can't think of any good reason to do so?

The answer to this deeply uninteresting question is yes.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

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

#72303

> If you don't like a language, don't use it.

You can use the language not only in one way. And auto can make the
code less readable for those who've not written the code. I use it
only if absolutely necessary.

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

#72265

On Friday, March 13, 2020 at 6:07:33 AM UTC-4, David Brown wrote:
> On 13/03/2020 00:27, jacobnavia wrote:
> > 
> 
> If you don't like C++, don't use it.

On the contrary, jacobnavia has no reason to leave C++. jacobnavia is happy 
with legacy C++, their unhappiness is related to an ISO standards committee 
that is not limiting itself to standardizing existing practice, but seemingly 
trying to morph it into a new language. But jacobnavia will always have 
backwards compatible legacy C++.

It's those of us that _want_ C++ to become a modern language, and have 
reservations where that's going, that have to also think about leaving. But 
where to? 

Daniel

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

#72272

On Fri, 2020-03-13, Daniel wrote:
> On Friday, March 13, 2020 at 6:07:33 AM UTC-4, David Brown wrote:
>> On 13/03/2020 00:27, jacobnavia wrote:
>> > 
>> 
>> If you don't like C++, don't use it.
>
> On the contrary, jacobnavia has no reason to leave C++. jacobnavia is happy 
> with legacy C++,

That's not my impression at all.

> their unhappiness is related to an ISO standards committee 
> that is not limiting itself to standardizing existing practice, but seemingly 
> trying to morph it into a new language. But jacobnavia will always have 
> backwards compatible legacy C++.
>
> It's those of us that _want_ C++ to become a modern language, and have 
> reservations where that's going, that have to also think about leaving. But 
> where to? 

Stick to C++11, with the idioms you believe in. Cherry-pick the good
features from later standards.  Don't join teams which value novelty
higher than getting things done.

/Jorgen

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

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

#72278

On 2020-03-13, Daniel <danielaparker@gmail.com> wrote:
> On Friday, March 13, 2020 at 6:07:33 AM UTC-4, David Brown wrote:
>> On 13/03/2020 00:27, jacobnavia wrote:
>> > 
>> 
>> If you don't like C++, don't use it.
>
> On the contrary, jacobnavia has no reason to leave C++. jacobnavia is happy 
> with legacy C++, their unhappiness is related to an ISO standards committee 
> that is not limiting itself to standardizing existing practice, but seemingly 
> trying to morph it into a new language. But jacobnavia will always have 
> backwards compatible legacy C++.
>
> It's those of us that _want_ C++ to become a modern language, and have 
> reservations where that's going, that have to also think about leaving. But 
> where to? 

Rust.
>
> Daniel


-- 
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]

#72285

On Saturday, 14 March 2020 06:53:39 UTC+2, Melzzzzz  wrote:
> On 2020-03-13, Daniel <danielaparker@gmail.com> wrote:
> > On Friday, March 13, 2020 at 6:07:33 AM UTC-4, David Brown wrote:
> >> On 13/03/2020 00:27, jacobnavia wrote:
> >> > 
> >> 
> >> If you don't like C++, don't use it.
> >
> > On the contrary, jacobnavia has no reason to leave C++. jacobnavia is happy 
> > with legacy C++, their unhappiness is related to an ISO standards committee 
> > that is not limiting itself to standardizing existing practice, but seemingly 
> > trying to morph it into a new language. But jacobnavia will always have 
> > backwards compatible legacy C++.
> >
> > It's those of us that _want_ C++ to become a modern language, and have 
> > reservations where that's going, that have to also think about leaving. But 
> > where to? 
> 
> Rust.

What is the chance that when Rust ever gets out of kindergarten it won't
be spoiled by "contributors" from monster companies as well? These
companies have plenty of money to sabotage anything.

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

#72288

On 2020-03-14, Öö Tiib <ootiib@hot.ee> wrote:
> On Saturday, 14 March 2020 06:53:39 UTC+2, Melzzzzz  wrote:
>> On 2020-03-13, Daniel <danielaparker@gmail.com> wrote:
>> > On Friday, March 13, 2020 at 6:07:33 AM UTC-4, David Brown wrote:
>> >> On 13/03/2020 00:27, jacobnavia wrote:
>> >> > 
>> >> 
>> >> If you don't like C++, don't use it.
>> >
>> > On the contrary, jacobnavia has no reason to leave C++. jacobnavia is happy 
>> > with legacy C++, their unhappiness is related to an ISO standards committee 
>> > that is not limiting itself to standardizing existing practice, but seemingly 
>> > trying to morph it into a new language. But jacobnavia will always have 
>> > backwards compatible legacy C++.
>> >
>> > It's those of us that _want_ C++ to become a modern language, and have 
>> > reservations where that's going, that have to also think about leaving. But 
>> > where to? 
>> 
>> Rust.
>
> What is the chance that when Rust ever gets out of kindergarten it won't
> be spoiled by "contributors" from monster companies as well? These
> companies have plenty of money to sabotage anything.

So far, Rust eliminated lot of things from original language. From qutie
to monster. But it is ok so far. ML features are what is great about it
and they got right with error handling. Also proper `move` built into
language (destructors not get called after move and compiler errors if
one try to access them)
>


-- 
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]

#72292

On Saturday, 14 March 2020 15:20:46 UTC+2, Melzzzzz  wrote:
> On 2020-03-14, Öö Tiib <ootiib@hot.ee> wrote:
> > On Saturday, 14 March 2020 06:53:39 UTC+2, Melzzzzz  wrote:
> >> On 2020-03-13, Daniel <danielaparker@gmail.com> wrote:
> >> > On Friday, March 13, 2020 at 6:07:33 AM UTC-4, David Brown wrote:
> >> >> On 13/03/2020 00:27, jacobnavia wrote:
> >> >> > 
> >> >> 
> >> >> If you don't like C++, don't use it.
> >> >
> >> > On the contrary, jacobnavia has no reason to leave C++. jacobnavia is happy 
> >> > with legacy C++, their unhappiness is related to an ISO standards committee 
> >> > that is not limiting itself to standardizing existing practice, but seemingly 
> >> > trying to morph it into a new language. But jacobnavia will always have 
> >> > backwards compatible legacy C++.
> >> >
> >> > It's those of us that _want_ C++ to become a modern language, and have 
> >> > reservations where that's going, that have to also think about leaving. But 
> >> > where to? 
> >> 
> >> Rust.
> >
> > What is the chance that when Rust ever gets out of kindergarten it won't
> > be spoiled by "contributors" from monster companies as well? These
> > companies have plenty of money to sabotage anything.
> 
> So far, Rust eliminated lot of things from original language. From qutie
> to monster. But it is ok so far. ML features are what is great about it
> and they got right with error handling. Also proper `move` built into
> language (destructors not get called after move and compiler errors if
> one try to access them)

You misunderstood my question. Lets say Rust becomes mature enough
to be useful enough so some shops start to write real software in it.
What stops all those googles, amazons, microsofts, ibms, oracles and
apples to form intermonsternational standardization committee of
wormtongues and to screw it into oblivion within a decade like
with C++?

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

#72263

On 13.03.2020 1:27, jacobnavia wrote:
> Consider:
>
> auto f = foo();
>
> What is "f"?

Right, with a non-informative name like 'foo' auto should probably not 
be used. Auto should be used only if it increases readability:

for (auto& ref: mycontainer) {/*...*/}

auto myThread = std::make_unique<std::thread>(MyThreadFunc, par1, par2);

etc.

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

#72267

On 12/03/2020 23:27, jacobnavia wrote:
> Consider:
> 
> auto f = foo();
> 
> What is "f"?
> 
> Ahhh you have to figure out the return type of foo() of course. Great, there you go to your favorite IDE and try to jump to the correct definition of the foo() method in the correct class with the correct overload resolution...
> 
> Even worst... when you change the return type of foo() from type A to type Z, all the "auto" constructs will continue to compile AUTOmatically of course. Problem is, the type of "f" will have changed and that can provoke incomprehensible compile time errors further down or even run time errors in the form of access violation or whatever!
> 
> Wouldn't it be better to write:
> 
> TYPE_A F = foo();
> 
> ????
> 
> If the return type of foo() changes, an easy to catch compile time error will inform us that a change happened and that we have to revise the code according to the new interface of foo().
> 
> Besides, the maintenance programmer doesn't need to figure out anything: the type of "f" is there, for all to see.
> 
> WATCH THAT AUTO!
> 

auto is great: use almost everywhere .. with concepts it will be even better:

iterator i = foo();

/Flibble

-- 
"Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin

“You won’t burn in hell. But be nice anyway.” – Ricky Gervais

“I see Atheists are fighting and killing each other again, over who doesn’t believe in any God the most. Oh, no..wait.. that never happens.” – Ricky Gervais

"Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Byrne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say."

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

#72277

[Multipart message — attachments visible in raw view] — view raw

jacobnavia writes:

> Consider:
>
> auto f = foo();
>
> What is "f"?

Who cares.

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

#72279

Is there any IDE that can expand an auto to the usual declarations ?

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

#72287

On 2020-03-14, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Is there any IDE that can expand an auto to the usual declarations ?
VS?

-- 
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]

#72329

>> Is there any IDE that can expand an auto to the usual declarations ?

> VS?

VS only supports these tooltips when you fly over an auto. But
it shows the internal types to which the containers are mapped
and not the types you used in the definition / declaration.

[toc] | [prev] | [standalone]

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

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

csiph-web