On Fri, Sep 12, 2008 at 06:37, Tony Balinski <[EMAIL PROTECTED]> wrote: > Quoting Bert Wesarg <[EMAIL PROTECTED]>: > >> Tony, >> >> this is probably a better solution than what I see in your current >> macro.c with the MACRO_BUILT_IN_IMPL() >> >> I.e. put all these MACRO_BUILT_IN_IMPL() into a new file and than >> include this with a appropriate MACRO_BUILT_IN_IMPL() definition. > > As you did with the interpreter ops? I don't know. The advantage of the > separate file approach is that compilers with low limits on macro expansion > can cope. I don't know how many there are still out there (suspect older OSs - > VMS, MVS, older SunOSs). The disadvantage (or rather aesthetic bother) is the > creation of a separate header file which (1) countains references to static > functions (true for interpret and macro) and (2) is only included by one file > (true for macro). Better IMO would be to split out the macro.c file into > separate "functional modules" - but I like others before simply keep in > adding! So I prefer the way I've done things (no new file) but recognise that > your way may be better. Either way, the X macro technique does make > maintenance easier, don't you think? Sure, thats why I did it. I think the macro.c split-up into functional modules could go hand-in-hand with the macro definition consolidation. I.e. a macro_<module>.c file the implmentation and a macro_<module>.h file with the corisponding MACRO_BUILT_IN_IMPL() lines.
BTW: I think the interpret.c file needs a out-factoring, too. At least the sparse array implementation should go into a new file, string handling possibly too. Split compiler and interpreter part. And lastly the debug code. Have a nice day. Bert > > Tony > -- > NEdit Develop mailing list - [email protected] > http://www.nedit.org/mailman/listinfo/develop > -- NEdit Develop mailing list - [email protected] http://www.nedit.org/mailman/listinfo/develop
