| TIP: Click on subject to list as thread! | ANSI |
| echo: | |
|---|---|
| to: | |
| from: | |
| date: | |
| subject: | Programming Language |
PF> What you should be doing is compiling your Cset (1.0 or 3.0) code
PF> into a DLL, and using the IBM dll from your Watcom program; thus
PF> both runtimes will be used (and Obviosly, you should make sure the
PF> two never meet -- ie: don't try free'ing a malloc'ed pointer accross
PF> runtimes).
DD> But DosFreeMem'ing a DosAllocMem'd pointer, I assume, would be safe?
Yes, but there are two problems with this:
1) It is just bad. If you have code different enough to put into a
dll -- why then do you go and start free'ing/closing stuff across
dll's? This just strikes me as a bad programming practice -- heck,
I hardly even do this across *.obj's; and it is totally abhorrent
to the C++ programmer, where, luckily, destructors prevent this
type of thing (if you use them!).
I would _always_ have some sort of de-alloc/close function exported
from the dll, even if all the code did was call free. For
example:
MYSTUFF *CreateAThing(...) // exported DLL function
{
MYSTUFF *ret = malloc(sizeof(MYSTUFF));
...
return ret;
}
void FreeAThing(MYSTUFF *p) // exported DLL function
{
free(p);
}
Not only have I totally isolated the C runtime from another copy of
the runtime, I have isolated the compiler from another vendor (any
C[++] compiler can now use my exported C functions), but I have
isolated it from other languages; there is no reason why a pascal
or smalltalk program couldn't use the two functions above.
2) It's not just malloc/free we are talking about. fopen(), for
example, probably calls malloc() [or something similar] under the
covers to allocate storage for the 'FILE *' it returns. fclose(),
similarly, will call free(). There is no way to get in there to
call DosFreeMem().
In fact, you should not let another dll (that has it's own runtime)
touch a 'FILE *' at all (for fread, fprintf, anything).
--- Maximus/2 3.00
* Origin: Sol 3 * Toronto * V.32 * (905)858-8488 (1:259/414)SEEN-BY: 270/101 620/243 711/401 409 410 413 430 807 808 809 934 955 712/407 SEEN-BY: 712/515 628 704 713/888 800/1 7877/2809 @PATH: 259/414 400 99 229/2 3615/50 396/1 270/101 712/515 711/808 809 934 |
|
| SOURCE: echomail via fidonet.ozzmosis.com | |
Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.