sizeof in a template, applied in a template type

[asetof...@gmail.com]

What about the use
sizeof(node<T>)
in a template, it return the correct size? Thank you

example the sizeof() used in function below

template<class T> class node{
public:
T el;
node*next;// is it better here "node<T>*next;" instead?
}

template<class T> class list{
public:
node<T>* pnd;
int sz;

function(void)
{int s=sizeof(node<T>);
....
}
}

[Marcel Mueller]

On 01.10.17 12.09, asetof...@gmail.com wrote:
> What about the use
> sizeof(node<T>)
> in a template, it return the correct size? Thank you

Yes. sizeof is reliable within templates since the generic arguments
must be known at compile time anyway.


Marcel

[asetof...@gmail.com]

Thank you

so cast is ok too, for example I in a template have something as (where T is the type of the template
)
node<T>*p=(node<T>*)malloc(sizeof(node<T>)

Whould be ok...(if p points to one element node<T>)

[Marcel Mueller]

It would work.

But why not to use operator new which needs nether a cast nor sizeof?


Marcel

[Öö Tiib]

In C++ uninitialized memory buffer may be cast into object type only
on limited cases. You can check it compile time with static_assert
if it is ok or not:

static_assert(std::is_pod<T>::value, "T must be POD type.");

Or it may be better to use new instead of malloc and cast.

[asetof...@gmail.com]

I don't use new() because I have my home made memory allocator function
that inform me for leaks and write out heap memory in some places where it should be not written

[David Brown]

One of the key features of C++ compared to C is better resource
management with more automation. It does not make sense to use a C
malloc that helps you see where your leaks are, when you could use C++
"new" and avoid the leaks in the first place.

C++ lets you use your own allocator with "new", and thus get the best of
both worlds.

[Barry Schwarz]

On Sun, 1 Oct 2017 15:02:17 -0700 (PDT), asetof...@gmail.com
wrote:

>I don't use new() because I have my home made memory allocator function

This I understand.

>that inform me for leaks and write out heap memory in some places where it should be not written

I am curious how an allocator can report a leaks.

I have no idea what the phrase after the "and" is supposed to mean.

--
Remove del for email

[asetof...@gmail.com]

Easy at end of the program is open a window that show if there are leaks the max memory usage from the program, the remain heap, as linked list (if I remember with address) the first address one has to pass to free() function for eliminate the first leak if I remember well or something as this. If the program find one write out the space in the heap, it stop the program and the address to last functon called first the write out the space is found too.

[asetof...@gmail.com]

Barry Schwarz

----
"and" would mean
if I have a space returned from malloc
it has 2 sentinels one in the start of that space and one in the end
that has no be written from program

If the data in one of these 2 sentinel space it is changed
when free has to free that memory
check if the data of the 2 borders sentinel is changed too
If it is changed free() call for end the program
A window is open show (with other things) the address array is written out the space, the value written, the side in the beginning or in the ending, the address last function called etc

[David Brown]

On 02/10/17 12:23, asetof...@gmail.com wrote:
<scrambled mess of quotations>

Please - if you want people to help you, then follow Usenet conventions
and quote properly. Posts without context do not help, nor do mixed
quotations from different posts at different times.

The best solution is to get a real newsreader and a real newserver,
instead of the disaster that Google provides. But if you have to use
google groups, learn to use it correctly and make the effort to format
your posts correctly.

[Richard]

[Please do not mail me a copy of your followup]

Marcel Mueller <news.5...@spamgourmet.org> spake the secret code
<oqqi5d$25v$2...@gwaiyur.mb-net.net> thusly:

>On 01.10.17 12.41, asetof...@gmail.com wrote:
>But why not to use operator new which needs nether a cast nor sizeof?

Because naked new/delete is a code smell.

Use std::unique_ptr or std::shared_ptr as appropriate (and the vast
majority of the time, you do not need shared_ptr).

CppCon 2016: Herb Sutter "Leak-Freedom in C++... By Default"
<https://www.youtube.com/watch?v=JfmTagWcqoE>
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[Richard]

[Please do not mail me a copy of your followup]

(Richard) legaliz...@mail.xmission.com spake the secret code
<oqtsvj$hnh$3...@news.xmission.com> thusly:

>Use std::unique_ptr or std::shared_ptr as appropriate (and the vast
>majority of the time, you do not need shared_ptr).

...and yes, you can use these with custom allocators. Learn how to
write C++ and stop writing C. (Don't use malloc/free.)

[Scott Lurndal]

legaliz...@mail.xmission.com (Richard) writes:
>[Please do not mail me a copy of your followup]
>
>(Richard) legaliz...@mail.xmission.com spake the secret code
><oqtsvj$hnh$3...@news.xmission.com> thusly:
>
>>Use std::unique_ptr or std::shared_ptr as appropriate (and the vast
>>majority of the time, you do not need shared_ptr).
>
>...and yes, you can use these with custom allocators. Learn how to
>write C++ and stop writing C. (Don't use malloc/free.)

Or just write code that performs correctly and optimally using any feature of
C++ (including those inherited from C) instead of relying on some
dogmatic approach to C++ programming.

And avoid using smart pointers when you care about performance.

[Ian Collins]

On 10/ 3/17 01:23 AM, David Brown wrote:
> On 02/10/17 12:23, asetof...@gmail.com wrote:
> <scrambled mess of quotations>
>
> Please - if you want people to help you, then follow Usenet conventions
> and quote properly. Posts without context do not help, nor do mixed
> quotations from different posts at different times.

You are wasting your time David. He/She has been posting
incomprehensible gibberish for years.

--
Ian

[Ian Collins]

Untrue, but one should avoid starting a sentence with "And" :)


--
Ian

[Öö Tiib]

You guys are turning software engineering into some sort of mix of
dark art, magic and religion. :D

Everybody know that programmers who care about performance measure
and profile that very performance. Why they do that? Because
mechanical usage of whatever "incantations" be it malloc, free,
new, delete, smart pointers or ignorant pointers does not usually
improve performance. Performance is always improved by using skill
of programmer. Period. ;)

[Chris M. Thomasson]

On 10/2/2017 3:23 AM, asetof...@gmail.com wrote:
> Barry Schwarz
>
> On Sun, 1 Oct 2017 15:02:17 -0700 (PDT), asetof...@gmail.com
> wrote:
>
>
>> I don't use new() because I have my home made memory allocator function
>
>
> This I understand.
>
>
>> that inform me for leaks and write out heap memory in some places where it should be not written
>
>
> I am curious how an allocator can report a leaks.

[...]

A radically simple and naive way would be that the allocator increments
a counter for each allocation, and decrements for each deallocation.

If this counter is not zero when the program terminates, there is a
leak. Stupid simple and naive, but it can help, in a sense.

[Paavo Helde]

Depends on the size of the program. If there were 10 million allocations
then knowing that 1000 of them were not freed is not very helpful. Also,
some programs allocate a lot of static or semi-static data structures
which are never freed (just because the OS will do it much better
anyway), so a single number at the end of the program would tell nothing.

A leak by definition is something which accumulates. To see the
accumulation you need to run something in a loop and report the
allocator diagnostics after each run. I have found it useful to
instrument the memory allocator so that I can define a bunch of memory
size intervals and a counter for each of them. When I see there is a
leak in some interval I redefine the intervals to be more fine-grained
in that area and rerun the program until I have identified the exact
culprit size(s). With some luck, there are not many places in the
program allocating this exact size and it becomes much simpler to find
the bug.

Of course, in proper C++ there are not many possibilities to create
accidental memory leaks, but still I occasionally find some, typically
in places where I have tried to be too clever like using placement new
and forgetting to call the destructor explicitly afterwards.

Cheers
Paavo

[Paavo Helde]

On 2.10.2017 21:15, Scott Lurndal wrote:
>
> And avoid using smart pointers when you care about performance.

Some smart pointers might affect performance when used in a wrong place,
but as a generalization the above is definitely wrong. E.g. using
MT-safe std::shared_ptr in a situation which does not require MT-safety
or shared ownership might indeed be slower than the ideal, but the
solution is to use a more suitable smartpointer, not to throw them all away!

Cheers
Paavo

[Richard]

[Please do not mail me a copy of your followup]

sl...@pacbell.net spake the secret code
<NmvAB.83850$9F2....@fx30.iad> thusly:

>>(Richard) legaliz...@mail.xmission.com spake the secret code
>><oqtsvj$hnh$3...@news.xmission.com> thusly:
>>
>>>Use std::unique_ptr or std::shared_ptr as appropriate (and the vast
>>>majority of the time, you do not need shared_ptr).
>

>Or just write code that performs correctly and optimally using any feature of
>C++ (including those inherited from C) instead of relying on some
>dogmatic approach to C++ programming.

The reason to avoid malloc/free isn't dogma, it is the accumulated
experience of people making stupid mistakes when they use malloc and
free along with raw pointers directly instead of using standard
containers and smart pointers.

>And avoid using smart pointers when you care about performance.

This doesn't make any sense to me. How is using std::unique_ptr to
declare ownership going to make things slower? Someone has to release
the memory when ownership is released and that's what unique_ptr
brings to the table. Performance in a modern machine is dominated by
cache misses more than microinstructions around obtaining the
underlying raw pointer from a smart pointer.

[Barry Schwarz]

But something other than the allocator must examine the counter. The
allocator is not reporting leaks. It is providing data that will
allow another function to determine if a leak is present. And in this
case, it will provide the quantity of leaks but no data about any of
them.

[asetof...@gmail.com]

------------
Some data of the heap list that use malloc it seems global data accessible in one assembly file to one function
name as freeList(void); at end of program freeList() is called
it print all relative memory info;
free to the sys, memory
allocate for build the heap list.
Function as malloc/free/realloc/freeList are function of one .dll from assembly language

[Paavo Helde]

On 3.10.2017 5:11, Barry Schwarz wrote:
> On Mon, 2 Oct 2017 12:47:48 -0700, "Chris M. Thomasson"
> <invalid_chr...@invalid.invalid> wrote:
>
>> On 10/2/2017 3:23 AM, asetof...@gmail.com wrote:
>>> Barry Schwarz
>>>
>>> On Sun, 1 Oct 2017 15:02:17 -0700 (PDT), asetof...@gmail.com
>>> wrote:
>>>
>>>
>>>> I don't use new() because I have my home made memory allocator function
>>>
>>>
>>> This I understand.
>>>
>>>
>>>> that inform me for leaks and write out heap memory in some places where it should be not written
>>>
>>>
>>> I am curious how an allocator can report a leaks.
>> [...]
>>
>> A radically simple and naive way would be that the allocator increments
>> a counter for each allocation, and decrements for each deallocation.
>>
>> If this counter is not zero when the program terminates, there is a
>> leak. Stupid simple and naive, but it can help, in a sense.
>
> But something other than the allocator must examine the counter. The
> allocator is not reporting leaks.

Oh, I see you are into word games. No problem, the allocator can easily
report its statistics to console when asked to allocate size_t(-1), for
example. Just kidding ;-)

