- A Standard Proposal: Remove forward declaration requirements - 5 Updates
- "Metaclasses: Thoughts on generative C++" 2017-07-26 by Herb Sutter - 3 Updates
- Reversing a Linked List using Recursion - 6 Updates
- Love God, Love People - 2 Updates
- Let us together create something the world desperately needs - 1 Update
- Atheist Scientist Becomes Christian After Researching Religions For Truth - 2 Updates
- optional va_args argument - 2 Updates
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jul 26 03:42PM -0400 This is the year 2017. Computers are powerful, and advanced and have algorithms for all kinds of compiler needs developed. The time of any component of a modern compiler REQUIRING forward declarations is long since past, save the needs of legacy software that was written for a system with that expectation. ----- What can be done to initiate a grass roots movement to remove the need for having forward declarations in upcoming C and C++ Standards? And just to be clear, I'm not saying we should remove the forward- declaration ability altogether, but just add a new option which removes the requirement of having it. I think some kind of compiler switch which disables the forward- declaration requirement, allowing an additional pass to be run on source code to resolve unknown references would be desirable. Thank you, Rick C. Hodgin |
| Lynn McGuire <lynnmcguire5@gmail.com>: Jul 26 03:55PM -0500 On 7/26/2017 2:42 PM, Rick C. Hodgin wrote: > source code to resolve unknown references would be desirable. > Thank you, > Rick C. Hodgin In C++'s strong typing system, how would you get rid of forward declarations ? I see them as a necessary evil as we have about 22 classes forward declared in our main app. Thanks, Lynn |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jul 26 05:44PM -0400 On 7/26/2017 4:55 PM, Lynn McGuire wrote: > In C++'s strong typing system, how would you get rid of forward > declarations ? I see them as a necessary evil as we have about 22 > classes forward declared in our main app. I don't propose getting rid of forward declarations, but enabling a switch that would allow them to not be required when the switch is in use. For many projects, it would only be a matter of allowing the def- inition for the thing you're referencing to be made somewhere in source code rather than already in source code. And when parsing on the first pass, you don't really do any parsing other than to lex and identify things that are known, though you could also save that for the next pass once you've loaded everything that may be resolved later in code. Thank you, Rick C. Hodgin |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Jul 26 11:18PM +0100 "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: <snip> > I don't propose getting rid of forward declarations, but enabling a > switch that would allow them to not be required when the switch is > in use. No change in the standard is required for that. And if the requirement *were* removed from the standard it could not mandate a switch or any other extra-linguistic mechanism for it. There might be a pre-defined macro that code could test, or a pragma to turn the option on or off, but nothing outside of C itself. The C standard has no jurisdiction there. <snip> -- Ben. |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Jul 26 11:37PM +0100 "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: <snip> > What can be done to initiate a grass roots movement to remove the need > for having forward declarations in upcoming C and C++ Standards? Implement it in a widely used compiler (gcc and clang are two obvious choices) and when/if it is seen to be useful and accepted a proposal would stand a reasonable chance of success. And even if it were to fail, the community would get the benefit (if any) from the feature. <snip> -- Ben. |
| Lynn McGuire <lynnmcguire5@gmail.com>: Jul 26 12:06PM -0500 "Metaclasses: Thoughts on generative C++" 2017-07-26 by Herb Sutter https://herbsutter.com/2017/07/26/metaclasses-thoughts-on-generative-c/ "I've been working on an experimental new C++ language feature tentatively called "metaclasses" that aims to make C++ programming both more powerful and simpler." Looks a little complicated to this old Fortran hacker. Lynn |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jul 26 09:24PM +0200 On 26.07.2017 19:06, Lynn McGuire wrote: > tentatively called "metaclasses" that aims to make C++ programming both > more powerful and simpler." > Looks a little complicated to this old Fortran hacker. I haven't looked at it but in Smalltalk terminology a metaclass is the class of class. Because in Smalltalk a class is an object, so, it's an object of some class: its metaclass. I fear if Herb's metaclasses are something else, then we're in for some terminological confusion. Anyway, the only C++ features that I miss – or that I see as clearly missing in the language – apart from modules, are support for covariant features, e.g. a clone method, and support for expressing const and non-const variants of a member function, in a concise & clear way. Cheers!, - Alf |
| David Brown <david.brown@hesbynett.no>: Jul 26 11:13PM +0200 On 26/07/17 21:24, Alf P. Steinbach wrote: > missing in the language – apart from modules, are support for covariant > features, e.g. a clone method, and support for expressing const and > non-const variants of a member function, in a concise & clear way. I'd like to see something Ada attributes for types. I had a little look at the proposed "reflections" for C++20, and they are an overly complex mess. It should be simple to get a compile-time method of doing things like converting enum names back and forth with values, or finding the maximum value in an enum. For a struct, you should be able to iterate over the data fields with name and types - it would be marvellous for database programming. This is all information that the compiler knows anyway, but it is inaccessible to the programmer. |
| David Brown <david.brown@hesbynett.no>: Jul 26 09:38AM +0200 On 25/07/17 23:27, Alf P. Steinbach wrote: > As I recall original Quicksort is O(n^2) worst case, which was > demonstrated by an adversarial algorithm (dynamically choosing data to > make any Quicksort bad) by one of the old Unix gurus. O(n²) time, but O(n) stack space for the basic naïve algorithm. It is not hard to modify the algorithm to have O(lg n) stack space, or to have near O(n . lg n) run time for almost all cases. > A recent improvement being considered as new basic sorting algorithm in > Boost, is O(n) worst case. O(n) is impossible for worst-case time, and unimpressive for scratch space or stack space. What is it measuring here? |
| David Brown <david.brown@hesbynett.no>: Jul 26 09:40AM +0200 On 26/07/17 01:26, Manfred wrote: > depth (and memory usage) is guaranteed a-priori to be bounded and within > implementation limits, /is/ correct - e.g an FFT implementation where > the sample size is fixed. That all sounds reasonable. Compilers can often turn recursive code into loops - but unless your implementation guarantees it, then relying on it to be sure your code will work is clearly not a good idea. |
| Tim Rentsch <txr@alumni.caltech.edu>: Jul 26 12:48AM -0700 > would run in O(1) space. There is some academic truth to the argument > that this may not be universally guaranteed, but that is, frankly, an > obtuse argument. I wasn't making an argument. I was giving an explanation, and trying to make a point. It's disappointing that more people didn't understand the difference between the two. > the fundamentals of the language's design, what looks like a perfectly > valid tail call may not be a tail call. Put another way, I would argue > that C++ is a language that does not *want* to be programmed that way. I believe that's a knee-jerk reaction based on how people are accustomed to thinking. Of course there are cases, and perhaps more often in C++, where using a recursive formulation is a bad choice. But there also are cases where it's a good choice. What I'm hoping to do is help people realize that there are different choices, and recognize which are which, rather than just continue the automatic "imperative good, recursive bad" chanting. > every change that may affect the tail-recursive function to make sure > that the compiler could figure out that it was still tail recursive, > that is -- and that seems like more effort than it's worth. Checking after every compile is done automatically as part of the make. As for whether it's worth the effort, if people don't try it they will never know either what effort is involved or what the payoff is. Thought experiments are notoriously unreliable. Don't you think people should at least try it out for a while before reaching a conclusion about how cost effective it is? > temporary objects being created through operator overloading, etc). > There is much to be said for code that is properly tail recursive > and for programming in that style, but this example is not it. I think that can be debated, but it's incidental to the more general discussion about when using a recursive writing is an appropriate choice. For most C or C++ developers, their automatic answer to that question is "Never, except maybe for things like binary trees or quicksort." I know a lot of those people will stay stuck in their imperative ruts. My hope is that some of them will realize the benefits of adopting a functional style in some cases, and develop a more balanced view of the two approaches, choosing between them appropriately rather than being either all one or all the other. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jul 26 10:19AM +0200 On 26.07.2017 09:38, David Brown wrote: >> Boost, is O(n) worst case. > O(n) is impossible for worst-case time, and unimpressive for scratch > space or stack space. What is it measuring here? Sorry, I meant O(n log n). I still don't recall the name of that beast etc. but I can try to find it later (in an hour or so). I need breakfast etc. :) Note, though, that while O(n) complexity appears unattainable, O(n) time is not impossible as a worst case. The simple spaghetti sort has O(n) time as worst case. You simply cut each strand of spaghetti so its length is proportional to one of the numbers to be sorted, and this is O(n) time; then you slam one end of the bundle against the kitchen table, which is O(1); and then you repeatedly remove and measure the spaghetti strand that's longest remaining, and this is also O(n) time. Cheers!, - Alf |
| David Brown <david.brown@hesbynett.no>: Jul 26 12:20PM +0200 On 26/07/17 10:19, Alf P. Steinbach wrote: > O(n) time; then you slam one end of the bundle against the kitchen > table, which is O(1); and then you repeatedly remove and measure the > spaghetti strand that's longest remaining, and this is also O(n) time. Certainly there are many ways of sorting that beat O(n log n) for worst case time complexity - but they rely on features of the data (like for bucket sort), or parallel processing (like your spaghetti sort). |
| Robert Wessel <robertwessel2@yahoo.com>: Jul 26 11:02AM -0500 On Wed, 26 Jul 2017 10:19:03 +0200, "Alf P. Steinbach" >Sorry, I meant O(n log n). >I still don't recall the name of that beast etc. but I can try to find >it later (in an hour or so). I need breakfast etc. :) You may be thinking of Musser's Introsort, which switches to Heapsort if Quicksort appears to be partitioning badly, thus guaranteeing O(n log n) behavior. This has been standard in C++ (and more recently in C) library implementations. There are, however, many sorts that are O(n log n) in the worst case. Quicksort (which has a O(n**2) worst case) tends to be faster than most other sorts when it's working well because it's inner loop is so simple. >O(n) time; then you slam one end of the bundle against the kitchen >table, which is O(1); and then you repeatedly remove and measure the >spaghetti strand that's longest remaining, and this is also O(n) time. If you allow parallel sorting O(log n) time is possible, although the hardware cost is usually absurd. O((log n)**2) is a more common limit, with algorithms that require "only" O(n (log n)**2) hardware. O(n) time is possible even with fairly simple parallel sorts, for example, you can do that with mergesort or Quicksort, with enough processors (for example, the final pass in a merge sort will require N steps, but the two sets being merged are of size N/2 and could have been built in parallel in N/2 time, etc.). There are several intermediate approaches as well. A challenge in parallel sorting is efficiency: usually very fast parallel sorts require much more work than less ambitious algorithms, but are capable of distributing that work over vast amounts of hardware. That's not a good tradeoff in many cases, where you'd like the sort to distribute, at reasonable cost, over a fairly limited number of nodes. |
| Leon Taylor <leontaylor476@gmail.com>: Jul 26 03:46AM -0700 On Tuesday, July 25, 2017 at 9:28:30 PM UTC+10, Rick C. Hodgin wrote: > around you. > Thank you, > Rick C. Hodgin Shut the fuck up Rick. Thanks, Leon |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jul 26 04:15AM -0700 Jesus Christ will forgive all who come to Him asking forgiveness. He will even forgive vile people. He wants to save us more than He wants to judge us because He loves us. The message of the cross is a love letter reading "Come, my love, be with me in Heaven." Thank you, Rick C. Hodgin |
| Leon Taylor <leontaylor476@gmail.com>: Jul 26 03:45AM -0700 On Friday, July 21, 2017 at 4:30:15 AM UTC+10, Rick C. Hodgin wrote: > I urge you ... please step forward and serve the Lord in this way. > Thank you, > Rick C. Hodgin lol you crack me up Rick |
| Juha Nieminen <nospam@thanks.invalid>: Jul 26 04:24AM > You will burn in eternal Hellfire in agony Says the person who is blatantly lying in the subject line of his post. I have said it before, and I say it again: You are a lying hypocrite. Go away, you lying hypocrite asshole. You are not getting any heaven points here. The only thing you are getting is becoming even more of a piece of shit than you already are. |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jul 26 02:14AM -0700 People do not earn their way into Heaven. It is the free gift of God to all who will receive Jesus, receive His sacrifice, and ask Him to forgive their sin. The things we do for Him in this world provide evidence of our salvation and conversion from flesh-only to flesh+spirit. Romans 10:9-13 (KJV) That if thou shalt confess with thy mouth the Lord Jesus, and shalt believe in thine heart that God hath raised him from the dead, thou shalt be saved. For with the heart man believeth unto righteousness; and with the mouth confession is made unto salvation. For the scripture saith, Whosoever believeth on him shall not be ashamed. For there is no difference between the Jew and the Greek: for the same Lord over all is rich unto all that call upon him. For whosoever shall call upon the name of the Lord shall be saved. There is no limitation as to who can be saved. The only thing now preventing people from being saved are the choices of the individual, the refusal to ask forgiveness, because Jesus will forgive everyone who comes to Him of every sin they committed for all time. Man is now the only one who will keep himself from being saved, Juha. Man's hard heart of rebellion and pride. Thank you, Rick C. Hodgin |
| Tim Rentsch <txr@alumni.caltech.edu>: Jul 25 08:40PM -0700 > va_list with NULL? > That would be much clearer. > NULL as a default value should be OK with nicely designed classes isn't it? The problem is NULL doesn't work portably for the va_list type, because of the possibility that it can be a non-array type. On some platforms there are good reasons to define va_list as an array type, and on other platforms reasons to define va_list as a non-array type. However we could define a macro NULL_VA_LIST so the declaration could read void SetErrorN( ErrorCode ec, int mc, const char* emf = NULL, va_list& args = NULL_VA_LIST ); which IMO is sufficiently descriptive (and perhaps a little better than using a regular lower-case variable name). Note btw that I say "macro", but it could be defined as a regular variable extern va_list NULL_VA_LIST; without clients needing to know the difference. > if (args == NULL) > rather than > if (&args == &empty_list) How about if ( is_null_va_list(args) ) ... which can be provided by a static inline function static inline bool is_null_va_list( va_list &list ){ return &list == &NULL_VA_LIST; } Of course I am expecting that NULL_VA_LIST and is_null_va_list() will both be defined in a single header file, so anyone who wants to use default va_list parameters would #include that one header. > figure out a common name for this object. "empty_va_list" is clear, > but other people could name it "no_args", and other va_list_default, > or... you see? If it were me I would simply go ahead with NULL_VA_LIST. It isn't perfect, but I think it's good enough. And using a reference type for the parameters means clients won't need to have their source code changed. |
| Tim Rentsch <txr@alumni.caltech.edu>: Jul 25 08:52PM -0700 >> ); > void foo( A args = A{} ) > {} Interesting. Surprising in a way that {}'s work but ()'s don't. I'm still digesting the differences between the two forms. Thank you. However using this form of initializer does not (AFAICT) allow a means of testing the parameter to see if it got a default value. Using a reference and 'empty_va_list' can do that. |
| 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