online switch case generator for strings

[Thiago Adams]

Let's say you want to create a switch case for strings.

switch (key)
{
case "Sunday": break;
case "Monday":break;
case "Tuesday": break;
case "Wednesday": break;
case "Thursday": break;
case "Friday: break;
case "Saturday": break;
}

I created an simple online generator for this.
http://thradams.com/switchgenerator.html


For instance (given a list of string):

Input:
Sunday Monday Tuesday Wednesday Thursday Friday Saturday

Output:

int find(const char* key)
{
int result = -1;
switch (key[0])
{
case /*Friday*/ 'F' :
if (key[1]=='r' && key[2]=='i' && key[3]=='d' && key[4]=='a' && key[5]=='y' && key[6]=='\0') {
result = 0;
}
break;
case /*Monday*/ 'M' :
if (key[1]=='o' && key[2]=='n' && key[3]=='d' && key[4]=='a' && key[5]=='y' && key[6]=='\0') {
result = 1;
}
break;
case 'S':
switch (key[1])
{
case /*Saturday*/ 'a' :
if (key[2]=='t' && key[3]=='u' && key[4]=='r' && key[5]=='d' && key[6]=='a' && key[7]=='y' && key[8]=='\0') {
result = 2;
}
break;
case /*Sunday*/ 'u' :
if (key[2]=='n' && key[3]=='d' && key[4]=='a' && key[5]=='y' && key[6]=='\0') {
result = 3;
}
break;
default : break;
}
break;
case 'T':
switch (key[1])
{
case /*Thursday*/ 'h' :
if (key[2]=='u' && key[3]=='r' && key[4]=='s' && key[5]=='d' && key[6]=='a' && key[7]=='y' && key[8]=='\0') {
result = 4;
}
break;
case /*Tuesday*/ 'u' :
if (key[2]=='e' && key[3]=='s' && key[4]=='d' && key[5]=='a' && key[6]=='y' && key[7]=='\0') {
result = 5;
}
break;
default : break;
}
break;
case /*Wednesday*/ 'W' :
if (key[1]=='e' && key[2]=='d' && key[3]=='n' && key[4]=='e' && key[5]=='s' && key[6]=='d' && key[7]=='a' && key[8]=='y' && key[9]=='\0') {
result = 6;
}
break;
default : break;
}
return result;
}

[Bonita Montero]

Better use a unordered_map to a scalar value on which you do a switch.

[Thiago Adams]

On Monday, April 29, 2019 at 2:08:10 PM UTC-3, Bonita Montero wrote:
> Better use a unordered_map to a scalar value on which you do a switch.

Why do you think unordered_map is better?

[Christian Gollwitzer]

Am 29.04.19 um 19:03 schrieb Thiago Adams:

>
> Let's say you want to create a switch case for strings.
>
> switch (key)
> {
> case "Sunday": break;
> case "Monday":break;
> case "Tuesday": break;
> case "Wednesday": break;
> case "Thursday": break;
> case "Friday: break;
> case "Saturday": break;
> }
>
> I created an simple online generator for this.
> http://thradams.com/switchgenerator.html
>
>
> For instance (given a list of string):
>
> Input:
> Sunday Monday Tuesday Wednesday Thursday Friday Saturday

A classic tool for this task is the "perfect hash", gperf is one of the
tools. If I feed it with the same string, it outputs the code below. A
perfect hash tries to compute the correct answer in a small number of
arithmetic operations, which can be lead to very fast lookups. In cases
where performance does not matter, I'd prefer a simple linear scan. So:


std::string input = "Monday";
std::vector<std::string> wdays {"Sunday", "Monday", "tuesday", ...};
auto day = std::find(std::begin(input), std::end(input), wdays);

or perhaps using a std::map.

Or a chain of if/else blocks, which can be simplified using the
preprocessor:

#define OPTION(X) else if (input == #X)

