Dlls,memory allocation

[Sundar]

Hi,

i am trying to make an application that will require registering of
quite a few dlls and execute. Now one of the first bottlenecks that my
mentor refused is allocation of memory or the usage of mallocs in the
dlls. He tells me that for an application to run perfectly , there must
be no dynamic memory in the libraries.. I am not quite impressed..

Can anyone clear out this mess please?

[Ian Collins]

Re: Dlls,memory allocation

Sundar wrote:

Hi,
>
i am trying to make an application that will require registering of
quite a few dlls and execute. Now one of the first bottlenecks that my
mentor refused is allocation of memory or the usage of mallocs in the
dlls. He tells me that for an application to run perfectly , there must
be no dynamic memory in the libraries.. I am not quite impressed..
>
Can anyone clear out this mess please?
>

Better asked on a windows group.

--
Ian Collins.

[santosh]

Re: Dlls,memory allocation

Sundar wrote:

Hi,
>
i am trying to make an application that will require registering of
quite a few dlls and execute. Now one of the first bottlenecks that my
mentor refused is allocation of memory or the usage of mallocs in the
dlls. He tells me that for an application to run perfectly , there must
be no dynamic memory in the libraries.. I am not quite impressed..
>
Can anyone clear out this mess please?

Ask in a Windows group or ask your mentor again.

[Bill Pursell]

Re: Dlls,memory allocation

Sundar wrote:

i am trying to make an application that will require registering of
quite a few dlls and execute. Now one of the first bottlenecks that my
mentor refused is allocation of memory or the usage of mallocs in the
dlls. He tells me that for an application to run perfectly , there must
be no dynamic memory in the libraries.. I am not quite impressed..
>
Can anyone clear out this mess please?

I'm not sure what the mess is. It makes writing the
library a lot simpler--any function that would have needed
to allocate memory instead takes an argument giving
the location of the needed memory, and you force
the caller to do more work by declaring that the
caller must provide sufficient memory. It's a bit
of a cop out on the part of the library builder, really.
Sometimes there is no way for the calling function
to know how much memory is needed, in which
case your library should provide a method for
the caller to discover the necessary space. eg:

T *f;
size_t size_of_f;

size_of_f = mylib_size_of(a ,b,c,d,e);
f = Malloc(size_of_ f * sizeof *f);
mylib_do(a,b,c, d,e,f);

Although there's really nothing wrong with:
f = mylib_do1(a,b,c ,d,e);
if (f == NULL)
handle_error();

--
Bill Pursell

[jacob navia]

Re: Dlls,memory allocation

Sundar wrote:

Hi,
>
i am trying to make an application that will require registering of
quite a few dlls and execute. Now one of the first bottlenecks that my
mentor refused is allocation of memory or the usage of mallocs in the
dlls. He tells me that for an application to run perfectly , there must
be no dynamic memory in the libraries.. I am not quite impressed..
>
Can anyone clear out this mess please?
>

This is a good idea not only for dlls but for
normal libraries too.

If you allocate memory in the library, it could be that the user thinks
he can free it. That would be catastrophic if your library was compiled
with another compiler and has another runtime free/malloc system than
what the user of the library is using.

You can only allocate memory if you also provide a means for freeing
the memory in your library. In that case, the allocation /freeing will
work. Whether it is a good practice it is another thing.

A cleaner interface is when the user makes all allocations/freeing
and your library uses the memory it is provided to work with: you
receive pointers to buffers, etc.

[CBFalconer]

Re: Dlls,memory allocation

Sundar wrote:

>
i am trying to make an application that will require registering of
quite a few dlls and execute. Now one of the first bottlenecks that my
mentor refused is allocation of memory or the usage of mallocs in the
dlls. He tells me that for an application to run perfectly , there must
be no dynamic memory in the libraries.. I am not quite impressed..

Nor am I. Your 'mentor' sounds very inexperienced.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net>

[Jens Thoms Toerring]

Re: Dlls,memory allocation

jacob navia <jacob@jacob.re mcomp.frwrote:

Sundar wrote:

i am trying to make an application that will require registering of
quite a few dlls and execute. Now one of the first bottlenecks that my
mentor refused is allocation of memory or the usage of mallocs in the
dlls. He tells me that for an application to run perfectly , there must
be no dynamic memory in the libraries.. I am not quite impressed..

This is a good idea not only for dlls but for
normal libraries too.
>
If you allocate memory in the library, it could be that the user thinks
he can free it. That would be catastrophic if your library was compiled
with another compiler and has another runtime free/malloc system than
what the user of the library is using.

