ginting@fred.cs.washington.edu (Eka Namara Ginting) (08/23/90)
I'm creating a library that I put in a folder in THINK C's folder. The code in the library opens two files; both of them in the same folder as the library, and it needs resources from a resource file also in the same directory. The library refers to the files by their names only (not full path - I want it to be independent of the volume.) If I create a project in an arbitrary folder, and import the library, I get an error because it can't find the two files (which are located in the library's folder.) If I move the files and the resource file to the folder where the project is, everything works fine. Can anyone give me a pointer as to how I can get this to work ? I need to have the files in a different folder from the project's folder without having the library referring to the files using full path names. Helllpppp !!! Thanks for your attention..... -- Eka Ginting ginting@fred.cs.washington.edu
mdtaylor@Apple.COM (Mark Taylor) (08/23/90)
In article <12866@june.cs.washington.edu> ginting@fred.cs.washington.edu (Eka Namara Ginting) writes: >I need to have the files in a different folder from the project's folder >without having the library referring to the files using full path names. The location of the library matters only to the project. Once your application is running, there's no way it "knows" where any of its source files, including libraries, may have resided on your disk. Or even where the THINK C Folder is, for that matter. I don't know what these files of yours are like, but if you can't turn their contents into resources, and you don't want them in the same folder as the application, maybe you could put them into the System Folder, perhaps in a Preferences folder? - Mark
tim@maths.tcd.ie (Timothy Murphy) (09/04/90)
On a related topic, what is the convention for naming paths in THINK C?
I find I can open a 'cousin' file as "::pa_dir:cousin_dir:file"
but if I want to give the full path,
must I know the name of the (hard) disk?
Another question: is there any way of #defining outside the program --
as eg from the command line in Unix or MS-DOS
cc -Dxyz prog.c
While I've got your attention,
is the 32k data limit due to Mac internals,
or to THINK C?
Last question (for the moment):
I find malloc()...free()
doesn't actually free the space the *first* time it is called,
but does on subsequent occasions.
Has anyone else noticed this?
Eg
#include <stdio.h>
#include <stdlib.h>
main()
{
int i;
char *cp;
for (i=0; i<100; i++) {
cp = malloc(1000);
printf("cp = %p\n", cp);
free(cp);
}
}
Timothy Murphy <tim@maths.tcd.ie>
--
Timothy Murphy
e-mail: tim@maths.tcd.iedak@sq.sq.com (David A Keldsen) (09/05/90)
tim@maths.tcd.ie (Timothy Murphy) writes: [deleted question that I'm not answering] >Another question: is there any way of #defining outside the program -- >as eg from the command line in Unix or MS-DOS >cc -Dxyz prog.c No. Put such defines in one file, #include as needed. >While I've got your attention, >is the 32k data limit due to Mac internals, >or to THINK C? Both. Turns out that it is a "reasonable choice" to implement access to this data by a register that is a 16 bit signed quantity, and this is the choice that the developers of Think-C made. It's pretty common. >Last question (for the moment): >I find malloc()...free() >doesn't actually free the space the *first* time it is called, >but does on subsequent occasions. >Has anyone else noticed this? >Eg >#include <stdio.h> >#include <stdlib.h> >main() >{ > int i; > char *cp; > for (i=0; i<100; i++) { > cp = malloc(1000); > printf("cp = %p\n", cp); > free(cp); > } >} malloc() doesn't take an integer, it takes a size_t as its argument. Look it up in the manual. So your first malloc() is reading the 1000 on the stack, and some other number for the high half of the size_t... you aren't actually getting 1000 malloc units. You see a lot of this when porting stuff to Think-C from various Unix environments. A more typical example is surprising "out of memory" errors, when you are just *sure* that you've got plenty. -- // David A. 'Dak' Keldsen: dak@sq.com or utai!sq!dak // "Well, I had resolved to be less offended by human nature, but I think // I blew it already." -- Calvin and Hobbes