Wednesday, December 14, 2022

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

Juha Nieminen <nospam@thanks.invalid>: Dec 14 06:23AM

>>"generateRandomValue" is better than "genRandVal". "column_index" is
>>better than "i".
 
> Not if you end up with a wall of text like a lot of Java code.
 
And there we go again with the length argument.
 
Length. Does. Not. Matter. What matters is readability.
 
>>(An exception is if the contraction or acronym is universally used and
>>understood, like "GPS", "HDMI", "cos", "tan", etc.)
 
> 'i' is VERY common as an index value in for().
 
But since 'i' does not refer to anything specific, it's better and more
readable if you express what you are indexing with it. This is especially
true the more loops there are (they don't even have to be nested).
 
I honestly cannot understand why you are even opposing that.
 
 
> In that case whats the point of having a namespace at all? You can achieve
> exactly the same result C style with function naming. Eg: instead of
> mylib::func() you can just call it mylib_func().
 
If you want to do that, go right ahead.
Juha Nieminen <nospam@thanks.invalid>: Dec 14 07:36AM

>> exactly the same result C style with function naming. Eg: instead of
>> mylib::func() you can just call it mylib_func().
 
> If you want to do that, go right ahead.
 
In fact, I have noticed a rather interesting psychological phenomenon
related to this.
 
Many C++ programmers will fight tooth and nail to defend their practice
of not writing namespace prefixes and the use of 'using' to allow them
to do that... and the exact same people never, ever, ever complaining
about having to write prefixes in names declared in many C libraries.
 
They hate the guts of namespace prefixes, but they have zero problems
if the prefix is actually in the names themselves, separated with an
underscore instead of ::.
 
Why? Your guess is as good as mine. I could present some shaky
psychological hypotheses, but ultimately I have no idea.
 
So, in this sense, it's actually *better* to attach the namespace to
the names themselves (with an underscore) because that will stop people
from going their way to avoid writing those prefixes, and their code
will automatically become more readable, and they will stop complaining
about the namespace prefixes. Take advantage of this curious psychological
phenomenon.
Juha Nieminen <nospam@thanks.invalid>: Dec 14 08:38AM

> what makes code more and less readable and understandable. For example,
> I could write an entire book on naming conventions alone, and how they
> can make the code so much more readable, or make it almost inscrutable.
 
I am reminded of this painful fact right today because I am, once again,
reviewing code written by other people. Code that's full of cryptic
inscrutable acronyms and abbreviations that make it infuriatingly hard
to understand what the code is doing.
 
The problem that the vast majority of programmers have is that when they
are writing code it's extremely clear *to them* what each variable means
and what its role is. However, to a third-party reader who is reading the
code for the first time it's not necessarily so.
 
The second problem is that people, for some reason, instinctively want to
write names that are as short as possible, as contracted and abbreviated
as possible, as compressed as possible, just to save typing a few
characters.
 
The problem is that when they are writing some kind of algorithm, the
algorithm itself, and each variable, is clear to the programmer who is
writing the code, but may not be clear at all to a third-party reader.
 
Thus you end up with cryptic acronyms like "tpl" and "tpr" and the like.
What are those supposed to mean? Maybe "l" stands for "left" and "r"
stands for "right"?
 
Turns out that they are supposed to stand for "test point left" and
"test point right". Finding that out is extra difficult because of the
code that initializes them is likewise cryptic, something along the
lines of "tpl = l.p;" which says nothing. What's with this obsession
with brevity? It makes code needlessly inscrutable and cryptic for
absolutely no benefit.
 
There's literally no reason why those acronyms couldn't be fully spelled
out, using full English words. "test_point_left" and "test_point_right"
are so much more readable and understandable. They immediately tell the
reader what they are supposed to be, and the reader doesn't have to try
to solve the puzzle of what "tpl" stands for by trying to decipher the
rest of the likewise-cryptic code.
 
Some people will still oppose this, for some reason. But you cannot
change what I am seeing. You are not going to make this code more readable
no matter how many times you repeat that the cryptic acronyms are
actually the ones that are more readable.
Muttley@dastardlyhq.com: Dec 14 09:33AM

On Tue, 13 Dec 2022 11:10:27 -0800 (PST)
 
>bool value2 = v[1];
 
>are both values, but different. Mutating value1 has side effects, mutating
>value2 does not.
 
IOW the auto type can differ from expectations.
 
TBH I've always avoided vector<bool> because of its specialisation. This is
another reason not to use it.
Muttley@dastardlyhq.com: Dec 14 09:35AM

On Wed, 14 Dec 2022 06:23:05 -0000 (UTC)
 
>> Not if you end up with a wall of text like a lot of Java code.
 
>And there we go again with the length argument.
 
>Length. Does. Not. Matter. What matters is readability.
 
Clearly you've not worked with much Java code.
 
>>>understood, like "GPS", "HDMI", "cos", "tan", etc.)
 
>> 'i' is VERY common as an index value in for().
 
>But since 'i' does not refer to anything specific, it's better and more
 
It doesn't need to, its simply an index counter. Everyone knows it as an
index counter.
 
>I honestly cannot understand why you are even opposing that.
 
Long winded names are as bad as names that are meaningless.
 
>> exactly the same result C style with function naming. Eg: instead of
>> mylib::func() you can just call it mylib_func().
 
>If you want to do that, go right ahead.
 
Its exactly what you're doing except you don't seem to realise it.
Muttley@dastardlyhq.com: Dec 14 09:43AM

On Wed, 14 Dec 2022 07:36:04 -0000 (UTC)
>of not writing namespace prefixes and the use of 'using' to allow them
>to do that... and the exact same people never, ever, ever complaining
>about having to write prefixes in names declared in many C libraries.
 
Err, because there's no choice with C?
 
>will automatically become more readable, and they will stop complaining
>about the namespace prefixes. Take advantage of this curious psychological
>phenomenon.
 
You need to look in the mirror. *You* are the one who uses the namespace name
*inside* itself. How is mynamespace::func() any different from writing
mynamespace_func()?
 
Most sensible C++ devs would just write func() inside that namespace which
is the whole point of namespaces. Why did you think they were invented in
the first place? Bjorn could have just gone with long function prefixes.
Ben Bacarisse <ben.usenet@bsb.me.uk>: Dec 14 11:54AM

> auto value = v[1];
> value = true;
> assert(v[1] == false); // fails
 
That "fail" is so obvious that I think there must be a better example of
something that will baffle the reader.
 
Is a wide-spread idiom in which some aggregate accessory (like
operator[]) really returns something that behaves like a reference but
which is defeated by the use of auto?
 
> C++ series, and that was also liberally sprinkled with auto, he would have
> to put some effort into convincing himself that it didn't have "auto value =
> copy of proxy" landmines.
 
Can you give a cut-down example? I can't shake the feeling that the
problem might not be with auto, but with the idiom that is defeated by
using auto. (Not that I want to defend all uses of auto. C++'s types
are so potentially baroque and open to abuse that knowing the exact type
might very well be beneficial at times.)
 
--
Ben.
Juha Nieminen <nospam@thanks.invalid>: Dec 14 12:19PM

> You need to look in the mirror. *You* are the one who uses the namespace name
> *inside* itself. How is mynamespace::func() any different from writing
> mynamespace_func()?
 
In the latter the prefix is mandatory, in the former it's not.
 
With the prefix it becomes a lot clearer where that func() is, and thus
the code is much easier to understand.
 
> Most sensible C++ devs would just write func() inside that namespace which
> is the whole point of namespaces. Why did you think they were invented in
> the first place? Bjorn could have just gone with long function prefixes.
 
Bjarne. And he isn't a Perfect God who is always right.
 
Namespaces can have other uses, such as bringing the names of one namespace
into another (which, in a way, is a bit like "inheriting" the other
namespace).
Juha Nieminen <nospam@thanks.invalid>: Dec 14 12:28PM


>>But since 'i' does not refer to anything specific, it's better and more
 
> It doesn't need to, its simply an index counter. Everyone knows it as an
> index counter.
 
What's so hard to understand in the fact that the name 'i' does not tell
me _anything_ about what it's going to be used for? And that if it's
named so that it tells what it's going to index, it makes the for loop
line immediately clearer, because it's directly telling me what we
are looping. Also, if the amount of code in the loop is even slightly
long, a quick visual scan will reveal all the instances of eg.
"column_index" a lot easier than an "i" buried somewhere inside
some square brackets at random places.
 
This becomes *especially* important with nested loop. You wouldn't
believe how significantly clearer it is when each loop variable is
named clearly after what it's going to index, compared to if they
are just named 'i', 'j' and 'k'.
 
I honestly cannot understand what's so controversial about this.
It should be quite self-evident: When you express what it's being
used for, it's much easier to understand than if it's just a
short generic name that says nothing.
 
>>I honestly cannot understand why you are even opposing that.
 
> Long winded names are as bad as names that are meaningless.
 
That's just a completely asinine assertion.
 
If long-winded names are bad, then why do you use long words when
you write English? Why don't you contract every word you use?
 
You use full English words because if you were to contract every
word your text would become illegible. Why is code any different?
 
I just find it baffling how this seems to be so controversial.
*Tell what you are doing* in your code. Don't make it cryptic and
obscure for no reason. This should be good programming 101.
We are not writing code for the obfuscated C code contest.
 
>>> mylib::func() you can just call it mylib_func().
 
>>If you want to do that, go right ahead.
 
> Its exactly what you're doing except you don't seem to realise it.
 
I fail to see the problem.
David Brown <david.brown@hesbynett.no>: Dec 14 02:11PM +0100

On 14/12/2022 08:36, Juha Nieminen wrote:
> of not writing namespace prefixes and the use of 'using' to allow them
> to do that... and the exact same people never, ever, ever complaining
> about having to write prefixes in names declared in many C libraries.
 
Really?
 
I wonder if you have very odd colleagues, or if you interpret things
differently from myself (and apparently some others in this thread).
 
I use "using" locally in functions when it makes code simpler and
clearer, because it makes names shorter and has less clutter. It also
makes it clearer that I am "using" a particular imported namespace. If
I have a namespace called "display", and I am writing a function that
uses the display, it is a /good/ thing to write "using namespace
display;" in that function. It is a /good/ thing to write "clear();" or
"get_dimensions()" rather than "display::clear();" and
"display::get_dimensions()".
 
Obviously if there is ambiguity, you need to use namespace prefixes.
 
In C, people /do/ grumble about long and awkward names with no scoping.
They minimise the problem by using short abbreviations for their
prefixes, and they don't complain too much because it is pointless to
complain too much since there is no alternative.
 
 
> They hate the guts of namespace prefixes, but they have zero problems
> if the prefix is actually in the names themselves, separated with an
> underscore instead of ::.
 
As you have been doing throughout this thread, you are wildly exaggerating.
 
People don't like having to write long prefixes when it is obvious from
the context of the code which library or set of identifiers you are
using. They don't like it in C, and they don't like it in C++. The
difference is that in C you are stuck with using it, while in C++ you
have multiple options for structured and scoped naming - and sometimes
you have the option of reducing the verbosity by a "using" clause.
 
> will automatically become more readable, and they will stop complaining
> about the namespace prefixes. Take advantage of this curious psychological
> phenomenon.
 
I believe this "curious psychological phenomenon" is primarily in your
own mind, not in the minds of other programmers.
Frederick Virchanza Gotham <cauldwell.thomas@gmail.com>: Dec 14 12:44AM -0800

The following code up on GodBolt:
 
https://godbolt.org/z/bfs3qn5Gx
 
prints out:
 
Dog takes l-value ref
Monkey takes r-value ref
Hello
 
I expected it to say "Monkey takes l-value ref".
 
