Malloc 2: The revenge of Malloc
Author |
Message |
Jeremy A.Smit #1 / 25
|
Malloc 2: The revenge of Malloc
Hi... I have a question about malloc::: I know how to allocate a single array: x=(type *)malloc(size*sizeof(type)); Where x is type 'type' and size 'size'. Now, this is fine for INTs, but I want to do the same with a multidimensional char array, like this: char[number of string][size of each string]; So I can put a word in the array like this. Array [0]='Hello there'=11 chars Array++; Array [1]='Blah'=4 chars This is because I'm reading words from a file. Actually, I'm writing a program which will read in about 10,000 HTML files and create a huge word index for them, for a CD-ROM full of HTML stuff (for my own use). This will make it easy to search 600mb over 30,000 files in a few seconds. However, I need to get the words into the computer's memory so my program can compare them (to get rid of redundancy - why index 'the' for the same file 500 times when once will suffice?) Thanks, Jeremy. -- Replace 'X' in e-mail with 'J' if you wish to e-mail me
|
Thu, 19 Apr 2001 03:00:00 GMT |
|
|
Singra #2 / 25
|
Malloc 2: The revenge of Malloc
See the FAQ for the group (section 6.16): ftp://rtfm.mit.edu/pub/faqs/C-faq/faq It has some very good examples.
:Hi... :I have a question about malloc::: :I know how to allocate a single array: :x=(type *)malloc(size*sizeof(type)); :Where x is type 'type' and size 'size'. Now, this is fine for INTs, but I :want to do the same with a multidimensional char array, like this: :char[number of string][size of each string]; :So I can put a word in the array like this. :Array [0]='Hello there'=11 chars :Array++; :Array [1]='Blah'=4 chars :This is because I'm reading words from a file. Actually, I'm writing a :program which will read in about 10,000 HTML files and create a huge word :index for them, for a CD-ROM full of HTML stuff (for my own use). This will :make it easy to search 600mb over 30,000 files in a few seconds. However, I :need to get the words into the computer's memory so my program can compare :them (to get rid of redundancy - why index 'the' for the same file 500 :times when once will suffice?) :Thanks, :Jeremy. :-- :Replace 'X' in e-mail with 'J' if you wish to e-mail me
|
Thu, 19 Apr 2001 03:00:00 GMT |
|
|
Jeremy A.Smit #3 / 25
|
Malloc 2: The revenge of Malloc
Quote: > Hi... > I have a question about malloc:::
It's okay, I did it this way: Define: char *word[200]; Sets up an array of 200 words with indeterminate lengths, and: word[5]=(char *)malloc(strlen("Hi there how ya doing")*sizeof(char)); strcpy(word[5],"Hi there how ya doing"; Would, I think, make the 5th word in the array contain the text 'Hi there how ya doing' without crashing the machine. I think this is correct!! :-) I think this works because the char definition says "char *word", so because of the '*' being there, the "[200]" applies not to the number of characters in the char, but the number of words in the array (BTW, 'words' is referring to *real* words, "Hello" and "Blah"). BTW, I think this is a great newsgroup, except for all the people asking about the wrong flavours of C and causing a mess. I always write in ANSI C, because the learning curve vs simplicity vs code portability makes it perfect. Although I think they should have put directory cataloguing in ANSI C. I end up writing a batch file that pipes the directory to a file and them runs my program, which recurses through the files. ;-) Cheers, Jeremy. -- Replace 'X' in e-mail with 'J' if you wish to e-mail me
|
Thu, 19 Apr 2001 03:00:00 GMT |
|
|
Robert Franci #4 / 25
|
Malloc 2: The revenge of Malloc
Instead of thinking of a two dimensional array, think of an array of pointers where each member in the array points to a string. You can allocate memory for the basic array using malloc where the size of the block is the number of pointers you want times the size of a pointer to char. Now, as you read a string from your file (into some char array that you have allocated), you can use malloc to allocate memory based on the lenght of the string + 1, store the pointer to this memory in your array and then copy the string into this memory. Quote:
> Hi... > I have a question about malloc::: > I know how to allocate a single array: > x=(type *)malloc(size*sizeof(type)); > Where x is type 'type' and size 'size'. Now, this is fine for INTs, but I > want to do the same with a multidimensional char array, like this: > char[number of string][size of each string]; > So I can put a word in the array like this. > Array [0]='Hello there'=11 chars > Array++; > Array [1]='Blah'=4 chars > This is because I'm reading words from a file. Actually, I'm writing a > program which will read in about 10,000 HTML files and create a huge word > index for them, for a CD-ROM full of HTML stuff (for my own use). This will > make it easy to search 600mb over 30,000 files in a few seconds. However, I > need to get the words into the computer's memory so my program can compare > them (to get rid of redundancy - why index 'the' for the same file 500 > times when once will suffice?) > Thanks, > Jeremy. > -- > Replace 'X' in e-mail with 'J' if you wish to e-mail me
|
Thu, 19 Apr 2001 03:00:00 GMT |
|
|
Mathew Hend #5 / 25
|
Malloc 2: The revenge of Malloc
Quote:
>char *word[200]; >word[5]=(char *)malloc(strlen("Hi there how ya doing")*sizeof(char)); >strcpy(word[5],"Hi there how ya doing"; >Would, I think, make the 5th word in the array contain the text 'Hi there >how ya doing' without crashing the machine. >I think this is correct!! :-)
No. The block of memory you have allocated is not large enough: you need to allocate an extra byte for the string terminator. You also shouldn't cast the return value of malloc; that can hide bugs. And you don't need to multiply by the size of the string by sizeof(char), as by definition that is equal to 1. So, word[ 5 ] = malloc( strlen( "Hi there how ya doing" ) + 1 ); strcpy( word[ 5 ], "Hi there how ya doing" ); But I'd write this as, const char *mystring = "Hi there how ya doing"; word[ 5 ] = malloc( strlen( mystring ) + 1 ); strcpy( word[ 5 ], mystring ); so that if I needed to change the string placed in word[ 5 ], I'd only need to change it in one place. Quote: >I think this works because the char definition says "char *word", so >because of the '*' being there, the "[200]" applies not to the number of >characters in the char, but the number of words in the array (BTW, 'words' >is referring to *real* words, "Hello" and "Blah").
Yes. char *word[ 200 ] defines an an array of 200 pointers to characters (200 strings). Quote: >BTW, I think this is a great newsgroup, except for all the people asking >about the wrong flavours of C and causing a mess. I always write in ANSI C, >because the learning curve vs simplicity vs code portability makes it >perfect. Although I think they should have put directory cataloguing in >ANSI C
All decent C compilers/operating systems support the directory handling provided by POSIX.1. Not quite as portable as ANSI C, but pretty close. Use it if you can. -- Mat.
|
Fri, 20 Apr 2001 03:00:00 GMT |
|
|
Stephan Wilm #6 / 25
|
Malloc 2: The revenge of Malloc
Quote:
> All decent C compilers/operating systems support the directory > handling provided by POSIX.1.
A lot of compilers don't. And often they're the only ones you can get. Stephan (initiator of the campaign against grumpiness in c.l.c)
|
Fri, 20 Apr 2001 03:00:00 GMT |
|
|
Mathew Hend #7 / 25
|
Malloc 2: The revenge of Malloc
: > : > All decent C compilers/operating systems support the directory : > handling provided by POSIX.1. : : A lot of compilers don't. Do you mean that they don't ship with suitable libraries, or that such libraries simply aren't available? -- Mat.
|
Fri, 20 Apr 2001 03:00:00 GMT |
|
|
Sunil Ra #8 / 25
|
Malloc 2: The revenge of Malloc
Quote:
> > Hi... > > I have a question about malloc::: > It's okay, I did it this way: > Define: > char *word[200]; > Sets up an array of 200 words with indeterminate lengths, and: > word[5]=(char *)malloc(strlen("Hi there how ya doing")*sizeof(char)); > strcpy(word[5],"Hi there how ya doing"; > Would, I think, make the 5th word in the array contain the text 'Hi there > how ya doing' without crashing the machine. > I think this is correct!! :-)
ummm... no, it's not. Most significantly, you're not allocating enough space for your string. You've forgotten about the nul terminator at the end. There's the syntax error in the strcpy() statement - you've left out a closing paren. Also, sizeof (char) is ALWAYS one! That's right, 1. Also, you'd do wellif you lost the cast to (char *) at the end - it's generally considered to be bad style in these parts. -- { Sunil Rao } "And India acquired yet another willing convert to the philosophy of the meaningfully meaningless... Or was it the meaninglessly meaningful? Did anyone know what was happening?" -- Gita Mehta
|
Fri, 20 Apr 2001 03:00:00 GMT |
|
|
Dan P #9 / 25
|
Malloc 2: The revenge of Malloc
Quote:
>> All decent C compilers/operating systems support the directory >> handling provided by POSIX.1. ^^^^^^^ >A lot of compilers don't. And often they're the only ones you can get.
Not quite as portable as ANSI C, but pretty close. Use it if you can. ^^^^^^^^^^^^^^^^^^ which you deleted, in order to make your pointless point. Show me one (hosted) implementation that does not SUPPORT the directory handling functions defined by POSIX.1. Note the keyword "support" rather than "provide". As for the availability of these functions, the FAQ claims that: Implementations also exist for MS-DOS, VMS, and other systems. Dan -- Dan Pop CERN, IT Division
Mail: CERN - EP, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland
|
Fri, 20 Apr 2001 03:00:00 GMT |
|
|
Stephan Wilm #10 / 25
|
Malloc 2: The revenge of Malloc
Quote:
> : > > : > All decent C compilers/operating systems support the directory > : > handling provided by POSIX.1. > : > : A lot of compilers don't. > Do you mean that they don't ship with suitable libraries, or that such > libraries simply aren't available?
Both AFAIK. See my (meek) reply to Dans flame. Whoops, what I forgot to mention in my reply to Dan: by now I am convinced that "A lot" is very probably a slight exaggeration. Maybe "A few compilers don't" would have saved me :-) Stephan (initiator of the campaign against grumpiness in c.l.c)
|
Fri, 20 Apr 2001 03:00:00 GMT |
|
|
Stephan Wilm #11 / 25
|
Malloc 2: The revenge of Malloc
Quote:
> >> All decent C compilers/operating systems support the directory > >> handling provided by POSIX.1. ^^^^^^^ > >A lot of compilers don't. And often they're the only ones you can get.
> Not quite as portable as ANSI C, but pretty close. Use it if you can. > ^^^^^^^^^^^^^^^^^^ > which you deleted, in order to make your pointless point.
Actually I removed it, because it was besides my pointless point, which related to the text I did quote: "All decent C compilers/operating systems ...". Guess what ? I'm one of those guys who look up if their current (good) compiler is implicitely being called non-decent :-) Quote: > Show me one (hosted) implementation that does not SUPPORT the directory > handling functions defined by POSIX.1. Note the keyword "support" rather > than "provide".
As far as I can judge: "INMOS ANSI-C ToolSet 3rd Generation" (2nd as well and I don't know about 4th, because it's not compatible with the hardware we use). Another might be the Texas Instruments C compiler for the C40, but I am very unsure about this, because: I used it a few years ago and I am not sure if it was complete hosted implementation. My general experience is that hosted ANSI-C implementations for specific rare hardware lack the comfort of any but the minimum requirements. Quote: > As for the availability of these functions, the FAQ claims that: > Implementations also exist for MS-DOS, VMS, and other systems.
OK, but one closing remark about my pointless point: no I am not a C implementor and I might lack special knowledge of finer and finest destinctions. I just saw a statement that broadly declassified all C compilers without some special non ANSI-C extension as being "not decent". (As usual I cannot really refute your statement which is based on superior knowledge and experience. I just thought it's worth pointing out that my reply was not just some quick flame without at least some thought to it) Stephan (initiator of the campaign against grumpiness in c.l.c)
|
Fri, 20 Apr 2001 03:00:00 GMT |
|
|
Graeme Fenwic #12 / 25
|
Malloc 2: The revenge of Malloc
:I have a question about malloc::: : [snip] but I :want to do the same with a multidimensional char array, like this: :char[number of string][size of each string]; As far as I know, there is no way to malloc() a *genuine* multidimensional array. However, you can do something very similar by mallocing an array of pointers, each of which point to a malloced area of memory. Also, this way, you can allocate memory dynamically- which I'm guessing is what you wanted to do here? :- :So I can put a word in the array like this. : :Array [0]='Hello there'=11 chars :Array++; :Array [1]='Blah'=4 chars BTW, you don't need to cast the void pointer returned by malloc expilicitly. C allows you to assign (void *) to any other pointer type, on the basis that you know what you're doing.
(Remove "BYESPAM" spam filter when replying by mail)
|
Fri, 20 Apr 2001 03:00:00 GMT |
|
|
Dan P #13 / 25
|
Malloc 2: The revenge of Malloc
Quote:
>> >> All decent C compilers/operating systems support the directory >> >> handling provided by POSIX.1. ^^^^^^^ >> >A lot of compilers don't. And often they're the only ones you can get.
>> Not quite as portable as ANSI C, but pretty close. Use it if you can. >> ^^^^^^^^^^^^^^^^^^ >> which you deleted, in order to make your pointless point. >Actually I removed it, because it was besides my pointless point, which >related >to the text I did quote: "All decent C compilers/operating systems ...".
This is called "quoting out of context", a lame practice. Quote: >Guess what ? I'm one of those guys who look up if their current (good) >compiler is implicitely being called non-decent :-)
Nobody called your hosted compiler non-decent, unless it cannot support the opendir/readdir functions. What makes you think this is the case, indeed? Quote: >> Show me one (hosted) implementation that does not SUPPORT the directory >> handling functions defined by POSIX.1. Note the keyword "support" rather >> than "provide". >As far as I can judge: "INMOS ANSI-C ToolSet 3rd Generation" (2nd as >well >and I don't know about 4th, because it's not compatible with the >hardware >we use). Another might be the Texas Instruments C compiler for the C40, >but I am very unsure about this, because: I used it a few years ago and >I am not sure if it was complete hosted implementation.
Are you sure these are hosted implementations? Do they provide a complete and meaningful implementation of the standard C library and do executables produced by them run under an operating system? An operating system meaningfully supporting functions like fopen, remove and rename is very likely to provide a method of accessing the names of the files that already exist (even if this implies reading raw disk sectors or tape blocks). And this is all that is needed to implement the POSIX.1 directory handling functions. Even if the OS doesn't support the concept of directory tree, i.e. all the files are in one place, as it was the case in CP/M-80 and MSDOS 1. Quote: >My general experience is that hosted ANSI-C implementations for specific >rare hardware lack the comfort of any but the minimum requirements.
My general experience is that hosted ANSI-C implementations do provide an interface to the underlying operating system that is hosting the implementation. And this is usually enough to implement the functions we're talking about. Quote: >> As for the availability of these functions, the FAQ claims that: >> Implementations also exist for MS-DOS, VMS, and other systems. >OK, but one closing remark about my pointless point: no I am not a C >implementor and I might lack special knowledge of finer and finest >destinctions.
The distinction between "provide" and "support" is not that fine. Quote: >I just saw a statement that broadly declassified all C >compilers without some special non ANSI-C extension as being "not >decent".
This would have been the case if the original poster wrote "provide" instead of "support". But he didn't. Before replying to a post, try to understand what the poster actually wanted to say. It's neither the first nor the last occasion when you reacted after a very superficial reading of the text you're replying to. Quote: >knowledge and experience. I just thought it's worth pointing out that my >reply was not just some quick flame without at least some thought to it)
I am even more convinced, now, after reading this post, that it *was* a quick flame without some thought to it. Proof: by your own admission, you reacted to what you perceived as an insult to your compilers and not to the actual contents of the original post. I agree with the original poster: a C compiler which doesn't give you direct access to the services of the underlying operating system is not decent. I have never such seen such an implementation, and I've used ones for very spartan environments (e.g. ZX-Spectrum or CP/M-80). For freestanding environments, it doesn't make much sense talking about how to read a directory, so it is pointless to argue that you can't implement opendir() there. Dan -- Dan Pop CERN, IT Division
Mail: CERN - EP, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland
|
Sat, 21 Apr 2001 03:00:00 GMT |
|
|
Lawrence Kir #14 / 25
|
Malloc 2: The revenge of Malloc
Quote:
>:I have a question about malloc::: >: [snip] but I >:want to do the same with a multidimensional char array, like this: >:char[number of string][size of each string]; >As far as I know, there is no way to malloc() a *genuine* multidimensional >array.
C doesn't support multidimensional arrays at all so it is unclear what "a *genuine* multidimensional array" means in the context of C. What C does support is arrays of arrays (or arrays etc.) such as int array3[XDIM][YDIM][ZDIM]; You certainly can create a datastructure of this form using malloc: int (*ptr3)[YDIM][ZDIM] = malloc(XDIM * sizeof *ptr3); if (ptr3 == NULL) { /* Allocation failed */ } The two arrays (array3 and the one created using malloc) are laid out in the same way in memory. The only difference is that the malloc'd array doesn't have a name so must be accessed through an auxiliary pointer, and is released using free(). The malloc'd array can be accesses using ptr3[x][y][z] i.e. similarly to array3[x][y][z]. -- -----------------------------------------
-----------------------------------------
|
Sat, 21 Apr 2001 03:00:00 GMT |
|
|
Graeme Fenwic #15 / 25
|
Malloc 2: The revenge of Malloc
Dammit... the original post in this thread is gone. So bear in mind I haven't got that to refer back to...
:C doesn't support multidimensional arrays at all so it is unclear what :"a *genuine* multidimensional array" means in the context of C. Chris Torek has already slapped my hands for this mistake. It was sloppy use of language- I meant arrays of arrays, but functionally, I tend to consider them as multidimensional arrays. No misleading indoctrination of newbies intended ;-) However, I hope I'm correct in saying that there's no way to dynamically allocate a genuine array (of whatever type, including another array) at runtime.
(Remove "BYESPAM" spam filter when replying by mail)
|
Sun, 22 Apr 2001 03:00:00 GMT |
|
|
Page 1 of 2
|
[ 25 post ] |
|
Go to page:
[1]
[2] |
|