[Scott Lurndal]

We have an application that has 24 to 96 cpu-bound threads and runs for
several days. Replacing the dogmatic C++ smart pointer style with
a more C style of element management improved performance by 40%, which
cut close to a day off the run time.

[Scott Lurndal]

legaliz...@mail.xmission.com (Richard) writes:
>[Please do not mail me a copy of your followup]
>
>sl...@pacbell.net spake the secret code
><NmvAB.83850$9F2....@fx30.iad> thusly:
>
>>>(Richard) legaliz...@mail.xmission.com spake the secret code
>>><oqtsvj$hnh$3...@news.xmission.com> thusly:
>>>
>>>>Use std::unique_ptr or std::shared_ptr as appropriate (and the vast
>>>>majority of the time, you do not need shared_ptr).
>>
>>Or just write code that performs correctly and optimally using any feature of
>>C++ (including those inherited from C) instead of relying on some
>>dogmatic approach to C++ programming.
>
>The reason to avoid malloc/free isn't dogma, it is the accumulated
>experience of people making stupid mistakes when they use malloc and
>free along with raw pointers directly instead of using standard
>containers and smart pointers.
>

Yet there are thousands of programmers who have successfully written
hundreds of thousands of applications using raw pointers and malloc/free without the
stupid mistakes.

