Saturday, December 31, 2022

Digest for comp.lang.c++@googlegroups.com - 14 updates in 4 topics

Juha Nieminen <nospam@thanks.invalid>: Dec 31 03:00PM

> insults and then largely died out -- until you showed up a week
> later and rekindled it.
 
> Read the room.
 
And what exactly is wrong with continuing this discussion?
 
I presented the blasphemous proposition (which is quite commonly
held) that using full English words in variable names makes code
easier to read. Apparently this blasphemy was so utterly
egregious that it elicited a dozen or so people to barrage me
in a huge flamewar, trying to make me see the error of my ways
and recant. When I refused to do so, it only strengthened their
resolve.
 
Which makes absolutely no sense.
 
There was especially one person in this thread who apparently
had taken as his life mission to oppose me no matter what,
and to convert me to the right path (and it's the same person
who started whining "you insulted me!!!" out of the blue),
but clearly I am the bad guy here, apparently because I have
committed blasphemy and heresy.
David Brown <david.brown@hesbynett.no>: Dec 31 04:20PM +0100

On 31/12/2022 16:00, Juha Nieminen wrote:
>> later and rekindled it.
 
>> Read the room.
 
> And what exactly is wrong with continuing this discussion?
 
It's going nowhere, that's what's wrong with continuing it. Too many
people got worked up and misunderstood or misread what others were
saying, and the discussion was getting too ugly. It was spoiling what
is normally a friendly and respectful group. The only good way out of
such threads is for people to appreciate it is over, and leave it all
alone. And that means /really/ leaving it alone, not digging it up and
bringing it into other threads with sarcastic comments. Pretty much
everyone had managed that, until Tim made one of his rounds of fly-by
necroposting.
 
So let's please just leave it there.
"daniel...@gmail.com" <danielaparker@gmail.com>: Dec 31 07:58AM -0800


> largely died out -- until you showed up a week
> later and rekindled it.
 
On Saturday, December 31, 2022 at 10:20:45 AM UTC-5, David Brown wrote:
 
> It's going nowhere, that's what's wrong with continuing it.
 
For those that think there's too much posting, stop posting, don't talk.
Jack Lemmon <invalid@invalid.net>: Dec 31 06:03PM

On 31/12/2022 15:00, Juha Nieminen wrote:
> And what exactly is wrong with continuing this discussion?
 
It's getting boring and we have to move forward. Rest for a while and
perhaps come back in 4 weeks time when you might have new ideas.
Michael S <already5chosen@yahoo.com>: Dec 31 02:46PM -0800

On Saturday, December 31, 2022 at 5:00:52 PM UTC+2, Juha Nieminen wrote:
> but clearly I am the bad guy here, apparently because I have
> committed blasphemy and heresy.
 
As long as you realized it, the mission is accomplished.
Michael S <already5chosen@yahoo.com>: Dec 31 02:47PM -0800

On Saturday, December 31, 2022 at 5:20:45 PM UTC+2, David Brown wrote:
> people got worked up and misunderstood or misread what others were
> saying, and the discussion was getting too ugly. It was spoiling what
> is normally a friendly and respectful group.
 
Do we read the discussion in the same group?
Juha Nieminen <nospam@thanks.invalid>: Dec 31 03:05PM


> The first one is there probably because we have many classes whose
> members are often not initialized by the constructions, but later, by
> the framework.
 
I think that using [[maybe_unused]] is better than disabling the warning
because it more explicitly indicates that it being unused is not a mistake
and the programmer was aware of it.
 
One warning, or was it actually an error, that does annoy me quite a bit
is the "narrowing conversion" thingie. I think it was introduced in C++11
or newer, and was never a problem before. To this day I'm not sure why
that warning/error is necessary.
 
(Maybe it has something to do with uniform initialization, which turned
out to be quite a mess?)
David Brown <david.brown@hesbynett.no>: Dec 31 04:40PM +0100

On 31/12/2022 16:05, Juha Nieminen wrote:
 
> I think that using [[maybe_unused]] is better than disabling the warning
> because it more explicitly indicates that it being unused is not a mistake
> and the programmer was aware of it.
 
It also has the advantage of allowing people to compile with other flags
(such as -Wextra without the -Wno- flag) without triggering the warning.
 
> that warning/error is necessary.
 
> (Maybe it has something to do with uniform initialization, which turned
> out to be quite a mess?)
 
I think warnings (or errors) about narrowing conversions are a good
idea. If I accidentally try to use a double as an integer, I'd rather
be told.
 
I find the "uniform initialisation" syntax ugly for scaler variables,
but the fact that narrowing conversions are not allowed is an advantage
here IMHO.
Paavo Helde <eesnimi@osa.pri.ee>: Dec 31 06:50PM +0200

31.12.2022 17:05 Juha Nieminen kirjutas:
 
> I think that using [[maybe_unused]] is better than disabling the warning
> because it more explicitly indicates that it being unused is not a mistake
> and the programmer was aware of it.
 
You are right in that the unused parameter warnings should be dealt
case-by-case instead of a global compiler option. I guess there was no
time or willingness to do that when the compiler suddenly started to
spit out hundreds of such warnings, and after adding the global option
there has been no motivation to do that.
 
Still, I'm not convinced [[maybe_unused]] is the best solution always.
As far as I can see, this is meant more for conditional compilation,
where a thing might be indeed sometimes used and sometimes not,
depending on preprocessor macro definitions.
 
In my code, I get this warning mainly for virtual function overrides
where some parameter is e.g. only used by 1 override of 10. And in those
9 other overrides the parameter is not maybe unused, but definitely
unused. Alas, by some reason there is no [[unused]] attribute.
 
In this scenario, I believe it might be better (i.e. more readable) to
just delete or comment out the parameter name, it will have the same
effect.
David Brown <david.brown@hesbynett.no>: Dec 31 06:47PM +0100

On 31/12/2022 17:50, Paavo Helde wrote:
 
> In this scenario, I believe it might be better (i.e. more readable) to
> just delete or comment out the parameter name, it will have the same
> effect.
 
That can often be the best choice - though of course "best" will depend
on many things.
 
Another option is a cast to void - I believe most compilers treat that
as considering the parameter "used" without generating any code. You
may feel a comment is warranted to explain what you are doing.
Frederick Virchanza Gotham <cauldwell.thomas@gmail.com>: Dec 31 07:41AM -0800

On Thursday, December 22, 2022, I wrote:
> but I can't remember having seen something
> like this in the C++ standard library nor Boost
> nor wxWidgets.
 
I've written code that will work on C++11, and which is optimised for C++17 which has guaranteed return value optimisation:
 
#ifndef HEADER_INCLUSION_GUARD_RESERVER
#define HEADER_INCLUSION_GUARD_RESERVER
 
#include <mutex> // recursive_mutex, lock_guard, unique_lock
#include <utility> // move
 
template<typename T>
class Reserver final {
 
Reserver(void) = delete;
Reserver(Reserver const &) = delete;
//Reserver(Reserver &&) = delete; - see below
Reserver &operator=(Reserver const &) = delete;
Reserver &operator=(Reserver &&) = delete;
Reserver const volatile *operator&(void) const volatile = delete;
 
T &obj;
 
#ifdef __cpp_guaranteed_copy_elision
std::lock_guard<std::recursive_mutex> m_lock;
Reserver(Reserver &&arg) = delete;
#else
std::unique_lock<std::recursive_mutex> m_lock;
public:
Reserver(Reserver &&arg)
: m_lock( std::move(arg.m_lock) ),
obj(arg.obj) {}
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)