Help please: Want to write this piece of code without using malloc

Nenita · 11-09-2014, 01:03 AM

Hi everyone, I'm writing a code but I would like to write a section of it without having to use malloc. Is there any other way to achieve this?

Code:

double **Ez, **Hx, **Hy, **sigmaz, **epsirz, **amux;
    Ez  =  (double**)malloc(sizeof(double*) * ndiv);
    Hx  =  (double**)malloc(sizeof(double*) * ndiv);
    Hy  =  (double**)malloc(sizeof(double*) * ndiv);
    sigmaz  =  (double**)malloc(sizeof(double*) * ndiv);
    epsirz  =  (double**)malloc(sizeof(double*) * ndiv);
    amux  =  (double**)malloc(sizeof(double*) * ndiv);
    
    for(i = 0; i<ndiv; i++){
      Ez[i]  =  (double*)malloc(sizeof(double)*ndiv);
      Hx[i]  =  (double*)malloc(sizeof(double)*ndiv);
      Hy[i]  =  (double*)malloc(sizeof(double)*ndiv);
      sigmaz[i]  =  (double*)malloc(sizeof(double)*ndiv);
      epsirz[i]  =  (double*)malloc(sizeof(double)*ndiv);
      amux[i]  =  (double*)malloc(sizeof(double)*ndiv);
    }

pan64 · 11-09-2014, 05:03 AM

is this your homework? ndiv is a constant, or where is it coming from?

johnsfine · 11-09-2014, 07:01 AM

What dialect of C or C++ are you using?

What is the lifetime of those allocations? For example, are they deleted before the end of the function in which they are created?

C99 allows you to declare local arrays (which are allocated on the stack) with sizes that are not know until run time (vs. ANSI C, which requires sizes of such arrays to be known at compile time).

Nenita · 11-09-2014, 08:47 AM

Quote:

Originally Posted by pan64

is this your homework? ndiv is a constant, or where is it coming from?

Yes, it is. I've actually written the whole code already but I wanted to know if this particular part of the code could be written without using malloc. Yes ndiv is a constant.

a4z · 11-09-2014, 08:52 AM

if niv is a constant than you know the size of you arrays and you can define it at compile time
double a[const][const];

Nenita · 11-09-2014, 08:54 AM

Quote:

Originally Posted by johnsfine

What dialect of C or C++ are you using?

What is the lifetime of those allocations? For example, are they deleted before the end of the function in which they are created?

C99 allows you to declare local arrays (which are allocated on the stack) with sizes that are not know until run time (vs. ANSI C, which requires sizes of such arrays to be known at compile time).

I'm using GNU. The lifetime of the allocations are deleted after the end of the function.

suicidaleggroll · 11-09-2014, 08:55 AM

Depending on where and how ndiv is defined, you might be able to do something as simple as:

Code:

double Ez[ndiv][ndiv]

and so on.

Be aware that sticking large amounts of data on the stack can lead to some nasty problems though.

Nenita · 11-09-2014, 08:57 AM

What I'm did was write a code simulating Electromagnetic Wave Propagation using 2D FDTD.

NevemTeve · 11-09-2014, 10:49 AM

It's not clear why you want to avoid malloc. Nonetheless, you can still use calloc or realloc.

smallpond · 11-09-2014, 10:54 AM

To avoid putting a large amount of data on the stack, you can also declare it as global which puts it uninitialized data space (BSS).

bigearsbilly · 11-09-2014, 01:16 PM

you seem to be making life very difficult for yourself.
maybe something like :

Code:

// define a struct to contain related variables:

struct thing {
  double Ez, Hx, Hy, sigmaz, epsirz, amux;
};

// now you make a single array to keep track of

struct thing array[ndiv];

// and use like so:

array[t].sigmaz = 0.0;
array[t].Hx = 3.14;

// etc

rtmistler · 11-14-2014, 12:24 PM

To add to the statements recommending pre-declaring your arrays; this is in my world a common practice, where we'll do a device supporting a certain amount of sessions or something similar and we initialize the system by either allocating all during initialization, or we declare fixed arrays as part of the code and yes we do place them in something like BSS.

The primary reason for doing this is since the product is supposed to support some maximum number of sessions, we do not take the chance that during peak operation, we could encounter an allocation failure. And you're kidding yourself if that's not the first thing QA does with your release.

Further, we also add headers to pre-allocated or statically mapped data so as to check the validity and integrity of the data. Sometimes simple things like start and end special markers or magic numbers. We may also place the address of the memory buffer somewhere within the buffer as a further verification step.

We re-use those buffers by way of shipping them from process to process. When the system breaks, and unfortunately it does, we have diagnostic utilities to validate the integrity of those buffers. If something breaks by accessing an out of range address, we can mostly tell what happened, because obviously a process shouldn't have an address of a buffer where that address is beyond the table's boundaries. Tracing back to the culprit who corrupted the address ... well that's always fun

I think I've only ever seen a bunch of nested allocations like that in academic exercises. My world has largely been routers, gateways, and such. Therefore they are designed to support what they advertise, hence our allocate or map in advance strategy. Thinking back, I did what you did and the first mentor I had was like "No, no, no, no, no ... c'mere kid, let's redo this here code ..." At least they were nice about it.

bigearsbilly · 11-14-2014, 01:46 PM

Quote:

Originally Posted by rtmistler

We may also place the address of the memory buffer somewhere within the buffer as a further verification step.

[hijack]
hmm interesting idea.
I might steal that one.