Friday, May 8, 2015

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

"Öö Tiib" <ootiib@hot.ee>: May 08 03:42PM -0700

On Thursday, 7 May 2015 02:09:19 UTC+3, Norman J. Goldstein wrote:
> polymorhphism. Both options allow hiding the implementation, so that
> the main class does not need to be recompiled, should the implementation
> change.
 
For me pimpl is not comparable with polymorphism. Pimpl is opaque smart
pointer similar to FILE* in C standard library. However pimpl goes farther
from that. All "pointerness" of its envelope object is also erased. It
behaves fully by value semantics.
 
> approaches require indirection to access the implementation, and require
> storing an extra pointer to do that (polymorphism has the pointer to the
> vtable).
 
Lot of problems can be solved with extra level of indirection.
 
> keeping the same main class. I conclude that there is no point using
> pimpl unless you want to do "hot" switching of implementations.
> Other opinions about this?
 
Most places where you use pointer (or smart pointer) you can also use pimpl.
 
Information erasure behind convenient interface is the whole difference.
Pimpl can be internally polymorphic, share objects, copy on write, have
object pools or what not but it is removed information from interface.

When implementation is polymorphic then we can achieve an effect like
pimpl object changing its type during its lifetime. That effect is
not possible with normal polymorphism in C++.

> Here is code that prints "hello" using both pimpl and polymorphism.
 
I can not imagine it as a problem to solve with either. ;)
"Öö Tiib" <ootiib@hot.ee>: May 08 03:55PM -0700

On Thursday, 7 May 2015 23:02:32 UTC+3, Richard wrote:
 
> Polymorphism makes it easier to unit test code collaborating with the
> interface. Pimpl doesn't help there.
 
Pimpl can be arranged in unit-testable manner. No much need to reinvent
a wheel here. Qt framework uses pimpl extensively and has plenty of good
examples how to arrange pimpl unit-testably.
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: May 08 11:19PM +0100

On Fri, 8 May 2015 10:21:00 -0700 (PDT)
> //do something
> return std::move(t); //explicitly force t to be an rvalue
> }
 
The first approach is the correct one. Any recent compiler will use
return value optimization (which is permitted by the standard), and
construct the return value in the caller's stack frame. Although move
semantics are permitted as an optimization, it will not in fact be
used: RVO will be used instead.
 
Chris
Doug Mika <dougmmika@gmail.com>: May 08 01:00PM -0700

Hi, what would be a good book that would cover intermediate to advanced c++ thoroughly?
Victor Bazarov <v.bazarov@comcast.invalid>: May 08 04:27PM -0400

On 5/8/2015 4:00 PM, Doug Mika wrote:
> Hi, what would be a good book that would cover intermediate to advanced c++ thoroughly?
 
There is no such a thing as "a" good book. You need to compile a
library (pun intended).
 
V
--
I do not respond to top-posted replies, please don't ask
ram@zedat.fu-berlin.de (Stefan Ram): May 08 08:23PM

>Hi, what would be a good book that would cover intermediate
>to advanced c++ thoroughly?
 
»The C++ programming language« by Bjarne Stroustrup,
most recent edition.
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.

No comments: