I was just wondering if structs in C is the something like objects in OOP, just with less functionality (no methods, privates etc), and if so, are they used the same way?
If not, how would you describe structs, and what would be a good example of how to use them
thanks =)
goes in newbie thread I assume =/
structs group relevant objects together.
It's like, if you have X and that X is somehow related to Y, and if something needs X it might need Y, then you need them in a struct most likely.
structs are everything C has to abstract away information (along with functions)
Imagine you can start your own string library like this:
struct string { char *s; size_t len; };If it seems inadequate, you can add more members or modify it in any way.
The functions operating on such objects would require a struct string *.
struct is actually more powerful than "objects in OOP" because it can refer to an actual memory layout; consider:
struct data { int a, b; char z[1024]; int c; };You can now read() and write() an entire struct data and get all of the data serialized to the disk (or deserialized) in one go. An external program can manipulate any of these values and you can then read them back safely. All of these things are guaranteed by the C standard, which is a very valuable thing indeed!
>>4
The C standard doesn't define the behavior of read or write, you buffoon.
POSIX does.
Replace read and write with fread and fwrite and what you've said is almost correct.
Great job, cocks-for-brains. You've parrotted C programmers for so long, you almost sound like one.
Fact is, the C standard most certainly describes the behavior of const void * access to structures between the struct data * and the (struct data *)+sizeof(struct data)
You can replace read() with fread() or readv() or even i_suck_cocks() if you want. The C standard guarantees that your function will be able to load data into your structure safely.
Not so with C++, which doesn't guarantee that method pointers nor vtables won't be dispatched. Thanks to operating systems relocating your program or library, you simply aren't guaranteed to be able to do that in C++.
Replace brains with cocks, and we've got you.
>>6
Wrong. It's all about representations. You can access any objects representation (in C or C++) via (unsigned char *).
You can write these unsigned chars, and you can read them back, yes.
No, you can't replace read with fread or readv.
The standard does not describe any behavior of 'const void *' access? (wtf) to structures (wtf #2) and the (struct data *) + sizeof (struct data) (wtf #3, that's a constraint violation requiring a diagnostic message)
Both C and C++ guarantee that you can write and then read back bytes. (unsigned chars)
Operating systems have nothing to do with C or C++.
You stupid motherfucking piece of shit uselesss cocksucker.
How does fread/fwriting a file handle endianness or different word lengths?
>>7 The C++ spec doesn't guarantee that those bytes won't include the vtable or any methods. >>4 is right.
See:
http://www.codesourcery.com/public/cxx-abi/cxx-vtable-ex.html
for more details.
>>8 It doesn't.
Considering that C++ objects are implemented in C as structs, yes.
However, when the classes/structs have member functions, sometimes pointers to those functions appear inside the struct, which means you cannot safely read/write the structure to the disk (or the network)-- the function may no longer be at that address, or someone may have tampered with the data.
I'm >>5 and >>7.
Everyone is clueless. When you write object X you are guaranteed to read back object X from a file stream in C and C++ (IO errors can happend, but they are not relevant)
The isssues addressed by >>12 are not even relevant! You've all missed the point!
Are there really that few people that know C or C++ well here?
>>8
fread takes 2 integers, size of individual member and number of members.
That way it can handle 'different word lengths'. (or any object length actually)
As for endianness, it's not even mentioned in the C standard (nor in the C++ standard)
What C (and C++) guarantees is about a particular implementation writing and reading back representations.
Get it? (btw, your program and protocol can guarantee such things easily, it's not up to the standard of the language to define such things, that would limit portability by a lot)
Anybody who actually follows this idiotic advice is going to be surprised as hell when they try to port it and 0x000001 turns into 0x1000000
When you write a C++ object, and read it back in, the classtype/vtables/method pointers could be overwritten. The C++ standard doesn't guarantee that they won't be, and for some kinds of objects and some compilers, they actually will be.
That's the point.
Someone better tell Oracle, Sun, Microsoft, and GNU. All of these groups produce applications with non-portable data files. Supporting portable data files is exceptionally difficult, and it's usually easier (if the data is necessary) to simply write a convertion tool.
> That way it can handle 'different word lengths'.
I meant reading a file that was written on a 32-bit machine with a 64-bit one. Or vice versa. Or 16-bit. Nowadays we have computers that have modes with any of those three word lengths.
> As for endianness, it's not even mentioned in the C standard (nor in the C++ standard)
If it isn't mentioned in a standard it doesn't exist?
I don't have a problem dumping structs like that to disk or a socket (done it myself for local apps), but that attitude is plain retarded.
Generally for those types of apps, I recommend a ASN.1 compiler, or similar. They can write C code to portably convert a data structure into a byte-stream (and back again), and in some cases the C code is very efficient- relying on compile-time knowledge of word sizes and endian that human-written "portable" C code wouldn't bother with.
Interesting. Thanks.
> Someone better tell Oracle, Sun, Microsoft, and GNU. All of these groups produce applications with non-portable data files. Supporting portable data files is exceptionally difficult, and it's usually easier (if the data is necessary) to simply write a convertion tool.
Got a source for which Sun/GNU applications in particular use non-portable data files? Considering both organizations provide applications that must work on a variety of platforms, I don't think you're correct.
Supporting portable data files is easy as falling over. In case you haven't noticed, there's no such thing as a PC-only .jpg or Mac-only .zip
> Got a source for which Sun/GNU applications in particular use non-portable data files? Considering both organizations provide applications that must work on a variety of platforms, I don't think you're correct.
Off the top of my head:
In fact, most cache file formats aren't binary portable simply because it isn't worth it- the files can be regenerated easily enough.
Databases are infrequently binary-portable (PostgreSQL isn't binary-portable at all) because it's a huge performance loss. They usually detect the problem (because that's cheap), and include a conversion tool, so this really is a smaller deal than you might otherwise think.
That's okay though. I accept your apology.
> Supporting portable data files is easy as falling over.
But clearly harder than reading and writing the structure blindly.
> In case you haven't noticed, there's no such thing as a PC-only .jpg or Mac-only .zip
Of course not. JPEG and ZIP files are designed for interchange; they are designed to be shared between machines.
Do you really think I suggested that no files should be designed for interchange?
> fread takes 2 integers, size of individual member and number of members.
> That way it can handle 'different word lengths'. (or any object length actually)
Did I miss something here? What does taking two parameters and multiplying them together have to do with, well, anything except argument inflation?
Nothing. Why do you ask?