*phew*, what have I started here?
I really hope we're not scaring any non-developers away from this
general purpose list with such a highly technical discussion!
If ANSI C created portability problems at the time it was
introduced (I don't think it still does today, btw.) then
C++ will be a true nightmare in comparison. Before switching
an existing codebase over to C++ you need several *very* good
reasons, and I can't personally think of even one good reason in
this case. I am really surprised that Greg reports about good
porting experiences with C++, as pretty much everybody else I
talk to warns me about exactly the opposite. The most experienced
C++ developers I know invariably call the language "a bloody mess".
As a more technically solid argument: Remember that you can
always call foreign C code from your C++ programs, but if you
want to call C++ from C, then the only way to do so is through
shared libraries, which opens yet another can of worms in terms
of portability and functional limitations. The performance issues
with a more complex language have already been mentioned. This is
no surprise, as there has gone around 20 years of experience into
C compiler technology, and only a fraction of that into any C++
compiler. This alone would be alarming, even when ignoring that
C++ is at least an order of magnitude more complex to compile,
and the standard has been in flux until very recently.
There are much simpler ways to make Radiance more modular than it
currently is, without throwing out all the work that has already
been invested in it. ANSIfication will be a great step into that
direction, forcing all function prototypes into header files.
As a second step, if we then manage to encapsulate the global
variables of each functional unit into a struct that can get
passed around as a pointer, then we might already have all the
modularity we need, without introducing anything that would
prevent Greg from still recognizing his own programs.
As a principle, I'm a big fan of object oriented programming (90%
of my own work is object oriented), but neither is C++ a good
object oriented language, nor do I think that object orientation
would be of any benefit for this specific task. The core
implementation of Radiance has to remain as simple as possible,
and using ANSI C is one of the factors that will keep it simple.
I really can't see how the introduction of "mindbending
abstractions" would be of any benefit at this level.
I do support the idea of relegating some parts of the system to
"legacy" status. I guess this would only put a formal label on
those modules that haven't been touched for several years anyway.
Maybe this label could simply result in putting them into a
seperate and optional support package.
It could also be interesting to consider another implementation
framework for all the helper programs circulating around the
actual Radiance core. Some of the csh scripts have been rewritten
in C for Windows, with limited flexibility and robustness. My
personal favourite language for this kind of task would be Python
(with some parts already existing). Note that such a more
portable reimplementation of individual small programs can be
done one by one, and there's no problem in keeping the old
versions around as long as necessary.
The problem of platform specific code variations is actually
independent from the ANSI conversion. In part, the ANSI standard
was supposed to reduce those incompatiblities, but succeeded in
that point only to a certain degree. I have no experience with
GNU autoconf myself, but maybe that would be a reasonable way to
eliminate the need to actually know which platform has what kind
of quirks. The configure scripts generated by autoconf simply
test the target machine and set the right compile variables
automatically. Again, this will probably have to be a step by
step replacement effort, but I think it would be worth it in the
long run. In the end, the #ifdefs in the code won't be about
specific OSes anymore, but simply about feature variations in the
available APIs.
Thanks for mentioning the Windows issue! The code of Radiance for
Windows includes some changes in the way how the stored ambient
values are accessed, which apparently were written for a
completely different platform. As far as I understand, those
changes are responsible for a large part of the performance
improvements that can be observed under Windows. I must admit
that I didn't find the time yet to have a look at the code of
3R4, so I have no idea whether it already includes the same
modifications. If not, then it might be a good idea to keep them
around during the merge, although that might make the task quite
a bit more involved.
Ignoring this aspect, the merge of the core functionality will
be relatively straightforward. The Windows code base is not very
clean (there are several conflicting compatiblity libraries in
use), so most of the result should probably be based on the unix
code. There are a number of details involving line endings in
text files and other differences between the systems where
Radiance needs to be more tolerant in the input it accepts, but I
have already fixed most of those for the binaries included in
Rayfront. I don't expect any major obstacles in porting those
fixes back to 3R4, especially after ANSIfication. The GUI based
programs are a different problem that needs to be tackled
seperately.
-schorsch
···
--
Georg Mischler -- simulations developer -- schorsch at schorsch.com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/