You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@xerces.apache.org by James Berry <jb...@apache.org> on 2005/06/01 07:11:12 UTC
Re: Xerces 3.x X-Platform revision plan
Hey Axel,
On May 31, 2005, at 2:49 PM, Axel Weiß wrote:
> Am Dienstag, 24. Mai 2005 23:15 schrieb James Berry:
>
>>> In a first step, the first two of them could be collapsed to:
>>> virtual char* transcode(const XMLCh* const toTranscode,
>>> MemoryManager* const
>>> manager=XMLPlatformUtils::fgMemoryManager) = 0;
>>>
>>> (whithout changing semantics, without demanding any other code
>>> changes).
>>>
>>
>> Yes. This changes the code signature; it's compatible at the
>> source level, though not at the object code level. I did something
>> similar in the Mac transcoder: I just called the memory managed
>> version with fgMemoryManager from the non-managed version.
>>
>
> Hi James,
>
> I found the following on
> http://xml.apache.org/xerces-c/faq-contributing.html:
>
> "What are the release policies for Xerces-C++?
>
> The informal release policies for Xerces-C++ are (using a
> versioning of
> version.release.modification):
> We don't try to enforce binary compatibility between new versions and
> releases."
Our goal is:
- source compatibility within a version (major version)
- binary compatibility within a release (minor version)
So:
- We can break source compatibility in going to 3.0
> Does this actually count?
>
> I would like to discuss an issue related to the LCP transcoder class.
> Given, that we can eliminate calcRequiredSize, we quickly run into
> another problem:
>
> virtual bool transcode
> (
> const XMLCh* const toTranscode
> , char* const toFill
> , const unsigned int maxBytes
> , MemoryManager* const manager = XMLPlatformUtils::fgMemoryManager
> );
>
> From the viewpoint of using this method, it's rather impossible to
> react
> on the case that the provided buffer has not succeeded. There are two
> information items missing:
> 1. how many bytes have been filled into the buffer?
> 2. how many utf-16 words have been successfully transcoded?
> (BTW: 1. would also be very usefull in the case the transcoding has
> succeeded).
>
> So I would promote to either remove this method completely from the
> LCP
> transcoder interface, or add two call-by-reference arguments providing
> the missing information.
>
> What do you think?
It's just the LCP transcoder, so it doesn't get used a whole lot.
These routines do zero-termination of the output, so you _can_
determine how much was generated, though it costs you a strlen call.
They either succeed to transcode all the input, or they fail, so you
can also determine how much was consumed (all or nothing).
That doesn't mean I'm sticking up for the interface. I think it
sucks. But I'm not sure it gets used much anyway, or even at all. I
guess you could try changing the function signature and see what
breaks.
As for whether we should make a change here, I sort of feel like the
LCP interface is there and can be tolerated, even if it's not
perfect. Like I said, it doesn't get used much, relatively speaking
(because it's not precise...you never know quite what it means across
any platform...it's really only valid in going to and from the
command line).
You're welcome to write to the list and see what people have to say
about changing the LCP interface.
James.
> Axel
>
> --
> Humboldt-Universität zu Berlin
> Institut für Informatik
> Signalverarbeitung und Mustererkennung
> Dipl.-Inf. Axel Weiß
> Rudower Chaussee 25
> 12489 Berlin-Adlershof
> +49-30-2093-3050
> ** www.freesp.de **
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
> For additional commands, e-mail: c-dev-help@xerces.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Xerces 3.x X-Platform revision plan
Posted by da...@us.ibm.com.
> It's just the LCP transcoder, so it doesn't get used a whole lot.
> These routines do zero-termination of the output, so you _can_
> determine how much was generated, though it costs you a strlen call.
> They either succeed to transcode all the input, or they fail, so you
> can also determine how much was consumed (all or nothing).
This is the important thing to remember about LCP transcoding: It's not
used much, if at all, within the parser, so we should be careful not to
spend too much time on optimizing/redesigning something that's not on the
critical path.
> That doesn't mean I'm sticking up for the interface. I think it
> sucks. But I'm not sure it gets used much anyway, or even at all. I
> guess you could try changing the function signature and see what
> breaks.
We need to make sure that each implementation of the local code page
transcoder can support reporting what the length should have been, etc.
> As for whether we should make a change here, I sort of feel like the
> LCP interface is there and can be tolerated, even if it's not
> perfect. Like I said, it doesn't get used much, relatively speaking
> (because it's not precise...you never know quite what it means across
> any platform...it's really only valid in going to and from the
> command line).
Probably the best way to handle this is to keep the old interface,
deprecate it, and add a new overload with the improved interface, because
that maintains source code compatibility.
Thanks!
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org