|
|
Blitz Devel : |
From: Julian Cummings (cummings_at_[hidden])
Date: 2003-01-15 22:53:35
Hi Tom,
Tom Hilinski wrote:
> I am in the process of porting blitz++ 0.6 to the Borland C++ Builder 6
> patch 2 compiler. Several issues have come up which are not specific to the
> Borland compiler (and some others that are, but I won't discuss them here.)
> Some are minor, a couple of others are significant.
>
> With the changes I've made, most of the tests I've tried in the examples and
> testsuite directories run ok. For some ofthe programs which don't run, I
> don't know if the code is correct or not, and haven't taken the time to
> debug them (e.g., testsuite/qcd.cpp).
>
> I now have a config.h and a set of BCB6 project files should any want them -
> I'll be glad to send them along.
I am thinking that we should add an "ide" directory with subdirectories
for different IDE's such as BCB and MSVC and make some project files
available in the Blitz distribution. If it's not too much trouble, perhaps
you could submit your BCB6 files via the SourceForge.net website, and
then we could add this to the repository.
> Issues I've fixed include the following:
>
> ---------------
> (1) blitz.h
> Modified the following to undef for use in MS Windows until Windows threads
> are implemented.
>
> #ifdef BZ_THREADSAFE
> #if defined(__WIN32__) || defined(_Windows) || defined(__CONSOLE__)
> // Microsoft Windows threads: not implemented
> #undef BZ_THREADSAFE
> #undef BZ_THREADSAFE_USE_PTHREADS
> #else
> // use pthreads.h
> #define BZ_THREADSAFE_USE_PTHREADS
> #endif
> #else
> // not thread-safe
> #undef BZ_THREADSAFE_USE_PTHREADS
> #endif
Sounds fine to me.
> ---------------
> (2) memblock.h
> Commented out the extraneous include of pthreads (inclusion should be
> controlled in only place - e.g., blitz.h):
>
> // already handled in blitz.h
> // #ifdef BZ_THREADSAFE
> // #include <pthread.h>
> // #endif
OK, although there's no harm done here. I have some misgivings
about the one-stop shopping header file blitz.h being sprinkled into
every other Blitz header file if it is going to be pulling in lots of other
stuff. In this particular case, blitz.h has to include pthread.h in order
to make the BZ_MUTEX macros work.
> ---------------
> (3) vector.h, veciter.h
> Implemented several operators and Vector::end().
> Built a test program to try them out.
Sounds good. I'll have a look at what you've done here.
> ---------------
> (4) examples/ and testsuite/
> Modified some of the examples as necessary for them to work correctly: e.g.
>
> examples/matmult.cpp
> original:
> A = 1.0f / (i+j-1);
> new:
> A = 1.0f / blitz::cast<float>(i+j-1);
Why is this a necessary change? Doesn't your compiler know about
promotion rules for standard built-in types float and int? If it's possible,
perhaps you could provide the diffs for all the changes you have made
to these testsuite and example codes. These are definitely not
compiler-independent problems you are seeing here. These test codes
have already been checked against most other compilers besides BCB.
> ---------------
>
> Issues I feel are significant and should be addressed include the
> following:
>
> (1) Use of the C assert macro and stdlib exit() lead to memory leaks since
> destructors are not necessarily called. These should all be replaced by
> throw. (We have an macro to replace assert which throws an exception, and
> can give this to the blitz project, if wanted.)
This can be done fairly easily by modifying the bzdebug.h header file,
which defines the BZASSERT macro and its friends that get used
throughout the source code. I am disturbed to see that there is a
BZ_THROW macro appearing in blitz.h, but it is simply defined as
nothing. What should be there is code that defines BZ_THROW as
throw if BZ_EXCEPTIONS is defined (meaning we have C++ exceptions
enabled). Then we could make the various BZASSERT macros equivalent
to BZ_THROW if BZ_EXCEPTIONS is defined, else leave it as assert.
I agree that throwing an exception is cleaner assuming this option is
available. I'd be happy to see your replacement assert macro.
> (2) Remove the directive "using namespace std" in the header file blitz.h.
> As you know, in order to maintain control over namespaces, "using namespace"
> usually should never be placed in a header file. Rather, each implementation
> file should be allowed to define the scope that is active within that file.
This is already on the TODO list. There is one bit of nastiness that I know of
having to do with the scope of std math functions and blitz Array functors.
The issue is getting things like std::sqrt(A) to work, where A is a blitz Array
of doubles. You just have to be very careful in the expression template code.
(!)
But this issue is high on my wish list, too. I will try to attack this one
soon.
> (3) Replace "cout" and "cerr" with stream object references defined at
> runtime. If the blitz library is used in a program in which cout and cerr
> are not captured, then the output is never seen. A GUI is typical example in
> which the output stream usually is not cout or cerr, but one provided by
> the GUI to capture the output and write it to a window.
Are you suggesting something like a global Blitz std::ostream reference that
is initialized by std::cout but can be modified to refer to some other
std::ostream
object that the user provides? That seems like a good idea. This reference
could be wrapped in a small object and declared in globals.cpp using the
special _bz_global macro.
> Well, its easy to suggest lots of work for other folks, though since my
> group appears to be very interested in Blitz++, I may do some these my
> self - our timeline is very short (sigh). Please send along any suggestions
> you care to regarding these issues.
These are all good suggestions. Any of these items you care to tackle
would be much appreciated. Sending patches or additions via the
sourceforge.net website is preferred, so the submissions will at least be
logged. It may take time for someone to test and approve submissions,
but they should eventually find their way to the next release.
Regards, Julian C.
-- Dr. Julian C. Cummings E-mail: cummings_at_[hidden] California Institute of Technology Phone: 626-395-2543 1200 E. California Blvd., Mail Code 158-79 Fax: 626-584-5917 Pasadena, CA 91125