[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnucap-devel] waves branch and wave copy constructor
From: |
al davis |
Subject: |
Re: [Gnucap-devel] waves branch and wave copy constructor |
Date: |
Sat, 20 Dec 2014 13:43:53 -0500 |
User-agent: |
KMail/1.13.7 (Linux/3.2.0-4-amd64; KDE/4.8.4; x86_64; ; ) |
On Saturday 20 December 2014, Felix Salfelder wrote:
> currently, there are two levels of std::map. instead of plain
> nested DISPATCHERs, a DISPATCHER<WAVE_LIST> could be more
> appropriate. i can think of functions to be implemented
> within a WAVE_LIST class, which might be complicated
> otherwise.
I see that ... WAVE_LIST is probably the best way. Let me
think about it.
> i'm not sure how explicitly disallowing implicit copies
> improves performance (who would actually copy 'by
> accident'?). but yes, it's more consistent. just some code
> needs to be changed after removing the copy constructor...
There are lots of such copies in the current implementation.
Every time the map is accessed, either in or out, something is
copied and something is deleted. With the map storing whole
objects, that means whole WAVE objects are copied every access.
It's worse than just one in, one out. There are temporaries.
For the simple types, these extra copies are often optimized
out. For complex types it can't be optimized out because it is
a real function call, and optimizers cannot look inside
functions.
This is why (one reason) the DISPATCHER stores pointers.
It's also a reason why certain functions are defined in header
files, "inline". Now the optimizer can look inside.
It's also why most gnucap classes inhibit access to the copy
constructor, by making it private and implicit. Then "clone" is
for when you really do need to make a copy.
Gnucap does not use implicitly generated copy constructors.
Even if the implicit one seems to do the right thing, it is
still better (and gnucap policy) to specify it explicitly, or
block it by making it private. That way, we know what it does,
and it is traceable (untested() macros). You can't trace code
you don't know is there.
Also, an implicitly generated copy constructor makes a shallow
copy, which may or may not be what you want. If it is specified
explicitly, we get full control of things like whether it makes
a deep or shallow copy.
To see what is a "deep" or "shallow" copy .... Suppose the
object has a pointer in it, which points to the real data. It's
allocated by "new" on construction, and deallocated by "delete"
on destruction.
A "deep" copy allocates another one every time a copy is made.
A "shallow" copy just copies the pointer.