On Sun, 1 Apr 2001, Peter Ajamian wrote:
> You did worse than that, you tried to use it on a constant which will
> prevent it from even compiling at all.
He's not casting away constness. The code was akin to
char *p1 = "abcdef";
char *p2 = strtok(p1, "c");
printf("strtok(\"%s\") = %s", p1, p2);
which will compile just fine with no warnings (assuming you add the
scaffolding around it to make it into a complete program), but crash.
> This is true, so caution is necessary. Fact is you shouldn't use
> _any_ function without realizing the implications
Fact is that people _will_ regardless of what you and I think they should
do and its worth pointing out here the pitfalls so that in the same place
they learned about strtok() they can learn about how it's not quite as
cool as one might first think.
> Depends on your defenition of better, if you mean devices that are
> less prone to break down under bad coding tecnique then you are
> correct, if you mean devices which are more efficient then that is
> open to some matter of debate.
strtok() is efficient only within its very narrow scope. For everything
outside of that, it is a steaming piece of crap. It modifies its first
argument, meaning that to keep it, you have to copy it; it modifies its
first argument, meaning that to work with a static string, you have to
copy it; it copies into static store on each non-NULL call; you lose the
delimiting character (so you can't know what caused the string to
terminate without further work); etc.
I can use a hammer to put a screw in the wall. That doesn't mean I should
and that doesn't mean it'll do it well. You're advocating proper use of
strtok() while you're using it completely outside of its scope. You're
correct that the BSD man pages make a blanket statement that is not
strictly true: strtok() can be used to tokenize multiple strings
simultaneously. You're ignoring, however, that it should not be. The
amount of copying, the complexity of the resulting code, etc., makes
strtok() highly unsuited for this task. It wasn't meant to do this and it
doesn't do it well on any level.
> This is exactly what your example tried to do. Again, strcpy() or
> str_dup() the input if this is a problem.
His example was of a bad use of strtok(). Not surprisingly, it did some
bad things. There's no need to lambaste him for it.
> The example you gave is no more "recursive" than this. Anyways, it
> demonstrates a wahy that strtok() can be used safely in recursion also.
There's a huge difference between recursion and iteration. Be advised of
this before continuing this aspect of the discussion: the code you posted
is not recursive at all. Recursion has a specific definition within
programmer jargon. Your code does not employ recursion.
> The correct output is what I showed.
Try it and see for yourself. That code is both a convincing argument
against that use of strtok() because of its complexity and a convincing
argument that even competent coders can stumble over complexity. The
output of your function is:
Th is a t est.
with no newline, and not what you showed.
In conclusion: you're arguing the same points from different perspectives.
It's strange to see two people agreeing on the core of the concept and
bickering over the frame of reference and other minutiae. (Primarily
because one of them isn't me.) So drop it. And everyone play nice.
-dak: There's only room for one asshole on this list. And I'm him.
--
+---------------------------------------------------------------+
| FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
| Archives: http://post.queensu.ca/listserv/wwwarch/circle.html |
+---------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/05/01 PST