Re: Comparing strings with if else

[Richard Damon]

On 11/8/15 9:29 AM, Stefan Ram wrote:
> There are many ways, but today I want to do it the LISP way!
>
> #include <iostream>
> #include <ostream>
>
> constexpr bool isequal
> ( char const * const s,
> char const * const s1 )
> { return
> *s ?( *s1 ? *s == *s1 && isequal( s + 1, s1 + 1 ): 0 ):
> *s1 ? 0 : 1; }
>

I would simplify this to:

return *s == *s1 && (*s ? isequal( s+1, s1+1) : 1);


> int main()
> { ::std::cout << isequal( "", "" )<< '\n';
> ::std::cout << isequal( "ab", "ab" )<< '\n';
> ::std::cout << isequal( "a", "a" )<< '\n';
>
> ::std::cout << isequal( "a", "b" )<< '\n';
> ::std::cout << isequal( "ab", "ac" )<< '\n';
> ::std::cout << isequal( "a", "" )<< '\n';
> ::std::cout << isequal( "", "a" )<< '\n'; }
>

[Ben Bacarisse]

r...@zedat.fu-berlin.de (Stefan Ram) writes:

> There are many ways, but today I want to do it the LISP way!
>
> #include <iostream>
> #include <ostream>
>
> constexpr bool isequal
> ( char const * const s,
> char const * const s1 )
> { return
> *s ?( *s1 ? *s == *s1 && isequal( s + 1, s1 + 1 ): 0 ):
> *s1 ? 0 : 1; }

I think

return *s == *s1 && (*s == 0 || isequal(s + 1, s1 + 1));

is a bit clearer (odd indentation aside). And it probably counts as
tail recursive for some compilers.

<snip>
--
Ben.

[Juha Nieminen]

Stefan Ram <r...@zedat.fu-berlin.de> wrote:
> ( char const * const s,
> char const * const s1 )

Is that deliberate obfuscation?

(Hint: Is there any rational reason to not to use 's1' and 's2'?
Or even better, something even clearer, like 'str1' and 'str2'.)

--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---

[Alf P. Steinbach]

On 11/9/2015 10:38 AM, Juha Nieminen wrote:
> Stefan Ram <r...@zedat.fu-berlin.de> wrote:
>> ( char const * const s,
>> char const * const s1 )
>
> Is that deliberate obfuscation?
>

I prefer "a" and "b" for such naming.

But I can understand "sI" and "sII".

And in the case of a source and a destination, the old 1970's C
convention is "s" and "d".


Cheers,

- Alf

[Juha Nieminen]

Alf P. Steinbach <alf.p.stein...@gmail.com> wrote:
> I prefer "a" and "b" for such naming.
>
> But I can understand "sI" and "sII".
>
> And in the case of a source and a destination, the old 1970's C
> convention is "s" and "d".

Why the love for brevity? Why must everything use as few characters as
possible?

But as said, even if you must use short names, I think 'str1' and 'str2'
ought to do.

Although if we are talking about comparing two things, a common
naming convention is 'lhs' and 'rhs' (especially for very short
comparison functions).

[Gareth Owen]

Juha Nieminen <nos...@thanks.invalid> writes:

> Alf P. Steinbach <alf.p.stein...@gmail.com> wrote:
>> I prefer "a" and "b" for such naming.
>>
>> But I can understand "sI" and "sII".
>>
>> And in the case of a source and a destination, the old 1970's C
>> convention is "s" and "d".
>
> Why the love for brevity? Why must everything use as few characters as
> possible?

Never understood it drives me mad. I am currently working on a departed
co-worker's code which is full of obfuscated snippets like

const uint8_t *b_r = src;
...
const uint8_t *t_b_r = b_r;
uint8_t *t_s_b_r = s_b_r;
for(int k=0;k<k_end;++k, br += stride)
{
*(s_b_r++) = *(b_r);
}


and when you refactor it it turns into something insanely clear:

const uint8_t *src_row = src + row*width;
uint8_t *dst_row = dst + row*dst_width;

for(int col=0;k<ncols;++col)
{
dst_row[col] = src_row[col*stride];
}


He's also a big fan of iterating over arrays with
int l = len;
for(;l--;) {
arr[l] = whatever();
}

seemingly *just* to avoid the wearisome job of typing an idiomatic
for-loop.

[Paavo Helde]

Gareth Owen <gwo...@gmail.com> wrote in news:87wptri...@gmail.com:

> Juha Nieminen <nos...@thanks.invalid> writes:
>
>> Alf P. Steinbach <alf.p.stein...@gmail.com> wrote:
>>> I prefer "a" and "b" for such naming.
>>>
>>> But I can understand "sI" and "sII".
>>>
>>> And in the case of a source and a destination, the old 1970's C
>>> convention is "s" and "d".
>>
>> Why the love for brevity? Why must everything use as few characters as
>> possible?
>
> Never understood it drives me mad. I am currently working on a
departed
> co-worker's code which is full of obfuscated snippets like
>
> const uint8_t *b_r = src;
> ...
> const uint8_t *t_b_r = b_r;
> uint8_t *t_s_b_r = s_b_r;
> for(int k=0;k<k_end;++k, br += stride)
> {
> *(s_b_r++) = *(b_r);
> }

