“Modern C++” != “New(est) Standard”

[Lynn McGuire]

“Modern C++” != “New(est) Standard”
https://arne-mertz.de/2018/08/modern-c-newest-standard/

After writing code in Smalltalk for several years, I love strong typing.

Lynn

[Öö Tiib]

He forgets to mention loose, minimally intrusive coupling.
Thanks to lambdas we do not need type unsafe void(*)(void*)
and void* pair for that.

Most modern from C++17 are variant and optional. Simply awesome
and ridiculously useful. The union was always unsafe and usage of
raw or unique_ptr to represent little, possibly missing value was
so sadly inefficient.

[woodb...@gmail.com]

I think variant is kind of useful, but am not as convinced
about optional. I've considered several times using a
vector of optional rather than a vector of unique_ptr here:
https://github.com/Ebenezer-group/onwards/blob/master/src/cmw/tiers/cmwA.cc
, but optional:
increases the size of my text segment by about 2% and
results in more expensive moves than unique_ptr.

The benefit of optional would be to avoid the heap allocation
and deallocation. I avoid the heap in general, but in this case
think the advantages of unique_ptr are worth it, especially if
the size of my type grows over time leading to even bigger text
segments and more expensive moves.

I'm not a big proponent of unique_ptr, but in this case I find
it helpful.


Brian
Ebenezer Enterprises
http://webEbenezer.net

[Öö Tiib]

On Saturday, 25 August 2018 21:08:30 UTC+3, woodb...@gmail.com wrote:
> On Friday, August 24, 2018 at 1:31:03 AM UTC-5, Öö Tiib wrote:
> > On Friday, 24 August 2018 04:14:20 UTC+3, Lynn McGuire wrote:
> > > “Modern C++” != “New(est) Standard”
> > > https://arne-mertz.de/2018/08/modern-c-newest-standard/
> > >
> > > After writing code in Smalltalk for several years, I love strong typing.
> >
> > He forgets to mention loose, minimally intrusive coupling.
> > Thanks to lambdas we do not need type unsafe void(*)(void*)
> > and void* pair for that.
> >
> > Most modern from C++17 are variant and optional. Simply awesome
> > and ridiculously useful. The union was always unsafe and usage of
> > raw or unique_ptr to represent little, possibly missing value was
> > so sadly inefficient.
>
> I think variant is kind of useful, but am not as convinced
> about optional. I've considered several times using a
> vector of optional rather than a vector of unique_ptr here:
> https://github.com/Ebenezer-group/onwards/blob/master/src/cmw/tiers/cmwA.cc
> , but optional:
> increases the size of my text segment by about 2% and
> results in more expensive moves than unique_ptr.

I can't imagine how you measured? Optional means additional bool,
when unique_ptr means additional pointer, additional indirection
and additional dynamic allocation/deallocation. The situations may
certainly vary but can't be that by that lot.

> The benefit of optional would be to avoid the heap allocation
> and deallocation. I avoid the heap in general, but in this case
> think the advantages of unique_ptr are worth it, especially if
> the size of my type grows over time leading to even bigger text
> segments and more expensive moves.
>
> I'm not a big proponent of unique_ptr, but in this case I find
> it helpful.

The unique_ptr is useful when the component is polymorphic. Optional
can't be polymorphic. It is also easy to see how unique_ptr can
provide storage performance advantage when the component is often
missing (rarely present) but how it can provide better speed
performance? Can you provide a cite or benchmark?

In general what is currently pricey is not memory amount, nor throughput
but it is latency. Optionals are local and that always means less cache
misses and better latency.

[woodb...@gmail.com]

I only have measurements of the text segments. Moving a
unique_ptr is a cheap, fixed time. Whereas moving an optional
is linear in terms of the members of the type. My type in this
case has almost all primitive subtypes that have to be copied.

>
> > The benefit of optional would be to avoid the heap allocation
> > and deallocation. I avoid the heap in general, but in this case
> > think the advantages of unique_ptr are worth it, especially if
> > the size of my type grows over time leading to even bigger text
> > segments and more expensive moves.
> >
> > I'm not a big proponent of unique_ptr, but in this case I find
> > it helpful.
>
> The unique_ptr is useful when the component is polymorphic. Optional
> can't be polymorphic. It is also easy to see how unique_ptr can
> provide storage performance advantage when the component is often
> missing (rarely present) but how it can provide better speed
> performance? Can you provide a cite or benchmark?
>
> In general what is currently pricey is not memory amount, nor throughput
> but it is latency. Optionals are local and that always means less cache
> misses and better latency.

I could go along with that, but would point out that you are
talking about the data and I was talking about the instructions/
text segment. Unique_ptr is cleaner from the instruction side.

[Öö Tiib]

I do not usually measure only one segment of memory. I measure
memory usage peaks and performance under big loads.

You are correct that if you need to frequently change ownership of
large objects (to move those) then unique_ptr is likely better.
That is so regardless if these are optional or not.

Concretely your vector of pendingRequests is a queue where inserts
are from one and erases from other end. It is likely that
std::list<std::optional<T>> wins std::vector<std::unique_ptr<T>>
there but both fragment memory so I would likely use
boost::circular_buffer_space_optimized<std::optional<T>> instead.

> > > The benefit of optional would be to avoid the heap allocation
> > > and deallocation. I avoid the heap in general, but in this case
> > > think the advantages of unique_ptr are worth it, especially if
> > > the size of my type grows over time leading to even bigger text
> > > segments and more expensive moves.
> > >
> > > I'm not a big proponent of unique_ptr, but in this case I find
> > > it helpful.
> >
> > The unique_ptr is useful when the component is polymorphic. Optional
> > can't be polymorphic. It is also easy to see how unique_ptr can
> > provide storage performance advantage when the component is often
> > missing (rarely present) but how it can provide better speed
> > performance? Can you provide a cite or benchmark?
> >
> > In general what is currently pricey is not memory amount, nor throughput
> > but it is latency. Optionals are local and that always means less cache
> > misses and better latency.
>
> I could go along with that, but would point out that you are
> talking about the data and I was talking about the instructions/
> text segment. Unique_ptr is cleaner from the instruction side.

I have had issues with code size only with embedded software and
there are usually no dynamic memory. Most data there is kept in fixed
arrays, ring buffers and stacks. Also stacks of threads are fixed, no
general purpose threads. So optional is fine there but stock
unique_ptr is out of question.

[woodb...@gmail.com]

If the internet is running well, I probably won't have to
frequently move objects. Maybe 2% of the time when the
internet is slow I could have scores of pending requests
and unique_ptr is better then.

>
> Concretely your vector of pendingRequests is a queue where inserts
> are from one and erases from other end. It is likely that
> std::list<std::optional<T>> wins std::vector<std::unique_ptr<T>>
> there but both fragment memory so I would likely use
> boost::circular_buffer_space_optimized<std::optional<T>> instead.
>

That or an intrusive list would make std::optional more
appealing, but I only use Boost in closed source applications.
Besides the standard, I only have one external dependency for
compression.

> > > > The benefit of optional would be to avoid the heap allocation
> > > > and deallocation. I avoid the heap in general, but in this case
> > > > think the advantages of unique_ptr are worth it, especially if
> > > > the size of my type grows over time leading to even bigger text
> > > > segments and more expensive moves.
> > > >
> > > > I'm not a big proponent of unique_ptr, but in this case I find
> > > > it helpful.
> > >
> > > The unique_ptr is useful when the component is polymorphic. Optional
> > > can't be polymorphic. It is also easy to see how unique_ptr can
> > > provide storage performance advantage when the component is often
> > > missing (rarely present) but how it can provide better speed
> > > performance? Can you provide a cite or benchmark?
> > >
> > > In general what is currently pricey is not memory amount, nor throughput
> > > but it is latency. Optionals are local and that always means less cache
> > > misses and better latency.
> >
> > I could go along with that, but would point out that you are
> > talking about the data and I was talking about the instructions/
> > text segment. Unique_ptr is cleaner from the instruction side.
>
> I have had issues with code size only with embedded software and
> there are usually no dynamic memory. Most data there is kept in fixed
> arrays, ring buffers and stacks. Also stacks of threads are fixed, no
> general purpose threads. So optional is fine there but stock
> unique_ptr is out of question.

The context here is that there's a file system. I don't think
there's a problem with using a little dynamic memory in that
context.


Brian
Ebenezer Enterprises
https://github.com/Ebenezer-group/onwards