SF.net SVN: harbour-project:[18852] trunk/harbour

380 views
Skip to first unread message

dru...@users.sourceforge.net

unread,
Feb 14, 2013, 7:54:04 PM2/14/13
to harbou...@googlegroups.com
Revision: 18852
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=18852&view=rev
Author: druzus
Date: 2013-02-15 00:54:04 +0000 (Fri, 15 Feb 2013)
Log Message:
-----------
2013-02-15 01:53 UTC+0100 Przemyslaw Czerpak (druzus/at/poczta.onet.pl)
* harbour/include/harbour.hbx
* harbour/src/rtl/Makefile
+ harbour/src/rtl/strxchg.c
+ added new PRG function:
hb_strXChg( <cString>, <cSource> | <acSource>, ;
<cDest> | <acDest> ] ) -> <cResult>
This function allows to easy replace different substrings in
given string.
If 2-nd is string then each character in <cString> which exists
in <cSource> at <n> position is replaced by corresponding character
at <n> position in <cDest> or string from <acDest>[ <n> ]
If 2-nd parameter is array then each <cString> substring which exists
in <acSource> at <n> position is replaced by corresponding character
at <n> position in <cDest> or string from <acDest>[ <n> ].
If <n> is longer then LEN() of <cDest> or <acDest> then given
character/substring is removed from result.
This function should help in code which wrongly uses repeated
StrTran() calls all regex which can change also substituted values.
Examples:
// encode XML value
cXmlText := hb_strXChg( cText, "<>&", { "&lt;", "&gt;", "&amp;" } )
// now decode it to raw text
cText := hb_strXChg( cXmlText, { "&lt;", "&gt;", "&amp;" }, "<>&" )
// strip all digits from string
cNoDigit := hb_strXChg( cText, "0123456789" )
// extract all digits from string
cDigits := hb_strXChg( cText, cNoDigit )
// convert chosen letters to upper case
? hb_strXChg( "hello world, "hlwd", "HLWD" )

* harbour/src/common/hbfopen.c
* added workaround for missing wsystem() in XCC

Modified Paths:
--------------
trunk/harbour/ChangeLog.txt
trunk/harbour/include/harbour.hbx
trunk/harbour/src/common/hbfopen.c
trunk/harbour/src/rtl/Makefile

Added Paths:
-----------
trunk/harbour/src/rtl/strxchg.c

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

Lorenzo Fiorini

unread,
Feb 15, 2013, 12:42:05 AM2/15/13
to harbou...@googlegroups.com
On Fri, Feb 15, 2013 at 1:54 AM, <dru...@users.sourceforge.net> wrote:

> + added new PRG function:
> hb_strXChg( <cString>, <cSource> | <acSource>, ;
> <cDest> | <acDest> ] ) -> <cResult>
> This function allows to easy replace different substrings in
> given string.

Great. Really useful also if you have html templates.
This avoid several consecutive strtran on the same string.

Many thanks,
Lorenzo

Mindaugas Kavaliauskas

unread,
Feb 15, 2013, 8:04:02 AM2/15/13
to harbou...@googlegroups.com
Hi,


On 2013.02.15 02:54, dru...@users.sourceforge.net wrote:
> + harbour/src/rtl/strxchg.c
> + added new PRG function:
> hb_strXChg(<cString>,<cSource> |<acSource>, ;
> <cDest> |<acDest> ] ) -> <cResult>

Thank You, very useful function! I use similar functions I my code for
various purpose: template parsing, character (codepage) conversion etc.

A small suggestion. I looks like functionality of this function for many
developers associates with STRTRAN(). Maybe naming HB_STRTRANM() (M for
multiple), HB_STRTRANARR() or similar would be more intuitive.


Regards,
Mindaugas

Lorenzo Fiorini

unread,
Feb 15, 2013, 8:34:05 AM2/15/13
to harbou...@googlegroups.com
On Fri, Feb 15, 2013 at 2:04 PM, Mindaugas Kavaliauskas
<dbt...@dbtopas.lt> wrote:

> A small suggestion. I looks like functionality of this function for many
> developers associates with STRTRAN(). Maybe naming HB_STRTRANM() (M for
> multiple), HB_STRTRANARR() or similar would be more intuitive.

+1

best regards,
Lorenzo

Viktor Szakáts

unread,
Feb 15, 2013, 8:43:39 AM2/15/13
to harbou...@googlegroups.com
> A small suggestion. I looks like functionality of this function for many developers associates with > STRTRAN(). Maybe naming HB_STRTRANM() (M for multiple), HB_STRTRANARR() or similar
> would be more intuitive.

