Andre Poenitz <[EMAIL PROTECTED]> writes:
| > There is more to externalising than speed.
|
| Agreed. And the string solution is not even slow...
ad. the stream_cast: it is even possible to specialize this if wanted
so that stream_cast<string, string> will be a no op, as will
stream_cast<int, int>.
alos stream_cast<type, string> and stream_cast<string, type> can be
simplified:
type stream_cast<type, string>(string const & str)
{
istringstream ist(str);
type t;
ist >> t;
return t;
}
string stream_cast<string, type>(type const & t)
{
ostringstream ost;
ost << t;
return ost.str();
}
more on FuncSlot... when I first though of this it was as a direct
replacement for the string that we pass to dispatch now, it is not too
hard to create a FuncSlot that can transfere the type untranslated.
It would be a larger implementation because we would need to create an
small class hierachy for the types possible to transfere with
FuncSlot... all of these would have to have the same root class.
could also be written so that stream_cast is only needed when the type
input into the funcslot is different form the type you want out of it.
| > {
| > // can we export type_info to a stream?
| > return ss << type_info(pp) ...
|
| This is possible but not acceptable for anything external since type_info
| can/will depend on compiler and platform.
that depends on what this type_info really is, we could easyly make
it: "printerparams_version_1"
| I can see, however, no problem with your alternative 'a string name' as in
|
| return ss << "printerparam " << ...
exactly.
Lgb