if (false) { // NOP }
OPTION(Sunday) {
// do this
}
OPTION(Monday) {
// do that
}

...
#undef OPTION

Christian


============ code by gperf ====================================
/* C code produced by gperf version 3.0.3 */
/* Command-line:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/gperf
*/
/* Computed positions: -k'1' */

#if !((' ' == 32) && ('!' == 33) && ('"' == 34) && ('#' == 35) \
&& ('%' == 37) && ('&' == 38) && ('\'' == 39) && ('(' == 40) \
&& (')' == 41) && ('*' == 42) && ('+' == 43) && (',' == 44) \
&& ('-' == 45) && ('.' == 46) && ('/' == 47) && ('0' == 48) \
&& ('1' == 49) && ('2' == 50) && ('3' == 51) && ('4' == 52) \
&& ('5' == 53) && ('6' == 54) && ('7' == 55) && ('8' == 56) \
&& ('9' == 57) && (':' == 58) && (';' == 59) && ('<' == 60) \
&& ('=' == 61) && ('>' == 62) && ('?' == 63) && ('A' == 65) \
&& ('B' == 66) && ('C' == 67) && ('D' == 68) && ('E' == 69) \
&& ('F' == 70) && ('G' == 71) && ('H' == 72) && ('I' == 73) \
&& ('J' == 74) && ('K' == 75) && ('L' == 76) && ('M' == 77) \
&& ('N' == 78) && ('O' == 79) && ('P' == 80) && ('Q' == 81) \
&& ('R' == 82) && ('S' == 83) && ('T' == 84) && ('U' == 85) \
&& ('V' == 86) && ('W' == 87) && ('X' == 88) && ('Y' == 89) \
&& ('Z' == 90) && ('[' == 91) && ('\\' == 92) && (']' == 93) \
&& ('^' == 94) && ('_' == 95) && ('a' == 97) && ('b' == 98) \
&& ('c' == 99) && ('d' == 100) && ('e' == 101) && ('f' == 102) \
&& ('g' == 103) && ('h' == 104) && ('i' == 105) && ('j' == 106) \
&& ('k' == 107) && ('l' == 108) && ('m' == 109) && ('n' == 110) \
&& ('o' == 111) && ('p' == 112) && ('q' == 113) && ('r' == 114) \
&& ('s' == 115) && ('t' == 116) && ('u' == 117) && ('v' == 118) \
&& ('w' == 119) && ('x' == 120) && ('y' == 121) && ('z' == 122) \
&& ('{' == 123) && ('|' == 124) && ('}' == 125) && ('~' == 126))
/* The character set is not based on ISO-646. */
error "gperf generated tables don't work with this execution character
set. Please report a bug to <bug-gn...@gnu.org>."
#endif


#define TOTAL_KEYWORDS 7
#define MIN_WORD_LENGTH 6
#define MAX_WORD_LENGTH 9
#define MIN_HASH_VALUE 6
#define MAX_HASH_VALUE 13
/* maximum key range = 8, duplicates = 0 */

#ifdef __GNUC__
__inline
#else
#ifdef __cplusplus
inline
#endif
#endif
static unsigned int
hash (str, len)
register const char *str;
register unsigned int len;
{
static unsigned char asso_values[] =
{
14, 14, 14, 14, 14, 14, 14, 14, 14, 14,
14, 14, 14, 14, 14, 14, 14, 14, 14, 14,
14, 14, 14, 14, 14, 14, 14, 14, 14, 14,
14, 14, 14, 14, 14, 14, 14, 14, 14, 14,
14, 14, 14, 14, 14, 14, 14, 14, 14, 14,
14, 14, 14, 14, 14, 14, 14, 14, 14, 14,
14, 14, 14, 14, 14, 14, 14, 14, 14, 14,
4, 14, 14, 14, 14, 14, 14, 0, 14, 14,
14, 14, 14, 5, 0, 14, 14, 0, 14, 14,
14, 14, 14, 14, 14, 14, 14, 14, 14, 14,
14, 14, 14, 14, 14, 14, 14, 14, 14, 14,
14, 14, 14, 14, 14, 14, 14, 14, 14, 14,
14, 14, 14, 14, 14, 14, 14, 14, 14, 14,
14, 14, 14, 14, 14, 14, 14, 14, 14, 14,
14, 14, 14, 14, 14, 14, 14, 14, 14, 14,
14, 14, 14, 14, 14, 14, 14, 14, 14, 14,
14, 14, 14, 14, 14, 14, 14, 14, 14, 14,
14, 14, 14, 14, 14, 14, 14, 14, 14, 14,
14, 14, 14, 14, 14, 14, 14, 14, 14, 14,
14, 14, 14, 14, 14, 14, 14, 14, 14, 14,
14, 14, 14, 14, 14, 14, 14, 14, 14, 14,
14, 14, 14, 14, 14, 14, 14, 14, 14, 14,
14, 14, 14, 14, 14, 14, 14, 14, 14, 14,
14, 14, 14, 14, 14, 14, 14, 14, 14, 14,
14, 14, 14, 14, 14, 14, 14, 14, 14, 14,
14, 14, 14, 14, 14, 14
};
return len + asso_values[(unsigned char)str[0]];
}