IMO, both suggestions are confusing (single char
suffixes ("M") are seldom very expressing, "ARR"
is wrong, because hashes, strings are also supported.
Also, since this is a new function, it might gain even
more functionality above STRTRAN() (which it already
did), so naming it like STRTRAN() would serve less
and less in the longer run.

On the other hand a case-insensitive switch or varian
could be useful in some cases.

-- Viktor

Viktor Szakáts

unread,
Feb 15, 2013, 8:45:30 AM2/15/13
to harbou...@googlegroups.com
Not to mentions HB_STRXCHG() parameters and
options don't resemble AT ALL to STRTRAN(). Fortunately
so, because STRTRAN() always seemed too
confusing in this regard.

Strong vote to keep the name.

-- Viktor
--
Viktor

Przemyslaw Czerpak

unread,
Feb 15, 2013, 8:55:25 AM2/15/13
to harbou...@googlegroups.com
On Fri, 15 Feb 2013, Mindaugas Kavaliauskas wrote:

Hi,

> On 2013.02.15 02:54, dru...@users.sourceforge.net wrote:
> > + harbour/src/rtl/strxchg.c
> > + added new PRG function:
> > hb_strXChg(<cString>,<cSource> |<acSource>, ;
> > <cDest> |<acDest> ] ) -> <cResult>
> A small suggestion. I looks like functionality of this function for
> many developers associates with STRTRAN(). Maybe naming
> HB_STRTRANM() (M for multiple), HB_STRTRANARR() or similar would be
> more intuitive.

I'm afraid that if we use name similar to StrTran() then people
seeing sth like:
? hb_strTranM( cText, "abcd", "1234" )
may expect that "abcd" is replaced by "1234" when this functions
exchanges characters.
BTW in my code it was called CharXChg().
Anyhow I'll accept any name you agree.

best regards,
Przemek

Bacco

unread,
Feb 15, 2013, 10:12:15 AM2/15/13
to harbou...@googlegroups.com
HB_StrChange / HB_StrSwap
> --
> You received this message because you are subscribed to the Google Groups "Harbour Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to harbour-deve...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

Juan Gálvez

unread,
Feb 15, 2013, 10:42:57 AM2/15/13
to harbou...@googlegroups.com
Hi Przemek,

It's a really useful function.

Many thanks
Juan

El 15/02/2013 1:54, dru...@users.sourceforge.net escribi�:

Viktor Szakáts

unread,
Feb 15, 2013, 2:30:06 PM2/15/13
to harbou...@googlegroups.com
On Fri, Feb 15, 2013 at 4:12 PM, Bacco <carlo...@gmail.com> wrote:
> HB_StrChange / HB_StrSwap

First very vague, second might be good
contender, about the same as current.

Bacco

unread,
Feb 15, 2013, 2:48:31 PM2/15/13
to harbou...@googlegroups.com
I prefer my suggestion (not because it's mine, but for simplicity and
aestethics). Although eXchange has almost the same meaning, the
shortcut doesn't seems so obvious to some non-english speakers, and I
personally find the camelcasing ugly.

By the way, the implementation is very nice, what is no surprise
coming from Przemek (as other leader contributions too).

Regards,
Bacco

ToninhoFWi

unread,
Feb 15, 2013, 5:27:54 PM2/15/13
to harbou...@googlegroups.com
>>may expect that "abcd" is replaced by "1234" when this functions
>>>exchanges characters.

IMHO CharXChg() ou StrXChg() ou StrExchange() are nice.

Thank you, really useful function.

Regards,

Toninho.

Bacco

unread,
Feb 15, 2013, 7:41:24 PM2/15/13
to harbou...@googlegroups.com
StrExchange is better than StrXChg in my view, albeit too long. I
still prefer StrSwap

vszakats

unread,
Feb 16, 2013, 7:27:41 AM2/16/13
to harbou...@googlegroups.com
There is already StrSwap() in hbct. Adding another one 
with HB_ prefix with completely different functionality is 
not good. BTW 'swap' strongly suggests a two way movement, 
and it's used in that meaning in HB_BYTESWAP*() functions 
and also in StrSwap()/CharSwap()/WordSwap(), ie. all existing 
Harbour functions that have this word in them.

Could be hb_StrReplace(), though I still don't feel it much 
better than current. Could also be hb_StrSubst(), but still 
not overly good.

