Tuesday, April 10, 2018

Digest for comp.lang.c++@googlegroups.com - 25 updates in 7 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>
Jorgen Grahn <grahn+nntp@snipabacken.se>: Apr 04 01:36PM

On Tue, 2018-04-03, Richard wrote:
 
> Your testing alternative is link-time substitution. It's a giant
> PITA, but you can do it if you really dislike abstract interface
> injection.
 
That's an alternative I'd like to investigate. At a previous
workplace we briefly considered it, but didn't know how to go about
it. Noone wanted to link test code into the product by accident, and
so on.
 
Then we introduced testability by dependency injection, and noone was
really happy with the result.
 
(And then we introduced component tests, since we had really well-
defined runtime components, and these were the ones that ended up
catching the bugs.)
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Apr 05 12:51PM -0700

On 4/5/2018 10:28 AM, Mr Flibble wrote:
>> benefit of SOLID design principles.
 
> TDD is cancer. Designing software by fixing failing tests is no way to
> design software.
 
Imvho, fixing a failing test can be beneficial. ;^)
Vir Campestris <vir.campestris@invalid.invalid>: Apr 05 09:35PM +0100

On 05/04/2018 18:01, Mr Flibble wrote:
> language compiler which has no such concept as vtables and virtual
> functions which means that "runtime polymorphism" is a nonsense as it
> doesn't actually exist.
 
After compilation all those nice high level abstractions have
disappeared in a cloud of assembler (or not even that, depending on your
compiler). And yet, runtime polymorphism does exist.
 
A C program could choose to put a function pointer into a struct, and
have the calling program use the function pointer. That's runtime
polymorphism. You could do it in assembler if you were that perverse. In
fact I have a vague memory of doing just that for an API many MANY years
ago, back when assembler efficiency mattered more than developer man hours.
 
(If there were lots of these you might want to put all the pointers in a
table shared between similar structs. You could call it a vtable.)
 
Andy
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>
Paavo Helde <myfirstname@osa.pri.ee>: Apr 05 08:29PM +0300

On 5.04.2018 9:27, Tim Rentsch wrote:
> just over 190 functions, the the median function length was 7
> lines, the average just over 20, and the (only) 51 line function
> coming in at 92+ percentile.
 
Uh-oh. Just yesterday I had a code review of a 239-line function,
containing a 187-line lambda in the middle. The author was not happy at
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.
 
I am not hoping he will be making 10-line functions, our modest goal is
50 lines at the moment.
 
Cheers
Paavo
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Apr 04 06:53PM +0100

On 04/04/2018 15:22, Rick C. Hodgin wrote:
[snip]
 
> You have a very wrong opinion and view of me. It's colored by your
> personal hatred of God, and the teachings I have to people regarding
> their sin.
 
I don't hate God because I know God doesn't exist. Speed of light mate.
 
/Flibble
 
--
"Suppose it's all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates
a world that is so full of injustice and pain. That's what I would say."
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Apr 04 01:57PM +0100

On 04/04/2018 13:37, Rick C. Hodgin wrote:
 
> My opinion. I think you'd reach many more users with a lower price
> point. You'd also be helping many more projects achieve fewer bugs,
> which in turn helps all of the users of those products.
 
Pretentious cockwomble.
 
/Flibble
 
--
"Suppose it's all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates
a world that is so full of injustice and pain. That's what I would say."
computer45 <computer45@cyber.com>: Apr 07 09:37AM

Post in violation of terms-of-service cancelled by Sir Cancelot <cancelbot@eternal-september.org>
From: computer45 <computer45@cyber.com>
Subject: Re: About PhDs in computer science..
Message-ID: <p966vc$jks$1@dont-email.me>
Newsgroups: comp.lang.c++
bartc <bc@freeuk.com>: Apr 10 12:41AM +0100

On 09/04/2018 17:30, Rick C. Hodgin wrote:
> to default to CAlive's syntax, which can either be instance settings,
> #pragmas, or command line switches.  Other new features do not break
> backward compatibility and are enabled by default.
 
That's the wrong approach IMO.
 
It means you can't look at a fragment of code and know what it means. Or
email or post code without also explaining what settings are intended.
Or copy & paste code between files which use different settings.
 
As it is, it will already look like C or C++ (or anything with braces
for that matter). It needs to have a strong identity of its own.
 
But, it's your project.
 
--
bartc
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 09 04:54PM -0700

On Monday, April 9, 2018 at 7:41:41 PM UTC-4, bartc wrote:
 
> It means you can't look at a fragment of code and know what it means. Or
> email or post code without also explaining what settings are intended.
> Or copy & paste code between files which use different settings.
 
I have a large code base that I've written over decades. I plan to
fully support my own code base. And I eventually want to provide
full C90 and C99 support so that people who have C code today can
switch to CAlive and make the migration in stages.
 
> As it is, it will already look like C or C++ (or anything with braces
> for that matter). It needs to have a strong identity of its own.
 
> But, it's your project.
 
I appreciate your input. I've given this a lot of thought. It's
not an idle or rash decision.
 
