- Unit testing (Re: Putting project code in many different files) - 7 Updates
- Derivation without size increase? - 2 Updates
- "Rust vs. C++: Fine-grained Performance" - 1 Update
- TDD considered harmful - 2 Updates
- DataItem cache - 1 Update
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Feb 08 10:18PM On 08/02/2016 21:01, Paavo Helde wrote: > A fact is something you observe, not nothing you derive. When facts > contradict your theory, then you have chosen wrong axioms or applied the > theory to the real life in a wrong way. Nope; axioms can be used in addition to observations to arrive at facts but not all facts require axioms. /Flibble |
Ian Collins <ian-news@hotmail.com>: Feb 09 11:23AM +1300 Mr Flibble wrote: >> theory to the real life in a wrong way. > Nope; axioms can be used in addition to observations to arrive at facts > but not all facts require axioms. None of this changes "TDD (especially in C++ land) is toxic" from bollocks to fact.... -- Ian Collins |
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Feb 08 10:25PM On 08/02/2016 22:23, Ian Collins wrote: >> but not all facts require axioms. > None of this changes "TDD (especially in C++ land) is toxic" from > bollocks to fact.... It cannot change it from bollocks to fact because it is already a fact and not bollocks. /Flibble |
Ian Collins <ian-news@hotmail.com>: Feb 09 11:31AM +1300 Mr Flibble wrote: >> bollocks to fact.... > It cannot change it from bollocks to fact because it is already a fact > and not bollocks. You really can't come up with a solid justification for that statement, can you? If you did, you wouldn't have to write like a 70s pantomime script. -- Ian Collins |
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Feb 08 10:39PM On 08/02/2016 22:31, Ian Collins wrote: > You really can't come up with a solid justification for that statement, > can you? > If you did, you wouldn't have to write like a 70s pantomime script. TDD reduces encapsulation ergo it is toxic when used with a language like C++. Maintaining class invariants should be at the heart of any design involving C++, a task which is virtually impossible when employing TDD. /Flibble |
Ian Collins <ian-news@hotmail.com>: Feb 09 11:46AM +1300 Mr Flibble wrote: > like C++. Maintaining class invariants should be at the heart of any > design involving C++, a task which is virtually impossible when > employing TDD. So you keep saying, without any evidence. TDD does not reduce encapsulation ergo it is not toxic when used with a language like C++. -- Ian Collins |
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Feb 08 10:58PM On 08/02/2016 22:46, Ian Collins wrote: > So you keep saying, without any evidence. > TDD does not reduce encapsulation ergo it is not toxic when used with a > language like C++. Even if I give you the benefit of the doubt regarding encapsulation there is still the problem that Test Driven DESIGN is completely the wrong approach to designing software. /Flibble |
Jorgen Grahn <grahn+nntp@snipabacken.se>: Feb 08 10:23PM On Fri, 2016-02-05, Jerry Stuckle wrote: > On 2/4/2016 3:40 PM, Paavo Helde wrote: >> I have a base class with sizeof 24. There are zillions of objects of >> this class so I have tried to get the size of this class to minimum. ... > Exactly how many are "zillions"? Even if you have 1,000,000 of them at > the same time (very doubtful - trying to process that many items would > take a lot of time), I don't want to nitpick, but a million objects is not that uncommon, nor do they necessarily take a lot of time to process. I don't believe you're making this mistake, but I sometimes meet people who have absurdly low expectations in this area. Brute force, modernish computers and the absence of total stupidity takes you far. For example, $ time od /dev/urandom| head -1000000 | sort | md5sum Sorting those 1,000,000 lines of text takes 7 seconds on my machine, which is ten years old. Calculating the checksum takes 200 ms. > you're only talking about 8 MB of additional memory. Yes. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
Ian Collins <ian-news@hotmail.com>: Feb 09 11:29AM +1300 Jorgen Grahn wrote: > $ time od /dev/urandom| head -1000000 | sort | md5sum > Sorting those 1,000,000 lines of text takes 7 seconds on my machine, > which is ten years old. Calculating the checksum takes 200 ms. To be fair, that probably shows your /dev/urandom isn't as random as it could be :) I agree with everything else... -- Ian Collins |
Lynn McGuire <lmc@winsim.com>: Feb 08 03:51PM -0600 "Rust vs. C++: Fine-grained Performance" cantrip.org/rust-vs-c++.html Modules, modules, modules! And Go is coming up fast according to my son. Lynn |
Vir Campestris <vir.campestris@invalid.invalid>: Feb 08 09:22PM On 07/02/2016 21:35, Jerry Stuckle wrote: > That is true. Only the function of the microprocessor is tested. And I > agree - if the interface works as designed, there is nothing else to test. I've only been involved in the design of one processor, and not for very long - and it was an SIMD thing, not a standard processor. But the HW guys went on about "scan chains", which allow them to access _every_ gate and make sure they are all working as designed. (I was quite pleased to be able to uncover a race condition when you had a branch, prefetch, and a cache miss all at the same time... this was of course not detected by the scan chain, as it was working as designed... and yes, it was fixed for customer silicon) Andy |
Jerry Stuckle <jstucklex@attglobal.net>: Feb 08 04:36PM -0500 On 2/8/2016 4:22 PM, Vir Campestris wrote: > course not detected by the scan chain, as it was working as designed... > and yes, it was fixed for customer silicon) > Andy Sure, but did they test every gate? Or did they just have access to every gate? Or did they just use the scan chains to debug problems? You have access to every expression in the source code. But do you test that every expression works? Or do you see if the unit does what it's supposed to? -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
Lynn McGuire <lmc@winsim.com>: Feb 08 02:15PM -0600 On 2/6/2016 11:11 AM, Marcel Mueller wrote: > as far as I can see. COW should be sufficient. > It looks like you are trying to reinvent Excel. Well considering the speed its design is probably similar. ;-) > Marcel BTW, we first released this software in 1990 on Windows 3.0 as a mixture of C and Smalltalk. This is some of the Smalltalk code that we converted to C++ in 2002. And, you are very correct. DesValue needs to go on a severe diet. Lynn |
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