Tuesday, December 15, 2020

Digest for comp.lang.c++@googlegroups.com - 20 updates in 5 topics

Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Dec 15 02:38PM

On Mon, 14 Dec 2020 21:53:34 -0800
> On 12/14/2020 5:00 PM, Chris Vine wrote:
[snip]
 
> Yeah. your right. I have seen a lot of broken code through the years
> that has this race condition, to the point where I thought it was a
> common mistake. Would cringe every time I would see a thread base class.
 
Hopefully this particular wrongness is becoming a thing of the past.
In the days of the mad OOP craze you had virtual functions everywhere,
including in thread base classes. A common idiom was to have a base
thread class with a pure virtual function called "start" or some
similar name, which you would override by inheritance with the concrete
implementation of the code to be executed by the thread in question.
Nowadays you just pass in a lambda function or std::function object
containing the implementation to your thread class, which obviates all
that: std::thread is not intended to be derived from.
Bonita Montero <Bonita.Montero@gmail.com>: Dec 15 04:07PM +0100

> This thread is about calling member functions of an object from another
> thread while the destructor of the object has already started in the
> first thread.
 
shared_ptr wouldn't help here because I've got a thread which is running
until a destructor waits for its termination and this thread might call
a virtual function before the thread waits for its end.
 
> One can use other ways of synchronization, but that would be more
> complicated and more error-prone (as demonstrated by the first post
> in this thread - it had synchronization, but in the wrong place).
 
shared_ptr<> is about holding multiple references to the same object
from different threads. Having multiple copies of the shared_ptr<>
in one thread is not what it is thought for because copying a shared
_ptr<> is slow. Within a thread you simply extract normal pointers
of a shared_ptr<>-object which live shorter than the shared_ptr<>
object itself.
Paavo Helde <myfirstname@osa.pri.ee>: Dec 15 05:18PM +0200

15.12.2020 17:07 Bonita Montero kirjutas:
 
> shared_ptr wouldn't help here because I've got a thread which is running
> until a destructor waits for its termination and this thread might call
> a virtual function before the thread waits for its end.
 
shared_ptr would help, because if you accessed the object via a
shared_ptr in both threads, the destructor would not be started while
there is a shared_ptr to the object alive, in any thread.
 
This would have forced you to rethink the design and place the
synchronization elsewhere, not in the base class destructor. Problem
avoided.
Bonita Montero <Bonita.Montero@gmail.com>: Dec 15 04:21PM +0100

> shared_ptr would help, because if you accessed the object via a
> shared_ptr in both threads, the destructor would not be started
> while there is a shared_ptr to the object alive, in any thread.
 
If the thread would be the last to have a shared_ptr<> it would call
the destructor which would wait for the termination of the thread.
So this wouldn't work.
scott@slp53.sl.home (Scott Lurndal): Dec 15 05:03PM

>> bug.
 
>Joinining in destructor was always no no if Java model is used.
>Not once I saw pworblems with this in RL.
 
bool in_context(void) const { return t_thread == pthread_self(); }
 
c_thread::~c_thread(void)
{
lock();
terminate();
unlock();
}
 