Dogma.

[Paavo Helde]

So based on your single negative experience with a single smartpointer
type and a single special massively parallel application you apparently
feel entitled to claim that all smartpointers absolutely kill
performance for all people and for all applications. Sigh.

Out of curiosity, was this "dogmatic C++ smart pointer" std::shared_ptr
or a similar multithread-safe one (which involves thread synchronization
at each smartpointer copy)? IOW, was the day lost on needless thread
synchronization or on something else?

I am curious because I have been taking great care that our parallel
heavy worker threads only use single-threaded data structures and
single-threaded smart-pointers, with zero thread synchronization during
the active run. Would be good to have some confirmation my efforts are
not wasted.

Cheers
Paavo

[Richard]

[Please do not mail me a copy of your followup]

sl...@pacbell.net spake the secret code

<u8MAB.80366$gF2....@fx31.iad> thusly:

>We have an application that has 24 to 96 cpu-bound threads and runs for
>several days. Replacing the dogmatic C++ smart pointer style with
>a more C style of element management improved performance by 40%, which
>cut close to a day off the run time.

You seem to equate advice with dogma.

Any piece of reasonable advice can be turned into silly usage that is
obviously stupid.

It's like turning the advice "owning your own home is a good thing"
into taking out a variable rate mortgage with a massive balloon
payment and servicing that mortgage early on with 90% of your take
home pay. You took a piece of reasonable advice and turned it into a
hell of your own making.