const char *
in_word_set (str, len)
register const char *str;
register unsigned int len;
{
static const char * wordlist[] =
{
"", "", "", "", "", "",
"Monday",
"Tuesday",
"Thursday",
"Wednesday",
"Friday",
"Sunday",
"",
"Saturday"
};

if (len <= MAX_WORD_LENGTH && len >= MIN_WORD_LENGTH)
{
unsigned int key = hash (str, len);

if (key <= MAX_HASH_VALUE)
{
register const char *s = wordlist[key];

if (*str == *s && !strcmp (str + 1, s + 1))
return s;
}
}
return 0;
}
===================================================

[Bonita Montero]

>> Better use a unordered_map to a scalar value on which you do a switch.

> Why do you think unordered_map is better?

It's a short solution with a moderate performance.

[Thiago Adams]

On Monday, April 29, 2019 at 2:18:12 PM UTC-3, Christian Gollwitzer wrote:
> Am 29.04.19 um 19:03 schrieb Thiago Adams:
> >
> > Let's say you want to create a switch case for strings.
> >
> > switch (key)
> > {
> > case "Sunday": break;
> > case "Monday":break;
> > case "Tuesday": break;
> > case "Wednesday": break;
> > case "Thursday": break;
> > case "Friday: break;
> > case "Saturday": break;
> > }
> >
> > I created an simple online generator for this.
> > http://thradams.com/switchgenerator.html
> >
> >
> > For instance (given a list of string):
> >
> > Input:
> > Sunday Monday Tuesday Wednesday Thursday Friday Saturday
>
> A classic tool for this task is the "perfect hash", gperf is one of the
> tools. If I feed it with the same string, it outputs the code below. A
> perfect hash tries to compute the correct answer in a small number of
> arithmetic operations, which can be lead to very fast lookups. In cases
> where performance does not matter, I'd prefer a simple linear scan. So:

I did some measurements and the generated code is very good , for
instance compared with binary search.
The switch cases are ordered and the compiler will create a jump
table for it.

I found this very interesting post about switch optimizations.

http://lazarenko.me/switch/

Unfortunate, I didn't have time to compare with a lot of other
options. Thanks for putting the gperf code.

In my research I also found this algorithm for perfect hash.

https://github.com/mixu/perfect

> std::string input = "Monday";
> std::vector<std::string> wdays {"Sunday", "Monday", "tuesday", ...};
> auto day = std::find(std::begin(input), std::end(input), wdays);

It is much faster then binary_search.


Comparing with hash and gperf, if you need to add/delete new word manually
it is something possible (we don't need to use the generator)
and using hash or gperf is impossible to add a new work without
running the generator again.

[Bart]

For what, the gperf code?

I tried that, looking up "Thursday" 100M times, and it took 4.9 seconds
(unoptimised code). Your switch code took 1.4 seconds.

About 1/4 of the 4.9 is spent doing the strlen that that method requires.

This method also requires a strcmp, which I thought odd given that this
is supposed to a perfect hash; just length compare will do as the only
clashes are with names that are different lengths.

[Paavo Helde]

On 29.04.2019 20:03, Thiago Adams wrote:
>
> Let's say you want to create a switch case for strings.
>
> switch (key)
> {
> case "Sunday": break;
> case "Monday":break;
> case "Tuesday": break;
> case "Wednesday": break;
> case "Thursday": break;
> case "Friday: break;
> case "Saturday": break;
> }
>
> I created an simple online generator for this.
> http://thradams.com/switchgenerator.html
>
>
> For instance (given a list of string):
>
> Input:
> Sunday Monday Tuesday Wednesday Thursday Friday Saturday
>
> Output:
>
> int find(const char* key)
> {
> int result = -1;
> switch (key[0])
> {
> case /*Friday*/ 'F' :
> if (key[1]=='r' && key[2]=='i' && key[3]=='d' && key[4]=='a' && key[5]=='y' && key[6]=='\0') {
> result = 0;

This looks a bit like a manual hash map implementation. Might be
competitive if there are no large common prefixes.

For C++ support the input should be in terms of std::basic_string<T,C,A>
and the output should be an enum class.

[rick.c...@gmail.com]

On Monday, April 29, 2019 at 1:03:37 PM UTC-4, Thiago Adams wrote:
> Let's say you want to create a switch case for strings.

If you want the fastest solution, create 256-element entries
with targets based on the first character. If you know your
input will only be A-Z, a-z, 0-9, plus a few characters, then
you can create smaller ones, but basically you create some-
thing like this:

> switch (key)
> {
> case "Sunday": break;
> case "Monday":break;
> case "Tuesday": break;
> case "Wednesday": break;
> case "Thursday": break;
> case "Friday: break;
> case "Saturday": break;
> }
>

struct STarget
{
void (*targetFunc)(STarget* t, char* s, int len);
STarget next_level[256];
};

STarget topLevel[256] =
{
/* data goes here in order from slot 0 thru 255 */
/* 'F' */ { targetFunc, f_level },
/* 'M' */ { targetFunc, m_level },
/* 'S' */ { targetFunc, s_level },
/* 'T' */ { targetFunc, t_level },
/* 'W' */ { targetFunc, w_level },
/* Fill other / unused ones with this */
/* ??? */ { unknownFunc, NULL) },
};

STarget f_level[256] =
{
/* Here we deal with the second character */
/* 'r' */ { fridayFunc, NULL },
};

STarget m_level[256] =
{
/* Here we deal with the second character */
/* 'o' */ { mondayFunc, NULL },
};

STarget s_level[256] =
{
/* Here we deal with the second character */
/* 'a' */ { saturdayFunc, NULL },
/* 'u' */ { sundayFunc, NULL },
};

STarget t_level[256] =
{
/* Here we deal with the second character */
/* 'h' */ { thursdayFunc, NULL },
/* 'u' */ { tuesdayFunc, NULL },
};

STarget w_level[256] =
{
/* Here we deal with the second character */
/* 'e' */ { wednesdayFunc, NULL },
};

// You can do this with recursion or iteration here
void targetFunc(STarget* t, char* s, int len)
{
STarget* tNext;

tNext = t->next_level[*s];
tNext->targetFunc(tNext, s + 1, len - 1);
}

void sundayFunc(STarget* t, char* s, int len)
{
}

void mondayFunc(STarget* t, char* s, int len)
{
}

void tuesdayFunc(STarget* t, char* s, int len)
{
}

void wednesdayFunc(STarget* t, char* s, int len)
{
}

void thursdayFunc(STarget* t, char* s, int len)
{
}

void fridayFunc(STarget* t, char* s, int len)
{
}

void saturdayFunc(STarget* t, char* s, int len)
{
}

void unknownFunc(STarget* t, char* s, int len)
{
}

void main(int argc, char* argv[])
{
// Assume the command line has the word to search
targetFunc(topLevel, argv[1], strlen(argv[1]));
}

Something like that, untested, but I use this same logic for how
to decode assembly instructions. Since the x86 opcode map goes
like this (one-byte, two-byte, or more-bytes, I can branch to
the correct handlers based on the first byte, and then sometimes
on the second byte, before I have to get down to trying out bit
combinations, or looking at sub-byte bit combos to determine the
instruction).

And of course, in cases where there's only one target, like
Monday, Wednesday, and Friday, you can immediately branch to
those if you want, and do the rest of the comparison there.

This way takes up more memory, but it does allow you to get to
the target almost immediately without multiple compares.

It may be useful if there are many common names for a given
letter, and in the case of branching off to the correct first-
letter determiner by the single branch, it will be faster in
that regard even if you use only one level.

You can generate this code with your generator, so that it will
use an amalgam of your algorithm, and this algorithm, based on
how many things you're looking for. You can also change it to
use only alphanumeric + a few other characters and make the
lists smaller, but you'll have to adjust your indexes down, and
that increases processing time a little ... but not much. You
can actually use a first-level translator for that, which takes
the raw up-to-255 value as input, and maps it through that level
of translation to its adjusted index entry, which you can also
generate on-the-fly based on your observed data sets and needs.

--
Rick C. Hodgin

[Mr Flibble]

And Satan invented fossils, yes?

/Flibble

--
“You won’t burn in hell. But be nice anyway.” – Ricky Gervais

“I see Atheists are fighting and killing each other again, over who
doesn’t believe in any God the most. Oh, no..wait.. that never happens.” –
Ricky Gervais

"Suppose it's all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a
world that is so full of injustice and pain. That's what I would say."

[Paavo Helde]

On 29.04.2019 20:44, Bart wrote:
>
> I tried that, looking up "Thursday" 100M times, and it took 4.9 seconds
> (unoptimised code). Your switch code took 1.4 seconds.

It is meaningless to compare the speed of unoptimized code, especially
in C++.

[rick.c...@gmail.com]

On Monday, April 29, 2019 at 2:49:25 PM UTC-4, Mr Flibble wrote:
> And Satan invented fossils, yes?

I'd answer, but you've given much evidence you won't listen to the
answer.

Other people, those who may actually be interested in the answer,
have already read my posts and have seen the proper response
(probably more than once).

--
Rick C. Hodgin

[Bart]

I would say the opposite. Especially as in this case, optimised code
took zero seconds. It takes extra effort to make allowances for
optimising compilers and makes sure you are comparing how long it takes
to do a task, rather than how long it takes NOT to do it.

But if I do that now, then the difference between hash/switch lookups is
3.5:1 for gcc-O3, compared with 3.2:1 using the original compiler, and
2.5:1 using gcc-O0.

The perfect hash version is still slower.

[Paavo Helde]

On 29.04.2019 22:19, Bart wrote:
> On 29/04/2019 19:58, Paavo Helde wrote:
>> On 29.04.2019 20:44, Bart wrote:
>>>
>>> I tried that, looking up "Thursday" 100M times, and it took 4.9 seconds
>>> (unoptimised code). Your switch code took 1.4 seconds.
>>
>> It is meaningless to compare the speed of unoptimized code, especially
>> in C++.
>
> I would say the opposite. Especially as in this case, optimised code
> took zero seconds. It takes extra effort to make allowances for
> optimising compilers and makes sure you are comparing how long it takes
> to do a task, rather than how long it takes NOT to do it.

Right, it is definitely easier to look for the lost wallet under street
lamps only ;-)

>
> But if I do that now, then the difference between hash/switch lookups is
> 3.5:1 for gcc-O3, compared with 3.2:1 using the original compiler, and
> 2.5:1 using gcc-O0.
>
> The perfect hash version is still slower.

Thanks for the numbers, these are now informative!

[Christian Gollwitzer]

Am 29.04.19 um 19:44 schrieb Bart:

> For what, the gperf code?
>
> I tried that, looking up "Thursday" 100M times, and it took 4.9 seconds
> (unoptimised code). Your switch code took 1.4 seconds.
>
> About 1/4 of the 4.9 is spent doing the strlen that that method requires.
>
> This method also requires a strcmp, which I thought odd given that this
> is supposed to a perfect hash; just length compare will do as the only
> clashes are with names that are different lengths.

The strcmp is necessary to check that the input was indeed part of the
keywords, so that when you input "xxx" and it hashes to one of the
menaingful slots, it doesn't get interpreted as "Wednesday"
accidentally. The hash is only perfect over the set of input values. As
to the speed, I don't know, either it is only advantageous for larger
numbers of keywords or lists of words that are not separated as easily,
or perfect hashes are not as good in practice as they are in theory.

Maybe also looking up only always the same string is not a good
benchmark, because of the jump prediction of the processor.

Christian

>

[Bart]

On 29/04/2019 22:24, Christian Gollwitzer wrote:
> Am 29.04.19 um 19:44 schrieb Bart:
>> For what, the gperf code?
>>
>> I tried that, looking up "Thursday" 100M times, and it took 4.9
>> seconds (unoptimised code). Your switch code took 1.4 seconds.
>>
>> About 1/4 of the 4.9 is spent doing the strlen that that method requires.
>>
>> This method also requires a strcmp, which I thought odd given that
>> this is supposed to a perfect hash; just length compare will do as the
>> only clashes are with names that are different lengths.
>
> The strcmp is necessary to check that the input was indeed part of the
> keywords, so that when you input "xxx" and it hashes to one of the
> menaingful slots, it doesn't get interpreted as "Wednesday"
> accidentally. The hash is only perfect over the set of input values. As
> to the speed, I don't know, either it is only advantageous for larger
> numbers of keywords or lists of words that are not separated as easily,
> or perfect hashes are not as good in practice as they are in theory.

I can make it nearly double its speed by tightening it up: just doing
strcmp on the full string, rather then checking the first characters
then strcmp on the rest. And by predetermining the search string length.

(Note: that search does not return the 0..6 index of the original switch
version, to denote Monday to Sunday, only the original string. So here
I'm only testing for inclusion of an arbitrary string in the set, not
which one.)

However, a version simply doing a linear search (and which does return
the index) isn't that much worse than my tweaked perfect hash version
(it had been faster).

I think this data set is just too small to show the advantages of
different approaches.

[Kenny McCormack]

In article <9f7d8f95-92e7-4af8...@googlegroups.com>,

<rick.c...@gmail.com> wrote:
>On Monday, April 29, 2019 at 2:49:25 PM UTC-4, Mr Flibble wrote:
>> And Satan invented fossils, yes?
>
>I'd answer, but you've given much evidence you won't listen to the
>answer.

That's never stopped you before; why start now?

Nobody listens to any of your crap - except to mock it.

--
Mike Huckabee has yet to consciously uncouple from Josh Duggar.

[rick.c...@gmail.com]

On Tuesday, April 30, 2019 at 9:16:00 AM UTC-4, Kenny McCormack wrote:
> Nobody listens to any of your crap - except to mock it.

That's how you operate, Kenny, so it's natural for you to think
that's how all other people are toward others. They aren't.

People contact me privately and tell me that my posts have been
moving, inspirational, they ask me questions about faith, etc.

The posts I've made have reached people ... and it's reached the
people who it was intended for. The rest of the people mocking
my posts are already self-condemned and may never be saved.

-----
Now, would you like to now reply with a signature that quotes me
out of context? One applying effort toward harming my name and
reputation as a true and devout Christian?

You, Kenny, self-condemn your own soul as well. And the sad thing
is ... it doesn't have to be that way. But you make it that way
by your hatred of God, hatred of truth, and love of sin.

--
Rick C. Hodgin

[Kenny McCormack]

In article <e9074159-9eaa-4d6b...@googlegroups.com>,

<rick.c...@gmail.com> wrote:
>On Tuesday, April 30, 2019 at 9:16:00 AM UTC-4, Kenny McCormack wrote:
>> Nobody listens to any of your crap - except to mock it.
>
>That's how you operate, Kenny, so it's natural for you to think
>that's how all other people are toward others. They aren't.

You're a liar.

End of story.

--
It's possible that leasing office space to a Starbucks is a greater liability
in today's GOP than is hitting your mother on the head with a hammer.

[rick.c...@gmail.com]

On Tuesday, April 30, 2019 at 9:44:06 AM UTC-4, Kenny McCormack wrote:
> In article <e9074159-9eaa-4d6b...@googlegroups.com>,
> <rick.c...@gmail.com> wrote:
> >On Tuesday, April 30, 2019 at 9:16:00 AM UTC-4, Kenny McCormack wrote:
> >> Nobody listens to any of your crap - except to mock it.
> >
> >That's how you operate, Kenny, so it's natural for you to think
> >that's how all other people are toward others. They aren't.
>
> You're a liar.
>
> End of story.

I am not a liar. You mock most everyone you reply to, Kenny.
Even in the posts where you provide some help there is still
a mocking signature.

Jesus comes to the people of this world, all of them, with His
arms outstretched (literally on the cross), saying "Come to me,
all you who are heavy laden and I will give you rest for your
souls." He offers to forgive people their sin, and to give
them eternal life in Heaven.

What He offers is the most desirable thing imaginable for all
people everywhere ... yet because people love darkness more
than light they flee from Him, flee from His offer.

The Bible is available at multiple places, Kenny. You probably
even have one on a shelf somewhere, and if not there's bible.com
and 500 other Bible-related websites.

Anyone entering into Hell will be by their own personal choice
to go there, and not for any other reason. Each person entering
Hell will have no but themselves to blame.

--
Rick C. Hodgin

PS -- Jesus told us that because the people of the world hated Him,
they would hated by the world. Seems He was right once again.

[Kenny McCormack]

In article <5d3252ec-1599-4227...@googlegroups.com>,
<rick.c...@gmail.com> babbled:

>> >That's how you operate, Kenny, so it's natural for you to think
>> >that's how all other people are toward others. They aren't.
>>
>> You're a liar.
>>
>> End of story.
>
>I am not a liar. You mock most everyone you reply to, Kenny.

What part of "End of story" is tripping you up?

--
I've been watching cat videos on YouTube. More content and closer to
the truth than anything on Fox.

[rick.c...@gmail.com]

On Tuesday, April 30, 2019 at 11:06:45 AM UTC-4, Kenny McCormack wrote:
> In article <5d3252ec-1599-4227...@googlegroups.com>,
> <rick.c...@gmail.com> babbled:
> >> >That's how you operate, Kenny, so it's natural for you to think
> >> >that's how all other people are toward others. They aren't.
> >> You're a liar.
> >> End of story.
> >I am not a liar. You mock most everyone you reply to, Kenny.
>
> What part of "End of story" is tripping you up?

Satan likes to put periods on things, to divide those who shine
the light from those who live in darkness. It's one of his
most effective tools because once the voice shining the light
is removed from input into one's life and ears ... then that
darkness can once again extend its clutches around the indi-
vidual and keep them on the wrong path, the one that leads to
their soul's destruction in the judgment.

Hopefully you'll learn: Things are true for the reasons they
are true, Kenny, and not for other reasons.

--
Rick C. Hodgin

[rick.c...@gmail.com]

On Tuesday, April 30, 2019 at 11:06:45 AM UTC-4, Kenny McCormack wrote:
> <rick.c...@gmail.com> babbled:

> >Kenny McCormack wrote:
> >> You're a liar.
> >> End of story.
> >I am not a liar. You mock most everyone you reply to, Kenny.
>
> What part of "End of story" is tripping you up?

Something you need to learn about truth, Kenny, is it's not like
lies. The truth exists as it is always and only. It speaks with
one voice. It doesn't have alternate takes or perspectives. It
is solid, invincible, always victorious in every situation.

It is that truth that will defeat everyone who has sin still
charged to their soul when they leave this world. It will be
the truth of God's laws resulting in judgment and condemnation
for the souls which retain sin.

Jesus came to take our sin away so we can endure that total
scrutiny of truth in that final day. Without Him, we will all
fail the test and will be found guilty. Only with Him taking
our sin away from us are we able to be set free from that same
judgment and condemnation that will fall upon those who do not
have their sin taken away.

Jesus is not a religion.
Jesus is not a joke.
Jesus is truth, which makes Him solid, invincible, and always
victorious in every situation, including the day of your judg-
ment if you are not saved before you leave this world. He will
be glorified in every soul's destruction on that day, the same
as He will be glorified in how He gave life to all who would
receive it.

Every knee shall bow, and every tongue shall confess that Jesus
Christ is Lord over all, and all to the glory of God the Father.

You can read that personally as:
Kenny's knee will bow, and Kenny's tongue shall confess that
Jesus Christ is Lord over all, and it will be to the glory of
God the Father ... whether you do that in your repentance and
salvation, or in your rebellion against Him and your soul's
destruction in Hell.

The truth is not like other things. You must come to understand
what it is you're up against. You will all before it 100% every
time, Kenny. The only winning move is to recognize that while
truth will destroy your soul in Hell over sin, that same truth
is always willing to forgive your sin and set you free JUST FOR
THE ASKING. Only a rebellious fool from Hell would ignore that
free offer of salvation and choose to die a coward's death in
the unending burning flames. Only a total and complete rebellious,
idiotic fool.

--
Rick C. Hodgin

[rick.c...@gmail.com]

On Tuesday, April 30, 2019 at 11:06:45 AM UTC-4, Kenny McCormack wrote:
> What part of "End of story" is tripping you up?

From the 1700s:

https://mobile.twitter.com/WhitefieldG/status/1123229014326300672

"Jesus died to save such as you; he is full of compassion;
and if you go to him, as poor, lost, undone sinners, Jesus
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
will give you his spirit; you shall live and reign, and
reign and live, you shall love and live, and live and love
with this Jesus to all eternity."

The proud will die in rebellion and enter into Hell.

The humble will die in repentance and will be shown grace and mercy.

That is truth.

--
Rick C. Hodgin

[Mr Flibble]

Nonsense.
A) Your bible is false.
B) Your god the existence of which is predicated on your bible being true
is, given (A), also false.