I think C is an amazing language. I think C++ added tremendously
valuable extensions, but went way too far. CAlive is an attempt
to combine some of those extensions to C, to remove some of C's
limitations, to take a different view of data through strict
typing by variable, but easy of transformation through union-like
constructs. I also have new ideas I want to incorporate.
 
Time will tell. It's a large project and I can't find anyone to
help me. So, it will take time and effort over years.
 
--
Rick C. Hodgin
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Apr 09 04:59PM -0700

On 4/9/2018 4:54 PM, Rick C. Hodgin wrote:
> fully support my own code base. And I eventually want to provide
> full C90 and C99 support so that people who have C code today can
> switch to CAlive and make the migration in stages.
 
Just a quick high level idea that can get your work out there:
 
Get a server.
 
Put a little websever on it.
 
Put your compiler on it.
 
Create a HTML based front end.
 
Send code generated from the webpage to the webserver.
 
Send the code from the webserver to the compiler.
 
Compile it; run it.
 
Send generated output to the user viewing the webpage.
 
You surly have something that can compile a hello world program right?
 
 
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 09 05:21PM -0700

On Monday, April 9, 2018 at 7:59:49 PM UTC-4, Chris M. Thomasson wrote:
> Put a little websever on it.
> Put your compiler on it.
> Create a HTML based front end...
 
You've mentioned this several times. So you'll stop posting about
it, know that I will never do this. It has no part of any desire
of my goals. CAlive uses a new ABI and is designed to work with a
developer during development. It does not simply run or fail as
other code does. A CAlive program with errors will compile and run
until it reaches the error code, then it will enter a new state
called an inquiry.
 
When it is completed and released publicly, you can study it if
you want to. Until then ... please stop requesting that I do this
thing you desire. I will never do it.
 
--
Rick C. Hodgin
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Apr 09 05:41PM -0700

On 4/9/2018 5:21 PM, Rick C. Hodgin wrote:
 
> You've mentioned this several times. So you'll stop posting about
> it, know that I will never do this. It has no part of any desire
> of my goals.
 
It can help get it out there.
 
 
> other code does. A CAlive program with errors will compile and run
> until it reaches the error code, then it will enter a new state
> called an inquiry.
 
This can all be accomplished by creating a compatible debugging GUI in
HTML5.
 
 
> When it is completed and released publicly, you can study it if
> you want to. Until then ... please stop requesting that I do this
> thing you desire. I will never do it.
 
Okay. Well, can you show us a simple hello world program in CAlive right
now?
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 09 05:51PM -0700

On Monday, April 9, 2018 at 8:41:25 PM UTC-4, Chris M. Thomasson wrote:
> > it, know that I will never do this. It has no part of any desire
> > of my goals.
 
> It can help get it out there.
 
I don't have a goal to "get it out there." I have a goal to design
and code it right, and let the tool's own merits speak for itself,
allowing people who have come to use it to tell other people about
it.
 
> > called an inquiry.
 
> This can all be accomplished by creating a compatible debugging GUI in
> HTML5.
 
Yes. I have no interest and will never do it.
 
> > thing you desire. I will never do it.
 
> Okay. Well, can you show us a simple hello world program in CAlive right
> now?
 
I am not here to cater to your whims, Chris. When the product is
released you'll be able to download it, source code and all, and
examine it fully.
 
--
Rick C. Hodgin
David Brown <david.brown@hesbynett.no>: Apr 10 12:22PM +0200

On 09/04/18 18:25, bartc wrote:
 
> This syntax comes from C, which C++ unwisely adopted (I believe in the
> interests of improving take-up of the language which would have been
> harder with an incompatible new syntax).
 
It would have been better if it had never been possible to mix a type
and pointers to the type in a single declaration in C. But since C had
it, C++ had no choice about how to interpret the same code.
 
What would have been possible in C++ would be to deprecate the mixture -
allowing either "int a, b;" or "int *a, *b;" but giving an error for
"int a, *b;" or "int *a, b;" regardless of white space positioning.
 
> use the right tools, use the right guidelines (one declaration per line)
> and learn C properly so you that will know that the example declares one
> pointer only.
 
People make mistakes with this sort of thing, and it would have been
better (IMHO) if mixing types and pointers in one declaration had never
been allowed in C (or C++). But it is not a /problem/ - if you don't
make such mixes, you don't get it wrong. And if you /do/ get it wrong,
you will almost certainly get an error somewhere in the code when you
use the variables.
 
/Problems/ come when there are mistakes you can easily make that are
hard to spot, hard to avoid despite good coding rules, and which are not
easily detected automatically by tools. There are plenty of /real/
problem areas in C - you don't need to invent them out of things that
are simply not as nice as they could have been.
 
 
> even, if you've mistyped and CWhatever is the name of a variable rather
> than a type, end up writing an expression that multiplies CWhatever by
> a, then yields the value b.
 
First, however, you will have had an expression that assigns a value to
a or b - that will always come before the use of the variable. And that
assignment is generally going to be a syntax error unless you are
over-zealous with casting.
 
There will be occasions where both T and T* types are valid, but they
are rare.
 
 
> If this is a new language, why repeat the mistake of C++ and try and
> have compatible syntax? Do something obviously new rather than
> perpetuating design errors from 50 years ago.
 