The advice is to use smart pointers to declare explicitly who owns the
heap memory. Does that mean slavishly use shared_ptr every time you
pass one of these pointers around? No, and in fact, that's a bad idea
for performance, particularly if you didn't use make_shared to
construct the pointers in the first place. Passing around
shared_ptr<T> should be used to emphasize changing ownership. If you
just need access to the data, pass a plain pointer or a reference.

I once worked on a team that insisted that the arguments of deep call
chains should all be shared_ptr instead of just the raw pointer.
This resulted in lots of wasted time being spent incrementing and
decrementing the reference count, even though the called functions
didn't own any of the data they were being given. If make_shared
wasn't used to created these shared_ptrs, then you have potential
cache misses as well, stomping all over your performance by stalling
the processor.

I couldn't convince them that this was paying a cost for little to
no benefit, so I complied with their wishes. They kept arguing "well
what if someone stores that pointer inside the call chain?". To which
I would look at them like "what, strangers are committing to our code
base without our knowledge?" This was a team where every commit went
through peer code review, so we should have been addressing real problems
and not imaginary monsters in the closet that might come out at night.
If this kind of mindless "it has to be shared_ptr everywhere" simple
minded behavior is what you're talking about as "dogma", then surprise,
I agree with you.

However, if you watch Herb Sutter's talk, that isn't what he's been
saying. He's not issuing dogma. He is offering advice about how to
use heap memory in such a way that ownership is explicit by design and
leak-free by construction. He's talking about the data structures and
how declaring things as shared_ptr or unique_ptr in the data structure
makes them leak free by default and explicitly declares who owns the data.
From there you should program in such a way that uses of the raw pointer
don't have any implication about ownership, just access. This makes it
such that if I ever see a function taking a raw pointer, I know that
ownership isn't transferred, only access provided. The called code
never becomes an owner of the pointed to data.

With sufficient personal discipline, you can use raw pointers and C
style programming habits and make all of this work. However, I see no
reason to reject Herb's advice, because it is consistent with my own
programming experience. Once I started using smart pointers and standard
library containers to manage the ownership of resources, I stopped having
memory/resource leaks. An entire class of problems just went away and
I could focus on the logic in my problem domain and not resource leaks.
It's not that I can't make it work the C way, or that I don't know how
to write efficient code, it's that C++ lets me achieve the same
objective (leak safety without compromising efficiency) with less
work.

[Jorgen Grahn]

On Tue, 2017-10-03, Richard wrote:
...

> With sufficient personal discipline, you can use raw pointers and C
> style programming habits and make all of this work. However, I see no
> reason to reject Herb's advice, because it is consistent with my own
> programming experience. Once I started using smart pointers and standard
> library containers to manage the ownership of resources, I stopped having

^^^^^^^^^^
> memory/resource leaks.

I was waiting for that. IME, almost all objects live either on the
stack, as a member, or in a container. I only rarely encounter
situations where I have to operator new anything. So from my point of
view, you're fighting over a rarely useful edge case.

Unless the opposition believes the standard containers are just C++
dogma, too.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Richard]

[Please do not mail me a copy of your followup]

Jorgen Grahn <grahn...@snipabacken.se> spake the secret code
<slrnota3g2.14...@frailea.sa.invalid> thusly:

