How to spilt string without library ?

[SmartBoy]

Hello

i want write code to split string to charachtar .

for example i have this string "Hello World"

i want get it like this

H
e
l
l
o

W
o
r
l
d

i need the idea please ::)

[Cjmovie]

Do you understand the concepts of strings? Or are you using Assembly? I'm supposing C, so here it goes:

A string is an array of characters. So a string is REALLY just a pointer. Like this:

Code: Select all

char* MyMessage = "Hello World!":
//   ^ Notice the * to make it a pointer

As such, you can treat it just like an array. So this:

Code: Select all

PrintChar(MyMessage[4]);

Would print

o

Because 'o' is the 5th letter of the string (remember - arrays start at 0, not 1!)

So you could just loop until you find the end of the string. The end of the string is found very simply: It will be a letter, but it will equal '0' if you compare it.

This code will take a string and print out one character on each line:

Code: Select all

void SplitString(char* Message){
 int i = 0; //Counting variable
 while(Message[i] != 0){ //While we haven't reached the end, marked by 0
  PrintChar(Message[i]); //Print character from string
  PrintChar('\n'); //Newline
  i++;
 }
}

Note! You must have a function that prints one character on the screen to use this, PrintChar.

[Solar]

Sorry, couldn't resist:

Code: Select all

void SplitString(char* Message){
 int i = 0; //Counting variable
 while(Message[i] != 0){ //While we haven't reached the end, marked by 0
  PrintChar(Message[i]); //Print character from string
  PrintChar('\n'); //Newline
  i++;
 }
}

Why do people always code so literally?

Code: Select all

void SplitString( char * Message )
{
    while ( *Message )
    {
        PrintChar( *Message++ );
        PrintChar( '\n' );
    }
}

Or, if your PrintChar() conveniently returns the character it just printed:

Code: Select all

void SplitString( char * Message )
{
    while ( PrintChar(*Message++) )
    {
        PrintChar( '\n' );
    }
}

[distantvoices]

Why do people always code so literally?

For understanding, solar. Elegance comes afterwards.

[Candy]

Why do people always code so literally?

Because the code looks obvious. Your code got me thinking for 3 seconds before I figured it out, plus it's got an error which you didn't notice yet. It doesn't print newlines, but rather the entire string just as it was.

[Solar]

No it doesn't!



Ahem...

;D

OK, I edited it.

[SmartBoy]

i don't know how i can thank you guys

i understand it and write my code .. thank you very very much

[Joel (not logged in)]

Code: Select all

void SplitString(char* Message){
int i = 0; //Counting variable
while(Message[i] != 0){ //While we haven't reached the end, marked by 0
  PrintChar(Message[i]); //Print character from string
  PrintChar('\n'); //Newline
  i++;
}
}

Please! I beg you! No while(*Message++)ing!! Actually this is a perfect for-loop:

Code: Select all

void SplitString(char* Message)
{
    for (int i = 0; Message[i] != '\0'; i++)
    {
        PrintChar(Message[i]);
        PrintChar('\n');
    }
}

[Solar]

Please! I beg you! No while(*Message++)ing!!

And why not? It's standard C lingo, and saves you one temporary variable on the stack...

[troflip]

And why not? It's standard C lingo, and saves you one temporary variable on the stack...

Yeah, but it's much less readable (IMO). Clarity is good

[Solar]

Yeah, but it's much less readable (IMO). Clarity is good

That is what I meant with "standard C lingo": That kind of pointer incrementing is a very common procedure, especially in string operations where '\0' signifies the end of the sequence. I consider it to be more readable, at least if you're used to writing / reading C.

[Joel (not logged in)]

Hmmm...I don't know. I'm pretty well used to reading and writing C++, anyway, and I consider that kind of stuff to obscure the code, although granted only by a little. I have a much bigger problem with:

while (PrintChar(*Message++))

In either case, something about relying on the 1/0 convention feels very assembly-languageish to me. Same deal with worrying about saving an int's worth of space on the stack

[Solar]

I wrote two versions of strcpy():

Code: Select all

void test( char* dest, char const* src )
{
        while ( *dest++ = *src++ );
}

Code: Select all

void test( char* dest, char const* src )
{
        int i;
        for ( i = 0; src[i] != '\0'; ++i )
        {
                dest[i] = src[i];
        }
        dest[i] = '\0';
}

I won't bore you with posting disassembly (you can try this at home), but we have:

• 1 vs. 4 effective code lines;
• 75 vs. 133 bytes of source;
• 28 vs. 50 bytes of object code (compiled with -O3);
• 1 vs. 2 movzbl;
• 1 vs. 2 conditional jumps.

C is "portable high-level assembler", it's been designed as such, and the only reason I am using it is if the task at hand is performance-critical. (Actually I'm comfortable enough with C++ to use that for performance-critical stuff...) I haven't profiled the object code but I'd expect a performance benefit of roundabout 50%.

I won't make this personal, but using a loop counter for iterating through a C string is so very Pascal...

[ark]

For a simple function like that, it's no big deal. I see it as a trade-off. The first version has the advantages you mention. The second is more code to digest and slightly less efficient. However, the first version is, I think, easier to make mistakes with and equally hard to read (bloating the second version with a little spacing would probably help its readability), because the code is considerably more complex per line and relies strongly on subtle properties (zero as false and value of assignment and zero as string terminator).

C is "portable high-level assembler", it's been designed as such, and the only reason I am using it is if the task at hand is performance-critical. (Actually I'm comfortable enough with C++ to use that for performance-critical stuff...) I haven't profiled the object code but I'd expect a performance benefit of roundabout 50%.

I'd use C++, on the other hand, even if performance weren't critical, and C code sometimes falls into my hands. I'm not trying to say you should never write code like that in C. I am simply saying I think it makes code a little less readable. In many cases where I've seen it, it's premature optimization. In a string copy function, it can certainly be appropriate because it's probably something you're going to call often and you don't want to drain performance with an iniefficient implementation (although really the efficient version still should be avoided because it is prone to buffer overflows, so we need a loop counter anyway, plus an additional comparison).

I won't make this personal, but using a loop counter for iterating through a C string is so very Pascal...

Well, that was my first real programming language (I knew a very little bit of Basic before that but not very much), so maybe it has influenced my style

[Solar]

...the efficient version still should be avoided because it is prone to buffer overflows, so we need a loop counter anyway, plus an additional comparison.

I agree that strcpy() is insecure (and probably a bad example), but I challenge you to:

• come up with a strcpy() that is not prone to overflows (how do you determine the available size in [tt]dest[/tt]?);
• come up with a strcpy() that couldn't be reproduced omitting any local variables without reducing readability for one used to C lingo.

;

Well, [Pascal] was my first real programming language (I knew a very little bit of Basic before that but not very much), so maybe it has influenced my style

That is all I meant: For one really used to C, the pointer "magic" done in my first example holds no terrors, and is actually less error-prone than handling the loop counter, getting the conditional right and remembering to set the terminating '\0' manually.

I really mean no offense. I myself don't have that much on-hand experience with C. But those redundant loop counters scream all kind of warnings at me not to trust a single line of the code because quite obviously the author is not used to writing C.