On Mon, Jul 21, 2008 at 7:50 AM, David Crayford <[EMAIL PROTECTED]> wrote: > Thanks Rick, comments below... > > Rick McGuire wrote: >> Standard library objects need to be used with care because of storage >> management issues. Much of the internals of the interpreter is >> implemented using objects that are allocated from the Rexx-managed >> heap. These objects need to be constructed such that they are >> compatible with that memory management system, which the standard >> library objects are not. > STL objects have associated allocator policies. I've seen this used to > create STL > containers using UNIX shared memory. It's tricky, best left in the "too > hard" basket. I take it > it's ok to use STL algortihms?
There are issues beyond just where the memory is allocated from. Any Rexx object allocated from the Rexx heap needs to be a subclass of RexxInternalObject and participate in the mark-and-sweep operations by implementing the live() and liveGeneral() methods. I think it's closer to the "not possible" basket than just merely being "too hard". I'm not sure I understand what you mean by STL algorithms. > >> As far as coding standards, a lot of the code is in transition from >> the coding standard I used in 1995 and the coding standard I prefer >> now. I don't like to get involved with the curly brace argument on >> placement and other stuff, but there are probably 3 "rules" I'd like >> to see followed: >> >> 1) Code indentation should be 4 spaces (the older code uses 2) >> 2) All if, for, while, etc. constructs should have curly braces >> (i.e., no "if (a = b) c = d;". The older code did not use that style, >> and I've been making a point of correcting this whenever I happen to >> be making changes in code that hasn't been converted yet. I will >> never object to anybody doing the same. >> 3) No had tabs. indentation should be done with spaces. >> > Great, perfectly suits my style. I use the SlickEdit editor which > introduced adaptive formatting in the > latest release. It adapts code assists to the convention it detects when > it opens the file. Brace style, indentation etc. > SlickEdit has very good support for classic REXX, including basic > context assist. Can I suggest that you add it your > list of editors that support REXX on your website. SlickEdit have > recently started to release instructions on > how to create user extensions to support proprietary languages. I'll put > this on my todo list for ooRexx. >> Other than that, I'm pretty flexible. Back in 1995, we tended to use >> line comments that had the /* and */ in specific columns. I prefer >> using the // form now. I don't see any need for changing the style >> that is there, nor should you make much of an attempt to try to keep >> the alignment. >> > On Mon, Jul 21, 2008 at 5:39 AM, David Crayford <[EMAIL PROTECTED]> wrote: >>> I've been familiarising myself with the code and have noticed that >>> ooRexx does not use: >>> >>> * The standard C++ library, iostreams, STL etc. >>> * Exceptions >>> * Generic programming (templates) >>> * namespaces >>> >>> I assume that this is due to history (ooRexx older than ISO C++), >>> performance and portability reasons. Are there any coding standards >>> or rules that I should know about? >>> >>> ------------------------------------------------------------------------- >>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >>> Build the coolest Linux based applications with Moblin SDK & win great >>> prizes >>> Grand prize is a trip for two to an Open Source event anywhere in the world >>> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >>> _______________________________________________ >>> Oorexx-devel mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >>> >>> >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >> Build the coolest Linux based applications with Moblin SDK & win great prizes >> Grand prize is a trip for two to an Open Source event anywhere in the world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> Oorexx-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >> >> > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Oorexx-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Oorexx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oorexx-devel
