|
|
Blitz Devel : |
From: Derrick Bass (derrick_at_[hidden])
Date: 2003-12-21 00:07:36
This is a response to some recent discussion on blitz-support, but I
think my comments are more appropriate here on blitz-dev...
On Dec 19, 2003, at 11:00 AM, Julian Cummings wrote:
> Personally, I feel that using libtool for a package with a very tiny
> library like blitz is overkill. But there was much shrieking when I
> floated the idea of abandoning it. I guess a lot of Linux users are
> very comfortable with using libtool along with autoconf/automake to
> build and install software packages. So as long as it doesn't get in
> the way, I don't mind.
> (Someone else may want to chime in here on why libtool is useful.)
>
> As for the purpose of the library, it holds instances of some global
> objects, such as the pre-defined tensor indices in namespace
> blitz::tensor.
libblitz seems to be one of the most problematic parts of Blitz,
judging from my own experiences and from the numerous problems reported
on the support list. I think it should eliminated entirely. It is small
enough that getting rid of it would not cause noticeable bloat to
people's programs or increases in compile times.
Most of the globals are not used for their values, but only for their
type, thus it is okay for there to be multiple copies, and so you can
replace them with static variables.
There are a few debugging variables whose values are important. For
those, it is possible to use the peculiarities of the C++ linker to put
global objects into the header files by making them static members of
template classes:
template<class T>
struct _dummy_class {
bool assertFailMode;
// And other globals
};
template<class T>
int _dummy_class<T>::assertFailMode;
Then wherever blitz uses assertFailMode replace it with
_dummy_class<char>::assertFailMode. (One could even use a macro to make
that less ugly, depending on one's views of the relative ugliness of
macros and weird unmotivated-looking expressions.) There will be a copy
of the variable in each object file that references it, but the linker
will ensure that only one of those makes into the final executable.
This is hacky and would require some comments in the code to explain
it, but I think that getting rid of the library would be worth it. This
technique relies only on features that are part of the C++ standard (at
least so far as I understand it), so it should be portable; however, I
have only tried it with gcc, so some testing might be in order first.
Derrick Bass