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 1 of 3  [1] 2 3  Next page →

#72244 — overuse of auto is dangerous

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!

[toc] | [next] | [standalone]

#72245

On Thu, 2020-03-12, jacobnavia wrote:
> Consider:
>
> auto f = foo();
...
> Wouldn't it be better to write:
>
> TYPE_A F = foo();
>
> ????

Yes, sometimes.  "How often should we use auto?" is a question that
has been discussed here several times.  (By people who actually use
C++, want to use C++, and want to do it well.)

/Jorgen

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

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

#72247

On 13/03/2020 12:27, jacobnavia wrote:

Overuse of ice cream is dangerous but we still use it...

WATCH THAT ICE CREAM!

-- 
Ian.

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

#72249

On Thursday, March 12, 2020 at 8:57:31 PM UTC-4, Ian Collins wrote:
> On 13/03/2020 12:27, jacobnavia wrote:
> 
> Overuse of ice cream is dangerous but we still use it...
> 
Indeed, but it would be nice if it _could_ be used safely everywhere, 
irrespective of whether we chose to use it. But it can't, it doesn't work when 
functions return proxies.

Daniel

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

#72251

On 13/03/2020 14:16, Daniel wrote:
> On Thursday, March 12, 2020 at 8:57:31 PM UTC-4, Ian Collins wrote:
>> On 13/03/2020 12:27, jacobnavia wrote:
>>
>> Overuse of ice cream is dangerous but we still use it...
>>
> Indeed, but it would be nice if it _could_ be used safely everywhere,
> irrespective of whether we chose to use it. But it can't, it doesn't work when
> functions return proxies.

Ice cream always works!

-- 
Ian.

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

#72252

On Thursday, March 12, 2020 at 11:17:55 PM UTC-4, Ian Collins wrote:
> 
> Ice cream always works!
> 
Just so.

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

#72269

On 13.03.2020 04:48, Daniel wrote:
> On Thursday, March 12, 2020 at 11:17:55 PM UTC-4, Ian Collins wrote:
>>
>> Ice cream always works!
>>
> Just so.
> 

What's wrong with bacon?

- Alf

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

#72271

On Friday, March 13, 2020 at 4:27:11 PM UTC-4, Alf P. Steinbach wrote:
> On 13.03.2020 04:48, Daniel wrote:
> > On Thursday, March 12, 2020 at 11:17:55 PM UTC-4, Ian Collins wrote:
> >>
> >> Ice cream always works!
> >>
> > Just so.
> > 
> 
> What's wrong with bacon?
> 
Could be a proxy, vegan bacon, same interface, but ...

Daniel

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

#72248

On 3/12/20 8:27 PM, 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

I am completely agree with you. In my previous job I had the opportunity 
to work with a very large C++14/17 project (EOS/WAX blockchains). The 
temptation to use "auto" everywhere was big: easy to start using it, by 
later I discovered that it was very awful to read and use the code, 
especially when you don't have a good IDE (but surprise surprise, even 
the good IDEs have serious problems with auto).

--
Cholo Lennon
Bs.As.
ARG

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

#72250

On 2020-03-13 at 00:27, jacobnavia wrote:
> Consider:
> 
> auto f = foo();
> 
> What is "f"?

Easy, "f" is the return value of foo(). Probably some kind of iterator 
that you are just going to pass to one or more std::algorithm, so you 
don't really care to spell out its name.


> 
> 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();


You mean like

typename std::unordered_map<key, data, std::hash<key>, 
std::equal_to<key>, special_allocator<std::pair<const key, 
data>>>::const_iterator F = foo();


    Bo Persson

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

#72257

Le 13/03/2020 à 03:17, Bo Persson a écrit :
> On 2020-03-13 at 00:27, jacobnavia wrote:
>> Consider:
>>
>> auto f = foo();
>>
>> What is "f"?
> 
> Easy, "f" is the return value of foo(). Probably some kind of iterator 
> that you are just going to pass to one or more std::algorithm, so you 
> don't really care to spell out its name.
> 
> 
>>
>> 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();
> 
> 
> You mean like
> 
> typename std::unordered_map<key, data, std::hash<key>, 
> std::equal_to<key>, special_allocator<std::pair<const key, 
> data>>>::const_iterator F = foo();
> 

Well, I know that C++ can be very unreadable. Maintaining C++ can be a 
nightmare, but yes, I would prefer that long declaration since I know 
that at the end f should be a const_iterator (if I parsed that correctly 
from the template forest there).

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

#72258

