Any way to make this code more compact, and/or be able to change at runtime?

[James Kanze]

Protoman wrote in message...

Simpler than a five line character translator? Good luck with that.

Well, character translation per se is usually only one line:
char translated = translationMap[ original ] ;
.

The real question, however, is: why a 36 character encoder? Why
not 256 (or more correctly, UCHAR_MAX+1)?

For the rest, there's a complete implementation of encode/decode
using a Enigma machine at my site
(http://kanze.james.neuf.fr/code-en.html, the executable
"crypt"). From the man page for it: "Isn't really useful for
anything. It's not secure enough for real encryption, and is a
lot more complicated than a simple rot13 for the cases where it
would be sufficient." But he's welcome to study it, and even
copy anything in it he wants.

Actually, it's only a three line function if you pass in the string refs.

char plugboard( char Char, std::string const &Values,
std::string const &Characters ){
std::size_t index( Characters.find( Char ) );
if( std::string::npos == index ){ return ' ';}
return Values.at( index );
}

Wouldn't it be more idiomatic to define a Translator functional
object, and let the user use std::transform? (It's certainly
more fashionable. You just aren't "in" unless you can work in
some templates and the standard algorithms. Whether it's a
better solution is, of course, a different question.)

 

[BobR]

/* """ Hi James,

Protoman wrote in message...

Simpler than a five line character translator? Good luck with that.

Well, character translation per se is usually only one line:
char translated = translationMap[ original ] ;
.
""" */

Hah! Where is your check for the validity of 'original'? <G>

/* """
The real question, however, is: why a 36 character encoder? Why
not 256 (or more correctly, UCHAR_MAX+1)?
""" */

Did you see the original post 'plugboard()'? Would you want to maintain 256
of those? :-}

/* """
For the rest, there's a complete implementation of encode/decode
using a Enigma machine at my site
(http://kanze.james.neuf.fr/code-en.html, the executable
"crypt"). From the man page for it: "Isn't really useful for
anything. It's not secure enough for real encryption, and is a
lot more complicated than a simple rot13 for the cases where it
would be sufficient." But he's welcome to study it, and even
copy anything in it he wants.

Actually, it's only a three line function if you pass in the string refs.
char plugboard( char Char, std::string const &Values,
std::string const &Characters ){
std::size_t index( Characters.find( Char ) );
if( std::string::npos == index ){ return ' ';}
return Values.at( index );
}

Wouldn't it be more idiomatic to define a Translator functional
object, and let the user use std::transform? (It's certainly
more fashionable. You just aren't "in" unless you can work in
some templates and the standard algorithms. Whether it's a
better solution is, of course, a different question.)
""" */

I agree.
Not sure if Protoman is doing homework, self-study or just a personal
project. Don't want to get too far ahead of the task (learning).
( hint: (s)he keeps using char arrays instead of std::string, std::vector,
etc.).

 

[Protoman]

/* """ Hi James,

Protoman wrote in message...
Simpler than a five line character translator? Good luck with that.

Well, character translation per se is usually only one line:
char translated = translationMap[ original ] ;
.
""" */

Hah! Where is your check for the validity of 'original'? <G>

/* """
The real question, however, is: why a 36 character encoder? Why
not 256 (or more correctly, UCHAR_MAX+1)?
""" */

Did you see the original post 'plugboard()'? Would you want to maintain 256
of those? :-}

/* """
For the rest, there's a complete implementation of encode/decode
using a Enigma machine at my site
(http://kanze.james.neuf.fr/code-en.html, the executable
"crypt"). From the man page for it: "Isn't really useful for
anything. It's not secure enough for real encryption, and is a
lot more complicated than a simple rot13 for the cases where it
would be sufficient." But he's welcome to study it, and even
copy anything in it he wants.

Actually, it's only a three line function if you pass in the string refs.
char plugboard( char Char, std::string const &Values,
std::string const &Characters ){
std::size_t index( Characters.find( Char ) );
if( std::string::npos == index ){ return ' ';}
return Values.at( index );
}

Wouldn't it be more idiomatic to define a Translator functional
object, and let the user use std::transform? (It's certainly
more fashionable. You just aren't "in" unless you can work in
some templates and the standard algorithms. Whether it's a
better solution is, of course, a different question.)
""" */

I agree.
Not sure if Protoman is doing homework, self-study or just a personal
project. Don't want to get too far ahead of the task (learning).
( hint: (s)he keeps using char arrays instead of std::string, std::vector,
etc.).

It's a personal project.

 

[Protoman]

James Kanze <[email protected]> wrote in message...

/* """ Hi James,

Well, character translation per se is usually only one line:
char translated = translationMap[ original ] ;
.
""" */

Hah! Where is your check for the validity of 'original'? <G>

/* """
The real question, however, is: why a 36 character encoder? Why
not 256 (or more correctly, UCHAR_MAX+1)?
""" */

Did you see the original post 'plugboard()'? Would you want to maintain 256
of those? :-}

/* """
For the rest, there's a complete implementation of encode/decode
using a Enigma machine at my site
(http://kanze.james.neuf.fr/code-en.html, the executable
"crypt"). From the man page for it: "Isn't really useful for
anything. It's not secure enough for real encryption, and is a
lot more complicated than a simple rot13 for the cases where it
would be sufficient." But he's welcome to study it, and even
copy anything in it he wants.

Wouldn't it be more idiomatic to define a Translator functional
object, and let the user use std::transform? (It's certainly
more fashionable. You just aren't "in" unless you can work in
some templates and the standard algorithms. Whether it's a
better solution is, of course, a different question.)
""" */

I agree.
Not sure if Protoman is doing homework, self-study or just a personal
project. Don't want to get too far ahead of the task (learning).
( hint: (s)he keeps using char arrays instead of std::string, std::vector,
etc.).

It's a personal project.- Hide quoted text -

- Show quoted text -

OK, I'm just going to return to my massive if...else block for now.
Now, when I did that, it encrypts, but it doesn't decrypt:

Rotor settings: QWERTYUIOP
Cleartext: DELTA
Ciphertext: PSS66

Rotor settings: QWERTYUIP
Ciphertext: PSS66
Cleartext: M7B1H

What do you think went wrong?

 

[BobR]

OK, I'm just going to return to my massive if...else block for now.
Now, when I did that, it encrypts, but it doesn't decrypt:

Rotor settings: QWERTYUIOP
Cleartext: DELTA
Ciphertext: PSS66

Rotor settings: QWERTYUIP
Ciphertext: PSS66
Cleartext: M7B1H

What do you think went wrong?

Don't know. I'd suggest the debugger, BUT, you'd be there for days/weeks
trying to find the bug. Maybe put a few 'cout' in the code to trace where it
goes wrong.

We'd need to see your current code to tell ( and it seems to big to post
here).

If using your original post code, double check that these two lines are
intact:

else if(Char=='J') return 'O';
// ....
else if(Char=='O') return 'J';

 

[Thomas J. Gritzan]

OK, I'm just going to return to my massive if...else block for now.
Now, when I did that, it encrypts, but it doesn't decrypt:

Rotor settings: QWERTYUIOP
Cleartext: DELTA
Ciphertext: PSS66

Rotor settings: QWERTYUIP
Ciphertext: PSS66
Cleartext: M7B1H

What do you think went wrong?

Are the two settings supposed to be the same?

Rotor settings: QWERTYUIOP
Rotor settings: QWERTYUIP

There's an 'O' in the first.

 

[Protoman]

Don't know. I'd suggest the debugger, BUT, you'd be there for days/weeks
trying to find the bug. Maybe put a few 'cout' in the code to trace where it
goes wrong.

We'd need to see your current code to tell ( and it seems to big to post
here).

If using your original post code, double check that these two lines are
intact:

else if(Char=='J') return 'O';
// ....
else if(Char=='O') return 'J';

Yeah, they are, and I'm usig my original code. So I don't know.

 

[James Kanze]

Protoman wrote in message...
B/c I want something simpler than that.
Simpler than a five line character translator? Good luck with that.

Well, character translation per se is usually only one line:
char translated = translationMap[ original ] ;
.

Hah! Where is your check for the validity of 'original'? <G>

The type of original is unsigned char, and the translationMap
has UCHAR_MAX + 1 entries.

Seriously, every time I've done this, original has been an int,
read using streambuf::sgetc or something similar, and I have
already checked for EOF. If it were something along the lines a
dereferenced std::string::const_iterator, I'd cast it to
unsigned char (although once in a very distant past, I
subtracted CHAR_MIN from it, and rearranged the table
accordingly).

Did you see the original post 'plugboard()'? Would you want to
maintain 256 of those? :-}

I wouldn't even want to maintain 36 of them. I think we
agree that that's not the way to go.

I agree.
Not sure if Protoman is doing homework, self-study or just a
personal project. Don't want to get too far ahead of the task
(learning). ( hint: (s)he keeps using char arrays instead of
std::string, std::vector, etc.).

That's always a problem when answering a question here. I'd
like to be able to say that the fact that he keeps using C style
arrays is a sign that he is experienced; that a beginner would
automatically use std::string and std::vector, and perhaps not
even know that C style arrays existed. But I know too well how
C++ is often taught to believe that. (I think my implementation
still uses C style arrays. I wrote it more than 15 years
ago, and I don't think I've updated it much since then.)

As for his goals: that's why I posted the extract from my
documentation. He shouldn't get the idea that this is an
effective encryption method. (But it is fun and instructive to
implement.)

 

[Protoman]

Are the two settings supposed to be the same?


There's an 'O' in the first.

That was a typing error when I posted. I don't think that's the
problem.