Thread: Casting a struct to char**, or abandon the struct and use char**?

Sorry for the cryptic title.

I have a program that reads csv files and adds each row to a data structure. Right now the data structure is separated from it's content, which is handled by it's own source file which knows about the content, declares a struct, parses a csv line etc.

What I want to do now is to find a way to easily change this content specific file, for example by only create a new struct that reflects a csv row. However each function depends on the struct to be exactly the way it currently is.

Is it a viable solution to cast the struct to a char** array (the struct contains char* only) and use pragmas or __attribute__ to make sure it's packed, or is it better to abandon the struct and only use a char** array, and with it lose the named members that a struct has?

What I want to do now is to find a way to easily change this content specific file, for example by only create a new struct that reflects a csv row. However each function depends on the struct to be exactly the way it currently is.

What functions are you talking about? Functions in the "content specific file", or some other functions? How are you passing this structure from your "content specific file" to the rest of your program. Depending on how you are using the structure you may be able to place the "new" information at the end of your structure. Then only functions designed to use this "new" information will try to access the "new" data.

Jim

I want to see if I can adapt the functions to any csv file by only changing a header file that declares a struct.

Why can't you just pass the correct structure into the function? This structure could have a different number and type of elements depending on the format of the csv file. If you have two structures, one structure to hold the data from the csv file, the other would be the "header". This "header" structure would contain fields containing the number of fields, an array containing the size of the fields, the type of the fields, and possibly the length of the fields.

Something like:

Code:

// Header structures.

struct field_info
{
   char field_type[3]; // c,s,i,ui,l, ul,f,d and any other types needed.
   size_t field_size;   // Probably only needed for strings.
};

#define NUM_FIELDS 10
struct record
{
   const size_t num_fields;  // Number of fields per line.
   struct field_info[NUM_FIELDS]; 
};

// Your data structure below. Contains NUM_FIELDS fields, of the type described in the field_info structure.

You would have some kind of "initialization" function that will fill in the values in the record structure. So you would need both a small source file along with the header file. You could even read the required information for the header information from a file if so desired.

Jim

Hm, interesting but wouldn't that make the struct members anonymous if that makes sense in the same way that an array would? I might not completely understand what you meant though.

This is two mock up examples:

Code:

// declared in a separate header
struct record {
   char *name;
   char *address;
};

Option 1:

Code:

struct record *parse_csv_row(char *line) {
   struct record *r = calloc(sizeof(struct record), 1);

   // using strsep and strdup to get the string to r->name

   // ditto for r->address;

   return r;
};

2:

Code:

#define COLS sizeof(struct record) / sizeof(char*)

void *parse_csv_row(char *line) {
   char **record = calloc(sizeof(struct record), 1);

   for(int i = 0; i < COLS; i++) {
      // using strsep and strdup to get the string to record[i]
   }

   return record;
}

The first function and any similar function that operates on the struct would have to be rewritten to reflect changes in the struct.

You could make a union of the struct and an actual array of char pointers, but you would have to update the union's type declaration if the members change. I'm not really sure if you'd be happy with that or not. I get the feeling I'm just moving the problem to another location.

Originally Posted by whiteflags

You could make a union of the struct and an actual array of char pointers, but you would have to update the union's type declaration if the members change. I'm not really sure if you'd be happy with that or not. I get the feeling I'm just moving the problem to another location.

That would be somewhat similar to what Jim proposed it sounds like. I think it might be easier to just use the array then and forget about named members, I guess it would be possible to define enums that represents the indexes, but it might be too messy.

Originally Posted by laserlight

If you want to decouple CSV parsing from your domain models, then the solution is to write a generic CSV parser that parses the CSV file into records that contain fields that are (or contain) strings.

That is pretty much the direction I have been going in, and quite similar to the 2nd example above, except for the "sizeof(struct record)" part which depends on the struct being packed as opposed to: "sizeof(char*), COLS"

Originally Posted by laserlight

Your struct objects are then created by processing these records as per the requirements of the struct. They don't need to know anything about CSV parsing; they just need to know that the nth field of the record corresponds to a particular member of the struct, then convert from string to the member type accordingly.

That may be a solution to avoid the cast to "struct record" that I currently do. I'm fine with keeping the members as strings, until I need to use them. Perhaps I could do something like a type_validator.h with functions like: is_integer, is_float and so on.

I was actually under the impression that all the members would be strings so using the union was really more about packing than anything.

Originally Posted by laserlight

That's because your struct record is not a CSV record: it is a struct in the subject domain. We might even rename it struct addressbook_record.

I'm not sure I follow, "record" as a name is abstract enough to be any record, but unlike arrays have the nice feature of named members. When ever I would actually use this struct I could call the instance something like addressbook_record.

Code:

struct record *addressbook_record;

while( /* read lines from csv file */ ) {
   addressbook_record = parse_csv_line( line );
   insert_in_datastructure( addressbook_record );
}

You basically want to implement an interface. The details in parse_csv_line can not be made to magically work with any old struct definition*, simply by including a different header file (unless that header included code, which is generally a no-no). Each type of object would need to define it's own parse_csv_line and that function would be linked in to the final executable. Even your magic header file method would involve a recompile, so you aren't losing any dynamic features here.

* I say "can not". Part of me wants to believe it's possible, and to figure this out, but thinking about all the preprocessor trickery and fugly x-macros that would be involved makes me queasy. It would be a lot of work, much harder that writing a makefile that uses the right header and links in the right .o file for the given CSV file format.

Originally Posted by anduril462

You basically want to implement an interface. The details in parse_csv_line can not be made to magically work with any old struct definition*, simply by including a different header file (unless that header included code, which is generally a no-no). Each type of object would need to define it's own parse_csv_line and that function would be linked in to the final executable. Even your magic header file method would involve a recompile, so you aren't losing any dynamic features here.

It can be done, and I have already done it. The question is if it's kosher to use the pack pragma or __attribute__ or if there are other solutions to do it that I haven't thought about.

This is what the current test header looks like in it's entirety.

Code:

#ifndef RECORD_H
#define RECORD_H

extern struct record {
   char *artist;
   char *song;
   char *duration;
   char *year;
}__attribute__((packed));

#endif

I also managed to generate this header from a CSV file (provided it has a title row) with awk, and tried to include it in my makefile for a laugh.

This is what the parse_csv_line function looks like, (btw this source file also contains:

#define RECORD_SIZE sizeof(struct record) / sizeof(char*)

Code:

void *parse_csv_line(char *line) {
    char *p = NULL;
    char **record;

    record = calloc(sizeof(struct record), 1);
    if(!record) return NULL;

    for(size_t i = 0; line && i < RECORD_SIZE; i++) {
        p = strsep(&line, ",");
        record[i] = strdup(p);
        if(line) {
            line = ffwd_space(line);
        }
    }

    return record;
}

Ahh, I see. I was thinking the record structure used non char * types. I do believe it will work. It seems like a total hack, relying on the result of packing such a struct being binary compatible with a char **. And packing is implementation defined as well. You could just read into a char ** and use an enum for the fields:

Code:

enum fields {
    ARTIST,
    SONG,
    DURATION,
    YEAR
};

char **record = read_from_csv_file();
printf("artist is '%s'\n", record[ARTIST]);

Since data field you store is just a string, I don't see you really gaining much benefit by having an actual struct versus a char **.