Thread: string ?

hello,
as i know laerning c we can see in a program in the begiining of ir what will i wil lbe? like:

int i;

or we can say:

char i;

or

float i;

but how can we do it be a strinf and be saved as a string i check and it is not

string i;

any help?

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.

To declare a dynamic string you say something like this:

Code:

#include <stdio.h>  /* For BUFSIZ */
#include <stdlib.h> /* For malloc */

char *string = malloc ( BUFSIZ );

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.

hey,
i done the following code:

Code:

 #include <stdio.h>

main()
{
 char string[BUFSIZ];

printf("Hello, how are you?\n");
scanf("%s", BUFSIZ);
printf("bad");
}

but i get this error when compiling:

dokimi.c:1: parse error before "buffer"
dokimi.c:1:36: missing terminating ' character
dokimi.c:1:36: warning: character constant too long
dokimi.c:2: parse error before "you"
dokimi.c:2: parse error before "that"
dokimi.c:3: parse error before "enter"
dokimi.c:3:36: missing terminating ' character
dokimi.c:3:36: warning: character constant too long
In file included from /usr/include/bits/types.h:143,
from /usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2/include/stdio
.h:45,
from dokimi.c:5:
/usr/include/bits/pthreadtypes.h:48: parse error before "size_t"
/usr/include/bits/pthreadtypes.h:51: parse error before "__stacksize"
In file included from /usr/include/_G_config.h:44,
from /usr/include/libio.h:32,
from /usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2/include/stdio
.h:74,
from dokimi.c:5:
/usr/include/gconv.h:72: parse error before "size_t"
/usr/include/gconv.h:85: parse error before "size_t"
/usr/include/gconv.h:94: parse error before "size_t"
/usr/include/gconv.h:170: parse error before "size_t"
/usr/include/gconv.h:173: parse error before '}' token
In file included from /usr/include/libio.h:32,
from /usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2/include/stdio
.h:74,
from dokimi.c:5:
/usr/include/_G_config.h:47: field `__cd' has incomplete type
/usr/include/_G_config.h:50: field `__cd' has incomplete type
In file included from /usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2/include/stdio
.h:74,
from dokimi.c:5:
/usr/include/libio.h:344: parse error before "size_t"
/usr/include/libio.h:353: parse error before "size_t"
/usr/include/libio.h:461: parse error before "_IO_sgetn"
/usr/include/libio.h:461: parse error before "size_t"
In file included from dokimi.c:5:
/usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2/include/stdio.h:268: parse error be
fore "size_t"
/usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2/include/stdio.h:274: parse error be fore "size_t"
/usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2/include/stdio.h:302: parse error be fore "size_t"
/usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2/include/stdio.h:306: parse error be fore "size_t"
/usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2/include/stdio.h:468: parse error be fore "fread"
/usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2/include/stdio.h:468: parse error be fore "size_t"
/usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2/include/stdio.h:471: parse error be fore "fwrite"
/usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2/include/stdio.h:471: parse error be fore "size_t"
/usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2/include/stdio.h:476: parse error be fore "fread_unlocked"
/usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2/include/stdio.h:476: parse error be fore "size_t"
/usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2/include/stdio.h:478: parse error be fore "fwrite_unlocked"
/usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2/include/stdio.h:478: parse error be fore "size_t"
/usr/include/gconv.h:172: warning: array `__data' assumed to have one element

why?

Look at this:

Code:

#include <stdio.h>
#include <stdlib.h> // for system command.

using namespace std;
char MyString[BUFSIZ];

int main()
{
    printf("Hello, how are you?\n");
    scanf("%s", &MyString[0]);
    printf("bad");
  
  system("PAUSE");	
  return 0;
}

OOps i forgot the & IN MY SCRIPT BUT WOULD like to ask what doe susing namespace std and systempause do as without them programs run well and why do we have [0] AND NOT ANOTHER NUMBER?

thankjs

by the way,
is it able scanf a whole sentenece with space inside like "Hello guys" an dnot get only the Hello?

thanks

Originally Posted by Bajanine

Look at this:

Code:

#include <stdio.h>
#include <stdlib.h> // for system command.

using namespace std;
char MyString[BUFSIZ];

int main()
{
    printf("Hello, how are you?\n");
    scanf("%s", &MyString[0]);
    printf("bad");
  
  system("PAUSE");	
  return 0;
}

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.

Maybe, I need to lay off the coffee and get some sleep!

>She said better not perfect
If I wanted perfect, I wouldn't use C.

>Oh oh. C has just died.
So says the guy who just posted code with void main.

>Of course not, thats what assembly is for
Only if you want a perfect mess.

>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.

>If you want a 200+ post "technical discussion" on void main vs gets, I'd suggest comp.lang.c.
Been there, done that. The cheap bastards didn't even give me a T-shirt.

>I think we can agree that neither constitute Good Advice™.
I'm glad we agree.