string ?

This is a discussion on string ? within the C Programming forums, part of the General Programming Boards category; hello,
as i know laerning c we can see in a program in the begiining of ir what will i ...

A string in C is simply an array of char with a special character ('\0') at the end. Naturally, you aren't forced to use that setup, but it's supported by the standard library and it's what everyone expects, so we usually use it.

To declare a static string you say this:

Code:

#include <stdio.h> /* For BUFSIZ */
char string[BUFSIZ];

The size of the array will vary drastically depending on how the string is going to be used. However, for strings that will take user or file input, BUFSIZ is a good assumption and saves you a little effort. Feel free to use BUFSIZ until you know for sure what kind of input you're expecting.

We're simply simulating an array by asking the memory manager to allocate N contiguous bytes (where N is equal to BUFSIZ) and return a pointer to the first byte. From there we can treat this string much like the static string. It comes in handy when you will only know the size of a string at run-time, because array sizes can only be specified at compile-time in C89. C99 supports variable length arrays, but that's getting a bit off-topic.

Notice that the call to malloc is different from what we usually recommend:

Code:

T *p = malloc ( N * sizeof *p );

The part that's missing is multiplying N by the size of the type being pointed to. The reason it's missing is because sizeof ( char ) is guaranteed to be 1, so it can be safely removed when allocating arrays of char.

When you allocate memory with malloc, always remember to free it when you're done:

Code:

free ( string );

That way you avoid memory leaks that can eat up resources and slow down your system on machines that don't reclaim a process' memory, or programs that run for long periods of time.

>For that reason someone invented C++.
BLASPHEMY! Begone from my C board, you foul lover of objects, before the gods of C cast you into the void as punishment for your weakness! There is no penance for saying such things in my presence. You are henceforth excommunicated. Never return to this house, filthy heretic!

Eew. First, this isn't the C++ forum. A using directive in C is a syntax error. Second, system("pause") is a poor way of keeping the program window open. Third, &MyString[0] is just clutter. You can use MyString with equal success.

@cogeek

>scanf("%s", BUFSIZ);
This is your biggest problem. BUFSIZ is a macro which turns out to be an integer literal. The %s format modifier expects a pointer to char. Change your call to:

Code:

scanf("%s", string);

And you'll find that it works better. Note that no ampersand is required because an array name is almost always converted to a pointer to the first element.

>main()
This is legal in C89, but bad practice. It's better to state the return type explicitly:

Code:

int main(void)

And don't forget to return a value! Even if you use C89's implicit int feature, failure to return a value is still undefined behavior.

>is it able scanf a whole sentenece with space inside like "Hello guys" an dnot get only the Hello?
Yes, but it's tricky to get right. A better solution would be to use fgets and forget about scanf entirely for all of your string input.

>For that reason someone invented C++.
BLASPHEMY! Begone from my C board, you foul lover of objects, before the gods of C cast you into the void as punishment for your weakness! There is no penance for saying such things in my presence. You are henceforth excommunicated. Never return to this house, filthy heretic!

>gets, or your equivalent, is worse than void main on the scale of C nasties.
gets, or my small improvement to Bajanine's equivalent, is only a potential threat. void main is always undefined behavior on a hosted implementation. If you really want to get into a technical debate with me then I'll be happy to oblige. *evil grin*

>maybe it is time some of the security vulnerabilities were removed from the C library.
It's long past due, which means that it won't happen because removing those functions would break too much existing code. It's a shame, but we just have to live with it.