Test for strings to be not equal (style question)
Ronald Fischer
I am using the following approach:
if { [string equal $first second] == 0 } {
do whatever....
}
I don't like the explicit test for "== 0"; is there a nicer way
to do it?
Ronald
--
Ronald Fischer <ron...@eml.cc>
Posted via http://www.newsoffice.de/
fan...@telefonica.net
Ronald Fischer ha escrito:
> What is a better way to test for two string being NOT equal?
if {$first ne $second} {
whatever
}
Andres
Donald Arseneau
> if { [string equal $first second] == 0 } {
>
> I don't like the explicit test for "== 0"; is there a nicer way
> to do it?
If you want to stick with [string] there is
![string equal $first second]
which makes better sense, but the "!" can sometimes be
hard to notice.
--
Donald Arseneau as...@triumf.ca
Robert Heller
>
> What is a better way to test for two string being NOT equal?
>
> I am using the following approach:
>
> if { [string equal $first second] == 0 } {
> do whatever....
> }
>
> I don't like the explicit test for "== 0"; is there a nicer way
> to do it?
if { ![string equal $first second] } {
do whatever....
}
>
> Ronald
>
>
--
Robert Heller -- 978-544-6933
Deepwoods Software -- Linux Installation and Administration
http://www.deepsoft.com/ -- Web Hosting, with CGI and Database
hel...@deepsoft.com -- Contract Programming: C/C++, Tcl/Tk
Jonathan Bromley
wrote:
>What is a better way to test for two string being NOT equal?
>
>I am using the following approach:
>
>if { [string equal $first second] == 0 } {
> do whatever....
>}
>
>I don't like the explicit test for "== 0"; is there a nicer way
>to do it?
Others have suggested
if {![string equal $first second]} {
but I'm not the only one to notice that the ! operator is
easy to miss when reading quickly.
I often write
if {[string compare $first second]} {
which is probably less efficient, but I find easier to read.
--
Jonathan Bromley, Consultant
DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan...@MYCOMPANY.com
http://www.MYCOMPANY.com
The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
Bryan Oakley
> Others have suggested
> if {![string equal $first second]} {
> but I'm not the only one to notice that the ! operator is
> easy to miss when reading quickly.
The solution is to isolate the !; this is a coding standard where I
work, to wit:
if { ! [some command ...]} {...}
That makes the ! much more visible, if not down-right impossible to miss.
Not that that has anything to do with this thread; just throwing out
simple solution to a simple problem.
Mark Janssen
> I often write
> if {[string compare $first second]} {
> which is probably less efficient, but I find easier to read.
> --
What I find confusing about this usage is that the true branch of the
if is taken if the strings are not equal, which is correct in this case
but to me not very obvious. I prefer {$a ne $b} as well because it
states more clearly the intented comparison (are the strings different)
Mark
Cameron Laird
Robert Heller <hel...@deepsoft.com> wrote:
>At Thu, 18 Jan 2007 12:08:04 +0100 Ronald Fischer <ron...@eml.cc> wrote:
>
>>
>> What is a better way to test for two string being NOT equal?
>>
>> I am using the following approach:
>>
>> if { [string equal $first second] == 0 } {
>> do whatever....
>> }
>>
>> I don't like the explicit test for "== 0"; is there a nicer way
>> to do it?
>
> if { ![string equal $first second] } {
> do whatever....
> }
.
.
I'm a tiny bit surprised no one has yet mentioned
if [string compare $first second] {...
nor that "... $first second" (is there a '$' missing?)
has been flagged as questionable.
Darren New
> I'm a tiny bit surprised no one has yet mentioned
> if [string compare $first second] {...
I've always found that treating a non-boolean result as a boolean is
confusing. Especially when [string compare] returns true for strings
that don't compare. :-)
--
Darren New / San Diego, CA, USA (PST)
Scruffitarianism - Where T-shirt, jeans,
and a three-day beard are "Sunday Best."
Glenn Jackman
> Cameron Laird wrote:
> > I'm a tiny bit surprised no one has yet mentioned
> > if [string compare $first second] {...
>
> I've always found that treating a non-boolean result as a boolean is
> confusing.
Amen! My nitpick exactly. The return value of [catch] falls into this
category too.
--
Glenn Jackman
"You can only be young once. But you can always be immature." -- Dave Barry
EKB
I'm surprised that this reply (2nd in the thread) has somehow not been
noticed. This is (in my opinion) the best answer. Here's the text from
the man page for "expr":
eq ne
Boolean string equal and string not equal. Each operator produces a
zero/one result. The operand types are interpreted only as strings.
Glenn Jackman
These operators were added in 8.4, which is over 4 years old (I think).
At work, a database product I use has embedded Tcl in it (so no hope of
upgrading) -- it's patchlevel is 8.0p2. "Wow, you're turning 10 this
year. Such a big boy! [ruffles hair condescendingly]"
I wonder (off-topically) how many other ancient installations are still
productively in use out there?
Cameron Laird
Glenn Jackman <gle...@ncf.ca> wrote:
.
.
.
>I wonder (off-topically) how many other ancient installations are still
>productively in use out there?
.
.
Many. Tcl is often used by the kind of people--those in
charge of factories, chemical refineries, transportation
networks, ...--who expect their stuff to work for decades
at a time. Tcl is all about gluing together useful parts,
even when some of them come from the real world; it's not
a language that just stares at its computing-fashion navel.
Darren New
> Many. Tcl is often used by the kind of people--those in
> charge of factories, chemical refineries, transportation
> networks, ...--who expect their stuff to work for decades
> at a time. Tcl is all about gluing together useful parts,
> even when some of them come from the real world; it's not
> a language that just stares at its computing-fashion navel.
Oh, you're just *begging* to get in the QOTW now, aren't you? :-)
Donald Arseneau
> I'm a tiny bit surprised no one has yet mentioned
>
> if [string compare $first second] {...
No braces?
I thought of it, and I should have mentioned it, saying:
There is also [string compare $first second] which can be
used for inequality, and you may find it used that way in
very old Tcl programs from before the introduction of
[string equal ]. However, it is terribly confusing because
"compare" does not really suggest "unequal".
If I'm editing an ancient program, I assiduously replace
[string compare] with ![string equal] when used for that
purpose. An even easier choice is replacing
if {[string compare foo bar] == 0}
with
if {[string equal foo bar]}
--
Donald Arseneau as...@triumf.ca
Donald Arseneau
> > > if {$first ne $second} {
> These operators were added in 8.4, which is over 4 years old (I think).
Indeed. Here I was thinking they were a late 8.4.n addition.
Maybe I was thinking of "in". I think it is safe to reccommend
it now!
--
Donald Arseneau as...@triumf.ca
Ronny
> The solution is to isolate the !; this is a coding standard where I
> work, to wit:
>
> if { ! [some command ...]} {...}
>
> That makes the ! much more visible, if not down-right impossible to miss.
I'll use that one. Thank you for this suggestion.
The variant if { $first ne $second } mentioned earlier, is nice, but
doesn't
work for me, because my program needs to run on Tcl 8.3.
Ronald
Glenn Jackman
> There is also [string compare $first second] which can be
> used for inequality, and you may find it used that way in
> very old Tcl programs from before the introduction of
> [string equal ]. However, it is terribly confusing because
> "compare" does not really suggest "unequal".
Which is why I don't treat the integer return value of such commands as
boolean values (particularly, [catch]). It strikes me that [string
compare] was written to be used as the command for [lsort -command],
returning one of {-1,0,1}.
> If I'm editing an ancient program, I assiduously replace
> [string compare] with ![string equal] when used for that
> purpose. An even easier choice is replacing
> if {[string compare foo bar] == 0}
> with
> if {[string equal foo bar]}
or: if {"foo" eq "bar"}
Cameron Laird
Darren New <dn...@san.rr.com> wrote:
>Cameron Laird wrote:
>> Many. Tcl is often used by the kind of people--those in
>> charge of factories, chemical refineries, transportation
>> networks, ...--who expect their stuff to work for decades
>> at a time. Tcl is all about gluing together useful parts,
>> even when some of them come from the real world; it's not
>> a language that just stares at its computing-fashion navel.
>
>
>Oh, you're just *begging* to get in the QOTW now, aren't you? :-)
.
.
Rather than contest the circumstantial evidence, I'll
take a role where I perhaps can be useful, and emphasize
that Tcl programmers coming from a computer background
will do well to understand how different things look to
engineers who seriously think in terms of thirty-year
product cycles--and vice versa.
I know *you* know this stuff already, Darren.
Tcl's a great tool.
Kevin Kenny
> I wonder (off-topically) how many other ancient installations are still
> productively in use out there?
NBC still seems quite happy with the semi-mythical 8.0.5, which now runs
NBC, Telemundo, UPN, Pax [part of the network, part of the time], and
over a dozen cable properties 24x7. There's also a lot of 8.0 code
(and a little bit of 7.6) in various bits of medical equipment. I'm
certain that I've still got 7.3 stuff in production *somewhere*, because
I've made no effort to expunge it -- I'm still prepared to maintain
it if someone a$k$ me in a $ufficiently per$ua$ive way. I
*think* the customers have retired all the 6.x installations that
I've had anything to do with, but I've been surprised before. (I came
to Tcl around verson 6.4, so I don't have anything earlier about.)
I don't expect any of these installations ever to upgrade their
versions of Tcl. Requalifying them would be a *lot* of work for
very little benefit. Eventually a more modern version will be
built into whatever replaces them. In the broadcasting case,
that may well take a while - the current system replaced some
automation from the early 1970s, and I wouldn't be at all surprised
to find that it, too, has a 25-year lifespan.
--
73 de ke9tv/2, Kevin
Jeff Hobbs
> In article <cd391$45af7e46$404a99a1$20...@news.news-service.com>,
> Robert Heller <hel...@deepsoft.com> wrote:
>> At Thu, 18 Jan 2007 12:08:04 +0100 Ronald Fischer <ron...@eml.cc> wrote:
>>
>>> What is a better way to test for two string being NOT equal?
>>>
>>> I am using the following approach:
>>>
>>> if { [string equal $first second] == 0 } {
>>> do whatever....
>>> }
>>>
>>> I don't like the explicit test for "== 0"; is there a nicer way
>>> to do it?
>> if { ![string equal $first second] } {
>> do whatever....
>> }
> .
>
> if [string compare $first second] {...
>
> nor that "... $first second" (is there a '$' missing?)
> has been flagged as questionable.
While [string compare] was the primary method for use up to 8.1.0, it
isn't the most efficient by far in 8.4. The optimization advantage you
get in ![string equal] (or expr 'ne') is that I can first test to see if
the two objects are even the same size, before ever looking at the first
byte (and this is often cached in the Tcl_Obj under the covers).
[string compare] returns the -1/0/1 lexical comparison, so it always has
to do some comparison to return its result.
--
Jeff Hobbs, The Tcl Guy, http://www.activestate.com/
Gerald W. Lester
A certain lab robot I know still runs 8.0.x.
I've not heard that ESO has moved off of 7.6, but they may have upgraded.
--
+--------------------------------+---------------------------------------+
| Gerald W. Lester |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+
Erik Allaert
> Kevin Kenny wrote:
>> Glenn Jackman wrote:
>>> I wonder (off-topically) how many other ancient installations are still
>>> productively in use out there?
>>
>> NBC still seems quite happy with the semi-mythical 8.0.5, which now runs
>> NBC, Telemundo, UPN, Pax [part of the network, part of the time], and
>> over a dozen cable properties 24x7. There's also a lot of 8.0 code
>> (and a little bit of 7.6) in various bits of medical equipment. I'm
>> certain that I've still got 7.3 stuff in production *somewhere*, because
>> I've made no effort to expunge it -- I'm still prepared to maintain
>> it if someone a$k$ me in a $ufficiently per$ua$ive way. I
>> *think* the customers have retired all the 6.x installations that
>> I've had anything to do with, but I've been surprised before. (I came
>> to Tcl around verson 6.4, so I don't have anything earlier about.)
>>
>> I don't expect any of these installations ever to upgrade their
>> versions of Tcl. Requalifying them would be a *lot* of work for
>> very little benefit. Eventually a more modern version will be
>> built into whatever replaces them. In the broadcasting case,
>> that may well take a while - the current system replaced some
>> automation from the early 1970s, and I wouldn't be at all surprised
>> to find that it, too, has a 25-year lifespan.
>
> A certain lab robot I know still runs 8.0.x.
>
> I've not heard that ESO has moved off of 7.6, but they may have upgraded.
and are currently ready to install Tcl/Tk 8.4.13 on nearly 100 workstations
controlling telescopes and instruments. With new instruments and requirements
popping up every so often, we cannot think of "freezing" any of our hardware
or software ...
Erik Allaert
European Southern Observatory (ESO)
Gerald W. Lester
> Gerald W. Lester wrote:
>...
>> I've not heard that ESO has moved off of 7.6, but they may have upgraded.
> You bet we did, looooooong ago. We've upgraded Tcl/Tk about once a year
> and are currently ready to install Tcl/Tk 8.4.13 on nearly 100 workstations
> controlling telescopes and instruments. With new instruments and
> requirements
> popping up every so often, we cannot think of "freezing" any of our
> hardware
> or software ...
>
> Erik Allaert
> European Southern Observatory (ESO)
Erik,
Good! Have not seen a post from ESO on c.l.t. in a long time, so was not sure.
Glad ya'll are staying current. Hope all is going well.
Plebeian
I currently work in the Printing Industry, and programming is NOT my
job. I am not sure about other printing companies. But I can now say
that we now use Tcl/Tk. Its just a small tool that I wrote to help
format .csv files, which saves a lot of man-hours if we did it the old
manual way.
Just thought I'd share my experience with the Group.
- Casey
suchenwi
Plebeian schrieb:
> I can now say
> that we now use Tcl/Tk. Its just a small tool that I wrote to help
> format .csv files, which saves a lot of man-hours if we did it the old
> manual way.
Good to hear! Did you use the csv package from tcllib, which makes
things very easy?
Plebeian
several years, I knew right away that things would be easy. And didn't
have to spend a lot of time researching.
:)
- Casey
On Jan 23, 9:16 am, "suchenwi"
<richard.suchenwirth-bauersa...@siemens.com> wrote:
> Plebeian schrieb:
>
> > I can now say
> > that we now use Tcl/Tk. Its just a small tool that I wrote to help
> > format .csv files, which saves a lot of man-hours if we did it the old
> > manual way.Good to hear! Did you use the csv package from tcllib, which makes
> things very easy?
Ronny
> cla...@lairds.us (Cameron Laird) writes:
> > I'm a tiny bit surprised no one has yet mentioned
>
> > if [string compare $first second] {...
> No braces?
I don't think braces are needed here. After all, string compare
evaluates to an integer.
Ronald
Kevin Kenny
>>> if [string compare $first second] {...
>
> evaluates to an integer.
There are several reasons to brace your expressions:
(1) It's faster. Tcl doesn't need to check whether the result
of [string compare] contains more metacharacters. Sure, it
won't ... but the bytecode compiler doesn't *know* that.
(2) It's safer. If you write things like [if $x {do this}],
you open the door to script-injection attacks in the case
where $x might come from user input.
(3) It's less cognitive burden. If you brace your expressions
every time, you're less likely to forget the braces when
you *do* need them.
Get into good habits.
Ronny
> There are several reasons to brace your expressions:
> (1) It's faster.
> (2) It's safer.
[...]
> (3) It's less cognitive burden. If you brace your expressions
> every time, you're less likely to forget the braces when
> you *do* need them.
Point understood! Thank you!
Ronald