PureBasic Forums - English

Hi,

today i needed an easy way to save and reload strings which contained #LF$, #CR$ and even #CRLF$. With the built-in WriteString() method one can save the string to file, but reloading with ReadString() will fail because the string will be split into multiple pieces (lines). Therefore i wrote the following procedures to write strings and reload them exactly as they have been written.
Am i wrong and is there a better solution to do this, or is it possible and senseful to add this procedures to the Purebasic capabilities?

Best regards
Uwe

uwekel wrote:With the built-in WriteString() method one can save the string to file, but reloading with ReadString() will fail because the string will be split into multiple pieces (lines).

WriteStringN() writes one line, and ReadString() reads one line. So what is exactly the problem?

Besides that, your procedure WriteText() does NOT create a normal text file.

This thread should be moved to "Coding questions".

and ReadString() reads one line

yes, but he will read some lines, also the characters LF and CR ...

@uwekel:
Your code isn't run with unicode!

STARGÅTE wrote:

and ReadString() reads one line

yes, but he will read some lines, also the characters LF and CR ...

Little John wrote:your procedure WriteText() does NOT create a normal text file.

For reading and writing any kind of binary data, there are ReadData(), WriteData() and other functions, so I still don't see any need for a feature request here.

Of course ReadDate() and WriteData() works, but my idea was to have a single-line command for this.

Your code isn't run with unicode!

Oh, sorry. Ii have not checked that. I guess for unicode it must be taken into account that the string memory length is twice the string length, right?

uwekel wrote:but my idea was to have a single-line command for this.

Yes, obviously. And probably 100 other people also would like to have built-in commands for their personally preferred binary file format ...
Just put your procedures into an include file, and voilà: you've got your single-line commands for your special file format.
It doesn't make sense to build commands for each and any file format into PB.

What's wrong with it? It's more an extension to the ReadString() and WriteString() methods than a personally preferred file format.

Personally for me, i have already stored the procedures in a common source file. The disadvantage of a common lib is, that it is - once included - completely (with all other stuff) embedded in the target executable. PB commands are only linked if used.

uwekel wrote:It's more an extension to the ReadString() and WriteString() methods than a personally preferred file format.

No. Those files are not normal text files, they can't be edited with standard text editors. I already wrote that.

You created a custom file format in 3 lines of code
Doing it in 1 line doesn't seem worth the effort of a dedicated function?

uwekel wrote:The disadvantage of a common lib is, that it is - once included - completely (with all other stuff) embedded in the target executable. PB commands are only linked if used.

Apparently procedures from source files are only linked if they reference each other, which isn't the case with those two functions for example.

At office i work with VB.Net and so i was a little inspirated from the ReadAllLines() method from the System.IO namespace. From my opinion it is a helpful and easy to use command i often use.

Apparently procedures from source files are only linked if they reference each other, which isn't the case with those two functions for example.

I just tested this. Just the use of IncludeFile "mycommonlib.pb" without using any code enlarges the target executable a lot. It seems that everything is linked into the executable.

Nope, I just tested it myself. Seems to be correct what I said.
I think in your case the different procedures are referencing each other, as I said.


Have a look at this code: Assuming you include this "common" file into your project...now:
Because the procedure BBB() calls AAA(), both will be compiled into the executable,
even if you only use function CCC(). That's what's happening.

If procedure BBB() looked like this... ...and you only use CCC() in your program, both AAA() and BBB() will not be included in your executable.

That's very interesting. I didn't know that. Cool