Tuesday, January 16, 2018

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

Ian Collins <ian-news@hotmail.com>: Jan 16 12:38PM +1300

On 01/16/2018 11:59 AM, Alf P. Steinbach wrote:
>> almost as zealously as I remove passing integral types by const reference!
 
> One can make a case for that, e.g. that it supports move semantics by
> default.
 
Move semantics on an int?
 
> But I value default `const`-ness as support for correctness, more than I
> value default mutability as support for that optimization.
 
How often have you seen code which modifies a value parameter? I guess
you could say that they have implied constness...
 
I still like my hazard lights analogy :)
 
--
Ian.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 16 12:41AM +0100

On 1/16/2018 12:01 AM, Mr Flibble wrote:
> lead you to have the false impression that the function *argument* that
> was copied to it was also const or a constant when in fact it was a
> variable.
 
There's nothing in the C++ language that could lead to such confusion.
 
At best you're talking about writing code that will be roughly
understood by people who could mistake a green apple for a broccoli on
account of the similar color, and supporting such people is not my goal.
 
Good luck with that.
 
 
> IMO this, like most of your other idioms, obfuscates rather then
> elucidates.
 
 
Cheers!,
 
- Alf
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 16 12:44AM +0100

On 1/16/2018 12:38 AM, Ian Collins wrote:
 
>> One can make a case for that, e.g. that it supports move semantics by
>> default.
 
> Move semantics on an int?
 
I don't think you actually failed to understand what a default
convention is about.
 
 
 
> How often have you seen code which modifies a value parameter?  I guess
> you could say that they have implied constness...
 
> I still like my hazard lights analogy :)
 
Because it's nothing but an associative label.
 
 
Cheers & hth.,
 
- Alf
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jan 16 12:03AM

On 15/01/2018 23:41, Alf P. Steinbach wrote:
>> that was copied to it was also const or a constant when in fact it was
>> a variable.
 
> There's nothing in the C++ language that could lead to such confusion.
 
Correct; it is your use of said language that is the problem.
 
> understood by people who could mistake a green apple for a broccoli on
> account of the similar color, and supporting such people is not my goal.
 
> Good luck with that.
 
The goal should be for code to be as easy to understand as possible at
both the micro and macro level; at both the call site and the callee
site. Your idioms do the opposite: they obfuscate making code harder to
reason about.
 
/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."
Melzzzzz <Melzzzzz@zzzzz.com>: Jan 16 12:25AM

> }
 
> where bar() is used for brevity and readability only, not as e.g. a
> predicate. Sorry about the synthetic example.
 
I use objects and classes defined in function for that, as I am still on
C++98 ;)
 
--
press any key to continue or any other to quit...
Melzzzzz <Melzzzzz@zzzzz.com>: Jan 16 12:26AM

> both the micro and macro level; at both the call site and the callee
> site. Your idioms do the opposite: they obfuscate making code harder to
> reason about.
 
Well, sure I rememeber good, that declaring function as void f(const int n)
for example is anti pattern ;p
 
 
--
press any key to continue or any other to quit...
Ian Collins <ian-news@hotmail.com>: Jan 16 01:37PM +1300

On 01/16/2018 01:25 PM, Melzzzzz wrote:
 
> I use objects and classes defined in function for that, as I am still on
> C++98 ;)
 
Time to cut the shackles!
 
--
Ian.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 16 01:38AM +0100

On 1/16/2018 1:03 AM, Mr Flibble wrote:
 
> The goal should be for code to be as easy to understand as possible at
> both the micro and macro level; at both the call site and the callee
> site.
 
Nobody confuses actual argument constness with formal argument constness.
 
The term "programmer" would not apply to such a person. Maybe you're
talking about a child of age 7, or someone with an extreme head injury.
Your stipulation of writing code for such a person can be nothing but
trolling, but I choose to answer you seriously.
 
Anyway, for someone confusing formal argument constness with actual
argument constness, your convention of non-const formal argument would
likewise, incorrectly, imply non-const actual argument.
 