Agreed.
 
 
> If you need compatibility, do something like this:
 
> CWhatever *a, b; // old rules, one pointer
> var CWhatever *a, b; // new rules, two pointers
 
Disagreed.
 
> and use the new form until the old can be deprecated. Then you can drop
> the 'var'. And not need to rely on white space to alter meaning.
 
Strongly disagreed - making a significant change in the interpretation
would be crazy.
 
Try this:
 
CWhatever *a, b;
-> Warning - mixing types and pointers is deprecated in "C mode"
-> Error - mixing types and pointers is not allowed in "CAlive mode"
 
The alternative is to use a noticeably different syntax to avoid the
possibility of errors or confusion. For example:
 
var CWhatever : a, b; // not pointers
var CWhatever* : a, b; // both pointers
var CWhatevr : *a, b; // syntax error
David Brown <david.brown@hesbynett.no>: Apr 10 12:27PM +0200

On 09/04/18 16:47, Rick C. Hodgin wrote:
 
> 04 -- "ambiguous declaration, assuming type CWhatever* for a, b."
 
> And any alternate uses of those types would produce relative errors,
> with the diagnostic there to aid in discovery / recovery.
 
Declarations like this should not be ambiguous, but clearly defined by
the language. Having warnings (or even error messages) here is a good
thing, but I would have something like "mixed declaration" rather than
"ambiguous declaration".
gazelle@shell.xmission.com (Kenny McCormack): Apr 10 10:49AM

In article <pai39g$bbl$1@dont-email.me>,
David Brown <david.brown@hesbynett.no> wrote:
...
>mixture - allowing either "int a, b;" or "int *a, *b;" but giving
>an error for "int a, *b;" or "int *a, b;" regardless of white space
>positioning.
 
Except that it would break existing code...
 
--
Just for a change of pace, this sig is *not* an obscure reference to
comp.lang.c...
Lynn McGuire <lynnmcguire5@gmail.com>: Apr 09 08:52PM -0500

Why is "std::string propBulkRow = 0;" legal ?
 
This compiles just fine on Visual C++ 2015.
 
Thanks,
Lynn
Melzzzzz <Melzzzzz@zzzzz.com>: Apr 10 02:19AM

> Why is "std::string propBulkRow = 0;" legal ?
 
> This compiles just fine on Visual C++ 2015.
 
Because string takes char * pointer in constructor.
Since 0 converts to NULL pointer this is legal.
Byted me several times. Recently, gcc implementation throws
exception,earlier it just segfualted.
 
--
press any key to continue or any other to quit...
Barry Schwarz <schwarzb@dqel.com>: Apr 10 12:11AM -0700

On Mon, 9 Apr 2018 20:52:46 -0500, Lynn McGuire
 
>Why is "std::string propBulkRow = 0;" legal ?
 
>This compiles just fine on Visual C++ 2015.
 
Because there is an implicit conversion from the integer 0 to the
character '0x00'.
 
--
Remove del for email
"Öö Tiib" <ootiib@hot.ee>: Apr 10 12:43AM -0700

On Tuesday, 10 April 2018 10:11:44 UTC+3, Barry Schwarz wrote:
 
> >This compiles just fine on Visual C++ 2015.
 
> Because there is an implicit conversion from the integer 0 to the
> character '0x00'.
 
That is not the reason. The std::basic_string<> does not have
any conversion constructions from CharT.
"Öö Tiib" <ootiib@hot.ee>: Apr 10 02:20AM -0700

On Tuesday, 10 April 2018 04:52:58 UTC+3, Lynn McGuire wrote:
> Why is "std::string propBulkRow = 0;" legal ?
 
> This compiles just fine on Visual C++ 2015.
 
That has been always legal since 0 is valid pointer constant.
C++11 has added more fun:

std::string falseText{false}; // also compiles
Paavo Helde <myfirstname@osa.pri.ee>: Apr 10 12:25PM +0300

On 10.04.2018 4:52, Lynn McGuire wrote:
> Why is "std::string propBulkRow = 0;" legal ?
 
> This compiles just fine on Visual C++ 2015.
 
With gcc, you can have it failing:
 
> g++ test1.cpp -Werror=zero-as-null-pointer-constant
 
test1.cpp:3:28: error: zero as null pointer constant
[-Werror=zero-as-null-pointer-constant]
std::string propBulkRow = 0;
^
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 09 04:35PM -0700

On Monday, April 9, 2018 at 7:16:00 PM UTC-4, Chris M. Thomasson wrote:
> Would you consider using the treatment or not?
 
The fact that you ask the question indicates you do not understand
anything about Christians, or what it means to be Christian. You're
still looking at things through tainted eyes, and a tainted mind.
 
If you want to know the truth, you know where to find it. Read and
study the Bible. Go to a Bible believing, Bible studying, Bible teach-
ing church and ask to speak to born again believers face-to-face.
 
Seek to learn the truth, Chris. Don't just scheme to trap people
into caged Q&A of your own contrivance.
 
--
Rick C. Hodgin
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)