/**
* Terminate the thread. If called in-context, it will clear the
* running flag and exit. If called out of context, it will cancel
* the thread and join with it.
*/
void
c_thread::terminate(void)
{
if (in_context()) {
t_running = false;
pthread_exit(NULL);
} else {
int diag = pthread_cancel(t_thread);
if (diag == ESRCH) {
/* Thread already gone, nothing to do */
} else if (diag != 0) {
t_logger->log("%s Unable to cancel thread: %s\n",
t_thread_name, strerror(diag));
}
 
void *rval;
diag = pthread_join(t_thread, &rval);
if (diag == ESRCH) {
/* Thread already gone, nothing to do */
} else if (diag != 0) {
t_logger->log("%s Thread join failed: %s\n",
t_thread_name, strerror(diag));
}
t_running = false;
}
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 15 01:48PM -0800

On 12/15/2020 2:23 AM, Bonita Montero wrote:
 
> Yes, but only if the mutex is locked.
> Sorry, but you seem to be too stupid to read < 250 lines of
> trivial code.
____________________
void thread_pool::theThread()
{
using namespace std;
using namespace chrono;
using hrc_tp = time_point<high_resolution_clock>;
auto byeBye = [this]()
{
// one less thread
--m_nThreads;
___________________
 
Where is the the mutex locked here? What did I miss?
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 15 01:50PM -0800

On 12/15/2020 2:23 AM, Bonita Montero wrote:
 
> Yes, but only if the mutex is locked.
> Sorry, but you seem to be too stupid to read < 250 lines of
> trivial code.
 
I only had time to briefly skim it.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 15 02:05PM -0800

On 12/15/2020 1:48 PM, Chris M. Thomasson wrote:
>          --m_nThreads;
> ___________________
 
> Where is the the mutex locked here? What did I miss?
 
Ahhh. I see, you are calling byeBye() under the protection of the lock
further down. Its was a little confusing. Sorry.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 15 02:12PM -0800

On 12/15/2020 2:22 AM, Bonita Montero wrote:
>>> as much threads as there are hw-threads in my computer (16).
 
>> Well, that's not good enough. Sorry.
 
> That's good enough because the synchronization-parts are trivial.
 
I have heard the same argument for ages.
Mr Flibble <flibble@i42.REMOVETHISBIT.co.uk>: Dec 15 07:03PM

On 14/12/2020 18:41, olcott wrote:
 
> I finally renamed my internal DebugTrace() to Halts() now that it finally does return its correct halting decision to main().
 
Renaming your function to "Halt" does NOT make it a halt decider; it makes it an erroneously named function. Until your function can decide if a loop or recursion CONTAINING CONDITIONALS (i.e. branching logic) never terminates you DO NOT have a halt decider, you HAVE NOT refuted Turing and you HAVE NOT "solved" the Halting Problem.
 
/Flibble
 
--
😎
"Öö Tiib" <ootiib@hot.ee>: Dec 15 05:36AM -0800

On Tuesday, 15 December 2020 at 03:05:39 UTC+2, Melzzzzz wrote:
> programming. Speaking of safety Rust vs C++ is it better not to have
> pointer arithmetic and do that by converting pointer to int and back and
> C++ model in which you just add value to pointer?
 
The unsafe operations are useful only in limited occasions and
in limited meanings even in low level embedded code.
So it is anyway good idea to make unsafe things like pointer
arithmetic or type punning to be ugly and inconvenient to express.
Totally different question is if need of type punning a pointer into
integral value and back is best uglifier factor but it works.
Bad code that does naked casts and pointer arithmetic all
over the place will look like garbage it is and so mission
accomplished.
spuddy@isnotyourbuddy.co.uk: Dec 15 02:11PM

On Tue, 15 Dec 2020 05:36:40 -0800 (PST)
>> C++ model in which you just add value to pointer?=20
 
>The unsafe operations are useful only in limited occasions and
>in limited meanings even in low level embedded code.
 
But when needed they're REALLY needed.
 
>So it is anyway good idea to make unsafe things like pointer
>arithmetic or type punning to be ugly and inconvenient to express.
 
How is pointer arithmetic inconvenient to express? It couldn't be any simpler.
 
>Totally different question is if need of type punning a pointer into
>integral value and back is best uglifier factor but it works.=20
 
Oh yeah, that would really make the code clearer.
 
>Bad code that does naked casts and pointer arithmetic all
>over the place will look like garbage it is and so mission
>accomplished.=20
 
I've found that people who have a problem with pointer arithmetic don't
really understand it. Or pointers.
"Öö Tiib" <ootiib@hot.ee>: Dec 15 07:29AM -0800


> >The unsafe operations are useful only in limited occasions and
> >in limited meanings even in low level embedded code.
> But when needed they're REALLY needed.
 
So these are in Rust.
 
> >So it is anyway good idea to make unsafe things like pointer
> >arithmetic or type punning to be ugly and inconvenient to express.
> How is pointer arithmetic inconvenient to express? It couldn't be any simpler.
 
My point was that it is bad when rarely needed unsafe operations are
difficult to notice.
 
> >Totally different question is if need of type punning a pointer into
> >integral value and back is best uglifier factor but it works.=20
 
> Oh yeah, that would really make the code clearer.
 
Yes, the unsafe stuff stands out so it is more clear that it is unsafe.
 
> >accomplished.=20
 
> I've found that people who have a problem with pointer arithmetic don't
> really understand it. Or pointers.
 
That is unfortunately so with every rarely needed feature. People
can program years in C++ without doing any pointer arithmetic
ever and so quite many can make errors in it. It saves my time when
I find problematic places quicker.
spuddy@isnotyourbuddy.co.uk: Dec 15 04:25PM

On Tue, 15 Dec 2020 07:29:49 -0800 (PST)
>> >integral value and back is best uglifier factor but it works.=20
 
>> Oh yeah, that would really make the code clearer.
 
>Yes, the unsafe stuff stands out so it is more clear that it is unsafe.
 
Illogical reasoning. Any experience developer knows to be careful with
pointers, they don't need it signposted.
 
>can program years in C++ without doing any pointer arithmetic
>ever and so quite many can make errors in it. It saves my time when
>I find problematic places quicker.
 
Sure, you can program in C++ without ever using pointers if you only ever
program baby code. But if you ever do for example any network packet processing
or are writing a parser, using shared memory or to-the-metal you'll soon get
sick of trying to do it all with std::string/array or some other higher level
abstraction not to mention how slow they'd be. If you only want to use high
level constructs perhaps you'd be better off with Java or Python.
"Öö Tiib" <ootiib@hot.ee>: Dec 15 10:52AM -0800


> >Yes, the unsafe stuff stands out so it is more clear that it is unsafe.
> Illogical reasoning. Any experience developer knows to be careful with
> pointers, they don't need it signposted.
 
I do not really care how well they know their own code. For me it is important
that they can be used to work with code of other people.
 
> >I find problematic places quicker.
> Sure, you can program in C++ without ever using pointers if you only ever
> program baby code.
 
That is for what is paid. It is tricky to find those rare customers who
let you waste $25K and whole month for writing a parser or video
codec or compression algorithm. Use best existing one. But interface
of such does not involve pointer arithmetic.
 
> sick of trying to do it all with std::string/array or some other higher level
> abstraction not to mention how slow they'd be. If you only want to use high
> level constructs perhaps you'd be better off with Java or Python.
 
Yes I'm quite bad with Python. In my company we have a little
homework assignment ... about processing text file. We sometimes
hire people whose C++ performs even weaker than my Python script
but we avoid those whose garbage works incorrectly.
Brian Wood <woodbrian77@gmail.com>: Dec 15 07:25AM -0800

On Tuesday, December 15, 2020 at 4:49:08 AM UTC-6, David Brown wrote:
> why would you think that increasing it would help? If you have been at
> this for 10 years, and have /no/ users, then it is surely time to change
> tactics.
 
Noah and his family spent decades working on the ark
before there was a drop of rain.
 
> For example, you could stop telling people your software is so
> useless that you will pay people to use it, and instead start charging
> for it. People will then see it might be worth something.
 
That might have made sense in the past, but due to
the Chinese government, those that haven't died
from the virus are often having a hard time financially.
My efforts are open to intelligent, hard-working
people, who through no fault of their own, happen to
be poor.
 
I hope we can get over the doubts and start to believe
that the time has come for on-line code generation.
The kicking and screaming gets old. You do a good
job though of pretending to be objective.
 
We now return you to your regularly scheduled programming...
 
template<class R>explicit
FixedVector (ReceiveBuffer<R>& buf):size_(give<::uint32_t>(buf))
,arr(new T[size_]){
for(int n=0;n<size_;++n){
if constexpr(::std::is_arithmetic_v<T>){
arr[n]=give<T>(buf);
}else{
new(arr+n)T(buf);
}
}
}
 
That's from this file:
https://github.com/Ebenezer-group/onwards/blob/master/src/cmw_Buffer.h
 
I posted this on Reddit and someone mentioned that
the placement new happens after the objects have been
default constructed. I knew that but wasn't sure what to
do about it. I asked if I should add a call to the destructor
prior to the placement new, but no one has replied yet.
 
https://www.reddit.com/r/cpp_questions/comments/kcfxsm/limited_vector_class/
 
There are more interesting questions buried in this and
other threads that I'd be happy to revisit if you happen to
come upon them and have a suggestion.
 
 
Brian
Ebenezer Enterprises - Enjoying programming again.
https://webEbenezer.net
David Brown <david.brown@hesbynett.no>: Dec 15 05:07PM +0100

On 15/12/2020 16:25, Brian Wood wrote:
>> tactics.
 
> Noah and his family spent decades working on the ark
> before there was a drop of rain.
 
You are not Noah, you are not building an ark, and you are not working
on mystical orders from a god. You are making a software system that
has no users, and no sign of any users in the future - at least partly
because you are personally ensuring that no one will want to use it.
 
Take a look at yourself in the mirror, and throw out the narcissism and
megalomania, and the martyr complex. Get a bit of realism in your life.
You are just a programmer - no more, no less. Make something that
people will find useful - or find out what people want, and make that.
Don't keep telling people you are the reincarnation of Noah and expect
them to come to your door.
 
 
> That might have made sense in the past, but due to
> the Chinese government, those that haven't died
> from the virus are often having a hard time financially.
 
Take your wild conspiracy theories and fanatic politics elsewhere. You
are not doing yourself any favours.
 
Yes, much of the world is having more challenges economically after this
past year. That has not stopped people and companies investing in
things that make economic sense. If your software is good, and will
save users money (since they don't have to develop similar functionality
themselves), then you can sell it.
 
> My efforts are open to intelligent, hard-working
> people, who through no fault of their own, happen to
> be poor.
 
Proper open source is fine - but it's not easy to make a business from
it if the code is all you have. Free software with paid support and
consultancy is one way to make it work.
 
But you are saying the software is free (but not open), while the
consultancy and support is so bad that you do it for free, and the
software is so difficult to use that you will spend weeks of effort so
that people will be able to use the zero-cost software. Do you really
not understand how that looks?
 
 
> I hope we can get over the doubts and start to believe
> that the time has come for on-line code generation.
 
Belief is not sufficient. No one has seen /any/ reason to suggest that
on-line code generation is a good idea, or that its "time" has come.
You have told us repeatedly, year after year, how wonderful this concept
is, how much it is the greatest revolution since sliced bread, and how
you are ready to take over the world with it. Yet as far as I can
remember, you have not once given a /single/ reason. Not the slightest
hint of a potential benefit. /Nothing/.
 
> The kicking and screaming gets old.
 
Exactly. Stop kicking and screaming. If you have some justification
for why anyone should want to use your software, or want to use on-line
code generation, then you could start with that.
 
> You do a good
> job though of pretending to be objective.
 
> We now return you to your regularly scheduled programming...
 
If you want to discuss something technical about some code, remove the
advertising for your software and then post it in a new thread. Make a
compilable code snippet, learn to use the space key so that it is
legible, and maybe someone here will be willing and able to help. But
as long as people think it is just advertising for your business, or
that you are going to wander off into religious or political fanaticism
again, you will have trouble finding willing help.
scott@slp53.sl.home (Scott Lurndal): Dec 15 05:06PM


>The software is more mature and versatile than a year ago.
>SaaS is doing well. As far as I can tell I'm sitting on a
>gold mine.
 
Sure.
 
 
>"In G-d we trust" has been the national motto of the US
>for many years. That trust extends to how you build
>and run a business.
 
Actually, for less than 70 years. It was added to counter the
"godless communists" during the height of the cold war by
religious nutcakes.

 
>I don't know if you're prying, but am thinking about
>Samson and Delilah.
 
A fairy tale from a collection of fireside stories.
"Öö Tiib" <ootiib@hot.ee>: Dec 15 09:32AM -0800

> > tactics.
> Noah and his family spent decades working on the ark
> before there was a drop of rain.
 
Did God tell you that you should build serialization library to
save the world?

> That might have made sense in the past, but due to
> the Chinese government, those that haven't died
> from the virus are often having a hard time financially.
 
The first corona-virus outbreak was 2002-2004. There was
plenty of time to study and find some cure or vaccine to
those viruses. No one did bother and now it is fault of
evil Chinese government?
 
> My efforts are open to intelligent, hard-working
> people, who through no fault of their own, happen to
> be poor.
 
But why they should not use other things like Protocol
Buffers, Apache Avro, Cereal or FlatBuffers?
These have good documentation, lot of examples, plenty
of tools, free to use and enough people online who can help
even if they are poor.

> that the time has come for on-line code generation.
> The kicking and screaming gets old. You do a good
> job though of pretending to be objective.
 
Why that online is good and offline is bad or that
there is some kind of controversy whatsoever?
Random flatbuffer site : <https://flatbuffers.ar.je/>
Choose C++ from drop-down and press [Generate]
Making such a thing is a week of work.
 
You should stop implying that you are God-directed
prophet of Online who saves world from evil Offline
Chinese. Even intelligent and hard working people
have had fair share of bullshit before in their lives.
Melzzzzz <Melzzzzz@zzzzz.com>: Dec 15 12:38PM

"
This foundational base toolkit enables the building, testing, and optimizing of data-centric applications across XPUs.
 
Intel® oneAPI Base Toolkit
 
Toolkits include the new DPC++ programming language, as well as familiar C, C++, and Fortran languages.
Domain-specific toolkits support specialized workloads.
 
Intel® oneAPI HPC Toolkit
Intel® oneAPI IoT Toolkit
Intel® oneAPI Rendering Toolkit
"
 
https://software.intel.com/content/www/us/en/develop/tools/oneapi/all-toolkits.html?cid=em&source=elo&campid=iags_WW_iagsdn_EMNL_EN_2020_CPDP%20Dec%202020%20Newsletter_C-MKA-16355_T-MKA-22042&content=iags_WW_iagsdn_EMNL_EN_2020_CPDP%20Dec%202020%20Newsletter_C-MKA-16355_T-MKA-22042&elq_cid=3714673&em_id=64842&elqrid=4a295da917d9489eaa4fb67c00e8ebb0&elqcampid=41857&erpm_id=6961740
 
Perhaps some would find this usefull.
--
current job title: senior software engineer
skills: c++,c,rust,go,nim,haskell...
 
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi
bili naoruzani. -- Mladen Gogala
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)