memory allocation / "dynamic arrays" / portability 
Author Message
 memory allocation / "dynamic arrays" / portability

Hi all, Im new here and have several questions about the mentioned
topics.

Ive already "written" a couple of small WIN32 C Programs, where I
didnt have to care much about the mentioned in the topic.

So im not completly new to C but now have problems do get a clear
picture about the following:

Many years ago I wrote a library in QuickBasic to develop CAM/CNC-
applications in an DOS-Enviroment. That worked quite well.
I had even an PM(!)OS/2 port, using the MS OS2 Basic compiler.
It got bigger and bigger over the time, and albeit I pretended to
myself to port it to C "soon", that never happened in the end.

Now after some ten years stayin away from that (some programs still
in use by customers anyway) I somehow again found myself in the
situation to port this to C, partly for use in WIN32, partly just
to make it OS-independent in the end.
(it includes even a spripting language and all that ...)

In QB you can build structures nearly the same way as in C.
Then, if you want to use them in dynamic arrays you have just to
write - DIM name_of_array(number of elements) as name_of_structure

if you preceed that which COMMOM SHARED it will be accessible from
anywhere/module in your program.

with a further DYNAMIC statement you can make the size of arrays
variable at run time.

One has just to REDIM name_of_array(new number of elements) to
change the size.

Now my questions.

How can I get a somehow similar behaviour, using C in general?
(but practically first for WIN32, later UNIXes) ?

And next, can please get me someone an idea how one should imagine,
where (pincipially/structural) and depending on what, variables and
arrays are stored, and how it may differ depending on host systems,
using C.

tia

Andreas



Sun, 31 Jul 2005 19:27:13 GMT  
 memory allocation / "dynamic arrays" / portability

Quote:
> In QB you can build structures nearly the same way as in C.
> Then, if you want to use them in dynamic arrays you have just to
> write - DIM name_of_array(number of elements) as name_of_structure
> if you preceed that which COMMOM SHARED it will be accessible from
> anywhere/module in your program.
> with a further DYNAMIC statement you can make the size of arrays
> variable at run time.
> One has just to REDIM name_of_array(new number of elements) to
> change the size.
> Now my questions.
> How can I get a somehow similar behaviour, using C in general?
> (but practically first for WIN32, later UNIXes) ?

malloc() and free() are your friends.

Quote:
> And next, can please get me someone an idea how one should imagine,
> where (pincipially/structural) and depending on what, variables and
> arrays are stored, and how it may differ depending on host systems,
> using C.

C does not define anything about where variables and arrays are
stored. That is up to the implementation to decide.

--

| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste       W++ B OP+                     |
\----------------------------------------- Finland rules! ------------/
"Remember: There are only three kinds of people - those who can count and those
who can't."
   - Vampyra



Sun, 31 Jul 2005 19:32:59 GMT  
 memory allocation / "dynamic arrays" / portability

Quote:

> Hi all, Im new here and have several questions about the mentioned
> topics.

> Ive already "written" a couple of small WIN32 C Programs, where I didnt
> have to care much about the mentioned in the topic.

> So im not completly new to C but now have problems do get a clear
> picture about the following:

> Many years ago I wrote a library in QuickBasic to develop CAM/CNC-
> applications in an DOS-Enviroment. That worked quite well. I had even an
> PM(!)OS/2 port, using the MS OS2 Basic compiler. It got bigger and
> bigger over the time, and albeit I pretended to myself to port it to C
> "soon", that never happened in the end.

> Now after some ten years stayin away from that (some programs still in
> use by customers anyway) I somehow again found myself in the situation
> to port this to C, partly for use in WIN32, partly just to make it
> OS-independent in the end. (it includes even a spripting language and
> all that ...)

> In QB you can build structures nearly the same way as in C. Then, if you
> want to use them in dynamic arrays you have just to write - DIM
> name_of_array(number of elements) as name_of_structure

> if you preceed that which COMMOM SHARED it will be accessible from
> anywhere/module in your program.

> with a further DYNAMIC statement you can make the size of arrays
> variable at run time.

> One has just to REDIM name_of_array(new number of elements) to change
> the size.

> Now my questions.

> How can I get a somehow similar behaviour, using C in general? (but
> practically first for WIN32, later UNIXes) ?

Oh, something like this:

#include <stdlib.h>
#include <assert.h>

struct x {
        int a, b;

Quote:
};

struct x *array = NULL;

