I'm using strtok to break apart a colon-delimited string. It basically
works, but it looks like strtok skips over empty sections. In other
words, if the string has 2 colons in a row, it doesn't treat that as a
null token, it just treats the 2 colons as a single delimiter.
Is that the intended behavior?
26  4375 
On 12 Oct 2006 11:38:36 -0700, ry********@gmail.com wrote:
>I'm using strtok to break apart a colon-delimited string. It basically
works, but it looks like strtok skips over empty sections. In other
words, if the string has 2 colons in a row, it doesn't treat that as a
null token, it just treats the 2 colons as a single delimiter.
Is that the intended behavior?
Yes. This is one of the drawbacks of strtok. From the current
position, it searches for a character *not* in the delimiter set, sets
this position as the return pointer, then searches for the first
character that *is* in the delimiter set and sets it to null.
(Individual implementations may be different, but that's the way it's
required to behave.)
For your application, it's probably easier to scan the string
yourself.
--
Al Balmer
Sun City, AZ ry********@gmail.com wrote:
I'm using strtok to break apart a colon-delimited string. It basically
works, but it looks like strtok skips over empty sections. In other
words, if the string has 2 colons in a row, it doesn't treat that as a
null token, it just treats the 2 colons as a single delimiter.
Is that the intended behavior?
Yes. Just one more reason to avoid strtok().
- William Hughes
William Hughes wrote:
>
ry********@gmail.com wrote:
I'm using strtok to break apart a colon-delimited string. It
basically works, but it looks like strtok skips over empty
sections. In other words, if the string has 2 colons in a row, it
doesn't treat that as a null token, it just treats the 2 colons as
a single delimiter.
Is that the intended behavior?
Yes. Just one more reason to avoid strtok().
Unless that's the behavior you want. Example, breaking lines into words
with white space. You don't want a bunch of "null" words.
Brian ry********@gmail.com writes:
I'm using strtok to break apart a colon-delimited string. It basically
works, but it looks like strtok skips over empty sections. In other
words, if the string has 2 colons in a row, it doesn't treat that as a
null token, it just treats the 2 colons as a single delimiter.
strtok() has at least these problems:
* It merges adjacent delimiters. If you use a comma as your
delimiter, then "a,,b,c" will be divided into three tokens,
not four. This is often the wrong thing to do. In fact, it
is only the right thing to do, in my experience, when the
delimiter set contains white space (for dividing a string
into "words") or it is known in advance that there will be
no adjacent delimiters.
* The identity of the delimiter is lost, because it is
changed to a null terminator.
* It modifies the string that it tokenizes. This is bad
because it forces you to make a copy of the string if
you want to use it later. It also means that you can't
tokenize a string literal with it; this is not
necessarily something you'd want to do all the time but
it is surprising.
* It can only be used once at a time. If a sequence of
strtok() calls is ongoing and another one is started,
the state of the first one is lost. This isn't a
problem for small programs but it is easy to lose track
of such things in hierarchies of nested functions in
large programs. In other words, strtok() breaks
encapsulation.
--
"A lesson for us all: Even in trivia there are traps."
--Eric Sosman
Default User wrote:
William Hughes wrote:
ry********@gmail.com wrote:
I'm using strtok to break apart a colon-delimited string. It
basically works, but it looks like strtok skips over empty
sections. In other words, if the string has 2 colons in a row, it
doesn't treat that as a null token, it just treats the 2 colons as
a single delimiter.
>
Is that the intended behavior?
Yes. Just one more reason to avoid strtok().
Unless that's the behavior you want. Example, breaking lines into words
with white space. You don't want a bunch of "null" words.
The point is not that the function's behaviour is not sometimes
what you want. The point is
-the default behaviour is surprising
-the default behaviour is not even
usually what you want
-the default behaviour throws information away
-if you don't like the default behaviour, see
figure 1.
Personally I'm with the Linux man pages on this one. Under Bugs
is the advice "Never use this function".
-William Hughes
William Hughes wrote:
>
Default User wrote:
Unless that's the behavior you want. Example, breaking lines into
words with white space. You don't want a bunch of "null" words.
The point is not that the function's behaviour is not sometimes
what you want. The point is
-the default behaviour is surprising
Only if one fails to read the documentation. A number of functions are
funny that way.
-the default behaviour is not even
usually what you want
How do you know? Even if true, so what?
-the default behaviour throws information away
Again, if you know that and if fits the problem, so what?
-if you don't like the default behaviour, see
figure 1.
I don't understand this statement. I have no idea what "figure 1" is.
Personally I'm with the Linux man pages on this one. Under Bugs
is the advice "Never use this function".
Well, that's stupid advice. The function may be tricky, but sometimes
it's just the right thing. In those cases, it should be used. If not,
it shouldn't.
Brian
On 12 Oct 2006 14:32:27 -0700, "William Hughes"
<wp*******@hotmail.comwrote:
>
Default User wrote:
>William Hughes wrote:
>
ry********@gmail.com wrote:
I'm using strtok to break apart a colon-delimited string. It
basically works, but it looks like strtok skips over empty
sections. In other words, if the string has 2 colons in a row, it
doesn't treat that as a null token, it just treats the 2 colons as
a single delimiter.
Is that the intended behavior?
Yes. Just one more reason to avoid strtok().
Unless that's the behavior you want. Example, breaking lines into words
with white space. You don't want a bunch of "null" words.
The point is not that the function's behaviour is not sometimes
what you want. The point is
-the default behaviour is surprising
The behavior of many functions might be surprising if you don't read
the documentation.
>
-the default behaviour is not even
usually what you want
Like any other function in the library, it's used where appropriate.
Sometimes it *is* what I want.
>
-the default behaviour throws information away
I don't really know what information you're referring to. You could
just as easily say it adds information. If there's information that
you need to protect, it's trivial.
>
-if you don't like the default behaviour, see
figure 1.
? Did you copy this from a book with pictures? That would explain the
odd indentation, I suppose.
>
Personally I'm with the Linux man pages on this one. Under Bugs
is the advice "Never use this function".
That's silly. Like any other function, it should be used when
appropriate, and not used when not appropriate.
--
Al Balmer
Sun City, AZ ry********@gmail.com wrote:
>
I'm using strtok to break apart a colon-delimited string. It
basically works, but it looks like strtok skips over empty
sections. In other words, if the string has 2 colons in a row, it
doesn't treat that as a null token, it just treats the 2 colons as
a single delimiter.
Is that the intended behavior?
Yes. If that is a problem, consider using my toksplit routine, the
code for which has been published here before. I think googling
for "toksplit" will bring it up, so I won't burden the newsgroup
with YAC (yet another copy).
--
Some informative links:
<news:news.announce.newusers
<http://www.geocities.com/nnqweb/>
<http://www.catb.org/~esr/faqs/smart-questions.html>
<http://www.caliburn.nl/topposting.html>
<http://www.netmeister.org/news/learn2quote.html>
<http://cfaj.freeshell.org/google/>
Al Balmer wrote:
On 12 Oct 2006 14:32:27 -0700, "William Hughes"
<wp*******@hotmail.comwrote:
Default User wrote:
William Hughes wrote:
ry********@gmail.com wrote:
I'm using strtok to break apart a colon-delimited string. It
basically works, but it looks like strtok skips over empty
sections. In other words, if the string has 2 colons in a row, it
doesn't treat that as a null token, it just treats the 2 colons as
a single delimiter.
>
Is that the intended behavior?
Yes. Just one more reason to avoid strtok().
Unless that's the behavior you want. Example, breaking lines into words
with white space. You don't want a bunch of "null" words.
The point is not that the function's behaviour is not sometimes
what you want. The point is
-the default behaviour is surprising
The behavior of many functions might be surprising if you don't read
the documentation.
-the default behaviour is not even
usually what you want
Like any other function in the library, it's used where appropriate.
Sometimes it *is* what I want.
-the default behaviour throws information away
I don't really know what information you're referring to.
The number of delimiters. (strtok() also discards the identity
of these delimiters but that has not been previously mentioned in
this subthread).
You could
just as easily say it adds information. If there's information that
you need to protect, it's trivial.
-if you don't like the default behaviour, see
figure 1.
? Did you copy this from a book with pictures? That would explain the
odd indentation, I suppose.
figure 1. is a picture of a hand with a single digit extended (guess
which
one). It comes from an old piece of xerox-lore, a parody of DEC (?)
documentation in which an oft repeated phase is "see figure 1."
I guess the reference was a little too obscure.
Personally I'm with the Linux man pages on this one. Under Bugs
is the advice "Never use this function".
That's silly. Like any other function, it should be used when
appropriate, and not used when not appropriate.
Well, never is probably too strong. However, strtok() is dominated by
a good general purpose parsing method. Since you need a good
general purpose parsing method, why not use that instead of
strtok()?
- William Hughes
On 12 Oct 2006 16:47:31 -0700, "William Hughes"
<wp*******@hotmail.comwrote:
>Well, never is probably too strong. However, strtok() is dominated by
a good general purpose parsing method. Since you need a good
general purpose parsing method, why not use that instead of
strtok()?
Where one is needed, I do, and am obligated to supply it with the rest
of the code. Anyone maintaining that code is then obligated to read
and understand it.
Where it's not needed, strtok is already there, and the maintainer
already knows what it does.
It's the same reason I don't supply my own version of other parts of
the standard library.
--
Al Balmer
Sun City, AZ
Ben Pfaff wrote:
>
ry********@gmail.com writes:
>I'm using strtok to break apart a colon-delimited string. It
basically works, but it looks like strtok skips over empty
sections. In other words, if the string has 2 colons in a row,
it doesn't treat that as a null token, it just treats the 2
colons as a single delimiter.
strtok() has at least these problems:
* It merges adjacent delimiters. If you use a comma as your
delimiter, then "a,,b,c" will be divided into three tokens,
not four. This is often the wrong thing to do. In fact, it
is only the right thing to do, in my experience, when the
delimiter set contains white space (for dividing a string
into "words") or it is known in advance that there will be
no adjacent delimiters.
* The identity of the delimiter is lost, because it is
changed to a null terminator.
* It modifies the string that it tokenizes. This is bad
because it forces you to make a copy of the string if
you want to use it later. It also means that you can't
tokenize a string literal with it; this is not
necessarily something you'd want to do all the time but
it is surprising.
* It can only be used once at a time. If a sequence of
strtok() calls is ongoing and another one is started,
the state of the first one is lost. This isn't a
problem for small programs but it is easy to lose track
of such things in hierarchies of nested functions in
large programs. In other words, strtok() breaks
encapsulation.
Whence sprang toksplit, which returns a pointer to the src string
just past the delimiting char, except at end of string. The only
possible nuisance IMO is that it handles only one possible token
delimiter char (apart from '\0').
const char *toksplit(const char *src, /* Source of tokens */
char tokchar, /* token delimiting char */
char *token, /* receiver of parsed token */
size_t lgh) /* length token can receive */
/* not including final '\0' */
--
Some informative links:
<news:news.announce.newusers
<http://www.geocities.com/nnqweb/>
<http://www.catb.org/~esr/faqs/smart-questions.html>
<http://www.caliburn.nl/topposting.html>
<http://www.netmeister.org/news/learn2quote.html>
<http://cfaj.freeshell.org/google/>
Al Balmer wrote:
On 12 Oct 2006 16:47:31 -0700, "William Hughes"
<wp*******@hotmail.comwrote:
Well, never is probably too strong. However, strtok() is dominated by
a good general purpose parsing method. Since you need a good
general purpose parsing method, why not use that instead of
strtok()?
Where one is needed, I do, and am obligated to supply it with the rest
of the code. Anyone maintaining that code is then obligated to read
and understand it.
Where it's not needed, strtok is already there, and the maintainer
already knows what it does.
It's the same reason I don't supply my own version of other parts of
the standard library.
Ok. I can see why, if you expect the code to be maintained by
others (a common setup), you would want to use standard functions.
And, usually, a bad standard is better than no standard. But there
are limits!
In any case, I don't think your average maintainence drone would
know how strtok() works, or that said drone would be better
at reading the documentation for strtok() than any documentation
you supply with a good general purpose routine.
One reason for my opinion is that personally I don't find
strtok() very useful (Indeed, outside of a couple of exericises that
mandated its use, I don't think I have ever used it). This is in
part because, if possible, I don't use C for string manipulation.
But even when I do use C I don't use strtok(). Clearly, my
situation may not be the most usual one (or even common).
- William Hughes
William Hughes wrote:
Default User wrote:
>William Hughes wrote:
>>ry********@gmail.com wrote:
I'm using strtok to break apart a colon-delimited string. It
basically works, but it looks like strtok skips over empty
sections. In other words, if the string has 2 colons in a row, it
doesn't treat that as a null token, it just treats the 2 colons as
a single delimiter.
Is that the intended behavior?
Yes. Just one more reason to avoid strtok().
Unless that's the behavior you want. Example, breaking lines into words
with white space. You don't want a bunch of "null" words.
The point is not that the function's behaviour is not sometimes
what you want. The point is
-the default behaviour is surprising
Perhaps. About the only thing surprising to me was that the argument
you pass it is affected.
-the default behaviour is not even
usually what you want
So far I've only ever needed the default behaviour with respect to
collapsing adjacent tokens. In fact, I *expected* this! That is, for
the majority of the reasons I need to tokenized a string, this default
behaviour is exactly what I want.
-the default behaviour throws information away
Not sure what you mean here, but I assume you are referring to how it
munges its argument. I guess I just never care about this because we
always store strings in a struct that is passed around, or make copies
of things we tokenized and care about.
-if you don't like the default behaviour, see
figure 1.
I assume figure 1 is a picture of your own implementation that has
non-default requirements :)
Personally I'm with the Linux man pages on this one. Under Bugs
is the advice "Never use this function".
Well, I'll ignore this advice. For the trivial case of needing
tokenized a string to store in my own array of buffers, it works just fine.
For those requirements that strtok() does not fit we have our own
internal tokenizing routines. If all I need is to parse out (say) a
bunch of email addresses passed as a list and store them in a char**
[which was the last time I used strtok()] then it fits perfectly. In
this case I don't even care if the calling code screwed up the list. I
either get one or more valid strings or I don't. I return success or
failure and let them howl!
Of course, if I'd been bitten by the function in the past, I'd be
arguing differently.
Many of the str_ routines in the Standard have some legacy use that
explains design decisions [e.g., strncpy() and database column width].
I wonder if strtok() also has history that explains why the defaults
cause so much consternation?
Clever Monkey wrote:
William Hughes wrote:
Default User wrote:
William Hughes wrote:
ry********@gmail.com wrote:
I'm using strtok to break apart a colon-delimited string. It
basically works, but it looks like strtok skips over empty
sections. In other words, if the string has 2 colons in a row, it
doesn't treat that as a null token, it just treats the 2 colons as
a single delimiter.
Is that the intended behavior?
Yes. Just one more reason to avoid strtok().
Unless that's the behavior you want. Example, breaking lines into words
with white space. You don't want a bunch of "null" words.
The point is not that the function's behaviour is not sometimes
what you want. The point is
-the default behaviour is surprising
Perhaps. About the only thing surprising to me was that the argument
you pass it is affected.
-the default behaviour is not even
usually what you want
So far I've only ever needed the default behaviour with respect to
collapsing adjacent tokens. In fact, I *expected* this! That is, for
the majority of the reasons I need to tokenized a string, this default
behaviour is exactly what I want.
-the default behaviour throws information away
Not sure what you mean here, but I assume you are referring to how it
munges its argument.
No, it also throws away the number [and identity] of the tokens.
I guess I just never care about this because we
always store strings in a struct that is passed around, or make copies
of things we tokenized and care about.
-if you don't like the default behaviour, see
figure 1.
I assume figure 1 is a picture of your own implementation that has
non-default requirements :)
Nope. See the jargon file.
Personally I'm with the Linux man pages on this one. Under Bugs
is the advice "Never use this function".
Well, I'll ignore this advice.
Chacon a son gout.
>For the trivial case of needing
tokenized a string to store in my own array of buffers, it works just fine.
For those requirements that strtok() does not fit we have our own
internal tokenizing routines.
And your reason for not using them in preference to strtok()?
If all I need is to parse out (say) a
bunch of email addresses passed as a list and store them in a char**
[which was the last time I used strtok()] then it fits perfectly. In
this case I don't even care if the calling code screwed up the list. I
either get one or more valid strings or I don't. I return success or
failure and let them howl!
Of course, if I'd been bitten by the function in the past, I'd be
arguing differently.
Many of the str_ routines in the Standard have some legacy use that
explains design decisions [e.g., strncpy() and database column width].
I wonder if strtok() also has history that explains why the defaults
cause so much consternation?
I am sure that the defaults were chosen for what was at the
time a good reason ( maybe because
the immediate need was removing whitespace). The fact remains
they are not a good choice for a general purpose routine
(and the fact that they are "mandatory defaults" makes things
even worse).
- William Hughes
William Hughes wrote:
Clever Monkey wrote:
>William Hughes wrote:
>>Default User wrote:
William Hughes wrote:
ry********@gmail.com wrote:
>I'm using strtok to break apart a colon-delimited string. It
>basically works, but it looks like strtok skips over empty
>sections. In other words, if the string has 2 colons in a row, it
>doesn't treat that as a null token, it just treats the 2 colons as
>a single delimiter.
>>
>Is that the intended behavior?
Yes. Just one more reason to avoid strtok().
Unless that's the behavior you want. Example, breaking lines into words
with white space. You don't want a bunch of "null" words.
[...]
>> -the default behaviour throws information away
Not sure what you mean here, but I assume you are referring to how it
munges its argument.
No, it also throws away the number [and identity] of the tokens.
Ah. I always just keep track of them myself, usually as a index into
the array of strings I'm building. I think every book on the standard
library has similar example code.
>For the trivial case of needing
tokenized a string to store in my own array of buffers, it works just fine.
For those requirements that strtok() does not fit we have our own
internal tokenizing routines.
And your reason for not using them in preference to strtok()?
A few reasons come to mind. It might be too heavy-weight for my
purpose, or too specific for the simplest case of "get 0 or more things
from this delimited string", which strtok() fits perfectly. I have a
chunk of code I use that is almost cliched that I use to walk the
string, get the pieces and exit with a count.
That is to say, we've never found the need for a better_strtok(), as the
standard implementation satisfies all the necessary requirements.
At this time it has not been obvious that we need to factor this out to
a general-purpose string tokenization routine. Add to that that the
code I maintain is well-established, and I can't simply refactor for the
purpose of refactoring. Adding this much risk to a stable codebase this
late in the day is actually worse than living with standard functions
with warts.
I actually just counted the amount of times we invoke strtok() in a
major part of our product, and I found 6 discrete instances. Some of
that is dead code that has been deprecated. Two of them are places I've
added new functionality.
We _could_ have factored that out to our own function, but, quite
frankly, we never saw the point (except maybe to replace 3-5 lines of
cliche code with a single function call [which is nothing to sneeze at],
but this is usually the last thing to drive maintenance in my experience).
Anyway, I understand why strtok() is not recommended. But I also think
that once you understand the limitations and caveats that go along with
it, there is no reason not to use it for those cases where it is a good fit.
I actually look forward to the time here I'm bitten by strtok(). It
seems like the main sin it commits is being useful to some and
completely useless for others.
On 12 Oct 2006 20:42:00 -0700, "William Hughes"
<wp*******@hotmail.comwrote:
>In any case, I don't think your average maintainence drone would
know how strtok() works,
Huh! I resent that ;-)
This maintenance drone has known about strtok for many years, as well
as all the other functions in the standard library. "Maintenance
drones" not only need to be capable of writing good, solid,
maintainable code, but have the added burden of needing to figure out
what some cowboy coder really meant to do.
--
Al Balmer
Sun City, AZ
Al Balmer <al******@att.netwrites:
On 12 Oct 2006 20:42:00 -0700, "William Hughes"
<wp*******@hotmail.comwrote:
>>In any case, I don't think your average maintainence drone would
know how strtok() works,
Huh! I resent that ;-)
This maintenance drone has known about strtok for many years, as well
as all the other functions in the standard library.
[...]
Perhaps you're not average? 8-)}
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Al Balmer wrote:
On 12 Oct 2006 20:42:00 -0700, "William Hughes"
<wp*******@hotmail.comwrote:
In any case, I don't think your average maintainence drone would
know how strtok() works,
Huh! I resent that ;-)
My appologies for an unintended insult.
>
This maintenance drone has known about strtok for many years, as well
as all the other functions in the standard library. "Maintenance
drones" not only need to be capable of writing good, solid,
maintainable code, but have the added burden of needing to figure out
what some cowboy coder really meant to do.
I agree. Maintenance is difficult work and the best programmers
should be placed on maintenance, not new development.
In my experience, however, this is not the case. The term
"Maintenance drone" is all too often appropriate.
-William Hughes
On Mon, 16 Oct 2006 20:38:37 GMT, Keith Thompson <ks***@mib.org>
wrote:
>Al Balmer <al******@att.netwrites:
>On 12 Oct 2006 20:42:00 -0700, "William Hughes"
<wp*******@hotmail.comwrote:
>>>In any case, I don't think your average maintainence drone would
know how strtok() works,
Huh! I resent that ;-)
This maintenance drone has known about strtok for many years, as well
as all the other functions in the standard library.
[...]
Perhaps you're not average? 8-)}
Well, I'd like to think that ;-)
Truthfully, though I've worked for large companies, and done much
maintenance, I've never worked with many other maintenance
programmers, so I'm not at all qualified to know what the average is.
Indeed, I've seen many developers of new programs that were not
qualified. It might be more appropriate just to remove the word
"maintenance" from William's claim.
--
Al Balmer
Sun City, AZ
On 16 Oct 2006 16:53:37 -0700, "William Hughes"
<wp*******@hotmail.comwrote:
>
Al Balmer wrote:
>On 12 Oct 2006 20:42:00 -0700, "William Hughes"
<wp*******@hotmail.comwrote:
>In any case, I don't think your average maintainence drone would
know how strtok() works,
Huh! I resent that ;-)
My appologies for an unintended insult.
>>
This maintenance drone has known about strtok for many years, as well
as all the other functions in the standard library. "Maintenance
drones" not only need to be capable of writing good, solid,
maintainable code, but have the added burden of needing to figure out
what some cowboy coder really meant to do.
I agree. Maintenance is difficult work and the best programmers
should be placed on maintenance, not new development.
In my experience, however, this is not the case. The term
"Maintenance drone" is all too often appropriate.
You may well be correct. Although I've worked for large companies,
their product focus was never software, and I often worked alone, so
I'm in no position to know how qualified an average maintenance
programmer is. I can relate my experience that many programmers who
consider themselves too good for maintenance work are incompetent,
though :-)
(I worked for one very small company where the entire programming
staff was top-notch - my own <g>)
--
Al Balmer
Sun City, AZ
Al Balmer wrote:
On 16 Oct 2006 16:53:37 -0700, "William Hughes"
<wp*******@hotmail.comwrote:
Al Balmer wrote:
On 12 Oct 2006 20:42:00 -0700, "William Hughes"
<wp*******@hotmail.comwrote:
In any case, I don't think your average maintainence drone would
know how strtok() works,
Huh! I resent that ;-)
My appologies for an unintended insult.
>
This maintenance drone has known about strtok for many years, as well
as all the other functions in the standard library. "Maintenance
drones" not only need to be capable of writing good, solid,
maintainable code, but have the added burden of needing to figure out
what some cowboy coder really meant to do.
I agree. Maintenance is difficult work and the best programmers
should be placed on maintenance, not new development.
In my experience, however, this is not the case. The term
"Maintenance drone" is all too often appropriate.
You may well be correct. Although I've worked for large companies,
their product focus was never software, and I often worked alone, so
I'm in no position to know how qualified an average maintenance
programmer is. I can relate my experience that many programmers who
consider themselves too good for maintenance work are incompetent,
though :-)
Which touches on an important point. New development is more
fun than maintenance (at least this seems to be a fairly widely held
opinion). Now, as a manager you decide that your are going to
put the best programmers on maintenance. You do this, all your
best programmers leave, you get fired.
- William Hughes
in 701714 20061017 183648 "William Hughes" <wp*******@hotmail.comwrote:
>You may well be correct. Although I've worked for large companies,
their product focus was never software, and I often worked alone, so
I'm in no position to know how qualified an average maintenance
programmer is. I can relate my experience that many programmers who
consider themselves too good for maintenance work are incompetent,
though :-)
Which touches on an important point. New development is more
fun than maintenance (at least this seems to be a fairly widely held
opinion). Now, as a manager you decide that your are going to
put the best programmers on maintenance. You do this, all your
best programmers leave, you get fired.
In my experience the maintenance guys are the real heroes.
The developers quickly knock off something which roughly corresponds to
the original spec then move on.
The maintenance people then get all the bugs out, change it to what was really
required then add all the nice features.
Which touches on an important point. New development is more
fun than maintenance (at least this seems to be a fairly widely held
opinion). Now, as a manager you decide that your are going to
put the best programmers on maintenance. You do this, all your
best programmers leave, you get fired.
That is the reality...(up to my limited knowledge.)
In someone's Signature in comp.lang.c i have seen,
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
Derivation From the above stmt.
"If you are doing debugging/Maintance of software you are more clever
than devloper, most probably your senior :)"
Actually Wrong Thinking here, for detailed discussion there is a thread
on
comp.software-eng named "most software jobs are software maintenance
rather than new development?" and i think some Interesting Thoughts are
there.
In my experience the maintenance guys are the real heroes.
The developers quickly knock off something which roughly corresponds to
the original spec then move on.
The maintenance people then get all the bugs out, change it to what was really
required then add all the nice features.
Have To Agree...
Sorry for giving reply on Not "C lang" related answer,
Cheers
--Raxit
"William Hughes" <wp*******@hotmail.comwrote:
Al Balmer wrote:
You may well be correct. Although I've worked for large companies,
their product focus was never software, and I often worked alone, so
I'm in no position to know how qualified an average maintenance
programmer is. I can relate my experience that many programmers who
consider themselves too good for maintenance work are incompetent,
though :-)
Which touches on an important point. New development is more
fun than maintenance (at least this seems to be a fairly widely held
opinion). Now, as a manager you decide that your are going to
put the best programmers on maintenance. You do this, all your
best programmers leave, you get fired.
IMO, the best thing (but probably equally infeasible) would be not to
have maintenance or development programmers, but project programmers.
You developed it, you maintain it.
Richard
Richard Bos wrote:
"William Hughes" <wp*******@hotmail.comwrote:
Al Balmer wrote:
You may well be correct. Although I've worked for large companies,
their product focus was never software, and I often worked alone, so
I'm in no position to know how qualified an average maintenance
programmer is. I can relate my experience that many programmers who
consider themselves too good for maintenance work are incompetent,
though :-)
Which touches on an important point. New development is more
fun than maintenance (at least this seems to be a fairly widely held
opinion). Now, as a manager you decide that your are going to
put the best programmers on maintenance. You do this, all your
best programmers leave, you get fired.
IMO, the best thing (but probably equally infeasible) would be not to
have maintenance or development programmers, but project programmers.
You developed it, you maintain it.
Two problems:
- the lifetime of many (most?) projects is longer that the
time a programmer spends with the company.
-if there is more than one person on the project the
maintenance will be done by the more junior
(an edict that maintenance work is to be distributed
in any other way could only come from a soon to be
fired member of senior management)
- William Hughes
On 18 Oct 2006 00:29:20 -0700, ra************@yahoo.co.in wrote:
>"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
yes, but for debug can be enought some routines that find errors
*time* and luck :) This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: ern |
last post by:
I'm using it like this:
char * _command = "one two three four";
char * g_UserCommands;
const char * delimeters = " ";
g_UserCommands = strtok(_command, delimeters);
g_UserCommands =...
|
by: Fernando Barsoba |
last post by:
Hi,
I'm using strtok() in the following way:
void obtain_param(char *pmsg, CONF_PARAMS *cnf ) {
char *s1, *s2;
size_t msg_len;
s1 = strtok (pmsg,":");
if (s1) {
|
by: Peter |
last post by:
hi all, the strtok() cannot phrase the token within another token, am i
correct?
For example, i want to get the second word of every row of a file, how
to use strok to complete this?
thanks...
|
by: plmanikandan |
last post by:
Hi,
I need to split the value stored in a string and store them to another
charrecter array.I am using strtok function.But i am getting invalid
output when there is no value between delimiter
...
|
by: hu |
last post by:
hi, everybody!
I'm testing the fuction of strtok(). The environment is WinXP, VC++6.0.
Program is simple, but mistake is confusing. First, the below code can get
right outcome:"ello world, hello...
|
by: Michael |
last post by:
Hi,
I have a proble I don't understand when using strtok(). It seems that if I
make a call to strtok(), then make a call to another function that also
makes use of strtok(), the original call is...
|
by: Mr John FO Evans |
last post by:
I cam across an interesting limitation to the use of strtok.
I have two strings on which I want strtok to operate.
However since strtok has only one memory of the residual string I must
complete...
|
by: Pietro Cerutti |
last post by:
Hello,
here I have a strange problem with a real simple strtok example.
The program is as follows:
### BEGIN STRTOK ###
#include <string.h>
#include <stdio.h>
|
by: semi_evil |
last post by:
I downloaded a few PHP scripts from various sites, in part to use them
as is, and partly to study and learn from them.
One script is littered with strtok() occurrences. So I checked the
manual...
|
by: siddhu |
last post by:
Dear experts,
As I know strtok_r is re-entrant version of strtok.
strtok_r() is called with s1(lets say) as its first parameter.
Remaining tokens from s1 are obtained by calling strtok_r() with...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| |