Klas Engwall

unread,
Feb 16, 2013, 11:02:08 AM2/16/13
to harbou...@googlegroups.com
It seems that this function is too capable to be covered by a simple
name :-)

I agree that swapping suggests two strings swapping parts with _each
other_, although I don't quite see how such functionality could be used :-)

hb_StrSubst() suggests something position based similiar to Substr().

I don't mind long names, like hb_StrExchange() or hb_StrReplace() and I
think that a name that is easily understood is better than one that
primarily aims to be short. From that perspective I think that "X" as
shorthand for "Ex" is unnecessarily short.

But like swapping, exchanging suggests that two parties exchange
something with each other, "when you give something to someone and they
give you something else" as the Cambridge Dictionary puts it.

What this new function does is rather to replace something with
something else, throwing away what was there before, so I vote for
hb_StrReplace().

Great new addition to the language, BTW. Thanks Przemek.

Regards,
Klas

vszakats

unread,
Feb 16, 2013, 1:28:56 PM2/16/13
to harbou...@googlegroups.com
On Saturday, February 16, 2013 5:02:08 PM UTC+1, Klas Engwall wrote:
It seems that this function is too capable to be covered by a simple
name :-)

I agree that swapping suggests two strings swapping parts with _each
other_, although I don't quite see how such functionality could be used :-)

hb_StrSubst() suggests something position based similiar to Substr().

I don't mind long names, like hb_StrExchange() or hb_StrReplace() and I
think that a name that is easily understood is better than one that
primarily aims to be short. From that perspective I think that "X" as
shorthand for "Ex" is unnecessarily short.

But like swapping, exchanging suggests that two parties exchange
something with each other, "when you give something to someone and they
give you something else" as the Cambridge Dictionary puts it.

Well put :)

What this new function does is rather to replace something with
something else, throwing away what was there before, so I vote for
hb_StrReplace().

hb_StrReplace() is okay with me.

-- Viktor

Bacco

unread,
Feb 17, 2013, 11:23:52 AM2/17/13
to harbou...@googlegroups.com
Althoug I agree about the 2 way consideration, I've only suggested it
because Exchange is the same concept (Change is not 2 way, Exchange
is), so StrChange woud be better than StrXChange.

All in all, StrReplace seems good enough to me. If others agree, I
propose you set it in stone before it's too late :)

Regards,
Bacco

Mindaugas Kavaliauskas

unread,
Feb 18, 2013, 8:07:25 AM2/18/13
to harbou...@googlegroups.com
Hi,

> + harbour/src/rtl/strxchg.c
> + added new PRG function:
> hb_strXChg(<cString>,<cSource> |<acSource>, ;
> <cDest> |<acDest> ] ) -> <cResult>

One more notice. hb_strxchg(cString, cSource, cDest) is not suitable for
multibyte codepages. Eg., in UTF8 encoding I can not use:
hb_strxchg(cString, "ąčęėįšųūž", "aceeisuuz")

I'm not sure if we need hb_bstrxchg() and hb_ustrxchg() because there is
a work around to use arrays as source and destination parameters. Maybe
good documentation is enough.


Regards,
Mindaugas

Przemyslaw Czerpak

unread,
Feb 18, 2013, 11:09:04 AM2/18/13
to harbou...@googlegroups.com
On Mon, 18 Feb 2013, Mindaugas Kavaliauskas wrote:

Hi,

> > + harbour/src/rtl/strxchg.c
> > + added new PRG function:
> > hb_strXChg(<cString>,<cSource> |<acSource>, ;
> > <cDest> |<acDest> ] ) -> <cResult>
> One more notice. hb_strxchg(cString, cSource, cDest) is not suitable
> for multibyte codepages. Eg., in UTF8 encoding I can not use:
> hb_strxchg(cString, "ąčęėįšųūž", "aceeisuuz")

Yes but it's by definition.
This function can be used for CP translations so if we begin to
decode multibyte characters then we break some other functionality
when result string uses different encoding.

> I'm not sure if we need hb_bstrxchg() and hb_ustrxchg() because
> there is a work around to use arrays as source and destination
> parameters. Maybe good documentation is enough.

Exactly, we should document that this function uses string in raw
form and does not assume any special encoding. If someone wants
to encode/decode multibyte characters then he should put them in
arrays. As helper function we can add:
hb_strToArray()
which will respect character encoding.

best regards,
Przemek
Reply all
Reply to author
Forward
0 new messages