Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #94192 > unrolled thread
| Started by | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| First post | 2016-09-28 09:35 -0700 |
| Last post | 2016-09-28 20:20 +0100 |
| Articles | 20 on this page of 135 — 24 participants |
Back to article view | Back to comp.lang.c
Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-09-28 09:35 -0700
Re: Is there any place to talk about language features? Keith Thompson <kst-u@mib.org> - 2016-09-28 09:39 -0700
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-09-28 09:46 -0700
Re: Is there any place to talk about language features? Richard Heathfield <rjh@cpax.org.uk> - 2016-09-28 17:53 +0100
Re: Is there any place to talk about language features? David Brown <david.brown@hesbynett.no> - 2016-09-28 21:21 +0200
Re: Is there any place to talk about language features? BartC <bc@freeuk.com> - 2016-09-28 20:36 +0100
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-09-28 13:55 -0700
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-09-28 14:02 -0700
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-09-29 10:03 +1300
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-09-28 14:13 -0700
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-09-29 10:22 +1300
Re: Is there any place to talk about language features? Robert Latest <boblatest@yahoo.com> - 2016-10-03 08:47 +0000
Re: Is there any place to talk about language features? James Kuyper <jameskuyper@verizon.net> - 2016-10-03 07:44 -0400
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-03 04:56 -0700
Re: Is there any place to talk about language features? BartC <bc@freeuk.com> - 2016-10-03 13:18 +0100
Re: Is there any place to talk about language features? BGB <cr88192@hotmail.com> - 2016-10-03 12:43 -0500
Re: Is there any place to talk about language features? Ike Naar <ike@iceland.freeshell.org> - 2016-10-03 21:43 +0000
Re: Is there any place to talk about language features? John Gordon <gordon@panix.com> - 2016-10-03 22:28 +0000
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-10-03 04:51 -0700
Re: Is there any place to talk about language features? BartC <bc@freeuk.com> - 2016-10-03 13:10 +0100
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-03 05:48 -0700
Re: Is there any place to talk about language features? BartC <bc@freeuk.com> - 2016-10-03 14:03 +0100
Re: Is there any place to talk about language features? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-03 14:24 +0100
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-03 07:07 -0700
Re: Is there any place to talk about language features? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-03 19:16 +0100
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-03 07:16 -0700
Re: Is there any place to talk about language features? supercat@casperkitty.com - 2016-10-03 07:45 -0700
Re: Is there any place to talk about language features? supercat@casperkitty.com - 2016-10-03 07:57 -0700
Re: Is there any place to talk about language features? James Kuyper <jameskuyper@verizon.net> - 2016-10-03 08:21 -0400
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-10-03 05:31 -0700
Re: Is there any place to talk about language features? supercat@casperkitty.com - 2016-10-03 06:43 -0700
Re: Is there any place to talk about language features? David Brown <david.brown@hesbynett.no> - 2016-10-03 15:08 +0200
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-09-28 14:22 -0700
Re: Is there any place to talk about language features? Keith Thompson <kst-u@mib.org> - 2016-09-28 15:16 -0700
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-09-28 16:08 -0700
Re: Is there any place to talk about language features? Keith Thompson <kst-u@mib.org> - 2016-09-28 16:57 -0700
Re: Is there any place to talk about language features? Keith Thompson <kst-u@mib.org> - 2016-09-28 14:19 -0700
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-09-28 14:50 -0700
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-09-28 17:03 -0700
Re: Is there any place to talk about language features? BartC <bc@freeuk.com> - 2016-09-29 01:08 +0100
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-09-28 17:33 -0700
Re: Is there any place to talk about language features? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-09-29 01:02 +0000
Re: Is there any place to talk about language features? BGB <cr88192@hotmail.com> - 2016-09-29 01:39 -0500
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-29 00:48 -0700
Re: Is there any place to talk about language features? BGB <cr88192@hotmail.com> - 2016-09-29 11:59 -0500
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-10-01 08:09 +1300
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-09-30 12:14 -0700
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-10-01 09:07 +1300
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-09-30 13:53 -0700
Re: Is there any place to talk about language features? Gareth Owen <gwowen@gmail.com> - 2016-09-30 22:13 +0100
Re: Is there any place to talk about language features? raltbos@xs4all.nl (Richard Bos) - 2016-10-01 09:36 +0000
Re: Is there any place to talk about language features? Jerry Stuckle <jstucklex@attglobal.net> - 2016-10-01 13:04 -0400
Re: Is there any place to talk about language features? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-09-30 14:20 -0700
Re: Is there any place to talk about language features? BartC <bc@freeuk.com> - 2016-09-30 22:30 +0100
Re: Is there any place to talk about language features? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2016-10-02 07:30 +0000
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-01 01:51 -0700
Re: Is there any place to talk about language features? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-01 10:31 +0100
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-10-01 23:22 +1300
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-01 06:15 -0700
Re: Is there any place to talk about language features? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-01 15:28 +0100
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-01 10:07 -0700
Re: Is there any place to talk about language features? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-01 19:52 +0100
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-10-02 20:38 +1300
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-02 03:37 -0700
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-10-03 08:35 +1300
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-02 15:17 -0700
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-10-03 18:29 +1300
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-03 01:09 -0700
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-10-04 08:21 +1300
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-03 13:12 -0700
Re: Is there any place to talk about language features? supercat@casperkitty.com - 2016-10-03 14:34 -0700
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-04 00:47 -0700
Re: Is there any place to talk about language features? Ike Naar <ike@iceland.freeshell.org> - 2016-10-04 07:49 +0000
Re: Is there any place to talk about language features? supercat@casperkitty.com - 2016-10-04 07:50 -0700
Re: Is there any place to talk about language features? Keith Thompson <kst-u@mib.org> - 2016-10-04 08:57 -0700
Re: Is there any place to talk about language features? supercat@casperkitty.com - 2016-10-04 10:42 -0700
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-10-05 15:47 +1300
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-04 20:58 -0700
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-10-05 18:14 +1300
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-05 02:15 -0700
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-10-05 22:44 +1300
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-05 03:12 -0700
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-10-06 15:38 +1300
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-05 19:50 -0700
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-10-06 16:25 +1300
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-05 21:19 -0700
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-10-06 18:11 +1300
Re: Is there any place to talk about language features? Gareth Owen <gwowen@gmail.com> - 2016-10-06 06:38 +0100
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-06 00:36 -0700
Re: Is there any place to talk about language features? gwowen <gwowen@gmail.com> - 2016-10-06 07:33 -0700
Re: Is there any place to talk about language features? supercat@casperkitty.com - 2016-10-06 09:00 -0700
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-07 00:32 -0700
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-10-07 05:05 -0700
Re: Is there any place to talk about language features? supercat@casperkitty.com - 2016-10-07 08:13 -0700
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-07 00:20 -0700
Re: Is there any place to talk about language features? Gareth Owen <gwowen@gmail.com> - 2016-10-07 17:01 +0100
Re: Is there any place to talk about language features? Les Cargill <lcargill99@comcast.com> - 2016-10-05 12:45 -0500
Re: Is there any place to talk about language features? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-05 11:12 +0100
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-05 03:15 -0700
Re: Is there any place to talk about language features? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-05 14:41 +0100
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-05 08:01 -0700
Re: Is there any place to talk about language features? supercat@casperkitty.com - 2016-10-05 08:41 -0700
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-05 10:29 -0700
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-10-05 12:29 -0700
Re: Is there any place to talk about language features? BartC <bc@freeuk.com> - 2016-10-05 11:08 +0100
Re: Is there any place to talk about language features? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-05 14:35 +0100
Re: Is there any place to talk about language features? BartC <bc@freeuk.com> - 2016-10-05 18:15 +0100
Re: Is there any place to talk about language features? supercat@casperkitty.com - 2016-10-05 10:38 -0700
Re: Is there any place to talk about language features? BartC <bc@freeuk.com> - 2016-10-05 19:14 +0100
Re: Is there any place to talk about language features? supercat@casperkitty.com - 2016-10-05 11:56 -0700
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-10-05 11:57 -0700
Re: Is there any place to talk about language features? Keith Thompson <kst-u@mib.org> - 2016-10-05 12:18 -0700
Re: Is there any place to talk about language features? David Brown <david.brown@hesbynett.no> - 2016-10-05 21:49 +0200
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-10-05 13:07 -0700
Re: Is there any place to talk about language features? "James R. Kuyper" <jameskuyper@verizon.net> - 2016-10-05 16:23 -0400
Re: Is there any place to talk about language features? David Brown <david.brown@hesbynett.no> - 2016-10-06 14:26 +0200
Re: Is there any place to talk about language features? supercat@casperkitty.com - 2016-10-05 13:56 -0700
Re: Is there any place to talk about language features? BartC <bc@freeuk.com> - 2016-10-06 14:17 +0100
Re: Is there any place to talk about language features? David Brown <david.brown@hesbynett.no> - 2016-10-06 15:53 +0200
Re: Is there any place to talk about language features? Keith Thompson <kst-u@mib.org> - 2016-10-06 09:12 -0700
Re: Is there any place to talk about language features? supercat@casperkitty.com - 2016-10-06 11:28 -0700
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-10-06 15:31 +1300
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-10-06 15:32 +1300
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-05 19:43 -0700
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-10-06 16:05 +1300
Re: Is there any place to talk about language features? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2016-10-02 07:24 +0000
Re: Is there any place to talk about language features? supercat@casperkitty.com - 2016-09-30 16:17 -0700
Re: Is there any place to talk about language features? raltbos@xs4all.nl (Richard Bos) - 2016-10-01 09:39 +0000
Re: Is there any place to talk about language features? supercat@casperkitty.com - 2016-10-01 14:11 -0700
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-09-29 07:47 -0700
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-09-29 10:25 -0700
Re: Is there any place to talk about language features? "James R. Kuyper" <jameskuyper@verizon.net> - 2016-09-28 12:59 -0400
Re: Is there any place to talk about language features? Richard Heathfield <rjh@cpax.org.uk> - 2016-09-28 18:30 +0100
Re: Is there any place to talk about language features? Keith Thompson <kst-u@mib.org> - 2016-09-28 12:10 -0700
Re: Is there any place to talk about language features? James Harris <james.harris.1@gmail.com> - 2016-09-28 20:20 +0100
Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7 Next page →
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-10-05 08:01 -0700 |
| Message-ID | <cdcd1de5-1e17-4eea-acae-5be492605578@googlegroups.com> |
| In reply to | #94480 |
On Wednesday, October 5, 2016 at 2:41:16 PM UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > On Wednesday, October 5, 2016 at 11:12:20 AM UTC+1, Ben Bacarisse wrote: > >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > >> > > > >> > You've hidden the goto. How do you think a C++ to C compiler implements > >> > throw? > >> > >> That's not a good argument. Function calls, 'while' loops and 'if' > >> statements also "hide the goto" and are all considered a good idea in > >> part because they do just that. If some construct is bad because it > >> hides a goto, the reason must be specific to that construct. > >> > > ifs and whiles are good idea because they don't allow the goto to jump out > > of or into a block. Not because the word 'goto" doesn't appear in the > > source. > > Right. So now I can work out your complaint about exceptions -- they > let you "jump out of the block" (though in what most people would > consider a relatively well-structured way). Yet you favour a goto which > jumps out of the bock. Maybe these are Malcolm-blocks. I seem to > remember that was a word you'd redefined from the usual meaning. > It's not a complaint about exceptions. My method does exactly the same thing, we jump out of the block (so it's no longer technically a structured programming block). One of the problems with the term "structured programming" is that the branding is too strong. if you don't use it, the result isn't necessarily an unstructured mess, aka "a bad program". But it is a program which cannot be expressed as a Malcolm-tree, which is all the subroutines from each call expanded out. It's not really a tree because we then need a special rule to accommodate recursion, so for that reason I recommend keeping recursion rare and only used in cases where data-recursive functions are too inconvenient. The gotos aren't structured, thought the functions themselves remain "blocks". You can if you want rewrite the function to eliminate the gotos, and whilst I'm not strongly opposed to that, I prefer gotos as it makes clear the difference between normal and error control paths, also because it tends to produce functions with less nesting. However exceptions are not superior to gotos because the mechanism is slightly obscured by the compiler.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-10-05 08:41 -0700 |
| Message-ID | <ea1c5dd5-e1f6-4974-83bc-796c172ee0ad@googlegroups.com> |
| In reply to | #94481 |
On Wednesday, October 5, 2016 at 10:04:07 AM UTC-5, Malcolm McLean wrote: > It's not a complaint about exceptions. My method does exactly the same thing, > we jump out of the block (so it's no longer technically a structured programming > block). One of the problems with the term "structured programming" is that > the branding is too strong. if you don't use it, the result isn't necessarily an > unstructured mess, aka "a bad program". But it is a program which cannot be > expressed as a Malcolm-tree, which is all the subroutines from each call > expanded out. It's not really a tree because we then need a special rule to > accommodate recursion, so for that reason I recommend keeping recursion > rare and only used in cases where data-recursive functions are too inconvenient. Many real-world problems can be expressed very cleanly as a combination of strictly-nested blocks without recursion. Many more can be expressed with clean nesting, but recursion added. Many other real-world problems, however, come close to fitting the "clean nesting" model, but have a few weird bits that don't fit. What's important should not be making the design of the code code fit a structured model, but making it fit the design of the application. Exceptions are one of the major impediments to using C++ in embedded systems, since the memory cost of having a compiler handle them automatically is often greater than would be the cost of code to manually handle error conditions. Within single- threaded applications, a paradigm that used a longjmp/setjmp model but allowed code to add handlers when entering a block and remove them when exiting a block might be more efficient, but such an approach would either require passing an "error-handling context" to every function that might need to make an emergency exit, or else keeping such context in a global variable. > However exceptions are not superior to gotos because the mechanism is slightly > obscured by the compiler. Exceptions offer structural guarantees which are not upheld by all possible free-form uses of goto. Such guarantees can be useful.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-10-05 10:29 -0700 |
| Message-ID | <6be6a773-3e71-46da-808f-c14cd8401765@googlegroups.com> |
| In reply to | #94483 |
On Wednesday, October 5, 2016 at 4:42:00 PM UTC+1, supe...@casperkitty.com wrote: > > Exceptions offer structural guarantees which are not upheld by all possible > free-form uses of goto. Such guarantees can be useful. > Not really. The guarantee is that the destructor does what it is supposed to do. If you add processing logic to destructors you can create a merry mess by throwing, catching, and doing your calculations in the destructors.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2016-10-05 12:29 -0700 |
| Message-ID | <44801da9-3b62-4fce-9c1c-cf488534a921@googlegroups.com> |
| In reply to | #94465 |
On Tuesday, October 4, 2016 at 11:47:32 PM UTC-3, Ian Collins wrote: > On 10/ 4/16 09:12 AM, Malcolm McLean wrote: > > On Monday, October 3, 2016 at 8:21:39 PM UTC+1, Ian Collins wrote: > >> On 10/ 3/16 09:09 PM, Malcolm McLean wrote: > >> > >> Do you not see how much easier such code is to write with automated > >> resource management? RAII allows the programmer (and the reader) to > >> focus on the higher level aspects of a solution without having to worry > >> about the trivia associated with resource management. > >> > > RAII is exactly the same as the system proposed by me, with the > > exception that code is executed without an explicit trace in the > > source. > > No it isn't. RAII exploits automatic creation and destruction of > objects used to manage resources. See This RAII, and resource management should be a separated topic. I think the resource management checks can be done in compile time. This has motivated me to create an C parser to try some experiments. Microsoft is doing some checkers for C++: C++ Core Guidelines Checkers: Preview of the Lifetime Safety checker https://blogs.msdn.microsoft.com/vcblog/2016/03/31/c-core-guidelines-checkers-preview-of-the-lifetime-safety-checker/ I think the unique_ptr in C++ is a try, but the compiler (not lib) can do a better job.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-10-05 11:08 +0100 |
| Message-ID | <nt2jem$19r$1@dont-email.me> |
| In reply to | #94408 |
On 03/10/2016 06:29, Ian Collins wrote: > On 10/ 3/16 11:17 AM, Malcolm McLean wrote: >> On Sunday, October 2, 2016 at 8:35:27 PM UTC+1, Ian Collins wrote: >>> >>> So you see the pattern of more and more complexity creeping into the >>> application code? >>> >> Not really. > > So you don't see each of your solutions becoming steadily more complex? You make it sound as though writing this stuff in C++ makes everything beautifully clean, clear and concise. But the C++ code I've seen is anything but that! The cleanest code might be with dynamic languages where most of the workings really are behind the scenes. And they are not bristling with syntax. C code wouldn't be anything like that but is usually much less sinister in appearance than C++. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-10-05 14:35 +0100 |
| Message-ID | <87ponezzoe.fsf@bsb.me.uk> |
| In reply to | #94472 |
BartC <bc@freeuk.com> writes: > On 03/10/2016 06:29, Ian Collins wrote: >> On 10/ 3/16 11:17 AM, Malcolm McLean wrote: >>> On Sunday, October 2, 2016 at 8:35:27 PM UTC+1, Ian Collins wrote: >>>> >>>> So you see the pattern of more and more complexity creeping into the >>>> application code? >>>> >>> Not really. >> >> So you don't see each of your solutions becoming steadily more complex? > > You make it sound as though writing this stuff in C++ makes everything > beautifully clean, clear and concise. No, that's your gloss. He makes it sound like exactly what he said: that Malcolm's simple solution has become more complex as more problems have been brought up. > But the C++ code I've seen is > anything but that! > > The cleanest code might be with dynamic languages where most of the > workings really are behind the scenes. And they are not bristling with > syntax. > > C code wouldn't be anything like that but is usually much less > sinister in appearance than C++. You are obsessed with syntax! What matters is how much code the programmer has to write and how many more opportunities there are for mistakes. Now I don't actually know if C++ reduces errors in this area or not (someone might have done a study -- I don't know) but the number of ::s and <>s in the code is not really the issue. Getting over even the ugliest syntax is a once-off learning exercise. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-10-05 18:15 +0100 |
| Message-ID | <nt3cem$ra5$1@dont-email.me> |
| In reply to | #94479 |
On 05/10/2016 14:35, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:
>
>> On 03/10/2016 06:29, Ian Collins wrote:
>>> On 10/ 3/16 11:17 AM, Malcolm McLean wrote:
>>>> On Sunday, October 2, 2016 at 8:35:27 PM UTC+1, Ian Collins wrote:
>>>>>
>>>>> So you see the pattern of more and more complexity creeping into the
>>>>> application code?
>>>>>
>>>> Not really.
>>>
>>> So you don't see each of your solutions becoming steadily more complex?
>>
>> You make it sound as though writing this stuff in C++ makes everything
>> beautifully clean, clear and concise.
>
> No, that's your gloss. He makes it sound like exactly what he said:
> that Malcolm's simple solution has become more complex as more problems
> have been brought up.
But C++ typically introduces other complexities to replace the ones that
it takes of behind the scenes.
>> But the C++ code I've seen is
>> anything but that!
>>
>> The cleanest code might be with dynamic languages where most of the
>> workings really are behind the scenes. And they are not bristling with
>> syntax.
>>
>> C code wouldn't be anything like that but is usually much less
>> sinister in appearance than C++.
>
> You are obsessed with syntax! What matters is how much code the
> programmer has to write and how many more opportunities there are for
> mistakes. Now I don't actually know if C++ reduces errors in this area
> or not (someone might have done a study -- I don't know) but the number
> of ::s and <>s in the code is not really the issue. Getting over even
> the ugliest syntax is a once-off learning exercise.
Syntax is important. Too much clutter can make it harder to discern the
code, or bugs within the code, or to see patterns that can be help with
detecting errors or with understanding. Badly designed syntax can make
programs more error prone (non-nesting /*...*/ for example).
And you don't get over something like C's (and C++'s) type declarations
so easily! Anyway how can you excuse something like this:
std::cout "A:" << a << "B:" << b << "C:" << c << std:endl
It makes C's version :
printf ("A:%d B:%d C:%d\n", a, b, c);
look almost clean. However I would normally write this as:
println =a, =b, =c
Which version do you think would most people prefer to write?
(The three aren't equivalent: the C version requires expression types to
be hard-coded which means it can't be used for a,b,c of any type. Two
typos (that I've just spotted; there could be more) have been left in
the C++ example.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-10-05 10:38 -0700 |
| Message-ID | <a6433da9-0904-4d3a-8a28-0d169d962bc6@googlegroups.com> |
| In reply to | #94484 |
On Wednesday, October 5, 2016 at 12:15:26 PM UTC-5, Bart wrote:
> (The three aren't equivalent: the C version requires expression types to
> be hard-coded which means it can't be used for a,b,c of any type. Two
> typos (that I've just spotted; there could be more) have been left in
> the C++ example.)
The design of "printf" trades off run-time complexity and code size for
compiler simplicity. A language could support type-safe variadic functions
in ways that would generate less code (often even at the call site, if one
could accept slower performance with argument extraction) than the va_list
approach, but it would require that the compiler know which functions needed
special variadic treatment [instead of passing a variable-sized object on the
stack, pass the address of that along with the address of an argument
descriptor; if the descriptor format can incorporate the addresses of global
variables or frame offsets for local variables, code equivalent to
printf("%d %d", someLocal, someGlobal, someLocal+someGlobal);
would only have to create a temp variable for "someLocal+someGlobal" and
pass the address of a descriptor which includes the offset of someLocal,
the address of someLocal, and the offset of the temporary.
Most functions wouldn't want the time overhead of parsing descriptors, but
for "printf"-style applications it wouldn't be any worse than parsing the
"%" strings.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-10-05 19:14 +0100 |
| Message-ID | <nt3ftn$8l2$1@dont-email.me> |
| In reply to | #94486 |
On 05/10/2016 18:38, supercat@casperkitty.com wrote:
> On Wednesday, October 5, 2016 at 12:15:26 PM UTC-5, Bart wrote:
>> (The three aren't equivalent: the C version requires expression types to
>> be hard-coded which means it can't be used for a,b,c of any type. Two
>> typos (that I've just spotted; there could be more) have been left in
>> the C++ example.)
>
> The design of "printf" trades off run-time complexity and code size for
> compiler simplicity.
Which it doesn't really achieve:
* Compilers often treat printf-family functions as special (so they
can warn on mismatched formats, or for optimising)
* The work of decoding the format is off-loaded into a library function,
which is likely to be part of the implementation
* To make it work, variadic functions need to be added to the language.
Which probably adds more complexity than just implement print
statements.
> A language could support type-safe variadic functions
> in ways that would generate less code (often even at the call site, if one
> could accept slower performance with argument extraction) than the va_list
> approach, but it would require that the compiler know which functions needed
> special variadic treatment [instead of passing a variable-sized object on the
> stack, pass the address of that along with the address of an argument
> descriptor; if the descriptor format can incorporate the addresses of global
> variables or frame offsets for local variables, code equivalent to
>
> printf("%d %d", someLocal, someGlobal, someLocal+someGlobal);
There are various ways, with printf-aware compilers, of implementing
printf without needing a general-purpose variadic feature.
(Or my approach would be to map a statement such as:
print(a,b);
into perhaps:
fprintint(stdout,a);
fprintint(stdout,b);
depending on a and b's types. Although that also needs a scheme to
optionally control the display format and width of each print item. It
/doesn't/ however need to know if it is int, char, string, long long
unsigned, float etc etc.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-10-05 11:56 -0700 |
| Message-ID | <c9552f9b-d297-4b56-9c37-8202053cbb4a@googlegroups.com> |
| In reply to | #94488 |
On Wednesday, October 5, 2016 at 1:14:38 PM UTC-5, Bart wrote: > On 05/10/2016 18:38, supercat wrote: > > * To make it work, variadic functions need to be added to the language. > Which probably adds more complexity than just implement print > statements. When printf was designed (I think it originated in the language B), and when it was first used in C, a compiler generating code for a function call would neither know nor care about the quantity and types of the expected arguments. Arguments would be placed in ascending order in memory (which would require that arguments be pushed in right-to-left or left-to-right order depending upon whether the stack grows up or down), and each would be either an int/pointer (B blurred the distinction between them) or a double. In later years, calling conventions became more complicated, but in the early years there was no need for compilers to do anything special with variadic functions. > There are various ways, with printf-aware compilers, of implementing > printf without needing a general-purpose variadic feature. Unfortunately, that only works with direct calls to "printf". There is no way to map such functionality into calls to functions which accept a variable set of arguments, turn it into a va_list, and pass that to a vprintf-family function.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2016-10-05 11:57 -0700 |
| Message-ID | <ea0cbf0c-6be5-4cbf-ac2b-69709877db5c@googlegroups.com> |
| In reply to | #94486 |
On Wednesday, October 5, 2016 at 2:38:55 PM UTC-3,
...
> The design of "printf" trades off run-time complexity and code size for
> compiler simplicity.
Some thoughts..
Compilers can check in compile time the printf arguments. (Visual Studio 2015 for instance does)
So, I was wondering that some compiler could possible generate inline and static code for printf.
printf("%d", 1); //compiler says: ok is "1"
printf("%d", i); //compiler says: ok is just itoa
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-10-05 12:18 -0700 |
| Message-ID | <ln4m4qr4e2.fsf@kst-u.example.com> |
| In reply to | #94491 |
Thiago Adams <thiago.adams@gmail.com> writes:
> On Wednesday, October 5, 2016 at 2:38:55 PM UTC-3,
> ...
>> The design of "printf" trades off run-time complexity and code size for
>> compiler simplicity.
>
> Some thoughts..
>
> Compilers can check in compile time the printf arguments. (Visual
> Studio 2015 for instance does)
Only if the format string is, or can be resolved to, a string literal --
which is the most common case, so it's a worthwhile check.
> So, I was wondering that some compiler could possible generate inline
> and static code for printf.
> printf("%d", 1); //compiler says: ok is "1"
> printf("%d", i); //compiler says: ok is just itoa
Yes, gcc does this. For example, it's able to compile
printf("%s\n", "hello");
as a call to puts().
It doesn't do the same for
printf("%d\n", 42);
probably (this is speculation) because constant arguments to "%d" are
not as common. There's certainly no fundamental reason it couldn't
compile that to the equivalent of `puts("42")`.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
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"
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-10-05 21:49 +0200 |
| Message-ID | <nt3lfb$t9k$1@dont-email.me> |
| In reply to | #94492 |
On 05/10/16 21:18, Keith Thompson wrote:
> Thiago Adams <thiago.adams@gmail.com> writes:
>> On Wednesday, October 5, 2016 at 2:38:55 PM UTC-3,
>> ...
>>> The design of "printf" trades off run-time complexity and code size for
>>> compiler simplicity.
>>
>> Some thoughts..
>>
>> Compilers can check in compile time the printf arguments. (Visual
>> Studio 2015 for instance does)
>
> Only if the format string is, or can be resolved to, a string literal --
> which is the most common case, so it's a worthwhile check.
>
>> So, I was wondering that some compiler could possible generate inline
>> and static code for printf.
>> printf("%d", 1); //compiler says: ok is "1"
>> printf("%d", i); //compiler says: ok is just itoa
>
> Yes, gcc does this. For example, it's able to compile
> printf("%s\n", "hello");
> as a call to puts().
>
> It doesn't do the same for
> printf("%d\n", 42);
> probably (this is speculation) because constant arguments to "%d" are
> not as common. There's certainly no fundamental reason it couldn't
> compile that to the equivalent of `puts("42")`.
>
It could be an issue with locales. I believe you can specify, via
locales, how the number is to be split up, and what "thousands
separator" you want. So the code has to call printf, because you might
have set the locale to use a colon for a separator, and split the number
every digit - giving "4:2" as the output.
I can't see any reason for the compiler not to turn printf("%d\n", 1)
into puts("1"), but I suppose it is simply not worth having such an
optimisation. (Or there is something more in locales that I haven't
noticed.)
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2016-10-05 13:07 -0700 |
| Message-ID | <ab98e1c0-9a01-4dd9-8e23-e0a446320d48@googlegroups.com> |
| In reply to | #94494 |
On Wednesday, October 5, 2016 at 4:49:22 PM UTC-3, David Brown wrote:
> On 05/10/16 21:18, Keith Thompson wrote:
> > Thiago Adams writes:
> >> On Wednesday, October 5, 2016 at 2:38:55 PM UTC-3,
> >> ...
> >>> The design of "printf" trades off run-time complexity and code size for
> >>> compiler simplicity.
> >>
> >> Some thoughts..
> >>
> >> Compilers can check in compile time the printf arguments. (Visual
> >> Studio 2015 for instance does)
> >
> > Only if the format string is, or can be resolved to, a string literal --
> > which is the most common case, so it's a worthwhile check.
> >
> >> So, I was wondering that some compiler could possible generate inline
> >> and static code for printf.
> >> printf("%d", 1); //compiler says: ok is "1"
> >> printf("%d", i); //compiler says: ok is just itoa
> >
> > Yes, gcc does this. For example, it's able to compile
> > printf("%s\n", "hello");
> > as a call to puts().
> >
> > It doesn't do the same for
> > printf("%d\n", 42);
> > probably (this is speculation) because constant arguments to "%d" are
> > not as common. There's certainly no fundamental reason it couldn't
> > compile that to the equivalent of `puts("42")`.
> >
>
> It could be an issue with locales. I believe you can specify, via
> locales, how the number is to be split up, and what "thousands
> separator" you want. So the code has to call printf, because you might
> have set the locale to use a colon for a separator, and split the number
> every digit - giving "4:2" as the output.
>
> I can't see any reason for the compiler not to turn printf("%d\n", 1)
> into puts("1"), but I suppose it is simply not worth having such an
> optimisation. (Or there is something more in locales that I haven't
> noticed.)
The compiler can generated the correct code.
The code associated with "int" is generated normally.
printf("%d", i);
All other run-time checks and ifs for "%s" can be removed. The compiler could call an internal func printf_int() for instance.
For this case:
printf("%d", 1);
Now it is not just remove "ifs" but the compiler can run the code and put the result.
--
constexpr is something in this line on C++.
int color = GetColor("red");
The compiler can run GetColor("red") in compile time or runtime.
GetColor can be implemented as:
constexpr int GetColor(const char *s)
{
return (s[0] == 'r' && s[1] == 'e' && s[2] == 'd') ? RED_CONST : BLUE_CONST;
}
I don't think this is a necessary feature for C, but I am just commenting on possibilities without changing the language.
Just a flag "try do to this at compile time if you can, if not, no problem "
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2016-10-05 16:23 -0400 |
| Message-ID | <63417349-6cc9-6d4e-a008-927255731f3d@verizon.net> |
| In reply to | #94494 |
On 10/05/2016 03:49 PM, David Brown wrote:
> On 05/10/16 21:18, Keith Thompson wrote:
...
>> Yes, gcc does this. For example, it's able to compile
>> printf("%s\n", "hello");
>> as a call to puts().
>>
>> It doesn't do the same for
>> printf("%d\n", 42);
>> probably (this is speculation) because constant arguments to "%d" are
>> not as common. There's certainly no fundamental reason it couldn't
>> compile that to the equivalent of `puts("42")`.
>>
>
> It could be an issue with locales. I believe you can specify, via
> locales, how the number is to be split up, and what "thousands
> separator" you want. So the code has to call printf, because you might
> have set the locale to use a colon for a separator, and split the number
> every digit - giving "4:2" as the output.
I believe that the decimal_point field of struct lconv is the only one
that affects the behavior of printf() when printing numeric quantities
(7.1.1p2), and "%d" makes no use of that field. There are no format
codes whose defined behavior involves using the current value of the
thousands_sep or grouping fields. Most of the other fields of that
struct apply only to monetary values, and the C standard library
provides no way to print monetary values making use of those fields.
Apparently, users are intended to call localeconv() to retrieve those
fields, and to write their own code making use of them.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-10-06 14:26 +0200 |
| Message-ID | <nt5fsn$olt$1@dont-email.me> |
| In reply to | #94496 |
On 05/10/16 22:23, James R. Kuyper wrote:
> On 10/05/2016 03:49 PM, David Brown wrote:
>> On 05/10/16 21:18, Keith Thompson wrote:
> ...
>>> Yes, gcc does this. For example, it's able to compile
>>> printf("%s\n", "hello");
>>> as a call to puts().
>>>
>>> It doesn't do the same for
>>> printf("%d\n", 42);
>>> probably (this is speculation) because constant arguments to "%d" are
>>> not as common. There's certainly no fundamental reason it couldn't
>>> compile that to the equivalent of `puts("42")`.
>>>
>>
>> It could be an issue with locales. I believe you can specify, via
>> locales, how the number is to be split up, and what "thousands
>> separator" you want. So the code has to call printf, because you might
>> have set the locale to use a colon for a separator, and split the number
>> every digit - giving "4:2" as the output.
>
> I believe that the decimal_point field of struct lconv is the only one
> that affects the behavior of printf() when printing numeric quantities
> (7.1.1p2), and "%d" makes no use of that field. There are no format
> codes whose defined behavior involves using the current value of the
> thousands_sep or grouping fields. Most of the other fields of that
> struct apply only to monetary values, and the C standard library
> provides no way to print monetary values making use of those fields.
> Apparently, users are intended to call localeconv() to retrieve those
> fields, and to write their own code making use of them.
OK.
It was just a possible explanation for why compilers (gcc and clang)
don't optimise prints of a compile-time-known number. I guess it's just
that no one has bothered writing such an optimisation into the compiler
- but it would be interesting to know if there is a more concrete reason
here.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-10-05 13:56 -0700 |
| Message-ID | <f50dfbfc-d64a-46e0-a87c-246c92d38930@googlegroups.com> |
| In reply to | #94492 |
On Wednesday, October 5, 2016 at 2:17:21 PM UTC-5, Keith Thompson wrote:
> Only if the format string is, or can be resolved to, a string literal --
> which is the most common case, so it's a worthwhile check.
It's not uncommon for library versions of printf to define useful behaviors
in cases where the Standard would impose no requirements. A compiler which
bundles its own standard library and includes no means of using anything
else might know exactly how its printf works, but since gcc relies upon the
user to supply library functions like printf it would be unhelpful for it to
make assumptions about how "printf" will behave in cases where its behavior
is not mandated by the Standard, bearing in mind that the Standard would say
nothing about the behavior of printf("%d",42); in cases where it is preceded
by calls to any implementation-specific function (which might enable special
formatting behaviors).
The substitution is actually a little dodgy even in the case where the
formatting string doesn't seem to contain any formatting characters, but
in embedded programs where *all* printf operations use constant strings
with no formatting characters, eliminating printf can save a lot of code
space. The value of such optimization in other cases is unlikely to be
sufficient to justify the behavioral anomalies that could result from
sometimes using gcc's built-in printf logic and sometimes using the
library's.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-10-06 14:17 +0100 |
| Message-ID | <nt5isi$36h$1@dont-email.me> |
| In reply to | #94492 |
On 05/10/2016 20:18, Keith Thompson wrote:
> Thiago Adams <thiago.adams@gmail.com> writes:
>> On Wednesday, October 5, 2016 at 2:38:55 PM UTC-3,
>> ...
>>> The design of "printf" trades off run-time complexity and code size for
>>> compiler simplicity.
>>
>> Some thoughts..
>>
>> Compilers can check in compile time the printf arguments. (Visual
>> Studio 2015 for instance does)
>
> Only if the format string is, or can be resolved to, a string literal --
> which is the most common case, so it's a worthwhile check.
>
>> So, I was wondering that some compiler could possible generate inline
>> and static code for printf.
>> printf("%d", 1); //compiler says: ok is "1"
>> printf("%d", i); //compiler says: ok is just itoa
>
> Yes, gcc does this. For example, it's able to compile
> printf("%s\n", "hello");
> as a call to puts().
>
> It doesn't do the same for
> printf("%d\n", 42);
> probably (this is speculation) because constant arguments to "%d" are
> not as common. There's certainly no fundamental reason it couldn't
> compile that to the equivalent of `puts("42")`.
The compiler can't dismiss that on the basis that the user could just
write printf("42\n") or puts(). The 42 could be hidden behind a macro,
or is an expression that is either compile-time, or that the compiler
can infer.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-10-06 15:53 +0200 |
| Message-ID | <nt5l0d$akk$1@dont-email.me> |
| In reply to | #94532 |
On 06/10/16 15:17, BartC wrote:
> On 05/10/2016 20:18, Keith Thompson wrote:
>> Thiago Adams <thiago.adams@gmail.com> writes:
>>> On Wednesday, October 5, 2016 at 2:38:55 PM UTC-3,
>>> ...
>>>> The design of "printf" trades off run-time complexity and code size for
>>>> compiler simplicity.
>>>
>>> Some thoughts..
>>>
>>> Compilers can check in compile time the printf arguments. (Visual
>>> Studio 2015 for instance does)
>>
>> Only if the format string is, or can be resolved to, a string literal --
>> which is the most common case, so it's a worthwhile check.
>>
>>> So, I was wondering that some compiler could possible generate inline
>>> and static code for printf.
>>> printf("%d", 1); //compiler says: ok is "1"
>>> printf("%d", i); //compiler says: ok is just itoa
>>
>> Yes, gcc does this. For example, it's able to compile
>> printf("%s\n", "hello");
>> as a call to puts().
>>
>> It doesn't do the same for
>> printf("%d\n", 42);
>> probably (this is speculation) because constant arguments to "%d" are
>> not as common. There's certainly no fundamental reason it couldn't
>> compile that to the equivalent of `puts("42")`.
>
> The compiler can't dismiss that on the basis that the user could just
> write printf("42\n") or puts(). The 42 could be hidden behind a macro,
> or is an expression that is either compile-time, or that the compiler
> can infer.
>
The compiler is allowed to do this sort of optimisation if the value is
known at compile-time. It doesn't matter if there are macros,
expressions, or anything else involved. It doesn't matter if it is not
a "constant expression". If the compiler can figure out that there is
no legal (i.e., due to behaviour defined by C or the implementation) way
for the expression to be anything other than a single known value, then
the compiler can use that value for optimisation.
If the compiler can't be sure that the value is always fixed, then
clearly it cannot perform such optimisations.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-10-06 09:12 -0700 |
| Message-ID | <lnzimhpich.fsf@kst-u.example.com> |
| In reply to | #94532 |
BartC <bc@freeuk.com> writes:
> On 05/10/2016 20:18, Keith Thompson wrote:
[...]
>> Yes, gcc does this. For example, it's able to compile
>> printf("%s\n", "hello");
>> as a call to puts().
>>
>> It doesn't do the same for
>> printf("%d\n", 42);
>> probably (this is speculation) because constant arguments to "%d" are
>> not as common. There's certainly no fundamental reason it couldn't
>> compile that to the equivalent of `puts("42")`.
>
> The compiler can't dismiss that on the basis that the user could just
> write printf("42\n") or puts(). The 42 could be hidden behind a macro,
> or is an expression that is either compile-time, or that the compiler
> can infer.
Of course that's true, and of course gcc or any other compiler
*could* optimize printf("%d\n", 42) to the equivalent of puts("42").
My speculation is that, even considering the cases where the
argument is not a constant but some expression that can be
evaluated at compile time, it just hasn't been considered worth
the effort to implement that particular optimization. There's no
fundamental principle at work here, just a tradeoff of effort.
I wouldn't be astonished to see a future version of gcc do this
optimization, perhaps just because some developer thought it would
be an interesting thing to implement.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
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"
[toc] | [prev] | [next] | [standalone]
Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web