Monday, February 8, 2016

Digest for comp.lang.c++@googlegroups.com - 13 updates in 5 topics

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: