On a project I need to get the offset of particular structure members. However I can't use any macros. So I tried to take the logic behind this
#define OFFSETOF(struct_name, fld_name) \
(unsigned int)&(((struct_name *)0)->fld_name)
And to transform it into a function which gives me this.
unsigned long offset_of_1(void *ptr, void *field)
{
return ((unsigned long)field - (unsigned long)ptr);
}
It works as long as I use a structure that has been initialized, it is the only work around I found that seems to be working. But I was wondering if there was a better way of doing this ?
if there was a better way of doing this ?
Use the standard library offsetof().
Either
"I can't use any macros." --> Approach the rule makers to allow standard library macros. #StoryTeller - Unslander Monica #Steve Summit
Post the code that appears to "need to get the offset of particular structure members" and perhaps an alternative is possible.
Related
Suppose the following piece of C code:
#define SOME_MACRO(m) \
void (*f)(m); \
unsigned int a; \
int *self;
and then a struct that does
typedef struct _Str {
SOME_MACRO(whatever)
char sthg[2];
} STR;
My question is: what is the purpose of this design choice? It's not that we're saving time in indirection, for instance. Is there anything more here than an attempt at modularizing the code of _STR?
My project uses that pattern to ensure that certain methods/members are available in every project class (e.g. for marshalling). Again without more examples there's no way to confirm but that is my theory.
SOME_MACRO(m) translates to a function pointer to a function returning nothing which takes in one argument of type m, and also a unsigned int and a pointer to int. I believe the design reasons behind something like this is highly case-specific and without having more elaborate example of the code I would believe this is used for modularizing the code as you mention.
just from the code that you given ,i also can't make a explanation but it's seems some simple ,so that ,i think ,it's just a test macro by a new programmer because the meaning of "SOME_MACRO"=some macro test codes...
I'm inexperienced with C, and working on a microcontroller with messages stored in arrays where each byte does something different. How do I give each element of the array a human-readable name instead of referencing them as msg[1], msg[2], etc.?
Is this what structs are for? But "you cannot make assumptions about the binary layout of a structure, as it may have padding between fields."
Should I just use macros like this? (I know "macros are bad", but the code is already full of them)
#define MSG_ID msg[0]
#define MSG_COMMAND msg[1]
Oh! Or I guess I could just do
MSG_ID = 0;
MSG_COMMAND = 1;
MSG[MSG_ID];
That's probably better, if a little uglier.
If you want to go that route, use a macro, for sure, but make them better than what you suggest:
#define MSG_ID(x) (x)[0]
#define MSG_COMMAND(x) (x)[1]
Which will allow the code to name the arrays in ways that make sense, instead of ways that work with the macro.
Otherwise, you can define constants for the indexes instead (sorry I could not come up with better names for them...):
#define IDX_MSG_ID 0
#define IDX_MSG_COMMAND 1
And macros are not bad if they are used responsibly. This kind of "simple aliasing" is one of the cases where macros help making the code easier to read and understand, provided the macros are named appropriately and well documented.
Edit: per #Lundin's comments, the best way to improve readability and safety of the code is to introduce a type and a set of functions, like so (assuming you store in char and a message is MESSAGE_SIZE long):
typedef char MESSAGE[MESSAGE_SIZE];
char get_message_id(MESSAGE msg) { return msg[0]; }
char get_message_command(MESSAGE msg) { return msg[1]; }
This method, though it brings some level of type safety and allows you to abstract the storage away from the use, also introduces call overhead, which in microcontroller world might be problematic. The compiler may alleviate some of this through inlining the functions (which you could incentize by adding the inline keyword to the definitions).
The most natural concept for naming a set of integers in C are enumerations:
enum msg_pos { msg_id, msg_command, };
By default they start counting at 0 and increment by one. You would then access a field by msg[msg_id] for example.
It's fine to use a struct if you take the time to figure out how your compiler lays them out, and structs can very useful in embedded programming. It will always lay out the members in order, but there may be padding if you are not on an 8-bit micro. GCC has a "packed" attribute you can apply to the struct to prohibit padding, and some other compilers have a similar feature.
What advantage (if any) is there to using typedef in place of #define in C code?
As an example, is there any advantage to using
typedef unsigned char UBYTE
over
#define UBYTE unsigned char
when both can be used as
void func()
{
UBYTE byte_value = 0;
/* Do some stuff */
return byte_value;
}
Obviously the pre-processor will try to expand a #define wherever it sees one, which wouldn't happen with a typedef, but that doesn't seem to me to be any particular advantage or disadvantage; I can't think of a situation where either use wouldn't result in a build error if there was a problem.
If you do a typedef of an array type, you'll see the difference:
typedef unsigned char UCARY[3];
struct example { UCARY x, y, z; };
Doing that with a #define... no, let's not go there.
[EDIT]: Another advantage is that a debuggers usually know about typedefs but not #defines.
1) Probably the great advantage is a cleaner code.
Usually abusing macros transforms the code in an unmaintainable mess, known as: 'macro soup'.
2) By using a typedef you define a new type. Using a macro you actually substitute text. The compiler is surely more helpful when dealing with typedef errors.
Well, coming from a C++, perspective, a C++ programmer using your code might have something like:
template<typename T> class String
{
typedef T char_type;
// ...
};
Now, if in your C code, you've written something like:
#define char_type uint32_t // because I'm using UTF-32
Well, you are going to be causing serious trouble for the users of your header file. With typedefs, you can change the value of the typedef within different scopes... while scopes aren't respected with #defines.
I know that you've labeled this C, but C programmers and C++ programmers need to realize that their headers might be used by each other... and this is one of those things to keep in mind.
With #define all you get is string substitution during preprocessing. typedef introduces a new type. This makes it easier to find possible problems in your code and in case of any the compiler might be able to give you more detailed information.
Debuggers and compiler error messages become more helpful if the compiler/debugger knows about the type. (this is also why you should use constants and not defines where possible)
Arrays, as others have shown
you can restrict typedefs to a smaller scope (say, a function). Even more true in C++.
I want to get the size of a specific member in a struct.
sizeof(((SomeStruct *) 0)->some_member) works for me but I feel like there might be a nicer way to do it.
I could #define SIZEOF_ELEM(STRUCT, ELEM) sizeof(((STRUCT *) 0)->ELEM) and then use SIZEOF_ELEM(SomeStruct, some_member), but I wonder whether there is already something better built-in.
My specific use-case is in hsc2hs (Haskell C bindings).
pokeArray (plusPtr context (#offset AVFormatContext, filename)) .
take (#size ((AVFormatContext *) 0)->filename) .
(++ repeat '\NUL') $ filename
What you've got is about as clean as it gets if you can't guarantee you have a variable to dereference. (If you can, then use just sizeof(var.member) or sizeof(ptr->member), of course, but this won't work in some contexts where a compile-time constant is needed.)
Once upon a long, long time ago (circa 1990), I ran into a compiler that had 'offsetof' defined using the base address 0, and it crashed. I worked around the problem by hacking <stddef.h> to use 1024 instead of 0. But you should not run into such problems now.
Microsoft has the following in one of their headers:
#define RTL_FIELD_SIZE(type, field) (sizeof(((type *)0)->field))
I see no reason to do any different.
They have related macros for:
RTL_SIZEOF_THROUGH_FIELD()
RTL_CONTAINS_FIELD()
and the nifty:
CONTAINING_RECORD()
which helps implement generic lists in straight C without having to require that link fields be at the start of a struct. See this Kernel Mustard article for details.
I believe you've already got the correct solution there. You could dig up your stddef.h and look for how offsetof is defined, since it does a very similar thing.
Remember that there may well be a difference between the sizeof a member and the difference between the offsetofs of that member and the next one, due to padding.
In C++ you could do sizeof(SomeStruct::some_member), but this is c and you have no scope resolution operator. What you've written is as good as can be written, as far as I know.
Introduction
Hello folks, I recently learned to program in C! (This was a huge step for me, since C++ was the first language, I had contact with and scared me off for nearly 10 years.) Coming from a mostly OO background (Java + C#), this was a very nice paradigm shift.
I love C. It's such a beautiful language. What surprised me the most, is the high grade of modularity and code reusability C supports - of course it's not as high as in a OO-language, but still far beyond my expectations for an imperative language.
Question
How do I prevent naming conflicts between the client code and my C library code? In Java there are packages, in C# there are namespaces. Imagine I write a C library, which offers the operation "add". It is very likely, that the client already uses an operation called like that - what do I do?
I'm especially looking for a client friendly solution. For example, I wouldn't like to prefix all my api operations like "myuniquelibname_add" at all. What are the common solutions to this in the C world? Do you put all api operations in a struct, so the client can choose its own prefix?
I'm very looking forward to the insights I get through your answers!
EDIT (modified question)
Dear Answerers, thank You for Your answers! I now see, that prefixes are the only way to safely avoid naming conflicts. So, I would like to modifiy my question: What possibilities do I have, to let the client choose his own prefix?
The answer Unwind posted, is one way. It doesn't use prefixes in the normal sense, but one has to prefix every api call by "api->". What further solutions are there (like using a #define for example)?
EDIT 2 (status update)
It all boils down to one of two approaches:
Using a struct
Using #define (note: There are many ways, how one can use #define to achieve, what I desire)
I will not accept any answer, because I think that there is no correct answer. The solution one chooses rather depends on the particular case and one's own preferences. I, by myself, will try out all the approaches You mentioned to find out which suits me best in which situation. Feel free to post arguments for or against certain appraoches in the comments of the corresponding answers.
Finally, I would like to especially thank:
Unwind - for his sophisticated answer including a full implementation of the "struct-method"
Christoph - for his good answer and pointing me to Namespaces in C
All others - for Your great input
If someone finds it appropriate to close this question (as no further insights to expect), he/she should feel free to do so - I can not decide this, as I'm no C guru.
I'm no C guru, but from the libraries I have used, it is quite common to use a prefix to separate functions.
For example, SDL will use SDL, OpenGL will use gl, etc...
The struct way that Ken mentions would look something like this:
struct MyCoolApi
{
int (*add)(int x, int y);
};
MyCoolApi * my_cool_api_initialize(void);
Then clients would do:
#include <stdio.h>
#include <stdlib.h>
#include "mycoolapi.h"
int main(void)
{
struct MyCoolApi *api;
if((api = my_cool_api_initialize()) != NULL)
{
int sum = api->add(3, 39);
printf("The cool API considers 3 + 39 to be %d\n", sum);
}
return EXIT_SUCCESS;
}
This still has "namespace-issues"; the struct name (called the "struct tag") needs to be unique, and you can't declare nested structs that are useful by themselves. It works well for collecting functions though, and is a technique you see quite often in C.
UPDATE: Here's how the implementation side could look, this was requested in a comment:
#include "mycoolapi.h"
/* Note: This does **not** pollute the global namespace,
* since the function is static.
*/
static int add(int x, int y)
{
return x + y;
}
struct MyCoolApi * my_cool_api_initialize(void)
{
/* Since we don't need to do anything at initialize,
* just keep a const struct ready and return it.
*/
static const struct MyCoolApi the_api = {
add
};
return &the_api;
}
It's a shame you got scared off by C++, as it has namespaces to deal with precisely this problem. In C, you are pretty much limited to using prefixes - you certainly can't "put api operations in a struct".
Edit: In response to your second question regarding allowing users to specify their own prefix, I would avoid it like the plague. 99.9% of users will be happy with whatever prefix you provide (assuming it isn't too silly) and will be very UNHAPPY at the hoops (macros, structs, whatever) they will have to jump through to satisfy the remaining 0.1%.
As a library user, you can easily define your own shortened namespaces via the preprocessor; the result will look a bit strange, but it works:
#define ns(NAME) my_cool_namespace_ ## NAME
makes it possible to write
ns(foo)(42)
instead of
my_cool_namespace_foo(42)
As a library author, you can provide shortened names as desribed here.
If you follow unwinds's advice and create an API structure, you should make the function pointers compile-time constants to make inlinig possible, ie in your .h file, use the follwoing code:
// canonical name
extern int my_cool_api_add(int x, int y);
// API structure
struct my_cool_api
{
int (*add)(int x, int y);
};
typedef const struct my_cool_api *MyCoolApi;
// define in header to make inlining possible
static MyCoolApi my_cool_api_initialize(void)
{
static const struct my_cool_api the_api = { my_cool_api_add };
return &the_api;
}
Unfortunately, there's no sure way to avoid name clashes in C. Since it lacks namespaces, you're left with prefixing the names of global functions and variables. Most libraries pick some short and "unique" prefix (unique is in quotes for obvious reasons), and hope that no clashes occur.
One thing to note is that most of the code of a library can be statically declared - meaning that it won't clash with similarly named functions in other files. But exported functions indeed have to be carefully prefixed.
Since you are exposing functions with the same name client cannot include your library header files along with other header files which have name collision. In this case you add the following in the header file before the function prototype and this wouldn't effect client usage as well.
#define add myuniquelibname_add
Please note this is a quick fix solution and should be the last option.
For a really huge example of the struct method, take a look at the Linux kernel; 30-odd million lines of C in that style.
Prefixes are only choice on C level.
On some platforms (that support separate namespaces for linkers, like Windows, OS X and some commercial unices, but not Linux and FreeBSD) you can workaround conflicts by stuffing code in a library, and only export the symbols from the library you really need. (and e.g. aliasing in the importlib in case there are conflicts in exported symbols)