Friday, June 8, 2018

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

woodbrian77@gmail.com: Jun 07 07:56PM -0700

> amateur hour startups who think doing a code update every hour and chucking it
> over the wall is a sensible way to work because someone decided to call the
> reactive headless chicken mode of development "Agile".
 
What you call "professional companies" I would probably call
Goliaths. Most, if not all of them, are increasingly lame.
Upstarts like https://duckduckgo.com and my company are here
to pick up the pieces.
 
 
Brian
Ebenezer Enterprises
https://github.com/Ebenezer-group/onwards
boltar@cylonHQ.com: Jun 08 08:25AM

On Thu, 7 Jun 2018 19:56:24 -0700 (PDT)
>> reactive headless chicken mode of development "Agile".
 
>What you call "professional companies" I would probably call
>Goliaths. Most, if not all of them, are increasingly lame.
 
Tell that to Apples $285 billion cash pile. And oddly they don't do a new
release of OS/X or iOS every 5 minutes, they (try) and get it right first.
 
>Upstarts like https://duckduckgo.com and my company are here
>to pick up the pieces.
 
I'm sure Google is quaking in its boots.
 
Besides, 99% of startups that are any good get bought out by a corp anyway
and the rest just provide some hipsters with their organic soya latte money for
a few years then go bust.
Manfred <noname@invalid.add>: Jun 08 06:11PM +0200

On 6/7/2018 8:00 PM, Öö Tiib wrote:
> scenario. We don't design now, we fix a bug correctly and properly,
> right? Hot-fixes cause something even more serious on about 50% of
> cases.
 
This sounds like adding a test case to the unit test (besides fixing the
code), isn't it?
 
Specifically for TDD, I think that for numerical processing code, or
complex systems where you can't go high in test coverage, it is
inherently limited, meaning that for proper quality you need to model
the problem domain first, and design accordingly.
 
That said, a good point that I see in TDD is that sometimes it can help
in understanding better the problem domain itself before starting to
develop the actual code. Something like writing a pilot program in a
reversed way.
legalize+jeeves@mail.xmission.com (Richard): Jun 08 07:34PM

[Please do not mail me a copy of your followup]
 
On Wed, 6 Jun 2018 09:42:37 -0700 (PDT)
 
>The thing that works is quality driven development. Unit tests are good
>tool but people who push that these are silver bullets against numerous
>(all) problems should be treated like all the other snake oil salesmen.
 
Sorry, again, this just feels like a straw man position. I have never
seen anyone try to sell unit testing (before or after writing the
implementation) as a silver bullet.
--
"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 08 07:37PM

[Please do not mail me a copy of your followup]
 
Manfred <noname@invalid.add> spake the secret code
>complex systems where you can't go high in test coverage, it is
>inherently limited, meaning that for proper quality you need to model
>the problem domain first, and design accordingly.
 
Property-based testing and fuzz testing shows some promise here.
However, I've never seen a TDD advocate that proposed it as an
alternative to understanding the problem domain or appropriate design,
so that feels like another straw man point.
 
Feel free to cite a case where a well known TDD advocate proposes it
as a substitute for understanding the problem domain.
 
I say "well known" because like anything, there are lots of people who
don't know what they are talking about and call it "TDD" or "Agile" or
whatever. I have literally seen people who don't know what they are
talking about say, in a lightning talk at an agile conference, that
the problem with agile is that it's not waterfall.
--
"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>
"Öö Tiib" <ootiib@hot.ee>: Jun 08 03:28PM -0700

On Friday, 8 June 2018 22:34:12 UTC+3, Richard wrote:
 
> Sorry, again, this just feels like a straw man position. I have never
> seen anyone try to sell unit testing (before or after writing the
> implementation) as a silver bullet.
 
Its not straw man but reality. It is real position actually in work.
I'm indifferent if the uncle bobs and jeffries actually meant it.
I hear them referred as source of that industry-damaging nonsense.
I have used unit tests for decades but now it has been made yet
another silver bullet junk perhaps thanks to those TDD morons not
making their positions clear.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jun 07 10:49PM +0200


>> Cheers!,
 
>> - Alf
 
> The question was from trying wrapping clib function getaddrinfo(2)
 
Like this:
 
------------------------------------------------------------------------------
// Source encoding: utf-8
// MinGW g++ build: "g++ main.cpp -std=c++17 -lws2_32 -lntdll"
 
#include <stdlib/all/basics.hpp> //
https://github.com/alf-p-steinbach/Wrapped-stdlib
using namespace stdlib::ext::hopefully_and_fail; // hopefully, fail
using namespace stdlib::ext::type_builders; // ptr_, ref_
 
#include <winsock2.h>
#include <ws2tcpip.h> // getaddrinfo, inet_ntop
 
// Goal: to wrap
//
// int WSAAPI getaddrinfo(
// ptr_<char const> pNodeName,
// ptr_<char const> pServiceName,
// ptr_<const addrinfo> pHints,
// ptr_<ptr<addrinfo>> ppResult
// );
 
#if defined( __GNUC__ ) and not defined( NO_INET_NTOP_FIX )
inline auto inet_ntop(
const int family,
const ptr_<const in6_addr> address,
const ptr_<char> buffer,
const socklen_t buffer_size
)
{
assert( family == AF_INET6 ); (void) family;
assert( buffer_size >= INET6_ADDRSTRLEN ); (void) buffer_size;
RtlIpv6AddressToStringA( address, buffer );
return buffer;
}
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)