Re: [Plplot-devel] C++ class constructor question

[Phil Rosenberg]

Hi Alan

The short answer is yes use a transmit and receive function to send
the data, but no don't create a new object every time you want to
send something. The current private object is definitely the way to
go.

I should have used a transmit and receive function in the current
code. If I wasn't going to trample your uncommitted changes I would
actually do that right now. The reason is partitioning of
functionality. The job of the Memory map, as it stands is to provide a
space in memory where the wxDevice can write data. You are absolutely
correct that it would be much better to have a send and receive method
- in reality the wxDevice does not care how the data gets sent, either
via shared memory, over a network port, by writing to a file on the
disk drive or even by messenger pigeon - it just wants to send it and
sometimes get some back. By adding those functions we totally separate
out the transmission from the other stuff that wxPLDevice does. This
would mean actually we could create different classes that do the
transmission in different ways and we could use different objects as
slot in replacements if we liked.

However, if you pull out the semaphores and have wxPLDevice look after
those then we have messed up our nice separation of functionality
again. Our wxPLDevice now knows that we are communicating with
semaphores and memory maps.

So what I should have done (and this probably came from the way things
evolved and got more complicated than I expected) is created a
PLCommunicator class. Then I could have inherited from this to make a
PLMemoryMapCommunicator and all the code from wxDevice::Transmit,
should go in there. In fact if you can give me some time to do that
without stepping on your uncommitted edits then I will as I think it
will make your life easier.

Now in terms of having a default constructor that initialises
everything invalid, well there is nothing wrong with that. I don't see
how constructing a new object for every use is simpler, in fact the
opposite. I'm also not sure where exactly you will be creating your
shared memory. In PLMemoryMap? If you keep creating and destroying
your PLMemoryMap objects then you will keep scrapping and recreating
your shared memory won't you? It also seems that although you would
remove a small amount of code from PlMemory map, you instead make the
class more difficult to use, so it doesn't seem like the right choice
for me in many ways.

I hope that makes sense.

Phil


On 11 February 2017 at 21:46, Alan W. Irwin  wrote:
> Hi Phil:
>
> I have noticed the style of communications you are using between various
> classes typically involves private variables such as
>
> PLMemoryMap  m_outputMemoryMap;
>
> for wxPLDevice, a default constructors for
> PLMemoryMap that essentially sets everything relevant to invalid
> values, and no explicit use of the constructor that does valid
> initialization for PLMemoryMap from within wxPLDevice.  (Instead an
> explicit create method is called to do the required valid
> initialization.)
>
> Would there be anything wrong with dropping that private variable,
> dropping the default invalid constructor, dropping the create method,
> creating an instance of PLMemoryMap (with correct explicit valid
> constructor with a mustExist argument to decide if you are going to
> reuse external memory locations from a previously initialized
> instance), and using the methods of that instance when you need them?
>
> That latter simplified approach is the one I have tentatively adopted
> for the new PLTwoSemaphores class I have just implemented (see commit
> cd13d65).  The (only) constructor checks that the argument values
> corresponding to the addresses of the two semaphores are non-NULL, and
> then the internal private variables of the instance that correspond to
> those two addresses are updated.  If mustExist is true, nothing more
> is done, but if mustExist is false, then sem_init is called for each
> of those pointers. The (only) destructor for the PLTwoSemaphores class
> calls sem_destroy for each of the (internal) pointers and sets those
> internal pointers to NULL.  And all other methods of PLTwoSemaphores
> that use those internal pointers check that they are non-NULL.
>
> So far the two-semaphores implementation is incomplete so I have only
> tested the new PLTwoSemaphores class with a build (with the g++
> compiler finding no issue with it).  Do you anticipate I will be
> running into trouble later on with the above simplified constructor
> approach once I start to use PLTwoSemaphores class instances (e.g., in
> the arguments for the currently empty PLMemoryMap::sendBytes and
> PLMemoryMap::receiveBytes methods?
>
> If it turns out you do believe the current simplified PLTwoSemaphores
> constructor approach will work OK, should we also switch to that
> simplified approach everywhere else (e.g., to handle wxPLDevice's use
> of PLMemoryMap)?
>
> Alan
> __
> Alan W. Irwin
>

[Plplot-devel] C++ class constructor question

[Alan W. Irwin]

Hi Phil:

I have noticed the style of communications you are using between various
classes typically involves private variables such as

PLMemoryMap  m_outputMemoryMap;

for wxPLDevice, a default constructors for
PLMemoryMap that essentially sets everything relevant to invalid
values, and no explicit use of the constructor that does valid
initialization for PLMemoryMap from within wxPLDevice.  (Instead an
explicit create method is called to do the required valid
initialization.)

Would there be anything wrong with dropping that private variable,
dropping the default invalid constructor, dropping the create method,
creating an instance of PLMemoryMap (with correct explicit valid
constructor with a mustExist argument to decide if you are going to
reuse external memory locations from a previously initialized
instance), and using the methods of that instance when you need them?

That latter simplified approach is the one I have tentatively adopted
for the new PLTwoSemaphores class I have just implemented (see commit
cd13d65).  The (only) constructor checks that the argument values
corresponding to the addresses of the two semaphores are non-NULL, and
then the internal private variables of the instance that correspond to
those two addresses are updated.  If mustExist is true, nothing more
is done, but if mustExist is false, then sem_init is called for each
of those pointers. The (only) destructor for the PLTwoSemaphores class
calls sem_destroy for each of the (internal) pointers and sets those
internal pointers to NULL.  And all other methods of PLTwoSemaphores
that use those internal pointers check that they are non-NULL.

So far the two-semaphores implementation is incomplete so I have only
tested the new PLTwoSemaphores class with a build (with the g++
compiler finding no issue with it).  Do you anticipate I will be
running into trouble later on with the above simplified constructor
approach once I start to use PLTwoSemaphores class instances (e.g., in
the arguments for the currently empty PLMemoryMap::sendBytes and
PLMemoryMap::receiveBytes methods?

If it turns out you do believe the current simplified PLTwoSemaphores
constructor approach will work OK, should we also switch to that
simplified approach everywhere else (e.g., to handle wxPLDevice's use
of PLMemoryMap)?

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel