Code to create a UC_UTF8_STRING from STRING_GENERAL
|
View:
New views
8 Messages
—
Rating Filter:
Alert me
|
 |
Code to create a UC_UTF8_STRING from STRING_GENERAL
by Colin Adams-3
::
Rate this Message:
Here is the functional version. It should be straight-forward to
change it to a creation procedure. Note that it is liberal on the memory creation of l_bytes, to avoid any resizing of this buffer. utf8_string (a_string: STRING_GENERAL): UC_UTF8_STRING is -- UTF-8 encoded version of `a_string' require a_string_not_void: a_string /= Void local i: INTEGER_32 l_bytes: STRING do create l_bytes.make (a_string.count * 4) from i := 1 until i > a_string.count loop utf8.append_code_to_utf8 (l_bytes, a_string.code (i).as_integer_32) i := i + 1 end create Result.make_from_utf8 (l_bytes) ensure utf8_string_not_void: Result /= Void correct_count: Result.count = a_string.count strings_equal: True -- can't be checked as STRING_GENERAL and UC_STRING lack the facilities (`for_all') end ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ gobo-eiffel-develop mailing list gobo-eiffel-develop@... https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop |
|
|
Re: Code to create a UC_UTF8_STRING from STRING_GENERAL
by Eric Bezault
::
Rate this Message:
Colin Adams wrote:
> Here is the functional version. It should be straight-forward to > change it to a creation procedure. > > Note that it is liberal on the memory creation of l_bytes, to avoid > any resizing of this buffer. In fact having it as creation procedure will allow us to avoid having to create the intermediary object `l_bytes'. After looking at class UC_STRING, I'm wondering whether we should just adapt the routines `make_from_string' and `make_from_substring' so that we can pass a STRING_GENERAL. Perhaps we will have to rename the version of `make_from_string' inherited from STRING. Or add `make_from_string_general', `make_from_substring_general', make `make_from_substring' obsolete (make it call `make_from_substring_general') and modify `make_from_string' to call `make_from_string_general'. I'm not sure what the best naming convention is. -- Eric Bezault mailto:ericb@... http://www.gobosoft.com ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ gobo-eiffel-develop mailing list gobo-eiffel-develop@... https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop |
|
|
Re: Code to create a UC_UTF8_STRING from STRING_GENERAL
by Colin Adams-3
::
Rate this Message:
On 21/04/2008, Eric Bezault <ericb@...> wrote:
> In fact having it as creation procedure will allow us to avoid > having to create the intermediary object `l_bytes'. > > After looking at class UC_STRING, I'm wondering whether we should > just adapt the routines `make_from_string' and `make_from_substring' > so that we can pass a STRING_GENERAL. Perhaps we will have to We could do that, as we have the is_string_8 query to choose between the current implementation and the STRING_32 one. > rename the version of `make_from_string' inherited from STRING. > Or add `make_from_string_general', `make_from_substring_general', > make `make_from_substring' obsolete (make it call > `make_from_substring_general') and modify `make_from_string' > to call `make_from_string_general'. I'm not sure what the best > naming convention is. I don't think we need to rename anything. ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ gobo-eiffel-develop mailing list gobo-eiffel-develop@... https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop |
|
|
Re: Code to create a UC_UTF8_STRING from STRING_GENERAL
by Eric Bezault
::
Rate this Message:
Colin Adams wrote:
> On 21/04/2008, Eric Bezault <ericb@...> wrote: >> In fact having it as creation procedure will allow us to avoid >> having to create the intermediary object `l_bytes'. >> >> After looking at class UC_STRING, I'm wondering whether we should >> just adapt the routines `make_from_string' and `make_from_substring' >> so that we can pass a STRING_GENERAL. Perhaps we will have to > > We could do that, as we have the is_string_8 query to choose between > the current implementation and the STRING_32 one. We don't need `is_string_8'. We just need to use STRING_GENERAL.code. >> rename the version of `make_from_string' inherited from STRING. >> Or add `make_from_string_general', `make_from_substring_general', >> make `make_from_substring' obsolete (make it call >> `make_from_substring_general') and modify `make_from_string' >> to call `make_from_string_general'. I'm not sure what the best >> naming convention is. > > I don't think we need to rename anything. We do: `make_from_string' is inherited from STRING with an argument of type STRING. We cannot redefine it to accept an argument of type STRING_GENERAL. -- Eric Bezault mailto:ericb@... http://www.gobosoft.com ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ gobo-eiffel-develop mailing list gobo-eiffel-develop@... https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop |
|
|
Re: Code to create a UC_UTF8_STRING from STRING_GENERAL
by Colin Adams-3
::
Rate this Message:
On 21/04/2008, Eric Bezault <ericb@...> wrote:
> After looking at class UC_STRING, I'm wondering whether we should > just adapt the routines `make_from_string' and `make_from_substring' > so that we can pass a STRING_GENERAL. Perhaps we will have to > rename the version of `make_from_string' inherited from STRING. > Or add `make_from_string_general', `make_from_substring_general', > make `make_from_substring' obsolete (make it call > `make_from_substring_general') and modify `make_from_string' > to call `make_from_string_general'. I'm not sure what the best > naming convention is. I think the last suggestion (adding make_from_string_general and changing make_from_string to call make_from_string_general, etc.) is best. ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ gobo-eiffel-develop mailing list gobo-eiffel-develop@... https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop |
|
|
Re: Code to create a UC_UTF8_STRING from STRING_GENERAL
by Colin Adams-3
::
Rate this Message:
2008/4/29 Colin Adams <colinpauladams@...>:
> On 21/04/2008, Eric Bezault <ericb@...> wrote: > >> After looking at class UC_STRING, I'm wondering whether we should >> just adapt the routines `make_from_string' and `make_from_substring' >> so that we can pass a STRING_GENERAL. Perhaps we will have to >> rename the version of `make_from_string' inherited from STRING. >> Or add `make_from_string_general', `make_from_substring_general', >> make `make_from_substring' obsolete (make it call >> `make_from_substring_general') and modify `make_from_string' >> to call `make_from_string_general'. I'm not sure what the best >> naming convention is. > > I think the last suggestion (adding make_from_string_general and > changing make_from_string to call make_from_string_general, etc.) is > best. > Shall we do this then? I've just this minute encountered the need for it. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ gobo-eiffel-develop mailing list gobo-eiffel-develop@... https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop |
|
|
Re: Code to create a UC_UTF8_STRING from STRING_GENERAL
by Colin Adams-3
::
Rate this Message:
I've had a change of heart on this.
I've just created READABLE_STRING, as an ancestor of STRING_GENERAL. I've put this into the Gobo version of Free_ELKS, and done test_debug_ge in $GOBO/test. All tests pass. I then did the same thing for ISE 6.2.7.3489, and it looks like all the tests for that will pass to. So later today, I will post these amended classes to the Free ELKS list, (after patching my current efforts towards ST_STRING with the changes, and checking the tests for that pass too), and if they are accepted, then we can have make_from_readable_string instead. 2008/5/17 Colin Adams <colinpauladams@...>: > 2008/4/29 Colin Adams <colinpauladams@...>: >> On 21/04/2008, Eric Bezault <ericb@...> wrote: >> >>> After looking at class UC_STRING, I'm wondering whether we should >>> just adapt the routines `make_from_string' and `make_from_substring' >>> so that we can pass a STRING_GENERAL. Perhaps we will have to >>> rename the version of `make_from_string' inherited from STRING. >>> Or add `make_from_string_general', `make_from_substring_general', >>> make `make_from_substring' obsolete (make it call >>> `make_from_substring_general') and modify `make_from_string' >>> to call `make_from_string_general'. I'm not sure what the best >>> naming convention is. >> >> I think the last suggestion (adding make_from_string_general and >> changing make_from_string to call make_from_string_general, etc.) is >> best. >> > > Shall we do this then? > > I've just this minute encountered the need for it. > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ gobo-eiffel-develop mailing list gobo-eiffel-develop@... https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop |
|
|
Re: Code to create a UC_UTF8_STRING from STRING_GENERAL
by Eric Bezault
::
Rate this Message:
Colin Adams wrote:
> 2008/4/29 Colin Adams <colinpauladams@...>: >> On 21/04/2008, Eric Bezault <ericb@...> wrote: >> >>> After looking at class UC_STRING, I'm wondering whether we should >>> just adapt the routines `make_from_string' and `make_from_substring' >>> so that we can pass a STRING_GENERAL. Perhaps we will have to >>> rename the version of `make_from_string' inherited from STRING. >>> Or add `make_from_string_general', `make_from_substring_general', >>> make `make_from_substring' obsolete (make it call >>> `make_from_substring_general') and modify `make_from_string' >>> to call `make_from_string_general'. I'm not sure what the best >>> naming convention is. >> I think the last suggestion (adding make_from_string_general and >> changing make_from_string to call make_from_string_general, etc.) is >> best. >> > > Shall we do this then? > > I've just this minute encountered the need for it. I just added `make_from_string_general' in UC_STRING. It should be easy to make it accept READABLE_STRING by just replacing any occurrence of STRING_GENERAL by READABLE_STRING in classes UC_STRING and UC_UTF8_ROUTINES. -- Eric Bezault mailto:ericb@... http://www.gobosoft.com ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ gobo-eiffel-develop mailing list gobo-eiffel-develop@... https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop |
| Free Forum Powered by Nabble | Forum Help |