void sizearray(size_t elements){
        struct x *newptr;
        if(!array)
                newptr = malloc(sizeof *newptr * elements);
        else
                newptr = realloc(array, sizeof *newptr * elements);
        assert(array = newptr);

Quote:
}
}

Run sizearray(number of elements) before using the array, and each time
you need to resize it. free(array) when done with it.

Quote:
> And next, can please get me someone an idea how one should imagine,
> where (pincipially/structural) and depending on what, variables and
> arrays are stored, and how it may differ depending on host systems,
> using C.

The layout in memory of structures is undefined, except that there is no
padding between the beginning of the struct and its first element.

--
Freenet distribution (temporary): http://24.25.175.161:8891/wbQUz9JhjVM/
I stopped believing in Santa Claus when I was six.  Mother took me to
see him in a department store and he asked for my autograph.
                -- Shirley Temple



Mon, 01 Aug 2005 08:55:20 GMT  
 memory allocation / "dynamic arrays" / portability
Thanks for your useful reply bd, together with some information from
another source, I now have a quite good view on that.

thanks again

Andreas



Mon, 01 Aug 2005 19:06:49 GMT  
 memory allocation / "dynamic arrays" / portability

...

Quote:
> struct x *array = NULL;

> void sizearray(size_t elements){
> struct x *newptr;
> if(!array)
> newptr = malloc(sizeof *newptr * elements);
> else
> newptr = realloc(array, sizeof *newptr * elements);

This if/else is a waste of effort.
realloc(x,n) where x is null does malloc anyway.

Quote:
> assert(array = newptr);

In addition to being obfuscated, this is technically wrong in C89
where assert() is defined only for an int argument.  (In C99, as in
(al(?) implementations, it is defined for any scalar type.)  Both
issues are solved by explicitly writing the != NULL or similar.

It is also debatable whether an assert() and hence abort()
is the right way to handle an allocation failure, but that can
depend on a lot of other factors not relevant here.

...

Quote:
> > And next, can please get me someone an idea how one should imagine,
> > where (pincipially/structural) and depending on what, variables and
> > arrays are stored, and how it may differ depending on host systems,
> > using C.

> The layout in memory of structures is undefined, except that there is no
> padding between the beginning of the struct and its first element.

And members within a struct must be in order:  the addresses can
be compared relationally (e.g. <) and give the right results.
(For C++ this is guaranteed only if not separated by access specifiers.)
And elements of an array must be consecutive:  pointers to them
can be compared relationally, and computed (and in fact subscripting
works *by* computing a pointer, see section 6 of the FAQ).

Whereas the placement of separate variables is not defined at all,
except for a TR (still?) under development and not applicable to
normal 'user' systems, and pointers to them can safely, much
less portably, be compared only for equality or inequality.

There are however three 'durations' of variables, associated with
and often referred to as 'storage classes':
* static variables are those defined at file scope (outside any
function), or within a block with the 'static' or 'extern' keyword;
they must exist and retain their values as long as the program
is running; in practice they are allocated by the linker and the
OS (program loader or similar).
* automatic variables are those declared within a block (function)
with no keyword or 'auto' or 'register'; they are required to exist
only until the function returns/exits and to be separate for each
recursive invocation of the function; in practice they are usually
allocated (as one 'frame' per function invocation) on a stack.
Function parameters, although not formally automatic variables,
are functionally <G> equivalent in that they exist per and during
a function invocation.
* dynamic objects are allocated with malloc(), calloc() or
realloc() and exist until explicitly free()d (or successfully
realloc()ed, as in the example above); they are usually
obtained from 'heap' space which itself is either statically
allocated (by the OS/loader) or by underlying OS calls.
Variables cannot be directly defined as dynamic, but
pointers to dynamic objects can and often should be
ordinary (static or automatic) variables.

--
- David.Thompson 1 now at worldnet.att.net



Sat, 06 Aug 2005 03:23:04 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. "Dynamic Allocation of 2-D Arrays"

2. "C Pointers and Dynamic Memory Management"

3. "dynamic" arrays in C

4. Error "free"-ing "malloc"-ed memory

5. Multi-dimensional array using dynamic memory allocation

6. Dynamic Array of pointer memory allocation

7. Dynamic Memory Allocation For Multi-Dimensional Arrays

8. dynamic memory allocation with arrays in C

9. Unsized array and dynamic memory allocation

10. Multi-dimensional array using dynamic memory allocation

11. Problems in Dynamic 2D array memory allocation

12. Dynamic memory allocation of two dimensional arrays

 

 
Powered by phpBB® Forum Software