Hello All & Enea
Enea Zaffanella wrote:
Basile STARYNKEVITCH wrote:
It would be cute if the routine passed to ppl_io_set_variable_output_function could take some client data.
I think I should be missing something.
Can't you "embed" the access to this supplementary data pointer into your own variable output function? That is, you provide an output function that, when called, accesses some (possibly many) global data pointer(s), rather than a single data pointer passed as a parameter.
Wouldn't that be enough for your purposes?
Yes, except for one important thing. You suggestion requires adding a new global or static data (which I am already doing in MELT branch since one week ago, the static variable basilys_pplcoefvectp in line 8212 of gcc/basilys.c MELT branch rev144956) and that is sometimes very messy and error prone.
As a hint, in GCC everyone was doing that kind of "dirty" tricks, and the resulting code is (in that repect, and in my humble & biased opinion) hard to read, hard to maintain, and hence brittle. GCC has hundreds of static or global variables, and that is way too much (in contrast, QT has basically one global variable, the QApplication one, and I believe GTK also have few global data variables. In term of coding comfort that make a huge difference.).
As an example of why client data is practically useful, most recent window toolkits (think of GTK, FOX, or QT) have some quite systematic way of providing client data for every routine pointer.
And I am very fond of functional languages (like Ocaml; and the MELT lisp dialect is quite functional in that aspect). They teach us that what matters (ie what functional values are) is not only code (like function pointers in C are) but closures, which are exactly an elegant mixture of code and data (called closed variables or closed values in the functional way of thinking).
So of course keeping the current interface is ok (but error prone, since it requires static data, and clearing/freeing it afterwards...), but a simplistic client data machinery [like the one I suggested] would be more comfortable for your users. I could live without, since my code already does live without.
Maybe in a C++ programming style one would subclass the class Parma_Polyhedra_Library::Variable (I am not sure of that) to contain some client data. I definitely (for GCC "political reasons") want to use PPL within MELT only thru its C API ((so I won't code any C++ anyway).
Regards.
BTW: for MELT my most urgent wish is of course not the client data in ppl_io_set_variable_output_function but simply a 0.11 version (or snapshot) containing the print_ppl_*_t_to_buffer functions inside libppl_c.so! Roberto knows about that...