From: Andrew R. <an...@co...> - 2003-08-22 14:28:12
Attachments:
patch-c++-5.2.1
|
I make frequent use of the C++ plplot bindings, however they seem to be slipping behind the C API. Attached is a patch against 5.2.1 to add in C++ api calls for plarrows, pllightsource, plsurf3d, pl_setcontlabelparam and pl_setcontlabelformat. The patch also adds a new plstream constructor which allows the background colour to be set. To my mind the current plstream implementation is slightly flawed. Currently the plstream constructor is responsible for calling plinit. This means that any functions such as plsdev that need to be called before plinit also need to be called in the constructor. This requires a large number of different constructors to cope with all the various combinations of options. Currently several aren't accessible at all. I'm not sure what the best solution would be. Do other people have ideas on this? Does anyone else actually use this? Regards, Andrew |
From: Rafael L. <lab...@ps...> - 2003-08-22 18:28:53
|
* Andrew Ross <an...@co...> [2003-08-22 13:17]: > I make frequent use of the C++ plplot bindings, however they seem > to be slipping behind the C API. Attached is a patch against 5.2.1 > to add in C++ api calls for plarrows, pllightsource, plsurf3d, > pl_setcontlabelparam and pl_setcontlabelformat. > > The patch also adds a new plstream constructor which allows the > background colour to be set. Thanks for your patch. > To my mind the current plstream implementation is slightly flawed. > Currently the plstream constructor is responsible for calling plinit. > This means that any functions such as plsdev that need to be called > before plinit also need to be called in the constructor. This > requires a large number of different constructors to cope with all > the various combinations of options. Currently several aren't > accessible at all. I'm not sure what the best solution would be. Do > other people have ideas on this? Does anyone else actually use this? From the cvs log, the last time when the C++ bindings where actively developed was over seven years ago. The bindings are not dead though, since tweaks have been committed steadily on plstream.cc. -- Rafael |
From: Maurice L. <mj...@ga...> - 2003-08-23 19:32:46
|
Andrew Ross writes: > To my mind the current plstream implementation is slightly flawed. > Currently the plstream constructor is responsible for calling plinit. > This means that any functions such as plsdev that need to be called > before plinit also need to be called in the constructor. This > requires a large number of different constructors to cope with all > the various combinations of options. Currently several aren't > accessible at all. I'm not sure what the best solution would be. Do > other people have ideas on this? Does anyone else actually use this? I agree, this was the wrong way to go. The constructor should've created the stream but left device initialization for an init() method, since as you say there are many options one might reasonably set before device initialzation is done. I don't know any way out of this situation other than breaking backward compatibility. :( As it stands, AFAIK there is very little use of the C++ bindings by the core developers. -- Maurice LeBrun Lightspeed Semiconductor Corp |
From: Maurice L. <mj...@ga...> - 2003-08-25 12:13:48
|
Maurice LeBrun writes: > Andrew Ross writes: > > To my mind the current plstream implementation is slightly flawed. > > Currently the plstream constructor is responsible for calling plinit. > > This means that any functions such as plsdev that need to be called > > before plinit also need to be called in the constructor. This > > requires a large number of different constructors to cope with all > > the various combinations of options. Currently several aren't > > accessible at all. I'm not sure what the best solution would be. Do > > other people have ideas on this? Does anyone else actually use this? > > I agree, this was the wrong way to go. The constructor should've created the > stream but left device initialization for an init() method, since as you say > there are many options one might reasonably set before device initialzation > is done. I don't know any way out of this situation other than breaking > backward compatibility. :( > > As it stands, AFAIK there is very little use of the C++ bindings by the > core developers. To clear up my position on the issue: in this case, I can see breaking backward compatibility by requiring users to first call the plstream constructor and then running an init() method to initialize the device. If you wanted to make this change I wouldn't be against it. -- Maurice LeBrun Lightspeed Semiconductor Corp |
From: Andrew R. <an...@co...> - 2003-08-24 20:38:48
|
On Sun, Aug 24, 2003 at 02:24:16PM -0500, Maurice LeBrun wrote: > Maurice LeBrun writes: > > To clear up my position on the issue: in this case, I can see breaking > backward compatibility by requiring users to first call the plstream > constructor and then running an init() method to initialize the device. > If you wanted to make this change I wouldn't be against it. I don't particularly like the idea of breaking compatibility, but I agree that it may be necessary in this case. It would also bring the C++ bindings more into line with the Java bindings which would be a good thing. If there are no strong objections to this I will rustle up a patch to make the necessary changes. As suggested by Alan I am also going to write C++ versions of the examples to test the interface. I shall report back to the list on my progress. Regards Andrew |