Is the behaviour undefined because of my use of 'forward' on Line #22? Should 'forward' only be used with a so-called 'template parameter forwarding reference'?
Bo Persson <bo@bo-persson.se>: Dec 14 10:26AM +0100

On 2022-12-14 at 09:44, Frederick Virchanza Gotham wrote:
> Hello
 
> I expected it to say "Monkey takes l-value ref".
 
> Is the behaviour undefined because of my use of 'forward' on Line #22? Should 'forward' only be used with a so-called 'template parameter forwarding reference'?
 
You are using it wrong, anyway. When the value is an int&, you should
"forward" is using forward<int&>(arg).
 
That's what happens with a forwarding reference.
Frederick Virchanza Gotham <cauldwell.thomas@gmail.com>: Dec 14 01:48AM -0800

On Wednesday, December 14, 2022 at 9:27:06 AM UTC, Bo Persson wrote:
 
> You are using it wrong, anyway. When the value is an int&, you should
> "forward" is using forward<int&>(arg).
 
> That's what happens with a forwarding reference.
 
 
If I knew for certain that it was an "int&" then why would I bother using 'forward' on it?
 
The question I'm asking is why 'forward' in this case is turning an L-value into an R-value?
Is it because it's UB to use 'forward' on something that isn't a "template parameter forwarding reference"?
Bo Persson <bo@bo-persson.se>: Dec 14 12:42PM +0100

On 2022-12-14 at 10:48, Frederick Virchanza Gotham wrote:
>> "forward" is using forward<int&>(arg).
 
>> That's what happens with a forwarding reference.
 
> If I knew for certain that it was an "int&" then why would I bother using 'forward' on it?
 
Beats me, it was your example.
 
 
> The question I'm asking is why 'forward' in this case is turning an L-value into an R-value?
 
Because that's how template argument deduction works. When you
explicitly supply <int> to a function returning T&&, you get an int&&.
No surprise here.
 
> Is it because it's UB to use 'forward' on something that isn't a "template parameter forwarding reference"?
 
No, but not very useful. The whole idea of std::forward is that it can
adapt to the deduced template parameter. If there is no template, it is
outside if the intended use pattern.
Juha Nieminen <nospam@thanks.invalid>: Dec 14 12:41PM

> If I knew for certain that it was an "int&" then why would I bother
> using 'forward' on it?
 
std::forward is useful mainly with templated types. It's not all that
useful with concrete types.
 
The main idea with std::forward is that it preserves lvalues as lvalues
and rvalues as rvalues when passing parameters to other functions (if
you don't use std::forward and tried to pass the function parameter
directly then an rvalue would decay to an lvalue, because a named
variable always decays to an lvalue, unless explicitly cast to an
rvalue). In order to do this you need to provide it with the original
type of the value you are passing, as a template parameter. This
would usually be the original template type that that parameter has.
Lynn McGuire <lynnmcguire5@gmail.com>: Dec 13 07:35PM -0600

On 12/13/2022 4:03 PM, d thiebaud wrote:
 
>> Isn't that new programming language suppose to be Go and Rust ?
 
>> Lynn
 
> And D, among others. I wish D had caught on more.
 
Looks like D is still hanging around.
https://dlang.org/
 
Lynn
d thiebaud <thiebauddick2@aol.com>: Dec 13 09:13PM -0500

On 12/13/22 20:35, Lynn McGuire wrote:
 
> Looks like D is still hanging around.
>    https://dlang.org/
 
> Lynn
 
Yes, but it hasn't had the success I hoped for.
"Öö Tiib" <ootiib@hot.ee>: Dec 13 08:06PM -0800

On Tuesday, 13 December 2022 at 22:15:21 UTC+2, Lynn McGuire wrote:
 
> > Time to create yet another new programming language that's a "better C++"!
 
> > And throw it in the same heap as the myriads of other such languages.
> Isn't that new programming language suppose to be Go and Rust ?
 
Oracle wants it is Java, Google wants it is Go, Apple wants it is Swift,
Microsoft wants it is C#.
 
So when they are not dealing with above argument they fight
against C, C++, D, Rust and Kotlin somewhat. No one
supports those languages any more than they need for
their own internal things.
"daniel...@gmail.com" <danielaparker@gmail.com>: Dec 13 08:17PM -0800

On Tuesday, December 13, 2022 at 11:06:36 PM UTC-5, Öö Tiib wrote:
> against C, C++, D, Rust and Kotlin somewhat. No one
> supports those languages any more than they need for
> their own internal things.
 
Google most decidedly supports Kotlin. Microsoft is poking
around with rust. Google is also putting resources into Carbon,
and pulling resources away from clang.
Muttley@dastardlyhq.com: Dec 14 09:39AM

On Tue, 13 Dec 2022 17:03:13 -0500
 
>> Isn't that new programming language suppose to be Go and Rust ?
 
>> Lynn
 
>And D, among others. I wish D had caught on more.
 
Don't forget Dart. Another emanation from Google which no doubt they'll get
bored with in a few years and drop like most of their projects.
 
And on MacOS there's Swift which is supposed to be a better Objective C.
Frankly it couldn't be much worse. Why Apple don't just use modern C++ and
get all the benefits not to mention experienced devs on board is anyones guess.
d thiebaud <thiebauddick2@aol.com>: Dec 14 04:40AM -0500

On 12/13/22 20:35, Lynn McGuire wrote:
Juha Nieminen <nospam@thanks.invalid>: Dec 14 12:34PM

> And on MacOS there's Swift which is supposed to be a better Objective C.
> Frankly it couldn't be much worse. Why Apple don't just use modern C++ and
> get all the benefits not to mention experienced devs on board is anyones guess.
 
Having programmed quite a lot not only in Objective-C, but in Objective-C++,
I kind of like the language.
 
Its C, an object-oriented extension of C, and C++, all piled up in one
huge heap, which in theory sounds like it would be a huge mess... but
perhaps a bit surprisingly it worked quite well, IMO.
 
Objective-C adds to the language several things that C++ simply cannot
add (such as runtime introspection), and C++ adds things that Objective-C
does not add (such as RAII and templates), and combined they work
surprisingly well, even though it might sound like a huge mess.
 
But I suppose the people at Apple finally decided that it's too big of
a mess, so they decided to create their own "simpler and cleaner"
language, which is completely incompatible with C++. And that's the
point at which I completely lost interest.
Vir Campestris <vir.campestris@invalid.invalid>: Dec 14 10:42AM


> error: expression contains unexpanded parameter pack 'T'
 
> in clang.
 
> Is there a way to get the type inside the function?
 
Surely the right way to code this is with an explicit specialisation
 
template<> auto sum(string&& args)
 
rather than a runtime check?
 
Andy
khalid khan <khalidmubarak0302@gmail.com>: Dec 14 02:23AM -0800

If you're a fan of Mathilde Tantot, then you'll be happy to know that she has an onlyfans account! On her onlyfans account, you'll find all sorts of exclusive content that you won't find anywhere else. From behind the scenes videos and photos to sexy lingerie shoots and more, there's something for everyone on Mathilde's onlyfans account. So if you're looking for a way to get closer to your favorite French model, be sure to check out her onlyfans account today!
 
Link Here
https://t.co/VAvme1zmcB
 
Details Here mathilde tantot onlyfansAs many of you know, I am a big fan of the Mathilde Tantot. I have been following her on social media for quite some time and I was really excited when I found out that she had started an OnlyFans account!I have to say, I was not disappointed. The content on her OnlyFans is fantastic. There are a ton of great pictures and videos, and she seems to be constantly adding new content.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 13 11:35PM -0800

On 5/12/2022 12:16 PM, Chris M. Thomasson wrote:
> Using my experimental vector field to generate a fractal formation. Here
> is generation two:
 
> https://fractalforums.org/gallery/1612-120522191048.png
 
Field Merger
 
Added in more dynamic points in a more complex field. For some reason to
me, they seem to resemble multiple galaxies merging. This is rendered in
real time...
 
https://youtu.be/KRkKZj9s3wk
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)