Monday, February 1, 2016

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

woodbrian77@gmail.com: Feb 01 02:43PM -0800

I've taken info from this page
 
http://meetingcpp.com/index.php/newsreader/items/c-user-group-meetings-in-february-2016.html
 
and come up with this:
 
The Meetings
 
1st Dublin - C/C++ Meetup
3rd Saint Louis - Resharper C++, Scott Meyers book, group exercise
10th Utah - Getting Started with C++
10th Washington, DC - Q & A / Info Sharing
10th San Francisco - Reliability and security of today's software platforms
11th Dresden - TBA
15th Austin - Monthly C/C++ Pub Social
15th Zentralschweiz - C++11/14 Idioms
16th Berlin - TBA
16th Hamburg - Monthly meeting
17th Sacramento - Talk C++
17th Düsseldorf - Building blocks of Metaprogramming
17th Seattle - C++2D Graphics Standardization
18th Berlin (Qt) - Have food/drinks and talk about Qt
21st Ho Chi Minh - HCM C++ User Group Meeting
23rd Macedonia - Emscripten - run your C/C++ code in web browser
24th San Francisco - Workshop and Discussion Group
24th Washington, DC - Q & A / Info Sharing
24th Stuttgart / Ludwigsburg (Qt) - Qt Meetup
25th Bremen - Lisp und ECL
27th Sofia - First Meeting
------------------------------------------------
 
If others are interested in a C++ meeting in the St. Paul,
Minnesota area, please let me know. By the grace of G-d,
I'm able to provide a meeting area in a conference room in
the office building where Ebenezer Enterprises is, and I
would be happy to give a talk or two.
 
Last month
 
https://groups.google.com/forum/#!topic/comp.lang.c++/o8whK7pA_sw
 
someone said that not all of these "meetings" may be
taking place. It sounded to me like the ones that have
a specific meeting topic are real meetings and the ones
that have a generic topic may be false positives.
 
 
Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net
Gareth Owen <gwowen@gmail.com>: Feb 01 09:41PM


> Is having a triple vodka a thing?
 
Jesus wept, man, of course its a thing. I kind of assumed you had two
or three before (re)starting each "... considered harmful" thread.
 
By the way, loved you in Red Dead Redemption.
http://reddead.wikia.com/wiki/Leigh_Johnson
Cholo Lennon <chololennon@hotmail.com>: Feb 01 11:22AM -0300

> amazed that you cannot see this.
 
> TDD is the totally wrong approach to software development. Design
> first, implement second and unit test third.
 
I agree with you. The first time I used TDD (don't confuse with writing
a unit test, a common mistake) was in a TDD course that my company sent
me. It was really weird. The teacher presented the problem to solve:
convert decimal numbers to roman numbers. Well, my group designed and
implemented the solution in a few minutes, wrong the teacher said! after
that, he explained how we should think and solve the problem using TDD:
Start with a simple test that fail. After that add the solution for 1
and test. Add the solution for 2 and test, etc. Try to find a pattern.
The iteration process was long because the pattern was changing. It was
your first time, the teacher said; future problems will be solved more
quickly.
 
I don't know, after several years of trying to apply the technic in
C++/Java/Python I'am still unconvinded. The teacher explained that TDD
avoids "analysis paralysis" (get stuck in a problem due to overthinking
it). You have to think the problem on the fly, try, fail, fix... but
IMO most of the time thinking in advance, solves the problem more
quickly and with a better design.
 
Regards
 
 
--
Cholo Lennon
Bs.As.
ARG
Gareth Owen <gwowen@gmail.com>: Feb 01 09:39PM

>> public method which has the effect that some of your public methods MUST
>> be unnecessarily large/complex.
 
> TDD and using private methods are orthogonal.
 
QFT. You might as well suggest that "Unit testing means you can't use
static linkage". Private members are an implementation detail. You
don't individually unit-test implementation details.
scott@slp53.sl.home (Scott Lurndal): Feb 01 04:53PM

>> > usually use smart pointers instead of raw pointers, even if it
 
>> Speak for yourself, kemosabe.
 
>Was "kemosabe" mean here as "trusty scout" or "faithful friend"?
 
Neither, in this case. It's american slang from the era
of the lone ranger shorts in the theaters.
Jerry Stuckle <jstucklex@attglobal.net>: Feb 01 03:07PM -0500

On 2/1/2016 11:53 AM, Scott Lurndal wrote:
 
>> Was "kemosabe" mean here as "trusty scout" or "faithful friend"?
 
> Neither, in this case. It's american slang from the era
> of the lone ranger shorts in the theaters.
 
Actually, it comes from even before that - the first radio broadcast
when the Lone Ranger legend began. Except it was the Lone Ranger who
call Tonto "Kemo sabe", not the other way around.
 
I've still got a 78 rpm of the original broadcast.
 
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
Vir Campestris <vir.campestris@invalid.invalid>: Feb 01 09:20PM

