what is the meaning of strtok(NULL,"$")?

basically used to parse a text into smaller tokens, based on the delimiter u provide...
c89 standard strtok.. should give u an idea...

$ is the delimiter here, the function takes the address of the stringto parse, so NULL probably means your not passing any string to it.

and if ur interested, this place tells u something about the bad sides of strtok... u can take a look at it too.

strtok uses the name of the string on its first invocation, NULL thereafter for the same string.

strtok can be confusing at first; it's a good instruction when you know how it works.

strtok uses the name of the string on its first invocation, NULL thereafter for the same string.

that sounds good... any code exapmples?

that sounds good... any code exapmples?

That's something you could (and should!) search for yourself, but I'll bite:

#include <stdio.h>
#include <string.h>

int main(void)
{
    char src[] = "This is a test"; /* Note that it's an array and not a pointer */
    char *tok = strtok(src, " ");

    while (tok) {
        puts(tok);
        tok = strtok(NULL, " ");
    }

    return 0;
}

The single most important thing to remember about strtok() is that it modifies the source string. Thus you can't use a pointer to a string literal, and if you want to retain the original string you must make a copy for strtok() to consume.

im reading this page about strtok() being bad... and i quite like it... has quite a detailed explanation of things..

for those interested, this page has a nice and short definition of re entrancy, and also this page,... though its a bit hard to understand (to me!)

im reading this page about strtok() being bad... and i quite like it... has quite a detailed explanation of things..

"Bad" as in "not designed the way I would have designed it". It certainly points out the issues that you need to keep in mind when using strtok(), but a program breaking when you use a function in a way that actively and intentionally goes against its design doesn't make the function bad, it makes you a bad programmer.

actively and intentionally goes against its design

a lot of ppl suggest strtok() for parsing... just shows how many ppl dont read (what can be said as) "the fine print" associated with a function...
daniweb's clearing stuff out.. so thats good :)

on another note, what is strtok() good/designed for?
there was this part in that page :

The correct way to use strtok is to pass it a copy of the string unless you know that it’s ok to modify it.

so thats how strok() should only be used?

the 2nd code in that page also feels good.. :)

on another note, what is strtok() good/designed for?

Tokenizing strings. But it's not designed to be reentrant, or designed to work with read-only strings, which is pretty much all the article you linked to complains about. I was kind of hoping for an actual argument against strtok() rather than the usual rehashed "it doesn't do what I think it should". :rolleyes:

so thats how strok() should only be used?

Obviously. I mean, if you know it's not okay to modify the string or you can't make a copy then clearly strtok() is the wrong choice. I'm not saying that you should always use strtok(), but anyone who says strtok() is evil and should never be used is an idiot.

but anyone who says strtok() is evil and should never be used is an idiot.

i think all this bad hype about strtok() is only coz people who dont know about these issues with it, put it in their code n think everythings gonna work fine,
and then, they hit run ....... and crash! :P

hence the frustration, leading it to the evil tag.. :P
satan's parser!!

i think all this bad hype about strtok() is only coz people who dont know about these issues with it, put it in their code n think everythings gonna work fine, and then, they hit run ....... and crash! :P

Bingo! There's really only one true case of a function being straight up "bad" across the board, and that function is gets(). The reason it's bad is because there's literally no way to make a call to gets() safe. Even atoi(), my next choice for the canonical "bad" function, can be made safe with careful validation around the call.

Fortunately, gets() was removed in the latest revision of the C standard.

There's really only one true case of a function being straight up "bad" across the board, and that function is gets()

use fgets() and stay happy.. :)
use gets() and get buffer overflow! (its quite easy to understand why it does that as well..)

as regards atoi() , i guess only if the programmer knows exactly how his code will be used, he can go with atoi() if needed... but the limitations i'm reading about it, makes it bad for any real life, out-of-the-classroom coding situations anyways.

some links i found useful:

  1. gets() being bad: read here
  2. atoi() being bad: read here and here

Fortunately, gets() was removed in the latest revision of the C standard.

any links to some good C11 resources ? the page i refer to most of the time is C89 standard.. the cplusplus.com

any links to some good C11 resources ?

For library details concerning all standards, this is available. Honestly, I just refer to the draft standard, but that takes practice due to the legalese it's written with. I'm not aware of any books or decent tutorial websites available yet.

the draft standard is just wow!!!

man! if only the college teachers abided by stuff like these...

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.