On Jun 18, 2004, at 10:43 AM, Adam Heinz wrote:
I see that are both LCP and non-LCP are implemented using the same TEC structures (transcoders), but I meant more in an object hierarchy sense -- since the core implementation is similar, why not build one transcoder that fulfills both LCP and non-LCP interfaces?
Actually, in the head revision anyway, you should see that the Mac LCP transcoder uses no TEC stuff directly...it calls into mTranscoder (an object of type XMLTranscoder) to do all transcoding.
I implemented the LCP transcoder in terms of a has-a relationship to XMLTranscoder, rather than an is-a (inheritance based) relationship. This ends up being better for this case, since the choice of XMLTranscoder can be a runtime, rather than compile-time, decision.
I guess the generic LCP transcoder adapter that I built could be rolled back into the base XMLTranscoder class, giving each XMLTranscoder free acces to the additional interfaces from LCP transcoder. Perhaps that's what you meant.
I was hoping to create a non-LCP transcoder, but be able to use
UINT calcRequiredSize(char*) or XMLCh* transcode(char*). Right now I'm using
a dog stupid method of allocation; four times as many characters as
the input string.
I think you could do this given the classes in the Mac transcoder. Just instanciate a MacLCPTranscoder (which actually isn't Mac-dependent at all), passing in the desired XMLTranscoder. You can then call calcRequiredSize to your heart's content.
James
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
