Saturday, June 19, 2021

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

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jun 19 04:44PM -0700

On 6/19/2021 6:38 AM, Sam wrote:
>> What can be better?
 
> Your own. Roll your own. That's what I did, and I mostly described what
> I did here: https://www.libcxx.org/refobj.html
 
Iirc, I have some really old code on an external hd around here
somewhere that split apart access into two areas. It had a global_ptr
and a local_ptr. local_ptr had no atomic's, no membars, ect. It was
meant to be used locally. The global_ptr was strongly thread-safe and
lock-free. So, a thread could do something like:
 
static global_ptr<foo> g_foo = new foo();
 
void threads()
{
local_ptr<foo> l_foo = g_foo;
if (! l_foo) return;
 
l_foo->foobar();
 
local_ptr<foo> l2_foo = l_foo;
 
l_foo = nullptr;
 
l2_foo->barbaz();
 
func(l2_foo);
}
 
void rouge_threads()
{
local_ptr<foo> l_foo = g_foo.exchange(new foo());
if (! l_foo) return;
l_foo->bingo();
}
 
 
All of the accesses to l_foo and l2_foo did not use any atomics,
membars, ect. Afaict, back in the day, one of the best smart pointers
out there was atomic_ptr developed by Joe Seigh:
 
http://atomic-ptr-plus.sourceforge.net
 
He posted full code for atomic_ptr somewhere over on
comp.programming.threads. I have implemented it multiple times for fun.
Works like a charm. However, it required DWCAS.
Sam <sam@email-scan.com>: Jun 13 01:37PM -0400

Bonita Montero writes:
 
>> All the voices in your head does not translate to "a lot of developers".
>> It's still only you.
 
> There are no good reasons to do it in a different way.
 
Just because you can't think of any doesn't mean there isn't.
Sam <sam@email-scan.com>: Jun 13 01:38PM -0400

Bonita Montero writes:
 
>> and nothing else.
 
> No, we're talking about replacing malloc() and thereby changing
> how C++-implementations allocate at last.
 
Noone is replacing malloc. It's still there. It's the operator new/delete
that gets replaced with code that uses an alternative allocator that offer
container-specific optimizations.
Sam <sam@email-scan.com>: Jun 14 07:00AM -0400

Bonita Montero writes:
 
>>> how C++-implementations allocate at last.
 
>> Noone is replacing malloc. ...
 
> There are a lot of people which change the implementation.
 
Speaking of "phantasies"…
 
 
> No, it's actually sufficient to replace malloc(). A lot of benchmarks
> wich malloc()-replacement like mimalloc show that this works with
> arbitrary C++-code.
 
Until it doesn't.
Bonita Montero <Bonita.Montero@gmail.com>: Jun 14 01:08PM +0200

>> wich malloc()-replacement like mimalloc show that this works with
>> arbitrary C++-code.
 
> Until it doesn't.
 
It has always worked because people expected that and because
of that standard libraries are designed in that way.
Manfred <noname@add.invalid>: Jun 15 08:30PM +0200

On 6/15/2021 7:49 AM, Öö Tiib wrote:
> me. No u8 literals, "launder" or "if constexpr" in it. So now it is
> perhaps best idea to not even read standard but take it narrower
> and read what Stroustrup thinks C++ is.
 
Wholeheartedly agree.
BTW stressing the point on "std::launder" that IMO is a sick solution
for a sick problem created by the committee - a problem that was simply
non-existing in Stroustrup's C++.
 
And he knows very well about the problem too, that C++ has become overly
complicated as you say:
 
"...C++17 did little to make our foundation more solid, regular, and
complete. Instead, it added significant surface complexity and increased
the number of features people need to learn. C++ could crumble under the
weight of these – mostly not quite fully-baked – proposals."
...
"We are on the path to something that could destroy C++. We must get off
that path!"
 
https://www.stroustrup.com/P0977-remember-the-vasa.pdf
Juha Nieminen <nospam@thanks.invalid>: Jun 16 04:33AM

> me. No u8 literals, "launder" or "if constexpr" in it. So now it is
> perhaps best idea to not even read standard but take it narrower
> and read what Stroustrup thinks C++ is.
 
I think you are painting too negative of a picture about the standardization
process and new versions of the language.
 
C++98 is complicated and rather quickly people discovered side-effects
that could be used for interesting applications, but which were never
originally designed for it.
 
SFINAE would be the quintessential example. That small specification of the
language, which was merely intended to make templates less likely to cause
conflicts with each other, turned out to serendipitously allow for a limited
form of compile-time introspection.
 
But this... kludge, if you will, is quite complicated to understand, because
the language was never designed with that in mind. Ask the average
experienced C++ programmer to explain SFINAE, and he'll have no idea.
 
Heck, ask the average experienced C++ programmer what std::enable_if is,
and how it's used, and he'll have no idea. You might know it perfectly well,
but let me assure you, the average C++ programmer doesn't. Not even the
experienced one. And even if someone has some vague grasp of how it's used,
ask him how and why it works, and chances are that he doesn't have a clue.
It essentially works by magic.
 
Likewise entire books were written about C++98 template metaprogramming.
Something that was never originally designed for the language, but which
arose serendipitously as a side-effect of how templates work. Yet, the
average experienced C++ programmer, even to this day, has very limited
knowledge and understanding of template metaprogramming. As, indeed, the
"feature" is complicated and difficult to use, and results in very
complicated-looking code.
 
Thus, things like 'constexpr', 'consteval' and 'requires' were introduced
to make all these much simpler and versatile. (For example C++98 template
metaprogramming was extremely limited in what you could do, as it was
limited to, essentially, basic integer arithmetic.)
 
People love to complain about how such new features "make the language
too complicated". They fail to see *why* these features were added:
To actually make *using* the language simpler. To replace the ugly
complicated hacks that were in common use in C++98 that were not only
complicated to use, but also resulted in complicated source code that's
hard to read and understand.
 
People also love to complain that new features require programmers to have
to learn more. Yet, the average C++ programmer doesn't even fully understand
the entirety of C++98 either (see SFINAE, for example), yet they don't have
much of a problem in writing C++ programs. It's not about knowing the
entirety of the language. It's about having the tools to do what you need
when you need them.
Bonita Montero <Bonita.Montero@gmail.com>: Jun 16 07:09AM +0200

> Mixing C and C++ code is completely irrelevant. C++ containers can use
> a custom allocator/deallocator in the same program that also includes
> C code, too, ...
 
They don't.
David Brown <david.brown@hesbynett.no>: Jun 16 10:35AM +0200

On 16/06/2021 06:33, Juha Nieminen wrote:
 
<snip for brevity>
 
> much of a problem in writing C++ programs. It's not about knowing the
> entirety of the language. It's about having the tools to do what you need
> when you need them.
 
I agree with a lot of what you wrote here.
 
C++ has been changing significantly. Many of the new features make the
language simpler to use, to do the things people previously did in
complex ways. A fine example is the "safe boolean idiom". It used to
be ridiculously complicated with conversions via pointer types and the
rest of the package. Now you just write "explicit operator bool" -
simple, clear, safe and easy. You used to write complicated enable_if
and SFINAE stuff - now you use "if constexpr" and concepts. You used to
use templates as their own ugly, slow and limited compile-time
programming language - now you use constexpr, and soon constinit and
consteval. These are things people use in real code. Not everyone uses
them, but some people do.
 
There is also plenty of stuff in newer C++ that is hard for people to
comprehend - there is too much, and some of it is too weird. But much
of it is not for the normal application programmer - it is for the
library programmer. Most people want to just /use/ std::vector,
std::optional and the rest of it - it's usually only the people who
/implement/ these that need the ugly details of perfect forwarding and
whatever else is new.
 
I currently use C++17 (with gcc extensions). This is embedded
programming - I don't use much of the standard library, but I do use
std::optional. I use "if constexpr" and inline variables. From C++14 I
use return type deduction, more general constexpr functions, binary
literals with digit separators. From C++11 - well, basically I didn't
consider C++ to give me much beyond C until C++11 was a realistic choice.
 
When C++20 is ready I will be using concepts, constinit and consteval
(the more that is done at compile time, the better). I'll use modules
when I can.
 
As soon as contracts, reflection and metaclasses make it to the
language, I'll be using them too.
 
And there is /lots/ that I will have no use for - but other people will.
(This is a concept many seem to find difficult.)
MrSpook_b1My5@751smt.edu: Jun 16 08:44AM

On Tue, 15 Jun 2021 13:09:23 -0700
>> for(<type> <var>: <container>)
>> C++ threads (for simple threading)
 
>I would also add C++ atomics and memory barriers.
 
The problem with C++ atomics is that they're not always atomic. Eg when
using +=, -= type operators, which makes them a bit pointless IMO. Better to
just use a lock and be 100% sure.
David Brown <david.brown@hesbynett.no>: Jun 16 11:18AM +0200


> That however is the problem. The language is so big now its not realistic to
> expect a developer to know all of it never mind know all of it well enough to
> use.
 
Most modern languages, along with their standard libraries, are too big
for a developer to know it all. People regularly refer to Python as a
language that is easy to learn and use - how many Python users
understand metaclasses, __slots__, generators, decorators? I would not
expect it to be even 1% of people who program in Python regularly. Yet
they are very useful features to have in the language for those that
need them, and very useful for people to use indirectly via libraries.
Similarly, no one has the full Python standard library in their heads.
 
How many POSIX programmers can say they know all of POSIX? How many
Windows programmers know all of the Windows API?
 
 
Being a big language (or standard library) is only a problem if the
amount you need to understand to work reasonably effectively is intractable.
 
> they may well dismiss a very good developer because he didn't know some obscure
> features of the language he could pick up in a few hours of learning anyway.
 
> And yes, it has happened to me.
 
That is a problem with interviewers, not the language. There have been
bad interviewers and bad hiring processes from long before C++ existed,
and there always will be.
MrSpook_3_fdyox@sg5nvjmv741xbigdp6.info: Jun 16 09:04AM

On Wed, 16 Jun 2021 10:35:42 +0200
>And there is /lots/ that I will have no use for - but other people will.
> (This is a concept many seem to find difficult.)
 
That however is the problem. The language is so big now its not realistic to
expect a developer to know all of it never mind know all of it well enough to
use. Yet company A will use a certain subset of C++, company B will use
another, company C yet another and so on, and in their interview process will
expect candidates knowledge to intersect with their use case. If it doesn't
they may well dismiss a very good developer because he didn't know some obscure
features of the language he could pick up in a few hours of learning anyway.
 
And yes, it has happened to me.
Juha Nieminen <nospam@thanks.invalid>: Jun 16 09:20AM


> That however is the problem. The language is so big now its not realistic to
> expect a developer to know all of it never mind know all of it well enough to
> use.
 
As I commented in my post, C++ has *always* been so big, ever since C++98,
that almost no C++ programmer fully knows the ins and outs of it.
 
The thing is, you don't need to know all of it. I have been programming in
C++ like 25 years, about 15 of them professionally, and to this day things like
SFINAE are mostly a mystery to me. Only recently did I learn some basic usage
of std::enable_if (which, while it was added to the standard library in C++11,
it's fully compatible with C++98 and you can use it if you implement it there).
But that's fine. It has never really been a problem.
 
The main thing that's beneficial to a C++ programmer is knowing what different
tools exist in the language, even if he has no knowledge about how to use them.
When you encounter a situation which sounds like the tool could be useful for,
you can then find out how to use it.
 
> they may well dismiss a very good developer because he didn't know some obscure
> features of the language he could pick up in a few hours of learning anyway.
 
> And yes, it has happened to me.
 
I wouldn't be surprised if the same is the case with almost any programming
language being used in the industry, such as Java, C# and Python. They probably
have their obscure corner cases that only a fraction of programmers know and
use fluently.
MrSpook_u_kch7_3@abbbp5z5c0iw8rwgxg4.gov: Jun 16 09:34AM

On Wed, 16 Jun 2021 11:18:21 +0200
>> use.
 
>Most modern languages, along with their standard libraries, are too big
>for a developer to know it all. People regularly refer to Python as a
 
I'd suggest its fairly easy to know C (minus libraries) in its entirety.
 
>language that is easy to learn and use - how many Python users
>understand metaclasses, __slots__, generators, decorators? I would not
 
I'd be surprised if an experienced python programmer didn't know about
generators (fancy name for co-routines) or decorators.
 
 
>That is a problem with interviewers, not the language. There have been
>bad interviewers and bad hiring processes from long before C++ existed,
>and there always will be.
 
The size of C++ makes it ever easier. And its not just interviewers - a lot
of companies use online tests which always seem to include questions on the
latest and greaters features of the language. (Plus the obligatory multiple
inheritence questions even though almost no one uses it).
Tim Woodall <news001@woodall.me.uk>: Jun 16 09:49AM

> when I can.
 
> As soon as contracts, reflection and metaclasses make it to the
> language, I'll be using them too.
 
Great points and pretty close to my usage. I've never tried to implement
the standard library and I'd not something I can imagine trying even in
retirement although I accept it is probably a great way to really get to
know the more esoteric bits of C++.
 
> And there is /lots/ that I will have no use for - but other people will.
> (This is a concept many seem to find difficult.)
 
But here, I think, is where people's problems are, when you're on a huge
code base with many developers, people use their own "pet feature" and
you end up needing to understand far, far more than you would wish (or
worse, end up guessing what code really does when you need to modify it
and get it working by "coincidence" rather than by "understanding")
 
I suffer this problem with python in particular, I use quite a lot of
python as glue logic but I don't pretend to be a python developer. And
the number of times someone "improves" something that I am then left
having to google to understand exactly what is happening. I've been
forced to learn a lot of python, but not because it's useful to me or I
will ever need it, but merely because someone else wanted to use a
feature rather than something that looks like what a C++ developer would
write.
David Brown <david.brown@hesbynett.no>: Jun 16 11:53AM +0200


>> Most modern languages, along with their standard libraries, are too big
>> for a developer to know it all. People regularly refer to Python as a
 
> I'd suggest its fairly easy to know C (minus libraries) in its entirety.
 
Sure (though there are subtle points that often elude people). But C is
not a modern language. I am not suggesting that there are no simple
languages, merely that C++ is far from being unique amongst large
languages - and that people use similarly large languages all the time.
 
>> understand metaclasses, __slots__, generators, decorators? I would not
 
> I'd be surprised if an experienced python programmer didn't know about
> generators (fancy name for co-routines) or decorators.
 
People use generators, iterators and decorators - they rarely define
their own.
 
> of companies use online tests which always seem to include questions on the
> latest and greaters features of the language. (Plus the obligatory multiple
> inheritence questions even though almost no one uses it).
 
Again, it is not the language that is the problem.
Paavo Helde <myfirstname@osa.pri.ee>: Jun 16 01:11PM +0300


> The problem with C++ atomics is that they're not always atomic. Eg when
> using +=, -= type operators, which makes them a bit pointless IMO. Better to
> just use a lock and be 100% sure.
 
What makes you think so? These operations are guaranteed to be atomic:
 
https://en.cppreference.com/w/cpp/atomic/atomic/operator_arith2
MrSpook_p6g@ktmy0vg8lj7jxt.biz: Jun 16 10:21AM

On Wed, 16 Jun 2021 13:11:04 +0300
>> using +=, -= type operators, which makes them a bit pointless IMO. Better to
>> just use a lock and be 100% sure.
 
>What makes you think so? These operations are guaranteed to be atomic:
 
Well I've tried to use them in multithreaded code and I can assure you, at
least on whatever version of gcc I was using at the time, they were not.
MrSpook_ge@ldwlviy1f9uwd19thc.gov: Jun 16 10:19AM

On Wed, 16 Jun 2021 11:53:44 +0200
>> latest and greaters features of the language. (Plus the obligatory multiple
>> inheritence questions even though almost no one uses it).
 
>Again, it is not the language that is the problem.
 
But it is - there's an awful lot of cruft thats been added to C++ that is
of dubious use yet at some point you have to know about it. Its been a long
long time since I looked at a problem and thought "I don't know how to solve
that easily in C++". A lot of the compile time rubbish added recently seems
like someones undergraduate compiler project rather than anything of use.
 
Eg people here seem to like constexpr. Why? What problem does it solve? If you
need to calculate a value just bloody calculate it yourself and hardcode it,
you don't need the compiler to do it for you at compile time.
MrSpook_G1Sw6pdcqz@5a69.edu: Jun 16 11:25AM

On Wed, 16 Jun 2021 13:14:31 +0200
>which language doesn't? Hands up those C experts who know what the
>"static" in "void bar(int a[static 10]);" is doing?), people will find
 
Hand up. What does it do? Or is it simply the same as static int because
the compiler doesn't care about certain syntax order, the same way that a[0]
and 0[a] are equivalent?
Paavo Helde <myfirstname@osa.pri.ee>: Jun 16 02:37PM +0300

16.06.2021 08:09 Bonita Montero kirjutas:
>> a custom allocator/deallocator in the same program that also includes
>> C code, too, ...
 
> They don't.
 
They do. We have a large C++ library which uses strings and STL
containers with a custom allocator built on top of the Intel TBB
allocator. OTOH, all third-party C or C++ libraries and any host
executables where our library might be loaded into still use whatever
they want, typically standard malloc().
 
It would even be conceptually impossible for our dynamically loaded
library to change the process malloc(), it would be far too late for that.
Sam <sam@email-scan.com>: Jun 16 06:37AM -0400

Bonita Montero writes:
 
>> a custom allocator/deallocator in the same program that also includes
>> C code, too, ...
 
> They don't.
 
Of course they do, it happens all the time.
David Brown <david.brown@hesbynett.no>: Jun 15 09:38AM +0200

On 15/06/2021 02:51, Nikolaj Lazic wrote:
 
>> Does.
 
>> Remember you can close and reopen namespaces unlike classes.
 
> That was the exact thing OP did and now asks for the way to avoid it.
 
That was indeed one of the ways I know it can be done. I was hoping
there was a syntax that avoided that, which I had overlooked - basically
because I think it would have been neater in my code if something like
"void ::g() {}" had been allowed by the language. It looks like there
is no such syntax that I am missing. That's what I had expected, but it
was worth a try.
 
Thanks to all in the thread for their suggestions.
Keith Thompson <Keith.S.Thompson+u@gmail.com>: Jun 12 09:47PM -0700

>> https://www.amazon.com/C-Concurrency-Action-Anthony-Williams/dp/1617294691/
 
> I have the 1st version of that book, it's a very good one on the
> subject. AFAIK it is "the" book about C++ multi-threaded programming.
 
Amazon doesn't have it in Kindle format, but the second edition (2019)
is available from the print, ebook, and audio formats.
 
I haven't read it, so I can't comment on how good it is.
 
https://www.manning.com/books/c-plus-plus-concurrency-in-action-second-edition
 
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
Keith Thompson <Keith.S.Thompson+u@gmail.com>: Jun 12 09:49PM -0700

>> subject. AFAIK it is "the" book about C++ multi-threaded programming.
 
> Amazon doesn't have it in Kindle format, but the second edition (2019)
> is available from the print, ebook, and audio formats.
 
I meant "available from the publisher".
 
 
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
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)