Monday, July 6, 2015

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

Martijn van Buul <pino@dohd.org>: Jul 06 08:30PM

* Öö Tiib:
>> requirements by a similar number due to a reduce in memory fragmentation.
 
> I don't dismiss it. Your design feels like hybrid of 'any' and 'variant'. I
> trust it does not matter for question of intrusive reference counting.
 
Well, it doesn't, other than setting the stage for a specific, real-life
example.
 
> When we have custom allocator then 'std::make_shared' does not
> work but then it might be worth considering usage of 'std::allocate_shared'
> as alternative to switching to intrusive pointer.
 
std::allocate_shared wouldn't work. In our case, because I created a
memory pool for one specific object (of constant size), I was able to
use a pool with constant block size (in other words: A doubly linked
list). This has several benefits - most importantly memory fragmentation,
as a memory pool of constant block size cannot fragment, whereas a dynamic
heap can.
 
The Allocator-interface used by std::make_shared wouldn't work here. Even
though it would still make allocations of the exact same size *in practice*,
the rub is that this size isn't known in advance.
 
>> shared_ptr
 
> I do not understand how usage of 'std::allocate_shared' makes extra
> allocations and what internal details you have in mind.
 
std::allocate_shared<T> will make a single allocation, containing the payload
and "a small bookkeeping object". The latter is an implementation detail;
the spec doesn't say anything about it, and different libraries use
different approaches.
 
So, on gcc, std::allocate_shared<T> will allocate
 
sizeof(T) + sizeof(__shared_ptr<>) - where __shared_ptr is overloaded
so often that I gave up trying to figure out which of the many templated
versions is actually used.
 
On Clang/LLVM, std::allocate_shared<T> will allocate
 
sizeof(T) + sizeof(__shared_ptr_emplace<T, Alloc>) which may or may
not be the same as sizeof(T) + sizeof(__shared_weak_count)
 
What MSVC does is anyone's guess - and it doesn't even matter. It's an
internal detail, relying on it would be foolish at best. The result is
that there is no way to predict exactly what size of allocation
std::allocae_shared<> will make, and I can't even rely on the fact that
this allocation will always be of the same size, given the same template
argument T.
 
With an intrusive_ptr I have none of these issues. I know exactly what
size of objects will be allocated, and I know it at compile time. It's
 
sizeof(T)
 
> wrote that virtual inheritance and diamond caused by two refcounted base
> classes is such a great example where 'shared_ptr' most likely wins intrusive
> refcounting.
 
... and i say that this *just* as application dependant as my case to the
contrary.
 
--
Martijn van Buul - pino@dohd.org
MikeCopeland <mrc2323@cox.net>: Jul 05 05:04PM -0700

I'm developing an application which contains a lot of user interface
dialog. As I test it, I'm forced to repeat an increasing number of
prompt/data response sets. For the moment, I'd like to have the program
use a fixed set of data as I evolve new functions.
Is there a better way to do something like:
#define TESTED true;
...
#ifndef TESTED
{
ossz.str(""), ossz << "Enter RaceId (3-9 characters) for race #"
<< nx1 + 1 << ":";
wProm(2, PRLINE, HINORM, ossz.str()), readStr(tEvent);
}
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)