1. well i have been really interested in encryption and have come up with some pretty weird ideas that have failed, well they worked just i started hating them...

1) did XOR according to the file length, so it was length dependent
2) found binary string of each value and converted it to a base3 number

then i started looking for encryption algorithms so i could get a feel for it,
i found the blowfish algorithm, which a lot of programs use, and its really interesting so i want to figure out how it works, ive also looked at Reijndael (rain doll) and its really cool, the theory that is.

so i want to make a really cool encryption algorithm just for fun.

2. i forgot where exactly i found it, but i found the source for an implementation and thats where i found the topic to this forum lol.

3. just google the encryption algorithms i mentioned and add c++ algorithm to the end of it and you will get all the sources i did.

4. Originally Posted by JoshR
I guess now it lets me hmm weird well here it is, just a small compression idea, wouldnt really be that helpfull
What yeah talking about moe! thats one idea we spent 3 pages talking about. It works well with integers if you could make some moficiations and have it just there in your projects, just not relied on a lot. Might also be more useful in a server/client enviroment, though I've never made one.. not sure how thatd work.

Yeah that .cpp is a great example for those of us who didnt spend 3 forum pages talking and testing it, comparing the bitfield ints to regular ones. It took me forever to see what you meant about using a union, thats a cool way of using the struct.

So that means if you set value to a value in that union, you could take it apart 8 bits at a time, right? hm.. bleh, how about take it apart 2 bits at a time! man, that would be cool if you could set a bitfield array of ints, like unsigned int namehere[100]:2;, each having their own 2 bits then loop a bitwise << for each one as an encryption, and of course setting the value wouldnt be hard if you just used a union (I think.. well, I've never worked with encryptions so thats probably wrong) and I'm just typing for fun because it wont let me make an array.

5. >>They have it so a char is 1 byte, even though there are 255 different chars to select (that adds up to 2 bytes)

Hmm?.. 2^(1byte * 8bits/byte) = 256... to add '0', subtract 1 from the max -> 0 to 255, i.e. unsigned char.
I believe, the (-127) to 128 representation is simply a matter of interpreting everything over 128 as a negative number starting from -127, so I'm not sure what you mean by 2 bytes.

>>So that means if you set value to a value in that union, you could take it apart 8 bits at a time, right?
Well, I'm not 100% sure about this part, but the variables in the struct may not be arranged as you expect. I don't have a copy of the C++ standard so I can't check up on this, but I think all that's guaranteed of a struct is that the declared variables exist *somewhere* in that block of memory and are of the type specified. AFAIK, the compiler is allowed to optimize by rearranging the physical location of the variables within the struct, so unless you find a compiler switch to turn this off, the bits you're accessing might not be the ones you're looking for. Again, though, I repeat: I could be totally wrong about this, or it might not apply to structs with bitfields, or anything in between, but you should look it up just in case.

6. Originally Posted by Hunter2
>>They have it so a char is 1 byte, even though there are 255 different chars to select (that adds up to 2 bytes)

Hmm?.. 2^(1byte * 8bits/byte) = 256... to add '0', subtract 1 from the max -> 0 to 255, i.e. unsigned char.
I believe, the (-127) to 128 representation is simply a matter of interpreting everything over 128 as a negative number starting from -127, so I'm not sure what you mean by 2 bytes.
Damn you saw my crazy hypothesizing from last night before I could delete it. Yeah I got my bit calculations wrong for some reason and thought 1111 1111 = 127 (so I was 1 digit off from 255). So what I said was wrong, 1 byte is plenty of space for all the characters, so I wonder why I read Java uses 2 char's space for all their characters.

Originally Posted by Hunter2
>>So that means if you set value to a value in that union, you could take it apart 8 bits at a time, right?
Well, I'm not 100% sure about this part, but the variables in the struct may not be arranged as you expect. I don't have a copy of the C++ standard so I can't check up on this, but I think all that's guaranteed of a struct is that the declared variables exist *somewhere* in that block of memory and are of the type specified. AFAIK, the compiler is allowed to optimize by rearranging the physical location of the variables within the struct, so unless you find a compiler switch to turn this off, the bits you're accessing might not be the ones you're looking for. Again, though, I repeat: I could be totally wrong about this, or it might not apply to structs with bitfields, or anything in between, but you should look it up just in case.
Oh yeah you're probably right about that, but he created an object of the struct in a union, which means the object shares the same memory address (space allocated) as the variable in the union. Unless you think it may alter the memory locations after creation? And if you saw his example he showd that when he set the 4 bitfields in the object that was in the union, you could print out a result of the bits as if they were all together when calling the variable in that union (that was the same size as the struct of course). This means if he set the variable in that union to a huge number or a long string he could call the bitfields of the object (thats also in the union) and edit the section (bitwise) 1/4 at a time (which only has its use if you bitshift and such, because you cant exactly edit the binary directly). And you can always find out how many times you should loop the bitfields editing idea by finding the sizeof the variable in the union. That is if bitfield arrays actually worked :-/ (int bitfield[100]:8. Take a look at the .cpp file he linked, its a cool idea... just not sure how to make more use of it in a larger scale.

I'd look it up if I had a reference.. and google is not my friend when it comes to this subject. :-/

7. Bitfields are only allowed in structs and unions, so I believe you can apply bitfields to an array as long as it's in a struct. Wait, no cuz you'd probably have to make it a poitner, and I believe pointers don't work with bitfields. Cuz I don't think int bitfield[100]:8 would work cuz it looks like you want to make an array of 100 elements that only takes 8 bits.
So what I said was wrong, 1 byte is plenty of space for all the characters, so I wonder why I read Java uses 2 char's space for all their characters.
I believe Java uses a form of Unicode encoding rather than ASCII like C++ chars do.

8. Originally Posted by Hunter2
the bits you're accessing might not be the ones you're looking for.
But ive used binary representations to check and infact have seen that the bits are placed in the order of the variables from top to bottom in the struct, you know one statement then it goes to the next etc... ive checked with an equation i wrote to show me the binary value and ive never found a case where it did anything odd, plus as its used in the popular blowfish algorithm, they wouldnt do something that could jeoperdize (sp?) the data.

9. Originally Posted by Ganoosh
Bitfields are only allowed in structs and unions, so I believe you can apply bitfields to an array as long as it's in a struct. Wait, no cuz you'd probably have to make it a poitner, and I believe pointers don't work with bitfields. Cuz I don't think int bitfield[100]:8 would work cuz it looks like you want to make an array of 100 elements that only takes 8 bits.

I believe Java uses a form of Unicode encoding rather than ASCII like C++ chars do.
Yeah thats exactly the problem.. there must be a way around it.

- Maybe an array of the struct.. I'll check
- And int bitfield:8[100]; doesnt work either, argh.

Know any tutorials on bitfields? google isnt being a friend on this one.

10. I don't think it'd work with an array, because if you have an array of 6-bit ints, the compiler would have to do a LOT of work to find the actual section of memory you're referring to when you use the subscript operator.

>>But ive used binary representations to check and infact have seen that the bits are placed in the order of the variables from top to bottom in the struct
Right, and there's no problem with this observation; however, what I'm saying is that just because "it works on my machine" doesn't mean it works on every machine - or more specifically, every compiler. What I meant was, 'top to bottom in the struct' may have no meaning. As for the blowfish algorithm, what you're seeing is just one implementation of the algorithm; it may simply be wrong. On the other hand, I could also be totally wrong and just confusing you I'll see if I can check up on this.

**EDIT**
OK, well I can't find anything about variable arrangement anywhere at all (actually, I don't know what to search for). I remember, though, that you cannot directly copy the binary representation of one struct over top of another 'equivalent' struct.
Code:
```struct A
{
int a;
int b;
}a;
struct B
{
int a;
int b;
}b;

memcpy(&a, &b, sizeof(a));  //Bad, structs are not equivalent```
Perhaps the problem with this has to do with struct packing problems as opposed to arrangement. However, this also brings up the problem:
Code:
```struct Bits
{
int a : 1;
int b : 1;
int c : 1;
int d : 1;
int e : 1;
int f : 1;
int g : 1;
int h : 1;
};

union UCharBits
{
unsigned char uchartype;
Bits bitstype;   //What size is the structure Bits?
};```
What if Bits is padded to 4 bytes, and the padding bits go on the wrong end of the struct? The bits you access then will be meaningless. I'm not sure if this is possible either, but if not, then I can't think of any reason why the earlier (guaranteed bad) example is harmful.

11. Interesting.
Microsoft Specific
The ordering of data declared as bit fields is from low to high bit, as shown in the figure above.
This would seem to lend validity to my variable-arrangement argument. On the other hand, it does mention that it allocates "a new unsigned int" when overflowed, which I previously didn't believe Not sure if it's because all the bitfields in the example were of type unsigned, or if that's just how it goes.

12. Theres no way its allocating "a new unsigned int" because we tested the sizeof the struct when overflowing it, and it simply truncated it.. unless its assigning the int outside of the struct in the memory.

PersonalData pd [1000]; //1000 bytes
Yes! there it is! my bit array, simply make an array of the struct instead, as pondered in my last post.

Code:
` unsigned int :3; //3 bits space...`
You can use spacers like that too. 3 bits spacer. // Edit: got that from this tutorial: http://kylm.com/?tutorial=48

The ordering of data declared as bit fields is from low to high bit, as shown in the figure above.
Interesting indeed.. hmm, but the question is if its changing the location of the bits to keep them in order of size, when the values are changed, in the object in the union. To the IDE!

13. Originally Posted by Dae
but the question is if its changing the location of the bits to keep them in order of size when the values are changed. To the IDE!
Tested using JoshH's .cpp and editing and printing the values after doing so. Once the object of the struct is created it wont change the location of the variables according to size if they change, its only on initilization or possibly its not changing because we use the object in a union so therefor has no right to change the ordering.. which in anycase means its working!

Of course it may just be my compiler and/or operating system, I'd obviously check before using my methods on different specs.

14. >>Theres no way its allocating "a new unsigned int" because we tested the sizeof the struct when overflowing it, and it simply truncated it..
What I meant, was 'overflowing' the original struct size of 4 bytes My bad.

>>Yes! there it is! my bit array, simply make an array of the struct instead, as pondered in my last post.
I don't see what you're trying to achieve here. All you have is an array of struct PersonalData, and each struct will be a multiple of 1 byte.

>>Once the object of the struct is created it wont change the location of the variables according to size if they change
If that were possible, then reading/writing structs to binary files would be pointless. What I was referring to was, top-to-bottom in the struct declaration could be arranged either left-to-right or right-to-left depending on your compiler - or perhaps even mixed up. The problem wouldn't be in stuff randomly moving around, it would be a problem of predicting which bitfields access which bits, and whether that would change depending on where you compiled!