Problem with .write() function

Hi dudes.

For some reason this works:

Code:

---

    ofstream out("filename.dat");
    char x[3]="ol";
    out.write(x, 1);

---

and this doesnt:

Code:

---

    ofstream out("filename.dat");
    unsigned char x[3]="ol";
    out.write(x, 1);

---

and this second code returns me the folowing error: invalid conversion from 'unsigned char *' to 'const char*'

but i dont know why, why cant i use an unsigned char instead of a char. and even in some books the examples use an unsigned char.

Im using the correct headers:

Code:

---

#include <iostream>
#include <fstream>
#include <ctype.h>

---

any ideas??

The first argument to the write method of ofstream is a const char *; therefore if you want to write data that is NOT a const char *, you must force it to be a const char *.

Code:

---

ofstream out("filename.dat");
unsigned char x[]="ol";
out.write(reinterpret_cast<const char *>(x), 1);

---

I thought that wouldn't matter.

The const here means write() promises it won't change the string. It's totally fine if your original string is non-const.

Why not just use char?

Unsigned/signed chars only make sense when you are using them to store numbers. For characters, the default signedness will always do the right thing.

Yes i know i can use just char, but what really drives me insane is that they use it in tutorials and books, then why doesnt it work for me?? for example, my code was taken from an example in a book.

Quote:

---

Originally Posted by shiroaisu

Yes i know i can use just char, but what really drives me insane is that they use it in tutorials and books, then why doesnt it work for me?? for example, my code was taken from an example in a book.

---

Are you sure [it was like that in the book]? In that case, throw away the book, it's crap. You can't do that. Also, mention what book it is. Let's make a "C books not to buy" thread..

You should check the book's errata webpage, especially after you notice or otherwise encounter errors in book examples.

Not to argue with the idea of a bad books thread, but there are good, instructive books with errors, and bad ones with inexcusable problems.

It's better to not use write at all. You have the stream operators, so it's a good idea to actually use them instead. It will ensure portable code and not having to bother with casts.
The the thing that the write function needs a cast is to discourage its use.

Quote:

---

It's better to not use write at all.

---

Unless you are using a stream in binary mode.

Quote:

---

The the thing that the write function needs a cast is to discourage its use.

---

>_<

Could you not do that? If this poor newbie takes such complete crap to heart he'll have a bad start when he wants to operate on binary files.

Soma

Fine, fine. If you need to operate with binary files, then you could use it. Or you could even use the C function fwrite/fread instead which offer equivalent functionality and are less painful to use. The C++ write/read offers no advantage whatsoever over its C sibling. In fact, it's more cumbersome instead.
The only advantage is the iostream. Files will close automatically. But with some RAII, the C fopen/fclose would be no problem either.
Whopeedo!

o_O

So your argument for dishing out such trash is that one could use something different?

*shrug*

Okay. I can dig it.

It's better to not use C++ at all. You have the Ruby* language, so it's a good idea to actually use Ruby. It will ensure portable code without having to bother with casts.

The thing is that the template functions cause "bloat" to discourage their use.

The C++ formatted IO manipulators offer no advantage whatsoever over its C siblings. In fact, it's more cumbersome.

But with some manual labour, the inefficiencies of a system can be fixed or mitigated.

Awesome.

Soma

* picked randomly

Argument? Not at all.
I decomposed the don't use write into two sides of an argument due to your request.
Now that you've seen both sides, you can pick whatever you want.
Plus binary files aren't portable.

Now choose! Choose the tool you want or need! Choose! Choose!
Or don't. That's up to you.

Quote:

---

Plus binary files aren't portable.

---

O_o

WTF!?

Quote:

---

Plus binary files aren't portable.

---

o_O

That explains a lot.

Soma

Yes, they don't behave the same on all platforms. One of the likely culprits is endianess. So I would like to mark as non-portable.
But obviously you don't agree. But we can't all agree.

Quote:

---

Originally Posted by Elysia

Plus binary files aren't portable.

---

To be nitpicky, they are portable, just not across ports :) Each port itself should be fine as long as you don't communicate between different ports via files.

Good point. Perhaps we should call it semi-portable? Portable under certain conditions, that is.

Quote:

---

Yes, they don't behave the same on all platforms.

---

O_o

You and MK27 should not be allowed to give advice regarding IO issues at any level.

Do you not realize that a text file, an ASCII file to offer a specific example, is a binary file with a particular interpretation? What about PNG, JPG, and DB3? Do you know any of those file formats? Do you think that they are text files? Ever hear of a "byte order mark" or "variable byte integers"?

Quote:

---

Yes, they don't behave the same on all platforms.

---

By your logic, neither are the standard streams. You should consider other forms of encoding the same character. Take a platform writing EBCDIC instead of ASCII. The EBCDIC text file produced by one platform is not "native" to platform expecting ASCII.

Soma

Are we going to clash about the definition of a binary file? It sounds to me that according to your definition, all files are binary files. They just follow a certain byte order, or a certain interpretation format.
According to me, a binary file is a file where you have simply written down the bytes of a variable as-is without any regard to external factors such as endianess.
So I stand by my point that they aren't portable: you cannot expect to write an integer and read it back the same way on all platforms.
But we could write a binary file and read it back in a controlled way, as you suggest. It would work, but it's still not entirely portable. Semi-portable it is, though.

Quote:

---

Originally Posted by Elysia

So I stand by my point that they aren't portable: you cannot expect to write an integer and read it back the same way on all platforms.

---

An MP3 file isn't portable? I feel like we've been down this road before.

I also have a definition for simply writing data to a file without regard for endianness or other portability issues: it's called "stupidity."

Quote:

---

Originally Posted by brewbuck

An MP3 file isn't portable? I feel like we've been down this road before.

---

By my definition of binary file, that is not a binary file because it follows a certain expected byte pattern.

Quote:

---

I also have a definition for simply writing data to a file without regard for endianness or other portability issues: it's called "stupidity."

---

...And that is what I have been trying to say: binary files (my definition) aren't portable. They are semi-portable. That is, it is possible to do it, but it might not be a good idea.
(Which is why I wanted to discourage the write function, which phantomotap complained about.)

Redefining things will not make you more correct.

Quote:

---

I also have a definition for simply writing data to a file without regard for endianness or other portability issues: it's called "stupidity."

---

Ignorance at best.

Quote:

---

By my definition of binary file, that is not a binary file because it follows a certain expected byte pattern.

---

That is an incredibly stupid definition... the ultimate in stupid definitions. If you dump a "little endian" integer of four bytes it follows an expected byte pattern by definition.

Quote:

---

And that is what I have been trying to say: binary files (my definition) aren't portable.

---

Quote:

---

Which is why I wanted to discourage the write function, which phantomotap complained about.

---

ENOUGH OF THIS! You are either foolish or a liar

It does not matter what definition of "binary file" you use, you can not use "text mode" of the C or C++ standard library IO facilities to create examples of either kind because these facilities are allowed to translate the binary patterns sent to them.

[Edit]
To make the above clearer, you are wrong no matter the definition you choose to use.
[/Edit]

So, which is it?

Soma

Quote:

---

Originally Posted by whiteflags

Redefining things will not make you more correct.

---

No one has provided any better definition.

But enough of this. Regardless of who is correct, I think this discussion has brought to light that problematics behind the original problem, on both sides of the argument.
One can reasonably get an understanding of the pros and cons by reading this, and that is sufficient.