- High horse - 15 Updates
- "Why does most C/C++ developer prefers char *c instead of char* c? Pin" - 9 Updates
- Blinking message in Dev C++ - 1 Update
| Daniel <danielaparker@gmail.com>: Jun 04 12:13PM -0700 On Monday, June 4, 2018 at 2:02:07 PM UTC-4, Dan Cross wrote: > Ian Collins <ian-news@hotmail.com> wrote: > Proponents of TDD in the Martin, Beck, Jeffries sense really do > try and push it too far. Agreed > that they do not believe it themselves, and are only saying so > because they are (most commonly) consultants and authors who are > trying to sell engagements and books. I can believe that about Boston Consulting Group, Accenture, IBM etc promoting Agile, but not Robert Martin :-) Having had the pleasure of communicating with him on various usenet groups since his C++ Report days, I don't believe that he would express an opinion about any matter that he didn't actually hold. > quality results. However, unit testing is insufficient to > ensure that software is correct and responsive in all respects > and TDD, in particular, seems like something of an oversold fad. Agreed, on all counts. Daniel |
| legalize+jeeves@mail.xmission.com (Richard): Jun 04 07:45PM [Please do not mail me a copy of your followup] cross@spitfire.i.gajendra.net (Dan Cross) spake the secret code >The bottom line: unit testing seems to sit at a local maxima on >the cost/benefit curve [...] Uh.... citation needed. Seriously. There are actual academic studies among programmers doing comparable work with and without TDD. The ones using TDD got to completeness first faster on average than those that didn't use TDD. -- "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>: Jun 04 08:47PM +0100 On 04/06/2018 20:45, Richard wrote: > There are actual academic studies among programmers doing comparable > work with and without TDD. The ones using TDD got to completeness > first faster on average than those that didn't use TDD. You think being code complete faster means higher quality? Seriously? I think you need a cluebat mate. /Flibble -- "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| scott@slp53.sl.home (Scott Lurndal): Jun 04 07:50PM >There are actual academic studies among programmers doing comparable >work with and without TDD. The ones using TDD got to completeness >first faster on average than those that didn't use TDD. Uh..... citation needed. Seriously. |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Jun 04 11:54AM -0400 On 06/03/2018 09:26 AM, Daniel wrote: > nonsensical to talk about "100" percent coverage unless you're talking > about software verified through mathematical proof, and if you're > talking about that, you're not talking about C++. I worked for awhile under a requirement that our unit tests provide 100% coverage of our code - but I strongly suspect that what we were talking about was involved different numbers in the numerator and denominator of the fraction that is being converted to 100% than what you're apparently thinking of. In our case, the denominator was the number of full-expressions in the code. To this number was added any sub-expressions that were not guaranteed to be executed when the containing expression was executed (such as b and c in a?b:c, or b in a&&b). The numerator was the number of such expressions which should be executed by the unit test if the code was correct (this is obviously not black-box testing, which we also did). This was combined with other requirements, such as the requirement that if a branch in the code depends upon the value of an integer expression, there must be at least two cases where that branch is tested; one where the expression should have the minimum possible value that should cause the high branch to be chosen, and one where it should have the maximum possible value that should cause the low branch to be chosen. This principle was extended in the obvious fashion for switch() statements. For purposes of this requirement, empty branches (such as if(a) b();) are treated as if there were an expression-statement on the missing branch (if(a) b(); else dummy();). Furthermore, there was a requirement that if two test cases caused different expressions to be executed, the test cases must be set up so that whether or not those expressions were executed causes a detectable difference in the test results. Was creating such thorough tests was "the best use of [my] time to keep [my] software free of defects"? Well, our defect rate rose significantly when management stopped requiring that we do such detailed testing, and started pressuring us to make deliveries too quickly to allow such testing to be done, so I suspect that the answer is "yes". > approached through unit tests, I'm thinking particularly of > simulation, where we need to run code for hours and calculate the > statistical properties of outcomes. I would be very surprised to learn that the "T" in TDD referred only to unit tests. I would assume that if a requirement involved the interaction of a program with the external environment (for instance, there is a requirement that, under certain circumstances, a missile must be fired), the corresponding test would include evaluating the impact on the external environment (i.e. confirming that the missile (or at least, a dummy missile) was actually fired). |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Jun 04 12:03PM -0400 On 06/04/2018 03:12 AM, Juha Nieminen wrote: >> On 02/06/18 14:17, Mr Flibble wrote: >>> I see Ian Collins is on his TDD high horse again. Fecking clueless. >> Feel free to write code that you don't know works. ... > Another thing I have noticed about TDD is that it's difficult to test > the behavior of private member functions (without exposing them to > outside code, breaking object-oriented modularity design. You test the private member function by calling whichever public functions call it, directly or indirectly. If execution of the private member function is needed to achieve some required result, it's always possible to perform such a test, by checking to see whether that required result occurred. If execution of a private member function has no testable consequences, then that private member function isn't actually needed. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jun 04 05:16PM +0100 On 04/06/2018 17:03, James Kuyper wrote: > ... If execution of a private member function has > no testable consequences, then that private member function isn't > actually needed. False. A private member function is allowed to call other private member functions without the need to maintain a class invariant; these other private member functions may indeed have no testable consequences unless taken together with the other private member functions that call them. TDD is the enemy of encapsulation ergo TDD is the enemy of good (object oriented) software design. /Flibble -- "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| Ian Collins <ian-news@hotmail.com>: Jun 05 08:50AM +1200 >> a class and test that. This does, surprisingly often, produce a >> useful reusable component. > Reducing encapsulation in the process. No, extracting functionality performed by private methods does not reduce encapsulation. For example if a private method performs a transformation on private data, say rotation of a point about an axis, how does extracting that transformation break encapsulation? The transform on its own has no impact on the parent class state, you need the transformation + data to do that. All you end up with is a tested transformation which can be used elsewhere if needed. > I have said before that TDD is > the enemy of encapsulation and therefore by extension an enemy of > good design as encapsulation is an important design principle. So you have, like a lot of things you say you have yet to prove it. Here's a counter claim: obsessive encapsulation is the enemy of modularisation and therefore by extension an enemy of good design as modularisation is an important design principle. -- Ian. |
| Ian Collins <ian-news@hotmail.com>: Jun 05 08:56AM +1200 On 05/06/18 03:54, James Kuyper wrote: > be fired), the corresponding test would include evaluating the impact on > the external environment (i.e. confirming that the missile (or at least, > a dummy missile) was actually fired). This is an important point people who target individual agile practices fail to acknowledge; to get the best results, the practices need to be used together, you can't just adopt one in isolation and expect to get the best results. You can't just rely on unit tests in isolation, whether they be added after the fact or through TDD. You need another layer (often two - automated system tests and user testing) to be sure your product id ready for market. -- Ian. |
| leigh.v.johnston@googlemail.com: Jun 04 02:03PM -0700 On Monday, June 4, 2018 at 9:50:26 PM UTC+1, Ian Collins wrote: > No, extracting functionality performed by private methods does not > reduce encapsulation. False. An increase in the number of public member variables across one or more classes represents a corresponding decrease in encapsulation. This is basic stuff you should know already. /Leigh |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jun 04 10:13PM +0100 >> No, extracting functionality performed by private methods does not >> reduce encapsulation. > False. An increase in the number of public member variables across one or more classes represents a corresponding decrease in encapsulation. This is basic stuff you should know already. Minor mistake there (wrote it on my phone): I meant "functions" not "variables"; so: An increase in the number of public member functions across one or more classes represents a corresponding decrease in encapsulation. This is basic stuff you should know already. /Flibble -- "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| legalize+jeeves@mail.xmission.com (Richard): Jun 04 05:01PM [Please do not mail me a copy of your followup] Ian Collins <ian-news@hotmail.com> spake the secret code >On 02/06/18 14:17, Mr Flibble wrote: >> I see Ian Collins is on his TDD high horse again. Fecking clueless. >Feel free to write code that you don't know works. From his high horse it's much easier to hit the ball with his polo mallet :-). -- "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> |
| Ian Collins <ian-news@hotmail.com>: Jun 05 09:20AM +1200 On 05/06/18 09:13, Mr Flibble wrote: > An increase in the number of public member functions across one or more > classes represents a corresponding decrease in encapsulation. This is > basic stuff you should know already. I don't think you (deliberately or otherwise) missed and snipped my point. I didn't say add more public member functions, I said extract the functionality into its one object (which could be a free function). -- Ian. |
| legalize+jeeves@mail.xmission.com (Richard): Jun 04 05:09PM [Please do not mail me a copy of your followup] Jorgen Grahn <grahn+nntp@snipabacken.se> spake the secret code >> test passes. >That's certainly the impression I got too, from reading Beck's book >once. His argument seemed weak to me. In a language like C++ where we have to contend with build systems and compilers and linkers and their funny ways, getting code to a syntactically correct state can be non-trivial at times. Going in small steps, e.g. from compilation error to failing test to passing test is one way to avoid making stupid mistakes. In my experience with doing TDD in C++, the "satisfy the compiler" or "satisfy the build system" steps generally only happen at the start of a new library or executable. In those situations, making sure my build system is setup correctly is a useful small step. When working on adding new features to existing code that was written with TDD, it's not usually necessary to proceed in those smaller steps. Experts take larger steps than novices. I've developed code without TDD for decades before I adopted TDD. I certainly know how to do it both ways and for an existing code base, it may simply be less work to do things the "old way" than adopt TDD because there might be too much decoupling needed to do strict TDD. However, having done it both ways for a number of years, I have found that I am more productive with TDD than without it. I find my bugs faster and spend less time doing long tedious integration debugging sessions. (I've been in a tedious integration debugging session for about two weeks right now at work.) -- "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> |
| Ian Collins <ian-news@hotmail.com>: Jun 05 09:28AM +1200 On 05/06/18 09:20, Ian Collins wrote: > I don't think you (deliberately or otherwise) missed and snipped my > point. I didn't say add more public member functions, I said extract > the functionality into its one object (which could be a free function). Need coffee. I think you (deliberately or otherwise) missed and snipped my point .... to its own object ... -- Ian. |
| scott@slp53.sl.home (Scott Lurndal): Jun 04 02:51PM >> the return address in the first word of the target function (e.g. PDP-8) >> or on a stack (Burroughs/IBM mainframes). >The branch instruction is a small part of the cost. Aside from any cache related costs (not a problem in the 70's), what additional costs are there in your concept of 70's functions? |
| Vir Campestris <vir.campestris@invalid.invalid>: Jun 04 08:57PM +0100 On 04/06/2018 15:51, Scott Lurndal wrote: > Aside from any cache related costs (not a problem in the 70's), what > additional costs are there in your concept of 70's functions? I assure you cache was an issue in the '70s. OK, it was only single level, and we had no branch predictors - but the cache on a 2900 was good enough that a dual processor would run some workloads more than twice as fast as a single CPU machine. Andy |
| David Brown <david.brown@hesbynett.no>: Jun 04 10:00PM +0200 On 04/06/18 16:51, Scott Lurndal wrote: >> The branch instruction is a small part of the cost. > Aside from any cache related costs (not a problem in the 70's), what > additional costs are there in your concept of 70's functions? The cost of a function call - compared to inlining the code - will depend a lot on the function, the cpu, the compiler, and how much of the code the compiler can see. But typical additional costs include moving data into the right registers for the calling convention (for cpus with few registers, this is little cost - also for cpus which have register renaming these can often be swallowed early in the pipeline. But for single issue cpus with lots of registers, it is costly). Data that is in "volatile" registers needs to be saved or re-created around the function call. The compiler loses information about what data may or may not be accessed, and thus has to flush write data from registers and reload read data after the call. The compiler loses the opportunity to merge the code for scheduling benefits, constant propagation, common subexpression optimisations, etc. Function calls can be very cheap, but they can also be significant cost. |
| scott@slp53.sl.home (Scott Lurndal): Jun 04 08:46PM >level, and we had no branch predictors - but the cache on a 2900 was >good enough that a dual processor would run some workloads more than >twice as fast as a single CPU machine. A rare machine indeed, with both cache and SMP. The B2900 (Burroughs) had neither. |
| scott@slp53.sl.home (Scott Lurndal): Jun 04 08:49PM >merge the code for scheduling benefits, constant propagation, common >subexpression optimisations, etc. >Function calls can be very cheap, but they can also be significant cost. The original point was that there was no movement or commandment to avoid function calls in the 70's due to the perceived expense. Nor were there pipelines or, in general, software-visible caches in the 70's. Functions were not at all uncommon in Fortran, COBOL or the many algol and algol-like languages in that era, even BASIC heavily used functions (GOSUB). |
| legalize+jeeves@mail.xmission.com (Richard): Jun 04 04:57PM [Please do not mail me a copy of your followup] bart4858@gmail.com spake the secret code > T z; >Then that relationship is lost, and it will need more maintenance to >ensure they stay the same type. This is really just a missing abstraction. If you want a 3D point, make a type for it. It's zero-overhead in C++ and allows you to express the idea directly in code. -- "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> |
| Lynn McGuire <lynnmcguire5@gmail.com>: Jun 04 04:13PM -0500 On 6/1/2018 8:11 AM, Scott Lurndal wrote: ... >> Only few rocket scientists had enough storage for comments so most >> code was write-only. > Complete nonsense. We used the UCS Univac 1108 for software development until 1978 when we got a Prime 450. We could barely afford to keep the code online on those old drum drives, much less the comments. So, no comments in our source code until 1978. And those comments sucked. I would love for our code from back then to have four letter variable names. We generally have: T = temperature P = pressure V = vapor L = liquid B = hydrocarbon liquid I = integer iterator Lynn |
| Bart <bc@freeuk.com>: Jun 04 06:05PM +0100 On 04/06/2018 17:57, Richard wrote: >> ensure they stay the same type. > This is really just a missing abstraction. If you want a 3D point, > make a type for it. The 3 values might form a vector with those three components, but usually they won't or you have other reasons for independent access to the variables. But even suppose you did encapsulate them into a type; the problem doesn't go away: do you declare them inside that type with one T and 3 names, or three Ts? -- bartc |
| legalize+jeeves@mail.xmission.com (Richard): Jun 04 05:12PM [Please do not mail me a copy of your followup] Bart <bc@freeuk.com> spake the secret code >But even suppose you did encapsulate them into a type; the problem >doesn't go away: do you declare them inside that type with one T and 3 >names, or three Ts? It's irrelevant at that point because the abstraction makes it clear that they all belong together. -- "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> |
| legalize+jeeves@mail.xmission.com (Richard): Jun 04 05:00PM [Please do not mail me a copy of your followup] bintom <binoythomas1108@gmail.com> spake the secret code >I noticed that there are no library functions in Dev C++ to display a >blinking message. So I wrote this function, which I hope does the job >for any oneout there. It doesn't work on my LA36. -- "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> |
| 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