🔒 Locked

sizeof(struct) or sizeof(pointer)

Started by CyberSlag5k Mar 12, 2005 at 3:07 PM 21 replies 6k views

Original Post

120

Mar 12, 2005 at 3:07 PM

I'd imagine this one is nothing more than personal preference, but I'm looking for a good reason to choose one or the other. Let's say I have a struct:


struct _myStruct
{
   short int x;
   float y;
   double z;
} *structPtr;

And later I wish to use structPtr as a buffer, let's say I'm filling it using fread (that's what I was doing when I thought to ask this, so why not). Which do you guys think is the better (if any) convention: fread(structPtr, sizeof(struct _myStruct), 8, myFile); or fread(structPtr, sizeof(*structPtr), 8, myFile); My inclination is to go with the first one (struct _myStruct) for better readability (there's no question as to what structPtr points to). However the second (*structPtr) is a little easier as far as writeability is concerned, as the programmer doesn't need to worry about what the struct was saved as. Honestly it makes no difference to me at all, but I figure I might as well pick a convention and roll with it. So does anyone have any good reasons to go with one rather than the other? EDIT: BTW, is there a way to make those source boxes an appropriate size for the code contained within? There's no reason it needs to be that big. Can I specify something in the tag that'll make it adhere to the size of the code contained? [Edited by - CyberSlag5k on March 14, 2005 8:07:18 AM]

Mercury

Mar 12, 2005 at 3:09 PM

They're very different things entirely. The size of a pointer is always 4 bytes on 32-bit platforms. On 64-bit platforms it's 8 bytes.
When using operations on memory, always use the sizeof() the struct, never the pointer.

Miserable

Mar 12, 2005 at 3:19 PM

Quote:
Original post by Mercury
They're very different things entirely.

No, they're very much the same thing, since he's dereferencing the pointer.

Personally, I have no preference.

Mercury

Mar 12, 2005 at 3:21 PM

Quote:
Original post by Miserable
Quote:
Original post by Mercury
They're very different things entirely.

No, they're very much the same thing, since he's dereferencing the pointer.

Personally, I have no preference.

Oh, whoops. I didn't see him dereferencing it. My bad.

In that case, I prefer the sizeof struct.

Polymorphic OOP

Mar 12, 2005 at 3:31 PM

I recommend prefering sizeof( *structPtr ), since it more clearly couples the fact that you are using structPtr with the size of what it points to, without even having to know structPtr's type information at the time fread is called. As well, if the name of _myStruct changes or if the type of structPtr changes, you don't have to change any code at the call-site of fread since you are not explicitly refering to its type.

Anon Mike

117

Anon Mike

Mar 12, 2005 at 4:10 PM

I'm in the sizeof(*ptr) camp too. It's more future-proof in case the type of *ptr changes. If you want to call it out more you can do sizeof( * ptr) instead.

Extrarius

234

Extrarius

Mar 12, 2005 at 4:50 PM

I always use sizeof on whatever I'm talking about instead of types, so in this case it'd be sizeof(*ptr)
As other have said, it's more future-friendly since it doesn't matter if the pointer changes types or something else like that.

Madster

Mar 12, 2005 at 4:53 PM

OT: you can use the code tags instead of source, for monospaced text sans the box. Thats as far as I go. =)

dcosborn

Mar 13, 2005 at 12:54 AM

When using sizeof on a variable you don't need the parentheses; they're only necessary when using sizeof on a type.

CyberSlag5k

Author

120

CyberSlag5k

Mar 13, 2005 at 10:20 AM

Quote:
Original post by dcosborn
When using sizeof on a variable you don't need the parentheses; they're only necessary when using sizeof on a type.

Really? How does that work? Is sizeof a built in keyword in C/C++?

Anyway, thanks for everyones' response. I agree with the consensus, *tempPtr so that I don't need to remember what type it is and if *tempPtr changes types I don't have to worry about if the pointer points to a different type.

When doing a malloc, though, would I still need to deal with the struct:

tempPtr = (struct _myStruct *)malloc(sizeof *tempPtr);

or can I do something like this:

tempPtr = (**tempPtr)malloc(sizeof *tempPtr):

Zahlman

257

Zahlman

Mar 13, 2005 at 10:16 PM

Quote:
Original post by CyberSlag5k
Quote:
Original post by dcosborn
When using sizeof on a variable you don't need the parentheses; they're only necessary when using sizeof on a type.

Really? How does that work? Is sizeof a built in keyword in C/C++?

It is AFAIK. Honestly I don't really understand why the parentheses are necessary at all :)

iMalc

182

iMalc

Mar 13, 2005 at 10:48 PM

Quote:
Original post by CyberSlag5k
Quote:
Original post by dcosborn
When using sizeof on a variable you don't need the parentheses; they're only necessary when using sizeof on a type.

Really? How does that work? Is sizeof a built in keyword in C/C++?