You are lucky if this is the most obfuscated code that you see :-)

>
> and when you refactor it it turns into something insanely clear:
>
> const uint8_t *src_row = src + row*width;
> uint8_t *dst_row = dst + row*dst_width;
>
> for(int col=0;k<ncols;++col)
> {
> dst_row[col] = src_row[col*stride];
> }

This code contains a multiplication in inner loop, so the original code
might have had better performance with old hardware and compilers.
Nowadays this probably does not matter any more.

Cheers
Paavo

[Jorgen Grahn]

On Mon, 2015-11-09, Gareth Owen wrote:
> Juha Nieminen <nos...@thanks.invalid> writes:
>
>> Alf P. Steinbach <alf.p.stein...@gmail.com> wrote:
>>> I prefer "a" and "b" for such naming.
>>>
>>> But I can understand "sI" and "sII".
>>>
>>> And in the case of a source and a destination, the old 1970's C
>>> convention is "s" and "d".
>>
>> Why the love for brevity? Why must everything use as few characters as
>> possible?

Sometimes there's just not anything more to say.

> Never understood it drives me mad. I am currently working on a
> departed co-worker's

For some reason, at first I read "deceased".

> code which is full of obfuscated snippets like
>
> const uint8_t *b_r = src;
> ...
> const uint8_t *t_b_r = b_r;
> uint8_t *t_s_b_r = s_b_r;
> for(int k=0;k<k_end;++k, br += stride)
> {
> *(s_b_r++) = *(b_r);
> }

To me, that's fairly long /and/ content-less names. The way he uses
underscores to separate words and ease readability is almost sadistic.

But I suspect it made perfect sense to him, and was written in good
faith.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Richard]

[Please do not mail me a copy of your followup]

Jorgen Grahn <grahn...@snipabacken.se> spake the secret code
<slrnn41qni.5...@frailea.sa.invalid> thusly:

>On Mon, 2015-11-09, Gareth Owen wrote:
>> Juha Nieminen <nos...@thanks.invalid> writes:
>>
>>> Alf P. Steinbach <alf.p.stein...@gmail.com> wrote:
>>>> I prefer "a" and "b" for such naming.
>>>>
>>>> But I can understand "sI" and "sII".
>>>>
>>>> And in the case of a source and a destination, the old 1970's C
>>>> convention is "s" and "d".
>>>
>>> Why the love for brevity? Why must everything use as few characters as
>>> possible?
>
>Sometimes there's just not anything more to say.

In 1978, my team went insane with "coding style" guidelines. One
programmer started writing (in C++ identifier form)

the_loop_variable

instead of

i

to get code like:

for (int the_loop_variable = 0; the_loop_variable < 10; ++the_loop_variable)
{
cout << the_loop_variable << '\n';
}

It uniformly made his code harder to read.

This is the difference between guidelines and rules. When there is a
rule that says "single letter variable names aren't allowed", then you
get the above nonsense. When there is a guideline that says "avoid
unnecessarily abbreviated variable names" or "use variable names to
reveal your intent", then loop variables like i or source/destination
variables for copying like s and d are just fine. They are idiomatic
and common enough that people aren't confused in reading the code.

Of course, idiomatic programming is something that you pick up from
reading other people's code and having a discussion about it. Anyone
can learn the syntax from a book describing the grammar, but they are
unlikely to pick up the idioms without reading realistic code. K&R
did a good job of explaining both syntax and idioms in "The C
Programming Language". Bjarne Stroustrup does a similarly good job in
"The C++ Programming Language". What a pity it is that so many people
refuse to listen to the creators of either language.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[Juha Nieminen]

Richard <legaliz...@mail.xmission.com> wrote:
> In 1978, my team went insane with "coding style" guidelines. One
> programmer started writing (in C++ identifier form)
>
> the_loop_variable
>
> instead of
>
> i

Of course the opposite of needless brevity in variable names is not to
make the variable names long but meaningless. They should be descriptive.

Compare:

for(int i = 0; i < amount; ++i)

for(int the_loop_variable = 0; the_loop_variable < amount; ++the_loop_variable)

for(int playerIndex = 0; playerIndex < amount; ++playerIndex)

Which one of those is most descriptive, even without seeing the context?

[Jorgen Grahn]

On Tue, 2015-11-10, Juha Nieminen wrote:
> Richard <legaliz...@mail.xmission.com> wrote:
>> In 1978, my team went insane with "coding style" guidelines. One
>> programmer started writing (in C++ identifier form)
>>
>> the_loop_variable
>>
>> instead of
>>
>> i
>
> Of course the opposite of needless brevity in variable names is not to
> make the variable names long but meaningless. They should be descriptive.
>
> Compare:
>
> for(int i = 0; i < amount; ++i)
>
> for(int the_loop_variable = 0; the_loop_variable < amount; ++the_loop_variable)
>
> for(int playerIndex = 0; playerIndex < amount; ++playerIndex)
>
> Which one of those is most descriptive, even without seeing the context?

I'm going to be obnoxious by pointing out that you cannot disregard
context. Short names, if they are any good, rely completely on
being obvious /in context/.

(I'm a bit worried by "amount", by the way. Doesn't seem to mix that
well with a loop index.)

(Meta: I know this subject has been beaten to death many times before.
But I still find it interesting, mostly because talking about it gives
insight into how other programmers think.)

[Öö Tiib]

On Tuesday, 10 November 2015 17:28:12 UTC+2, Jorgen Grahn wrote:
> On Tue, 2015-11-10, Juha Nieminen wrote:

...

> > Compare:
> >
> > for(int i = 0; i < amount; ++i)
> >
> > for(int the_loop_variable = 0; the_loop_variable < amount; ++the_loop_variable)
> >
> > for(int playerIndex = 0; playerIndex < amount; ++playerIndex)

...

> (I'm a bit worried by "amount", by the way. Doesn't seem to mix that
> well with a loop index.)

"amount" is perhaps result of Juha fixing magic number error '10' automatically
without much thinking from Richard's example:

for (int the_loop_variable = 0; the_loop_variable < 10; ++the_loop_variable)
{
cout << the_loop_variable << '\n';
}

That '10' does pass no reviews especially when author is using names like
'the_loop_variable'. Reviews of such code will be from unfriendly to extreme anal.
I have seen even coding standard extended to suggest against using various
ballast words (like "data", "item", "value", "the", "buffer", "variable", "list", "info")
in names thanks to such guys.

[Gareth Owen]

Jorgen Grahn <grahn...@snipabacken.se> writes:

> To me, that's fairly long /and/ content-less names. The way he uses
> underscores to separate words and ease readability is almost sadistic.
>
> But I suspect it made perfect sense to him, and was written in good
> faith.

Oh, I'm sure it was ... that doesn't make me feel any better tho.

[Jorgen Grahn]

On Tue, 2015-11-10, 嘱 Tiib wrote:
> On Tuesday, 10 November 2015 17:28:12 UTC+2, Jorgen Grahn wrote:
>> On Tue, 2015-11-10, Juha Nieminen wrote:
...

>> > for(int playerIndex = 0; playerIndex < amount; ++playerIndex)
>
> ...
>
>> (I'm a bit worried by "amount", by the way. Doesn't seem to mix that
>> well with a loop index.)
>
> "amount" is perhaps result of Juha fixing magic number error '10'
> automatically without much thinking from Richard's example:

Yes, I'm pretty sure it was something like that.
I guess that makes "amount" a good name -- because it made
me suspicious.

[Christopher Pisz]

On 11/8/2015 8:29 AM, Stefan Ram wrote:
> There are many ways, but today I want to do it the LISP way!
>
> #include <iostream>
> #include <ostream>
>
> constexpr bool isequal

> ( char const * const s,
> char const * const s1 )

> { return
> *s ?( *s1 ? *s == *s1 && isequal( s + 1, s1 + 1 ): 0 ):
> *s1 ? 0 : 1; }
>

> int main()
> { ::std::cout << isequal( "", "" )<< '\n';
> ::std::cout << isequal( "ab", "ab" )<< '\n';
> ::std::cout << isequal( "a", "a" )<< '\n';
>
> ::std::cout << isequal( "a", "b" )<< '\n';
> ::std::cout << isequal( "ab", "ac" )<< '\n';
> ::std::cout << isequal( "a", "" )<< '\n';
> ::std::cout << isequal( "", "a" )<< '\n'; }
>

#include <iostream>
#include <string>

int main
{
std::string one("one");
std::string two("two");

if( one == two )
{
std::cout << "Comparing strings with if else\n";
}
else
{
// Especially, when they are already using the standard library anyway
std::cout << "Why do people try to do things that are already done?\n";
}
}




--
I have chosen to troll filter/ignore all subthreads containing the
words: "Rick C. Hodgins", "Flibble", and "Islam"
So, I won't be able to see or respond to any such messages
---

[Öö Tiib]

Was it question or rhetoric question? I try to answer it anyway. :D

0) OP's reason "today I want to do it the LISP way!" you already quoted.

1) 'std::string' is incorrect.
1.a) Special 'std::basic_string<something_else_but_char>' is tricky
to make.

2) 'icu::UnicodeString' is heavyweight:
http://icu-project.org/apiref/icu4c/classicu_1_1UnicodeString.html
2.a) Packaging ICU is tricky:
http://userguide.icu-project.org/packaging

3) NIH policy. We do not release software that is "not invented here"!

etc. So people again roll their own 'ihibb::string'
("invented-here-in-bamboo-bush") text processing facilities.