Garrett D'Amore wrote:
> `
> The various GUI libraries are far less a concern, since generally
> there is little desire to mix and match libraries from different
> toolkits into the same application. Its usually fairly obvious if
> you're going to use middleware which makes use of KDE, for example.
> But the situation were are talking about here is far more subtle --
> because it potentially impacts *every* piece of C++ middleware,
> without any obvious way for the user to know which backend C++
> libraries were used.
>
> How will developer using WhizzyWidgets++ library know which C++
> library to use? And if they also want to use FancyFastNetwork
> library, which is built with a different library? (Then they are
> stuck..)
Another point here to consider: Unlike the GUI libraries, where
generally source incompatibilities *force* one to pick one library or
another, the choice of which C++ library comes down to selecting
implementations. Many consumers of the C++ library may work with either
implementation (i.e. barring use of certain unsupported features most
code should be source compatible with multiple different
implementations), and it will be incredibly difficult for consumers of
middleware to know which libraries were used underneath.
(One possible solution would be to confine libraries built against
libstdc++ into a separate "namespace" -- kind of like the various perl5
version-specific ghettos. At least then there wouldn't be too many
surprises.)
The architecture presented in this case so far is just far too
inadequate at the moment.
But then again, if all we are interested in doing is saving folks the
effort to download other components, and are becoming mere integrators,
then there is no place for architecture and we should stop discussing
things like this altogether. (And, IMO, probably stop having ARC review
at all.)
-- Garrett
