xerces-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Roddey <drod...@charmedquark.com>
Subject Re: Bugs and Compile Problems in 1.4.0
Date Sun, 04 Feb 2001 01:00:40 GMT
> > The separation isn't that clean. Some transcoders are quite useable on
> > multiple platforms. And one at least, the in memory one, is useful on
> > every platform I think.
> Can the dead code be moved out?
>

There shouldn't be more than a handful of them, but sure they could be
removed. Its just not a big priorty relative to a lot of other things I
guess.

> Can the platform independant code be seperated from the platform specific
> code and headers?
>

It already mostly is. If its in a sub-directory under utils/platforms, then
its platform dependent. The only other possible ones are the other
subdirectories under utils/*. Everything else is platform independent. Given
the work it would require to do some ultra-strict isolation, relative to
just putting a readme in that directory that explains the issues, I'm not
sure its worth it.

> Can the code that applies to multiple platforms but not universal indicate
> which platforms it supports so platform specific code can be provided only
> when needed.
>

I'm not sure it would achieve what you are looking for. Think about it.
Either the platform is already supported by the parser, in which case the
build infrastructure is there. Else, you are porting to a new platform, in
which case lots of documentation about what the existing bits will compile
on wouldn't probably have helped you a lot, since what you have to figure
out is what to use on the new platform, which is by definition not going to
be documented, right?

I'm not arguing against more documention, since you can never have too much
of course. But, if you read the FAQs carefully and ask a few questions
before starting a new port (particuarly since somene else may have already
done it), you'd get a lot further anyway.

> Also, Is it reasonable to seperate the header and c++ files from each
other?
>

Not in my opinion, no.

> I also noticed some static variables in the header files. Shouldn't they
be
> in the C++ files so the data from the header files doesn't need to be
linked
> into the executable?
>

No, they just shouldn't be static. This was caught a few weeks ago and
already fixed.

> I think it is worth having a discussion about these issues to get other
> opinions.
>

You can, though much of this has been gone over ad nauseum long ago. But
everyone is free to express what they think should be done. Of course, old
timers like me are also free to try to shout you down because we sometimes
feel like the stability and simplicity of the code is paramount for long
term viability.

Everyone who shows up on this list often has a lot of nice ideas, but in
many cases they are designed to make the world look like that person wants
it to look, and to deal with issues that person specifically has. And
sometimes people have good ideas and they are adopted. But the Xerces code
base runs on a wide variety of platforms and compilers and so it sometimes
must take certain hits the in level of slickness and the use of fancy
language services and such. Use of C++ namespaces is one such contentious
issue.

--------------------------
Dean Roddey
The CIDLib C++ Frameworks
Charmed Quark Software
droddey@charmedquark.com
http://www.charmedquark.com

"We're gonna need a bigger boat"



Mime
View raw message