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

Groups > comp.lang.c > #97390

Re: Negative effects of c++ in C

Show all headers | View raw

On 24/11/16 01:34, Keith Thompson wrote:
> rockbrentwood@gmail.com writes:
> [...]
>> But here's one issue that's really hit the sore spot for me. The
>> "auto" keyword is woefully underused and ISO wants to waste a
>> perfectly good legacy by trashing it ... only to replace its natural
>> generalization with one of its 201x "keywords" (which look like warts
>> on the language).
> 
> The "auto" keyword is essentially useless in C, but C++ (starting in
> C++11, I think) has re-used the "auto" keyword for its own purposes.  I
> wouldn't mind if C followed suit, but there aren't as many advantages
> for C as for C++.
> 

gcc has the "__auto_type" for C that works mostly like "auto" in C++11.
 There are a few restrictions, such as only supporting a single variable
definition at a time (which is good practice anyway), but basically it
does the same job.

The primary motivation for it was to implement <stdatomic> type-generic
atomic macros in gcc.  These are, of course, part of the implementation,
so the compiler is free to use implementation-specific extensions to
make the macros.

But for those that are happy to use gcc extensions, __auto_type is
available in C.  And you can use "#define auto __auto_type", though I
think that is undefined behaviour according to the standards (but seems
to work fine in gcc, as long as you don't need the normal use of "auto"
in your code).

> In C++, this:
>     auto var = expr;
> causes var to have the type of expr.
> 
>> Take a close look at the places _thread_local is used. Inside a block
>> it may only occur with static or extern, while auto may never occur
>> with either. Outside it may freely be used, while auto may never be
>> used.
>>
>> The literal meaning of auto is to denote a variable that's heaped on
>> the call frame for a subroutine. But the ESSENTIAL meaning is to
>> denote a variable that's heaped on a separately called program thread
>> -- regardless of whether it's called as a subroutine or spawned as a
>> separate thread.
> 
> Subroutines/functions are not threads.  A called function executes in
> the same thread as its caller.
> 
>> In a unified framework that embodies both cases, a subroutine itself
>> may be regarded as equivalent to a thread that suspends its caller and
>> then resumes the caller when it returns.
> 
> What you call "a thread that suspends it caller", I call "not a thread".
> 
>> So, instead of phasing out the "auto" keyword only to replace it in
>> these other contexts by another (wart of a) keyword, just simply use
>> auto for all the contexts and do away with "thread_local" entirely.
> 
> _Thread_local (not _thread_local) is already in the language.  The word
> "auto" does not, to me, suggest the same thing that _Thread_local does.
> 

Agreed.

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

Thread

Negative effects of c++ in C jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-22 11:18 +0100
  Re: Negative effects of c++ in C Noob <root@127.0.0.1> - 2016-11-22 11:46 +0100
    Re: Negative effects of c++ in C jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-22 14:48 +0100
      Re: Big main() "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-22 21:51 +0800
      Re: Negative effects of c++ in C Noob <root@127.0.0.1> - 2016-11-22 15:29 +0100
      Re: Negative effects of c++ in C antispam@math.uni.wroc.pl - 2016-11-22 15:09 +0000
    Re: Negative effects of c++ in C jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-22 16:58 +0100
  Re: Negative effects of c++ in C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-22 14:29 +0000
    Re: Negative effects of c++ in C David Brown <david.brown@hesbynett.no> - 2016-11-22 15:58 +0100
      Re: Negative effects of c++ in C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-22 15:55 +0000
      Re: Negative effects of c++ in C jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-22 17:01 +0100
        Re: Negative effects of c++ in C Noob <root@127.0.0.1> - 2016-11-22 18:32 +0100
        Re: Negative effects of c++ in C David Brown <david.brown@hesbynett.no> - 2016-11-23 00:19 +0100
  [OT] It's only words... :) "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-22 22:55 +0800
    Re: [OT] It's only words... :) "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-22 22:57 +0800
  Re: Negative effects of c++ in C Ian Collins <ian-news@hotmail.com> - 2016-11-23 08:43 +1300
    Re: Negative effects of c++ in C jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-22 21:14 +0100
    Re: Negative effects of c++ in C jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-22 21:17 +0100
  Re: Negative effects of c++ in C rockbrentwood@gmail.com - 2016-11-23 15:41 -0800
    Re: Negative effects of c++ in C supercat@casperkitty.com - 2016-11-23 16:19 -0800
      Re: Negative effects of c++ in C David Brown <david.brown@hesbynett.no> - 2016-11-24 14:06 +0100
        Re: Negative effects of c++ in C supercat@casperkitty.com - 2016-11-24 07:36 -0800
          Re: Negative effects of c++ in C David Brown <david.brown@hesbynett.no> - 2016-11-25 00:23 +0100
            Re: Negative effects of c++ in C supercat@casperkitty.com - 2016-11-25 09:42 -0800
    Re: Negative effects of c++ in C Keith Thompson <kst-u@mib.org> - 2016-11-23 16:34 -0800
      Re: Negative effects of c++ in C David Brown <david.brown@hesbynett.no> - 2016-11-24 14:55 +0100

csiph-web