admin管理员组文章数量:1346064
I'm trying to make an implementation of a Vector in C (yes, I know, this has been done to death), generic across any types used. So far I have an implementation something like:
#define Vector(T) struct Vector_##T
// other routines, initialization, destruction, ...
// an example routine
#define DEFINE_VectorFirst(T) \
T VectorFirst_##T(Vector(T) vec) { \
return vec.data[0]; \
}
#define DEFINE_VECTOR(T) \
struct Vector_##T { \
T *data; \
size_t len; \
size_t capacity; \
}; \
DEFINE_VectorFirst(T)
// a few types for now
DEFINE_VECTOR(int)
DEFINE_VECTOR(double)
so I can, for example, declare a Vector(double) and then call VectorFirst_double on it. Ideally I'd like to not have to specify the type name every time, so I can use a generic:
#define GENERIC(F, T) Vector(T) : F##_##T
#define VectorFirst(v) \
_Generic((v), GENERIC(VectorFirst, int), GENERIC(VectorFirst, double))(v)
and now VectorFirst automatically calls the right version, but this loses the nice property that I can DEFINE_VECTOR in a bunch of different header files. In this way, the original version is "extensible", letting me make vectors of whatever structs I might declare elsewhere, but in the generic one I need to know all of the vector types I might ever need at one spot.
I could just use macros instead of functions for some things (#define VectorFirst(v) v.data[0] or the like) but it seems like this would make debugging annoying and maybe be slow for larger functions.
Are there any preprocessor techniques that can be used to restore this extensibility behavior and let me add new entries to a _Generic somewhere else? This is a small-scale test so I'm okay with whatever awful preprocessor hacks people know of.
I'm trying to make an implementation of a Vector in C (yes, I know, this has been done to death), generic across any types used. So far I have an implementation something like:
#define Vector(T) struct Vector_##T
// other routines, initialization, destruction, ...
// an example routine
#define DEFINE_VectorFirst(T) \
T VectorFirst_##T(Vector(T) vec) { \
return vec.data[0]; \
}
#define DEFINE_VECTOR(T) \
struct Vector_##T { \
T *data; \
size_t len; \
size_t capacity; \
}; \
DEFINE_VectorFirst(T)
// a few types for now
DEFINE_VECTOR(int)
DEFINE_VECTOR(double)
so I can, for example, declare a Vector(double) and then call VectorFirst_double on it. Ideally I'd like to not have to specify the type name every time, so I can use a generic:
#define GENERIC(F, T) Vector(T) : F##_##T
#define VectorFirst(v) \
_Generic((v), GENERIC(VectorFirst, int), GENERIC(VectorFirst, double))(v)
and now VectorFirst automatically calls the right version, but this loses the nice property that I can DEFINE_VECTOR in a bunch of different header files. In this way, the original version is "extensible", letting me make vectors of whatever structs I might declare elsewhere, but in the generic one I need to know all of the vector types I might ever need at one spot.
I could just use macros instead of functions for some things (#define VectorFirst(v) v.data[0] or the like) but it seems like this would make debugging annoying and maybe be slow for larger functions.
Are there any preprocessor techniques that can be used to restore this extensibility behavior and let me add new entries to a _Generic somewhere else? This is a small-scale test so I'm okay with whatever awful preprocessor hacks people know of.
1 Answer
Reset to default 3Are there any preprocessor techniques that can be used to restore this extensibility behavior and let me add new entries to a
_Genericsomewhere else?
Not as such. But you have to understand that _Generic is a (weird) operator. Every appearance is separate, including every instance resulting from expansion of a macro. There is no meaningful sense of "elsewhere" in which one could add entries to a particular generic selection expression.
Macros, on the other hand, can be defined and undefined fairly freely. You don't have to have a common definition that is shared everywhere. "Somewhere else" can provide their own definition that suits them.
You could perhaps facilitate each translation unit defining a suitable set of type-generic macros by leveraging X macros. It might look something like this:
generic_vector.h
// ...
// A suitable GENERIC_OPTS definition must be in scope already
#ifndef GENERIC_OPTS
#error no definition of GENERIC_OPTS
#endif
#define GENERIC(F, T) Vector(T) : F##_##T
#define VF_DECL(T) , GENERIC(VectorFirst, T)
#define VectorFirst(v) \
_Generic((v) \
GENERIC_OPTS(VF_DECL) \
)(v)
// ... other operations ...
other.c
#define GENERIC_OPTS(G) \
G(int) \
G(double) \
G(uint64_t)
#include "generic_vector.h"
#undef GENERIC_OPTS
// ...
There, the definition of GENERIC_OPTS in other.c controls what element types can be used with the VectorFirst() macro as defined in that file. If you need to generate function definitions as well, then they can be accommodated the same way, but you will want to declare them with internal linkage (i.e. static) if each translation unit is defining its own.
Do be aware, however, that C data type names can be arbitrarily complex. Even among just the (unqualified) standard arithmetic types, a majority have multi-word names, as @chux alluded to in comments. Your GENERIC() macro for building type-specific identifiers from type names will work as you intend only for type names that are single identifiers.
You can work around that by defining typedefs for types whose names are not a single identifier, but that gets nasty fast. If you really want to pursue this idea, then you should consider writing a full-fledged code generator instead of relying on the limited capabilities of the C preprocessor.
本文标签： quotExtensiblequot C genericsStack Overflow
版权声明：本文标题："Extensible" C generics - Stack Overflow 内容由网友自发贡献，该文观点仅代表作者本人， 转载请联系作者并注明出处：http://www.betaflare.com/web/1743822378a2545020.html， 本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，一经查实，本站将立刻删除。
#define GENERIC(F, T) Vector(T) : F##_##Twill have trouble with typelong long(types with a space in them). Your 1st approach apparently does not have that issue. – chux Commented 2 days agotypedefs, but that's still a fairly nasty gotcha. – John Bollinger Commented 2 days agoint*deserve testing too. (@JohnBollinger and hiding a pointer type in atypedefis an antipattern) – chux Commented 2 days ago