Hi,i have a question about C. (i use linux).The problem is: I will

  • Thread starter Thread starter rambo3131
  • Start date Start date
AI Thread Summary
The discussion focuses on reading an arbitrary number of character lines from standard input in C, emphasizing the need for dynamic memory allocation due to the unknown size and number of lines. The use of `fgets` is recommended for reading lines, while `malloc` and `realloc` are suggested for managing memory for each line and the array of line pointers. Participants highlight the importance of terminating each line with a null character and marking the end of the lines with a null pointer. There's a suggestion to consider C++ for easier memory management, utilizing standard string and vector types that automatically handle resizing. The conversation also touches on the potential for allocating maximum expected memory based on user input, while encouraging the use of man pages for further guidance on functions like `fgets` and `realloc`.
rambo3131
Messages
18
Reaction score
0
Hi,i have a question about C. (i use linux).The problem is: I will read arbitrary number of character lines from standard input.(not from a file). Size of the lines is also arbitrary. Lines are separated with new line character. . I must send EOF with CTRL-D from terminal.

I should allocate space for each line. Each line should be terminated with terminating null character ('\0').
After the last line, I should mark the end of the lines with a null pointer (NULL).


I don't want code,but some hints please please help me
 
Technology news on Phys.org


You can read the lines in with fgets (do NOT use gets) into a fixed length buffer, with the length being the longest line you will see.

You probably don't know how many lines of input you will get. Given what you said, I'm thinking you can malloc an array of char * and realloc it when you need more space for more lines.

Don't forget you have access to man pages. So you can type 'man fgets' in a shell to see documentation on fgets, realloc, fopen, etc.

Does that help?

P.S. To read from standard input, just use 'stdin' as the FILE* to fgets (or other calls to that stream).
 


rambo3131 said:
I will read arbitrary number of character lines from standard input.(not from a file). Size of the lines is also arbitrary.

Is there an upper limit on the length of a line, or on the number of lines? If your only constraint is your computer's memory capacity, then you have to use dynamic memory allocation (malloc()) and be prepared to increase the size of the allocated memory for a line, or for the number of lines, when necessary. I'm not very familiar with C-style memory allocation (I'm a C++ guy myself), but I think realloc() can be used for this. For example, if you fill the memory allocated for a line, you can expand it by e.g. a factor of two.
 


There's an alterative approach. Any user input will be smaller than the amount of available space in RAM, at least on a modern day PC. Taking advantage of this, you can allocate (malloc()) enough memory to hold the largest amount of input you expect to see with this program, and also allocate enough memory required to hold an array of pointers for the maximum number of lines you expect to see. After receiving a line of input data, if the function you use reports the number of character input, you can use that to set a pointer to the next line and input agin. The alternative is to use memchr to search for the EOL (and advance one past that to set a pointer for the next line).
 
Last edited:


Have you considered programming in C++ instead of in C?
Everything that works in C works in C++ as well, but C++ has features that makes what you want to do easier.
 


Yes, by using the standard string and vector types to store the data, you eliminate any worries about capacity, at least until you run out of memory in your computer.

When you read a string using getline(), it automatically expands to accommodate the entire line.

When you append an item to a vector using the push_back() member function, the vector automatically expands as necessary.
 
Thread 'Is this public key encryption?'
I've tried to intuit public key encryption but never quite managed. But this seems to wrap it up in a bow. This seems to be a very elegant way of transmitting a message publicly that only the sender and receiver can decipher. Is this how PKE works? No, it cant be. In the above case, the requester knows the target's "secret" key - because they have his ID, and therefore knows his birthdate.
Thread 'Project Documentation'
Trying to package up a small bank account manager project that I have been tempering on for a while. One that is certainly worth something to me. Although I have created methods to whip up quick documents with all fields and properties. I would like something better to reference in order to express the mechanical functions. It is unclear to me about any standardized format for code documentation that exists. I have tried object orientated diagrams with shapes to try and express the...

Similar threads

Back
Top