ANSI vs. C++

*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/

Georg Mischler wrote:

*phew*, what have I started here?

... a rather fruitful and long awaited discussion.

I really hope we're not scaring any non-developers away from this
general purpose list with such a highly technical discussion!

--admin mode on
radiance-online just got the mailing list "radiance-dev" added, to serve
further discussions amongst those so inclined.
--admin mode off

I happily back Georg's comments on C++ being slower (at compile time
and, apparently, running), non reciprocal to ANSI-C and not as
standardized as ANSI-C is, plus the fact that "object oriented"
programming is possible with, yet not inforced by ANSI-C.
As example, system dependancy in a job distributing system for
HP-UX,Linux,IRIX and SUN-OS was, thanks to Posix, limited to a small
number of system calls. Approx 200 lines total out of 4500 are ifdefed
and fit into two seperate files (file locking and getting system
parameters like load, swap space, physical ram etc.).
Compared with compiling stuff like the URT kit a decade ago, systems
have become more standardized. Is GNU's autoconf really needed for a
raytracer, which is supposedly not close to the system ? (fork&flock
aside)

Thoughts on a rewrite were founded on the limited and cumbersome
"interface" for extending the core rendering. My line of thought runs
weirdly like this:

···

--
Radiance has been used to solve light problems other programs can't
handle (in the early days its arbitrary geometry was better than the
than solely available box-oriented illumination programs, it's surface
description is more realistic than _todays_ Lightscape, the ambient
cache was a big step forward, etc. ). That top-notch position is one
reason people use it.

As much as I appreciate a broad use of it in daily usage for problems
which aren't driving the algorithms to its limits (and my highest
respect to those using it for that, the lighted world would be a much
better place if people use 20% of Radiance capabilites early enough in
the architectural planning process), is the rest of the
rendering/light-calculating software industry in a non-dormant state.

Algorithms for global illumination have been progressing since Greg
introduced the ambient cache into Radiance, and it would be quite nice
to extend Radiance more easily. Validation is of top priority (that's
what I help Roland Schregle to do at FhG-ISE), and the number of
extensions ideas is less than a handful (given we find people to do it).
Yet without a clearer interface not only is the effort reproduced for
each project, but different projects potentially cludge (as happens with
Roland Schregle's photon-map and Christopher Reinhart's yearly
simulations). Furthermore, not without reason we may expect advances in
commercial programs, which may (I have to grasp for the heart pills...)
force us someday to use a closed-software, non-tracable package just
because Radiance can't do what the client expects and gets from other
packages.

However, that interface is not changed solely by prototyping functions.
Doing more than that risks new bugs- well, we'll get them out. Maybe
there's a core structure between just-prototypes and a full rewrite ?
--

- Moving 'legacy' programs into a seperate package- fine.
- step-by-step conversion- yeap.

-Peter

--
pab-opto, Freiburg, Germany, www.pab-opto.de