| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jul 26 08:29PM -0400 On 7/26/2017 8:15 PM, jacobnavia wrote: > Suppose a 3000 line GUI program that ends with > #include <windows.h> > UGGGGGG!!!!! While such a thing would be theoretically possible, why code like that? Just because an ability exists doesn't mean it should be exploited in such a way. My goals are primarily to resolve issues of interbred include files which contain definitions referenced in other include files. If you have a large enough system with enough structs or classes that reference one other in other header files in a crossover manner, it becomes increasingly difficult to ensure things are defined in the right order so you can reference members rather than just ptrs. I have spent a great deal of time in my Visual FreePro, Jr. project creating files that are loaded ahead of others, so they can refer- ence the members of things defined in other files. I have done this because I have a file that handles lexing, but it also knows about bitmaps, and the bitmap class handles bitmaps, but it also knows about lexing components so they can be rendered properly during debugging, etc. This type of interbred library mandates something more than what C/C++ offer in the way of forward declarations. With just that one relaxation, I would be able to include my bitmaps.h file, and my lexing.h file, and even though they reference components in each other, neither would produce an error, and no special or fancy programming workarounds would be required. Thank you, Rick C. Hodgin |
| David Brown <david.brown@hesbynett.no>: Jul 27 09:29AM +0200 On 26/07/17 23:44, Rick C. Hodgin wrote: > 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. The standards don't have "compiler switches" - that is something an implementation has. There is nothing to stop an implementation having such a switch if it wants, assuming it can be made to work properly. This is, in fact, an essential requirement for getting such a change into the C or C++ standards - it is expected that there be one or more /major/ compiler implementations of a feature that have undergone testing, evaluation and refinement. (By "major", I mean tools like gcc, clang, MSVC - not something like Jacob's compiler, fine tool though it may be. You need a large user base.) > 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. At first glance, I think it is likely that forward declarations could be made redundant - though I certainly have not given it serious thought. Basically, the compiler could first read through the file and whenever it finds a function definition, class definition, struct definition, etc., it could construct an appropriate forward declaration. Then it could artificially insert these into the code and compile as normal. It would be more of an inconvenience, I think, for other tools that parse code in a simpler way, such as highlighting editors. I suppose it all depends on your style of coding, but personally I rarely need forward declarations - so they are no bother to me. The only thing that annoys me about forward declarations is that some people insist on putting a list of them at the start of their files, regardless of their need - such lists can get inconsistent and are a maintenance irritation. |
| bartc <bc@freeuk.com>: Jul 27 11:07AM +0100 On 27/07/2017 08:29, David Brown wrote: > it finds a function definition, class definition, struct definition, > etc., it could construct an appropriate forward declaration. Then it > could artificially insert these into the code and compile as normal. It wouldn't need to be that crude. That might be what a separate tool would do to transform such C code into conventional C. (Actually, exactly what I used once, which identified local and export functions given stylised function definitions, and wrote out .cl and .cx header files respectively.) > It would be more of an inconvenience, I think, for other tools that > parse code in a simpler way, such as highlighting editors. This is not parsing, which stays the same. If it wants to colour different kinds of identifiers in different ways, then yes it might need to look ahead in the file, but it is not exactly a trivial task anyway as it needs to resolve variables, typedefs, macros, enum names, and labels as well as function names. (How does such an editor manage with C++?) > I suppose it all depends on your style of coding, but personally I > rarely need forward declarations - so they are no bother to me. I think everyone does unless they pay attention to the exact ordering of functions in a file. You're writing function F, and it calls G. Now you have to write G, but you have to make sure it precedes F (so you can no longer read your code top-down). You now modify F and it calls a new function H, and H is inserted between G and F. Later, you modify G to call H too. But now that won't work, because G won't see H. You have to now move H to just before G, or create (and have to maintain) a forward declaration of H. You can try inserting every new function at the top of the file, but then, such a function may need to call an existing function, so that won't work. Or, you write function F which calls G which then calls F; where does each go? This stuff happens ALL THE TIME. I can't understand how you've never come across it. > insist on putting a list of them at the start of their files, regardless > of their need - such lists can get inconsistent and are a maintenance > irritation. This is what the proposal will help eliminate. For local declarations anyway. For exported, shared functions, it would need a much bigger change to eliminate having to declare functions in headers. -- bartc |
| David Brown <david.brown@hesbynett.no>: Jul 27 02:01PM +0200 On 27/07/17 12:07, bartc wrote: > exactly what I used once, which identified local and export functions > given stylised function definitions, and wrote out .cl and .cx header > files respectively.) Certainly it can be done that way. There is the "cproto" program that does a fair amount of that already, which I believe was designed for automating the generation of function prototypes from old C90 and K&R C for use in C99. A similar idea could be used here, with the benefit that you don't need to change the C (or C++) compiler at all, nor the standards. > a trivial task anyway as it needs to resolve variables, typedefs, > macros, enum names, and labels as well as function names. (How does such > an editor manage with C++?) No, I agree it is not a trivial task - so it is not helpful to make it harder! > You're writing function F, and it calls G. Now you have to write G, but > you have to make sure it precedes F (so you can no longer read your code > top-down). Very roughly, you can do "top down" coding (write F first, then write G) or "bottom up" coding (write G first, then write F). If you put the definition of G earlier in the source than the definition of F, then you don't need forward declarations and your code /does/ read top-down if you think of "bottom up" coding. And it means that if you want to find the definition of a function you are using, you only need to look in one direction - up the file. That is not the way everyone likes to arrange their code in a file, but it is a perfectly valid, logical, consistent and readable way to do it. Modern editors and IDE (by "modern", I mean "this century") have no problem with multiple windows on the same file, showing "table of contents" or "outlines" of functions, jumping to definitions or declarations of functions, etc. > Later, you modify G to call H too. But now that won't work, because G > won't see H. You have to now move H to just before G, or create (and > have to maintain) a forward declaration of H. First, if you have a call graph where F calls G, and both F and G call H, you probably have a poor structure in your code. The exception would be when H is a more general utility-type function - and you would know that when writing H, and thus place it earlier in the code in the first place. Second, cut and paste to move H is a few seconds work - it is less effort than writing a forward declaration (even though that would not be a significant effort either). > You can try inserting every new function at the top of the file, but > then, such a function may need to call an existing function, so that > won't work. Just write your functions in a sensible order. Sometimes that means writing code that uses functions before they are defined, sometimes that means moving about a bit in the file before writing a new function. You are imagining problems - unless somehow I am unique in the way I write code. It is rare that I ever have to move a function definition around in code to get the order write, and rarer still that I ever need to make forward declarations for my static functions (all non-static functions have extern declarations in a matching header file). > Or, you write function F which calls G which then calls F; where does > each go? In the bin. Circular dependencies are almost always a terrible way to structure your code. And for my type of work, recursion of any sort should be met with extreme scepticism - stack space is limited, reliability is paramount, and you have to be /very/ sure of /hard/ upper limits for the recursion depths. More generally, of course, this is an occasions where a forward function declaration is necessary. > This stuff happens ALL THE TIME. I can't understand how you've never > come across it. No, it does not happen all the time - at least not when you have a plan of the code you are writing. > This is what the proposal will help eliminate. For local declarations > anyway. For exported, shared functions, it would need a much bigger > change to eliminate having to declare functions in headers. I eliminate these lists of static forward declarations by not having them. Problem solved. |
| bartc <bc@freeuk.com>: Jul 27 01:23PM +0100 On 27/07/2017 13:01, David Brown wrote: > you think of "bottom up" coding. And it means that if you want to find > the definition of a function you are using, you only need to look in one > direction - up the file. OK, so you have to worry about the ordering of functions in a file. (I've just grabbed the first source file to hand, and counted 92 functions.) > Second, cut and paste to move H is a few seconds work - it is less > effort than writing a forward declaration (even though that would not be > a significant effort either). So you have to think carefully about the ordering of functions in a file. And at maintaining that order. >> then, such a function may need to call an existing function, so that >> won't work. > Just write your functions in a sensible order. So you have think carefully ... etc > In the bin. Circular dependencies are almost always a terrible way to > structure your code. And for my type of work, recursion of any sort > should be met with extreme scepticism - stack space is limited, With my type of work, there is a lot of recursion (not just in languages but with any kind hierarchical data structure). > More generally, of course, this is an occasions where a forward function > declaration is necessary. So now you have to have declarations. >> come across it. > No, it does not happen all the time - at least not when you have a plan > of the code you are writing. So you have to plan the layout, which means thinking carefully etc > I eliminate these lists of static forward declarations by not having > them. Problem solved. Sorry, it isn't. You're 'solving' the problem by worrying about things and doing a bunch of work that would otherwise not be necessary. The proposal would do away with that leaving you free to concentrate on other things. -- bartc |
| David Brown <david.brown@hesbynett.no>: Jul 27 03:07PM +0200 On 27/07/17 14:23, bartc wrote: > OK, so you have to worry about the ordering of functions in a file. > (I've just grabbed the first source file to hand, and counted 92 > functions.) I don't worry about the order of functions - I can write code in an order that suits me without worrying. It is hard to tell, since I have written my C code this way for decades, but I don't believe it is a difficult habit to learn. And 92 functions in one file is, IMHO, a good deal too many. >> a significant effort either). > So you have to think carefully about the ordering of functions in a > file. And at maintaining that order. As I say, I don't have to think about it. And I don't have to "maintain the order" - my functions do not wander about inside their files when I am not looking. It is rare that I ever have to change the order of functions within a file - usually that will only happen when doing some major restructuring, in which case a bit of cut-and-paste is a negligible detail in the work. >>> won't work. >> Just write your functions in a sensible order. > So you have think carefully ... etc No - it does not take significant thought. It is really very, very simple. >> More generally, of course, this is an occasions where a forward function >> declaration is necessary. > So now you have to have declarations. Yes. I have not suggested, at any time, that you don't sometimes need forward declarations. I have only said that I very rarely need them (excluding, of course, declarations in a header for exported functions). If you are using recursion, you will need forward declarations on occasion. (The same applies to types - for most types, you do not need any kind of forward declarations. But for recursive structures, you do.) >> No, it does not happen all the time - at least not when you have a plan >> of the code you are writing. > So you have to plan the layout, which means thinking carefully etc When I start writing code, I have a pretty good idea of the basic structure of my code - the functions I will need, and which ones will call others. Then I know the order they will go in the file. I may or may not write them in that order - that will depend on the kind of code I am writing, how much testing I will be doing underway, etc. >> them. Problem solved. > Sorry, it isn't. You're 'solving' the problem by worrying about things > and doing a bunch of work that would otherwise not be necessary. As I said, ordering the code as I do does not involve work or effort, and certainly not worry. You are imagining a problem that does not exist - simply because it means doing something in a way that is different from your own habits. > The proposal would do away with that leaving you free to concentrate on > other things. It would change /nothing/ for me. |
| Robert Wessel <robertwessel2@yahoo.com>: Jul 27 11:57AM -0500 On Thu, 27 Jul 2017 09:29:05 +0200, David Brown >insist on putting a list of them at the start of their files, regardless >of their need - such lists can get inconsistent and are a maintenance >irritation. While I have no real objection to making forward declarations option in C, and it's certainly been done in many other languages, I've not really thought about it enough to consider if there are any hidden pitfalls (one of the big ones would have been the implicit definitions which are no longer allowed). But you could almost certainly make such a thing work for the vast majority of functions, and so long as the language were defined in such a way that the compiler can diagnose any remaining cases. OTOH, while this might be a nice enhancement, it's a pretty small one in terms of usability as far as I'm concerned. My list of things I want improved in C (and C++) has a bunch of stuff I'd rate as having much higher importance/significance than this change. So while I'd not really object on any technical grounds, I'd object on the grounds of this being an inappropriate priority. OTTH, the C committee really doesn't pay much attention to my objections... |
| Vir Campestris <vir.campestris@invalid.invalid>: Jul 27 08:57PM +0100 On 27/07/2017 13:01, David Brown wrote: <snip> > Second, cut and paste to move H is a few seconds work - it is less > effort than writing a forward declaration (even though that would not be > a significant effort either). </snip> You must have a very clever source control system. I've never seen one that will distinguish "This lump of code has been moved" from "This lump has been inserted, and that one deleted". Which becomes really interesting in reviews, when you really need to know whether it has been changed slightly when it moved. Andy |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jul 27 04:18PM -0400 On 7/27/2017 3:57 PM, Vir Campestris wrote: > Which becomes really interesting in reviews, when you really need to > know whether it has been changed slightly when it moved. > Andy From a comment Linus Torvalds made during this presentation on Git: 2007 - Google Tech Talk: Linus Torvalds on git https://www.youtube.com/watch?v=4XpnKHJAok8 He said the ability exists within the git history to track movement and editing of lines of code from their current location back to their original location, even if they've moved from file to file. He indicated it would be an expensive operation, and it would likely involve writing some custom code to examine the evolution of blocks over time, but he indicated it is possible with Git. It does not appear to be something that's done during normal commit cycles, however. IIRC, Git can identify that file x was renamed to file y, even if it also has some changes within it. Thank you, Rick C. Hodgin |
| Paavo Helde <myfirstname@osa.pri.ee>: Jul 27 11:53PM +0300 On 27.07.2017 22:57, Vir Campestris wrote: > moved" from "This lump has been inserted, and that one deleted". > Which becomes really interesting in reviews, when you really need to > know whether it has been changed slightly when it moved. If your ability to refactor code starts to become limited because of source control and code review issues then you know you are in a big trouble! Cart before horse and all that stuff... |
| woodbrian77@gmail.com: Jul 26 06:08PM -0700 On Wednesday, July 26, 2017 at 12:06:33 PM UTC-5, Lynn McGuire wrote: > more powerful and simpler." > Looks a little complicated to this old Fortran hacker. > Lynn I think C++ 2023 is the earliest that would have a chance. In the meantime, the C++ Middleware Writer automates the creation of serialization functions. Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net |
| scott@slp53.sl.home (Scott Lurndal): Jul 27 12:28PM >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. The proposal is more related to introspection and his metaclasses are more like a template for the underlying 'struct'/'class' semantics within the compiler itself. |
| scott@slp53.sl.home (Scott Lurndal): Jul 27 12:29PM >> Lynn >I think C++ 2023 is the earliest that would have a=20 >chance. Gratuitous advertisement elided. Note that the aforementioned feature is already implemented in clang. |
| legalize+jeeves@mail.xmission.com (Richard): Jul 27 08:35PM [Please do not mail me a copy of your followup] Lynn McGuire <lynnmcguire5@gmail.com> spake the secret code >tentatively called ``metaclasses'' that aims to make C++ programming both >more powerful and simpler." >Looks a little complicated to this old Fortran hacker. It's easier to understand if you watch the YouTube video from ACCU 2017: Thoughts on Metaclasses <https://www.youtube.com/watch?v=6nsyX37nsRs> -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Terminals Wiki <http://terminals-wiki.org> The Computer Graphics Museum <http://computergraphicsmuseum.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jul 27 08:50PM +0100 I blame the popular resurgence in the fucktardedness which is functional programming for the belief that it is OK to do unbounded recursion in C++ when C++ doesn't have the same guarantees as the fucktarded functional programming languages. It is a well known fact that the majority of Haskell programmers have suffered from or are in the process of having a stroke. Just sayin'. /Flibble |
| Daniel <danielaparker@gmail.com>: Jul 27 01:03PM -0700 On Thursday, July 27, 2017 at 3:51:10 PM UTC-4, Mr Flibble wrote: > I blame the popular resurgence in the fucktardedness Mr Flibble should know better, that usage connotes abuse. The acceptable equivalent is fucknitiveimpairment. Daniel |
| Tim Rentsch <txr@alumni.caltech.edu>: Jul 26 10:38PM -0700 > } > Of course, doing so would be contrary to the comp.lang.c++ spirit > of arguing minutae to death, so feel free to ignore me. :-) Personally I find a recursive definition is often a lot easier to understand than an iterative one. My point though was only about comparing two recursive definitions: one where the recursive call is a tail call, and one where it is not a tail call. For just these two cases, the one where the call is a tail call is generally better. |
| Tim Rentsch <txr@alumni.caltech.edu>: Jul 26 11:22PM -0700 > So, in terms of the abstract machine there is a substantial difference > between the two solutions in terms of data /storage/: for the the > iterative case it is O(1) and for the recursive case it is O(n) That has no effect on the program's semantics. > machine. Real implementations deal with real memory constraints, and > assuming that an implementation will allocate new storage at each loop > is just perverse, and you know it. My comment is meant to explain a distinction between the language formal semantics and what might occur in actual practice. Whether such transformations are likely is irrelevant; all that matters is that the meaning of the program is the same in both cases. >> language but a practical consideration related to quality of >> implementation. Do you see what I mean when I say that? > Others have already answered why your statement above is wrong. What I said is right. If you think it isn't then either you have misunderstood what I was saying or you are confused about something. > In this case, code which can result in stack overflow is just wrong, > even if it is syntactically and semantically correct (seems trivial to > me, but appearently it needs saying). What I think you mean is that such code is unacceptable. I wasn't saying anything about that. > do not also have formal proof of defined and bounded usage of stack > space. This means a formal proof of defined and bounded recursion > depth and stack frame size of each recursion. I think you don't realize quite what it is you are saying here. But that is moving into another area of discussion so for now I will say no more about it. > will be compiled by your employer or by your customer (possibly with > different compiler settings, or a different version or a different > compiler itself or on a different machine or architecture). These things depend on what it is that is being delivered, and what the expectations are of the people of might be taking delivery. If you want to talk about that then we could do that, but it's outside the scope of what I was saying. > This is expecially true since you are relying on compiler behaviour > which is /not/ dictated by the standard. Using iterative code also relies on compiler behavior that is not dictated by the standard. > recursive compilation (e.g. triggering a destructor call). If and when > this happens, it is still your code's fault, because it is you who > wrote the recursive C++ source. This falls into the same category as what I said above about what is being delivered, etc. |
| Tim Rentsch <txr@alumni.caltech.edu>: Jul 26 11:37PM -0700 > s = impl::reversed( s, 0 ); > } > ------------------------------------------------------------------ Personally I find the revised definition atrocious, and decidedly worse than what it is meant to replace. But what I was talking about is really orthogonal to these low-level style questions, so I will just leave it at that. |
| Tim Rentsch <txr@alumni.caltech.edu>: Jul 27 12:04AM -0700 > I plonked Stuckle some time ago, but this point deserves rebuttal since > it is simply wrong. A true *tail call* can always be optimized away and > replaced by a goto. [...] I think a clarification is needed here. What you're saying is right but may be misleading. A call that is a tail call as far as the source language is concerned (ie, no pesky destructors to worry about, etc) might or might not be optimizable to a goto, depending on the actual call and what the ABI calling conventions are. I don't pretend to understand all the issues but the question is more subtle than it may appear at first glance. Your point holds for a /true/ tail call, but what constitutes a true tail call depends on more than just the source code and the language definition. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jul 27 10:35AM +0200 On 27.07.2017 08:37, Tim Rentsch wrote: > worse than what it is meant to replace. But what I was talking > about is really orthogonal to these low-level style questions, > so I will just leave it at that. You really have to get your code correct and working, before you can have an opinion on style. - Alf |
| David Brown <david.brown@hesbynett.no>: Jul 27 12:11PM +0200 On 27/07/17 10:35, Alf P. Steinbach wrote: >> so I will just leave it at that. > You really have to get your code correct and working, before you can > have an opinion on style. No, you don't. It is easier to make readable code correct, than to make correct code readable. (For what it is worth, I don't like either of your styles. Each has its good points and bad points, as I see it. And each is quite individual, using features that are rarely seen in other people's code.) |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jul 27 12:33PM +0200 On 27.07.2017 12:11, David Brown wrote: > No, you don't. > It is easier to make readable code correct, than to make correct code > readable. Yes, as long as "readable" translates into "easy to map to a correct picture of what should go in an abstract machine". This kind of readability comes from correctness in the first place. Before Tim gets to the point of ditching notation that looks good as math, but yields execution that will fail on reasonably large data sets, he needs to /learn/ about styles: he has no background to judge, he is an infant in this field. > (For what it is worth, I don't like either of your styles. Each has its > good points and bad points, as I see it. And each is quite individual, > using features that are rarely seen in other people's code.) So it is. My style has evolved through some 35+ years of programming, and I'm not a conformist, plus I'm one of those who produce code that works, so it's natural that my style doesn't conform to the current norm. And certainly it may be that others won't catch up before both C and C++ are history. Tim's style has the problem that it yields non-working code, it's a superficial cosmetic thing from the mathematical ideals world. Cheers!, - Alf |
| David Brown <david.brown@hesbynett.no>: Jul 27 01:29PM +0200 On 27/07/17 12:33, Alf P. Steinbach wrote: >> readable. > Yes, as long as "readable" translates into "easy to map to a correct > picture of what should go in an abstract machine". That is certainly part of "readability", but not all of it. That says it should be clear what the code does at a low level. However, it should also be clear what the code is supposed to do, and how it achieves it algorithmically. (Yes, this is perhaps stretching the word "readable" a bit - but it is the concept that is important here.) > This kind of readability comes from correctness in the first place. It is interconnected, but it does not come directly from it. Code can be readable and wrong - it has bugs in it. But being readable, it should be relatively easy to find and fix the bugs. On the other hand, code can be correct but still impenetrable. Such code is easy to break, since it is hard to modify without unintended consequences because you can't see what is really going on in the code. > math, but yields execution that will fail on reasonably large data sets, > he needs to /learn/ about styles: he has no background to judge, he is > an infant in this field. (That is an argument I am keeping away from!) > a conformist, plus I'm one of those who produce code that works, so it's > natural that my style doesn't conform to the current norm. And certainly > it may be that others won't catch up before both C and C++ are history. A lot of people have developed their own favourite style of coding over the years - and that's fine. Any individual is going to be better (more productive, less bugs) at programming in a style they are very familiar with. I am sure Tim could say pretty much the same things here as you do despite the differences in style. However, conformance to more common styles is sometimes important. If you need to share your work with others (excluding others that may share your style), or need to work on other people's code, then you need to fit with other styles. All I am saying here is that /I/ find some (not many) aspects of your style of coding to be detrimental to the readability of the code. (And similarly with Tim's code.) So I don't find it at all surprising that other people may not like it. > Tim's style has the problem that it yields non-working code, it's a > superficial cosmetic thing from the mathematical ideals world. I agree that it is wrong to rely on compiler optimisations for code correctness (rather than just code efficiency). If recursive code might not work in this case, then it is a poor choice of structuring for the code here. In general, however, "mathematical style" code may be more amenable to correctness proofs, and therefore have advantages at other times. |
| Manfred <noname@invalid.add>: Jul 27 08:33PM +0200 On 7/27/2017 8:22 AM, Tim Rentsch wrote: >> On 06/22/2017 09:07 PM, Tim Rentsch wrote: >>> Manfred <noname@invalid.add> writes: >>>> On 6/20/2017 7:27 PM, Tim Rentsch wrote: [...] >> between the two solutions in terms of data /storage/: for the the >> iterative case it is O(1) and for the recursive case it is O(n) > That has no effect on the program's semantics. You went further than that, in fact you wrote about the Iterative/Recursive implementations: "Under the rules laid out in the language standard, they are therefore completely interchangeable" I made clear that the two solutions are /not/ interchangeable. > Whether such transformations are likely is irrelevant; all that > matters is that the meaning of the program is the same in both > cases. I believe that it definitely matters if one of the cases is not correct. This is true even in a pure research environment. >> Others have already answered why your statement above is wrong. > What I said is right. If you think it isn't then either you have > misunderstood what I was saying or you are confused about something. Just to avoid any confusion: you wrote "As far as correctness goes, the two approaches have identical semantics, so either both are correct or neither is." This statement is wrong: it has been made abundantly clear that one approach is correct and the other is not. If you still don't get it, I would say it is you who are confused about something, sorry. > I think you don't realize quite what it is you are saying here. > But that is moving into another area of discussion so for now I > will say no more about it. I am sorry, but this is really a gratuitous statement. > the expectations are of the people of might be taking delivery. If > you want to talk about that then we could do that, but it's outside > the scope of what I was saying. The context of this discussion is C++ code, so the point that when delivering C++ code the method that you describe above does not hold, is pretty much on topic. >> which is /not/ dictated by the standard. > Using iterative code also relies on compiler behavior that is > not dictated by the standard. This is also not true. It is really getting boring to have to correct all these mistakes, anyway let's do this too: You propose to rely on some compiler optimization feature (specifically tail recursion optimization) to avoid your program to run out of stack space. Appearantly it has to be recalled here that compiler optimizations are not dictated by the standard. Iterative code does /not/ run out of stack space, even with no optimizations at all. >> wrote the recursive C++ source. > This falls into the same category as what I said above about what > is being delivered, etc. Indeed it is about what is being delivered, which is C++ code. |
| 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