I've been looking at different implementations of qsort, and there's a line in the source found here (https://code.woboq.org/userspace/glibc/stdlib/qsort.c.html) that I don't understand. It looks like a function pointer declaration. I'd appreciate any help. I've included as much code as necessary (with the line noted) to I think answer the question. Please let me know if not, thanks.
typedef struct
{
char *lo;
char *hi;
} stack_node;
void _quicksort (void *const pbase, size_t total_elems, size_t size, cmp_t cmp, void *arg)
{
char *base_ptr = (char *) pbase;
const size_t max_thresh = 4 * size;
if (total_elems == 0)
return;
if (total_elems > 4)
{
char *lo = base_ptr;
char *hi = &lo[size * (total_elems - 1)];
stack_node stack[(8 * sizeof(size_t))];
stack_node *top = stack;
/* Line below is a function pointer declaration? Initializes struct? */
((void) ((top->lo = (((void*)0))), (top->hi = (((void*)0))), ++top));
while ((stack < top))
{
char *left_ptr;
char *right_ptr;
char *mid = lo + size * ((hi - lo) / size >> 1);
... code goes on
No, it is not a function pointer declaration. It is just a convoluted way to say
top->lo = 0;
top->hi = 0;
++top;
You can rewrite the above as a single expression statement using , operator
top->lo = 0, top->hi = 0, ++top;
then add unnecessary casts
top->lo = (void *) 0, top->hi = (void *) 0, ++top;
and a bunch of redundant ()s
(top->lo = (((void *) 0))), (top->hi = (((void *) 0))), ++top;
and then cast the whole thing to (void) (say, to suppress any potential compiler warnings about expression result's being "unused")
((void) ((top->lo = (((void *) 0))), (top->hi = (((void *) 0))), ++top));
and now you have your original version.
Why someone decided to use that strange syntax with , operator and massive amount of redundant () is not clear to me. Looks like a macro expansion. Maybe it is a piece of already-preprocessed code? The ((void *) 0) parts might easily be preprocessor replacements for standard NULL macro.
Looking at the URL we discover that the line is actually a macro definition in particular
/* The next 4 #defines implement a very fast in-line stack abstraction. */
/* The stack needs log (total_elements) entries (we could even subtract
log(MAX_THRESH)). Since total_elements has type size_t, we get as
upper bound for log (total_elements):
bits per byte (CHAR_BIT) * sizeof(size_t). */
#define STACK_SIZE (CHAR_BIT * sizeof(size_t))
#define PUSH(low, high) ((void) ((top->lo = (low)), (top->hi = (high)), ++top))
#define POP(low, high) ((void) (--top, (low = top->lo), (high = top->hi)))
#define STACK_NOT_EMPTY (stack < top)
and the code actually appears in the definition of PUSH and its compendium appears in POP. The use of extra ()s is to ensure that ++top and --top happen inline and in the correct sequence.
The reason it's implemented this way is clearer when we see the Copyright (C) 1991 - 2017 message at the top of the qsort.c ... Compilers in 1991 were probably really sucky at inlining functions.
Related
memset_pg.h
#include <stdint.h>
#include<stdio.h>
#include<string.h>
#define LONG_ALIGN_MASK (sizeof(long) - 1)
typedef size_t Size;
#define MEMSET_LOOP_LIMIT 1024
/*
* MemSet
* Exactly the same as standard library function memset(), but considerably
* faster for zeroing small word-aligned structures (such as parsetree nodes).
* This has to be a macro because the main point is to avoid function-call
* overhead. However, we have also found that the loop is faster than
* native libc memset() on some platforms, even those with assembler
* memset() functions. More research needs to be done, perhaps with
* MEMSET_LOOP_LIMIT tests in configure.
*/
#define MemSet(start, val, len) \
do \
{ \
/* must be void* because we don't know if it is integer aligned yet */ \
void *_vstart = (void *) (start); \
int _val = (val); \
Size _len = (len); \
\
printf("_vstart: %lu\n",(uintptr_t) _vstart); \
if ((((uintptr_t) _vstart) & LONG_ALIGN_MASK) == 0 && \
(_len & LONG_ALIGN_MASK) == 0 && \
_val == 0 && \
_len <= MEMSET_LOOP_LIMIT && \
/* \
* If MEMSET_LOOP_LIMIT == 0, optimizer should find \
* the whole "if" false at compile time. \
*/ \
MEMSET_LOOP_LIMIT != 0) \
{ \
long *_start = (long *) _vstart; \
long *_stop = (long *) ((char *) _start + _len); \
while (_start < _stop) \
*_start++ = 0; \
printf("non-standard MemSet invoked\n"); \
} \
else { \
memset(_vstart, _val, _len); \
printf("standard memset invoked\n"); \
} \
} while (0)
#define TEST "test"
memset_pg.c
/*
gcc -Wall -Werror memset_pg.c && ./a.out
*/
#include "memset_pg.h"
#include<stdio.h>
#include<inttypes.h>
#include<assert.h>
int main(void)
{
printf("LONG_ALIGN_MASK:%ld\n",LONG_ALIGN_MASK);
// char str[] = "beautiful earth";
char str[] = "earth567";
printf("strlen=%ld\n",strlen(str));
MemSet(str,0,strlen(str));
printf("via MemSet: str return |%s|\n",str);
printf("str pointer:%ld\n", (uintptr_t)str);
return 0;
}
I am not sure this part ((uintptr_t) _vstart) & LONG_ALIGN_MASK mean. It means at least the pointer cast to unsign long ending 3 bit should be 000. But I don't know the pattern mean.
typedef struct POD_OnlyStruct{
int a;
int b;
char d;
}POD_OnlyStruct;
POD_OnlyStruct t;
MemSet(&t,0, sizeof t);
the above will not invoke non-standard memset.
However, the following will invoke the non-standard memset.
typedef struct POD_OnlyStruct{
int a;
int b;
int c;
char d;
}POD_OnlyStruct;
POD_OnlyStruct t;
MemSet(&t,0, sizeof t);
(_len & LONG_ALIGN_MASK) == 0 means that the _len is power of 8.
In long *_stop = (long *) ((char *) _start + _len); I am not sure the usage of (char *).
I am not sure this part ((uintptr_t) _vstart) & LONG_ALIGN_MASK mean.
_vstart Is a void pointer. By casting it to a uintptr_t it becomes a number we can work with, this suppresses an error for the next operation. By doing the & LONG_ALIGN_MASK we check if this pointer is aligned to some boundry. According to the rest of your post, we check if the last three digits are zero.
The guiding text tells you why to do it. To me (purely opinion here) it needs to have a massive advantage over the memset in the libraries to be worth it, because the code is hard to read.
Edit: A new question was added:
In long *_stop = (long *) ((char *) _start + _len); I am not sure the usage of (char *)
Pointer arithmetic! A char is by definition 1 byte, but a long can be a couple more. Say we do long* a = ((long*)NULL) + 1, we now see that a = sizeof(long)/sizeof(char) = sizeof(long). This is just how pointer arithmetic works, adding one to some pointer will actually add the size of the type of the pointer to it. This is very useful when, for example, traversing an array via a pointer, plus 1 will always go to the start of the next element (given that you started at the start of some element).
So the cast to char* here makes sure that we are adding _len to _start, and not _len*sizeof(long). This usage, by the way, means that _len has to be an uintptr_t and not a size_t. A size_t is defined as the maximum array index, while uintptr_t is guaranteed to be able to contain any pointer. On most systems this does not matter (max array index == UINTPTR_MAX, usually), but technically this is an issue.
Note that casting _vstart to uintptr_t instead of (char*) would have had the same effect and maybe be more readable.
I am not sure this part ((uintptr_t) _vstart) & LONG_ALIGN_MASK mean.
This is to check whether the start address has the same alignment as a long, because if it is not, then the expression (long *) _vstart has undefined behaviour.
Note that nowadays compilers know that memset() clears memory, and will actually inline it if they see you are only setting a small amount of memory. So this MemSet() macro is completely unnecessary. In fact, some compilers might even see that the while-loop in that code is equivalent to a memset(), and replace it with a function call if they think that is more efficient (note that compilers can be told to optimize for size over performance).
In long *_stop = (long *) ((char *) _start + _len); I am not sure the usage of (char *).
This is because _start is a pointer to long. If you add _len to that, it would advance it _len times the size of long. To make sure it just adds _len bytes, you need to cast it to char * first. Also remember that ptr + offset is equivalent to &ptr[offset].
I am fiddling around with an implementation of a generic dynamic array. The array should hold information about its size, how many entries are used, and then hold the actual data. The meta-information (size/used) is generic, but the data needs to handle different types, so I am handling that with macros. I am trying, however, to get the memory allocation code into functions. So my thought it is: I have a struct for meta-information
struct da_meta {
size_t size;
size_t used;
};
and then I have a macro that creates a struct per type, using a flexible array following the meta information:
#define dynarray(TYPE) \
struct { \
struct da_meta meta; \
TYPE data[]; \
}
I can declare an integer array, for example, as
dynarray(int) *int_array = 0;
To allocate and reallocate arrays, my thought was now to use code such as this:
#define size_overflow(meta_size, obj_size, len) \
((SIZE_MAX - meta_size) / obj_size < len)
// Always free if we cannot reallocate
void *realloc_dynarray_mem(void *p,
size_t meta_size,
size_t obj_size,
size_t new_len)
{
if (size_overflow(meta_size, obj_size, new_len))
goto abort;
struct da_meta *new_da =
realloc(p, meta_size + obj_size * new_len);
if (!new_da) goto abort;
new_da->size = new_len;
new_da->used = MIN(new_da->used, new_len);
return new_da;
abort:
free(p);
return 0;
}
The function gets the size of the struct sans the data objects, the size of individual objects, and the number of objects to allocate memory for. I don't use the size of the struct meta type, because it might be too small depending on the alignment of the data objects, but I will get it from sizeof the concrete (typed) structures. The function will always free the input and return NULL if I cannot allocate because in my application I have to give up if I cannot grow the array, so I don't try to preserve the old data in case there is an error.
There is nothing wrong with this code, as far as I can tell. I can always allocate memory, and as long as I have more than the size of struct meta, I can set the variables there. But when I return the result and use it as a dynarray(T) type, I am less sure. I think it should work, because C should put the memory of the first member of a struct first in a struct, and that is where I put struct meta, but am I right here?
I create a new array like this:
void *new_dynarray_mem(size_t meta_size,
size_t obj_size,
size_t len)
{
struct da_meta *array =
realloc_dynarray_mem(0, meta_size, obj_size, len);
if (array) {
// we do set size in realloc, but
array->size = len;
// if used was not initialised in realloc (and it wasn't)
// then we have to set it here...
array->used = 0;
}
return array;
}
#define new_da(type, init_size) \
new_dynarray_mem(sizeof(dynarray(type)), \
sizeof(type), init_size)
Here, the macro new_da() gets the size of the header/meta information from sizeof(dynarray(type)) and the size of the underlying types from sizeof(type). The second value is fine, but I am also uncertain about the first. Does the C standard guarantee that if I create two different structs with exactly the same code, e.g., calling dynarray(int) twice, that I get the same memory layout? I cannot imagine a compiler that would give me a different layout for the same code, but when it comes to imagining what compilers get up to, I am quite limited.
For appending to the array, I think all is fine. There I do not generate new types but get the size from the existing dynamic array, so if the first allocation is standard compliant, then I think the appending is as well, but I could be wrong.
#define da_free(da) \
do { free(da); da = 0; } while(0)
#define grow(size) \
(((size) == 0) ? /* special case for zero */ \
1 : \
((size) > SIZE_MAX / 2) ? /* can we grow? */ \
0 : /* no, then report size zero */ \
(2 * (size))) /* double the size */
#define da_append(da, ...) \
do { \
if (da->meta.used == da->meta.size) { \
size_t new_size = grow(da->meta.size); \
if (new_size == 0) { da_free(da); break; } \
da = realloc_dynarray_mem( \
da, sizeof *da, *da->data, new_size \
); \
if (!da) break; \
} \
da->data[da->meta.used++] = __VA_ARGS__; \
} while (0)
Am I guaranteed that if I lay out the concrete dynamic arrays with the meta-information at the top of the structs, then I can treat the allocate memory as both a pointer to the meta-information and the array? Is it safe to assume that I get the same size and memory layout if I generate the same struct twice? I feel that it must be that way since it shouldn't differ from if I include the same header file twice, but since I am generating the code there might be something that I am missing.
EDIT Based on the comments, I have updated the code to that below, but I have left the original code (of course) so the comments make sense in terms of that.
#define da_at(da,i) (da->data[(i)])
#define da_len(da) (da->meta.used)
struct da_meta {
size_t size;
size_t used;
};
#define dynarr(TYPE) \
struct { \
struct da_meta meta; \
TYPE data[]; \
}
// Always free if we cannot reallocate
void *realloc_dynarray_mem(struct da_meta *p,
size_t meta_size,
size_t obj_size,
size_t new_len)
{
// Size size overflow?
if (((SIZE_MAX - meta_size) / obj_size < new_len))
goto fail;
struct da_meta *new_da =
realloc(p, meta_size + obj_size * new_len);
if (!new_da) goto fail;
new_da->size = new_len;
new_da->used = MIN(new_da->used, new_len);
return new_da;
fail:
free(p);
return 0;
}
void *new_dynarray_mem(size_t meta_size,
size_t obj_size,
size_t len)
{
struct da_meta *array =
realloc_dynarray_mem(0, meta_size, obj_size, len);
if (array) array->used = 0;
return array;
}
void *grow_dynarray_mem(struct da_meta *p,
size_t meta_size,
size_t obj_size)
{
// Can we double the length?
size_t used = meta_size - obj_size * p->size;
size_t adding = MAX(1, p->size);
if ((SIZE_MAX - used) / obj_size < adding) {
free(p);
return 0;
}
return realloc_dynarray_mem(
p, meta_size, obj_size, p->size + adding
);
}
#define new_da(da, init_size) \
new_dynarray_mem(sizeof *(da), \
sizeof *(da)->data, \
(init_size))
#define da_free(da) \
do { free(da); da = 0; } while(0)
#define da_append(da, ...) \
do { \
if (da->meta.used == da->meta.size) { \
da = grow_dynarray_mem( \
(struct da_meta *)da, \
sizeof *da, sizeof *da->data \
); \
if (!da) break; \
} \
da->data[da->meta.used++] = __VA_ARGS__; \
} while (0)
When used, the code can look like this:
int main(void)
{
dynarr(int) *int_array = new_da(int_array, 0);
if (!int_array) goto error;
printf("%zu out of %zu\n",
int_array->meta.used,
int_array->meta.size);
for (int i = 0; i < 5; i++) {
da_append(int_array, i);
if (!int_array) goto error;
}
for (int i = 0; i < da_len(int_array); i++) {
printf("%d ", da_at(int_array, i));
}
printf("\n");
da_free(int_array);
return 0;
error:
return 1;
}
Just remember about padding between between meta and the start of the array and about alignment requirements and you should be fine.
because C should put the memory of the first member of a struct first in a struct, and that is where I put struct meta, but am I right here?
Yes.
Am I guaranteed that if I lay out the concrete dynamic arrays with the meta-information at the top of the structs, then I can treat the allocate memory as both a pointer to the meta-information
Yes, and...
and the array?
No. The array starts at address after meta + padding. So at address (char*)da + sizeof(dynarray(TYPE)) or just da->data.
Is it safe to assume that I get the same size and memory layout if I generate the same struct twice?
No and yes. There are many other great stackoverflow questions and answers about that topic - research them. Pragmatically yes, it would be a strange compiler that would would generate different padding for the same looking struct, but technically that's allowed.
using a flexible array
Unless you have specific aim, then I would just advise not to use them. It makes it harder for you to write the code. It makes it very hard to create and manage an array of such arrays.
goto abort;
What an unfortunate name for a goto label - abort() is a standard function.
#define grow(size)
Please use a prefix to all your library functions, especially macros. Defining such macro will make it impossible to use it in other code that happens to use a different grow() function. da_ seems like a good prefix.
I guess *da->data in realloc_dynarray_mem should be sizeof(*da->data).
#edit
I would suggest to use typeof keyword in new_da(). This would avoid specifying the type twice: in dynarray(TYPE) and in new_da(type, init_size). To make it, instead of passing the type, just pass the pointer on the dynamic array:
#define new_da(da, init_size) \
(da) = new_dynarray_mem(sizeof(dynarray(typeof(*(da)))), \
sizeof(typeof((da)->data[0])), (init_size))
Hence, this would avoid the mistake where the type used in the definition would differ from the type used in the allocation:
dynarray(int) *pInt;
pInt = new_da(char, 1024);
UPDATE FROM DISCUSSION IN COMMENTS:
And what about a single macro to define and initialize ?
#define new_da(da, type, init_size) \
dynarray(type) *da = new_dynarray_mem(sizeof(dynarray(type)), sizeof(type), init_size)
I am trying to port a program that uses the GCC transparent union extension but the compiler I need to use doesn't support them. When I compile the program I get a mismatch between the caller and the function prototype. I think all I have to do is add a cast to each caller, but I am not sure. What is the easiest way to code around this lack in the compiler?
The code I am trying to port is Quagga 1.1.0. The OS is Solaris with the Oracle Studio compiler.
Here is the error I get:
quagga-1.1.0/lib/zclient.c", line 1030: argument #1 is incompatible with prototype:
prototype: union prefix46constptr {pointer to const struct prefix {..} p, pointer to const struct prefix_ipv4 {..} p4, pointer to
const struct prefix_ipv6 {..} p6} : "quagga-1.1.0/lib/prefix.h", line
228
argument : pointer to struct prefix {unsigned char family, unsigned char prefixlen, union {..} u}
Here is the function being called:
const char *
prefix2str (union prefix46constptr pu, char *str, int size)
{
Here is the line where the function is called:
prefix2str (ifc->address, buf, sizeof buf))
And here are the transparent unions:
union prefix46ptr
{
struct prefix *p;
struct prefix_ipv4 *p4;
struct prefix_ipv6 *p6;
} __attribute__ ((transparent_union));
union prefix46constptr
{
const struct prefix *p;
const struct prefix_ipv4 *p4;
const struct prefix_ipv6 *p6;
} __attribute__ ((transparent_union));
Here is the whole function:
const char *
prefix2str (union prefix46constptr pu, char *str, int size)
{
const struct prefix *p = pu.p;
char buf[BUFSIZ];
if (p->family == AF_ETHERNET) {
int i;
char *s = str;
assert(size > (3*ETHER_ADDR_LEN) + 1 /* slash */ + 3 /* plen */ );
for (i = 0; i < ETHER_ADDR_LEN; ++i) {
sprintf(s, "%02x", p->u.prefix_eth.octet[i]);
if (i < (ETHER_ADDR_LEN - 1)) {
*(s+2) = ':';
s += 3;
} else {
s += 2;
}
}
sprintf(s, "/%d", p->prefixlen);
return 0;
}
inet_ntop (p->family, &p->u.prefix, buf, BUFSIZ);
snprintf (str, size, "%s/%d", buf, p->prefixlen);
return str;
}
Ok, first of all, StackOverflow is (at least, in my opinion) not a place where you go to submit bugs for a project. Bug reports should be submitted in a mailing list or bug tracker for the project in question.
In this case, it seems a non-standard feature has been used where a standard feature would suffice. Remove __attribute__ ((transparent_union)) and const struct prefix *p = pu.p;, and replace union prefix46constptr pu with const struct prefix *p.
You'll also most likely need to modify some code in headers, and make other changes which should be done by whoever is fixing the bug. I assume they're competent C programmers and will understand how to do that... but then again, they should understand how to make the above changes, too!
There are times when a design is just too cromulent to deal with, and this is one of those times. I advise seeking other alternatives, if you can! One should not simply hack IPV6 support in as though IPV4 functions can be modified to produce the required functionality.
Folks
I am trying to understand if there is any thing in the following piece of code that will cause it to fail on 64 bit platforms. My main concern is whether some type conversions are happening that are not suitable for 64 bit. Do not pay too much attention on the actual numbers assigned to the variables as i made them up just for this example. My main concern is the type conversion issues happening between long and int and size_t and any other issues you may see.
#define NL_AREA 40
#define NS_AREA 38
#define NB_EXTRA (1536 - NS_AREA * NL_AREA)
main()
{
long int bufsize;
int obssize, nelm, nbuf;
int ncol, ndet = 10;
void *result;
obssize = xxx; /* some size */
bufsize = (long)obssize * (NL_AREA * NS_AREA + NB_EXTRA);
ncol = 50;
nbuf = ncol * ndet;
nelm = 1;
result = Buf_Init(bufsize, nelm, nbuf);
}
void *
Buf_Init( size_t elm_size,
int nelm_buf,
long nbuf )
{
long buf_size;
void *p;
buf_size = ((long) elm_size) * nelm_buf;
if ((p = (void *)malloc(buf_size)) == NULL)
return NULL;
else
return p;
}
I could comment on type conversions, but... why ponder about unexpected type conversions in your code when you can avoid them completely? If portability is important, then don't use the default primitive data types. Use stdint.h instead.
Swap int for int32_t.
Swap long for int32_t.
Keep size_t as it is, or swap it for uint32_t in case it matters. Most likely it does not.
And suddenly the code turned 100% portable.
Other comments:
Why would you do (void *)malloc(buf_size)? Casting from void* to void* doesn't make any sense.
For a hosted system, main() must always return int. Implicit int has been removed from the C language 15 years ago.
I am getting back into using C, but I've been spoiled by generics in other languages. I have made it to the following piece of code in my implementation of a resizable array:
typdef struct {
void** array;
int length;
int capacity;
size_t type_size;
} Vector;
void vector_add(Vector* v, void* entry) {
// ... code for adding to the array and resizing
}
int main() {
Vector* vector = vector_create(5, sizeof(int));
vector_add(vector, 4); // This is erroneous...
// ...
}
In my attempt to make this generic, I'm now unable to add an integer to the vector without storing it in memory somewhere else.
Is there any way to make this work (either as is, or possibly a better approach to generics)?
For my answer I am assuming that you are not familiar with the sections of memory (ie the use of the memory pool).
In my attempt to make this generic, I'm now unable to add an integer to the vector without storing it in memory somewhere else.
If you want to create a generic structure (as you did) then you will need to use void pointers. Consequently, from the use of void pointers you will need to store the values for each field on the memory pool, or uncommonly on the stack. Note, the structure is composed of void pointers and hence only memory addresses are contained within the structure, pointing to other locations in memory where the values are.
Be careful if you declare them on the stack as once your stack frame is popped from the call stack those memory addresses are not considered to be valid and hence may be used by another stack frame (overwriting your existing values within that collection of memory addresses).
Aside: If you migrate to C++ then you can consider the use of C++ templates.
Yes; you can embrace Greenspun's Tenth Rule and develop a full blown dynamic language in C, and in the process, develop a relatively clean C run time that can be used from within C.
In this project I did just that, as have others before me.
In the C run time of this project, a generic number would be created from a C number like this:
val n = num(42);
because of the way val is represented, it takes up only a machine word. A few bits of type tag are used to distinguish a number from a pointer, from a character, etc.
There is also this:
val n = num_fast(42);
which is much faster (a bit manipulation macro) because it doesn't do any special checks that the number 42 fits into the "fixnum" range; it's used for small integers.
A function that adds its argument to every element of a vector could be written (very inefficiently) like this:
val vector_add(val vec, val delta)
{
val iter;
for (iter = zero; lt(iter, length(vec)); iter = plus(iter, one)) {
val *pelem = vecref_l(vec, iter);
*pelem = plus(*pelem, delta);
}
return nil;
}
Since plus is generic, this will work with fixnums, bignums and reals, as well as with characters, since it is possible to add integer displacements to characters via plus.
Type mismatch errors will be caught by the lower level functions and turned into exceptions. For instance if vec isn't something to which length can be applied, length will throw.
Functions with a _l suffix return a location. Wherease vecref(v, i) returns the value at offset i in vector v, vecref_l(v, i) returns a pointer to the val typed location in the vector which stores that value.
It's all C, just with the ISO C rules bent a little bit: you can't make a type like val efficiently in strictly conforming C, but you can do it quite portably to architectures and compilers you care about supporting.
Our vector_add isn't generic enough. It's possible to do better:
val sequence_add(val vec, val delta)
{
val iter;
for (iter = zero; lt(iter, length(vec)); iter = plus(iter, one)) {
val elem = ref(vec, iter);
refset(vec, iter, plus(elem, delta));
}
return nil;
}
By using the generic ref and refset, this now works with lists and strings also, not only vectors. We can do something like:
val str = string(L"abcd");
sequence_add(str, num(2));
The contents of str will change to cdef since a displacement of 2 is added to each character, in place.
Your idea can be done:
int *new_int = (int*)malloc(sizeof(int));
*new_int = 4;
vector_add(vector, new_int);
Naturally, it would be a good idea to do a int *create_int(int x) function or something similar:
int *create_int(int x)
{
int *n = (int*)malloc(sizeof(int));
*n = 4;
return n;
}
//...
vector_add(vector, create_int(4));
If your environment allows it you may consider using a well tested, widely used library that already manages all that, such as Glib. Or even C++.
You can avoid having many many small allocations by storing the data instead of pointers to it, like
typedef struct {
char* array;
int length;
int capacity;
size_t type_size;
} Vector;
bool vector_add(Vector* v, void* entry)
{
if (v->length < v->capacity || vector_expand(v)) {
char* location = v->array + (v->length++)*(v->type_size);
memcpy(location, entry, v->type_size);
return 1;
}
return 0; // didn't fit
}
int main()
{
Vector* vector = vector_create(5, sizeof(int));
int value = 4;
vector_add(vector, &value); // pointer to local is ok because the pointer isn't stored, only used for memcpy
}
Yes, here's an implementation of mine (similar to yours) that may help. It uses macros that can be wrapped with function calls for immediate values.
#ifndef VECTOR_H
# define VECTOR_H
# include <stddef.h>
# include <string.h>
# define VECTOR_HEADROOM 4
/* A simple library for dynamic
* string/array manipulation
*
* Written by: Taylor Holberton
* During: July 2013
*/
struct vector {
void * data;
size_t size, len;
size_t headroom;
};
int vector_init (struct vector *);
size_t vector_addc (struct vector *, int index, char c);
size_t vector_subc (struct vector *, int index);
// these ones are just for strings (I haven't yet generalized them)
size_t vector_adds (struct vector *, int index, int iend, const char * c);
size_t vector_subs (struct vector *, int ibegin, int iend);
size_t vector_addi (struct vector *, int index, int i);
size_t vector_subi (struct vector *, int index);
# define vector_addm(v, index, datatype, element) \
do { \
if (!v) return 0; \
\
if (!v->size){ \
v->data = calloc (v->headroom, sizeof (datatype)); \
v->size = v->headroom; \
} \
\
datatype * p = v->data; \
\
if (v->len >= (v->size - 2)){ \
v->data = realloc (v->data, \
(v->size + v->headroom) * sizeof (datatype)); \
p = v->data; \
memset (&p[v->size], 0, v->headroom * sizeof(datatype));\
v->size += v->headroom; \
} \
\
if ((index < 0) || (index > v->len)){ \
index = v->len; \
} \
\
for (int i = v->len; i >= index; i--){ \
p[i + 1] = p[i]; \
} \
\
p[index] = element; \
\
v->len++; \
\
} while (0)
# define vector_subm(v, index, datatype) \
do { \
if (!v || !v->len){ \
return 0; \
} \
\
if ((index < 0) || (index > (v->len - 1))){ \
index = v->len - 1; \
} \
\
datatype * p = v->data; \
\
for (int i = index; i < v->len; i++){ \
p[i] = p[i + 1]; \
} \
\
v->len--; \
\
if ((v->size - v->len) > v->headroom){ \
v->data = realloc (v->data, ((v->size - v->headroom) + 1) * sizeof (datatype));\
v->size -= v->headroom; \
} \
\
} while (0)
#endif
And I usually wrap them like:
size_t vector_addi (struct vector * v, int index, int i){
vector_addm (v, index, int, i);
return v->len;
}
I haven't had this code-reviewed, but I've been using it in a large program I'm writing and I haven't had any memory errors from them (using valgrind).
The only thing that is really missing (I've been meaning to add) the ability to add and subtract arrays from arrays.
Edit: I believe you can also do this same sort of thing with stdarg.h, but I've never tried it.
You asked for a better approach? Here ist is: https://github.com/m-e-leypold/glitzersachen-demos/tree/master/generix/v0-2011 (Disclosure: This is my code).
Let me explain very shortly:
I wanted type safe generic containers (which in other languages would be provided by proper generics (Ada) or parametric polymorphism (OCaml). This is the the feature that is most missing in C.
Macros just cannot do it (I'm not
going to explain that in detail. Suffice to say: The result of a template expansion or
generic instantiation should be a module in it's own right: In C this means, there are pre
processor symbols exported respectively can be used for module configuration (like
-DUSE_PROCESS_QUEUE_DEBUGCODE) you couldn't do that if you used C macros to generate
instances.
I'm abstracting over element type by moving element size and all relevant operation into a descriptive structure. This will be passed to every invocation of the generic code. Note that the descriptor describes the element type, so a descriptor instance will be needed once per generic instance.
I'm using a template processor to create a thin type safe frontend module to the generic code.
Example:
This is the prototype for the generic code to retrieve an element:
void fifo_get ( fifo_DESCRIPTOR* inst, fifo* , void* var );
This is the descriptor type:
typedef struct fifo_DESCRIPTOR {
size_t maxindex;
size_t element_size;
} fifo_DESCRIPTOR;
This is the template code in the type safe wrapper template:
<<eT>> <<>>get ( <<T>>* f ) {
<<eT>> e; fifo_get( &DESCRIPTOR, (fifo*) f, (void*) &e ); return e;
}
And this is what the template expander (instantiating an generic) produces from the template:
float floatq_get ( floatq* f ) {
float e; fifo_get( &DESCRIPTOR, (fifo*) f, (void*) &e ); return e;
}
All this has a nice make integration, but hardly any type safety in instantiation. Every error only crops up when compiling with cc.
I cannot justify at the moment, why to stick with source text templates in C instead of migrating to C++. For me, it was just an experiment.
Regards.
This approach will probably horrify you, but it can be made to work if you don't need any type-specialized logic:
// vector.h
#ifndef VECTOR_H
#define VECTOR_H
#define VECTOR_IMP(itemType) \
typedef struct { \
itemType * array; \
int length; \
int capacity; \
} itemType##_Vector; \
\
static inline void itemType##_vector_add(itemType##_Vector* v, itemType v) { \
// implementation of adding an itemType object to the array goes here \
} \
\
[... other static-inline generic vector methods would go here ...] \
// Now we can "instantiate" versions of the Vector struct and methods for
// whatever types we want to use.
VECTOR_IMP(int);
VECTOR_IMP(float);
VECTOR_IMP(char);
#endif
... and some example calling code:
#include "vector.h"
int main(int argc, char ** argv)
{
float_Vector fv = {0};
int_Vector iv = {0};
char_Vector cv = {0};
int_vector_add(&iv, 5);
float_vector_add(&fv, 3.14f);
char_vector_add(&cv, 'A');
return 0;
}
Instead of having the vector class store the added object, you could just return a pointer to the location where the caller can store it:
typdef struct {
char *buffer;
size_t length;
size_t capacity;
size_t type_size;
} Vector;
void *vector_add(Vector* v)
{
if (v->length == v->capacity) {
// ... increase capacity by at least one
// ... realloc buffer to capacity * type_size
}
return v->buffer + v->type_size * v->length++;
}
// in main:
*(int*)vector_add(v) = 4;
Using some non-standard GNU C extensions, it is possible to define generic functions with inferred parameter types. This macro defines a nested function in a statement expression and infers the parameter type using typeof:
#include <stdio.h>
#define fib(n1) ({\
typeof(n1) func(typeof(n1) n){\
if (n <= 1)\
return n;\
return func(n-1) + func(n-2);\
}\
func(n1);\
})
int main()
{
printf("%d\n",fib(3));
printf("%f\n",fib(3.0));
return 0;
}