What got the compiler to do with it? If I am not completely mistaken,
malloc() and friends are from the C standard library. And if a library
would require a different standard C library from the one the program
linking against the library needs I guess problems about malloc() etc.
would probably be only just one of your headaches.

You can only allocate memory if you also provide a means for freeing
the memory in your library. In that case, the allocation /freeing will
work. Whether it is a good practice it is another thing.

So a non-standard, but often found function like strdup() would also
be unacceptable since there's no "unstrdup" function and you need to
free() the memory for the copy you got? And is there a difference if
I write my own version of strdup() and don't put it into a library or
put it in the library? Would the first way be a "good idea" but the
second a bad one?

A cleaner interface is when the user makes all allocations/freeing
and your library uses the memory it is provided to work with: you
receive pointers to buffers, etc.

Quite often not feasible when only the library can determine how
much memory it's going to need. And if you would have a separate
function for figuring out how much memory is going to be needed
there can be a lot of cases where the information you got that way
can already be outdated once you have allocated memory and finally
call the library function that then is supposed to use the memory.
And as a simpler example: how useful would e.g. again strdup() be
if you would have to do call strlen() first, then allocate enough
memory for the copy and only then do the copy? Actually, you then
would already have written yourself all that strdup() does for you.

I would think that the user should *read* the documentation for the
library (s)he is using, taking special care of which memory one gets
from calls of library functions can or must be free'ed, if it will
be re-used on another invocation of the function etc. Not allocating
memory in libraries just because some users can gat it wrong sounds
to me like outlawing chain saws because some people will hurt them-
selfs trying to use them because the skipped reading the safety in-
structions (or just using their brains).

Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\______________ ____________ http://toerring.de

[Tom St Denis]

Re: Dlls,memory allocation

Jens Thoms Toerring wrote:

If you allocate memory in the library, it could be that the user thinks
he can free it. That would be catastrophic if your library was compiled
with another compiler and has another runtime free/malloc system than
what the user of the library is using.

>
What got the compiler to do with it? If I am not completely mistaken,
malloc() and friends are from the C standard library. And if a library
would require a different standard C library from the one the program
linking against the library needs I guess problems about malloc() etc.
would probably be only just one of your headaches.

Not to go completely off topic ... but in Windows there are two C
libraries, VCRT and I forgot the other but someone could do "cl /?" and
find it. It gets worse when you write a dll with VC6 [say] and then
link it to an app with VC8.

Although the processes share the process space (or they're partially
mapped into one another), the malloc/free implementations are not
shared and trying to free something malloc'ed by the other will usually
cause a segfault.

The simple way to solve this is to provide a free function for whatever
objects/structs/whatever your dll allocates.

This isn't required in UNIX, BSD or Linux as the shared objects share
heap information.

Tom

[Jens Thoms Toerring]

OT: Re: Dlls,memory allocation

Tom St Denis <tomstdenis@gma il.comwrote:

Jens Thoms Toerring wrote:

If you allocate memory in the library, it could be that the user thinks
he can free it. That would be catastrophic if your library was compiled
with another compiler and has another runtime free/malloc system than
what the user of the library is using.

What got the compiler to do with it? If I am not completely mistaken,
malloc() and friends are from the C standard library. And if a library
would require a different standard C library from the one the program
linking against the library needs I guess problems about malloc() etc.
would probably be only just one of your headaches.

Not to go completely off topic ... but in Windows there are two C
libraries, VCRT and I forgot the other but someone could do "cl /?" and
find it. It gets worse when you write a dll with VC6 [say] and then
link it to an app with VC8.

Although the processes share the process space (or they're partially
mapped into one another), the malloc/free implementations are not
shared and trying to free something malloc'ed by the other will usually
cause a segfault.

I knew that C gives you enough rope to hang yourself. But there seem
to be environments where they tie it for you into a noose, fasten it
to the ceiling and put a wobbly, three-legged chair under it;-)

Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\______________ ____________ http://toerring.de

[Tom St Denis]

Re: OT: Re: Dlls,memory allocation

Jens Thoms Toerring wrote:

I knew that C gives you enough rope to hang yourself. But there seem
to be environments where they tie it for you into a noose, fasten it
to the ceiling and put a wobbly, three-legged chair under it;-)

You think that's odd, why not check out their statement on C99
compliance :-)

[oh wait, they don't have one, nor a plan to make it there...]

For the most part if you stay away from the file system, sockets,
shared memory, semaphores, mutexes, pipes, and forking, Windows is just
like any other UNIX OS w.r.t. the standard C libraries. :-)

I, for one, just avoid Windows as a developer platform and laugh at
anyone who is caught trying to synergize their core coporate values by
diverging into vertical markets aligned with the strategic outlines of
Microsoft.

:-)

Tom