Allan Rae <[EMAIL PROTECTED]> writes:
| just another consideration). With regard to the speed arguement though,
| when using a single string there is the added costs of parsing which Lars'
| solution, FuncSlot, avoids since all argements must conform to some
| preordained order.
Yes, also note that the example implementaion of FuncSlot uses a
vector to store the strings, this is actually very effective memory
wise. (of course possible to do better, but not bad at all, especially
when you think about the added functionality you get that that you
would have needed anyway.)
| You would have done better to argue for a strstream solution in your
| original proposal so we could just add a strstream operator<< and
| operator>> for data objects like PrinterParams etc. At the time I
| was unaware of strstream and it now seems stringstream is the current
| fashion.
stringstreams are nice (or iostreams in general)
| > Anyway. Nice to see you arriving there.
|
| Strings (plural) are fine but it's how we implement the getting to and
| from strings that is important. In stream_cast<> and Lars' FuncSlot we
| finally have an alternate solution to XTL.
And it is dead simple.
The stream_cast is beeing included in the Boost library, but is called
lexical_cast there.
| We can simulate some of the capabilities of XTL using our own
| serialisation code based on stream_cast<>. This will probably prove
| adequate for most purposes but Lars' example code doesn't convince me it's
| capable of doing all the stuff XTL is capable of.
I am sure you are right, but I am not sure if this will matter a lot
to us.
| I also think we'll end
| up writing about three times as much code using stream_cast<> and FuncSlot
| as XTL would require (although it'll be less than converting everything by
| hand... perhaps).
In the case of the Minibuffer proposal, the LyXFunc/LyXAction +
FuncSlot stream_cast will be the glue and will as far as I can see not
add any bloat at all. Of course if your case is dialogs and their
binding to LyXFuncs the matter will most likely be completely
different. (and that case was not in my mind when thinging about
stream_cast and FuncSlot.)
| However, stream_cast<> has the advantage that it works
| on most if not all compilers now, whereas XTL only works on a few
| compilers now.
|
| XTL is still the better solution because it would also allow us to
| support
It is also the worse solution since it is so much more complex.
| Lars' why not just use stringstream as the parameter for dispatch()? You
| can build all the stuff you want by hand then and we can write two
| operator functions to support [de]serialising any given data object like
| PrinterParams?
primarily to keep arguments from each other. If we keep it in a stream
we will have to have a arg-delimiter. Envision a lfun like
"lyxfile-diff this is file one and file two", what are the names of
the files?
| We still don't get compile-time type-checking to match arguements to the
| requirements of a given LFUN but it's flexible.
I do not think a stream arg is more flexible, because:
...
FuncSlot fs("set-variable").arg("printer-arguments");
ostringstream os;
os << buffer.printerArgs;
fs.arg(os.str());
and then in diapatch LFUN_PRINTERARGS (after resolving in
LFUN_SET_VARIABLE):
istringstream is(fs[3]);
PrinterArgs pa;
is >> pa;
...
| We'd need a version
| number for the data so that older apps can still talk to LyX after we add
| or delete a variable from the data structure.
sure but all this could be hidden in the << and >> operators for the
structure.
| We could add the type_info
| within the operator<< like this to get some extra checking (assuming my
| imagined stream operators exist) or just use a string name:
You can get a types name by type_info<type>.name().
Lgb