>On Tue, 2017-10-03, Richard wrote:
>...
>> With sufficient personal discipline, you can use raw pointers and C
>> style programming habits and make all of this work. However, I see no
>> reason to reject Herb's advice, because it is consistent with my own
>> programming experience. Once I started using smart pointers and standard
>> library containers to manage the ownership of resources, I stopped having
> ^^^^^^^^^^
>> memory/resource leaks.
>
>I was waiting for that. IME, almost all objects live either on the
>stack, as a member, or in a container.

This is exactly the point of Herb Sutter's presentation.

>I only rarely encounter
>situations where I have to operator new anything. So from my point of
>view, you're fighting over a rarely useful edge case.

Well, to be honest, we haven't seen the offending code in question,
just an indirect discussion of "smart pointers are inefficient"
without seeing how they are being used in the actual code.

If smart pointers were generally inefficient when properly used, then
I think we would have heard about it from more than just one person
posting on usenet. It's not like there are only a few people who care
about performance with C++.

[Öö Tiib]

I thought we know it.

The 'std::shared_ptr' is quite heavy since it has additional level of
indirection, two thread safe reference counts (shared count and weak
count) and deleter functor. Also when the object is not made with
'std::make_shared' then additional allocation (and deallocation) is
made per object. That all can cripple performance if it is used in
that 5% of code base that is executed 95% of run time.

The 'std::unique_ptr' does the things what we would do anyway
when needing a dynamic member. IMHO it affects performance only
when we did not need dynamically allocated object there at all (so
rough pointer would be as bad waste there).

[Richard Damon]

One thing worth pointing out, 'new' will do NOTHING to help with
resource management. All new does is create object space from the heap,
and then call the object constructor on it. Its advantage is that you
can't forget to construct the object.

Putting the pointer you get from new into a 'smart' object that will
manage the lifetime is what help, and that starts with the automatic
call of the destructor when the object goes out of scope.

[asetof...@gmail.com]

No problem with malloc free in C++ object constructor destructor
(at last for the compiler I use)

What is the problem?
The important I reserve enough memory for the object and that memory is good aligned
Or I think it wrong?

I already have a new/delete operator that use my malloc/ free implementation but I use always malloc/free, the same.

[Richard Damon]

There is technically nothing wrong with using malloc instead of new, as
long as you also construct the object in the memory afterwords. It is
very non-idiomatic though.

One way to see this is that, by definition, new Type is defined as
calling operator new and then the constructor, and operator new is
typically implemented as a call to malloc, followed by a test for null
and a throw (this isn't required, but typical, malloc can NOT call
operator new though, so a user provide operator new is allowed to call
malloc)

[Bonita Montero]

> template<class T> class list{
> public:
> node<T>* pnd;
> int sz;
>
> function(void)
There's a missing return-type here.


> {int s=sizeof(node<T>);
> ....
> }
> }
>

[David Brown]

On 07/10/17 22:53, Richard Damon wrote:
> On 10/2/17 3:29 AM, David Brown wrote:
>> On 02/10/17 00:02, asetof...@gmail.com wrote:
>>> I don't use new() because I have my  home made memory allocator
>>> function that inform me for leaks and write out heap memory in some
>>> places where it should be not written
>>>
>>
>> One of the key features of C++ compared to C is better resource
>> management with more automation.  It does not make sense to use a C
>> malloc that helps you see where your leaks are, when you could use C++
>> "new" and avoid the leaks in the first place.
>>
>> C++ lets you use your own allocator with "new", and thus get the best of
>> both worlds.
>>
>
> One thing worth pointing out, 'new' will do NOTHING to help with
> resource management. All new does is create object space from the heap,
> and then call the object constructor on it. Its advantage is that you
> can't forget to construct the object.
>

The use of "new" (and, crucially, "delete") means that constructors and
destructors are called properly. You still have to be careful about the
outer level - anything your code allocates with "new", it must remember
to "delete". But use of "new" and "delete" at least means any
sub-objects are managed responsibly.

To complete the picture, you should use a smart pointer or a standard
library container on the outside level, as you point out below.

But it is the "new" bit that does the allocation, and so that's where
you mix in your own allocator - even though you ideally only want "new"
to be called indirectly from functions like "make_unique".

[asetof...@gmail.com]

Bonita Montero wrote

> template<class T> class list{
> public:
> node<T>* pnd;
> int sz;
>
> function(void)
There's a missing return-type here.

----
I write:

yes that would not compile
perhaps it was better

"int function(void)"

----

[Öö Tiib]

On Monday, 9 October 2017 21:33:28 UTC+3, David Brown wrote:
>
> But it is the "new" bit that does the allocation, and so that's where
> you mix in your own allocator - even though you ideally only want "new"
> to be called indirectly from functions like "make_unique".

Note that the operator new is typically called from lower layer of
abstraction. I mean it is usually 'std::allocator::alloc' that makes
memory management of containers to work. That 'alloc' is described
to allocate uninitialized memory with '::operator new(std::size_t)' but
(for letting containers to optimize better) it is left unspecified
when and how it does that.

[James R. Kuyper]

std::container<T,Allocator> (where "container stands in for any of the
standard containers) uses Allocator::allocate() (NOT alloc) to allocate
memory. Allocator defaults to std::allocator, which does indeed use
::operator new(std::size_t). However, since asetofsymbols mentioned
using his own home made memory allocator, and David Brown mentioned that
you can define your own allocator for use with new, I think it's
important to keep track of the fact that you don't have to use
std::allocator just because you're using a standard container.

More precisely, the standard containers are quite likely to use
Allocator::Rebind<U>::other, because not everything that needs to be
dynamically allocated by std::container<T,Allocator> is necessarily of
type T.

[Öö Tiib]

On Tuesday, 10 October 2017 00:03:16 UTC+3, James R. Kuyper wrote:
> On 2017-10-09 15:45, Öö Tiib wrote:
> > On Monday, 9 October 2017 21:33:28 UTC+3, David Brown wrote:
> >>
> >> But it is the "new" bit that does the allocation, and so that's where
> >> you mix in your own allocator - even though you ideally only want "new"
> >> to be called indirectly from functions like "make_unique".
> >
> > Note that the operator new is typically called from lower layer of
> > abstraction. I mean it is usually 'std::allocator::alloc' that makes
> > memory management of containers to work. That 'alloc' is described
> > to allocate uninitialized memory with '::operator new(std::size_t)' but
> > (for letting containers to optimize better) it is left unspecified
> > when and how it does that.
>
> std::container<T,Allocator> (where "container stands in for any of the
> standard containers) uses Allocator::allocate() (NOT alloc) to allocate

Thanks for fixing, perhaps my memory mistook "alloc" from Objective-C.

> memory. Allocator defaults to std::allocator, which does indeed use
> ::operator new(std::size_t). However, since asetofsymbols mentioned
> using his own home made memory allocator, and David Brown mentioned that
> you can define your own allocator for use with new, I think it's
> important to keep track of the fact that you don't have to use
> std::allocator just because you're using a standard container.

I had impression that asetofsymbols did redefine the operator new (that std::allocator uses). User-defined Allocator classes are used but
not too often in actual code bases.

>
> More precisely, the standard containers are quite likely to use
> Allocator::Rebind<U>::other, because not everything that needs to be
> dynamically allocated by std::container<T,Allocator> is necessarily of
> type T.

The full truth about almost anything in C++ is tiny bit over-complicated. :D
Since C++11 the standard containers must actually use std::allocator_traits<Allocator>::rebind_alloc<U> in that situation.
On case Allocator is std::allocator<T> then that evaluates to same type
like what you wrote (just "rebind" not "Rebind") but that match is AFAIK
not required from allocator_traits of user-defined allocators. I trust
that "rebind" is optional or planned to deprecate by C++17 or both.

[asetof...@gmail.com]

It is easy: New operator (not std) in few I remember call one malloc type routine that call the OS function that give memory.
New/delete/io/ stream/memory functions are in a C++ library .dll
(for to say the true someone are in one assembly .dll, and are reached /callable using pointers from the C++ .dll) They have 0 routine in common with C++ std library, no dipendence, follow no standard but have the same names (if I not consider macro) and 50%? of C++ library functionality

[Vir Campestris]

On 09/10/2017 19:33, David Brown wrote:
> even though you ideally only want "new" to be called indirectly from
> functions like "make_unique".

I bumped into an awkward one the other day. There's a static function to
get the singleton object, which returns a shared_ptr to it. When I tried
to call make_unique I found the author had carefully made the
constructor private. I then spent half an hour trying to find what to
make a "friend" to allow make_unique to be used. Then gave up.

Andy