Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

Control Flow

2 (2.2%)

Arrays, Strings, Pointers, and References

8 (9%)

Functions

4 (4.5%)

Basic object-oriented programming

30 (33.7%)

A bit more advanced OOP (Composition, Operator overloading, Inheritance, Virtual Functions)

18 (20.2%)

Templates

8 (9%)

Other (Explain)

4 (4.5%)

Working with files?  (Streams)

15 (16.9%)

Total Members Voted: 89

[ILikePie]

There's nothing wrong with text. Currently, I'm writing code that writes bytes into a file, the end result being a bmp file, and it's quite the pain to debug. I mean, if you're writing text, you know you've just written 56, you don't have to go about converting bytes into decimal numbers and vice versa.

[Supermikhail]

Well, that's why I'm trying to write a good interface for editing the elements database first, including adding and viewing entries. With how advanced teenagers are in computer matters nowadays, I'd very much dislike having the data easily readable.

Edit: A-ha! You've reminded me of my project that I tried to write when still in Delphi. Maybe that's why it wouldn't read the file, because it was bmp.

[Virex]

Any file format is readable with a hex editor, so it doesn't really matter what format you chose.

[ILikePie]

Yes, but hex editors show ASCII characters only, they won't show decimal numbers. Some do have hex to decimal conversion, but it's not easy as just reading the file. If want to encrypt something, you can try compressing it with Huffman (which Java supports by default), and then just decompress before reading.

[Supermikhail]

Any file format is readable with a hex editor, so it doesn't really matter what format you chose.

While I've never used a hex editor, I imagine that usefulness of what you've read from a file readable with a hex editor or a plain text editor varies. Of course, I won't be able to stop a hacker who breaks DRMs for breakfast every day; I just don't want to make the same mistake our teacher made when I was in high school - she placed a data file in text format in the same folder as the executable for our test. Not many, but some people figured it out and took the results out of the text file. Kind of recursion on a new level, if you think about it. Or lack of encapsulation.

Yes, but hex editors show ASCII characters only, they won't show decimal numbers. Some do have hex to decimal conversion, but it's not easy as just reading the file. If want to encrypt something, you can try compressing it with Huffman (which Java supports by default), and then just decompress before reading.

I imagine it would decompress it into a file on the hard drive during execution? Or, er... it's in a java library, right? Or I need to write the compressor myself?... Ah, I guess it can be all done in RAM.

Oh. Wow. Binary? I hope java won't screw up string output like C++.

[Virex]

Any file format is readable with a hex editor, so it doesn't really matter what format you chose.

While I've never used a hex editor, I imagine that usefulness of what you've read from a file readable with a hex editor or a plain text editor varies. Of course, I won't be able to stop a hacker who breaks DRMs for breakfast every day; I just don't want to make the same mistake our teacher made when I was in high school - she placed a data file in text format in the same folder as the executable for our test. Not many, but some people figured it out and took the results out of the text file. Kind of recursion on a new level, if you think about it. Or lack of encapsulation.

You could just, you know, not use obvious names for in your text file? If you use a function that maps the things you're writing one-to-one to something that would be intelligible for humans prior to storage, then that's better then what you'd get when just storing things in a deviating file format. Other tricks include using non-standard extensions (doesn't keep people from opening it with notepad), hiding the data amongst a load of junk or writing and reading the file in a weird order (alternate between appending and perpending for example)

[ILikePie]

I imagine it would decompress it into a file on the hard drive during execution? Or, er... it's in a java library, right? Or I need to write the compressor myself?... Ah, I guess it can be all done in RAM.

jars are compressed using Huffman (zip), which means the api must include some kind of way to compress things yourself, and that's java.util.zip. Or more specifically, java.util.zip.Deflater/Inflater. Though, yeah, as Virex mentioned, keeping a cryptic text file is much more practical.

e, If you're giving this out to a bunch kids, you could also hide the file.

[Virex]

It's only more practical as long as you can assure that you can understand the file when you're working with it. If you're hard-coding obfuscation into your code to support it you're going to run into problems. It's better to have the obfuscation be done at write-time

[ILikePie]

Yes, of course. That's why I suggested compression, it happens at write time, and can easily be reversed.

[Supermikhail]

The program actually needs obvious names, like element names and compound names... well, might need. But, I guess I'll tackle that after I've become more familiar with Java and can write simple files. Also, I guess I'll go for i18n (it's acceptable to abbreviate it like that in coder circles, right?) then - my program is intended for Russian students, but currently, you could say my whole computer is English, and the previous "version" was written completely in English. Urgh. My life is full of bugs!

Also also, write-time? That's for when a program writes into a database, right? Then there's runtime, that's when a program executes. I wonder what you call the time when you write a program. I thought it could be "design-time".

[Virex]

(I don't know if write-time is an official term, but it describes the case at hand pretty well)


I'd call it code-time, but I'd guess design time would fit as well.


Also note that you can just keep sensible names in the code, but have the code itself obfuscate those. Then if you need to edit the database, you can just use a deobfuscation algorithm to turn it into readable text. It may even be viable to write your own mini text editor for this, seeing as Swing (the main Java GUI library) is very powerful yet easy to use. Netbeans even comes with a GUI designer to do half of the work for you (though I still prefer to do it by hand, mainly because I don't understand half of how to have the GUI's made by Netbeans designer communicate with your code.)

[ILikePie]

Then if you need to edit the database, you can just use a deobfuscation algorithm to turn it into readable text. It may even be viable to write your own mini text editor for this, seeing as Swing (the main Java GUI library) is very powerful yet easy to use.

If all you need is too see the database, a cat-like tool should work fine.

[Virex]

Cat like? I'm not strapping my cat to my pc, if that's what you're getting at.

[Supermikhail]

keep sensible names in the code

Huh? You either mean hard-coding a large part of the data-base, or "code" is more flexible than I thought. But I understand obfuscation and deobfuscation... to which I've thought of a great addition - store the database file in part-files, and only combine them together in RAM, to form a complete database, and then dehuffman it. !!!

Addendum. I don't understand anymore what you're saying, guys! I've never used any cats on computer.

[Virex]

I am not sure how you intend to build your data base, but I was assuming at least a part of it was generated via code. If you're doing everything by hand you may instead want to write a program that hufman's your file and only keep the master file for yourself.