Anyway, thanks for everyones' response. I agree with the consensus, *tempPtr so that I don't need to remember what type it is and if *tempPtr changes types I don't have to worry about if the pointer points to a different type.

When doing a malloc, though, would I still need to deal with the struct:

tempPtr = (struct _myStruct *)malloc(sizeof *tempPtr);

or can I do something like this:

tempPtr = (**tempPtr)malloc(sizeof *tempPtr):

Consider this another vote for using sizeof(*tempPtr) because it's one less thing to change if you change the variables type.

The only way to say "Use the same type as this thingy over here..." that I know of is to use templates.

template <class T> inline void Malloc(T *&ptr, int n) { ptr = (T*)malloc(sizeof(T) * n); }

or something like that (untested).

dcosborn

Mar 13, 2005 at 11:20 PM

Quote:
Original post by CyberSlag5k
tempPtr = (struct _myStruct *)malloc(sizeof *tempPtr);

malloc returns a void * which can be implicitly cast to any other type of pointer. So you can just say tempPtr = malloc(sizeof *tempPtr);

Miserable

Mar 14, 2005 at 12:50 AM

Quote:
Original post by dcosborn
malloc returns a void * which can be implicitly cast to any other type of pointer. So you can just say tempPtr = malloc(sizeof *tempPtr);

This is true, as I assume you are talking about C. It should be noted that it is illegal in C++.

CyberSlag5k

Author

120

CyberSlag5k

Mar 14, 2005 at 10:19 AM

Yeah the malloc thing is a bummer. We had a team meeting yesterday and I brought up this topic. Everyone agreed that using the dereferenced pointer is much nicer, but we're kind of stuck when it comes to malloc (we're using C++). Any other suggestions on how to get around it?

Simagery

Mar 14, 2005 at 11:05 AM

Not sure why malloc is causing you a problem in C++. It's certainly not illegal. Malloc is just a function from the standard C library, not a language keyword. In a way, it's impossible for malloc to be 'illegal' as it is defined using the language...

Anywho, if you're wanting to avoid using malloc in preference to new, then it's just a matter of:

MyStryct *tempPtr = new MyStruct;

Or, if you're looking to allocate 'x' number of bytes:

void *rawPtr = static_cast<void *>(new char[x]);

Though I would strongly recommend against the above unless you have a really good reason to allocate raw memory (dynamically growing struct or something).

dcosborn

Mar 14, 2005 at 11:33 AM

Just curious - if you're using C++, whats with all the C style code. You're using FILE * instead of std::ifstream and malloc instead of new. I would suggest that your problems stem from the fact that you're resisting the language.

CyberSlag5k

Author

120

CyberSlag5k

Mar 14, 2005 at 12:05 PM

Quote:
Original post by Simagery
Not sure why malloc is causing you a problem in C++. It's certainly not illegal. Malloc is just a function from the standard C library, not a language keyword. In a way, it's impossible for malloc to be 'illegal' as it is defined using the language...

Anywho, if you're wanting to avoid using malloc in preference to new, then it's just a matter of:
MyStryct *tempPtr = new MyStruct;
Or, if you're looking to allocate 'x' number of bytes:
void *rawPtr = static_cast<void *>(new char[x]);
Though I would strongly recommend against the above unless you have a really good reason to allocate raw memory (dynamically growing struct or something).

Oh, I have no problem with malloc. It just defeats the purpose of using dereferencing a pointer instead of just using the type name (as is the topic of the thread).

So while something like this works:

fread(structPtr, sizeof(*structPtr), 8, myFile);

Using malloc still requires a cast to a pointer of the desired type:

structPtr = (struct _my_type *)malloc(sizeof *structPtr);

Defeating the purpose of using *structPointer over another struct _my_type * for the sizeof.

Quote:
Original post by dcosborn
Just curious - if you're using C++, whats with all the C style code. You're using FILE * instead of std::ifstream and malloc instead of new. I would suggest that your problems stem from the fact that you're resisting the language.

Some fair questions. I use FILE because I'm reading the information in in binary (using fread) and I don't want any formatting being done. And we use malloc for situations where space is being reserved for things like dynamic arrays. New is used when we actually want a new instance.

*shrug* personal (team agreed upon) preferences.

Rattrap

125

Rattrap

Mar 14, 2005 at 12:16 PM

You do need to watch what the sizeof operator is returning. It generates the value at compile time, not at runtime. So if it is dynamically allocated, all your going to get is the pointer size.

CyberSlag5k

Author

120

CyberSlag5k

Mar 14, 2005 at 12:50 PM

Quote:
Original post by Rattrap
You do need to watch what the sizeof operator is returning. It generates the value at compile time, not at runtime. So if it is dynamically allocated, all your going to get is the pointer size.

Well the pointer size is just 4 bytes, which is what sizeof structPtr returns. The sizeof *structPtr should be the size of whatever type structPtr points to. In this case a _my_type, which could be any size. No?

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.