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
