gnucap-devel
[Top][All Lists]
Advanced

[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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]