No coding convention can save the 8-year old child, or the head injured,
from mis-interpreting your code, in the way that you describe.
 
 
>  Your idioms do the opposite: they obfuscate making code harder to
> reason about.
 
The `const` on a local variable or formal argument isn't an indication
of constness of the source of the value.
 
It's a constraint, saying that this value won't be changing.
 
 
Cheers & hth.,
 
- Alf
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jan 16 12:41AM

On 16/01/2018 00:38, Alf P. Steinbach wrote:
 
> The `const` on a local variable or formal argument isn't an indication
> of constness of the source of the value.
 
> It's a constraint, saying that this value won't be changing.
 
It is superfluous because as the parameter is a value copy changes to it
would have no side effects (certainly for scalar types). It is
obfuscation pure and simple. No need for it.
 
/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."
Ian Collins <ian-news@hotmail.com>: Jan 16 01:48PM +1300

On 01/16/2018 01:38 PM, Alf P. Steinbach wrote:
 
> The `const` on a local variable or formal argument isn't an indication
> of constness of the source of the value.
 
> It's a constraint, saying that this value won't be changing.
 
While true, it is pretty much superfluous and it isn't idiomatic which
makes the ready think twice. As I said up thread, how often have you
seen code which modifies a value parameter?
 
--
Ian.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 16 01:50AM +0100

On 1/16/2018 1:41 AM, Mr Flibble wrote:
 
>> It's a constraint, saying that this value won't be changing.
 
> It is superfluous because as the parameter is a value copy changes to it
> would have no side effects (certainly for scalar types).
 
You're IMO partially right here, but if so then for the wrong reason.
 
In the concrete example (up-thread) the `const` is, IMO, indeed
superfluous, because the function body is just a single function call.
 
But in general the top level `const` on pass-by-value formal argument is
a constraint on what can happen to that value in the function's code,
e.g. when that code is a loop with not grokable-at-a-glance body. It is
not intended as a constraint on what can happen to the actual argument.
I apply the `const` as a general default that supports correctness,
where its absence signals that that formal argument needs to be mutable.
 
 
>  It is obfuscation pure and simple. No need for it.
 
Cheers & hth.,
 
- Alf
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jan 16 12:56AM

On 16/01/2018 00:50, Alf P. Steinbach wrote:
 
> You're IMO partially right here, but if so then for the wrong reason.
 
> In the concrete example (up-thread) the `const` is, IMO, indeed
> superfluous, because the function body is just a single function call.
 
There is no difference between
 
int f(int a, int b)
{
return add(a, b);
}
 
and
 
int f(int a, int b)
{
return a + b;
}
 
as to whether or not a const qualification of the function parameters
would be superfluous. It would be superfluous in both cases.
 
Cheers & I hope this fucking helps.,
 
- 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."
Melzzzzz <Melzzzzz@zzzzz.com>: Jan 16 12:57AM


>> I use objects and classes defined in function for that, as I am still on
>> C++98 ;)
 
> Time to cut the shackles!
 
Heh, not me ;)
 
--
press any key to continue or any other to quit...
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 16 01:59AM +0100

On 1/16/2018 1:48 AM, Ian Collins wrote:
 
> While true, it is pretty much superfluous and it isn't idiomatic which
> makes the ready think twice.  As I said up thread, how often have you
> seen code which modifies a value parameter?
 
It happens. E.g., the common swap idiom for exception safe assignment,
 
auto operator=( Self other )
-> Self
{ swap( *this, other ); }
 
Of course it can be written less succinctly with `const` formal argument:
 
auto operator=( Self const& other )
-> Self
{
Self temp = other;
swap( *this, temp );
}
 
But this version is not just more verbose: disregarding the compiler's
likely optimization it's less efficient for the case of rvalue argument.
 
Cheers & hth.,
 
- Alf
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jan 16 01:04AM

On 16/01/2018 00:59, Alf P. Steinbach wrote:
>     }
 
> But this version is not just more verbose: disregarding the compiler's
> likely optimization it's less efficient for the case of rvalue argument.
 
Both versions exhibit undefined behaviour probably due to over
confidence caused by your egregious non-idiomatic "auto" return type OCD.
 
/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."
Melzzzzz <Melzzzzz@zzzzz.com>: Jan 16 01:08AM

>> likely optimization it's less efficient for the case of rvalue argument.
 
> Both versions exhibit undefined behaviour probably due to over
> confidence caused by your egregious non-idiomatic "auto" return type OCD.
 
Yeah, operator = shoudl return reference to this or some lhs object ;)
 
--
press any key to continue or any other to quit...
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 16 02:42AM +0100

On 1/16/2018 2:04 AM, Mr Flibble wrote:
>> likely optimization it's less efficient for the case of rvalue argument.
 
> Both versions exhibit undefined behaviour probably due to over
> confidence caused by your egregious non-idiomatic "auto" return type OCD.
 
No, it has nothing to do with `auto` (the function declaration syntax).
 
But I forgot a `&` there, it should be
 
-> Self&
 
and there should be a
 
return *this;
 
at the end of each function.
 
Those are silly errors from posting an answer overly quickly, and I'd
like to thank you for pointing it out, even with the added misleading
assertion. I tend to rely on Thunderbird 2036b's automatic check of
posting contents, but it's not yet been implemented. Thanks. :)
 
Cheers!,
 
- Alf
Ian Collins <ian-news@hotmail.com>: Jan 16 02:55PM +1300

On 01/16/2018 02:42 PM, Alf P. Steinbach wrote:
 
> and there should be a
 
> return *this;
 
> at the end of each function.
 
If you are going to use auto, you don't need the suffix return in this
case :)
 
--
Ian.
Jorgen Grahn <grahn+nntp@snipabacken.se>: Jan 16 07:05AM

On Mon, 2018-01-15, Ian Collins wrote:
 
> Um, you are probably in a small minority there. To my eyes they are
> just clutter. In our code base I remove spurious parameter qualifiers
> almost as zealously as I remove passing integral types by const reference!
 
Oddly, I'm with Alf here. Maybe not for tiny function bodies like this one,
but not just for huge ones either.
 
To me, /not/ marking them 'const' signals an intent to modify them
later on in the code.
 
How common that view is, I cannot tell. It has been uncontroversial
where I worked. Perhaps I've done it more than others, but I can't
recall having problems with it in my code reviews.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Jorgen Grahn <grahn+nntp@snipabacken.se>: Jan 16 07:15AM

On Tue, 2018-01-16, Melzzzzz wrote:
> On 2018-01-15, Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
...
>> predicate. Sorry about the synthetic example.
 
> I use objects and classes defined in function for that, as I am still on
> C++98 ;)
 
Yeah, I tried to do that, too, but my point was that you can do it
better now.
 
E.g., I was always hesitant to add a private member function
Foo::baz() when I just wanted to tidy up the implementation of
Foo::bar().
 
As for predicates, it was famously clumpsy to write a small class with
operator() just for one call to std::remove_if() or similar.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
"Öö Tiib" <ootiib@hot.ee>: Jan 15 11:37PM -0800

On Tuesday, 16 January 2018 02:48:39 UTC+2, Ian Collins wrote:
 
> While true, it is pretty much superfluous and it isn't idiomatic which
> makes the ready think twice. As I said up thread, how often have you
> seen code which modifies a value parameter?
 
Looking at couple code bases I see sometimes algorithms to what iterators
are passed. Those more often iterate using iterator parameters instead
of making additional local copies.

There are clear benefits of being conservative but there are also
benefits of being innovative. For example thanks to Alf's attempts of
innovation we have something to discuss and to think twice. ;)
James Kuyper <jameskuyper@verizon.net>: Jan 16 08:47AM -0500

On 01/15/2018 07:48 PM, Ian Collins wrote:
 
> While true, it is pretty much superfluous and it isn't idiomatic which
> makes the ready think twice. As I said up thread, how often have you
> seen code which modifies a value parameter?
 
I treat value parameters the same as any other local variable - which
means it's not particularly uncommon for my code to modify them. For
precisely the same reason, I declare them const according to the same
policy I use for other local variables: they are const by default unless
I plan to modify them.
Thiago Adams <thiago.adams@gmail.com>: Jan 16 03:21AM -0800


> C++ 2011 was both late and immature when it did arrive. Better
> late than never, but things were a mess. The back-porting is to
> finally get C++ 2011 right.
 
What is the motivation to use the latest version
of C++ in the generated code?
You have an external generator, then I presume the
user will not change the generated code. If he does,
then he lost the changes he did. It is one way generation,
is that right?
In this case, the programmer doesn't care about
the code because he don't need to see/change.
In this case C89 has advantages, unless you
have some customization points using templates or
other C++ feature.
C is a very good target for generators.
cdalten@gmail.com: Jan 16 05:30AM -0800

On Wednesday, December 6, 2017 at 3:09:51 PM UTC-8, Lynn McGuire wrote:
> file-system library derived from Boost, and other additions."
 
> 1,605 pages ! ! !
 
> I would still like to see a standard windowing user interface library.
 
Wasn't this attempted on *nix a few decades ago?
David Brown <david.brown@hesbynett.no>: Jan 16 10:52AM +0100

On 15/01/18 19:16, Manfred wrote:
> language that is somewhat more formal than commonly used, i.e. make a
> wider use of the language rules, even those that are not commonly used,
> for the sake of getting acquainted with the rules themselves.
 
People learning a language need to learn both the correct language
rules, and informal usage.
 
> On the other hand, when someone becomes a journalist, then it is
> perfectly understandable to stick to a plain and simple style of
> writing, to facilitate immediate comprehension by the public.
 
Plain, simple, but /correct/ - which is different from the language you
might use for writing a high-brow novel, and also different from the
language you would use at the pub.
 
> real world" (and avoid going beyond what is of common use) is that it is
> nowadays so common to read incorrect grammar everywhere, from private
> email to published newspapers - which is a symptom of widespread ignorance.
 
There are many reasons for this - but I don't think it is because
schools teach kids that "I was, like, LOL!!!! See U l8r" is appropriate
for serious communication.
 
> possible, the student should be able to handle complex constructs, and
> in order to do that he must have used them - so better use them at
> school than at work.
 
I believe you are misunderstanding me.
 
I am not recommending limiting programming, or limiting teaching of
programming, to simple things. As Einstein said, "Everything should be
as simple as it can be, but no simpler". Students of a programming
language must certainly be able to understand more complex code, and
writing it should be part of their training (depending on the level of
the course).
 
I have been talking about code /clarity/, not simplicity. If you are
doing a complex task, the code will be complex - it does not have to be
unclear, even though it is difficult to understand. What I am against
is code that /could/ be easy to understand, but isn't - and I am
certainly against knowingly and intentionally writing code like that.
Whether code is simple or complex, it should be written with an aim of
making it clear. Write it so that your first impressions and quick
glance at the code matches the reality of it. Write it so that when you
look more at the details, it is still consistent. Write is so that when
you fully understand it, it still means the same thing. There should be
/no/ surprises under way in terms of /what/ the code does - even though
there may be surprises or unfamiliar techniques in terms of /how/ it
does it.
 
There can often be judgement calls about how much experience or
knowledge you expect from readers of the code - how much it is
reasonable to expect them to know straight away, and how much they may
have to look up. You don't want your code to be overly verbose just in
case it is a complete newbie that is looking at it. But in this case we
are talking about subtle precedences with relatively rarely user
operator combinations that even experts (including the person writing
the code) might need to look up in reference manuals, and where all the
risk of errors or misunderstandings can be avoided by just adding a pair
of parenthesis. I stand by my judgement that it is crazy to write such
code, and irresponsible to do so in a teaching situation.
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)