Re: Enhancing STRING_GENERAL

Emmanuel Stapf

Re: Enhancing STRING_GENERAL

Reply Threaded More More options
Print post
Permalink
> other hand you're happy with string conversions which in my
> opinion are much more costly in terms of performance.

Indeed they are costly, but at least in this case I hope those conversions
will only be present for a short period of time until everything is switched
to STRING_32.

Manu



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
freeelks-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freeelks-devel
------------------------------------------------------------------------  
Eiffel Software
805-685-1006
http://www.eiffel.com       
Customer support: http://support.eiffel.com       
User group: http://groups.eiffel.com/join       
------------------------------------------------------------------------  
Emmanuel Stapf

Re: Enhancing STRING_GENERAL

Reply Threaded More More options
Print post
Permalink
> As for UC_STRING disappearing, that would rather depend on
> how the ECMA committee decides to answer the question that I
> posed in my report:

Any chance that you can come to the next ECMA meeting? I think it would be
beneficial to everyone to discuss this issue in depth.

Thanks,
Manu


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
freeelks-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freeelks-devel
------------------------------------------------------------------------  
Eiffel Software
805-685-1006
http://www.eiffel.com       
Customer support: http://support.eiffel.com       
User group: http://groups.eiffel.com/join       
------------------------------------------------------------------------  
Colin Adams-3

Re: Enhancing STRING_GENERAL

Reply Threaded More More options
Print post
Permalink
No.

On 26/10/2007, Emmanuel Stapf [ES] <[hidden email]> wrote:

> > As for UC_STRING disappearing, that would rather depend on
> > how the ECMA committee decides to answer the question that I
> > posed in my report:
>
> Any chance that you can come to the next ECMA meeting? I think it would be
> beneficial to everyone to discuss this issue in depth.
>
> Thanks,
> Manu
>
>

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
freeelks-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freeelks-devel
Peter Gummer-2

Re: Enhancing STRING_GENERAL

Reply Threaded More More options
Print post
Permalink
In reply to this post by Emmanuel Stapf
Eric Bezault wrote:

> If you keep using `s.area.item', then Peter, who wants to use
> these features, won't be able to use them because he is also
> using UC_STRING.


I've gone back and looked at how I'm using UC_STRING.

On .NET I don't use UC_STRING at all (except indirectly, via other Gobo
classes), because I use native .NET classes to convert between STRING_8 and
SYSTEM_STRING (see
http://www.eiffelroom.com/blog/peter_gummer/utf_8_in_net_revisited).

In classic Eiffel, I use UC_STRING only as a local variable within one
routine:

feature -- Unicode

 utf8 (utf8_bytes: STRING): STRING_32
   -- `utf8_bytes' converted from a sequence of UTF-8 bytes to 32-bit
Unicode characters.
  require
   utf8_bytes_attached: utf8_bytes /= Void
   utf8_bytes_valid: (create {UC_UTF8_ROUTINES}).valid_utf8 (utf8_bytes)
  local
   s: STRING
  do
   create {UC_UTF8_STRING} s.make_from_utf8 (utf8_bytes)
   Result := s.as_string_32
  ensure
   attached: Result /= Void
   not_longer: Result.count <= utf8_bytes.count
  end

In other words, I use STRING_8 everywhere. I use UC_STRING only as an
encoder, to give me 32-bit Unicode strings for input to Vision2 routines.
(Rather inefficiently too!)

The current implementation of starts_with and ends_with may be incorrect,
but they meet my current needs.

- Peter Gummer



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
freeelks-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freeelks-devel
Eric Bezault

Re: Enhancing STRING_GENERAL

Reply Threaded More More options
Print post
Permalink
Peter Gummer wrote:
> Eric Bezault wrote:
>> If you keep using `s.area.item', then Peter, who wants to use
>> these features, won't be able to use them because he is also
>> using UC_STRING.

> The current implementation of starts_with and ends_with may be incorrect,
> but they meet my current needs.

OK then, I give up.

--
Eric Bezault
mailto:[hidden email]
http://www.gobosoft.com

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
freeelks-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freeelks-devel