[Mr Flibble]

[Mr Flibble]

And Satan invented fossils, yes?

[Bart]

On 30/04/2019 18:22, Mr Flibble wrote:

> And Satan invented fossils, yes?

FFS. We got off lightly last time (an actual miracle). You really want
another spate of posts full of religious crap? You seem to like lighting
the touch-paper.

Just let it go.

[woodb...@gmail.com]

On Monday, April 29, 2019 at 12:03:37 PM UTC-5, Thiago Adams wrote:
> Let's say you want to create a switch case for strings.
>

> switch (key)
> {
> case "Sunday": break;
> case "Monday":break;
> case "Tuesday": break;
> case "Wednesday": break;
> case "Thursday": break;
> case "Friday: break;
> case "Saturday": break;
> }
>

> I created an simple online generator for this.
> http://thradams.com/switchgenerator.html
>
>

Best wishes for this. When I started with on-line code
generation, I had a web interface also. Eventually I
was able to develop a command line interface:
https://github.com/Ebenezer-group/onwards
. You are welcome to use code/ideas from there if
you decide to further automate things. For example,
users could contact your site via their build process
without having to go to your site and click anything
or copy/paste anything.


Brian
Ebenezer Enterprises - Enjoying programming again.
http://webEbenezer.net

[Öö Tiib]

Bart, you are often searching apricots from apple tree.
Just let it go.

[Thiago Adams]

This seems to be more a commercial/licensing approach than practical.

For licensing, instead of compute the result on the cloud you could
just check the license and generated everything locally.

Something like this (generation on the cloud) could be used for top
secret technology where you don't want to distribute the code even
in binary form or if the installation or use of the binary forms were
too complicated.

For my case, everything is simple and free and web is a
good option.

I also have a C-source-to-source compiler where I could implement
the switch case for strings and generate the code.

How could (in terms of syntax) switch for strings be part of
the language?


Because pointer as also numbers I think the direct syntax is not possible.

switch (psz)
{
case "A": break;
}

?

switch "" (psz)
{
case "A": break;
}


Some languages like C#, Swift and I guess Pascal have this feature.

[woodb...@gmail.com]

It wasn't that many years ago that the "Ten Commandments"
were posted in US classrooms. Now though, many, including
governments, are focused on stealing technologies from
others. So I'm happy with this fortress/cloud environment.
Without it socialists would run me out of business. I
remember Obama saying something like: you didn't build that.
Really? Who do you think did? Rudolph the Red-Nosed Reindeer.


Brian
Ebenezer Enterprises
http://webEbenezer.net