Thursday, April 5, 2018

Digest for comp.lang.c++@googlegroups.com - 6 updates in 3 topics

legalize+jeeves@mail.xmission.com (Richard): Apr 05 09:43PM

[Please do not mail me a copy of your followup]
 
Ian Collins <ian-news@hotmail.com> spake the secret code
>you start out with a requirement the code does not meet, you start out
>with a test its does not pass. Once it meets the requirement, the test
>passes.
 
This.
 
Maybe people would understand this better if it were called Design
Driven Development instead of Test Driven Development. The main
activity is a design activity, not a testing activity.
--
"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>
Robert Wessel <robertwessel2@yahoo.com>: Apr 05 04:57PM -0500

On Thu, 05 Apr 2018 20:29:51 +0300, Paavo Helde
>all when I told him this is no good. He said he cannot think up names
>for smaller functions and anyway he finds it easier to follow the
>program logic if it is all nicely linear in a single function.
 
 
That raises an interesting philosophical point. Do you count lambdas
as a separate routine for the purposes of keeping routines a
reasonable number of lines? In languages that have traditionally
allowed nested functions, not counting the nested functions separately
would be absurd, and lambdas are looking more and more like nested
functions.
 
So in your example, is that a problematically long 239 line routine,
or an acceptable 52 line routine with a (problematically long) 187
line lambda? Leaving aside for a moment that any size goals for a
lambda probably ought to be considerably shorter that the usually "50
line" limit.
woodbrian77@gmail.com: Apr 05 03:15PM -0700

On Thursday, April 5, 2018 at 3:35:22 PM UTC-5, Vir Campestris wrote:
> > 50 lines at the moment.
 
> 50 is short. I aim to keep the entire function on screen. As screens
> have grown from 25 lines my functions have grown a little too.
 
Yeah, I'm happy when I find ways to get small functions, but don't
worry much about it when I can't figure out how to break up a big
function. I have a 114 line function here:
https://github.com/Ebenezer-group/onwards/blob/master/tiers/cmwA.cc
 
. It used to be longer so figure I'm making progress.
 
 
Brian
Ebenezer Enterprises
http://webEbenezer.net
legalize+jeeves@mail.xmission.com (Richard): Apr 05 10:23PM

[Please do not mail me a copy of your followup]
 
Robert Wessel <robertwessel2@yahoo.com> spake the secret code
 
>So in your example, is that a problematically long 239 line routine,
>or an acceptable 52 line routine with a (problematically long) 187
>line lambda?
 
The latter.
 
>Leaving aside for a moment that any size goals for a
>lambda probably ought to be considerably shorter that the usually "50
>line" limit.
 
There are legitimate reasons for having large-ish lambdas. James
McNellis and Kate Gregory go over a use case for large-ish lambdas in
their "Modernizing Legacy C++ Code" talk here:
<https://www.youtube.com/watch?v=LDxAgMe6D18#t=29m17s>
--
"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): Apr 05 09:41PM

[Please do not mail me a copy of your followup]
 
Paavo Helde <myfirstname@osa.pri.ee> spake the secret code
 
>To give him credits, he actually produces working code far from trivial,
>albeit very slowly, and there are very few bugs in the final code.
 
I too used to produce code this way before TDD. It's not that I
couldn't get the bugs out from careful manual testing, it's that the
time between creating the bug and fixing the bug was orders of
magnitude longer than when I practice TDD. In other words, my error
rate has remained rather consistent but the time between creating and
fixing a bug goes from never/months/weeks/days/hours to seconds.
 
>So,
>if the code works, and there are no bugs, then why could it not be a
>239-line function?
 
It's fine if it will never need to be modified ever again.
--
"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>
Tim Rentsch <txr@alumni.caltech.edu>: Apr 04 10:06PM -0700


> You can substitute your compiler in the makefile. But it
> has to have support for 2017 ++C. It should work with
> clang 5 or 6 and newer versions of MSVC.
 
I already had tried a different version of g++, which didn't
work. After getting your message I tried clang 5, which was
better, but then there was a problem of a missing header file
(that was <string_view>). There was some sort of experimental
version of <string_view> under /usr/include, and I arranged
to get that with a -I, but that led to some other errors at
which I point I basically gave up. Sorry but that's the
best I can do for you at present.
 
> for building the software in the repo. The output from the
> on-line code generator only requires a 2011 ++C compile.
> I hope this helps.
 
I'm not faulting your choices. For me it's important to go
through a complete build, because it helps to see what I'm
dealing with. I think at present what you have done is
just a bit too close to the cutting edge for my environment.
Sometime in the future maybe things will change enough so
I can think about giving it another try.
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.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)