Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: Uncle Steve Newsgroups: comp.lang.c Subject: Re: Non-constant initializers Date: Mon, 16 May 2011 22:42:12 -0400 Organization: Friends of the Galactic Collective Lines: 74 Message-ID: <51b3b3a156bb21a-0dbc8@gmail.com> References: <9322eedb3a632f5-29a98@gmail.com> <70b21f510c7390e-cc0de@gmail.com> <649063b2282a33c-c8c94@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Injection-Info: mx03.eternal-september.org; posting-host="9mti4zl2mrQmHFyxsa0q3g"; logging-data="17028"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/A4RBXgzHL8pc4btTEnKYV" User-Agent: nn 6.7.3 Content-Length: 3356 Cancel-Lock: sha1:lAcW4q82UXWh4HrVuUoo2yqPC3Y= Xref: x330-a1.tempe.blueboxinc.net comp.lang.c:4145 On Mon, May 16, 2011 at 09:37:57PM -0400, James Kuyper wrote: > On 05/16/2011 09:16 PM, Uncle Steve wrote: > ... > > Maybe, but I think you presume too much when you assume that the > > compiler should be the arbiter of optimization. Possibly some far-in- > > the-future compiler will have strong-AI capabilities wrt code > > generation, but until that time the human programmer will probably be > > able to do a better job than the compiler. All things being equal. > > Average C programmers fell behind compilers in their ability to perform > optimization at least a decade ago; probably more. An expert assembly > language programmer can still produce code that is better optimized than > a compiler can produce, But it would take that expert days to optimize > code that the compiler can optimize in seconds. It is, in most cases, a > horrible waste of time (==money) to let humans do something that > computers are so much better at. Algorithm development is a much more > profitable use of expensive human expertise than routine optimization. Yeah, well algorithm development isn't all that sexy these days. It's all about the Next! Great! Platform! like Java or whatever. Ruby looks good, and just as soon as I free up some CFT, I'm really going to check it out. > >>> [1] Joke. Not sure what the next revision of C will be called. I > >>> can't see there being many changes at this point, C should be about > >>> ready to be carved in stone by now. > >> > >> Nah, lots left to be done. > > > > Are you saying that there are major changes to the C standard in the > > offing? I don't see how that could be without changing fundamentals, > > and we all know that that is about as likely as porcine avians. > > The latest draft is dated 2010-12-02, and can be found at > > It summarizes the differences from C99 as follows: > > > — conditional (optional) features (including some that were previously mandatory) > > — support for multiple threads of execution including an improved memory sequencing > > model, atomic objects, and thread-local storage ( and > > ) > > — additional floating-point characteristic macros () > > — querying and specifying alignment of objects (, ) > > — Unicode characters and strings () (originally specified in > > ISO/IEC TR 19769:2004) > > — type-generic expressions > > — static assertions > > — anonymous structures and unions > > — no-return functions > > — macros to create complex numbers () > > — support for opening files for exclusive access > > — removed the gets function () > > — added the aligned_alloc, at_quick_exit, and quick_exit functions > > () > > — (conditional) support for bounds-checking interfaces (originally specified in > > ISO/IEC TR 24731−1:2007) > > — (conditional) support for analyzability Yikes! Well, I knew RDMA was going to make waves, but I haven't been programming with threads long enough to really get a feel for how it might affect the language. And then there's all that math stuff. I guess there really is a lot yet to do. Regards, Uncle Steve -- Should a professional politician be charged with molestation if he kisses babies while attending political rallies?