- Longest word in a dictionary problem -- which container - 1 Update
- We've won! - 3 Updates
| Vir Campestris <vir.campestris@invalid.invalid>: Nov 22 09:15PM On 19/11/2018 10:19, Paul wrote: > Below is my solution to finding the longest word in a dictionary given > a collection of letters. You want to rework your question. I think a dictionary is a list of words, so I'd read through it looking for the longest gap between two non-word characters. But it's apparent that isn't at all what you mean. Andy |
| "Öö Tiib" <ootiib@hot.ee>: Nov 22 03:50AM -0800 On Wednesday, 21 November 2018 22:57:30 UTC+2, David Brown wrote: > modern C++ compilers. It takes extra code space for the unwind tables - > these are rarely an issue (except for constraint-limited embedded > systems). The result of table-driven exception handling is faster overall than failure checking with branches when failures happen rarely (once among thousands of successes). That is paid with size of generated code. > compiling code which has an external call, the compiler does not know if > the function can throw an exception, and must order code on the > assumption that it might. If compiler does not know about potential exceptions then it also does not know about potential other side effects. > functions can skip having a stack frame. It has higher run-time speed > costs for code that does not throw an exception, but works faster when > an exception is thrown. Since the exceptions are part of function's interface the mechanism (and so the handling strategy) should be part of ABI. ABI has likely to pick one since allowing several in parallel would be likely most expensive. |
| Robert Wessel <robertwessel2@yahoo.com>: Nov 22 10:23AM -0600 On Tue, 20 Nov 2018 14:05:37 -0800, "Chris M. Thomasson" >> especially with routines that can be a bit larger, like qsort(). >Back in they day, I had to turn link time optimizations off for highly >sensitive synchronization algorithms. It was too scary to keep them on. That sounds more like problems with the synchronization routines. There would not be any worse problems with LTCG than if you happened to move the code for the routines into a single source file, and compiled that, or you used GCC (or similar) in the mode where it can compile several source files at once. Now it's easy to see how such a thing might happen. For example, a routine might depend on not being specialized and optimized into its caller so that it executes the required globally visible operations completely and in the desired order, but that only works if you're assuming things about the C implementation that are *not* required by the standard (or, often, most implementations). IOW, code that breaks because you turn LTCG on, is just broken. Just like code that fails when you turn (ordinary) optimization on. Compiler bugs excepted, of course. |
| "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Nov 22 12:48PM -0800 On 11/22/2018 8:23 AM, Robert Wessel wrote: >> Back in they day, I had to turn link time optimizations off for highly >> sensitive synchronization algorithms. It was too scary to keep them on. > That sounds more like problems with the synchronization routines. I just turned them off because of paranoia. > the standard (or, often, most implementations). > IOW, code that breaks because you turn LTCG on, is just broken. Just > like code that fails when you turn (ordinary) optimization on. There was no portable language guarantee about memory barriers and atomic operations back then. I made heavy use of assembly language in separately assembled files, (no inline). LTGC scared me. > Compiler bugs excepted, of course. Well, there was a problem with a GCC optimization that broke a POSIX mutex. It was an old post on comp.programming.threads: https://groups.google.com/d/topic/comp.programming.threads/Y_Y2DZOWErM/discussion |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment