Monday, February 10, 2020

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

Juha Nieminen <nospam@thanks.invalid>: Feb 10 12:11PM

> I posted everything to understand the issue.
> The code is sufficient and the description of the question as well.
> And I see you didn't understand it.
 
The onus on the understandability of text is on the writer, not the reader.
Bonita Montero <Bonita.Montero@gmail.com>: Feb 10 03:23PM +0100

>> The code is sufficient and the description of the question as well.
>> And I see you didn't understand it.
 
> The onus on the understandability of text is on the writer, not the reader.
 
The people on Stack Overflow understood it.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 10 02:04PM -0800

On 2/10/2020 6:23 AM, Bonita Montero wrote:
 
>> The onus on the understandability of text is on the writer, not the
>> reader.
 
> The people on Stack Overflow understood it.
 
// pseudo code, sorry for any typos:
 
 
void foo(shared_ptr<bar> ptr)
{
shared_ptr<bar> tptr = ptr;
 
// create thread using tptr
}
 
 
// call foo with a temporary
foo(shared_ptr<bar>(new bar()));
 
 
iirc, works fine. the tptr in the function foo has a reference,
therefore the refcount is bumped accordingly. You can create a thread
using tptr.
 
I don't really use std::shared_ptr all that much, preferring "intrusive"
counts that embed the refcount within the object itself.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 10 03:15PM -0800

On 2/10/2020 2:04 PM, Chris M. Thomasson wrote:
 
> iirc, works fine. the tptr in the function foo has a reference,
> therefore the refcount is bumped accordingly. You can create a thread
> using tptr.
 
You can package tptr up in a struct: a thread descriptor that has a
shared_ptr<bar> member to store it in. This maintains the reference
count, start the thread, and it has that reference, fine. The reference
was bumped _before_ the thread was started. You can store it in a
"message" struct and enqueue it such that other threads can dequeue it.
The reference was bumped _before_ another thread has a chance to grab
it. Just keep in mind that shared_ptr requires that a thread has a prior
reference before it can access it. In other words, shared_ptr provides
basic thread safety, not strong, at least last time I used it. pseudo-code:
 
 
This is bad wrt shared_ptr:
 
 
static shared_ptr<bar> g_bar; // nullptr
 
 
void multiple_threads()
{
for (;;)
{
// this does not work wrt the
// last time I looked at shared_ptr
 
shared_ptr<bar> local = g_bar;
 
local->foobar();
}
 
}
 
 
void single_thread()
{
shared_ptr<bar> local(new bar());
g_bar = local;
}
 
 
 
 
 
Bonita Montero <Bonita.Montero@gmail.com>: Feb 10 06:35PM +0100

> Almost getting enough time to try it out. Its an interesting go at the
> problem. Fwiw, here is a new animation that can benefit from this in C++:
> https://youtu.be/Q6lJqIl-Nvs
 
You have diffuse associations.
Not that you'll end up where Aminer is today.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 10 02:07PM -0800

On 2/10/2020 9:35 AM, Bonita Montero wrote:
>> https://youtu.be/Q6lJqIl-Nvs
 
> You have diffuse associations.
> Not that you'll end up where Aminer is today.
 
Creating a swizzle in C++ that can behave like GLSL is not a trivial
task. However, it should help anybody who is porting shader code over to
a pure C++ representation.
Arch Beard <arch.beard@campuscoinproject.org>: Feb 10 04:17PM

We have a C++ cryptocurrency project under the name CampusCoin that can
really use your help. We are a non-profit. If you can offer assistance
in any way, it would really help our community to get back on track and
allow us to do great things with students moving forward.
 
Thank you for your consideration.
 
Sincerely,
 
Arch Beard
CampusCoin Project
Paul <pepstein5@gmail.com>: Feb 10 02:52AM -0800

The below code snippet is from the isocpp.org faq (as an example of bad style)
cmplx& z3 seems to define a non-const reference to a temporary variable
so I'm not sure why the cmplx& z3 definition is legal.
(The author's point is that the code is bad style, not that it has any major
defects.)
Also, would it be ok to say cmplx z3 = *new cmplx(z+d); ?
Thanks a lot for your help,
 
Paul
 
 
void compute(cmplx z, double d)
{
cmplx z2 = z+d; // c++ style
z2 = f(z2); // use z2
cmplx& z3 = *new cmplx(z+d); // Java style (assuming Java could overload +)
z3 = f(z3);
delete &z3;
}
Paavo Helde <myfirstname@osa.pri.ee>: Feb 10 01:27PM +0200

On 10.02.2020 12:52, Paul wrote:
> The below code snippet is from the isocpp.org faq (as an example of bad style)
> cmplx& z3 seems to define a non-const reference to a temporary variable
> so I'm not sure why the cmplx& z3 definition is legal.
 
It's not a temporary. The keyword "new" means it's allocated dynamically
so it will live until explicitly deleted. One only has to make sure the
correct pointer value is passed to the 'delete' operator, which is done
properly in this example.
 
> (The author's point is that the code is bad style, not that it has any major
> defects.)
 
Yes, it's bad style. Also, if the f() function throws an exception,
there would be a memory leak as the 'delete' line would not be executed.
 
> Also, would it be ok to say cmplx z3 = *new cmplx(z+d); ?
> Thanks a lot for your help,
 
This is not ok as you now have an incurable memory leak (the address of
the dynamically allocated object is lost). Also, the current 'delete
&z3;' line would becomes UB because a wrong pointer is sent to it.
 
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)