On 01/02/2016 20:07, Jerry Stuckle wrote:
> Actually, it comes from even before that - the first radio broadcast
> when the Lone Ranger legend began. Except it was the Lone Ranger who
> call Tonto "Kemo sabe", not the other way around.
 
Who are you calling tonto?
 
<http://www.spanishdict.com/translate/tonto>
 
(I didn't know that when I was a kid...)
 
Andy
Jerry Stuckle <jstucklex@attglobal.net>: Feb 01 02:55PM -0500

On 2/1/2016 11:14 AM, Paavo Helde wrote:
> something, then you cannot do code refactoring and code redesign. This
> means that given enough time the codebase will turn unmanageable,
> regardless of how good the design and specifications.
 
If you do, yes. However, that's more work to correct the error and test
again. Wasted time for developers and testers.
 
I'm not saying you don't change or refactor code. I'm saying you
shouldn't do it needlessly because you didn't test independent classes
before dependent ones.
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
Jerry Stuckle <jstucklex@attglobal.net>: Feb 01 03:01PM -0500

On 2/1/2016 2:44 PM, Ian Collins wrote:
>> done is waste time and unnecessarily create bugs because the mock
>> classes cannot, by definition, completely follow the specification.
 
> So you've tried it, done it wrong and given up. Too bad.
 
Nope, I've seen it done before, by more than one group. I've even been
called in a couple of times to manage a project that was mismanaged that
way. Projects that were late and over budget.
 
>> duplicate the behavior of the real class. It can only do some of it.
>> And that means potential problems are missed.
 
> I can't? Bugger, what have I been doing all these years? of course I can.
 
And you've been wasting time and money doing it. Or writing crap code.
I'm not sure which. Maybe both.
 
>> (unnecessarily).
 
> Can't I? The transformation will be well defined and will be testing in
> the real classes tests. Ever heard of a contract?
 
Yes, I've heard of contracts. I've also seen people try your way and
fail miserably. And they thought they were doing it "right" also, until
they saw otherwise.
 
 
> Yes, I would simply write something like:
 
> test::FOO_decode::willThrow( std::bad_alloc );
 
> before calling the code that will call the decoder.
 
But that doesn't emulate the out of memory condition. It just throws an
exception. Many other things can go wrong when you truly are out of
memory - things you aren't testing for.
 
For instance - what happens if the class you're testing allocates memory
while processing the out of memory condition? Since you aren't really
out of memory, that allocation will succeed - where in real life it will
fail. You have just introduced a bug.
 
>> the file is truncated? Or any of a number of things a proper test suite
>> would check?
 
> It will - in the tests for the real object.
 
Which means you will have multiple classes to test to see which one is
failing. A waste of tester and developer time.
 
 
>> Yes, you have. Now if you'd only learn how to do it correctly.
 
> I'm lucky in that I already do. You don't appear to have got beyond
> understanding what it is.
 
You seem to be quite willing to spend your employer's or client's money
unnecessarily. My job has been to ensure the projects come in on time,
within budget and as free of bugs as possible.
 
It looks like we have two different goals.
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
Jerry Stuckle <jstucklex@attglobal.net>: Feb 01 03:02PM -0500

On 2/1/2016 1:03 PM, Geoff wrote:
>> developer and a project manager.
 
> That must be why IBM software is so reliable and never needs bug
> fixes. :)
 
Any software will have bugs. But IBM's have fewer bugs per K LOC than
average.
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
Jerry Stuckle <jstucklex@attglobal.net>: Feb 01 03:03PM -0500

On 2/1/2016 1:53 PM, Öö Tiib wrote:
 
> Somehow when IBM and software are in same sentence then only horror comes
> to mind ... Rational Rose, ClearQuest, Lotus Notes, WebSphere ... crazy
> stuff done with apparently zero self-awareness whatsoever.
 
And if you follow back, every one of those was a product produced by
another company that IBM bought for one reason or another - not
necessarily the products you mentioned.
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
Jerry Stuckle <jstucklex@attglobal.net>: Feb 01 03:05PM -0500

On 2/1/2016 2:45 PM, Ian Collins wrote:
>> developer and a project manager.
 
> Ah-ha, that explains it: in this part of the world, we would never let a
> project manager anywhere near our code!
 
That's why you fail. Good project managers here understand the code and
the job being done. They are not mindless fools.
 
That's how they successfully manage the projects.
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
Ian Collins <ian-news@hotmail.com>: Feb 02 08:45AM +1300

Jerry Stuckle wrote:
> recalls, either - and are quite stringent in their testing.
 
> Neither are any of the other companies I have consulted for - both as a
> developer and a project manager.
 
Ah-ha, that explains it: in this part of the world, we would never let a
project manager anywhere near our code!
 
--
Ian Collins
Ian Collins <ian-news@hotmail.com>: Feb 02 09:41AM +1300

Jerry Stuckle wrote:
 
>> So you claim, but you continue (is is it choose?) to a display a basic
>> ignorance of the practice.
 
> Not at all.
 
