When you define a new struct
is better to define also an interface to that type
(i.e. "setter" and "getter" functions) or to access members directly via .
and ->
operators?
EDIT
Plain C programming
When you define a new struct
is better to define also an interface to that type
(i.e. "setter" and "getter" functions) or to access members directly via .
and ->
operators?
EDIT
Plain C programming
With C you would typically not define setters and getters for each struct member.
The advantages of setters and getters is present in C++ because you can do data hiding via private and protected. With C there is no such concept of private and protected struct members.
If you were reading someone else's code, would you rather see:
setSomeValue(&aStruct, VALUE);
or:
aStruct.someValue = VALUE;
The syntax of the second makes it obvious that a field of aStruct is being set. In the first, you're depending on the function and variable names chosen by the programmer to get that information.
In C, if you are creating a new struct it already has setter/getter built in. If you are using a variable name, you use varName.memberElement and if you are using a struct pointer: pointer-->memberElement. For instance:
struct Random
{
int temp;
};
If we create a struct variable, struct Random example
then we can access and set variables using the . notation.
example.temp = 12345;
If we create a struct pointer, we would use -> notation.
struct Random element, *pointer;
pointer = &element;
We set pointer to point at element and then to access members,
pointer->temp = 12345;
No need to create separate setter/getter interfaces and functions in C. Don't make more work for yourself.
It depends of the size of the program and intended use. Bear in mind that all members of a struct are public by default. If you need them to be private, use "class" instead.
Following up Brian Bondy's answer, in C you cannot have getters and setters; member functions are just not part of the language.
In C++, typically they are not used because structs almost always contain, by convention, Plain Old Data and the members are just accessed directly.
It depends on whether your struct is an abstract data type or not. If you make the struct definition public in your header, then defining accessors doesn't make any sense - API clients can still read/write fields directly, and, in C, they do have reasonable expectation that it will work.
On the other hand, you may want to hide the struct entirely, and only show its declaration to the clients, as a kind of an opaque handle:
foo.h:
typedef struct foo foo;
foo* foo_create();
void foo_free(foo*);
int foo_get_bar(foo*);
void foo_set_bar(foo*, int);
foo.cpp:
struct foo {
int bar;
};
foo* foo_create() { return malloc(sizeof(foo)); }
void foo_free(foo* p) { free(p); }
int foo_get_bar(foo* p) { return p->bar; }
void foo_set_bar(foo* p, int newval) { p->bar = nwval; }
client.cpp:
#include "foo.h"
foo* f = foo_create();
f->bar = 123; // compile error, bar is not defined
foo_set_bar(f, 123); // ok
The reason for doing it that way is 1) encapsulation, same as in OO, and 2) versioning - you may add new fields to your struct, or reorganize them freely, and old code will remain binary-compatible.