Alberto Massari wrote:
Hi David,
At 08.45 24/07/2007 -0700, David Bertoni wrote:
Scott Cantor wrote:
Another point regarding this is that when you use native types,
people glue
APIs and components together based on the fact that both APIs use those
types. Then you have a brittle contract because neither component
*meant* to
promise that they would work together through the native type. Using a
typedef prevents people from overestimating what they can combine
together
safely, since it requires a cast.
Wow, I didn't realize I would create so much controversy here! ;-)
I have to agree with most others that the distinction between the size
of a "memory buffer" and the number of items in a container seems
arbitrary.
Also, the "length" of a UTF-16 string in Xerces-C, which is now
expressed in XMLSize_t is _not_ the size of a memory buffer. Rather,
it is the number of UTF-16 code units, which doesn't seem much
different to me than the number of attributes in a document, or the
number of items in a container. After all, isn't it all about
"counting" things?
Well, every number is expressing a "count" of something ;-)
Yes, that's exactly my point.
What I have in mind could be expressed also in this way: a
size_t/XMLSize_t has a meaning only when given a starting address, i.e.
it's part of a tuple (void*, size_t), while an unsigned int/unsigned
long can be treated as a standalone number, i.e. X attributes, Y lines.
Although I understand the distinction you're making, I don't think it will
even be remotely obvious to users.
Finally, I have to agree with Scott that a typedef would be better.
You've no idea the number of changes I had to make in Xalan-C for
compatibility with the Xerces-C changes to XMLSize_t. Luckily, about
5 years ago, we started using typedefs extensively, or I would have
had to make many more changes.
Switching from philosophical to practical (not that being philosophical
is necessary a bad thing), is this a request to add new typedefs?
E.g.: XMLCount_t, XMLLineCol_t, others...?
What about those APIs that currently return 'int' because they use -1 to
signal 'not found'?
Well, I would be more in favor of consistency in the APIs, so I would
prefer XMLSize_t be used for "n" lines or "n" attributes, etc...
As for the use of int in the XMLString interface, I think it's a bad idea.
If we're using XMLSize_t for the length of null-terminated UTF-16 strings
in the SAX APIs, we should use XMLSize_t in the XMLString class. To signal
"not found," we can do what the std::string class does, and define a value
that indicates the condition. In fact, we can make that value compatible
with -1, so existing code won't break. Xalan-C's XalanDOMString class does
just that:
class XALAN_DOM_EXPORT XalanDOMString
{
public:
...
#if defined(XALAN_INLINE_INITIALIZATION)
static const size_type npos = ~0u;
#else
enum { npos = ~0u };
#endif
As long as we're going through the pain of changing some of the interfaces,
we really should just bite the bullet and change them all. In fact, I
remember a debate we had on the list more than a year ago that talked about
changing all of the unsigned int types to use size_t. I was opposed to it
because it caused lots of turbulence, but now that we've started down that
path, I really feel we should go all the way.
Thanks!
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