You appear to find the concept of developers delivering tested code a
hard one to grasp.
 
 
>> Where did I say otherwise? Exact quote please.
 
> You said you wouldn't stress test code on a development system. Look
> back and see.
 
Indeed I did, but where did I say anything about not having "a test
group and test system(s)"?
 
 
>> Where did I say otherwise? Exact quote please.
 
> You said you can't test for out of memory on a development system. Look
> back and see.
 
I know, but where did I say anything about there not being a test group?
 
 
>> Please explain how mentioning embedded systems changed the topic.
 
> No one was talking about embedded systems before you brought it up.
> Look back and see.
 
I know, but how was mentioning embedded systems as an example changing
the topic? Please explain.
 
> of testing. A couple of times I've taken over failing projects because
> the developers were doing the testing instead of writing the code.
> Projects that were late and over budget.
 
So you are an advocate for developers delivering untested code?
 
>> say it again: "From the perspective of software other than its driver, a
>> device is a class other code". There, is that clear now?
 
> Yes, it is perfectly clear you have no idea what you're talking about.
 
Ah good, an insult. I'll take that as a concession.
 
>> that are well defined by the customer.
 
> Nope. But I don't try to mock classes, either. It just leads to more
> work and more bugs.
 
Ah good, avoiding the issue by changing the topic.
 
>> yourself....
 
> Nope. Not at all. But you obviously don't understand the difference
> between hardware and software.
 
Response by insult again, good.
 
--
Ian Collins
Ian Collins <ian-news@hotmail.com>: Feb 02 09:45AM +1300

Jerry Stuckle wrote:
 
>> Ah-ha, that explains it: in this part of the world, we would never let a
>> project manager anywhere near our code!
 
> That's why you fail.
 
I'll be sure to let you know when we do.
 
> Good project managers here understand the code and
> the job being done. They are not mindless fools.
 
So anyone who doesn't understand code is a mindless fool? You have a
very poor view of most of humanity.
 
> That's how they successfully manage the projects.
 
They successfully manage the projects by enabling those doing the
development to get on with their jobs....
 
--
Ian Collins
Ian Collins <ian-news@hotmail.com>: Feb 02 09:59AM +1300

Jerry Stuckle wrote:
 
> Manufacturers of operating systems and heavily used applications such as
> IBM (where I first learned how to develop and test) don't like product
> recalls, either - and are quite stringent in their testing.
 
You must have missed this memo when you were there:
http://collaboration.csc.ncsu.edu/laurie/Papers/agile07.pdf
 
Care to comment?
 
--
Ian Collins
scott@slp53.sl.home (Scott Lurndal): Feb 01 09:11PM


>Somehow when IBM and software are in same sentence then only horror comes
>to mind ... Rational Rose, ClearQuest, Lotus Notes, WebSphere ... crazy
>stuff done with apparently zero self-awareness whatsoever.
 
Whereas I think "MVS", still highly regarded and very reliable (as z/OS).
Paavo Helde <myfirstname@osa.pri.ee>: Feb 01 11:14PM +0200

On 1.02.2016 21:55, Jerry Stuckle wrote:
>> regardless of how good the design and specifications.
 
> If you do, yes. However, that's more work to correct the error and test
> again. Wasted time for developers and testers.
 
It's not wasted if the codebase turns better - it helps to save the
efforts in the future. And there are no testers involved, I'm talking
about automated test suite runs triggered either be the developer
manually or then automatically by each check-in.
 
 
> I'm not saying you don't change or refactor code. I'm saying you
> shouldn't do it needlessly
 
There is a need to refactor because otherwise the code would slowly turn
into a mess. Some TDD/agile people advocate the idea that each time when
you touch the code, it should leave the codebase generally cleaner, not
dirtier. This means that in addition to adding the concrete feature or
bugfix one should also look at the surrounding code and try to make it
all work more smoothly together.
 
> because you didn't test independent classes
> before dependent ones.
 
Now I am confused. What do you exactly mean by "testing before" and what
this has to do with anything? I am talking about refactoring the code
base when all tests are already succeeding. You cannot refactor
non-working code, it would be pointless. So both the A and B components
must be working and pass their unit tests before you can start refactoring.
 
Cheers
Paavo
Victor Bazarov <v.bazarov@comcast.invalid>: Feb 01 09:22AM -0500

On 2/1/2016 6:22 AM, Stefan Ram wrote:
 
> When a function »m« calls another function »f«, we call »m« a
> »client« of »f«, but how to we call »f« then? One does not
> call a function a »server«, does one?
 
In the latter case I'm more familiar with referring to 'm' as a "caller"
(usually inside the 'f' function), and if one has to give 'f' a special
name, it's a "called function". However, given that the compiler is
free to inline the code (or refrain from generating the code that would
call it _at all_ in some cases), no special term is in common use, I
believe. I have heard a "callee", but not often enough to make it
customary.
 
V
--
I do not respond to top-posted replies, please don't ask
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: