fwrite can't write dynamic strings???

itCbitC · 05-18-2009, 09:42 AM

Quote:

Originally Posted by matsp

Also, "od" works well for inspecting binary files - it supports printing in various display formats (e.g. octal, hex, decimal, float(? Never used that)) as well as showing records of various lengths.

--
Mats

yes od and xd work better than the xxd command of vi

Devil Panther · 05-18-2009, 09:45 AM

So my best solution is a staticly sized string?

**laserlight** · 05-18-2009, 09:50 AM

Quote:

Originally Posted by Devil Panther

So my best solution is a staticly sized string?

I am not sure about best, but it is a solution.

Incidentally, have you considered say, using SQLite? It has been described by its own author as a substitute for fopen(), and depending on your requirements it could suitably do just that.

itCbitC · 05-18-2009, 09:52 AM

Quote:

Originally Posted by Devil Panther

So my best solution is a staticly sized string?

What's wrong with the dynamic solution? It works just as well.

matsp · 05-18-2009, 10:52 AM

Quote:

Originally Posted by itCbitC

What's wrong with the dynamic solution? It works just as well.

Depending on what you are doing, it may make the whole scheme a lot more complex - for example, reading a variable size record can be quite a lot more complex than a fixed size one - either we need to store the size and then read back the size again to know how much more to read. Or if we don't store the size, we need to read each byte, until we get a zero.

A struct like this:

Code:

struct 
{
    int x;
    char *name;
    double d;
};

would require at least three writes and possibly almost indefinite number of reads, or four writes and four reads. [We could change the struct to hold a length as well, which would remove one read operation, as we read the length and x in the same operation].

It gets even more messy if there are several strings in the structure.

The other problem comes if we need to seek to get to element n. If each struct is stored with a different number of bytes, we can't actually use seek, unless we also keep a table of index -> offset. Or we have to read each element from first to whichever we look for.

--
Mats

Devil Panther · 05-18-2009, 11:47 AM

Quote:

Originally Posted by matsp

Depending on what you are doing, it may make the whole scheme a lot more complex - for example, reading a variable size record can be quite a lot more complex than a fixed size one - either we need to store the size and then read back the size again to know how much more to read. Or if we don't store the size, we need to read each byte, until we get a zero.

A struct like this:

Code:

struct 
{
    int x;
    char *name;
    double d;
};

would require at least three writes and possibly almost indefinite number of reads, or four writes and four reads. [We could change the struct to hold a length as well, which would remove one read operation, as we read the length and x in the same operation].

It gets even more messy if there are several strings in the structure.

The other problem comes if we need to seek to get to element n. If each struct is stored with a different number of bytes, we can't actually use seek, unless we also keep a table of index -> offset. Or we have to read each element from first to whichever we look for.

--
Mats

I have the name length, see my struct.
But when I write the char *name to the file it writes the pointer's address (as it should). How can I write the string itself?

matsp · 05-18-2009, 12:04 PM

Quote:

Originally Posted by Devil Panther

I have the name length, see my struct.
But when I write the char *name to the file it writes the pointer's address (as it should). How can I write the string itself?

Something like this:

Code:

struct stuff {
	int nameSize;
	char *name;
	int num;
};

...
void writestuff(FILE *f, stuff *st)
{
    fwrite(&st->nameSize, 1, sizeof(st->nameSize), f);
    fwrite(st->name, 1, st->nameSize, f);
    fwrite(&st->num, 1, sizeof(st->num), f);
}

And to read it, just do the same the other way around.

[Note that I've assumed that nameSize includes the terminating zero. If it doesn't, you have to add one to it when reading and writing]

--
Mats

itCbitC · 05-18-2009, 12:46 PM

Quote:

Originally Posted by matsp

Depending on what you are doing, it may make the whole scheme a lot more complex - for example, reading a variable size record can be quite a lot more complex than a fixed size one - either we need to store the size and then read back the size again to know how much more to read. Or if we don't store the size, we need to read each byte, until we get a zero.

Don't quite follow this part you posted. IMO, sizeof struct stuff will remain constant irrespective of the size of each dynamically allocated string its member name is pointing to. In this case struct stuff is defined as

Code:

struct stuff
{
        int nameSize;
        char *name;
        int num;
};

and it doesn't matter if name points to a 100 element array of char or just one, the size of stuff will still be 12.

Quote:

Originally Posted by matsp

A struct like this:

Code:

struct 
{
    int x;
    char *name;
    double d;
};

would require at least three writes and possibly almost indefinite number of reads, or four writes and four reads. [We could change the struct to hold a length as well, which would remove one read operation, as we read the length and x in the same operation].

It gets even more messy if there are several strings in the structure.

Why so? Assuming 3 struct stuffs were created initially, it'll require 3 fwrite()s to store and exactly 3 fread()s to retrieve all of 'em.

Quote:

Originally Posted by matsp

The other problem comes if we need to seek to get to element n. If each struct is stored with a different number of bytes, we can't actually use seek, unless we also keep a table of index -> offset. Or we have to read each element from first to whichever we look for.

--
Mats

IBTD, each struct will be exactly the same size as even those "different number of bytes" aren't stored in the struct but are being pointed to by name. 'Tis the same whether the struct members are statically or dynamically allocated arrays.

**laserlight** · 05-18-2009, 12:49 PM

Quote:

Originally Posted by itCbitC

Don't quite follow this part you posted. IMO, sizeof struct stuff will remain constant irrespective of the size of each dynamically allocated string its member name is pointing to.

That is precisely the point: if a fixed size array is used, taking the sizeof the struct will reflect the array size. If a dynamic array is used, then the part about storing the size or using a designated termination value comes into play. In such a case, when we talk about the size of the record, we are not talking about taking the sizeof the struct, but about the size including the dynamic array that is involved.

tabstop · 05-18-2009, 01:30 PM

Quote:

Originally Posted by itCbitC

Don't quite follow this part you posted. IMO, sizeof struct stuff will remain constant irrespective of the size of each dynamically allocated string its member name is pointing to. In this case struct stuff is defined as

Code:

struct stuff
{
        int nameSize;
        char *name;
        int num;
};

and it doesn't matter if name points to a 100 element array of char or just one, the size of stuff will still be 12.

Why so? Assuming 3 struct stuffs were created initially, it'll require 3 fwrite()s to store and exactly 3 fread()s to retrieve all of 'em.

IBTD, each struct will be exactly the same size as even those "different number of bytes" aren't stored in the struct but are being pointed to by name. 'Tis the same whether the struct members are statically or dynamically allocated arrays.

Except that all you're going to write is a pointer, which will provide zero actual data. You need to follow the data and write what it points to, which could be who knows how big.

itCbitC · 05-18-2009, 06:09 PM

Quote:

Originally Posted by laserlight

That is precisely the point: if a fixed size array is used, taking the sizeof the struct will reflect the array size. If a dynamic array is used, then the part about storing the size or using a designated termination value comes into play. In such a case, when we talk about the size of the record, we are not talking about taking the sizeof the struct, but about the size including the dynamic array that is involved.

gotcha!

Devil Panther · 05-19-2009, 02:18 AM

Thank you for all your help

05-18-2009, 09:45 AM	#17
Devil Panther * Death to Visual Basic * Join Date: Aug 2001 Posts: 768	So my best solution is a staticly sized string? __________________ "I don't suffer from insanity but enjoy every minute of it" - *Edgar Allen Poe* http://www.Bloodware.net - Developing free software for the community.
Devil Panther is offline

05-19-2009, 02:18 AM	#27
Devil Panther * Death to Visual Basic * Join Date: Aug 2001 Posts: 768	Thank you for all your help __________________ "I don't suffer from insanity but enjoy every minute of it" - *Edgar Allen Poe* http://www.Bloodware.net - Developing free software for the community.
Devil Panther is offline

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Need help with comparing strings (I'm a beginner C programmer)	Bandizzle	C Programming	2	04-29-2009 10:13 AM
Help with calloc and pointers to strings.	sweetarg	C Programming	1	10-24-2005 02:28 PM
operator overloading and dynamic memory program	jlmac2001	C++ Programming	3	04-06-2003 11:51 PM
Dynamic Toolbars	nvoigt	Windows Programming	1	01-11-2002 10:21 AM
array of strings + more	null	C Programming	10	10-01-2001 03:39 PM