Loading ...
Sorry, an error occurred while loading the content.
 

RE: LINKED_LIST

Expand Messages
  • David Broadfoot
    A class rename can be accommodated without really breaking all the apps. A filter could automatically update the name in all SE source apps. I think that ISE
    Message 1 of 47 , Jul 1, 1999
      A class rename can be accommodated without really breaking all the apps. A
      filter could automatically update the name in all SE source apps. I think that
      ISE have taken that approach before. (Also, there are other ways of
      accommodating class renaming.)

      But it's a pity that the same class name is reused with a different interface in
      the first place without first checking what VE, ISE and HA have done already.
      This is a sure way to inhibit portability - and you can't blame ISE for that
      when they (presumably) were first to come up with an Eiffel LINKED_LIST class
      interface.

      I guess that copyright restrictions at the time preventing the use of ISE's
      Linked List interface even if the implementation was clean-roomed. Something
      like Sun's Community Source Licensing Principles might be good for Nice and the
      language standard. It dictates that interfaces remain in the public domain even
      if the implementation is proprietary. See
      http://www.sun.com/981208/scsl/principles.html

      So, lack of co-operation prevents any standardisation of even such basic library
      elements that C++ enjoys with the STL. It's not very encouraging.

      David Broadfoot
      Synax Systems
      Sydney, Australia


      > -----Original Message-----
      > From: hutch@... [mailto:hutch@...]On Behalf Of
      > hutch@...
      > Sent: Thursday, 1 July 1999 5:55
      > To: roger@...
      > Cc: smalleiffel@...
      > Subject: Re: LINKED_LIST
      >
      [snip]
      > So, it is better to break all the applications written in SE?
      >
      > Bob
      >
    • Olivier Zendra
      ... (Eiffel) Objects allocated on the Eiffel side are managed by the (SmallEiffel-generated) GC. Objects (actually structures) malloc ed on the C side have to
      Message 47 of 47 , Jul 4, 1999
        Andrew Reilly wrote:

        > As another poster mentioned, mixing the SmallEiffel GC with the
        > C++ malloc/new is probably a much larger problem. How does this
        > work with C code now? (You can tell I haven't actually managed
        > to do any significant work in SmallEiffel yet: still collecting
        > the bits and reading...)

        (Eiffel) Objects allocated on the Eiffel side are managed by the
        (SmallEiffel-generated) GC.
        Objects (actually structures) malloc'ed on the C side have to be freed
        on the C side as well .

        --
        Olivier ZENDRA E-mail: zendra@...
        LORIA - NANCY - FRANCE http://SmallEiffel.loria.fr
      Your message has been successfully submitted and would be delivered to recipients shortly.