Erlang/OTP R10B-10 has been released
Tue Mar 21 14:24:16 CET 2006
On 2006-03-21 08:54, Matthias Lang wrote:
> Another thing. A major use of the preprocessor is conditional
> compilation, e.g.
> pi() -> 3.0.
> pi() -> 3.14159.
> That can cause confusion along the lines of "am I debugging the code
> I'm looking at", but how else do you solve that problem?
since this (conditional compilation) is very difficult to manage i will
try to come up with something that is atleast different.
pi(politically_correct) -> 3.0;
pi(_) -> 3.14159.
you will need an extra variable for all functions call chains that are
> The standard advice is to put the variant code in seperate
> modules. Doing that has quite a disruptive effect on a program's
> organisation---the classic example is that you have a working system
> on hardware X and now you want to extend it to work on hardware
> Y. Your choices are now
> a) Use conditional compilation and sprinkle changes throughout
> the code. Ugly because it uses the preprocessor and because
> code gets twice as long in many seperate places. Nice because
> it's fairly easy to convince yourself that you haven't broken
> the system for X.
in the past ('85-'90) i tried this when programming in c. unfortunatly
it was only myself i convinced about not breaking X. the software i
wrote was often broken for X.
> b) Re-structure the system so that there's a layer of redirection
> ("abstraction") which takes care of the differences between X and
> Y. Nice because it avoids the preprocessor. Ugly because it's
> harder to avoid creating double-maintenance problems and ugly
> because its more likely, in my experience, to introduce bugs
> to the otherwise 'stable' X target.
after '93 i tried to put the c code for X and the c code for Y into
different source files, and link with the right verison. it worked
better for me. ie, i had less maintenance problems and less bugs in the
'stable' X target.
More information about the erlang-questions