On Friday, 13 March 2020 04:18:06 UTC+2, Bo Persson  wrote:
> On 2020-03-13 at 00:27, jacobnavia wrote:
> > Consider:
> > 
> > auto f = foo();
> > 
> > What is "f"?
> 
> Easy, "f" is the return value of foo(). Probably some kind of iterator 
> that you are just going to pass to one or more std::algorithm, so you 
> don't really care to spell out its name.
> 
> 
> > 
> > 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();
> 
> 
> You mean like
> 
> typename std::unordered_map<key, data, std::hash<key>, 
> std::equal_to<key>, special_allocator<std::pair<const key, 
> data>>>::const_iterator F = foo();

That seems to be one of main annoyances with C++. Compiler diagnostics,
debuggers and smart code editors will talk something like that about
generically constructed types used.

So I usually suggest to be helpful by using typedefs when constructing
such types:

    using KeyData      = std::pair<const Key, Data>;
    using KeyDataAlloc = special_allocator<KeyData>;
    using MapKeyToData = std::unordered_map<Key, Data, std::hash<Key>
                             , std::equal_to<Key>, KeyDataAlloc>;

Same way MapKeyToData::const_iterator can be declared if it is 
type of important citizens in code. Then that "poo" can be declared as;

    MapKeyToData::const_iterator poo();

Going "auto poo();" here feels already deliberate waste of readers time
even when the usual "poo" has more descriptive name.
Now that voids your example since the question becomes between:

    auto p = poo();

    MapKeyToData::const_iterator p = poo();

It can be clear enough with auto and also lot of code viewing tools
let to one-click navigate to declaration of that "poo" when unsure.

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

#72333

On 13/03/2020 08:14, Öö Tiib wrote:
<snip>
> So I usually suggest to be helpful by using typedefs when constructing
> such types:
> 
>      using KeyData      = std::pair<const Key, Data>;
>      using KeyDataAlloc = special_allocator<KeyData>;
>      using MapKeyToData = std::unordered_map<Key, Data, std::hash<Key>
>                               , std::equal_to<Key>, KeyDataAlloc>;
> 
> Same way MapKeyToData::const_iterator can be declared if it is
> type of important citizens in code. Then that "poo" can be declared as;
> 
>      MapKeyToData::const_iterator poo();

</snip>

This is the kind of thing I like. I use auto when I have to:

auto l = []() etc - lambdas have an unknown type

and when the meaning is obvious

auto p = std::make_unique< ...

Otherwise I avoid it. A lot of the time auto simplifies writing code, 
but makes reading it harder. And I expect to read it more often than I 
write it.

Andy

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

#72334

On 17/03/2020 10:35, Vir Campestris wrote:
> On 13/03/2020 08:14, Öö Tiib wrote:
> <snip>
>> So I usually suggest to be helpful by using typedefs when constructing
>> such types:
>>
>>       using KeyData      = std::pair<const Key, Data>;
>>       using KeyDataAlloc = special_allocator<KeyData>;
>>       using MapKeyToData = std::unordered_map<Key, Data, std::hash<Key>
>>                                , std::equal_to<Key>, KeyDataAlloc>;
>>
>> Same way MapKeyToData::const_iterator can be declared if it is
>> type of important citizens in code. Then that "poo" can be declared as;
>>
>>       MapKeyToData::const_iterator poo();
> 
> </snip>
> 
> This is the kind of thing I like. I use auto when I have to:
> 
> auto l = []() etc - lambdas have an unknown type
> 
> and when the meaning is obvious
> 
> auto p = std::make_unique< ...
> 
> Otherwise I avoid it. A lot of the time auto simplifies writing code,
> but makes reading it harder. And I expect to read it more often than I
> write it.

Those are excellent use cases, the first would be really messy to write 
without auto and the second would be needless repetition.  As a 
guideline, this is pretty much what we follow.  Another good use is for 
the return value from the likes of std::find.

-- 
Ian.

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

#72270

> typename std::unordered_map<key, data, std::hash<key>, 
> std::equal_to<key>, special_allocator<std::pair<const key, 
> data>>>::const_iterator F = foo();

Takes 20s to read, but auto is even more unreadable.

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

#72260

On 13/03/2020 00: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!
> 

What is the point you are trying to make with these posts?  That
features which are useful can also be misused?  Welcome to reality -
this is nothing new, either in programming languages or any other aspect
of life.

Drinking a glass of water is a good idea.  Sticking your head in a
bucket of water is a really bad idea.  Appropriate use of something is
good, excessive use or abuse is bad.  The same applies to using auto,
structured bindings, C macros, "if" statements, or Usenet.

