Thursday, October 19, 2017

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

Marcel Mueller <news.5.maazl@spamgourmet.org>: Oct 19 08:00PM +0200

On 15.10.17 16.38, Paavo Helde wrote:
>> the ref count is part of the object, you can safely convert to a raw
>> pointer and back to an intrusive_ptr.
 
> Only as long as you don't need weak pointers, and as long as you
 
Indeed. Weak pointers are an indication for shared_ptr.
 
> carefully avoid doing this during construction and destruction.
 
?
 
I already had classes that managed their own lifetime with intrusive
reference counts.
 
What kind of problem do you have in mind?
 
 
[intrusive_ptr]
>> This method is also faster than shared_ptr.
 
> Only if you don't use std::make_shared() or std::allocate_shared (like
> you should).
 
The disadvantage is that you need to use the custom allocator all the way.
 
 
> class in the standard (intrusive refcount, no thread safety, no weak
> pointers, etc), but regarding the recommendations this would not help
> much because the newbies would not know if their code can use it or not.
 
For my own purposes I combined the efficiency and the thread-safety by
abusing the volatile quantifier. Only volatile instances invoke the
thread safe functions. They provide even strong thread safety.
Of course, this only applies to the access to the smart pointer itself.
The access to the reference counter need to use atomic
increment/decrement to allow the coexistence of thread-safe and local
instances that refer to the same object. That's the price.
 
 
Marcel
Paavo Helde <myfirstname@osa.pri.ee>: Oct 20 01:01AM +0300

On 19.10.2017 21:00, Marcel Mueller wrote:
 
> I already had classes that managed their own lifetime with intrusive
> reference counts.
 
> What kind of problem do you have in mind?
 
So what do you think will happen when you construct a refcounted
intrusive smartpointer from 'this' (or a raw pointer having the value of
'this') during the constructor or destructor call, maybe indirectly
through some other member functions?
 
In the constructor, if the extra smartpointer goes out of scope, your
object gets destroyed before it has even finished constructing. In
destructor, it would become destroyed twice.
 
This can be fixed and worked around (e.g. by avoiding constructing
smartpointers from 'this' during ctor/dtor), but then it would not be
such a simple and safe solution any more.
 
With std::shared_ptr an extra shared_ptr can be legally constructed only
from another shared_ptr which does not exist during ctor/dtor call;
calling shared_from_this() is not UB either since C++17 (throws an
exception which can be caught and handled).
 
 
>> Only if you don't use std::make_shared() or std::allocate_shared (like
>> you should).
 
> The disadvantage is that you need to use the custom allocator all the way.
 
std::make_shared() uses the standard allocator.
 
cheers
paavo
Cholo Lennon <chololennon@hotmail.com>: Oct 19 04:04PM -0300

I know that some people here are older than me (forty something), do you
feel the same? at least in my country, some tech companies are starting
to hire developers younger than 35 :-O
 
 
"Survey: Tech workers are terrified they will be sacked for being too old"
 
http://www.theregister.co.uk/2017/10/19/tech_workers_terrified_theyll_age_out/
 
 
--
Cholo Lennon
Bs.As.
ARG
Ian Collins <ian-news@hotmail.com>: Oct 20 08:17AM +1300

On 10/20/17 08:04 AM, Cholo Lennon wrote:
> to hire developers younger than 35 :-O
 
> "Survey: Tech workers are terrified they will be sacked for being too old"
 
> http://www.theregister.co.uk/2017/10/19/tech_workers_terrified_theyll_age_out/
 
At least in this this part of the world, the headline is utter nonsense.
 
 
--
Ian
Vir Campestris <vir.campestris@invalid.invalid>: Oct 19 09:47PM +0100

On 19/10/2017 20:04, Cholo Lennon wrote:
> I know that some people here are older than me (forty something), do you
> feel the same? at least in my country, some tech companies are starting
> to hire developers younger than 35 :-O
 
It's an old problem. But just FYI - in the last 5 years I've been made
redundant (company changed direction) got a new job, had that company
shut down the division, got another job, left in disgust and got another
job. I've not been unemployed in the whole time.
 
I'm a pure techy - no staff reporting to me - and my kids are 35...
 
Andy
"Öö Tiib" <ootiib@hot.ee>: Oct 19 02:40PM -0700

On Thursday, 19 October 2017 22:04:23 UTC+3, Cholo Lennon wrote:
> to hire developers younger than 35 :-O
 
> "Survey: Tech workers are terrified they will be sacked for being too old"
 
> http://www.theregister.co.uk/2017/10/19/tech_workers_terrified_theyll_age_out/
 
What we have feels like symptoms of bubble. Wasn't dot-com bubble
20 years ago about 1997 and busted 2001? Money is easy to raise during
bubble and so who they hire likely depends on what is the plan of
business. Again piles of insane web sites (now "SaaS"/"cloud")
stupid programs (now "Apps"/"IoT") and moronic chat and spam bots
(now "AI"/"machine learning").
 
Opportunists who want to ride on that bubble do not want to hire those
who experienced previous burst. What to do with someone who likely
will see through that the buzzword poop won't fly too long? They need
people who believe that they do genial things and work for next Steve
Jobs. Workers who struggle hard to add polish to whatever hopeless
mock-up mirage are the power that helps to get the hopes up and
investments going.
 
Other companies that make actually competitive products and real
profits (not investments on buzzword projections) will continue to
have diverse employee base. Also those won't likely snap whenever
the bubble will fusillade. ;-)
aminer68@gmail.com: Oct 19 01:31PM -0700

Hello,
 
A new algorithm of mine is coming, it is a scalable FIFO queue that i will implement for Delphi and FreePascal and C++. Hope you will be happy of all my scalable algorithms.
 
I think my algorithm will be better than the following algorithm:
 
Using Elimination to Implement Scalable and Lock-Free FIFO Queues:
 
http://people.csail.mit.edu/shanir/publications/SPAA2005.pdf
 
Thank you,
Amine Mopulay Ramdane.
Bo Persson <bop@gmb.dk>: Oct 19 07:32AM +0200

On 2017-10-18 20:32, Gareth Owen wrote:
 
> CounterPoint: Chandler Carruth how they use ever single bit of composite
> objects in Clang/LLVM https://www.youtube.com/watch?v=vElZc6zSIXM (key
> bits from 22:00 ish)
 
Of course you can do that if you have your own compiler.
 
But the code will have zero portability, which is a problem only if you
intended it to be portable. Clang/LLVM internal code might not have that
goal.
 
 
Bo Persson
"Öö Tiib" <ootiib@hot.ee>: Oct 18 11:44PM -0700

On Wednesday, 18 October 2017 17:07:41 UTC+3, David Brown wrote:
> hidden information (watermarking is a related technology). Presumably
> if that's what Rick is thinking of, it is in terms of spotting the
> malware or preventing it.
 
It can be "secret". In reality I have seen it done with fully straight face
on case of desire to pass more information without changing some interface.
Result is typically opposite to what I imagine they wanted to achieve.
Instead of backward compatibility they get very odd defects for the
parties that were made before so did not imagine the extended "Gotcha!"s
in interface and future is also dim because of confused maintainers with
that strange interface. That is why I lean towards "foolish".
Gareth Owen <gwowen@gmail.com>: Oct 19 06:55PM +0100


> Of course you can do that if you have your own compiler.
 
> But the code will have zero portability, which is a problem only if
> you intended it to be portable.
 
Nope.
 
It's insanely complicated template magic, and it relies on alignof and
uintptr_t from C++11, but other than that, its completely standard.
JiiPee <no@notvalid.com>: Oct 19 01:56PM +0100

On 18/10/2017 21:06, Öö Tiib wrote:
>> first values by the constructor). When you have to "zero" the object to
>> its initial values (the same values as when the object is created).
> Normally it is better when objects are not reused in different roles.
 
Thanks, interesting view... something to think about. Ok so maybe I
should delete the object and create new one.
 
ram@zedat.fu-berlin.de (Stefan Ram): Oct 19 01:09AM

>object (which would then have automatically everything initialized to
>first values by the constructor). When you have to "zero" the object to
>its initial values (the same values as when the object is created).
 
»Con.1: By default, make objects immutable
 
Reason
 
Immutable objects are easier to reason about«
 
C++ Core Guidelines (April 7, 2016)
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)