Could someone explain this code for me please...

This is a discussion on Could someone explain this code for me please... within the C++ Programming forums, part of the General Programming Boards category; I'm not sure what I'm trying to accomplish, hell I dont even know how true encryption is suppose to work. ...

  1. #76
    Dae
    Dae is offline
    Deprecated Dae's Avatar
    Join Date
    Oct 2004
    Location
    Canada
    Posts
    1,034
    I'm not sure what I'm trying to accomplish, hell I dont even know how true encryption is suppose to work. I'm going to put things on halt until I get some concepts to work with now that I understand bitfields got JoshR's union idea down pact. Gonna go look up some tutorials.

    I uses JoshR's example to show how the bitfield struct in the union could be used to mix around the binary of the other methods in the union. No idea for what purpose, honestly.

    Code:
    #include <iostream>
    #include <cstdio>
    
    using namespace std;
    
    struct char4 {
            unsigned int a:2;
            unsigned int b:2;
            unsigned int c:2;
            unsigned int d:2;
    };
    
    union TEST {
            char A[]; // the data to binary edit
            char4 bits[]; // the bitfields used to do so
    };
    
    int main() {
        TEST ch;
        strcpy(ch.A, "This is a string.\0");
    
        cout << "Size of TEST:  (unable to determine atm)" << endl;;
        cout << "String A:   " << strlen(ch.A) << endl;
    
        // change every second bit, if its 1 it becomes 0, or visa-versa
        for( int x = 0; x < strlen(ch.A); ++x ) {
           ch.bits[x].a = ch.bits[x].a ^ (1 << 1);
           ch.bits[x].b = ch.bits[x].b ^ (1 << 1);
           ch.bits[x].c = ch.bits[x].c ^ (1 << 1);
           ch.bits[x].d = ch.bits[x].d ^ (1 << 1);
        }
    
        cout << "String A:   " << ch.A << endl;
    
        // return the string back to the way it was
        for( int x = 0; x < strlen(ch.A); ++x ) {
           ch.bits[x].a = ch.bits[x].a ^ (1 << 1);
           ch.bits[x].b = ch.bits[x].b ^ (1 << 1);
           ch.bits[x].c = ch.bits[x].c ^ (1 << 1);
           ch.bits[x].d = ch.bits[x].d ^ (1 << 1);
        }
    
        cout << "String A:   " << ch.A << endl;
        cin.get();
    }
    A std::string wouldnt work because of errors, so I used a char string. If you had some class that imported data and assigned it to some space just like where that char string is.. Might work, might not work, definetly needs expansion but in any case thats 1 thing I was trying to do.. but dont care to spend anymore time mixing the binary around for fun because I know this encryption could be more efficient if I knew more concepts.

    Ah apparently using XOR you could encrypt it using anything, so I guess this implement might not be so good.. Got anymore ideas JoshR? I didnt know what you were talking about at the beginning of this thread because I had never seen this before, but I remember at the beginning of the thread you were on about a union and XOR and thats finally where I am
    Last edited by Dae; 06-24-2005 at 05:29 AM.
    Warning: Have doubt in anything I post.

    GCC 4.5, Boost 1.40, Code::Blocks 8.02, Ubuntu 9.10 010001000110000101100101

  2. #77
    *this
    Join Date
    Mar 2005
    Posts
    498
    Strings should work, im working on an algorithm right now that i call the stairway method where it shifts the blocks of 8 bits around an array (char* or string) in a stairway fassion, then later i will do some XOR and other bit tricks. I am working on a template that allows either string or char* and decides how to calculate the size accordingly. Ill post some code once i make significant progress, just working on pseudocode right now.

    btw
    Code:
    for( int x = 0; x < strlen(ch.A); ++x ) {
    you should calculate the string lenght ( strlen(ch.A) ) outside of the loop because it calls the function that has to use an algorithm and calculate it each time it is looped so better to do it once.

  3. #78
    *this
    Join Date
    Mar 2005
    Posts
    498
    lol its gonna take me a while, i like to work out the details on paper first, like the theory behind it etc... this is all i have so far:
    Code:
    #include <iostream>
    using namespace std;
    
    ///////////////////////////////////////////
    typedef unsigned int CHAR32;
    ///////////////////////////////////////////
    struct BITBLOCKS {
       unsigned int    one:8;
       unsigned int    two:8;
       unsigned int  three:8;
       unsigned int   four:8;
    };
    ///////////////////////////////////////////
    typedef union {
       unsigned int  value;
       BITBLOCKS      bits;
    } BITUNION;
    ///////////////////////////////////////////
    
    int main() {
    
       cin.get();
       return 0;
    }

  4. #79
    Carnivore ('-'v) Hunter2's Avatar
    Join Date
    May 2002
    Posts
    2,879
    >>A std::string wouldnt work because of errors
    While searching for a reference I saw recently explaining in detail why you can't use complex classes inside unions, I stumbled across this:
    Unions are not always portable, due to the way different processors store bytes in memory. Our version of itoh(), for instance, runs correctly on IntelĂ processors, but displays the bytes in reverse order on SPARCĂ-based workstations.
    So, yeah, looks like it'd take a bit more work to get the direct bit-access to work in a foolproof manner (probably can solve this using compiler-defined macros that will somehow identify what order the bits are stored in).

    *EDIT: JoshR, just so you know, since your bitfields are all 8 bits you might as well use unsigned char.
    Just Google It. √

    (\ /)
    ( . .)
    c(")(") This is bunny. Copy and paste bunny into your signature to help him gain world domination.

  5. #80
    *this
    Join Date
    Mar 2005
    Posts
    498
    Ya i just used the same types i saw before, good idea for chars, wont waste bytes.

    Hmm thats interesting about unions...Brings a lot of thoughts to mind.

  6. #81
    Dae
    Dae is offline
    Deprecated Dae's Avatar
    Join Date
    Oct 2004
    Location
    Canada
    Posts
    1,034
    Quote Originally Posted by JoshR
    Ya i just used the same types i saw before, good idea for chars, wont waste bytes.
    Wont waste bytes either way, the reason he suggested to use a char is so you dont call a bitfield operation (takes more time than using a char) and you cant retrieve the memory address of the bitfields, with a char you can.

    Hmm thats interesting about unions...Brings a lot of thoughts to mind.
    Yeah what Hunter said is why I cant use a string instead of a char*, its a complex class, so it gives you errors about having a constructor and deconstructor and such when you use a string.

    Im now just making a program to import text files and encrypt/decrypt them, because it was more fun seeing the effects that way . Throw in a XOR and a complement~ in there, but still having a trouble finding something to encrypt thats based on the file (ie. bytes in the file, length of the file title, etc.) but those values can change so that wouldnt decrypt well.

    It says the best way to encrypt something is to compress it first, agh not sure how to do large scale import file compressions so off to google.
    Warning: Have doubt in anything I post.

    GCC 4.5, Boost 1.40, Code::Blocks 8.02, Ubuntu 9.10 010001000110000101100101

  7. #82
    Dae
    Dae is offline
    Deprecated Dae's Avatar
    Join Date
    Oct 2004
    Location
    Canada
    Posts
    1,034
    Quote Originally Posted by JoshR
    Code:
    for( int x = 0; x < strlen(ch.A); ++x ) {
    you should calculate the string lenght ( strlen(ch.A) ) outside of the loop because it calls the function that has to use an algorithm and calculate it each time it is looped so better to do it once.
    Oh, thanks for pointing that out!
    Warning: Have doubt in anything I post.

    GCC 4.5, Boost 1.40, Code::Blocks 8.02, Ubuntu 9.10 010001000110000101100101

  8. #83
    ATH0 quzah's Avatar
    Join Date
    Oct 2001
    Posts
    14,826
    Quote Originally Posted by Hunter2
    I stumbled across this:
    Unions are not always portable, due to the way different processors store bytes in memory. Our version of itoh(), for instance, runs correctly on IntelĂ processors, but displays the bytes in reverse order on SPARCĂ-based workstations.
    So, yeah, looks like it'd take a bit more work to get the direct bit-access to work in a foolproof manner (probably can solve this using compiler-defined macros that will somehow identify what order the bits are stored in).
    Actually you need to not quote stupid people. This has nothing to do with unions at all. Unions are portable. The person you quoted is an idiot, and doesn't understand that it has to do with integer byte ordering, and nothing at all to do with unions. They may as well have stated "classes are not completely portable" or "structures are not completely portable". The problem has nothing to do with unions. It's the byte order of the integer itself.

    You should point whoever you quoted over to some place like here so they get a better clue as to what they're talking about.

    The reason it seems like a problem with the union, is because the union specificly shows them the individual bytes because of the way they've got it set up, so they can see the real issue: byte ordering.


    Quzah.
    Hope is the first step on the road to disappointment.

  9. #84
    Carnivore ('-'v) Hunter2's Avatar
    Join Date
    May 2002
    Posts
    2,879
    Oops, yes, it didn't occur to me to point out that the problem isn't with unions themselves. But that particular quote pretty much summed up what I've been trying to say in several of my previous posts - that this particular use of unions isn't necessarily portable - which I had no confirmation for prior to this (and, I was working with only a fuzzy idea of what *might* go wrong, I wasn't sure specifically what). Thanks for the clarification.
    Just Google It. √

    (\ /)
    ( . .)
    c(")(") This is bunny. Copy and paste bunny into your signature to help him gain world domination.

  10. #85
    *this
    Join Date
    Mar 2005
    Posts
    498
    What could be used to determine if the system uses big endian or little endian?

  11. #86
    *this
    Join Date
    Mar 2005
    Posts
    498
    could you do this:
    Code:
    #include <iostream>
    using namespace std;
    
    ///////////////////////////////////////////
    typedef unsigned int CHAR32;
    ///////////////////////////////////////////
    struct BITBLOCKSB {
       unsigned char    one;
       unsigned char    two;
       unsigned char  three;
       unsigned char   four;
    };
    ///////////////////////////////////////////
    struct BITBLOCKSL {
       unsigned char   four;
       unsigned char  three;
       unsigned char    two;
       unsigned char    one;
    };
    ///////////////////////////////////////////
    typedef union {
       unsigned int    value;
       BITBLOCKSB       bits;
    } BITUNIONB;
    ///////////////////////////////////////////
    typedef union {
       unsigned int    value;
       BITBLOCKSL       bits;
    } BITUNIONL;
    ///////////////////////////////////////////
    bool BIGENDIAN() {
       short int bit = 1;
       char* byte = (char*) &bit;
       return(byte[0] ? true : false);
    }
    ///////////////////////////////////////////
    #define BIGENDIAN BIGENDIAN()
    ///////////////////////////////////////////
    
    int main() {
       if (BIGENDIAN)
          BITUNIONB bitUnion;
       else
          BITUNIONL bitUnion;
    
       cin.get();
       return 0;
    }
    Last edited by JoshR; 06-25-2005 at 10:19 PM.

  12. #87
    *this
    Join Date
    Mar 2005
    Posts
    498
    Instead could i possibly use preprocessor directives? im not the best with them, dont use them that much, but could i do this instead?

    Code:
    #include <iostream>
    using namespace std;
    
    /////////////////////////////////////////////////
    typedef unsigned int CHAR32;
    //-----------------------------------------------
    // Breaks up 32 bits into blocks of 8 bits
    // BITBLOCKSB for Big-Endian
    // BITBLOCKSL for Little-Endian
    //-----------------------------------------------
    struct BITBLOCKSB {
       unsigned char    one;
       unsigned char    two;
       unsigned char  three;
       unsigned char   four;
    };
    
    struct BITBLOCKSL {
       unsigned char   four;
       unsigned char  three;
       unsigned char    two;
       unsigned char    one;
    };
    //-----------------------------------------------
    // Allows access to the bit blocks
    // BITUNIONB for Big-Endian
    // BITUNIONL for Little-Endian
    //-----------------------------------------------
    typedef union {
       CHAR32      value;
       BITBLOCKSB   bits;
    } BITUNIONB;
    
    typedef union {
       CHAR32      value;
       BITBLOCKSL   bits;
    } BITUNIONL;
    //-----------------------------------------------
    // Current PC endian type
    //-----------------------------------------------
    bool ENDIAN() {
       short int bit = 1;
       char* byte = (char*) &bit;
       return (byte[0] ? true : false);
    }
    //-----------------------------------------------
    const bool BIGENDIAN = ENDIAN();
    //-----------------------------------------------   
    #if (BIGENDIAN)
       #define BITUNION BITUNIONB
    #else 
       #define BITUNION BITUNIONL
    #endif
    /////////////////////////////////////////////////
    
    int main() {
       BITUNION bitUnion;
       bitUnion.value = 254;
       cout << (int)bitUnion.bits.one << " " << (int)bitUnion.bits.two << " " 
          << (int)bitUnion.bits.three << " " << (int)bitUnion.bits.four;
          
       cout << endl << "Big Endian? " << (BIGENDIAN ? " Yes" : " No") << endl;
       cin.get();
       return 0;
    }

  13. #88
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,751
    This thread has gotten too large to even read what everyone's been saying, and somewhere along the line the topic changed from bitfields to endianess.

    I suggest you ask your current specific question in a new thread, so we can all see once again what the real issues are.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  14. #89
    *this
    Join Date
    Mar 2005
    Posts
    498
    good point, ya definetly is a looooong topic

  15. #90
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,751
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

Page 6 of 6 FirstFirst 123456
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Writing Code
    By ILoveVectors in forum C++ Programming
    Replies: 4
    Last Post: 06-13-2005, 01:27 AM
  2. True ASM vs. Fake ASM ????
    By DavidP in forum A Brief History of Cprogramming.com
    Replies: 7
    Last Post: 04-02-2003, 04:28 AM
  3. Seems like correct code, but results are not right...
    By OmniMirror in forum C Programming
    Replies: 4
    Last Post: 02-13-2003, 01:33 PM
  4. Interface Question
    By smog890 in forum C Programming
    Replies: 11
    Last Post: 06-03-2002, 06:06 PM
  5. Replies: 4
    Last Post: 01-16-2002, 12:04 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21