If you don't like C++, don't use it.  If you don't want to support it in
your tools, that's fine (and understandable - it would be a massive
effort).  If you don't understand C++ or the purpose of its features
(this is apparent from your posts), either ask about it or drop it.  But
please stop whining.

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

#72261

On 13/03/2020 10:07, David Brown wrote:
> On 13/03/2020 00: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!
>>
> 
> What is the point you are trying to make with these posts?

Frustration with the way this spectacularly complex language is going?

> If you don't like C++, don't use it.  If you don't want to support it in
> your tools, that's fine (and understandable - it would be a massive
> effort).  If you don't understand C++ or the purpose of its features
> (this is apparent from your posts), either ask about it or drop it.  But
> please stop whining.

The consequences can perculate through even if you don't use the language.

I've experienced that extensively with C. Much less so with C++ but 
largely because I don't even bother trying to use libraries with C++ 
interfaces, or trying to port or understand bits of software written in 
C++, or attempting to build any open source code that uses C++.

Even using C, if someone wants to make use of VS for example, that IDE 
is heavily C++-centric.

However it is fascinating seeing how the language is developing, how it 
is totally incapable of taking a simple, straightforward approach to 
anything. Rule number one: every new feature must be arcane.

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

#72264

On 13/03/2020 11:39, Bart wrote:
> On 13/03/2020 10:07, David Brown wrote:
>> On 13/03/2020 00: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!
>>>
>>
>> What is the point you are trying to make with these posts?
> 
> Frustration with the way this spectacularly complex language is going?

If you don't like a language, don't use it.  If you don't know a
language, either learn about it or keep quite about it - it is pointless
to come to a language forum and complain about it.

I know only a little Ruby - but from what I have seen, it is an
unusually ugly and unclear language.  I have three choices.  First, I
could just ignore it and use other languages.  Second, I could put the
effort into studying it, learning it, writing code in it, and see if it
has advantages that outweigh my initial bad impression - after all, a
great many other people choose to use it.  Or third, I could go to a
Ruby Usenet group and grumble about how terrible I think it is.  Which
do you think is the smart choice?

With C, there is at least the vague excuse that as the lingua franca of
the software world, you often can't get entirely away from it even if
you don't like it.  That does not apply to C++.

> 
>> If you don't like C++, don't use it.  If you don't want to support it in
>> your tools, that's fine (and understandable - it would be a massive
>> effort).  If you don't understand C++ or the purpose of its features
>> (this is apparent from your posts), either ask about it or drop it.  But
>> please stop whining.
> 
> The consequences can perculate through even if you don't use the language.
> 
> I've experienced that extensively with C. Much less so with C++ but
> largely because I don't even bother trying to use libraries with C++
> interfaces, or trying to port or understand bits of software written in
> C++, or attempting to build any open source code that uses C++.
> 
> Even using C, if someone wants to make use of VS for example, that IDE
> is heavily C++-centric.
> 
> However it is fascinating seeing how the language is developing, how it
> is totally incapable of taking a simple, straightforward approach to
> anything. Rule number one: every new feature must be arcane.
> 

Some things in C++ are hard to understand.  But it is orders of
magnitude harder to understand how some people have such a hatred for
things they are basically clueless about as a result of determined
wilful ignorance.

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

#72283

Le 13/03/2020 à 14:26, David Brown a écrit :
> If you don't like a language, don't use it.  If you don't know a
> language, either learn about it or keep quite about it - it is pointless
> to come to a language forum and complain about it.

Well, as a user of comp.lang.c I have been reading about the problems 
with C by C++ heads since YEARS. They come to comp.lang.c to tell us how 
bad C is and how good C++ is with various arguments. We listen politely 
and answer them how do you do that in C, for instance when they say "C 
is lacking xxx"

I haven't seen answers like "If you do not like C do not use it and go 
away".

In this particular thread I am asking about your awareness about "auto" 
misfeatures and we seemed to agree that are problems with it.

I am not saying that C++ is a pile of shit or even that this construct 
should be taken away... I am pointing to the problems with it in the 
following context:

Many of the new features added to C++ aren't well THOUGHT OUT and 
provoke more problems than the ones they try to solve!

This is precisely why I think that continuing to add features each 3 
years to an already highly complex language is a recipe for DISASTER!

I singled out two of them: structured binding and auto but there are 
many more. Is it still possible to change the way the committee is working?

Instead of cheap polemic could you (maybe) reflect about that and 
express your opinion about that?

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

#72290

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

jacobnavia writes:

> Many of the new features added to C++ aren't well THOUGHT OUT and provoke  
> more problems than the ones they try to solve!

There are some like that, I do believe. But they're none of the ones you're  
having a cow about.

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

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

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

csiph-web