Reason for the Format

[ranjeet.gupta]

Dear All

As I was going through the code, I find the below piece of code,

#define FILEMAPPING \
char *data; \
int size; \
char *position; \
int (*open)(struct FileMapping *self, const char *filename ); \
int (*close) (struct FileMapping *self ); \
int (*destroy) (struct FileMapping *self ); \
int (*isYourFile)(struct FileMapping *self, const char *filename, u32
*outSameFile );

typedef struct FileMapping
{
FILEMAPPING
} FileMapping, *FileMapping;

Over above they have declared the Macro Named FILEMAPPING but I am not
able to understand what does it really mean ?, they have declared the
macro which is going to be replaced in the structure FileMapping, But
why they want to go in the above format. ?

its is just same as some what below code..

#define LINKLIST int data; struct node *link;

strcut node {

LINKLIST;
};


Thanks in Advance
Ranjeet

 

[Jaspreet]

Dear All

As I was going through the code, I find the below piece of code,

#define FILEMAPPING \
char *data; \
int size; \
char *position; \
int (*open)(struct FileMapping *self, const char *filename ); \
int (*close) (struct FileMapping *self ); \
int (*destroy) (struct FileMapping *self ); \
int (*isYourFile)(struct FileMapping *self, const char *filename, u32
*outSameFile );

typedef struct FileMapping
{
FILEMAPPING
} FileMapping, *FileMapping;

Over above they have declared the Macro Named FILEMAPPING but I am not
able to understand what does it really mean ?, they have declared the
macro which is going to be replaced in the structure FileMapping, But
why they want to go in the above format. ?

its is just same as some what below code..

#define LINKLIST int data; struct node *link;

strcut node {

LINKLIST;
};


Thanks in Advance
Ranjeet

Ranjeet I guess it just for better readiblity and code organisation so
that tomorrow if any other developer comes across this code he is able
to understand it better.

Imagine having all the variable and function decl. on the same line and
then compare it with seperate variable decl on different line and then
function decl. on different lines.

 

[SM Ryan]

(e-mail address removed) wrote:
# Dear All
#
# As I was going through the code, I find the below piece of code,
#
# #define FILEMAPPING \
# char *data; \
# int size; \
# char *position; \
# int (*open)(struct FileMapping *self, const char *filename ); \
# int (*close) (struct FileMapping *self ); \
# int (*destroy) (struct FileMapping *self ); \
# int (*isYourFile)(struct FileMapping *self, const char *filename, u32
# *outSameFile );
#
# typedef struct FileMapping
# {
# FILEMAPPING
# } FileMapping, *FileMapping;
#
# Over above they have declared the Macro Named FILEMAPPING but I am not
# able to understand what does it really mean ?, they have declared the
# macro which is going to be replaced in the structure FileMapping, But
# why they want to go in the above format. ?

Subtyping. If you want a FileMapping object, use struct {FILEMAPPING}. If
you want to derive a subtype that allows the segment length to be set,
#define EXTENDEDABLE_FILEMAPPING \
FILEMAPPING \
int (*setlength)(struct ExtendableFileMapping *self,long long);
typedef struct ExtendableFileMapping {
EXTENDEDABLE_FILEMAPPING
} ExtendableFileMapping;

If I remember aright you are guarenteed that if
ExtendableFileMapping *e = (plugh);
FileMapping *m = (FileMapping*)e;
then
&(m->data) == &(e->data)
&(m->size) == &(e->size)
. . .
&(m->isYourFile) == &(e->isYourFile)
so that you can cast a subtyped object to a supertype and access supertype
fields and methods either way.

The less tricky way to do this is
/*supertype*/
typedef struct FileMapping
char *data;
int size;
char *position;
int (*open)(struct FileMapping *self, const char *filename );
int (*close) (struct FileMapping *self );
int (*destroy) (struct FileMapping *self );
int (*isYourFile)(struct FileMapping *self, const char *filename, u32
*outSameFile );
} FileMapping;

/*subtype*/
typedef struct ExtendableFileMapping
FileMapping super;
int (*setlength)(struct ExtendableFileMapping *self,long long);
} ExtendableFileMapping;

ExtendableFileMapping *e = (plugh);
FileMapping *m = &(e->super);

 

[Grumble]

Ranjeet Gupta wrote:
# Dear All
#
[...]

Why do you use a non-standard quote character?
('#' instead of '>')

Your signature delimiter is incorrect.
(It should be DASH-DASH-SPACE-NEWLINE)

Is "exhilarating" misspelled on purpose?

 

[SM Ryan]

# SM Ryan wrote:
#
# > Ranjeet Gupta wrote:
# > # Dear All
# > #
# > [...]
# > --
# > SM Ryan http://www.rawbw.com/~wyrmwif/
# > I hope it feels so good to be right. There's nothing more
# > exhilirating pointing out the shortcomings of others, is there?
#
# Why do you use a non-standard quote character?
# ('#' instead of '>')

So I can look at post and see if it's a reply to me by just looking
at the body.

 

[john_bode]

Dear All

As I was going through the code, I find the below piece of code,

#define FILEMAPPING \
char *data; \
int size; \
char *position; \
int (*open)(struct FileMapping *self, const char *filename ); \
int (*close) (struct FileMapping *self ); \
int (*destroy) (struct FileMapping *self ); \
int (*isYourFile)(struct FileMapping *self, const char *filename, u32
*outSameFile );

typedef struct FileMapping
{
FILEMAPPING
} FileMapping, *FileMapping;

Over above they have declared the Macro Named FILEMAPPING but I am not
able to understand what does it really mean ?, they have declared the
macro which is going to be replaced in the structure FileMapping, But
why they want to go in the above format. ?

SM Ryan's explanation of subtyping makes sense, but...yuck. This is
one of those cases where you'd be better served using a language that
directly supports derived types (C++, Java, etc.).

One trick I saw in some old MacOS code was known as piggybacking.
People would create their own document types by starting with the base
Window type and adding attributes for their particular needs:

struct MyDocument {
Window wind;
char *docName;
char *docAuthor;
/* additional attributes as necessary */
};

Since a pointer to a struct is also necessarily a pointer to the first
element, people could pass a pointer to objects of type MyDocument to
the Toolbox routines where a pointer to a Window type was expected.
That way data that needed to be associated with a specific window could
be stored with that window. Simplified data management somewhat.

The tradeoff was that you wound up doing some ugly casting acrobatics.

 

[SM Ryan]

(e-mail address removed) wrote:

# One trick I saw in some old MacOS code was known as piggybacking.
# People would create their own document types by starting with the base
# Window type and adding attributes for their particular needs:

# Since a pointer to a struct is also necessarily a pointer to the first
# element, people could pass a pointer to objects of type MyDocument to
# the Toolbox routines where a pointer to a Window type was expected.
# That way data that needed to be associated with a specific window could
# be stored with that window. Simplified data management somewhat.

That's essentially what single inheritance languages like Smalltalk do
behind the scenes. The one difference is instead of packing data and
function pointers together, they pack the data and a pointer to a
struct of function pointers shared by every object in the same class.

 

[Chris Torek]

[I use something other than the usual ">" quote character] So [that]
I can look at post and see if it's a reply to me by just looking
at the body.

I believe there is a small flaw in this reasoning.