Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Negative effects of c++ in C Date: Wed, 23 Nov 2016 16:34:20 -0800 Organization: None to speak of Lines: 49 Message-ID: References: <2bddc4e1-cdc2-465c-b3af-b5738f0cad94@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="4bb3765469ee7e914c6a7877adee9414"; logging-data="32490"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/gJMj/z0Fek4KHQPUipw5l" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:904jadeLf+7+OFu8oU/F11qieSg= sha1:WD4xvGSGhjPZZziuvhVtinA3PNs= Xref: csiph.com comp.lang.c:97375 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++. 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. -- Keith Thompson (The_Other_Keith) kst-u@mib.org Working, but not speaking, for JetHead Development, Inc. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"