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

Re: [eiffel-nice-language] STRING.resize

Expand Messages
  • Ulrich Windl
    Oops, sorry, I used the wrong group (ment for library ). Please forgive me! Ulrich
    Message 1 of 3 , Jun 10, 2002
    • 0 Attachment
      Oops, sorry, I used the wrong group (ment for "library"). Please
      forgive me!

      Ulrich

      On 11 Jun 2002, at 6:39, ujmw2001 wrote:

      > Hello,
      >
      > I'm working at EIffel/C interfaceing at the moment, and there are two
      > things for class STRING, I'd like to mention:
      >
      > When returning an arbitrary byte string from C to Eiffel, the routine
      > "from_external" that SmallEiffel offers is rather useless. So I used
      > CECIL to access two features from C, namely "resize" and "put". Then
      > form C I first resize the string object to the proper length, then I
      > put the characters in.
      >
      > Unfortunately we could not decide to standardize resize in 2001.
      >
      > So for any specification I'd like to see something like
      >
      > resize(size : INTEGER) is
      > -- change the storage allocation for the character stream to `size'
      > require
      > valid_size: size >= 0
      > ensure
      > size_set: count = size
      > capacity: capacity >= size
      >
      > The problem that arises from "size < count" could be handled with a
      > force flag: "not force and size >= count or else force"
      >
      > Better ideas?
      > Regards,
      > Ulrich
      >
      >
      >
      >
      > ---------------------------
      >
      > http://www.eiffel-nice.org/
      >
      > --------------------------
      >
      > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
      >
      >
    • Arno Wagner
      ... The problem with from_external is that is does not create an Eiffel string, but rather an access-object for the c-string. But there is
      Message 2 of 3 , Jun 11, 2002
      • 0 Attachment
        On Tue, Jun 11, 2002 at 08:43:36AM +0200, Ulrich Windl wrote:
        > > Hello,
        > >
        > > I'm working at EIffel/C interfaceing at the moment, and there are two
        > > things for class STRING, I'd like to mention:
        > >
        > > When returning an arbitrary byte string from C to Eiffel, the routine
        > > "from_external" that SmallEiffel offers is rather useless. So I used
        > > CECIL to access two features from C, namely "resize" and "put". Then
        > > form C I first resize the string object to the proper length, then I
        > > put the characters in.

        The problem with "from_external" is that is does not create an
        Eiffel string, but rather an "access-object" for the c-string.
        But there is "from_external_copy", that does the job. If I
        remember correctly it was the result from a complaint about
        the nonavailability of a way to make a "clean" copy of a
        c-string.

        > > Unfortunately we could not decide to standardize resize in 2001.
        > >
        > > So for any specification I'd like to see something like
        > >
        > > resize(size : INTEGER) is
        > > -- change the storage allocation for the character stream to `size'
        > > require
        > > valid_size: size >= 0
        > > ensure
        > > size_set: count = size
        > > capacity: capacity >= size
        > > The problem that arises from "size < count" could be handled with a
        > > force flag: "not force and size >= count or else force"

        What exactly would be the reason for "resize"? External access only?
        It might be better to hide this from the user! In addition I see no
        reason at all for a feature "size". IMO the external interface should
        offer "count" and the "suggested_capacity" as parameter in creation,
        and nothing else. If we introduce "capacity" and "size" we either
        disallow, e.g., support for sparse strings, compressed strings and
        other implementational options. Or these features will have no impact
        on the internal representation, making them rather useless.

        Maybe I just did not get your point, please clarify...

        Regards,
        Arno
        --
        Arno Wagner, Communication Systems Group, ETH Zuerich, wagner@...
        GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F
        ----
        For every complex problem there is an answer that is clear, simple,
        and wrong. -- H L Mencken
      • Ulrich Windl
        Hi, from_external_copy definitely lacks the explicit length needed for transparent character streams! Regards, Ulrich
        Message 3 of 3 , Jun 11, 2002
        • 0 Attachment
          Hi,

          from_external_copy definitely lacks the explicit length needed for
          transparent character streams!

          Regards,
          Ulrich

          On 11 Jun 2002, at 16:27, Arno Wagner wrote:

          > On Tue, Jun 11, 2002 at 08:43:36AM +0200, Ulrich Windl wrote:
          > > > Hello,
          > > >
          > > > I'm working at EIffel/C interfaceing at the moment, and there are two
          > > > things for class STRING, I'd like to mention:
          > > >
          > > > When returning an arbitrary byte string from C to Eiffel, the routine
          > > > "from_external" that SmallEiffel offers is rather useless. So I used
          > > > CECIL to access two features from C, namely "resize" and "put". Then
          > > > form C I first resize the string object to the proper length, then I
          > > > put the characters in.
          >
          > The problem with "from_external" is that is does not create an
          > Eiffel string, but rather an "access-object" for the c-string.
          > But there is "from_external_copy", that does the job. If I
          > remember correctly it was the result from a complaint about
          > the nonavailability of a way to make a "clean" copy of a
          > c-string.
          >
          > > > Unfortunately we could not decide to standardize resize in 2001.
          > > >
          > > > So for any specification I'd like to see something like
          > > >
          > > > resize(size : INTEGER) is
          > > > -- change the storage allocation for the character stream to `size'
          > > > require
          > > > valid_size: size >= 0
          > > > ensure
          > > > size_set: count = size
          > > > capacity: capacity >= size
          > > > The problem that arises from "size < count" could be handled with a
          > > > force flag: "not force and size >= count or else force"
          >
          > What exactly would be the reason for "resize"? External access only?
          > It might be better to hide this from the user! In addition I see no
          > reason at all for a feature "size". IMO the external interface should
          > offer "count" and the "suggested_capacity" as parameter in creation,
          > and nothing else. If we introduce "capacity" and "size" we either
          > disallow, e.g., support for sparse strings, compressed strings and
          > other implementational options. Or these features will have no impact
          > on the internal representation, making them rather useless.
          >
          > Maybe I just did not get your point, please clarify...
          >
          > Regards,
          > Arno
          > --
          > Arno Wagner, Communication Systems Group, ETH Zuerich, wagner@...
          > GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F
          > ----
          > For every complex problem there is an answer that is clear, simple,
          > and wrong. -- H L Mencken
          >
          >
          > ---------------------------
          >
          > http://www.eiffel-nice.org/
          >
          > --------------------------
          >
          > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
          >
          >
        Your message has been successfully submitted and would be delivered to recipients shortly.